Re: [Intel-gfx] [PATCH v6 3/3] drm/i915/dp: Expose connector VRR monitor range via debugfs
Hi Manasi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
linus/master next-20200613]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Manasi-Navare/VRR-capable-attach-prop-in-i915-DPCD-helper-VRR-debugfs/20200613-070517
base: git://anongit.freedesktop.org/drm-intel for-linux-next
:: branch date: 2 days ago
:: commit date: 2 days ago
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
cppcheck warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/display/intel_display_debugfs.c:2258:0: warning:
>> Invalid number of character '{' when no macros are defined. [syntaxError]
^
>> drivers/gpu/drm/i915/display/intel_display_debugfs.c:2258:0: warning:
>> Invalid number of character '{' when these macros are defined:
>> 'CONFIG_DEBUG_FS'. [syntaxError]
^
>> drivers/gpu/drm/i915/display/intel_display_debugfs.c:2258:0: warning:
>> Invalid number of character '{' when these macros are defined:
>> 'CONFIG_DRM_FBDEV_EMULATION'. [syntaxError]
^
#
https://github.com/0day-ci/linux/commit/670af3cf7a3a36bb87776fbfd7f913cd33681bbc
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 670af3cf7a3a36bb87776fbfd7f913cd33681bbc
vim +2258 drivers/gpu/drm/i915/display/intel_display_debugfs.c
670af3cf7a3a36 Bhanuprakash Modem 2020-06-12 2202
926b005cd8c4e3 Jani Nikula2020-02-11 2203 /**
926b005cd8c4e3 Jani Nikula2020-02-11 2204 *
intel_connector_debugfs_add - add i915 specific connector debugfs files
926b005cd8c4e3 Jani Nikula2020-02-11 2205 * @connector: pointer to a
registered drm_connector
926b005cd8c4e3 Jani Nikula2020-02-11 2206 *
926b005cd8c4e3 Jani Nikula2020-02-11 2207 * Cleanup will be done by
drm_connector_unregister() through a call to
926b005cd8c4e3 Jani Nikula2020-02-11 2208 *
drm_debugfs_connector_remove().
926b005cd8c4e3 Jani Nikula2020-02-11 2209 *
926b005cd8c4e3 Jani Nikula2020-02-11 2210 * Returns 0 on success,
negative error codes on error.
926b005cd8c4e3 Jani Nikula2020-02-11 2211 */
926b005cd8c4e3 Jani Nikula2020-02-11 2212 int
intel_connector_debugfs_add(struct drm_connector *connector)
926b005cd8c4e3 Jani Nikula2020-02-11 2213 {
926b005cd8c4e3 Jani Nikula2020-02-11 2214 struct dentry *root =
connector->debugfs_entry;
926b005cd8c4e3 Jani Nikula2020-02-11 2215 struct drm_i915_private
*dev_priv = to_i915(connector->dev);
926b005cd8c4e3 Jani Nikula2020-02-11 2216
926b005cd8c4e3 Jani Nikula2020-02-11 2217 /* The connector must
have been registered beforehands. */
926b005cd8c4e3 Jani Nikula2020-02-11 2218 if (!root)
926b005cd8c4e3 Jani Nikula2020-02-11 2219 return -ENODEV;
926b005cd8c4e3 Jani Nikula2020-02-11 2220
926b005cd8c4e3 Jani Nikula2020-02-11 2221 if
(connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
926b005cd8c4e3 Jani Nikula2020-02-11
debugfs_create_file("i915_panel_timings", S_IRUGO, root,
926b005cd8c4e3 Jani Nikula2020-02-11 2223
connector, _panel_fops);
926b005cd8c4e3 Jani Nikula2020-02-11 2224
debugfs_create_file("i915_psr_sink_status", S_IRUGO, root,
926b005cd8c4e3 Jani Nikula2020-02-11 2225
connector, _psr_sink_status_fops);
926b005cd8c4e3 Jani Nikula2020-02-11 2226 }
926b005cd8c4e3 Jani Nikula2020-02-11 2227
926b005cd8c4e3 Jani Nikula2020-02-11 2228 if
(connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
926b005cd8c4e3 Jani Nikula2020-02-11 2229
connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
926b005cd8c4e3 Jani Nikula2020-02-11 2230
connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
926b005cd8c4e3 Jani Nikula2020-02-11 2231
debugfs_create_file("i915_hdcp_sink_capability", S_IRUGO, root,
926b005cd8c4e3 Jani Nikula2020-02-11 2232
connector, _hdcp_sink_capability_fops);
926b005cd8c4e3 Jani Nikula2020-02-11 2233 }
926b005cd8c4e3 Jani Nikula2020-02-11 2234
926b005cd8c4e3 Jani Nikula2020-02-11 2235 if (INTEL_GEN(dev_priv)
>= 10 &&
926b005cd8c4e3 Jani Nikula2020-02-11 2236
[Intel-gfx] [drm-intel:for-linux-next-fixes 4/16] drivers/gpu/drm/i915/gt/selftest_lrc.c:1402:3: error: too few arguments to function 'engine_heartbeat_enable'
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head: add78d27d388520cbed6a7bf01d1e0afa183314d
commit: 04dc41776145f539ab6da442cb633e45539bed9a [4/16] drm/i915/gt: Prevent
timeslicing into unpreemptable requests
config: i386-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5953:
drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'live_timeslice_nopreempt':
drivers/gpu/drm/i915/gt/selftest_lrc.c:1333:3: error: too few arguments to
function 'engine_heartbeat_disable'
1333 | engine_heartbeat_disable(engine);
| ^~~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:54:13: note: declared here
54 | static void engine_heartbeat_disable(struct intel_engine_cs *engine,
| ^~~~
>> drivers/gpu/drm/i915/gt/selftest_lrc.c:1402:3: error: too few arguments to
>> function 'engine_heartbeat_enable'
1402 | engine_heartbeat_enable(engine);
| ^~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:64:13: note: declared here
64 | static void engine_heartbeat_enable(struct intel_engine_cs *engine,
| ^~~
vim +/engine_heartbeat_enable +1402 drivers/gpu/drm/i915/gt/selftest_lrc.c
1300
1301 static int live_timeslice_nopreempt(void *arg)
1302 {
1303 struct intel_gt *gt = arg;
1304 struct intel_engine_cs *engine;
1305 enum intel_engine_id id;
1306 struct igt_spinner spin;
1307 int err = 0;
1308
1309 /*
1310 * We should not timeslice into a request that is marked with
1311 * I915_REQUEST_NOPREEMPT.
1312 */
1313 if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
1314 return 0;
1315
1316 if (igt_spinner_init(, gt))
1317 return -ENOMEM;
1318
1319 for_each_engine(engine, gt, id) {
1320 struct intel_context *ce;
1321 struct i915_request *rq;
1322 unsigned long timeslice;
1323
1324 if (!intel_engine_has_preemption(engine))
1325 continue;
1326
1327 ce = intel_context_create(engine);
1328 if (IS_ERR(ce)) {
1329 err = PTR_ERR(ce);
1330 break;
1331 }
1332
1333 engine_heartbeat_disable(engine);
1334 timeslice = xchg(>props.timeslice_duration_ms,
1);
1335
1336 /* Create an unpreemptible spinner */
1337
1338 rq = igt_spinner_create_request(, ce,
MI_ARB_CHECK);
1339 intel_context_put(ce);
1340 if (IS_ERR(rq)) {
1341 err = PTR_ERR(rq);
1342 goto out_heartbeat;
1343 }
1344
1345 i915_request_get(rq);
1346 i915_request_add(rq);
1347
1348 if (!igt_wait_for_spinner(, rq)) {
1349 i915_request_put(rq);
1350 err = -ETIME;
1351 goto out_spin;
1352 }
1353
1354 set_bit(I915_FENCE_FLAG_NOPREEMPT, >fence.flags);
1355 i915_request_put(rq);
1356
1357 /* Followed by a maximum priority barrier (heartbeat) */
1358
1359 ce = intel_context_create(engine);
1360 if (IS_ERR(ce)) {
1361 err = PTR_ERR(rq);
1362 goto out_spin;
1363 }
1364
1365 rq = intel_context_create_request(ce);
1366 intel_context_put(ce);
1367 if (IS_ERR(rq)) {
1368 err = PTR_ERR(rq);
1369 goto out_spin;
1370 }
1371
1372 rq->sched.attr.priority = I915_PRIORITY_BARRIER;
1373 i915_request_get(rq);
1374 i915_request_add(rq);
1375
1376 /*
1377 * Wait until the barrier is in ELSP, and we know
timeslicing
1378 * will have been activated.
1379 */
1380 if (wait_for_submit(engine, rq, HZ / 2)) {
1381 i915_request_put(rq);
1382 err = -ETIME;
1383 goto out_spin;
1384 }
1385
1386 /*
1387 * Since the ELSP[0] request is unpreemptible, it
should not
1388 * allow the
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Exercise far preemption rollbacks (rev2)
== Series Details == Series: drm/i915/selftests: Exercise far preemption rollbacks (rev2) URL : https://patchwork.freedesktop.org/series/78384/ State : success == Summary == CI Bug Log - changes from CI_DRM_8630_full -> Patchwork_17957_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17957_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-apl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-apl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-apl1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#1528]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html * igt@gem_ctx_persistence@process: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-kbl7/igt@gem_ctx_persiste...@process.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-kbl2/igt@gem_ctx_persiste...@process.html * igt@gem_exec_schedule@implicit-boths@bcs0: - shard-snb: [PASS][7] -> [INCOMPLETE][8] ([i915#82]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-snb2/igt@gem_exec_schedule@implicit-bo...@bcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-snb4/igt@gem_exec_schedule@implicit-bo...@bcs0.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-glk8/igt@gem_exec_whis...@basic-queues-priority.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-glk9/igt@gem_exec_whis...@basic-queues-priority.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / [i915#95]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-glk4/igt@kms_big...@linear-64bpp-rotate-180.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_color@pipe-b-ctm-negative: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +9 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-skl10/igt@kms_co...@pipe-b-ctm-negative.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-skl8/igt@kms_co...@pipe-b-ctm-negative.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-apl: [PASS][15] -> [DMESG-FAIL][16] ([i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-apl2/igt@kms_flip_til...@flip-changes-tiling-y.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-apl2/igt@kms_flip_til...@flip-changes-tiling-y.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#95]) +11 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-apl1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-plflip-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-apl3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-plflip-blt.html * igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary: - shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-iclb7/igt@kms_frontbuffer_track...@fbc-shrfb-scaledprimary.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-iclb3/igt@kms_frontbuffer_track...@fbc-shrfb-scaledprimary.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-move: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-move.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-move.html * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-snb: [PASS][23] -> [SKIP][24] ([fdo#109271]) +2 similar issues [23]:
[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5972:
drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'live_timeslice_nopreempt':
drivers/gpu/drm/i915/gt/selftest_lrc.c:1333:3: error: too few arguments to
function 'engine_heartbeat_disable'
1333 | engine_heartbeat_disable(engine);
| ^~~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:54:13: note: declared here
54 | static void engine_heartbeat_disable(struct intel_engine_cs *engine,
| ^~~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:1402:3: error: too few arguments to
function 'engine_heartbeat_enable'
1402 | engine_heartbeat_enable(engine);
| ^~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:64:13: note: declared here
64 | static void engine_heartbeat_enable(struct intel_engine_cs *engine,
| ^~~
Caused by commit
04dc41776145 ("drm/i915/gt: Prevent timeslicing into unpreemptable requests")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpZ4xP9ctkgf.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Don't flush the tasklet if not setup
== Series Details ==
Series: drm/i915/gt: Don't flush the tasklet if not setup
URL : https://patchwork.freedesktop.org/series/78382/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8629_full -> Patchwork_17955_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17955_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17955_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17955_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/shard-iclb2/igt@gem_ctx_isolation@preservation...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/shard-iclb3/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_exec_balancer@bonded-early:
- shard-tglb: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/shard-tglb7/igt@gem_exec_balan...@bonded-early.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/shard-tglb5/igt@gem_exec_balan...@bonded-early.html
### Piglit changes ###
Possible regressions
* spec@glsl-4.00@execution@built-in-functions@fs-op-mult-dmat2x4-dmat4x2
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/pig-icl-1065g7/spec@glsl-4.00@execution@built-in-functi...@fs-op-mult-dmat2x4-dmat4x2.html
* spec@glsl-4.00@execution@built-in-functions@gs-op-div-double-dmat3x4 (NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][6] +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/pig-icl-1065g7/spec@glsl-4.00@execution@built-in-functi...@gs-op-div-double-dmat3x4.html
New tests
-
New tests have been introduced between CI_DRM_8629_full and
Patchwork_17955_full:
### New Piglit tests (6) ###
* spec@glsl-4.00@execution@built-in-functions@fs-op-mult-dmat2x4-dmat4x2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@glsl-4.00@execution@built-in-functions@fs-op-mult-dmat3x4-dmat3:
- Statuses : 1 crash(s)
- Exec time: [93.95] s
* spec@glsl-4.00@execution@built-in-functions@fs-op-mult-dmat4-dmat3x4:
- Statuses : 1 crash(s)
- Exec time: [159.53] s
* spec@glsl-4.00@execution@built-in-functions@fs-op-sub-dmat4-double:
- Statuses : 1 crash(s)
- Exec time: [28.11] s
* spec@glsl-4.00@execution@built-in-functions@gs-op-div-double-dmat3x4:
- Statuses : 1 crash(s)
- Exec time: [20.37] s
* spec@glsl-4.00@execution@built-in-functions@vs-op-div-dvec3-dvec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_17955_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#198])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/shard-skl1/igt@gem_ctx_isolation@preservation...@vcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/shard-skl8/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_exec_reloc@basic-concurrent0:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#1930])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html
* igt@gem_mmap_offset@ptrace@gtt:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] /
[i915#95]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/shard-kbl6/igt@gem_mmap_offset@ptr...@gtt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/shard-kbl1/igt@gem_mmap_offset@ptr...@gtt.html
* igt@gem_mmap_wc@write-cpu-read-wc:
- shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#95]) +26
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/shard-apl3/igt@gem_mmap...@write-cpu-read-wc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/shard-apl1/igt@gem_mmap...@write-cpu-read-wc.html
* igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk: [PASS][15] -> [DMESG-FAIL][16] ([i915#118] /
[i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/shard-glk6/igt@kms_big...@y-tiled-64bpp-rotate-180.html
[16]:
[Intel-gfx] [drm-intel:for-linux-next-fixes 4/16] drivers/gpu/drm/i915/gt/selftest_lrc.c:1333:34: error: too few arguments to function call, expected 2, have 1
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head: add78d27d388520cbed6a7bf01d1e0afa183314d
commit: 04dc41776145f539ab6da442cb633e45539bed9a [4/16] drm/i915/gt: Prevent
timeslicing into unpreemptable requests
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
3d8149c2a1228609fd7d7c91a04681304a2f0ca9)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 04dc41776145f539ab6da442cb633e45539bed9a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5953:
>> drivers/gpu/drm/i915/gt/selftest_lrc.c:1333:34: error: too few arguments to
>> function call, expected 2, have 1
engine_heartbeat_disable(engine);
^
drivers/gpu/drm/i915/gt/selftest_lrc.c:54:13: note: 'engine_heartbeat_disable'
declared here
static void engine_heartbeat_disable(struct intel_engine_cs *engine,
^
drivers/gpu/drm/i915/gt/selftest_lrc.c:1402:33: error: too few arguments to
function call, expected 2, have 1
engine_heartbeat_enable(engine);
~~~ ^
drivers/gpu/drm/i915/gt/selftest_lrc.c:64:13: note: 'engine_heartbeat_enable'
declared here
static void engine_heartbeat_enable(struct intel_engine_cs *engine,
^
2 errors generated.
vim +1333 drivers/gpu/drm/i915/gt/selftest_lrc.c
1300
1301 static int live_timeslice_nopreempt(void *arg)
1302 {
1303 struct intel_gt *gt = arg;
1304 struct intel_engine_cs *engine;
1305 enum intel_engine_id id;
1306 struct igt_spinner spin;
1307 int err = 0;
1308
1309 /*
1310 * We should not timeslice into a request that is marked with
1311 * I915_REQUEST_NOPREEMPT.
1312 */
1313 if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
1314 return 0;
1315
1316 if (igt_spinner_init(, gt))
1317 return -ENOMEM;
1318
1319 for_each_engine(engine, gt, id) {
1320 struct intel_context *ce;
1321 struct i915_request *rq;
1322 unsigned long timeslice;
1323
1324 if (!intel_engine_has_preemption(engine))
1325 continue;
1326
1327 ce = intel_context_create(engine);
1328 if (IS_ERR(ce)) {
1329 err = PTR_ERR(ce);
1330 break;
1331 }
1332
> 1333 engine_heartbeat_disable(engine);
1334 timeslice = xchg(>props.timeslice_duration_ms,
1);
1335
1336 /* Create an unpreemptible spinner */
1337
1338 rq = igt_spinner_create_request(, ce,
MI_ARB_CHECK);
1339 intel_context_put(ce);
1340 if (IS_ERR(rq)) {
1341 err = PTR_ERR(rq);
1342 goto out_heartbeat;
1343 }
1344
1345 i915_request_get(rq);
1346 i915_request_add(rq);
1347
1348 if (!igt_wait_for_spinner(, rq)) {
1349 i915_request_put(rq);
1350 err = -ETIME;
1351 goto out_spin;
1352 }
1353
1354 set_bit(I915_FENCE_FLAG_NOPREEMPT, >fence.flags);
1355 i915_request_put(rq);
1356
1357 /* Followed by a maximum priority barrier (heartbeat) */
1358
1359 ce = intel_context_create(engine);
1360 if (IS_ERR(ce)) {
1361 err = PTR_ERR(rq);
1362 goto out_spin;
1363 }
1364
1365 rq = intel_context_create_request(ce);
1366 intel_context_put(ce);
1367 if (IS_ERR(rq)) {
1368 err = PTR_ERR(rq);
1369 goto out_spin;
1370 }
1371
1372 rq->sched.attr.priority = I915_PRIORITY_BARRIER;
1373 i915_request_get(rq);
1374 i915_request_add(rq);
1375
1376 /*
1377 * Wait until the barrier is in ELSP, and we know
timeslicing
1378 * will have been
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Exercise far preemption rollbacks (rev2)
== Series Details == Series: drm/i915/selftests: Exercise far preemption rollbacks (rev2) URL : https://patchwork.freedesktop.org/series/78384/ State : success == Summary == CI Bug Log - changes from CI_DRM_8630 -> Patchwork_17957 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/index.html Known issues Here are the changes found in Patchwork_17957 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-tgl-u2/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_backlight@basic-brightness: - fi-whl-u: [PASS][3] -> [DMESG-WARN][4] ([i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html * igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@gem_render_linear_blits@basic: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-tgl-y/igt@gem_render_linear_bl...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-tgl-y/igt@gem_render_linear_bl...@basic.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-glk-dsi/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@kms_psr@cursor_plane_move: - fi-tgl-y: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-tgl-y/igt@kms_psr@cursor_plane_move.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-tgl-y/igt@kms_psr@cursor_plane_move.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8630/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17957/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html *
Re: [Intel-gfx] [PATCH v7 3/3] drm/i915/dp: Expose connector VRR monitor range via debugfs
On Mon, Jun 15, 2020 at 10:36:28PM +0100, Emil Velikov wrote:
> Hi Manasi,
>
> On Sat, 13 Jun 2020 at 00:55, Manasi Navare wrote:
> >
> > From: Bhanuprakash Modem
> >
> > [Why]
> > It's useful to know the min and max vrr range for IGT testing.
> >
> > [How]
> > Expose the min and max vfreq for the connector via a debugfs file
> > on the connector, "vrr_range".
> >
> > Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> >
> > v7:
> > * Fix cmpilation due to rebase
> > v6:
> > * Rebase (manasi)
> > v5:
> > * Rename to vrr_range to match AMD debugfs
> > v4:
> > * Rebase
> > v3:
> > * Remove the unnecessary debug print (Manasi)
> > v2:
> > * Fix the typo in max_vfreq (Manasi)
> > * Change the name of node to i915_vrr_info so we can add
> > other vrr info for more debug info (Manasi)
> > * Change the VRR capable to display Yes or No (Manasi)
> > * Fix indentation checkpatch errors (Manasi)
> >
> Nit: generally revision log is listed in v2 -> v6 order.
Okay point noted. Will update this in the next rev
>
> > Signed-off-by: Bhanuprakash Modem
> > Signed-off-by: Manasi Navare
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Tested-by: Manasi Navare
> > ---
> > .../drm/i915/display/intel_display_debugfs.c | 22 ++-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 28dd717e943a..2921f7d2a26e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -2185,6 +2185,21 @@ static const struct file_operations
> > i915_dsc_fec_support_fops = {
> > .write = i915_dsc_fec_support_write
> > };
> >
> > +static int vrr_range_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > +
> > + if (connector->status != connector_status_connected)
> > + return -ENODEV;
> > +
> > + seq_printf(m, "Vrr_capable: %s\n",
> > yesno(intel_dp_is_vrr_capable(connector)));
> > + seq_printf(m, "Min: %u\n",
> > (u8)connector->display_info.monitor_range.min_vfreq);
> > + seq_printf(m, "Max: %u\n",
> > (u8)connector->display_info.monitor_range.max_vfreq);
> > +
> > + return 0;
> > +}
> > +DEFINE_SHOW_ATTRIBUTE(vrr_range);
> > +
> > /**
> > * intel_connector_debugfs_add - add i915 specific connector debugfs files
> > * @connector: pointer to a registered drm_connector
> > @@ -2220,10 +2235,15 @@ int intel_connector_debugfs_add(struct
> > drm_connector *connector)
> > if (INTEL_GEN(dev_priv) >= 10 &&
> > ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
> > !to_intel_connector(connector)->mst_port) ||
> > -connector->connector_type == DRM_MODE_CONNECTOR_eDP))
> > +connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
> > debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
> > connector, _dsc_fec_support_fops);
> >
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + debugfs_create_file("vrr_range", S_IRUGO,
> > + root, connector,
> > _range_fops);
> > + }
> > +
>
> I think this should be added by core drm. Ideally drm will add it
> automatically for each connector that the driver has called
> drm_connector_attach_vrr_capable_property() upon.
>
But in this case drm_connector_attach_vrr_capable_property() is called by
individual
driver since its an optional connector property. So we call this inside i915.
Also currently AMD sets this debugfs inside AMD IMO, so setting this here for
now.
But I agree that can be moved to drm core may be when drm_display_info gets
populated
with min and max, thats where drm can add this?
Manasi
> -Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/3] drm/i915/dp: Expose connector VRR monitor range via debugfs
Hi Manasi,
On Sat, 13 Jun 2020 at 00:55, Manasi Navare wrote:
>
> From: Bhanuprakash Modem
>
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
>
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector, "vrr_range".
>
> Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
>
> v7:
> * Fix cmpilation due to rebase
> v6:
> * Rebase (manasi)
> v5:
> * Rename to vrr_range to match AMD debugfs
> v4:
> * Rebase
> v3:
> * Remove the unnecessary debug print (Manasi)
> v2:
> * Fix the typo in max_vfreq (Manasi)
> * Change the name of node to i915_vrr_info so we can add
> other vrr info for more debug info (Manasi)
> * Change the VRR capable to display Yes or No (Manasi)
> * Fix indentation checkpatch errors (Manasi)
>
Nit: generally revision log is listed in v2 -> v6 order.
> Signed-off-by: Bhanuprakash Modem
> Signed-off-by: Manasi Navare
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Tested-by: Manasi Navare
> ---
> .../drm/i915/display/intel_display_debugfs.c | 22 ++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 28dd717e943a..2921f7d2a26e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2185,6 +2185,21 @@ static const struct file_operations
> i915_dsc_fec_support_fops = {
> .write = i915_dsc_fec_support_write
> };
>
> +static int vrr_range_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> +
> + if (connector->status != connector_status_connected)
> + return -ENODEV;
> +
> + seq_printf(m, "Vrr_capable: %s\n",
> yesno(intel_dp_is_vrr_capable(connector)));
> + seq_printf(m, "Min: %u\n",
> (u8)connector->display_info.monitor_range.min_vfreq);
> + seq_printf(m, "Max: %u\n",
> (u8)connector->display_info.monitor_range.max_vfreq);
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(vrr_range);
> +
> /**
> * intel_connector_debugfs_add - add i915 specific connector debugfs files
> * @connector: pointer to a registered drm_connector
> @@ -2220,10 +2235,15 @@ int intel_connector_debugfs_add(struct drm_connector
> *connector)
> if (INTEL_GEN(dev_priv) >= 10 &&
> ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
> !to_intel_connector(connector)->mst_port) ||
> -connector->connector_type == DRM_MODE_CONNECTOR_eDP))
> +connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
> debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
> connector, _dsc_fec_support_fops);
>
> + if (INTEL_GEN(dev_priv) >= 12)
> + debugfs_create_file("vrr_range", S_IRUGO,
> + root, connector, _range_fops);
> + }
> +
I think this should be added by core drm. Ideally drm will add it
automatically for each connector that the driver has called
drm_connector_attach_vrr_capable_property() upon.
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/mipi-dbi: Remove ->enabled
Hi Daniel, On Fri, 12 Jun 2020 at 17:01, Daniel Vetter wrote: > > The atomic helpers try really hard to not lose track of things, > duplicating enabled tracking in the driver is at best confusing. > Double-enabling or disabling is a bug in atomic helpers. > > In the fb_dirty function we can just assume that the fb always exists, > simple display pipe helpers guarantee that the crtc is only enabled > together with the output, so we always have a primary plane around. > > Now in the update function we need to be a notch more careful, since > that can also get called when the crtc is off. And we don't want to > upload frames when that's the case, so filter that out too. > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: David Lechner > --- > drivers/gpu/drm/drm_mipi_dbi.c | 16 ++-- > drivers/gpu/drm/tiny/ili9225.c | 12 +++- > drivers/gpu/drm/tiny/st7586.c | 11 +++ > include/drm/drm_mipi_dbi.h | 5 - > 4 files changed, 12 insertions(+), 32 deletions(-) > > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c > index fd8d672972a9..79532b9a324a 100644 > --- a/drivers/gpu/drm/drm_mipi_dbi.c > +++ b/drivers/gpu/drm/drm_mipi_dbi.c > @@ -268,7 +268,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, > struct drm_rect *rect) > bool full; > void *tr; > > - if (!dbidev->enabled) > + if (WARN_ON(!fb)) > return; > AFAICT no other driver has such WARN_ON. Let's drop that - it is pretty confusing and misleading as-is. With that, patches 7/8 and 8/8 are: Reviewed-by: Emil Velikov -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Exercise far preemption rollbacks (rev2)
== Series Details ==
Series: drm/i915/selftests: Exercise far preemption rollbacks (rev2)
URL : https://patchwork.freedesktop.org/series/78384/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
39ae8f5dde72 drm/i915/selftests: Exercise far preemption rollbacks
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e36ba817fa96 ("drm/i915/gt:
Incrementally check for rewinding")'
#19:
References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding")
total: 1 errors, 0 warnings, 0 checks, 162 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 6/8] drm/i915/display: Implement infoframes readback for LSPCON
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Thursday, June 11, 2020 9:31 PM
> > > To: Shankar, Uma
> > > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com;
> > > Mun, Gwan- gyeong
> > > Subject: Re: [v3 6/8] drm/i915/display: Implement infoframes
> > > readback for LSPCON
> > >
> > > On Thu, Jun 11, 2020 at 06:46:50PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Jun 11, 2020 at 12:42:30AM +0530, Uma Shankar wrote:
> > > > > Implemented Infoframes enabled readback for LSPCON devices.
> > > > > This will help align the implementation with state readback
> > > > > infrastructure.
> > > > >
> > > > > Signed-off-by: Uma Shankar
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_lspcon.c | 63
> > > > > -
> > > > > 1 file changed, 61 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > > index 9034ce6f20b9..0ebe9a700291 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > > @@ -576,11 +576,70 @@ void lspcon_set_infoframes(struct
> > > > > intel_encoder
> > > *encoder,
> > > > > buf, ret);
> > > > > }
> > > > >
> > > > > +static bool _lspcon_read_avi_infoframe_enabled_mca(struct
> > > > > +drm_dp_aux *aux) {
> > > > > + int ret;
> > > > > + u32 val = 0;
> > > > > + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> > > > > +
> > > > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > > > + if (ret < 0) {
> > > > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > > > + return false;
> > > > > + }
> > > > > +
> > > > > + if (val & LSPCON_MCA_AVI_IF_KICKOFF)
> > > > > + return true;
> > > > > +
> > > > > + return false;
> > > >
> > > > return val & ...;
> > > >
> > > > > +}
> > > > > +
> > > > > +static bool _lspcon_read_avi_infoframe_enabled_parade(struct
> > > > > +drm_dp_aux *aux) {
> > > > > + int ret;
> > > > > + u32 val = 0;
> > > > > + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> > > > > +
> > > > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > > > + if (ret < 0) {
> > > > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > > > + return false;
> > > > > + }
> > > > > +
> > > > > + if (val & LSPCON_PARADE_AVI_IF_KICKOFF)
> > > > > + return true;
> > > > > +
> > > > > + return false;
> > > > > +}
> > > > > +
> > > > > u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> > > > > const struct intel_crtc_state
> > > > > *pipe_config) {
> > > > > - /* FIXME actually read this from the hw */
> > > > > - return 0;
> > > > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > > + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> > > > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > > > + bool infoframes_enabled;
> > > > > + u32 mask = 0;
> > > > > + u32 val;
> > > > > +
> > > > > + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> > > > > + infoframes_enabled =
> > > _lspcon_read_avi_infoframe_enabled_mca(_dp->aux);
> > > > > + else
> > > > > + infoframes_enabled =
> > > > > +_lspcon_read_avi_infoframe_enabled_parade(_dp->aux);
> > > > > +
> > > > > + if (infoframes_enabled)
> > > > > + return true;
> > > >
> > > > This is supposed to return a bitmask of all enabled infoframes.
> >
> > > Actually since we're dealing with both the LSPCON specific stuff and
> > > DIP stuff for the DRM infoframe I think we should stop using using
> > > intel_hdmi_infoframes_enabled(), and instead provide a LSPCON
> > > specific replacement for it. That way we can directly return the
> > > abstract bitmask instead of pretending to return a bitmask of the DIP
> > > bits.
> >
> > Sure, will fix this and resend the next version.
> >
> > > >
> > > > Also my question "how do we turn off infoframes once enabled?"
> > > > from
> > > > https://patchwork.freedesktop.org/patch/351719/?series=72928=1
> > > > still remains unanswered...
> >
> > For the AVI infoframe we generally compute and change the respective
> > values. If no change is requested and computed we can let the existing
> > infoframes be transmitted. AFAIK there is no mechanism called out, to
> > explicitly disable this on Lspcon. Have not seen any issues due to this, so
> hoping that it may be safe even if they are enabled.
>
> It's not valid to transmit infoframes to DVI sinks.
With your fix, we won't be enabling or setting the infoframe on DVI sinks.
If I understand correctly, we may have issue if we connect HDMI (where we would
have
sent the infoframe) and later unplug and plug a DVI sink. With unplug if Lspcon
is not
resetting this internally then this will be a problem. I
Re: [Intel-gfx] [v3 6/8] drm/i915/display: Implement infoframes readback for LSPCON
On Mon, Jun 15, 2020 at 08:39:55PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Thursday, June 11, 2020 9:31 PM
> > To: Shankar, Uma
> > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Mun, Gwan-
> > gyeong
> > Subject: Re: [v3 6/8] drm/i915/display: Implement infoframes readback for
> > LSPCON
> >
> > On Thu, Jun 11, 2020 at 06:46:50PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 11, 2020 at 12:42:30AM +0530, Uma Shankar wrote:
> > > > Implemented Infoframes enabled readback for LSPCON devices.
> > > > This will help align the implementation with state readback
> > > > infrastructure.
> > > >
> > > > Signed-off-by: Uma Shankar
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_lspcon.c | 63
> > > > -
> > > > 1 file changed, 61 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > index 9034ce6f20b9..0ebe9a700291 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > > @@ -576,11 +576,70 @@ void lspcon_set_infoframes(struct intel_encoder
> > *encoder,
> > > > buf, ret);
> > > > }
> > > >
> > > > +static bool _lspcon_read_avi_infoframe_enabled_mca(struct
> > > > +drm_dp_aux *aux) {
> > > > + int ret;
> > > > + u32 val = 0;
> > > > + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> > > > +
> > > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > > + if (ret < 0) {
> > > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > > + return false;
> > > > + }
> > > > +
> > > > + if (val & LSPCON_MCA_AVI_IF_KICKOFF)
> > > > + return true;
> > > > +
> > > > + return false;
> > >
> > > return val & ...;
> > >
> > > > +}
> > > > +
> > > > +static bool _lspcon_read_avi_infoframe_enabled_parade(struct
> > > > +drm_dp_aux *aux) {
> > > > + int ret;
> > > > + u32 val = 0;
> > > > + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> > > > +
> > > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > > + if (ret < 0) {
> > > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > > + return false;
> > > > + }
> > > > +
> > > > + if (val & LSPCON_PARADE_AVI_IF_KICKOFF)
> > > > + return true;
> > > > +
> > > > + return false;
> > > > +}
> > > > +
> > > > u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> > > > const struct intel_crtc_state
> > > > *pipe_config) {
> > > > - /* FIXME actually read this from the hw */
> > > > - return 0;
> > > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> > > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > > + bool infoframes_enabled;
> > > > + u32 mask = 0;
> > > > + u32 val;
> > > > +
> > > > + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> > > > + infoframes_enabled =
> > _lspcon_read_avi_infoframe_enabled_mca(_dp->aux);
> > > > + else
> > > > + infoframes_enabled =
> > > > +_lspcon_read_avi_infoframe_enabled_parade(_dp->aux);
> > > > +
> > > > + if (infoframes_enabled)
> > > > + return true;
> > >
> > > This is supposed to return a bitmask of all enabled infoframes.
>
> > Actually since we're dealing with both the LSPCON specific stuff and DIP
> > stuff for
> > the DRM infoframe I think we should stop using using
> > intel_hdmi_infoframes_enabled(), and instead provide a LSPCON specific
> > replacement for it. That way we can directly return the abstract bitmask
> > instead
> > of pretending to return a bitmask of the DIP bits.
>
> Sure, will fix this and resend the next version.
>
> > >
> > > Also my question "how do we turn off infoframes once enabled?"
> > > from
> > > https://patchwork.freedesktop.org/patch/351719/?series=72928=1
> > > still remains unanswered...
>
> For the AVI infoframe we generally compute and change the respective values.
> If no change is
> requested and computed we can let the existing infoframes be transmitted.
> AFAIK there is no
> mechanism called out, to explicitly disable this on Lspcon. Have not seen any
> issues due to this,
> so hoping that it may be safe even if they are enabled.
It's not valid to transmit infoframes to DVI sinks.
>
> I am planning to take your patch from the series and float along with this
> series, adding check for DRM
> Infoframes also. Hope that is ok ?
>
> Thanks Ville for your feedback.
>
> Regards,
> Uma Shankar
>
> > > > +
> > > > + if (lspcon->hdr_supported) {
> > > > + val = intel_de_read(dev_priv,
> > > > +
Re: [Intel-gfx] [v3 6/8] drm/i915/display: Implement infoframes readback for LSPCON
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, June 11, 2020 9:31 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Mun, Gwan-
> gyeong
> Subject: Re: [v3 6/8] drm/i915/display: Implement infoframes readback for
> LSPCON
>
> On Thu, Jun 11, 2020 at 06:46:50PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 11, 2020 at 12:42:30AM +0530, Uma Shankar wrote:
> > > Implemented Infoframes enabled readback for LSPCON devices.
> > > This will help align the implementation with state readback
> > > infrastructure.
> > >
> > > Signed-off-by: Uma Shankar
> > > ---
> > > drivers/gpu/drm/i915/display/intel_lspcon.c | 63
> > > -
> > > 1 file changed, 61 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > index 9034ce6f20b9..0ebe9a700291 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > @@ -576,11 +576,70 @@ void lspcon_set_infoframes(struct intel_encoder
> *encoder,
> > > buf, ret);
> > > }
> > >
> > > +static bool _lspcon_read_avi_infoframe_enabled_mca(struct
> > > +drm_dp_aux *aux) {
> > > + int ret;
> > > + u32 val = 0;
> > > + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> > > +
> > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > + if (ret < 0) {
> > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > + return false;
> > > + }
> > > +
> > > + if (val & LSPCON_MCA_AVI_IF_KICKOFF)
> > > + return true;
> > > +
> > > + return false;
> >
> > return val & ...;
> >
> > > +}
> > > +
> > > +static bool _lspcon_read_avi_infoframe_enabled_parade(struct
> > > +drm_dp_aux *aux) {
> > > + int ret;
> > > + u32 val = 0;
> > > + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> > > +
> > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > + if (ret < 0) {
> > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > + return false;
> > > + }
> > > +
> > > + if (val & LSPCON_PARADE_AVI_IF_KICKOFF)
> > > + return true;
> > > +
> > > + return false;
> > > +}
> > > +
> > > u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> > > const struct intel_crtc_state *pipe_config) {
> > > - /* FIXME actually read this from the hw */
> > > - return 0;
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > + bool infoframes_enabled;
> > > + u32 mask = 0;
> > > + u32 val;
> > > +
> > > + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> > > + infoframes_enabled =
> _lspcon_read_avi_infoframe_enabled_mca(_dp->aux);
> > > + else
> > > + infoframes_enabled =
> > > +_lspcon_read_avi_infoframe_enabled_parade(_dp->aux);
> > > +
> > > + if (infoframes_enabled)
> > > + return true;
> >
> > This is supposed to return a bitmask of all enabled infoframes.
> Actually since we're dealing with both the LSPCON specific stuff and DIP
> stuff for
> the DRM infoframe I think we should stop using using
> intel_hdmi_infoframes_enabled(), and instead provide a LSPCON specific
> replacement for it. That way we can directly return the abstract bitmask
> instead
> of pretending to return a bitmask of the DIP bits.
Sure, will fix this and resend the next version.
> >
> > Also my question "how do we turn off infoframes once enabled?"
> > from
> > https://patchwork.freedesktop.org/patch/351719/?series=72928=1
> > still remains unanswered...
For the AVI infoframe we generally compute and change the respective values. If
no change is
requested and computed we can let the existing infoframes be transmitted. AFAIK
there is no
mechanism called out, to explicitly disable this on Lspcon. Have not seen any
issues due to this,
so hoping that it may be safe even if they are enabled.
I am planning to take your patch from the series and float along with this
series, adding check for DRM
Infoframes also. Hope that is ok ?
Thanks Ville for your feedback.
Regards,
Uma Shankar
> > > +
> > > + if (lspcon->hdr_supported) {
> > > + val = intel_de_read(dev_priv,
> > > + HSW_TVIDEO_DIP_CTL(pipe_config-
> >cpu_transcoder));
> > > + mask |= VIDEO_DIP_ENABLE_GMP_HSW;
> > > +
> > > + if (val & mask)
> > > + return val & mask;
> > > + }
> > > +
> > > + return false;
> > > }
> > >
> > > void lspcon_resume(struct intel_lspcon *lspcon)
> > > --
> > > 2.22.0
> >
> > --
> > Ville Syrjälä
> > Intel
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Exercise far preemption rollbacks
== Series Details == Series: drm/i915/selftests: Exercise far preemption rollbacks URL : https://patchwork.freedesktop.org/series/78384/ State : success == Summary == CI Bug Log - changes from CI_DRM_8629 -> Patchwork_17956 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/index.html Known issues Here are the changes found in Patchwork_17956 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@bad-flink: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [PASS][5] -> [FAIL][6] ([i915#138]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-kbl-guc/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-icl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html - fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html Possible fixes * igt@gem_ctx_exec@basic: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-tgl-y/igt@gem_ctx_e...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-tgl-y/igt@gem_ctx_e...@basic.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-icl-guc: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_pipe_crc_basic@read-crc-pipe-c: - fi-tgl-y: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17956/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [24]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Exercise far preemption rollbacks
== Series Details ==
Series: drm/i915/selftests: Exercise far preemption rollbacks
URL : https://patchwork.freedesktop.org/series/78384/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
268ee667bc05 drm/i915/selftests: Exercise far preemption rollbacks
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e36ba817fa96 ("drm/i915/gt:
Incrementally check for rewinding")'
#19:
References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding")
total: 1 errors, 0 warnings, 0 checks, 162 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Exercise far preemption rollbacks
Not too long ago, we realised we had issues with a rolling back a
context so far for a preemption request we considered the resubmit not
to be a rollback but a forward roll. This means we would issue a lite
restore instead of forcing a full restore, continuing execution of the
old requests rather than causing a preemption. Add a selftest to
exercise such a far rollback, such that if we were to skip the full
restore, we would execute invalid instructions in the ring and hang.
Note that while I was able to confirm that this causes us to do a
lite-restore preemption rollback (with commit e36ba817fa96 ("drm/i915/gt:
Incrementally check for rewinding") disabled), it did not trick the HW
into rolling past the old RING_TAIL. Myybe on other HW.
References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 150 +
1 file changed, 150 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 91543494f595..3d088116a055 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -363,6 +363,155 @@ static int live_unlite_preempt(void *arg)
return live_unlite_restore(arg, I915_USER_PRIORITY(I915_PRIORITY_MAX));
}
+static int live_unlite_ring(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ struct igt_spinner spin;
+ enum intel_engine_id id;
+ int err = 0;
+
+ /*
+* Setup a preemption event that will cause almost the entire ring
+* to be unwound, potentially fooling our intel_ring_direction()
+* into emitting a forward lite-restore instead of the rollback.
+*/
+
+ if (igt_spinner_init(, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq;
+ struct igt_live_test t;
+ int n;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(, gt->i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+ engine_heartbeat_disable(engine);
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ struct intel_context *tmp;
+
+ tmp = intel_context_create(engine);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(tmp);
+ if (err) {
+ intel_context_put(tmp);
+ goto err_ce;
+ }
+
+ memset32(tmp->ring->vaddr,
+0xdeadbeef, /* trigger a hang if executed */
+tmp->ring->vma->size / sizeof(u32));
+
+ ce[n] = tmp;
+ }
+
+ rq = igt_spinner_create_request(, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_ce;
+ }
+
+ i915_request_get(rq);
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(, rq)) {
+ intel_gt_set_wedged(gt);
+ i915_request_put(rq);
+ err = -ETIME;
+ goto err_ce;
+ }
+
+ /* Fill the ring, until we will cause a wrap */
+ n = 0;
+ while (intel_ring_direction(ce[0]->ring,
+ rq->wa_tail,
+ ce[0]->ring->tail) <= 0) {
+ struct i915_request *tmp;
+
+ tmp = intel_context_create_request(ce[0]);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ i915_request_put(rq);
+ goto err_ce;
+ }
+
+ i915_request_add(tmp);
+ intel_engine_flush_submission(engine);
+ n++;
+ }
+ intel_engine_flush_submission(engine);
+ pr_debug("%s: Filled ring with %d nop tails {size:%x, tail:%x,
emit:%x, rq.tail:%x}\n",
+engine->name, n,
+ce[0]->ring->size,
+ce[0]->ring->tail,
+ce[0]->ring->emit,
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Don't flush the tasklet if not setup
== Series Details == Series: drm/i915/gt: Don't flush the tasklet if not setup URL : https://patchwork.freedesktop.org/series/78382/ State : success == Summary == CI Bug Log - changes from CI_DRM_8629 -> Patchwork_17955 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/index.html Known issues Here are the changes found in Patchwork_17955 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1242]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html * igt@vgem_basic@dmabuf-export: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html Possible fixes * igt@gem_flink_basic@bad-open: - fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-tgl-y/igt@gem_flink_ba...@bad-open.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-tgl-y/igt@gem_flink_ba...@bad-open.html * igt@i915_selftest@live@gt_lrc: - fi-tgl-u2: [DMESG-FAIL][11] ([i915#1233]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-icl-guc: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_pipe_crc_basic@read-crc-pipe-c: - fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17955/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8629/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [24]:
[Intel-gfx] [PATCH] drm/i915/selftests: Exercise far preemption rollbacks
Not too long ago, we realised we had issues with a rolling back a
context so far for a preemption request we considered the resubmit not
to be a rollback but a forward roll. This means we would issue a lite
restore instead of forcing a full restore, continuing execution of the
old requests rather than causing a preemption. Add a selftest to
exercise such a far rollback, such that if we were to skip the full
restore, we would execute invalid instructions in the ring and hang.
Note that while I was able to confirm that this causes us to do a
lite-restore preemption rollback (with commit e36ba817fa96 ("drm/i915/gt:
Incrementally check for rewinding") disabled), it did not trick the HW
into rolling past the old RING_TAIL. Myybe on other HW.
References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 150 +
1 file changed, 150 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 91543494f595..dc11d8562d34 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -363,6 +363,155 @@ static int live_unlite_preempt(void *arg)
return live_unlite_restore(arg, I915_USER_PRIORITY(I915_PRIORITY_MAX));
}
+static int live_unlite_ring(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ struct igt_spinner spin;
+ enum intel_engine_id id;
+ int err = 0;
+
+ /*
+* Setup a preemption event that will cause almost the entire ring
+* to be unwound, potentially fooling our intel_ring_direction()
+* into emitting a forward lite-restore instead of the rollback.
+*/
+
+ if (igt_spinner_init(, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq;
+ struct igt_live_test t;
+ int n;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(, gt->i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+ engine_heartbeat_disable(engine);
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ struct intel_context *tmp;
+
+ tmp = intel_context_create(engine);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(tmp);
+ if (err) {
+ intel_context_put(tmp);
+ goto err_ce;
+ }
+
+ memset32(tmp->ring->vaddr,
+0xdeadbeef, /* trigger a hang if executed */
+tmp->ring->vma->size / sizeof(u32));
+
+ ce[n] = tmp;
+ }
+
+ rq = igt_spinner_create_request(, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_ce;
+ }
+
+ i915_request_get(rq);
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(, rq)) {
+ intel_gt_set_wedged(gt);
+ i915_request_put(rq);
+ err = -ETIME;
+ goto err_ce;
+ }
+
+ /* Fill the ring, until we will cause a wrap */
+ n = 0;
+ while (intel_ring_direction(ce[0]->ring,
+ rq->wa_tail,
+ ce[0]->ring->emit) <= 0) {
+ struct i915_request *tmp;
+
+ tmp = intel_context_create_request(ce[0]);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ i915_request_put(rq);
+ goto err_ce;
+ }
+
+ i915_request_add(tmp);
+ intel_engine_flush_submission(engine);
+ n++;
+ }
+ intel_engine_flush_submission(engine);
+ pr_debug("%s: Filled ring with %d nop tails {size:%x, tail:%x,
emit:%x, rq.tail:%x}\n",
+engine->name, n,
+ce[0]->ring->size,
+ce[0]->ring->tail,
+ce[0]->ring->emit,
+
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests
== Series Details == Series: series starting with [CI,1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests URL : https://patchwork.freedesktop.org/series/78380/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8627_full -> Patchwork_17954_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17954_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17954_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17954_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@requests: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl3/igt@i915_selftest@m...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-kbl2/igt@i915_selftest@m...@requests.html - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb5/igt@i915_selftest@m...@requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-tglb2/igt@i915_selftest@m...@requests.html - shard-apl: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-apl1/igt@i915_selftest@m...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-apl6/igt@i915_selftest@m...@requests.html - shard-iclb: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb6/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-iclb7/igt@i915_selftest@m...@requests.html Known issues Here are the changes found in Patchwork_17954_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_selftest@mock@requests: - shard-glk: [PASS][11] -> [INCOMPLETE][12] ([i915#58] / [k.org#198133]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-glk7/igt@i915_selftest@m...@requests.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-glk8/igt@i915_selftest@m...@requests.html - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#198]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl7/igt@i915_selftest@m...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-skl10/igt@i915_selftest@m...@requests.html * igt@kms_flip@wf_vblank-ts-check-interruptible@a-hdmi-a1: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#1928]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-glk8/igt@kms_flip@wf_vblank-ts-check-interrupti...@a-hdmi-a1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-glk8/igt@kms_flip@wf_vblank-ts-check-interrupti...@a-hdmi-a1.html * igt@kms_flip_event_leak: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#165] / [i915#78]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl4/igt@kms_flip_event_leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-kbl2/igt@kms_flip_event_leak.html * igt@kms_panel_fitting@atomic-fastset: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +13 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl2/igt@kms_panel_fitt...@atomic-fastset.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-skl4/igt@kms_panel_fitt...@atomic-fastset.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [24]:
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add PSR2 software tracking registers
On Mon, 2020-06-15 at 19:37 +0100, Mun, Gwan-gyeong wrote:
> On Fri, 2020-06-12 at 21:49 +, Mun, Gwan-gyeong wrote:
> > On Fri, 2020-06-12 at 14:18 -0700, Souza, Jose wrote:
> > > On Fri, 2020-06-12 at 21:57 +0100, Mun, Gwan-gyeong wrote:
> > > > On Tue, 2020-05-26 at 15:14 -0700, José Roberto de Souza wrote:
> > > > > This registers will be used to implement PSR2 software
> > > > > tracking.
> > > > >
> > > > > BSpec: 55229
> > > > > BSpec: 50424
> > > > > BSpec: 50420
> > > > > Signed-off-by: José Roberto de Souza
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_reg.h | 68
> > > > > ++-
> > > > > --
> > > > > 1 file changed, 63 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > > index e9d50fe0f375..6f547e459d30 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > @@ -4566,6 +4566,18 @@ enum {
> > > > > #define PSR2_SU_STATUS_MASK(frame) (0x3ff <<
> > > > > PSR2_SU_STATUS_SHIFT(frame))
> > > > > #define PSR2_SU_STATUS_FRAMES8
> > > > >
> > > > > +#define _PSR2_MAN_TRK_CTL_A 0x60910
> > > > > +#define _PSR2_MAN_TRK_CTL_EDP0x6f910
> > > > > +#define PSR2_MAN_TRK_CTL(tran) _MMIO_T
> > > > > RANS2(tran, _PSR2_MAN_TRK_CTL_A)
> > > > > +#define PSR2_MAN_TRK_CTL_ENABLE REG_BIT
> > > > > (31)
> > > > > +#define PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK REG_GEN
> > > > > MASK(30,
> > > > > 21)
> > > > > +#define PSR2_MAN_TRK_CTL_REGION_START_ADDR(val) REG_FIE
> > > > > LD_PREP(
> > > > > PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK, val)
> > > > > +#define PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK REG_GEN
> > > > > MASK(20, 11)
> > > > > +#define PSR2_MAN_TRK_CTL_REGION_END_ADDR(val) REG_FIE
> > > > > LD_PREP(PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK, val)
> > > > > +#define PSR2_MAN_TRK_CTL_SINGLE_FULL_FRAME REG_BIT
> > > > > (3)
> > > > > +#define PSR2_MAN_TRK_CTL_CONTINUOS_FULL_FRAME REG_BIT
> > > > > (2)
> > > > > +#define PSR2_MAN_TRK_CTL_PARTIAL_FRAME_UPDATE REG_BIT
> > > > > (1)
> > > > > +
> > > > As per Bspec, it would be better that the names of bit as below.
> > > >
> > > > PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME
> > > > PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME
> > > > PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_ENABLE
> > >
> > > No problem in naming like this but MAN_TRK and SF is kind of
> > > redundant and the name was already big.
> > > Your call.
> > >
> > > > > /* VGA port control */
> > > > > #define ADPA _MMIO(0x61100)
> > > > > #define PCH_ADPA_MMIO(0xe1100)
> > > > > @@ -7129,7 +7141,52 @@ enum {
> > > > > #define PLANE_COLOR_CTL(pipe, plane) \
> > > > > _MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe),
> > > > > _PLANE_COLOR_CTL_2(pipe))
> > > > >
> > > > > -#/* SKL new cursor registers */
> > > > > +#define _PLANE_SEL_FETCH_BASE_1_A0x70890
> > > > > +#define _PLANE_SEL_FETCH_BASE_2_A0x708B0
> > > > > +#define _PLANE_SEL_FETCH_BASE_3_A0x708D0
> > > > > +#define _PLANE_SEL_FETCH_BASE_4_A0x708F0
> > > > > +#define _PLANE_SEL_FETCH_BASE_5_A0x70920
> > > > > +#define _PLANE_SEL_FETCH_BASE_6_A0x70940
> > > > > +#define _PLANE_SEL_FETCH_BASE_7_A0x70960
> > > > > +#define _PLANE_SEL_FETCH_BASE_CUR_A 0x70880
> > > > > +#define _PLANE_SEL_FETCH_BASE_1_B0x70990
> > > > > +
> > > > And as per Bspec, the prefix _SEL_FETCH_PLANE_ is better than
> > > > _PLANE_SEL_FETCH_ .
> > > You mean just for the "internal" ones? For PLANE_SEL_FETCH_CTL,
> > > PLANE_SEL_FETCH_SIZE... would be better keep like this to match
> > > other
> > > plane register
> > > names.
> > Internals and externals. I also noticed your intention (match other
> > plane related registers), but when I checked other plane related
> > resiters, they followed bspec names. (But I am not confident on
> > register naming policy; we always have to follow documented register
> > names or not. )
> > > > > +#define _PLANE_SEL_FETCH_BASE_A(plane) _PICK(plane, \
> > > > > + _PLANE_SEL_FETCH_B
> > > > > ASE_1_A,
> > > > > \
> > > > > + _PLANE_SEL_FETCH_B
> > > > > ASE_2_A,
> > > > > \
> > > > > + _PLANE_SEL_FETCH_B
> > > > > ASE_3_A,
> > > > > \
> > > > > + _PLANE_SEL_FETCH_B
> > > > > ASE_4_A,
> > > > > \
> > > > > + _PLANE_SEL_FETCH_B
> > > > > ASE_5_A,
> > > > > \
> > > > > + _PLANE_SEL_FETCH_B
> > > > > ASE_6_A,
> > > > > \
> > > > > +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove redundant i915_request_await_object in blit clears (rev2)
== Series Details ==
Series: drm/i915: Remove redundant i915_request_await_object in blit clears
(rev2)
URL : https://patchwork.freedesktop.org/series/78374/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627_full -> Patchwork_17953_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17953_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_big_fb@y-tiled-64bpp-rotate-0:
- shard-glk: [PASS][1] -> [DMESG-FAIL][2] ([i915#118] / [i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-glk7/igt@kms_big...@y-tiled-64bpp-rotate-0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#300])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#46])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt:
- shard-tglb: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-msflip-blt.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-msflip-blt.html
* igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite:
- shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +8
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl9/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-skl1/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265])
+1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-iclb1/igt@kms_psr@psr2_cursor_render.html
* igt@kms_vblank@pipe-c-wait-busy-hang:
- shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#95]) +6 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-apl8/igt@kms_vbl...@pipe-c-wait-busy-hang.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-apl7/igt@kms_vbl...@pipe-c-wait-busy-hang.html
* igt@perf_pmu@semaphore-busy@rcs0:
- shard-kbl: [PASS][19] -> [FAIL][20] ([i915#1820])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl3/igt@perf_pmu@semaphore-b...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-kbl7/igt@perf_pmu@semaphore-b...@rcs0.html
Possible fixes
* igt@gem_exec_balancer@sliced:
- shard-tglb: [TIMEOUT][21] ([i915#1936]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb6/igt@gem_exec_balan...@sliced.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/shard-tglb2/igt@gem_exec_balan...@sliced.html
*
{igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing@edp-1-pipe-a}:
- shard-tglb: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
Re: [Intel-gfx] [PATCH] drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
On Fri, Jun 12, 2020 at 02:15:02PM -0700, Bloomfield, Jon wrote:
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Rodrigo Vivi
> > Sent: Wednesday, June 10, 2020 1:18 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Alexandre Oliva ; Nikula, Jani
> > ;
> > sta...@vger.kernel.org; Chris Wilson
> > Subject: [Intel-gfx] [PATCH] drm/i915: Include asm sources for {ivb,
> > hsw}_clear_kernel.c
> >
> > Alexandre Oliva has recently removed these files from Linux Libre
> > with concerns that the sources weren't available.
> >
> > The sources are available on IGT repository, and only open source
> > tools are used to generate the {ivb,hsw}_clear_kernel.c files.
> >
> > However, the remaining concern from Alexandre Oliva was around
> > GPL license and the source not been present when distributing
> > the code.
> >
> > So, it looks like 2 alternatives are possible, the use of
> > linux-firmware.git repository to store the blob or making sure
> > that the source is also present in our tree. Since the goal
> > is to limit the i915 firmware to only the micro-controller blobs
> > let's make sure that we do include the asm sources here in our tree.
> >
> > Btw, I tried to have some diligence here and make sure that the
> > asms that these commits are adding are truly the source for
> > the mentioned files:
> >
> > igt$ ./scripts/generate_clear_kernel.sh -g ivb \
> > -m ~/mesa/build/src/intel/tools/i965_asm
> > Output file not specified - using default file "ivb-cb_assembled"
> >
> > Generating gen7 CB Kernel assembled file "ivb_clear_kernel.c"
> > for i915 driver...
> >
> > igt$ diff ~/i915/drm-tip/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c \
> > ivb_clear_kernel.c
> >
> > < * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:29:32 AM UTC
> > > * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:00:54 AM PDT
> > 61c61
> > < };
> > > };
> > \ No newline at end of file
> >
> > igt$ ./scripts/generate_clear_kernel.sh -g hsw \
> > -m ~/mesa/build/src/intel/tools/i965_asm
> > Output file not specified - using default file "hsw-cb_assembled"
> >
> > Generating gen7.5 CB Kernel assembled file "hsw_clear_kernel.c"
> > for i915 driver...
> >
> > igt$ diff ~/i915/drm-tip/drivers/gpu/drm/i915/gt/hsw_clear_kernel.c \
> > hsw_clear_kernel.c
> > 5c5
> > < * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:30:13 AM UTC
> > > * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:01:42 AM PDT
> > 61c61
> > < };
> > > };
> > \ No newline at end of file
> >
> > Used IGT and Mesa master repositories from Fri Jun 5 2020)
> > IGT: 53e8c878a6fb ("tests/kms_chamelium: Force reprobe after replugging
> > the connector")
> > Mesa: 5d13c7477eb1 ("radv: set keep_statistic_info with
> > RADV_DEBUG=shaderstats")
> > Mesa built with: meson build -D platforms=drm,x11 -D dri-drivers=i965 \
> > -D gallium-drivers=iris -D prefix=/usr \
> > -D libdir=/usr/lib64/ -Dtools=intel \
> > -Dkulkan-drivers=intel && ninja -C build
> >
> > v2: Header clean-up and include build instructions in a readme (Chris)
> > Modified commit message to respect check-patch
> >
> > Reference: http://www.fsfla.org/pipermail/linux-libre/2020-
> > June/003374.html
> > Reference: http://www.fsfla.org/pipermail/linux-libre/2020-
> > June/003375.html
> > Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> > Cc: # v5.7+
> > Cc: Alexandre Oliva
> > Cc: Prathap Kumar Valsan
> > Cc: Akeem G Abodunrin
> > Cc: Mika Kuoppala
> > Cc: Chris Wilson
> > Cc: Jani Nikula
> > Cc: Joonas Lahtinen
> > Signed-off-by: Rodrigo Vivi
>
> Reviewed-by: Jon Bloomfield
Thanks, pushed to dinq
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Don't flush the tasklet if not setup
Chris Wilson writes:
> If the tasklet is not being used, don't try and flush it.
>
> Fixes: 594893870044 ("drm/i915/gt: Add a safety submission flush in the
> heartbeat")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 31049e0bdb57..045179c65c44 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1094,6 +1094,9 @@ void intel_engine_flush_submission(struct
> intel_engine_cs *engine)
> {
> struct tasklet_struct *t = >execlists.tasklet;
>
> + if (!t->func)
> + return;
> +
> /* Synchronise and wait for the tasklet on another CPU */
> tasklet_kill(t);
>
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Don't flush the tasklet if not setup
If the tasklet is not being used, don't try and flush it.
Fixes: 594893870044 ("drm/i915/gt: Add a safety submission flush in the
heartbeat")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 31049e0bdb57..045179c65c44 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1094,6 +1094,9 @@ void intel_engine_flush_submission(struct intel_engine_cs
*engine)
{
struct tasklet_struct *t = >execlists.tasklet;
+ if (!t->func)
+ return;
+
/* Synchronise and wait for the tasklet on another CPU */
tasklet_kill(t);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add PSR2 software tracking registers
On Fri, 2020-06-12 at 21:49 +, Mun, Gwan-gyeong wrote:
> On Fri, 2020-06-12 at 14:18 -0700, Souza, Jose wrote:
> > On Fri, 2020-06-12 at 21:57 +0100, Mun, Gwan-gyeong wrote:
> > > On Tue, 2020-05-26 at 15:14 -0700, José Roberto de Souza wrote:
> > > > This registers will be used to implement PSR2 software
> > > > tracking.
> > > >
> > > > BSpec: 55229
> > > > BSpec: 50424
> > > > BSpec: 50420
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h | 68
> > > > ++-
> > > > --
> > > > 1 file changed, 63 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index e9d50fe0f375..6f547e459d30 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -4566,6 +4566,18 @@ enum {
> > > > #define PSR2_SU_STATUS_MASK(frame) (0x3ff <<
> > > > PSR2_SU_STATUS_SHIFT(frame))
> > > > #define PSR2_SU_STATUS_FRAMES 8
> > > >
> > > > +#define _PSR2_MAN_TRK_CTL_A0x60910
> > > > +#define _PSR2_MAN_TRK_CTL_EDP 0x6f910
> > > > +#define PSR2_MAN_TRK_CTL(tran) _MMIO_T
> > > > RANS2(tran, _PSR2_MAN_TRK_CTL_A)
> > > > +#define PSR2_MAN_TRK_CTL_ENABLE REG_BIT
> > > > (31)
> > > > +#define PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK REG_GEN
> > > > MASK(30,
> > > > 21)
> > > > +#define PSR2_MAN_TRK_CTL_REGION_START_ADDR(val) REG_FIE
> > > > LD_PREP(
> > > > PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK, val)
> > > > +#define PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK REG_GEN
> > > > MASK(20, 11)
> > > > +#define PSR2_MAN_TRK_CTL_REGION_END_ADDR(val) REG_FIE
> > > > LD_PREP(PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK, val)
> > > > +#define PSR2_MAN_TRK_CTL_SINGLE_FULL_FRAMEREG_BIT
> > > > (3)
> > > > +#define PSR2_MAN_TRK_CTL_CONTINUOS_FULL_FRAME REG_BIT
> > > > (2)
> > > > +#define PSR2_MAN_TRK_CTL_PARTIAL_FRAME_UPDATE REG_BIT
> > > > (1)
> > > > +
> > > As per Bspec, it would be better that the names of bit as below.
> > >
> > > PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME
> > > PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME
> > > PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_ENABLE
> >
> > No problem in naming like this but MAN_TRK and SF is kind of
> > redundant and the name was already big.
> > Your call.
> >
> > > > /* VGA port control */
> > > > #define ADPA _MMIO(0x61100)
> > > > #define PCH_ADPA_MMIO(0xe1100)
> > > > @@ -7129,7 +7141,52 @@ enum {
> > > > #define PLANE_COLOR_CTL(pipe, plane) \
> > > > _MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe),
> > > > _PLANE_COLOR_CTL_2(pipe))
> > > >
> > > > -#/* SKL new cursor registers */
> > > > +#define _PLANE_SEL_FETCH_BASE_1_A 0x70890
> > > > +#define _PLANE_SEL_FETCH_BASE_2_A 0x708B0
> > > > +#define _PLANE_SEL_FETCH_BASE_3_A 0x708D0
> > > > +#define _PLANE_SEL_FETCH_BASE_4_A 0x708F0
> > > > +#define _PLANE_SEL_FETCH_BASE_5_A 0x70920
> > > > +#define _PLANE_SEL_FETCH_BASE_6_A 0x70940
> > > > +#define _PLANE_SEL_FETCH_BASE_7_A 0x70960
> > > > +#define _PLANE_SEL_FETCH_BASE_CUR_A0x70880
> > > > +#define _PLANE_SEL_FETCH_BASE_1_B 0x70990
> > > > +
> > > And as per Bspec, the prefix _SEL_FETCH_PLANE_ is better than
> > > _PLANE_SEL_FETCH_ .
> > You mean just for the "internal" ones? For PLANE_SEL_FETCH_CTL,
> > PLANE_SEL_FETCH_SIZE... would be better keep like this to match
> > other
> > plane register
> > names.
> Internals and externals. I also noticed your intention (match other
> plane related registers), but when I checked other plane related
> resiters, they followed bspec names. (But I am not confident on
> register naming policy; we always have to follow documented register
> names or not. )
> > > > +#define _PLANE_SEL_FETCH_BASE_A(plane) _PICK(plane, \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_1_A,
> > > > \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_2_A,
> > > > \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_3_A,
> > > > \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_4_A,
> > > > \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_5_A,
> > > > \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_6_A,
> > > > \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_7_A,
> > > > \
> > > > +_PLANE_SEL_FETCH_B
> > > > ASE_CUR_
> > > > A)
> > > > +#define _PLANE_SEL_FETCH_BASE_1(pipe) _PIPE(pipe,
> > > > _PLANE_SEL_FETCH_BASE_1_A, _PLANE_SEL_FETCH_BASE_1_A)
It seems that
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/shmem-helper: Fix obj->filp derefence
== Series Details == Series: drm/shmem-helper: Fix obj->filp derefence URL : https://patchwork.freedesktop.org/series/78378/ State : success == Summary == CI Bug Log - changes from CI_DRM_8627_full -> Patchwork_17952_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17952_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#69]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl10/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-skl10/igt@gem_...@in-flight-suspend.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#454]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb1/igt@i915_pm...@dc6-psr.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-glk9/igt@kms_big...@y-tiled-64bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#1928]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl8/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html * igt@kms_flip_tiling@flip-to-y-tiled: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl6/igt@kms_flip_til...@flip-to-y-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-kbl4/igt@kms_flip_til...@flip-to-y-tiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-render: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#402]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-render.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb5/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl9/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-skl6/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl10/igt@kms_...@bpc-switch-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-skl7/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [24]:
Re: [Intel-gfx] [PATCH v2] drm/i915: Remove redundant i915_request_await_object in blit clears
>-Original Message-
>From: Tvrtko Ursulin
>Sent: Monday, June 15, 2020 12:16 PM
>To: Ruhl, Michael J ; Intel-
>g...@lists.freedesktop.org
>Cc: Ursulin, Tvrtko ; Auld, Matthew
>; Chris Wilson
>Subject: Re: [PATCH v2] drm/i915: Remove redundant
>i915_request_await_object in blit clears
>
>
>On 15/06/2020 17:11, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: Tvrtko Ursulin
>>> Sent: Monday, June 15, 2020 11:15 AM
>>> To: Intel-gfx@lists.freedesktop.org
>>> Cc: Ursulin, Tvrtko ; Auld, Matthew
>>> ; Chris Wilson ;
>Ruhl,
>>> Michael J
>>> Subject: [PATCH v2] drm/i915: Remove redundant
>i915_request_await_object
>>> in blit clears
>>>
>>> From: Tvrtko Ursulin
>>>
>>> One i915_request_await_object is enough and we keep the one under the
>>> object lock so it is final.
>>>
>>> At the same time move async clflushing setup under the same locked
>>> section and consolidate common code into a helper function.
>>>
>>> v2:
>>> * Emit initial breadcrumbs after aways are set up. (Chris)
>>>
>>> Signed-off-by: Tvrtko Ursulin
>>> Cc: Matthew Auld
>>> Cc: Chris Wilson
>>> Cc: Michael J. Ruhl
>>> ---
>>> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 52 ---
>>> 1 file changed, 21 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> index f457d7130491..bfdb32d46877 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>>> @@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context
>>> *ce, struct i915_vma *vma)
>>> intel_engine_pm_put(ce->engine);
>>> }
>>>
>>> +static int
>>> +move_obj_to_gpu(struct drm_i915_gem_object *obj,
>>
>> I am not understanding the name of this function.
>>
>> How is the object moved to the gpu? Is clflush a move? Or is
>> it that it is moving to the gpu domain?
>>
>> What about:
>>
>> obj_flush_and_wait()
>>
>> or just:
>>
>> flush_and_wait()
>>
>> ?
>>
>> Or am I missing something?
>
>Yes, the fact I have renamed the existing move_to_gpu to move_obj_to_gpu
>while moving it up in the file and so risked falling victim to bike
>shedding now. :D
Ok.
Code path makes sense to me.
Reviewed-by: Michael J. Ruhl
M
>
>Regards,
>
>Tvrtko
>
>>
>> Mike
>>
>>> + struct i915_request *rq,
>>> + bool write)
>>> +{
>>> + if (obj->cache_dirty & ~obj->cache_coherent)
>>> + i915_gem_clflush_object(obj, 0);
>>> +
>>> + return i915_request_await_object(rq, obj, write);
>>> +}
>>> +
>>> int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
>>> struct intel_context *ce,
>>> u32 value)
>>> @@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct
>>> drm_i915_gem_object *obj,
>>> if (unlikely(err))
>>> return err;
>>>
>>> - if (obj->cache_dirty & ~obj->cache_coherent) {
>>> - i915_gem_object_lock(obj);
>>> - i915_gem_clflush_object(obj, 0);
>>> - i915_gem_object_unlock(obj);
>>> - }
>>> -
>>> batch = intel_emit_vma_fill_blt(ce, vma, value);
>>> if (IS_ERR(batch)) {
>>> err = PTR_ERR(batch);
>>> @@ -165,27 +170,22 @@ int i915_gem_object_fill_blt(struct
>>> drm_i915_gem_object *obj,
>>> if (unlikely(err))
>>> goto out_request;
>>>
>>> - err = i915_request_await_object(rq, obj, true);
>>> - if (unlikely(err))
>>> - goto out_request;
>>> -
>>> - if (ce->engine->emit_init_breadcrumb) {
>>> - err = ce->engine->emit_init_breadcrumb(rq);
>>> - if (unlikely(err))
>>> - goto out_request;
>>> - }
>>> -
>>> i915_vma_lock(vma);
>>> - err = i915_request_await_object(rq, vma->obj, true);
>>> + err = move_obj_to_gpu(vma->obj, rq, true);
>>> if (err == 0)
>>> err = i915_vma_move_to_active(vma, rq,
>>> EXEC_OBJECT_WRITE);
>>> i915_vma_unlock(vma);
>>> if (unlikely(err))
>>> goto out_request;
>>>
>>> - err = ce->engine->emit_bb_start(rq,
>>> - batch->node.start, batch->node.size,
>>> - 0);
>>> + if (ce->engine->emit_init_breadcrumb)
>>> + err = ce->engine->emit_init_breadcrumb(rq);
>>> +
>>> + if (likely(!err))
>>> + err = ce->engine->emit_bb_start(rq,
>>> + batch->node.start,
>>> + batch->node.size,
>>> + 0);
>>> out_request:
>>> if (unlikely(err))
>>> i915_request_set_error_once(rq, err);
>>> @@ -317,16 +317,6 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
>>> intel_context *ce,
>>> return ERR_PTR(err);
>>> }
>>>
>>> -static int move_to_gpu(struct i915_vma *vma, struct i915_request *rq,
>bool
>>> write)
>>> -{
>>> - struct drm_i915_gem_object *obj = vma->obj;
>>> -
>>> - if
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/mm: remove unused rb_hole_size()
== Series Details == Series: series starting with [1/3] drm/mm: remove unused rb_hole_size() URL : https://patchwork.freedesktop.org/series/78376/ State : success == Summary == CI Bug Log - changes from CI_DRM_8627_full -> Patchwork_17951_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17951_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb1/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-tglb5/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#165]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl1/igt@i915_pm_...@system-suspend-modeset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-kbl2/igt@i915_pm_...@system-suspend-modeset.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#95]) +18 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-apl3/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-apl1/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt: - shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-plflip-blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-plflip-blt.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb5/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-tglb7/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +10 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl3/igt@kms_plane_multi...@atomic-pipe-a-tiling-yf.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-skl9/igt@kms_plane_multi...@atomic-pipe-a-tiling-yf.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-iclb1/igt@kms_psr@psr2_cursor_render.html * igt@perf_pmu@semaphore-busy@rcs0: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#1820]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl3/igt@perf_pmu@semaphore-b...@rcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-kbl7/igt@perf_pmu@semaphore-b...@rcs0.html Possible fixes * igt@gem_exec_balancer@sliced: - shard-tglb: [TIMEOUT][21] ([i915#1936]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb6/igt@gem_exec_balan...@sliced.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/shard-tglb8/igt@gem_exec_balan...@sliced.html * igt@gem_exec_schedule@implicit-read-write@rcs0: - shard-snb: [INCOMPLETE][23] ([i915#82]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-snb2/igt@gem_exec_schedule@implicit-read-wr...@rcs0.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/selftests: Disable preemptive
heartbeats over preemption tests
URL : https://patchwork.freedesktop.org/series/78380/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17954
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/index.html
Known issues
Here are the changes found in Patchwork_17954 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [FAIL][2] ([i915#579])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-icl-u2: [PASS][3] -> [FAIL][4] ([i915#262])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62]) -> [SKIP][20]
([fdo#109271])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17954/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html
[24]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests
== Series Details == Series: series starting with [CI,1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests URL : https://patchwork.freedesktop.org/series/78380/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests
== Series Details == Series: series starting with [CI,1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests URL : https://patchwork.freedesktop.org/series/78380/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5227b0190b79 drm/i915/selftests: Disable preemptive heartbeats over preemption tests 031614ee83cc drm/i915/selftests: Dump engine state and trace upon hanging after reset -:28: CHECK:LINE_SPACING: Please don't use multiple blank lines #28: FILE: drivers/gpu/drm/i915/gt/selftest_hangcheck.c:509: + + total: 0 errors, 0 warnings, 1 checks, 21 lines checked 13826b79b2ed drm/i915/gt: Add a safety submission flush in the heartbeat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/mm: cleanup and improve next_hole_*_addr()
Reviewed-by: Nirmoy Das
On 6/15/20 4:54 PM, Christian König wrote:
Skipping just one branch of the tree is not the most
effective approach.
Instead use a macro to define the traversal functions and
sort out both branch sides.
This improves the performance of the unit tests by
a factor of more than 4.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c | 106 +--
1 file changed, 34 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 177a5df0fe95..a4a04d246135 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -325,6 +325,11 @@ static struct drm_mm_node *best_hole(struct drm_mm *mm,
u64 size)
return best;
}
+static bool usable_hole_addr(struct rb_node *rb, u64 size)
+{
+ return rb && rb_hole_addr_to_node(rb)->subtree_max_hole >= size;
+}
+
static struct drm_mm_node *find_hole_addr(struct drm_mm *mm, u64 addr, u64
size)
{
struct rb_node *rb = mm->holes_addr.rb_node;
@@ -333,7 +338,7 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm
*mm, u64 addr, u64 size)
while (rb) {
u64 hole_start;
- if (rb_hole_addr_to_node(rb)->subtree_max_hole < size)
+ if (!usable_hole_addr(rb, size))
break;
node = rb_hole_addr_to_node(rb);
@@ -374,82 +379,39 @@ first_hole(struct drm_mm *mm,
}
/**
- * next_hole_high_addr - returns next hole for a DRM_MM_INSERT_HIGH mode
request
- * @entry: previously selected drm_mm_node
- * @size: size of the a hole needed for the request
- *
- * This function will verify whether left subtree of @entry has hole big enough
- * to fit the requtested size. If so, it will return previous node of @entry or
- * else it will return parent node of @entry
+ * DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
+ * @name: name of function to declare
+ * @first: first rb member to traverse (either rb_left or rb_right).
+ * @last: last rb member to traverse (either rb_right or rb_left).
*
- * It will also skip the complete left subtree if subtree_max_hole of that
- * subtree is same as the subtree_max_hole of the @entry.
- *
- * Returns:
- * previous node of @entry if left subtree of @entry can serve the request or
- * else return parent of @entry
+ * This macro declares a function to return the next hole of the addr rb tree.
+ * While traversing the tree we take the searched size into account and only
+ * visit branches with potential big enough holes.
*/
-static struct drm_mm_node *
-next_hole_high_addr(struct drm_mm_node *entry, u64 size)
-{
- struct rb_node *rb_node, *left_rb_node, *parent_rb_node;
- struct drm_mm_node *left_node;
-
- if (!entry)
- return NULL;
- rb_node = >rb_hole_addr;
- if (rb_node->rb_left) {
- left_rb_node = rb_node->rb_left;
- parent_rb_node = rb_parent(rb_node);
- left_node = rb_entry(left_rb_node,
-struct drm_mm_node, rb_hole_addr);
- if (left_node->subtree_max_hole < size &&
- parent_rb_node && parent_rb_node->rb_left != rb_node)
- return rb_hole_addr_to_node(parent_rb_node);
- }
-
- return rb_hole_addr_to_node(rb_prev(rb_node));
+#define DECLARE_NEXT_HOLE_ADDR(name, first, last) \
+static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size) \
+{ \
+ struct rb_node *parent, *node = >rb_hole_addr;\
+ \
+ if (!entry || RB_EMPTY_NODE(node)) \
+ return NULL;\
+ \
+ if (usable_hole_addr(node->first, size)) { \
+ node = node->first; \
+ while (usable_hole_addr(node->last, size)) \
+ node = node->last; \
+ return rb_hole_addr_to_node(node); \
+ } \
+ \
+ while ((parent = rb_parent(node)) && node == parent->first) \
+ node = parent; \
+ \
+ return rb_hole_addr_to_node(parent);\
}
-/**
- * next_hole_low_addr - returns next hole for a DRM_MM_INSERT_LOW mode request
- * @entry: previously selected drm_mm_node
- * @size: size of the a hole needed for the request
- *
- * This function will verify whether right subtree of
Re: [Intel-gfx] [PATCH 1/3] drm/mm: remove unused rb_hole_size()
Reviewed-by: Nirmoy Das
On 6/15/20 4:54 PM, Christian König wrote:
Just some code cleanup.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 82d2888eb7fe..425fcd3590e8 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -305,11 +305,6 @@ static inline struct drm_mm_node
*rb_hole_addr_to_node(struct rb_node *rb)
return rb_entry_safe(rb, struct drm_mm_node, rb_hole_addr);
}
-static inline u64 rb_hole_size(struct rb_node *rb)
-{
- return rb_entry(rb, struct drm_mm_node, rb_hole_size)->hole_size;
-}
-
static struct drm_mm_node *best_hole(struct drm_mm *mm, u64 size)
{
struct rb_node *rb = mm->holes_size.rb_root.rb_node;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/mm: optimize find_hole() as well
Acked-by: Nirmoy Das
On 6/15/20 4:54 PM, Christian König wrote:
Abort early if there isn't enough space to allocate from a subtree.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c| 11 +++
drivers/gpu/drm/selftests/test-drm_mm.c | 11 ---
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 425fcd3590e8..177a5df0fe95 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -325,7 +325,7 @@ static struct drm_mm_node *best_hole(struct drm_mm *mm, u64
size)
return best;
}
-static struct drm_mm_node *find_hole(struct drm_mm *mm, u64 addr)
+static struct drm_mm_node *find_hole_addr(struct drm_mm *mm, u64 addr, u64
size)
{
struct rb_node *rb = mm->holes_addr.rb_node;
struct drm_mm_node *node = NULL;
@@ -333,6 +333,9 @@ static struct drm_mm_node *find_hole(struct drm_mm *mm, u64
addr)
while (rb) {
u64 hole_start;
+ if (rb_hole_addr_to_node(rb)->subtree_max_hole < size)
+ break;
+
node = rb_hole_addr_to_node(rb);
hole_start = __drm_mm_hole_node_start(node);
@@ -358,10 +361,10 @@ first_hole(struct drm_mm *mm,
return best_hole(mm, size);
case DRM_MM_INSERT_LOW:
- return find_hole(mm, start);
+ return find_hole_addr(mm, start, size);
case DRM_MM_INSERT_HIGH:
- return find_hole(mm, end);
+ return find_hole_addr(mm, end, size);
case DRM_MM_INSERT_EVICT:
return list_first_entry_or_null(>hole_stack,
@@ -497,7 +500,7 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct
drm_mm_node *node)
return -ENOSPC;
/* Find the relevant hole to add our node to */
- hole = find_hole(mm, node->start);
+ hole = find_hole_addr(mm, node->start, 0);
if (!hole)
return -ENOSPC;
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c
index ca5f35def905..b879aedfc00d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1981,16 +1981,6 @@ static int __igt_once(unsigned int mode)
}
memset(, 0, sizeof(node));
- err = drm_mm_insert_node_generic(, ,
-2, 0, 0,
-mode | DRM_MM_INSERT_ONCE);
- if (!err) {
- pr_err("Unexpectedly inserted the node into the wrong hole:
node.start=%llx\n",
- node.start);
- err = -EINVAL;
- goto err_node;
- }
-
err = drm_mm_insert_node_generic(, , 2, 0, 0, mode);
if (err) {
pr_err("Could not insert the node into the available hole!\n");
@@ -1998,7 +1988,6 @@ static int __igt_once(unsigned int mode)
goto err_hi;
}
-err_node:
drm_mm_remove_node();
err_hi:
drm_mm_remove_node(_hi);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915/selftests: Dump engine state and trace upon hanging after reset
If the engine dies after a reset, and so we fail to submit a request
but need to be interrupted by the CI runner, dump the engine state.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 2af66f8ffbd2..1ea4935e0eeb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -499,6 +499,21 @@ static int igt_reset_nop_engine(void *arg)
rq = intel_context_create_request(ce);
if (IS_ERR(rq)) {
+ struct drm_printer p =
+
drm_info_printer(gt->i915->drm.dev);
+ intel_engine_dump(engine, ,
+ "%s(%s): failed to
submit request\n",
+ __func__,
+ engine->name);
+
+
+ GEM_TRACE("%s(%s): failed to submit
request\n",
+ __func__,
+ engine->name);
+ GEM_TRACE_DUMP();
+
+ intel_gt_set_wedged(gt);
+
err = PTR_ERR(rq);
break;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915/gt: Add a safety submission flush in the heartbeat
Just in case everything fails (like for example "missed interrupt
syndrome" on Sandybridge), always flush the submission tasklet from the
heartbeat. This papers over such issues, but will still appear as a
second long glitch, and prevents us from detecting it unless we happen
to be performing a timed test.
v2: We rely on flush_submission() synchronizing with the tasklet on
another CPU.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 23 +--
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3 +++
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d613cf31970c..31049e0bdb57 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1094,19 +1094,18 @@ void intel_engine_flush_submission(struct
intel_engine_cs *engine)
{
struct tasklet_struct *t = >execlists.tasklet;
- if (__tasklet_is_scheduled(t)) {
- local_bh_disable();
- if (tasklet_trylock(t)) {
- /* Must wait for any GPU reset in progress. */
- if (__tasklet_is_enabled(t))
- t->func(t->data);
- tasklet_unlock(t);
- }
- local_bh_enable();
+ /* Synchronise and wait for the tasklet on another CPU */
+ tasklet_kill(t);
+
+ /* Having cancelled the tasklet, ensure that is run */
+ local_bh_disable();
+ if (tasklet_trylock(t)) {
+ /* Must wait for any GPU reset in progress. */
+ if (__tasklet_is_enabled(t))
+ t->func(t->data);
+ tasklet_unlock(t);
}
-
- /* Otherwise flush the tasklet if it was running on another cpu */
- tasklet_unlock_wait(t);
+ local_bh_enable();
}
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index f67ad937eefb..cd20fb549b38 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -65,6 +65,9 @@ static void heartbeat(struct work_struct *wrk)
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
+ /* Just in case everything has gone horribly wrong, give it a kick */
+ intel_engine_flush_submission(engine);
+
rq = engine->heartbeat.systole;
if (rq && i915_request_completed(rq)) {
i915_request_put(rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915/selftests: Disable preemptive heartbeats over preemption tests
Since the heartbeat may cause a preemption event, disable it over the
preemption suppression tests.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index f651bdf7f191..91543494f595 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -2282,7 +2282,7 @@ static int live_suppress_self_preempt(void *arg)
if (igt_flush_test(gt->i915))
goto err_wedged;
- intel_engine_pm_get(engine);
+ engine_heartbeat_disable(engine);
engine->execlists.preempt_hang.count = 0;
rq_a = spinner_create_request(,
@@ -2290,14 +2290,14 @@ static int live_suppress_self_preempt(void *arg)
MI_NOOP);
if (IS_ERR(rq_a)) {
err = PTR_ERR(rq_a);
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_client_b;
}
i915_request_add(rq_a);
if (!igt_wait_for_spinner(, rq_a)) {
pr_err("First client failed to start\n");
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_wedged;
}
@@ -2309,7 +2309,7 @@ static int live_suppress_self_preempt(void *arg)
MI_NOOP);
if (IS_ERR(rq_b)) {
err = PTR_ERR(rq_b);
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_client_b;
}
i915_request_add(rq_b);
@@ -2320,7 +2320,7 @@ static int live_suppress_self_preempt(void *arg)
if (!igt_wait_for_spinner(, rq_b)) {
pr_err("Second client failed to start\n");
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_wedged;
}
@@ -2334,12 +2334,12 @@ static int live_suppress_self_preempt(void *arg)
engine->name,
engine->execlists.preempt_hang.count,
depth);
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
err = -EINVAL;
goto err_client_b;
}
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
if (igt_flush_test(gt->i915))
goto err_wedged;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove redundant i915_request_await_object in blit clears
== Series Details == Series: drm/i915: Remove redundant i915_request_await_object in blit clears URL : https://patchwork.freedesktop.org/series/78374/ State : success == Summary == CI Bug Log - changes from CI_DRM_8627_full -> Patchwork_17949_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17949_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@processes: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl2/igt@gem_ctx_persiste...@processes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-skl3/igt@gem_ctx_persiste...@processes.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][3] -> [DMESG-FAIL][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-glk5/igt@kms_big...@linear-64bpp-rotate-0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-ytiled: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-apl2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-ytiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-apl3/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-ytiled.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +9 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-kbl4/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt: - shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl9/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-skl6/igt@kms_frontbuffer_track...@psr-rgb101010-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-iclb3/igt@kms_psr@psr2_cursor_render.html * igt@kms_sequence@queue-idle: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#93] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl3/igt@kms_seque...@queue-idle.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-kbl4/igt@kms_seque...@queue-idle.html * igt@kms_vblank@pipe-c-wait-busy-hang: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#95]) +16 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-apl8/igt@kms_vbl...@pipe-c-wait-busy-hang.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/shard-apl1/igt@kms_vbl...@pipe-c-wait-busy-hang.html * igt@perf_pmu@semaphore-busy@rcs0: - shard-kbl: [PASS][23] -> [FAIL][24] ([i915#1820]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl3/igt@perf_pmu@semaphore-b...@rcs0.html
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Implement PSR2 selective fetch
On Fri, Jun 12, 2020 at 08:33:31PM +, Souza, Jose wrote:
> On Fri, 2020-06-12 at 19:30 +0300, Ville Syrjälä wrote:
> > On Tue, May 26, 2020 at 03:14:46PM -0700, José Roberto de Souza wrote:
> > > All GEN12 platforms supports PSR2 selective fetch but not all GEN12
> > > platforms supports PSR2 hardware tracking(aka RKL).
> > >
> > > This feature consists in software program registers with the damaged
> > > area of each plane this way hardware will only fetch from memory those
> > > areas and sent the PSR2 selective update blocks to panel, saving even
> > > more power but to it actually happen userspace needs to send the
> > > damaged areas otherwise it will still fetch the whole plane as
> > > fallback.
> > > As today Gnome3 do not send damaged areas and the only compositor that
> > > I'm aware that sets the damaged areas is Weston.
> > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/17
> > >
> > > So here implementing page flip part, it is still completely missing
> > > frontbuffer modifications, that is why the enable_psr2_sel_fetch
> > > parameter was added.
> > >
> > > The plan is to switch all GEN12 platforms to selective fetch when
> > > ready, it will also depend in add some tests sending damaged areas.
> > > I have a hacked version of kms_psr2_su with 3 planes that I can
> > > cleanup and send in a few days(99% of PSR2 selective fetch changes was
> > > done during my free time while bored during quarantine rainy days).
> > >
> > > BSpec: 55229
> > > Cc: Ville Syrjälä
> > > Cc: Imre Deak
> > > Cc: Gwan-gyeong Mun
> > > Cc: Rodrigo Vivi
> > > Cc: Dhinakaran Pandiyan
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 5 +
> > > .../drm/i915/display/intel_display_debugfs.c | 3 +
> > > .../drm/i915/display/intel_display_types.h| 10 +
> > > drivers/gpu/drm/i915/display/intel_psr.c | 329 +-
> > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +
> > > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > > drivers/gpu/drm/i915/i915_params.c| 5 +
> > > drivers/gpu/drm/i915/i915_params.h| 1 +
> > > 9 files changed, 352 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index b69878334040..984809208c29 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -11729,6 +11729,8 @@ static void i9xx_update_cursor(struct intel_plane
> > > *plane,
> > > if (INTEL_GEN(dev_priv) >= 9)
> > > skl_write_cursor_wm(plane, crtc_state);
> > >
> > > + intel_psr2_program_plane_sel_fetch(plane, crtc_state, plane_state);
> > > +
> > > if (plane->cursor.base != base ||
> > > plane->cursor.size != fbc_ctl ||
> > > plane->cursor.cntl != cntl) {
> > > @@ -15115,6 +15117,8 @@ static void commit_pipe_config(struct
> > > intel_atomic_state *state,
> > >
> > > if (new_crtc_state->update_pipe)
> > > intel_pipe_fastset(old_crtc_state, new_crtc_state);
> > > +
> > > + intel_psr2_program_trans_man_trk_ctl(new_crtc_state);
> > > }
> > >
> > > if (dev_priv->display.atomic_update_watermarks)
> > > @@ -15156,6 +15160,7 @@ static void intel_update_crtc(struct
> > > intel_atomic_state *state,
> > > intel_color_load_luts(new_crtc_state);
> > >
> > > intel_pre_plane_update(state, crtc);
> > > + intel_psr2_sel_fetch_update(state, crtc);
> > >
> > > if (new_crtc_state->update_pipe)
> > > intel_encoders_update_pipe(state, crtc);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index 70525623bcdf..0f600974462b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -417,6 +417,9 @@ static int i915_edp_psr_status(struct seq_file *m,
> > > void *data)
> > > su_blocks = su_blocks >> PSR2_SU_STATUS_SHIFT(frame);
> > > seq_printf(m, "%d\t%d\n", frame, su_blocks);
> > > }
> > > +
> > > + seq_printf(m, "PSR2 selective fetch: %s\n",
> > > +enableddisabled(psr->psr2_sel_fetch_enabled));
> > > }
> > >
> > > unlock:
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 30b2767578dc..b77a512e5362 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -586,6 +586,13 @@ struct intel_plane_state {
> > > u32 planar_slave;
> > >
> > > struct drm_intel_sprite_colorkey ckey;
> > > +
> > > +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove redundant i915_request_await_object in blit clears (rev2)
== Series Details ==
Series: drm/i915: Remove redundant i915_request_await_object in blit clears
(rev2)
URL : https://patchwork.freedesktop.org/series/78374/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17953
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/index.html
Known issues
Here are the changes found in Patchwork_17953 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][5] -> [DMESG-WARN][6] ([i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] /
[i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@vgem_ba...@setversion.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][11] ([i915#1888]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +2
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17953/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:
Re: [Intel-gfx] [PATCH] drm/i915/dp: DP PHY compliance for JSL
On Fri, Jun 12, 2020 at 12:38:59PM -0700, Manasi Navare wrote:
> On Fri, Jun 12, 2020 at 10:21:31PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 12, 2020 at 12:12:25PM -0700, Manasi Navare wrote:
> > > On Fri, Jun 12, 2020 at 10:01:19PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Jun 12, 2020 at 11:44:13AM -0700, Manasi Navare wrote:
> > > > > On Fri, Jun 12, 2020 at 09:36:37PM +0300, Ville Syrjälä wrote:
> > > > > > On Fri, Jun 12, 2020 at 11:25:42AM -0700, Manasi Navare wrote:
> > > > > > > On Fri, Jun 05, 2020 at 12:03:19AM +0300, Ville Syrjälä wrote:
> > > > > > > > On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled
> > > > > > > > wrote:
> > > > > > > > > On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> > > > > > > > > > On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas
> > > > > > > > > > wrote:
> > > > > > > > > > > Signed-off-by: Khaled Almahallawy
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Vidya Srinivas
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 40
> > > > > > > > > > > ++---
> > > > > > > > > > > 1 file changed, 32 insertions(+), 8 deletions(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > > > > > index 7223367171d1..44663e8ac9a1 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > > > > > @@ -5470,22 +5470,32 @@
> > > > > > > > > > > intel_dp_autotest_phy_ddi_disable(struct
> > > > > > > > > > > intel_dp *intel_dp)
> > > > > > > > > > > struct drm_i915_private *dev_priv = to_i915(dev);
> > > > > > > > > > > struct intel_crtc *crtc = to_intel_crtc(intel_dig_port-
> > > > > > > > > > > >base.base.crtc);
> > > > > > > > > > > enum pipe pipe = crtc->pipe;
> > > > > > > > > > > - u32 trans_ddi_func_ctl_value, trans_conf_value,
> > > > > > > > > > > dp_tp_ctl_value;
> > > > > > > > > > > + u32 trans_ddi_func_ctl_value, trans_conf_value,
> > > > > > > > > > > dp_tp_ctl_value, trans_ddi_port_mask;
> > > > > > > > > > > + enum port port = intel_dig_port->base.port;
> > > > > > > > > > > + i915_reg_t dp_tp_reg;
> > > > > > > > > > > +
> > > > > > > > > > > + if (IS_ELKHARTLAKE(dev_priv)) {
> > > > > > > > > > > + dp_tp_reg = DP_TP_CTL(port);
> > > > > > > > > > > + trans_ddi_port_mask = TRANS_DDI_PORT_MASK;
> > > > > > > > > > > + } else if (IS_TIGERLAKE(dev_priv)) {
> > > > > > > > > > > + dp_tp_reg = TGL_DP_TP_CTL(pipe);
> > > > > > > > > > > + trans_ddi_port_mask = TGL_TRANS_DDI_PORT_MASK;
> > > > > > > > > > > + }
> > > > > > > > > > >
> > > > > > > > > > > trans_ddi_func_ctl_value = intel_de_read(dev_priv,
> > > > > > > > > > >
> > > > > > > > > > > TRANS_DDI_FUNC_CTL(pip
> > > > > > > > > > > e));
> > > > > > > > > > > trans_conf_value = intel_de_read(dev_priv,
> > > > > > > > > > > PIPECONF(pipe));
> > > > > > > > > > > - dp_tp_ctl_value = intel_de_read(dev_priv,
> > > > > > > > > > > TGL_DP_TP_CTL(pipe));
> > > > > > > > > > >
> > > > > > > > > > > + dp_tp_ctl_value = intel_de_read(dev_priv, dp_tp_reg);
> > > > > > > > > > > trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
> > > > > > > > > > > - TGL_TRANS_DDI_PORT_MASK);
> > > > > > > > > > > + trans_ddi_port_mask);
> > > > > > > > > > > trans_conf_value &= ~PIPECONF_ENABLE;
> > > > > > > > > > > dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
> > > > > > > > > > >
> > > > > > > > > > > intel_de_write(dev_priv, PIPECONF(pipe),
> > > > > > > > > > > trans_conf_value);
> > > > > > > > > > > intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
> > > > > > > > > > > trans_ddi_func_ctl_value);
> > > > > > > > > > > - intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> > > > > > > > > > > dp_tp_ctl_value);
> > > > > > > > > > > + intel_de_write(dev_priv, dp_tp_reg, dp_tp_ctl_value);
> > > > > > > > > >
> > > > > > > > > > All this ad-hoc modeset code really should not exist. It's
> > > > > > > > > > going to
> > > > > > > > > > have different bugs than the norma modeset paths, so
> > > > > > > > > > compliance
> > > > > > > > > > testing
> > > > > > > > > > this special code proves absolutely nothing about the
> > > > > > > > > > normal modeset
> > > > > > > > > > code. IMO someone needs to take up the task of rewrtiting
> > > > > > > > > > all this to
> > > > > > > > > > just perform normal modesets.
> > > > > > > > >
> > > > > > > > > Agree. I've just found that we get kernel NULL pointer
> > > > > > > > > dereference and
> > > > > > > > > panic when we try to access to_intel_crtc(intel_dig_port-
> > > > > > > > > >base.base.crtc).
> > > > > > > >
> > > > > > > > Yeah, that's a legacy pointer which should no longer be
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add a safety submission flush in the heartbeat
Chris Wilson writes:
> Just in case everything fails (like for example "missed interrupt
> syndrome" on Sandybridge), always flush the submission tasklet from the
> heartbeat. This papers over such issues, but will still appear as a
> second long glitch, and prevents us from detecting it unless we happen
> to be performing a timed test.
>
> v2: We rely on flush_submission() synchronizing with the tasklet on
> another CPU.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 23 +--
> .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3 +++
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index d613cf31970c..31049e0bdb57 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1094,19 +1094,18 @@ void intel_engine_flush_submission(struct
> intel_engine_cs *engine)
> {
> struct tasklet_struct *t = >execlists.tasklet;
>
> - if (__tasklet_is_scheduled(t)) {
> - local_bh_disable();
> - if (tasklet_trylock(t)) {
> - /* Must wait for any GPU reset in progress. */
> - if (__tasklet_is_enabled(t))
> - t->func(t->data);
> - tasklet_unlock(t);
> - }
> - local_bh_enable();
> + /* Synchronise and wait for the tasklet on another CPU */
> + tasklet_kill(t);
> +
> + /* Having cancelled the tasklet, ensure that is run */
> + local_bh_disable();
> + if (tasklet_trylock(t)) {
> + /* Must wait for any GPU reset in progress. */
> + if (__tasklet_is_enabled(t))
On heartbeat context this could be an assertion I think.
But it is difficult to enforce hw sanity and still please the
user.
They will curse on glitch, even tho thye are saved!
Reviewed-by: Mika Kuoppala
-Mika
> + t->func(t->data);
> + tasklet_unlock(t);
> }
> -
> - /* Otherwise flush the tasklet if it was running on another cpu */
> - tasklet_unlock_wait(t);
> + local_bh_enable();
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index f67ad937eefb..cd20fb549b38 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -65,6 +65,9 @@ static void heartbeat(struct work_struct *wrk)
> struct intel_context *ce = engine->kernel_context;
> struct i915_request *rq;
>
> + /* Just in case everything has gone horribly wrong, give it a kick */
> + intel_engine_flush_submission(engine);
> +
> rq = engine->heartbeat.systole;
> if (rq && i915_request_completed(rq)) {
> i915_request_put(rq);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Remove redundant i915_request_await_object in blit clears
Quoting Tvrtko Ursulin (2020-06-15 16:14:49) > From: Tvrtko Ursulin > > One i915_request_await_object is enough and we keep the one under the > object lock so it is final. > > At the same time move async clflushing setup under the same locked > section and consolidate common code into a helper function. > > v2: > * Emit initial breadcrumbs after aways are set up. (Chris) s/aways/awaits/ > Signed-off-by: Tvrtko Ursulin > Cc: Matthew Auld > Cc: Chris Wilson > Cc: Michael J. Ruhl > --- > .../gpu/drm/i915/gem/i915_gem_object_blt.c| 52 --- > 1 file changed, 21 insertions(+), 31 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c > b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c > index f457d7130491..bfdb32d46877 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c > @@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context *ce, > struct i915_vma *vma) > intel_engine_pm_put(ce->engine); > } > > +static int > +move_obj_to_gpu(struct drm_i915_gem_object *obj, > + struct i915_request *rq, > + bool write) * shrug, I prefer to think in terms of vma, but even vma are unlikely to be the final form here. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Remove redundant i915_request_await_object in blit clears
On 15/06/2020 17:11, Ruhl, Michael J wrote:
-Original Message-
From: Tvrtko Ursulin
Sent: Monday, June 15, 2020 11:15 AM
To: Intel-gfx@lists.freedesktop.org
Cc: Ursulin, Tvrtko ; Auld, Matthew
; Chris Wilson ; Ruhl,
Michael J
Subject: [PATCH v2] drm/i915: Remove redundant i915_request_await_object
in blit clears
From: Tvrtko Ursulin
One i915_request_await_object is enough and we keep the one under the
object lock so it is final.
At the same time move async clflushing setup under the same locked
section and consolidate common code into a helper function.
v2:
* Emit initial breadcrumbs after aways are set up. (Chris)
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Chris Wilson
Cc: Michael J. Ruhl
---
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 52 ---
1 file changed, 21 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index f457d7130491..bfdb32d46877 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context
*ce, struct i915_vma *vma)
intel_engine_pm_put(ce->engine);
}
+static int
+move_obj_to_gpu(struct drm_i915_gem_object *obj,
I am not understanding the name of this function.
How is the object moved to the gpu? Is clflush a move? Or is
it that it is moving to the gpu domain?
What about:
obj_flush_and_wait()
or just:
flush_and_wait()
?
Or am I missing something?
Yes, the fact I have renamed the existing move_to_gpu to move_obj_to_gpu
while moving it up in the file and so risked falling victim to bike
shedding now. :D
Regards,
Tvrtko
Mike
+ struct i915_request *rq,
+ bool write)
+{
+ if (obj->cache_dirty & ~obj->cache_coherent)
+ i915_gem_clflush_object(obj, 0);
+
+ return i915_request_await_object(rq, obj, write);
+}
+
int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
struct intel_context *ce,
u32 value)
@@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct
drm_i915_gem_object *obj,
if (unlikely(err))
return err;
- if (obj->cache_dirty & ~obj->cache_coherent) {
- i915_gem_object_lock(obj);
- i915_gem_clflush_object(obj, 0);
- i915_gem_object_unlock(obj);
- }
-
batch = intel_emit_vma_fill_blt(ce, vma, value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
@@ -165,27 +170,22 @@ int i915_gem_object_fill_blt(struct
drm_i915_gem_object *obj,
if (unlikely(err))
goto out_request;
- err = i915_request_await_object(rq, obj, true);
- if (unlikely(err))
- goto out_request;
-
- if (ce->engine->emit_init_breadcrumb) {
- err = ce->engine->emit_init_breadcrumb(rq);
- if (unlikely(err))
- goto out_request;
- }
-
i915_vma_lock(vma);
- err = i915_request_await_object(rq, vma->obj, true);
+ err = move_obj_to_gpu(vma->obj, rq, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq,
EXEC_OBJECT_WRITE);
i915_vma_unlock(vma);
if (unlikely(err))
goto out_request;
- err = ce->engine->emit_bb_start(rq,
- batch->node.start, batch->node.size,
- 0);
+ if (ce->engine->emit_init_breadcrumb)
+ err = ce->engine->emit_init_breadcrumb(rq);
+
+ if (likely(!err))
+ err = ce->engine->emit_bb_start(rq,
+ batch->node.start,
+ batch->node.size,
+ 0);
out_request:
if (unlikely(err))
i915_request_set_error_once(rq, err);
@@ -317,16 +317,6 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
intel_context *ce,
return ERR_PTR(err);
}
-static int move_to_gpu(struct i915_vma *vma, struct i915_request *rq, bool
write)
-{
- struct drm_i915_gem_object *obj = vma->obj;
-
- if (obj->cache_dirty & ~obj->cache_coherent)
- i915_gem_clflush_object(obj, 0);
-
- return i915_request_await_object(rq, obj, write);
-}
-
int i915_gem_object_copy_blt(struct drm_i915_gem_object *src,
struct drm_i915_gem_object *dst,
struct intel_context *ce)
@@ -375,7 +365,7 @@ int i915_gem_object_copy_blt(struct
drm_i915_gem_object *src,
goto out_request;
for (i = 0; i < ARRAY_SIZE(vma); i++) {
- err = move_to_gpu(vma[i], rq, i);
+ err = move_obj_to_gpu(vma[i]->obj, rq, i);
if (unlikely(err))
goto out_unlock;
Re: [Intel-gfx] [PATCH v2] drm/i915: Remove redundant i915_request_await_object in blit clears
>-Original Message-
>From: Tvrtko Ursulin
>Sent: Monday, June 15, 2020 11:15 AM
>To: Intel-gfx@lists.freedesktop.org
>Cc: Ursulin, Tvrtko ; Auld, Matthew
>; Chris Wilson ; Ruhl,
>Michael J
>Subject: [PATCH v2] drm/i915: Remove redundant i915_request_await_object
>in blit clears
>
>From: Tvrtko Ursulin
>
>One i915_request_await_object is enough and we keep the one under the
>object lock so it is final.
>
>At the same time move async clflushing setup under the same locked
>section and consolidate common code into a helper function.
>
>v2:
> * Emit initial breadcrumbs after aways are set up. (Chris)
>
>Signed-off-by: Tvrtko Ursulin
>Cc: Matthew Auld
>Cc: Chris Wilson
>Cc: Michael J. Ruhl
>---
> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 52 ---
> 1 file changed, 21 insertions(+), 31 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>index f457d7130491..bfdb32d46877 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
>@@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context
>*ce, struct i915_vma *vma)
> intel_engine_pm_put(ce->engine);
> }
>
>+static int
>+move_obj_to_gpu(struct drm_i915_gem_object *obj,
I am not understanding the name of this function.
How is the object moved to the gpu? Is clflush a move? Or is
it that it is moving to the gpu domain?
What about:
obj_flush_and_wait()
or just:
flush_and_wait()
?
Or am I missing something?
Mike
>+ struct i915_request *rq,
>+ bool write)
>+{
>+ if (obj->cache_dirty & ~obj->cache_coherent)
>+ i915_gem_clflush_object(obj, 0);
>+
>+ return i915_request_await_object(rq, obj, write);
>+}
>+
> int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
>struct intel_context *ce,
>u32 value)
>@@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct
>drm_i915_gem_object *obj,
> if (unlikely(err))
> return err;
>
>- if (obj->cache_dirty & ~obj->cache_coherent) {
>- i915_gem_object_lock(obj);
>- i915_gem_clflush_object(obj, 0);
>- i915_gem_object_unlock(obj);
>- }
>-
> batch = intel_emit_vma_fill_blt(ce, vma, value);
> if (IS_ERR(batch)) {
> err = PTR_ERR(batch);
>@@ -165,27 +170,22 @@ int i915_gem_object_fill_blt(struct
>drm_i915_gem_object *obj,
> if (unlikely(err))
> goto out_request;
>
>- err = i915_request_await_object(rq, obj, true);
>- if (unlikely(err))
>- goto out_request;
>-
>- if (ce->engine->emit_init_breadcrumb) {
>- err = ce->engine->emit_init_breadcrumb(rq);
>- if (unlikely(err))
>- goto out_request;
>- }
>-
> i915_vma_lock(vma);
>- err = i915_request_await_object(rq, vma->obj, true);
>+ err = move_obj_to_gpu(vma->obj, rq, true);
> if (err == 0)
> err = i915_vma_move_to_active(vma, rq,
>EXEC_OBJECT_WRITE);
> i915_vma_unlock(vma);
> if (unlikely(err))
> goto out_request;
>
>- err = ce->engine->emit_bb_start(rq,
>- batch->node.start, batch->node.size,
>- 0);
>+ if (ce->engine->emit_init_breadcrumb)
>+ err = ce->engine->emit_init_breadcrumb(rq);
>+
>+ if (likely(!err))
>+ err = ce->engine->emit_bb_start(rq,
>+ batch->node.start,
>+ batch->node.size,
>+ 0);
> out_request:
> if (unlikely(err))
> i915_request_set_error_once(rq, err);
>@@ -317,16 +317,6 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
>intel_context *ce,
> return ERR_PTR(err);
> }
>
>-static int move_to_gpu(struct i915_vma *vma, struct i915_request *rq, bool
>write)
>-{
>- struct drm_i915_gem_object *obj = vma->obj;
>-
>- if (obj->cache_dirty & ~obj->cache_coherent)
>- i915_gem_clflush_object(obj, 0);
>-
>- return i915_request_await_object(rq, obj, write);
>-}
>-
> int i915_gem_object_copy_blt(struct drm_i915_gem_object *src,
>struct drm_i915_gem_object *dst,
>struct intel_context *ce)
>@@ -375,7 +365,7 @@ int i915_gem_object_copy_blt(struct
>drm_i915_gem_object *src,
> goto out_request;
>
> for (i = 0; i < ARRAY_SIZE(vma); i++) {
>- err = move_to_gpu(vma[i], rq, i);
>+ err = move_obj_to_gpu(vma[i]->obj, rq, i);
> if (unlikely(err))
> goto out_unlock;
> }
>--
>2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/shmem-helper: Fix obj->filp derefence
== Series Details ==
Series: drm/shmem-helper: Fix obj->filp derefence
URL : https://patchwork.freedesktop.org/series/78378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17952
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/index.html
Known issues
Here are the changes found in Patchwork_17952 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][5] -> [DMESG-WARN][6] ([i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@vgem_ba...@setversion.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +2
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62]) -> [SKIP][20]
([fdo#109271])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +3 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17952/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: remove unnecessary conversion to bool
== Series Details ==
Series: drm/i915: remove unnecessary conversion to bool
URL : https://patchwork.freedesktop.org/series/78372/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627_full -> Patchwork_17947_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17947_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_reloc@basic-spin-others@vcs0}:
- shard-snb: [WARN][1] ([i915#2036]) -> [WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-snb5/igt@gem_exec_reloc@basic-spin-oth...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-snb4/igt@gem_exec_reloc@basic-spin-oth...@vcs0.html
Known issues
Here are the changes found in Patchwork_17947_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +8 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@i915_module_load@reload:
- shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb1/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-tglb5/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#151] / [i915#69])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl2/igt@i915_pm_...@system-suspend-modeset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-skl3/igt@i915_pm_...@system-suspend-modeset.html
* igt@kms_big_fb@y-tiled-64bpp-rotate-0:
- shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-glk7/igt@kms_big...@y-tiled-64bpp-rotate-0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-256x256-sliding:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#62])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x256-sliding.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x256-sliding.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#69])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl4/igt@kms_fbcon_...@psr-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-skl8/igt@kms_fbcon_...@psr-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#79])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
* igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-skl: [PASS][17] -> [FAIL][18] ([i915#46])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-skl7/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#95]) +21
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-apl1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-apl2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt:
- shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html
*
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Dump engine state and trace upon hanging after reset
Chris Wilson writes:
> If the engine dies after a reset, and so we fail to submit a request
> but need to be interrupted by the CI runner, dump the engine state.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> index 2af66f8ffbd2..1ea4935e0eeb 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> @@ -499,6 +499,21 @@ static int igt_reset_nop_engine(void *arg)
>
> rq = intel_context_create_request(ce);
> if (IS_ERR(rq)) {
> + struct drm_printer p =
> +
> drm_info_printer(gt->i915->drm.dev);
> + intel_engine_dump(engine, ,
> + "%s(%s): failed to
> submit request\n",
> + __func__,
> + engine->name);
> +
> +
> + GEM_TRACE("%s(%s): failed to submit
> request\n",
> + __func__,
> + engine->name);
> + GEM_TRACE_DUMP();
> +
> + intel_gt_set_wedged(gt);
> +
> err = PTR_ERR(rq);
> break;
> }
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/shmem-helper: Fix obj->filp derefence
== Series Details ==
Series: drm/shmem-helper: Fix obj->filp derefence
URL : https://patchwork.freedesktop.org/series/78378/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ce71e5b57288 drm/shmem-helper: Fix obj->filp derefence
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 7d2cd72a9aa3
("drm/shmem-helpers: Simplify dma-buf importing")'
#11:
commit 7d2cd72a9aa3df3604cafd169a2d4a525afb68ca
-:56: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 26 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/mm: remove unused rb_hole_size()
== Series Details ==
Series: series starting with [1/3] drm/mm: remove unused rb_hole_size()
URL : https://patchwork.freedesktop.org/series/78376/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17951
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/index.html
Known issues
Here are the changes found in Patchwork_17951 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-apl-guc/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][3] -> [DMESG-WARN][4] ([i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@active:
- fi-skl-lmem:[PASS][5] -> [DMESG-FAIL][6] ([i915#666])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-skl-lmem/igt@i915_selftest@l...@active.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-skl-lmem/igt@i915_selftest@l...@active.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] /
[i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@prime_vgem@basic-fence-flip:
- fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26] +3
similar issues
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17951/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2:
Re: [Intel-gfx] [PATCH 01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests
Chris Wilson writes:
> Since the heartbeat may cause a preemption event, disable it over the
> preemption suppression tests.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index f651bdf7f191..91543494f595 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -2282,7 +2282,7 @@ static int live_suppress_self_preempt(void *arg)
> if (igt_flush_test(gt->i915))
> goto err_wedged;
>
> - intel_engine_pm_get(engine);
> + engine_heartbeat_disable(engine);
> engine->execlists.preempt_hang.count = 0;
>
> rq_a = spinner_create_request(,
> @@ -2290,14 +2290,14 @@ static int live_suppress_self_preempt(void *arg)
> MI_NOOP);
> if (IS_ERR(rq_a)) {
> err = PTR_ERR(rq_a);
> - intel_engine_pm_put(engine);
> + engine_heartbeat_enable(engine);
> goto err_client_b;
> }
>
> i915_request_add(rq_a);
> if (!igt_wait_for_spinner(, rq_a)) {
> pr_err("First client failed to start\n");
> - intel_engine_pm_put(engine);
> + engine_heartbeat_enable(engine);
> goto err_wedged;
> }
>
> @@ -2309,7 +2309,7 @@ static int live_suppress_self_preempt(void *arg)
> MI_NOOP);
> if (IS_ERR(rq_b)) {
> err = PTR_ERR(rq_b);
> - intel_engine_pm_put(engine);
> + engine_heartbeat_enable(engine);
> goto err_client_b;
> }
> i915_request_add(rq_b);
> @@ -2320,7 +2320,7 @@ static int live_suppress_self_preempt(void *arg)
>
> if (!igt_wait_for_spinner(, rq_b)) {
> pr_err("Second client failed to start\n");
> - intel_engine_pm_put(engine);
> + engine_heartbeat_enable(engine);
> goto err_wedged;
> }
>
> @@ -2334,12 +2334,12 @@ static int live_suppress_self_preempt(void *arg)
> engine->name,
> engine->execlists.preempt_hang.count,
> depth);
> - intel_engine_pm_put(engine);
> + engine_heartbeat_enable(engine);
> err = -EINVAL;
> goto err_client_b;
> }
>
> - intel_engine_pm_put(engine);
> + engine_heartbeat_enable(engine);
> if (igt_flush_test(gt->i915))
> goto err_wedged;
> }
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev3)
== Series Details ==
Series: series starting with [01/10] drm/i915/selftests: Disable preemptive
heartbeats over preemption tests (rev3)
URL : https://patchwork.freedesktop.org/series/78371/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17950
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17950 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17950, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17950:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-tgl-u2: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_17950 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +3
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][19] ([i915#402]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17950/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][21] ([i915#62]) -> [SKIP][22]
([fdo#109271])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[22]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/mm: remove unused rb_hole_size()
== Series Details ==
Series: series starting with [1/3] drm/mm: remove unused rb_hole_size()
URL : https://patchwork.freedesktop.org/series/78376/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4790c8cb3116 drm/mm: remove unused rb_hole_size()
-:28: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author '"Christian König" '
total: 0 errors, 1 warnings, 0 checks, 11 lines checked
53df83ceed85 drm/mm: optimize find_hole() as well
-:86: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author '"Christian König" '
total: 0 errors, 1 warnings, 0 checks, 60 lines checked
ef8803bbb4c3 drm/mm: cleanup and improve next_hole_*_addr()
-:92: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as
'(name)' to avoid precedence issues
#92: FILE: drivers/gpu/drm/drm_mm.c:392:
+#define DECLARE_NEXT_HOLE_ADDR(name, first, last) \
+static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size) \
+{ \
+ struct rb_node *parent, *node = >rb_hole_addr; \
+ \
+ if (!entry || RB_EMPTY_NODE(node)) \
+ return NULL;\
+ \
+ if (usable_hole_addr(node->first, size)) { \
+ node = node->first; \
+ while (usable_hole_addr(node->last, size)) \
+ node = node->last; \
+ return rb_hole_addr_to_node(node); \
+ } \
+ \
+ while ((parent = rb_parent(node)) && node == parent->first) \
+ node = parent; \
+ \
+ return rb_hole_addr_to_node(parent);\
}
-:92: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'first' - possible
side-effects?
#92: FILE: drivers/gpu/drm/drm_mm.c:392:
+#define DECLARE_NEXT_HOLE_ADDR(name, first, last) \
+static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size) \
+{ \
+ struct rb_node *parent, *node = >rb_hole_addr; \
+ \
+ if (!entry || RB_EMPTY_NODE(node)) \
+ return NULL;\
+ \
+ if (usable_hole_addr(node->first, size)) { \
+ node = node->first; \
+ while (usable_hole_addr(node->last, size)) \
+ node = node->last; \
+ return rb_hole_addr_to_node(node); \
+ } \
+ \
+ while ((parent = rb_parent(node)) && node == parent->first) \
+ node = parent; \
+ \
+ return rb_hole_addr_to_node(parent);\
}
-:92: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'first' may be better as
'(first)' to avoid precedence issues
#92: FILE: drivers/gpu/drm/drm_mm.c:392:
+#define DECLARE_NEXT_HOLE_ADDR(name, first, last) \
+static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size) \
+{ \
+ struct rb_node *parent, *node = >rb_hole_addr; \
+ \
+ if (!entry || RB_EMPTY_NODE(node)) \
+ return NULL;\
+ \
+ if (usable_hole_addr(node->first, size)) { \
+ node = node->first; \
+ while (usable_hole_addr(node->last, size)) \
+ node = node->last; \
+ return rb_hole_addr_to_node(node); \
+ } \
+
[Intel-gfx] [PATCH v2] drm/i915: Remove redundant i915_request_await_object in blit clears
From: Tvrtko Ursulin
One i915_request_await_object is enough and we keep the one under the
object lock so it is final.
At the same time move async clflushing setup under the same locked
section and consolidate common code into a helper function.
v2:
* Emit initial breadcrumbs after aways are set up. (Chris)
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Chris Wilson
Cc: Michael J. Ruhl
---
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 52 ---
1 file changed, 21 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index f457d7130491..bfdb32d46877 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context *ce,
struct i915_vma *vma)
intel_engine_pm_put(ce->engine);
}
+static int
+move_obj_to_gpu(struct drm_i915_gem_object *obj,
+ struct i915_request *rq,
+ bool write)
+{
+ if (obj->cache_dirty & ~obj->cache_coherent)
+ i915_gem_clflush_object(obj, 0);
+
+ return i915_request_await_object(rq, obj, write);
+}
+
int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
struct intel_context *ce,
u32 value)
@@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
if (unlikely(err))
return err;
- if (obj->cache_dirty & ~obj->cache_coherent) {
- i915_gem_object_lock(obj);
- i915_gem_clflush_object(obj, 0);
- i915_gem_object_unlock(obj);
- }
-
batch = intel_emit_vma_fill_blt(ce, vma, value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
@@ -165,27 +170,22 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
if (unlikely(err))
goto out_request;
- err = i915_request_await_object(rq, obj, true);
- if (unlikely(err))
- goto out_request;
-
- if (ce->engine->emit_init_breadcrumb) {
- err = ce->engine->emit_init_breadcrumb(rq);
- if (unlikely(err))
- goto out_request;
- }
-
i915_vma_lock(vma);
- err = i915_request_await_object(rq, vma->obj, true);
+ err = move_obj_to_gpu(vma->obj, rq, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
i915_vma_unlock(vma);
if (unlikely(err))
goto out_request;
- err = ce->engine->emit_bb_start(rq,
- batch->node.start, batch->node.size,
- 0);
+ if (ce->engine->emit_init_breadcrumb)
+ err = ce->engine->emit_init_breadcrumb(rq);
+
+ if (likely(!err))
+ err = ce->engine->emit_bb_start(rq,
+ batch->node.start,
+ batch->node.size,
+ 0);
out_request:
if (unlikely(err))
i915_request_set_error_once(rq, err);
@@ -317,16 +317,6 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
intel_context *ce,
return ERR_PTR(err);
}
-static int move_to_gpu(struct i915_vma *vma, struct i915_request *rq, bool
write)
-{
- struct drm_i915_gem_object *obj = vma->obj;
-
- if (obj->cache_dirty & ~obj->cache_coherent)
- i915_gem_clflush_object(obj, 0);
-
- return i915_request_await_object(rq, obj, write);
-}
-
int i915_gem_object_copy_blt(struct drm_i915_gem_object *src,
struct drm_i915_gem_object *dst,
struct intel_context *ce)
@@ -375,7 +365,7 @@ int i915_gem_object_copy_blt(struct drm_i915_gem_object
*src,
goto out_request;
for (i = 0; i < ARRAY_SIZE(vma); i++) {
- err = move_to_gpu(vma[i], rq, i);
+ err = move_obj_to_gpu(vma[i]->obj, rq, i);
if (unlikely(err))
goto out_unlock;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/shmem-helper: Fix obj->filp derefence
I broke that in my refactoring:
commit 7d2cd72a9aa3df3604cafd169a2d4a525afb68ca
Author: Daniel Vetter
Date: Fri May 29 16:05:42 2020 +0200
drm/shmem-helpers: Simplify dma-buf importing
Reported-by: Thomas Zimmermann
Fixes: 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing")
Cc: Boris Brezillon
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 0a7e3b664bc2..3e7ee407a17c 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -70,15 +70,17 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size,
bool private)
mutex_init(>vmap_lock);
INIT_LIST_HEAD(>madv_list);
- /*
-* Our buffers are kept pinned, so allocating them
-* from the MOVABLE zone is a really bad idea, and
-* conflicts with CMA. See comments above new_inode()
-* why this is required _and_ expected if you're
-* going to pin these pages.
-*/
- mapping_set_gfp_mask(obj->filp->f_mapping, GFP_HIGHUSER |
-__GFP_RETRY_MAYFAIL | __GFP_NOWARN);
+ if (!private) {
+ /*
+* Our buffers are kept pinned, so allocating them
+* from the MOVABLE zone is a really bad idea, and
+* conflicts with CMA. See comments above new_inode()
+* why this is required _and_ expected if you're
+* going to pin these pages.
+*/
+ mapping_set_gfp_mask(obj->filp->f_mapping, GFP_HIGHUSER |
+__GFP_RETRY_MAYFAIL | __GFP_NOWARN);
+ }
return shmem;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/mm: remove unused rb_hole_size()
Just some code cleanup.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 82d2888eb7fe..425fcd3590e8 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -305,11 +305,6 @@ static inline struct drm_mm_node
*rb_hole_addr_to_node(struct rb_node *rb)
return rb_entry_safe(rb, struct drm_mm_node, rb_hole_addr);
}
-static inline u64 rb_hole_size(struct rb_node *rb)
-{
- return rb_entry(rb, struct drm_mm_node, rb_hole_size)->hole_size;
-}
-
static struct drm_mm_node *best_hole(struct drm_mm *mm, u64 size)
{
struct rb_node *rb = mm->holes_size.rb_root.rb_node;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/mm: cleanup and improve next_hole_*_addr()
Skipping just one branch of the tree is not the most
effective approach.
Instead use a macro to define the traversal functions and
sort out both branch sides.
This improves the performance of the unit tests by
a factor of more than 4.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c | 106 +--
1 file changed, 34 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 177a5df0fe95..a4a04d246135 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -325,6 +325,11 @@ static struct drm_mm_node *best_hole(struct drm_mm *mm,
u64 size)
return best;
}
+static bool usable_hole_addr(struct rb_node *rb, u64 size)
+{
+ return rb && rb_hole_addr_to_node(rb)->subtree_max_hole >= size;
+}
+
static struct drm_mm_node *find_hole_addr(struct drm_mm *mm, u64 addr, u64
size)
{
struct rb_node *rb = mm->holes_addr.rb_node;
@@ -333,7 +338,7 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm
*mm, u64 addr, u64 size)
while (rb) {
u64 hole_start;
- if (rb_hole_addr_to_node(rb)->subtree_max_hole < size)
+ if (!usable_hole_addr(rb, size))
break;
node = rb_hole_addr_to_node(rb);
@@ -374,82 +379,39 @@ first_hole(struct drm_mm *mm,
}
/**
- * next_hole_high_addr - returns next hole for a DRM_MM_INSERT_HIGH mode
request
- * @entry: previously selected drm_mm_node
- * @size: size of the a hole needed for the request
- *
- * This function will verify whether left subtree of @entry has hole big enough
- * to fit the requtested size. If so, it will return previous node of @entry or
- * else it will return parent node of @entry
+ * DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
+ * @name: name of function to declare
+ * @first: first rb member to traverse (either rb_left or rb_right).
+ * @last: last rb member to traverse (either rb_right or rb_left).
*
- * It will also skip the complete left subtree if subtree_max_hole of that
- * subtree is same as the subtree_max_hole of the @entry.
- *
- * Returns:
- * previous node of @entry if left subtree of @entry can serve the request or
- * else return parent of @entry
+ * This macro declares a function to return the next hole of the addr rb tree.
+ * While traversing the tree we take the searched size into account and only
+ * visit branches with potential big enough holes.
*/
-static struct drm_mm_node *
-next_hole_high_addr(struct drm_mm_node *entry, u64 size)
-{
- struct rb_node *rb_node, *left_rb_node, *parent_rb_node;
- struct drm_mm_node *left_node;
-
- if (!entry)
- return NULL;
- rb_node = >rb_hole_addr;
- if (rb_node->rb_left) {
- left_rb_node = rb_node->rb_left;
- parent_rb_node = rb_parent(rb_node);
- left_node = rb_entry(left_rb_node,
-struct drm_mm_node, rb_hole_addr);
- if (left_node->subtree_max_hole < size &&
- parent_rb_node && parent_rb_node->rb_left != rb_node)
- return rb_hole_addr_to_node(parent_rb_node);
- }
-
- return rb_hole_addr_to_node(rb_prev(rb_node));
+#define DECLARE_NEXT_HOLE_ADDR(name, first, last) \
+static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size) \
+{ \
+ struct rb_node *parent, *node = >rb_hole_addr; \
+ \
+ if (!entry || RB_EMPTY_NODE(node)) \
+ return NULL;\
+ \
+ if (usable_hole_addr(node->first, size)) { \
+ node = node->first; \
+ while (usable_hole_addr(node->last, size)) \
+ node = node->last; \
+ return rb_hole_addr_to_node(node); \
+ } \
+ \
+ while ((parent = rb_parent(node)) && node == parent->first) \
+ node = parent; \
+ \
+ return rb_hole_addr_to_node(parent);\
}
-/**
- * next_hole_low_addr - returns next hole for a DRM_MM_INSERT_LOW mode request
- * @entry: previously selected drm_mm_node
- * @size: size of the a hole needed for the request
- *
- * This function will verify whether right subtree of @entry has hole big
enough
- * to fit the
[Intel-gfx] [PATCH 2/3] drm/mm: optimize find_hole() as well
Abort early if there isn't enough space to allocate from a subtree.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c| 11 +++
drivers/gpu/drm/selftests/test-drm_mm.c | 11 ---
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 425fcd3590e8..177a5df0fe95 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -325,7 +325,7 @@ static struct drm_mm_node *best_hole(struct drm_mm *mm, u64
size)
return best;
}
-static struct drm_mm_node *find_hole(struct drm_mm *mm, u64 addr)
+static struct drm_mm_node *find_hole_addr(struct drm_mm *mm, u64 addr, u64
size)
{
struct rb_node *rb = mm->holes_addr.rb_node;
struct drm_mm_node *node = NULL;
@@ -333,6 +333,9 @@ static struct drm_mm_node *find_hole(struct drm_mm *mm, u64
addr)
while (rb) {
u64 hole_start;
+ if (rb_hole_addr_to_node(rb)->subtree_max_hole < size)
+ break;
+
node = rb_hole_addr_to_node(rb);
hole_start = __drm_mm_hole_node_start(node);
@@ -358,10 +361,10 @@ first_hole(struct drm_mm *mm,
return best_hole(mm, size);
case DRM_MM_INSERT_LOW:
- return find_hole(mm, start);
+ return find_hole_addr(mm, start, size);
case DRM_MM_INSERT_HIGH:
- return find_hole(mm, end);
+ return find_hole_addr(mm, end, size);
case DRM_MM_INSERT_EVICT:
return list_first_entry_or_null(>hole_stack,
@@ -497,7 +500,7 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct
drm_mm_node *node)
return -ENOSPC;
/* Find the relevant hole to add our node to */
- hole = find_hole(mm, node->start);
+ hole = find_hole_addr(mm, node->start, 0);
if (!hole)
return -ENOSPC;
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index ca5f35def905..b879aedfc00d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1981,16 +1981,6 @@ static int __igt_once(unsigned int mode)
}
memset(, 0, sizeof(node));
- err = drm_mm_insert_node_generic(, ,
-2, 0, 0,
-mode | DRM_MM_INSERT_ONCE);
- if (!err) {
- pr_err("Unexpectedly inserted the node into the wrong hole:
node.start=%llx\n",
- node.start);
- err = -EINVAL;
- goto err_node;
- }
-
err = drm_mm_insert_node_generic(, , 2, 0, 0, mode);
if (err) {
pr_err("Could not insert the node into the available hole!\n");
@@ -1998,7 +1988,6 @@ static int __igt_once(unsigned int mode)
goto err_hi;
}
-err_node:
drm_mm_remove_node();
err_hi:
drm_mm_remove_node(_hi);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant i915_request_await_object in blit clears
Quoting Tvrtko Ursulin (2020-06-15 15:54:56)
>
> On 15/06/2020 15:30, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-06-15 15:09:28)
> >> From: Tvrtko Ursulin
> >>
> >> One i915_request_await_object is enough and we keep the one under the
> >> object lock so it is final.
> >>
> >> At the same time move async clflushing setup under the same locked
> >> section and consolidate common code into a helper function.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> Cc: Matthew Auld
> >> Cc: Chris Wilson
> >> Cc: Michael J. Ruhl
> >> ---
> >> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 35 +++
> >> 1 file changed, 13 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> >> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> >> index f457d7130491..7d8b396e265a 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> >> @@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context *ce,
> >> struct i915_vma *vma)
> >> intel_engine_pm_put(ce->engine);
> >> }
> >>
> >> +static int
> >> +move_obj_to_gpu(struct drm_i915_gem_object *obj,
> >> + struct i915_request *rq,
> >> + bool write)
> >> +{
> >> + if (obj->cache_dirty & ~obj->cache_coherent)
> >> + i915_gem_clflush_object(obj, 0);
> >> +
> >> + return i915_request_await_object(rq, obj, write);
> >> +}
> >> +
> >> int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
> >> struct intel_context *ce,
> >> u32 value)
> >> @@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct
> >> drm_i915_gem_object *obj,
> >> if (unlikely(err))
> >> return err;
> >>
> >> - if (obj->cache_dirty & ~obj->cache_coherent) {
> >> - i915_gem_object_lock(obj);
> >> - i915_gem_clflush_object(obj, 0);
> >> - i915_gem_object_unlock(obj);
> >> - }
> >> -
> >> batch = intel_emit_vma_fill_blt(ce, vma, value);
> >> if (IS_ERR(batch)) {
> >> err = PTR_ERR(batch);
> >> @@ -165,10 +170,6 @@ int i915_gem_object_fill_blt(struct
> >> drm_i915_gem_object *obj,
> >> if (unlikely(err))
> >> goto out_request;
> >>
> >> - err = i915_request_await_object(rq, obj, true);
> >> - if (unlikely(err))
> >> - goto out_request;
> >> -
> >> if (ce->engine->emit_init_breadcrumb) {
> >> err = ce->engine->emit_init_breadcrumb(rq);
> >> if (unlikely(err))
> >> @@ -176,7 +177,7 @@ int i915_gem_object_fill_blt(struct
> >> drm_i915_gem_object *obj,
> >> }
> >>
> >> i915_vma_lock(vma);
> >> - err = i915_request_await_object(rq, vma->obj, true);
> >> + err = move_obj_to_gpu(vma->obj, rq, true);
> >> if (err == 0)
> >> err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
> >> i915_vma_unlock(vma);
> >
> > Ah, but here it's also the wrong side of init_breadcrumb.
>
> Why it is important to mark the object as active on the failure path? We
> skip the payload, no?
It's important that all the async waits are before the breadcrumb. Up
until recently we would emit the semaphore after the init, and so believe
the payload was running and all waits were completed even though it was
still waiting on another request to complete. If this blt request was
subsequently relied upon to indicate the other fence completions we
would then start other requests early. [It's less important now as we
look at a flag saying that the init_breadcrumb has been emitted and
avoid adding more semaphores.]
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev3)
== Series Details == Series: series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev3) URL : https://patchwork.freedesktop.org/series/78371/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2269:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2270:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2273:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev3)
== Series Details == Series: series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev3) URL : https://patchwork.freedesktop.org/series/78371/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5fa39ee36f3b drm/i915/selftests: Disable preemptive heartbeats over preemption tests 00b8905ebbd9 drm/i915/selftests: Dump engine state and trace upon hanging after reset -:27: CHECK:LINE_SPACING: Please don't use multiple blank lines #27: FILE: drivers/gpu/drm/i915/gt/selftest_hangcheck.c:509: + + total: 0 errors, 0 warnings, 1 checks, 21 lines checked 4dc0044cb492 drm/i915/gt: Add a safety submission flush in the heartbeat 6f4c470b5862 drm/i915/execlists: Replace direct submit with direct call to tasklet a2f814c038a3 drm/i915/execlists: Defer schedule_out until after the next dequeue -:117: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV) #117: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2441: + *execlists->inactive++ = *port; ^ total: 0 errors, 0 warnings, 1 checks, 179 lines checked cd5b50c90e8b drm/i915/gt: ce->inflight updates are now serialised db8e1905bf15 drm/i915/gt: Drop atomic for engine->fw_active tracking fd7fb36f7457 drm/i915/gt: Use virtual_engine during execlists_dequeue 0d9311cd5488 drm/i915/gt: Decouple inflight virtual engines 11a16dbbd0c4 drm/i915/gt: Resubmit the virtual engine on schedule-out ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant i915_request_await_object in blit clears
On 15/06/2020 15:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-06-15 15:09:28)
From: Tvrtko Ursulin
One i915_request_await_object is enough and we keep the one under the
object lock so it is final.
At the same time move async clflushing setup under the same locked
section and consolidate common code into a helper function.
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Chris Wilson
Cc: Michael J. Ruhl
---
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 35 +++
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index f457d7130491..7d8b396e265a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context *ce,
struct i915_vma *vma)
intel_engine_pm_put(ce->engine);
}
+static int
+move_obj_to_gpu(struct drm_i915_gem_object *obj,
+ struct i915_request *rq,
+ bool write)
+{
+ if (obj->cache_dirty & ~obj->cache_coherent)
+ i915_gem_clflush_object(obj, 0);
+
+ return i915_request_await_object(rq, obj, write);
+}
+
int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
struct intel_context *ce,
u32 value)
@@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
if (unlikely(err))
return err;
- if (obj->cache_dirty & ~obj->cache_coherent) {
- i915_gem_object_lock(obj);
- i915_gem_clflush_object(obj, 0);
- i915_gem_object_unlock(obj);
- }
-
batch = intel_emit_vma_fill_blt(ce, vma, value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
@@ -165,10 +170,6 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
if (unlikely(err))
goto out_request;
- err = i915_request_await_object(rq, obj, true);
- if (unlikely(err))
- goto out_request;
-
if (ce->engine->emit_init_breadcrumb) {
err = ce->engine->emit_init_breadcrumb(rq);
if (unlikely(err))
@@ -176,7 +177,7 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
}
i915_vma_lock(vma);
- err = i915_request_await_object(rq, vma->obj, true);
+ err = move_obj_to_gpu(vma->obj, rq, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
i915_vma_unlock(vma);
Ah, but here it's also the wrong side of init_breadcrumb.
Why it is important to mark the object as active on the failure path? We
skip the payload, no?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove redundant i915_request_await_object in blit clears
== Series Details ==
Series: drm/i915: Remove redundant i915_request_await_object in blit clears
URL : https://patchwork.freedesktop.org/series/78374/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17949
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/index.html
Known issues
Here are the changes found in Patchwork_17949 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-byt-n2820: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-byt-n2820/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-byt-n2820/igt@debugfs_test@read_all_entries.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][3] -> [DMESG-WARN][4] ([i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][11] ([i915#1888]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +2
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][23] ([i915#402]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17949/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
*
[Intel-gfx] [PATCH] drm/i915/selftests: Dump engine state and trace upon hanging after reset
If the engine dies after a reset, and so we fail to submit a request
but need to be interrupted by the CI runner, dump the engine state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 2af66f8ffbd2..1ea4935e0eeb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -499,6 +499,21 @@ static int igt_reset_nop_engine(void *arg)
rq = intel_context_create_request(ce);
if (IS_ERR(rq)) {
+ struct drm_printer p =
+
drm_info_printer(gt->i915->drm.dev);
+ intel_engine_dump(engine, ,
+ "%s(%s): failed to
submit request\n",
+ __func__,
+ engine->name);
+
+
+ GEM_TRACE("%s(%s): failed to submit
request\n",
+ __func__,
+ engine->name);
+ GEM_TRACE_DUMP();
+
+ intel_gt_set_wedged(gt);
+
err = PTR_ERR(rq);
break;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant i915_request_await_object in blit clears
Quoting Tvrtko Ursulin (2020-06-15 15:09:28)
> From: Tvrtko Ursulin
>
> One i915_request_await_object is enough and we keep the one under the
> object lock so it is final.
>
> At the same time move async clflushing setup under the same locked
> section and consolidate common code into a helper function.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matthew Auld
> Cc: Chris Wilson
> Cc: Michael J. Ruhl
> ---
> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 35 +++
> 1 file changed, 13 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> index f457d7130491..7d8b396e265a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> @@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context *ce,
> struct i915_vma *vma)
> intel_engine_pm_put(ce->engine);
> }
>
> +static int
> +move_obj_to_gpu(struct drm_i915_gem_object *obj,
> + struct i915_request *rq,
> + bool write)
> +{
> + if (obj->cache_dirty & ~obj->cache_coherent)
> + i915_gem_clflush_object(obj, 0);
> +
> + return i915_request_await_object(rq, obj, write);
> +}
> +
> int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
> struct intel_context *ce,
> u32 value)
> @@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
> *obj,
> if (unlikely(err))
> return err;
>
> - if (obj->cache_dirty & ~obj->cache_coherent) {
> - i915_gem_object_lock(obj);
> - i915_gem_clflush_object(obj, 0);
> - i915_gem_object_unlock(obj);
> - }
> -
> batch = intel_emit_vma_fill_blt(ce, vma, value);
> if (IS_ERR(batch)) {
> err = PTR_ERR(batch);
> @@ -165,10 +170,6 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
> *obj,
> if (unlikely(err))
> goto out_request;
>
> - err = i915_request_await_object(rq, obj, true);
> - if (unlikely(err))
> - goto out_request;
> -
> if (ce->engine->emit_init_breadcrumb) {
> err = ce->engine->emit_init_breadcrumb(rq);
> if (unlikely(err))
> @@ -176,7 +177,7 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
> *obj,
> }
>
> i915_vma_lock(vma);
> - err = i915_request_await_object(rq, vma->obj, true);
> + err = move_obj_to_gpu(vma->obj, rq, true);
> if (err == 0)
> err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
> i915_vma_unlock(vma);
Ah, but here it's also the wrong side of init_breadcrumb.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev2)
== Series Details ==
Series: series starting with [01/10] drm/i915/selftests: Disable preemptive
heartbeats over preemption tests (rev2)
URL : https://patchwork.freedesktop.org/series/78371/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17948
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17948 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17948, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17948:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-tgl-u2: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_17948 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#1242])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][7] -> [DMESG-WARN][8] ([i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@vgem_basic@dmabuf-mmap:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@vgem_ba...@dmabuf-mmap.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-tgl-y/igt@vgem_ba...@dmabuf-mmap.html
Possible fixes
* igt@gem_ctx_create@basic:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_ctx_cre...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-tgl-y/igt@gem_ctx_cre...@basic.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +2
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +3
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17948/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:
[Intel-gfx] [PATCH] drm/i915: Remove redundant i915_request_await_object in blit clears
From: Tvrtko Ursulin
One i915_request_await_object is enough and we keep the one under the
object lock so it is final.
At the same time move async clflushing setup under the same locked
section and consolidate common code into a helper function.
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Chris Wilson
Cc: Michael J. Ruhl
---
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 35 +++
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index f457d7130491..7d8b396e265a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -126,6 +126,17 @@ void intel_emit_vma_release(struct intel_context *ce,
struct i915_vma *vma)
intel_engine_pm_put(ce->engine);
}
+static int
+move_obj_to_gpu(struct drm_i915_gem_object *obj,
+ struct i915_request *rq,
+ bool write)
+{
+ if (obj->cache_dirty & ~obj->cache_coherent)
+ i915_gem_clflush_object(obj, 0);
+
+ return i915_request_await_object(rq, obj, write);
+}
+
int i915_gem_object_fill_blt(struct drm_i915_gem_object *obj,
struct intel_context *ce,
u32 value)
@@ -143,12 +154,6 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
if (unlikely(err))
return err;
- if (obj->cache_dirty & ~obj->cache_coherent) {
- i915_gem_object_lock(obj);
- i915_gem_clflush_object(obj, 0);
- i915_gem_object_unlock(obj);
- }
-
batch = intel_emit_vma_fill_blt(ce, vma, value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
@@ -165,10 +170,6 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
if (unlikely(err))
goto out_request;
- err = i915_request_await_object(rq, obj, true);
- if (unlikely(err))
- goto out_request;
-
if (ce->engine->emit_init_breadcrumb) {
err = ce->engine->emit_init_breadcrumb(rq);
if (unlikely(err))
@@ -176,7 +177,7 @@ int i915_gem_object_fill_blt(struct drm_i915_gem_object
*obj,
}
i915_vma_lock(vma);
- err = i915_request_await_object(rq, vma->obj, true);
+ err = move_obj_to_gpu(vma->obj, rq, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
i915_vma_unlock(vma);
@@ -317,16 +318,6 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
intel_context *ce,
return ERR_PTR(err);
}
-static int move_to_gpu(struct i915_vma *vma, struct i915_request *rq, bool
write)
-{
- struct drm_i915_gem_object *obj = vma->obj;
-
- if (obj->cache_dirty & ~obj->cache_coherent)
- i915_gem_clflush_object(obj, 0);
-
- return i915_request_await_object(rq, obj, write);
-}
-
int i915_gem_object_copy_blt(struct drm_i915_gem_object *src,
struct drm_i915_gem_object *dst,
struct intel_context *ce)
@@ -375,7 +366,7 @@ int i915_gem_object_copy_blt(struct drm_i915_gem_object
*src,
goto out_request;
for (i = 0; i < ARRAY_SIZE(vma); i++) {
- err = move_to_gpu(vma[i], rq, i);
+ err = move_obj_to_gpu(vma[i]->obj, rq, i);
if (unlikely(err))
goto out_unlock;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev2)
== Series Details == Series: series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev2) URL : https://patchwork.freedesktop.org/series/78371/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2269:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2270:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2273:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev2)
== Series Details == Series: series starting with [01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests (rev2) URL : https://patchwork.freedesktop.org/series/78371/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4a185d115cdb drm/i915/selftests: Disable preemptive heartbeats over preemption tests 7188eaf51b40 drm/i915/selftests: Dump engine state and trace upon hanging after reset -:29: CHECK:LINE_SPACING: Please don't use multiple blank lines #29: FILE: drivers/gpu/drm/i915/gt/selftest_hangcheck.c:511: + + total: 0 errors, 0 warnings, 1 checks, 24 lines checked 8ca01417d140 drm/i915/gt: Add a safety submission flush in the heartbeat 211c9c5a677c drm/i915/execlists: Replace direct submit with direct call to tasklet 502d7d962450 drm/i915/execlists: Defer schedule_out until after the next dequeue -:117: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV) #117: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2441: + *execlists->inactive++ = *port; ^ total: 0 errors, 0 warnings, 1 checks, 179 lines checked ab23cefb7c81 drm/i915/gt: ce->inflight updates are now serialised ffe345ebb5eb drm/i915/gt: Drop atomic for engine->fw_active tracking d8fe93841b53 drm/i915/gt: Use virtual_engine during execlists_dequeue db4fcfc79839 drm/i915/gt: Decouple inflight virtual engines 2d03c2830ca3 drm/i915/gt: Resubmit the virtual engine on schedule-out ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove unnecessary conversion to bool
== Series Details ==
Series: drm/i915: remove unnecessary conversion to bool
URL : https://patchwork.freedesktop.org/series/78372/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8627 -> Patchwork_17947
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/index.html
Known issues
Here are the changes found in Patchwork_17947 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@modeset:
- {fi-tgl-dsi}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +3
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][23] ([i915#402]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8627/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17947/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][25] ([i915#62]) -> [DMESG-FAIL][26]
([i915#62] / [i915#95])
[25]:
[Intel-gfx] [PATCH] drm/i915/gt: Add a safety submission flush in the heartbeat
Just in case everything fails (like for example "missed interrupt
syndrome" on Sandybridge), always flush the submission tasklet from the
heartbeat. This papers over such issues, but will still appear as a
second long glitch, and prevents us from detecting it unless we happen
to be performing a timed test.
v2: We rely on flush_submission() synchronizing with the tasklet on
another CPU.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 23 +--
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3 +++
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d613cf31970c..31049e0bdb57 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1094,19 +1094,18 @@ void intel_engine_flush_submission(struct
intel_engine_cs *engine)
{
struct tasklet_struct *t = >execlists.tasklet;
- if (__tasklet_is_scheduled(t)) {
- local_bh_disable();
- if (tasklet_trylock(t)) {
- /* Must wait for any GPU reset in progress. */
- if (__tasklet_is_enabled(t))
- t->func(t->data);
- tasklet_unlock(t);
- }
- local_bh_enable();
+ /* Synchronise and wait for the tasklet on another CPU */
+ tasklet_kill(t);
+
+ /* Having cancelled the tasklet, ensure that is run */
+ local_bh_disable();
+ if (tasklet_trylock(t)) {
+ /* Must wait for any GPU reset in progress. */
+ if (__tasklet_is_enabled(t))
+ t->func(t->data);
+ tasklet_unlock(t);
}
-
- /* Otherwise flush the tasklet if it was running on another cpu */
- tasklet_unlock_wait(t);
+ local_bh_enable();
}
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index f67ad937eefb..cd20fb549b38 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -65,6 +65,9 @@ static void heartbeat(struct work_struct *wrk)
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
+ /* Just in case everything has gone horribly wrong, give it a kick */
+ intel_engine_flush_submission(engine);
+
rq = engine->heartbeat.systole;
if (rq && i915_request_completed(rq)) {
i915_request_put(rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove unnecessary conversion to bool
In function perform_bb_shadow, bb->ppgtt is bool, so maybe there is no need to convert the bool condition to bool. This change is to make the code a bit readable. Signed-off-by: Bernard Zhao --- drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c b/drivers/gpu/drm/i915/gvt/cmd_parser.c index 8b87f130f7f1..221eaebfe513 100644 --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c @@ -1880,7 +1880,7 @@ static int perform_bb_shadow(struct parser_exec_state *s) if (!bb) return -ENOMEM; - bb->ppgtt = (s->buf_addr_type == GTT_BUFFER) ? false : true; + bb->ppgtt = (s->buf_addr_type != GTT_BUFFER); /* the start_offset stores the batch buffer's start gma's * offset relative to page boundary. so for non-privileged batch -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/15] pwm: lpss: Add range limit check for the base_unit register value
Hello Andy, On Fri, Jun 12, 2020 at 02:57:32PM +0300, Andy Shevchenko wrote: > On Fri, Jun 12, 2020 at 12:12:42AM +0200, Uwe Kleine-König wrote: > > I didn't follow the complete discussion but note that the general rule > > is: > > > > round period down to the next possible implementable period > > round duty_cycle down to the next possible implementable duty_cycle > > > > so if a small enough period (and so a small duty_cycle) is requested it > > is expected that duty_cycle will be zero. > > ...which brings me an idea that PWM framework should expose API to get a > capabilities, like DMA Engine has. > > In such capabilities, in particular, caller can get ranges of the correct > frequencies of the underneath hardware. my idea is to introduce a function pwm_round_state() that has a similar semantic to clk_round_rate(). But this is only one of several thoughts I have for the pwm framework. And as there is (AFAIK) no user who would benefit from pwm_round_state() this is further down on my todo list. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915/execlists: Replace direct submit with direct call to tasklet
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fast/immediate submissions, without requiring any
duplicated code paths.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h | 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 27 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 78
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 1 +
4 files changed, 45 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 791897f8d847..c77b3c0d2b3b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -210,6 +210,7 @@ int intel_engine_resume(struct intel_engine_cs *engine);
int intel_ring_submission_setup(struct intel_engine_cs *engine);
+void __intel_engine_stop_cs(struct intel_engine_cs *engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 81884303bf6d..667ee52448a0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -903,33 +903,34 @@ static unsigned long stop_timeout(const struct
intel_engine_cs *engine)
return READ_ONCE(engine->props.stop_timeout_ms);
}
-int intel_engine_stop_cs(struct intel_engine_cs *engine)
+void __intel_engine_stop_cs(struct intel_engine_cs *engine)
{
struct intel_uncore *uncore = engine->uncore;
- const u32 base = engine->mmio_base;
- const i915_reg_t mode = RING_MI_MODE(base);
- int err;
+ const i915_reg_t mode = RING_MI_MODE(engine->mmio_base);
+ intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
+ intel_uncore_posting_read_fw(uncore, mode);
+}
+
+int intel_engine_stop_cs(struct intel_engine_cs *engine)
+{
if (INTEL_GEN(engine->i915) < 3)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
- intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
+ __intel_engine_stop_cs(engine);
- err = 0;
- if (__intel_wait_for_register_fw(uncore,
-mode, MODE_IDLE, MODE_IDLE,
+ if (__intel_wait_for_register_fw(engine->uncore,
+RING_MI_MODE(engine->mmio_base),
+MODE_IDLE, MODE_IDLE,
1000, stop_timeout(engine),
NULL)) {
ENGINE_TRACE(engine, "timed out on STOP_RING -> IDLE\n");
- err = -ETIMEDOUT;
+ return -ETIMEDOUT;
}
- /* A final mmio read to let GPU writes be hopefully flushed to memory */
- intel_uncore_posting_read_fw(uncore, mode);
-
- return err;
+ return 0;
}
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e866b8d721ed..40c5085765da 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2703,16 +2703,6 @@ static void process_csb(struct intel_engine_cs *engine)
invalidate_csb_entries([0], [num_entries - 1]);
}
-static void __execlists_submission_tasklet(struct intel_engine_cs *const
engine)
-{
- lockdep_assert_held(>active.lock);
- if (!READ_ONCE(engine->execlists.pending[0])) {
- rcu_read_lock(); /* protect peeking at execlists->active */
- execlists_dequeue(engine);
- rcu_read_unlock();
- }
-}
-
static void __execlists_hold(struct i915_request *rq)
{
LIST_HEAD(list);
@@ -3102,7 +3092,7 @@ static bool preempt_timeout(const struct intel_engine_cs
*const engine)
if (!timer_expired(t))
return false;
- return READ_ONCE(engine->execlists.pending[0]);
+ return engine->execlists.pending[0];
}
/*
@@ -3112,7 +3102,6 @@ static bool preempt_timeout(const struct intel_engine_cs
*const engine)
static void execlists_submission_tasklet(unsigned long data)
{
struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
- bool timeout = preempt_timeout(engine);
process_csb(engine);
@@ -3122,16 +3111,17 @@ static void execlists_submission_tasklet(unsigned long
data)
execlists_reset(engine, "CS error");
}
- if (!READ_ONCE(engine->execlists.pending[0]) || timeout) {
+ if (unlikely(preempt_timeout(engine)))
+ execlists_reset(engine, "preemption time out");
+
+
[Intel-gfx] [PATCH 10/10] drm/i915/gt: Resubmit the virtual engine on schedule-out
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
By keeping the unwind order intact on the local engine, we can preserve
data dependency ordering while doing a preempt-to-busy pass until we
have determined the new ELSP. This means that if we try to timeslice
between a virtual engine and a data-dependent ordinary request, the pair
will maintain their relative ordering and we will avoid the
resubmission, cancelling the timeslicing until further change.
The dilemma though is that we then may end up in a situation where the
'demotion' of the virtual request to an ordinary request in the engine
queue results in filling the ELSP[] with virtual requests instead of
spreading the load across the engines. To compensate for this, we mark
each virtual request and refuse to resubmit a virtual request in the
secondary ELSP slots, thus forcing subsequent virtual requests to be
scheduled out after timeslicing. By delaying the decision until we
schedule out, we will avoid unnecessary resubmission.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 118 -
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
2 files changed, 75 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 4a1e23e51314..45029eb86b6e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1117,53 +1117,23 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
__i915_request_unsubmit(rq);
- /*
-* Push the request back into the queue for later resubmission.
-* If this request is not native to this physical engine (i.e.
-* it came from a virtual source), push it back onto the virtual
-* engine so that it can be moved across onto another physical
-* engine as load dictates.
-*/
- if (likely(rq->execution_mask == engine->mask)) {
- GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
- if (rq_prio(rq) != prio) {
- prio = rq_prio(rq);
- pl = i915_sched_lookup_priolist(engine, prio);
- }
-
GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root));
-
- list_move(>sched.link, pl);
- set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+ GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
+ if (rq_prio(rq) != prio) {
+ prio = rq_prio(rq);
+ pl = i915_sched_lookup_priolist(engine, prio);
+ }
+ GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root));
- /* Check in case we rollback so far we wrap [size/2] */
- if (intel_ring_direction(rq->ring,
-intel_ring_wrap(rq->ring,
-rq->tail),
-rq->ring->tail) > 0)
- rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
+ list_move(>sched.link, pl);
+ set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
- active = rq;
- } else {
- struct intel_engine_cs *owner = rq->context->engine;
+ /* Check in case we rollback so far we wrap [size/2] */
+ if (intel_ring_direction(rq->ring,
+intel_ring_wrap(rq->ring, rq->tail),
+rq->ring->tail) > 0)
+ rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
- /*
-* Decouple the virtual breadcrumb before moving it
-* back to the virtual engine -- we don't want the
-* request to complete in the background and try
-* and cancel the breadcrumb on the virtual engine
-* (instead of the old engine where it is linked)!
-*/
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
->fence.flags)) {
- spin_lock_nested(>lock,
-SINGLE_DEPTH_NESTING);
- i915_request_cancel_breadcrumb(rq);
- spin_unlock(>lock);
- }
- WRITE_ONCE(rq->engine, owner);
- owner->submit_request(rq);
- active =
[Intel-gfx] [PATCH 05/10] drm/i915/execlists: Defer schedule_out until after the next dequeue
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it back in during dequeue. This is just extra work
that we can avoid if we keep the context marked as inflight across the
dequeue. This becomes more significant later on for minimising virtual
engine misses.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 13 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 47 ++-
4 files changed, 51 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 4954b0df4864..b63db45bab7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -45,8 +45,8 @@ struct intel_context {
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
-#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 2)
-#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 2)
+#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 3)
+#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 3)
struct i915_address_space *vm;
struct i915_gem_context __rcu *gem_context;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 667ee52448a0..0e94e52ee760 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -515,6 +515,8 @@ void intel_engine_init_execlists(struct intel_engine_cs
*engine)
memset(execlists->pending, 0, sizeof(execlists->pending));
execlists->active =
memset(execlists->inflight, 0, sizeof(execlists->inflight));
+ execlists->inactive =
+ memset(execlists->post, 0, sizeof(execlists->post));
execlists->queue_priority_hint = INT_MIN;
execlists->queue = RB_ROOT_CACHED;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 073c3769e8cc..31cf60cef5a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -208,6 +208,10 @@ struct intel_engine_execlists {
* @active: the currently known context executing on HW
*/
struct i915_request * const *active;
+ /**
+* @inactive: the current vacancy of completed CS
+*/
+ struct i915_request **inactive;
/**
* @inflight: the set of contexts submitted and acknowleged by HW
*
@@ -225,6 +229,15 @@ struct intel_engine_execlists {
* preemption or idle-to-active event.
*/
struct i915_request *pending[EXECLIST_MAX_PORTS + 1];
+ /**
+* @post: the set of completed context switches
+*
+* Since we may want to stagger the processing of the CS switches
+* with the next submission, so that the context are notionally
+* kept in flight across the dequeue, we defer scheduling out of
+* the completed context switches.
+*/
+ struct i915_request *post[2 * EXECLIST_MAX_PORTS + 1];
/**
* @port_mask: number of execlist ports - 1
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 40c5085765da..adc14adfa89c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1385,6 +1385,8 @@ __execlists_schedule_in(struct i915_request *rq)
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
+ CE_TRACE(ce, "schedule-in, ccid:%x\n", ce->lrc.ccid);
+
return engine;
}
@@ -1431,6 +1433,8 @@ __execlists_schedule_out(struct i915_request *rq,
* refrain from doing non-trivial work here.
*/
+ CE_TRACE(ce, "schedule-out, ccid:%x\n", ccid);
+
/*
* If we have just completed this context, the engine may now be
* idle and we want to re-enter powersaving.
@@ -2055,9 +2059,10 @@ static void set_preempt_timeout(struct intel_engine_cs
*engine,
active_preempt_timeout(engine, rq));
}
-static inline void clear_ports(struct i915_request **ports, int count)
+static inline struct i915_request **
+clear_ports(struct i915_request **ports, int count)
{
- memset_p((void **)ports, NULL, count);
+ return memset_p((void **)ports, NULL, count);
}
static void execlists_dequeue(struct intel_engine_cs *engine)
@@ -2433,7 +2438,7 @@ static void execlists_dequeue(struct
[Intel-gfx] [PATCH 08/10] drm/i915/gt: Use virtual_engine during execlists_dequeue
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtual engine lookup, for typical use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 214 +---
1 file changed, 101 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 09ec7242fbcb..34a8eadc2de3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -454,7 +454,7 @@ static int queue_prio(const struct intel_engine_execlists
*execlists)
static inline bool need_preempt(const struct intel_engine_cs *engine,
const struct i915_request *rq,
- struct rb_node *rb)
+ struct virtual_engine *ve)
{
int last_prio;
@@ -491,9 +491,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
rq_prio(list_next_entry(rq, sched.link)) > last_prio)
return true;
- if (rb) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ if (ve) {
bool preempt = false;
if (engine == ve->siblings[0]) { /* only preempt one sibling */
@@ -1816,6 +1814,35 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
+static struct virtual_engine *
+first_virtual_engine(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *el = >execlists;
+ struct rb_node *rb = rb_first_cached(>virtual);
+
+ while (rb) {
+ struct virtual_engine *ve =
+ rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ struct i915_request *rq = READ_ONCE(ve->request);
+
+ if (!rq) { /* lazily cleanup after another engine handled rq */
+ rb_erase_cached(rb, >virtual);
+ RB_CLEAR_NODE(rb);
+ rb = rb_first_cached(>virtual);
+ continue;
+ }
+
+ if (!virtual_matches(ve, rq, engine)) {
+ rb = rb_next(rb);
+ continue;
+ }
+
+ return ve;
+ }
+
+ return NULL;
+}
+
static void virtual_xfer_breadcrumbs(struct virtual_engine *ve)
{
/*
@@ -1900,7 +1927,7 @@ static void defer_active(struct intel_engine_cs *engine)
static bool
need_timeslice(const struct intel_engine_cs *engine,
const struct i915_request *rq,
- const struct rb_node *rb)
+ struct virtual_engine *ve)
{
int hint;
@@ -1909,9 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
hint = engine->execlists.queue_priority_hint;
- if (rb) {
- const struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ if (ve) {
const struct intel_engine_cs *inflight =
intel_context_inflight(>context);
@@ -2063,7 +2088,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
struct intel_engine_execlists * const execlists = >execlists;
struct i915_request **port = execlists->pending;
struct i915_request ** const last_port = port + execlists->port_mask;
- struct i915_request * const *active;
+ struct i915_request * const *active = READ_ONCE(execlists->active);
+ struct virtual_engine *ve = first_virtual_engine(engine);
struct i915_request *last;
struct rb_node *rb;
bool submit = false;
@@ -2090,26 +2116,6 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* and context switches) submission.
*/
- for (rb = rb_first_cached(>virtual); rb; ) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
- struct i915_request *rq = READ_ONCE(ve->request);
-
- if (!rq) { /* lazily cleanup after another engine handled rq */
- rb_erase_cached(rb, >virtual);
- RB_CLEAR_NODE(rb);
- rb = rb_first_cached(>virtual);
- continue;
- }
-
- if (!virtual_matches(ve, rq, engine)) {
- rb = rb_next(rb);
- continue;
- }
-
- break;
- }
-
/*
* If the queue is higher priority than the last
* request in the currently active context, submit afresh.
@@ -2117,10 +2123,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
[Intel-gfx] [PATCH 02/10] drm/i915/selftests: Dump engine state and trace upon hanging after reset
If the engine dies after a reset, and so we fail to submit a request
but need to be interrupted by the CI runner, dump the engine state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 2af66f8ffbd2..0f1be62cdc6f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -499,6 +499,24 @@ static int igt_reset_nop_engine(void *arg)
rq = intel_context_create_request(ce);
if (IS_ERR(rq)) {
+ struct drm_printer p =
+
drm_info_printer(gt->i915->drm.dev);
+ intel_engine_dump(engine, ,
+ "%s(%s): failed to
submit request %llx:%lld\n",
+ __func__,
+ engine->name,
+ rq->fence.context,
+ rq->fence.seqno);
+
+
+ GEM_TRACE("%s(%s): failed to submit
request %llx:%lld\n",
+ __func__, engine->name,
+ rq->fence.context,
+ rq->fence.seqno);
+ GEM_TRACE_DUMP();
+
+ intel_gt_set_wedged(gt);
+
err = PTR_ERR(rq);
break;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915/gt: Add a safety submission flush in the heartbeat
Just in case everything fails (like for example "missed interrupt
syndrome" on Sandybridge), always flush the submission tasklet from the
heartbeat. This papers over such issues, but will still appear as a
second long glitch, and prevents us from detecting it unless we happen
to be performing a timed test.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 19 +++
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3 +++
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d613cf31970c..81884303bf6d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1094,19 +1094,14 @@ void intel_engine_flush_submission(struct
intel_engine_cs *engine)
{
struct tasklet_struct *t = >execlists.tasklet;
- if (__tasklet_is_scheduled(t)) {
- local_bh_disable();
- if (tasklet_trylock(t)) {
- /* Must wait for any GPU reset in progress. */
- if (__tasklet_is_enabled(t))
- t->func(t->data);
- tasklet_unlock(t);
- }
- local_bh_enable();
+ local_bh_disable();
+ if (tasklet_trylock(t)) {
+ /* Must wait for any GPU reset in progress. */
+ if (__tasklet_is_enabled(t))
+ t->func(t->data);
+ tasklet_unlock(t);
}
-
- /* Otherwise flush the tasklet if it was running on another cpu */
- tasklet_unlock_wait(t);
+ local_bh_enable();
}
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index f67ad937eefb..cd20fb549b38 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -65,6 +65,9 @@ static void heartbeat(struct work_struct *wrk)
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
+ /* Just in case everything has gone horribly wrong, give it a kick */
+ intel_engine_flush_submission(engine);
+
rq = engine->heartbeat.systole;
if (rq && i915_request_completed(rq)) {
i915_request_put(rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915/gt: Decouple inflight virtual engines
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the context is inflight, only kick the bound sibling while it
inflight and upon scheduling out the kick the rest (so that we can swap
engines on timeslicing if the previously bound engine becomes
oversubscribed).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 30 +
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 34a8eadc2de3..4a1e23e51314 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1409,9 +1409,8 @@ execlists_schedule_in(struct i915_request *rq, int idx)
static void kick_siblings(struct i915_request *rq, struct intel_context *ce)
{
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
- struct i915_request *next = READ_ONCE(ve->request);
- if (next == rq || (next && next->execution_mask & ~rq->execution_mask))
+ if (READ_ONCE(ve->request))
tasklet_hi_schedule(>base.execlists.tasklet);
}
@@ -1825,18 +1824,14 @@ first_virtual_engine(struct intel_engine_cs *engine)
rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
struct i915_request *rq = READ_ONCE(ve->request);
- if (!rq) { /* lazily cleanup after another engine handled rq */
+ /* lazily cleanup after another engine handled rq */
+ if (!rq || !virtual_matches(ve, rq, engine)) {
rb_erase_cached(rb, >virtual);
RB_CLEAR_NODE(rb);
rb = rb_first_cached(>virtual);
continue;
}
- if (!virtual_matches(ve, rq, engine)) {
- rb = rb_next(rb);
- continue;
- }
-
return ve;
}
@@ -5486,7 +5481,6 @@ static void virtual_submission_tasklet(unsigned long data)
if (unlikely(!mask))
return;
- local_irq_disable();
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = READ_ONCE(ve->siblings[n]);
struct ve_node * const node = >nodes[sibling->id];
@@ -5496,20 +5490,19 @@ static void virtual_submission_tasklet(unsigned long
data)
if (!READ_ONCE(ve->request))
break; /* already handled by a sibling's tasklet */
+ spin_lock_irq(>active.lock);
+
if (unlikely(!(mask & sibling->mask))) {
if (!RB_EMPTY_NODE(>rb)) {
- spin_lock(>active.lock);
rb_erase_cached(>rb,
>execlists.virtual);
RB_CLEAR_NODE(>rb);
- spin_unlock(>active.lock);
}
- continue;
- }
- spin_lock(>active.lock);
+ goto unlock_engine;
+ }
- if (!RB_EMPTY_NODE(>rb)) {
+ if (unlikely(!RB_EMPTY_NODE(>rb))) {
/*
* Cheat and avoid rebalancing the tree if we can
* reuse this node in situ.
@@ -5549,9 +5542,12 @@ static void virtual_submission_tasklet(unsigned long
data)
if (first && prio > sibling->execlists.queue_priority_hint)
tasklet_hi_schedule(>execlists.tasklet);
- spin_unlock(>active.lock);
+unlock_engine:
+ spin_unlock_irq(>active.lock);
+
+ if (intel_context_inflight(>context))
+ break;
}
- local_irq_enable();
}
static void virtual_submit_request(struct i915_request *rq)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915/selftests: Disable preemptive heartbeats over preemption tests
Since the heartbeat may cause a preemption event, disable it over the
preemption suppression tests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index f651bdf7f191..91543494f595 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -2282,7 +2282,7 @@ static int live_suppress_self_preempt(void *arg)
if (igt_flush_test(gt->i915))
goto err_wedged;
- intel_engine_pm_get(engine);
+ engine_heartbeat_disable(engine);
engine->execlists.preempt_hang.count = 0;
rq_a = spinner_create_request(,
@@ -2290,14 +2290,14 @@ static int live_suppress_self_preempt(void *arg)
MI_NOOP);
if (IS_ERR(rq_a)) {
err = PTR_ERR(rq_a);
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_client_b;
}
i915_request_add(rq_a);
if (!igt_wait_for_spinner(, rq_a)) {
pr_err("First client failed to start\n");
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_wedged;
}
@@ -2309,7 +2309,7 @@ static int live_suppress_self_preempt(void *arg)
MI_NOOP);
if (IS_ERR(rq_b)) {
err = PTR_ERR(rq_b);
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_client_b;
}
i915_request_add(rq_b);
@@ -2320,7 +2320,7 @@ static int live_suppress_self_preempt(void *arg)
if (!igt_wait_for_spinner(, rq_b)) {
pr_err("Second client failed to start\n");
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
goto err_wedged;
}
@@ -2334,12 +2334,12 @@ static int live_suppress_self_preempt(void *arg)
engine->name,
engine->execlists.preempt_hang.count,
depth);
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
err = -EINVAL;
goto err_client_b;
}
- intel_engine_pm_put(engine);
+ engine_heartbeat_enable(engine);
if (igt_flush_test(gt->i915))
goto err_wedged;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915/gt: ce->inflight updates are now serialised
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 43 -
1 file changed, 18 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index adc14adfa89c..8b3959207c02 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1371,7 +1371,7 @@ __execlists_schedule_in(struct i915_request *rq)
unsigned int tag = ffs(READ_ONCE(engine->context_tag));
GEM_BUG_ON(tag == 0 || tag >= BITS_PER_LONG);
- clear_bit(tag - 1, >context_tag);
+ __clear_bit(tag - 1, >context_tag);
ce->lrc.ccid = tag << (GEN11_SW_CTX_ID_SHIFT - 32);
BUILD_BUG_ON(BITS_PER_LONG > GEN12_MAX_CONTEXT_HW_ID);
@@ -1399,13 +1399,10 @@ execlists_schedule_in(struct i915_request *rq, int idx)
GEM_BUG_ON(!intel_engine_pm_is_awake(rq->engine));
trace_i915_request_in(rq, idx);
- old = READ_ONCE(ce->inflight);
- do {
- if (!old) {
- WRITE_ONCE(ce->inflight, __execlists_schedule_in(rq));
- break;
- }
- } while (!try_cmpxchg(>inflight, , ptr_inc(old)));
+ old = ce->inflight;
+ if (!old)
+ old = __execlists_schedule_in(rq);
+ WRITE_ONCE(ce->inflight, ptr_inc(old));
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
return i915_request_get(rq);
@@ -1420,12 +1417,11 @@ static void kick_siblings(struct i915_request *rq,
struct intel_context *ce)
tasklet_hi_schedule(>base.execlists.tasklet);
}
-static inline void
-__execlists_schedule_out(struct i915_request *rq,
-struct intel_engine_cs * const engine,
-unsigned int ccid)
+static inline void __execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
+ struct intel_engine_cs * const engine = ce->inflight;
+ unsigned int ccid;
/*
* NB process_csb() is not under the engine->active.lock and hence
@@ -1433,7 +1429,7 @@ __execlists_schedule_out(struct i915_request *rq,
* refrain from doing non-trivial work here.
*/
- CE_TRACE(ce, "schedule-out, ccid:%x\n", ccid);
+ CE_TRACE(ce, "schedule-out, ccid:%x\n", ce->lrc.ccid);
/*
* If we have just completed this context, the engine may now be
@@ -1443,12 +1439,13 @@ __execlists_schedule_out(struct i915_request *rq,
i915_request_completed(rq))
intel_engine_add_retire(engine, ce->timeline);
+ ccid = ce->lrc.ccid;
ccid >>= GEN11_SW_CTX_ID_SHIFT - 32;
ccid &= GEN12_MAX_CONTEXT_HW_ID;
if (ccid < BITS_PER_LONG) {
GEM_BUG_ON(ccid == 0);
GEM_BUG_ON(test_bit(ccid - 1, >context_tag));
- set_bit(ccid - 1, >context_tag);
+ __set_bit(ccid - 1, >context_tag);
}
intel_context_update_runtime(ce);
@@ -1469,26 +1466,22 @@ __execlists_schedule_out(struct i915_request *rq,
*/
if (ce->engine != engine)
kick_siblings(rq, ce);
-
- intel_context_put(ce);
}
static inline void
execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
- struct intel_engine_cs *cur, *old;
- u32 ccid;
trace_i915_request_out(rq);
- ccid = rq->context->lrc.ccid;
- old = READ_ONCE(ce->inflight);
- do
- cur = ptr_unmask_bits(old, 2) ? ptr_dec(old) : NULL;
- while (!try_cmpxchg(>inflight, , cur));
- if (!cur)
- __execlists_schedule_out(rq, old, ccid);
+ GEM_BUG_ON(!ce->inflight);
+ ce->inflight = ptr_dec(ce->inflight);
+ if (!intel_context_inflight_count(ce)) {
+ __execlists_schedule_out(rq);
+ WRITE_ONCE(ce->inflight, NULL);
+ intel_context_put(ce);
+ }
i915_request_put(rq);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915/gt: Drop atomic for engine->fw_active tracking
Since schedule-in/out is now entirely serialised by the tasklet bitlock,
we do not need to worry about concurrent in/out operations and so reduce
the atomic operations to plain instructions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 0e94e52ee760..c91d18b384e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1524,7 +1524,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "\tLatency: %luus\n",
ewma__engine_latency_read(>latency));
drm_printf(m, "\tForcewake: %x domains, %d active\n",
- engine->fw_domain, atomic_read(>fw_active));
+ engine->fw_domain, READ_ONCE(engine->fw_active));
rcu_read_lock();
rq = READ_ONCE(engine->heartbeat.systole);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 31cf60cef5a8..ca124f229f65 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -335,7 +335,7 @@ struct intel_engine_cs {
* as possible.
*/
enum forcewake_domains fw_domain;
- atomic_t fw_active;
+ unsigned int fw_active;
unsigned long context_tag;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8b3959207c02..09ec7242fbcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1380,7 +1380,7 @@ __execlists_schedule_in(struct i915_request *rq)
ce->lrc.ccid |= engine->execlists.ccid;
__intel_gt_pm_get(engine->gt);
- if (engine->fw_domain && !atomic_fetch_inc(>fw_active))
+ if (engine->fw_domain && !engine->fw_active++)
intel_uncore_forcewake_get(engine->uncore, engine->fw_domain);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
@@ -1451,7 +1451,7 @@ static inline void __execlists_schedule_out(struct
i915_request *rq)
intel_context_update_runtime(ce);
intel_engine_context_out(engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
- if (engine->fw_domain && !atomic_dec_return(>fw_active))
+ if (engine->fw_domain && !--engine->fw_active)
intel_uncore_forcewake_put(engine->uncore, engine->fw_domain);
intel_gt_pm_put_async(engine->gt);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Add a new debugfs to request HDCP version
Hi Anshuman,
Thanks for the review comments and suggestions.
Please find my response inline:
On 6/15/2020 10:15 AM, Anshuman Gupta wrote:
On 2020-06-08 at 15:31:03 +0530, Ankit Nautiyal wrote:
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to satisfy the content-protection
requirements of the user. Due to this, the content-protection
tests cannot test a lower version of HDCP, if the platform and the
display panel, both support higher HDCP version.
To provide some support for testing and debugging, a per-connector
debugfs is required to set the HDCP version via debugfs that the
kernel can consider, while enabling HDCP.
This patch adds a new debugfs entry for each connector that supports
HDCP. For enforcing a particular HDCP version for a connector, the user
can write into the debugfs for that connector.
IMHO this doesn't feel like a debugfs per connector, even if it is a
global singleton resource for all connectors, i don't see any problem in
that, may be a global debugfs would make sense here ?
The current solution was inline with the comments in the IGT patch,
where the approach for a connector level debugfs was discussed by the
community members.
But I agree we don't necessarily require per connector debugfs for our
use-case here.
We can use a global resource for storing the request for HDCP version
and use it if it is set, while enabling HDCP.
Perhaps will store it in dev_priv, instead of connector->hdcp.
I will try that out and send next version.
v2: As suggested by Jani Nikula:
-used kstrtouint_from_user() to directly read as uint from user buffer.
-used 32 bit flag instead of 64 bit for hdcp_ver flag.
-removed unnecessary prints and fixed other minor formatting issues.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_debugfs.c | 68 +++
1 file changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 70525623bcdf..c01653d412e7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2185,6 +2185,72 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_hdcp_ver_request_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ u32 hdcp_ver_flag;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ /* HDCP is supported by connector */
+ if (!intel_connector->hdcp.shim)
+ return -EINVAL;
+
+ hdcp_ver_flag = intel_connector->hdcp.debugfs_ver_request;
+ seq_printf(m, "HDCP_VER_FLAGS: %u\n", hdcp_ver_flag);
+
+ return 0;
+}
+
+static int i915_hdcp_ver_request_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_hdcp_ver_request_show,
+ inode->i_private);
+}
+
+static ssize_t i915_hdcp_ver_request_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ unsigned int hdcp_ver = 0;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_hdcp *hdcp = _connector->hdcp;
+
+ if (!hdcp->shim)
+ return -EINVAL;
+
+ if (len == 0)
+ return 0;
+
+ ret = kstrtouint_from_user(ubuf, len, 0, _ver);
+ if (ret < 0)
+ return ret;
+
+ if (hdcp_ver > HDCP_VERSION_MASK)
+ return -EINVAL;
+
+ hdcp->debugfs_ver_request = hdcp_ver;
A lockless assignment, this would probably not scale.
Could u please add some comment here for current IGT need this is ok,
but for any concurrent usgaes proper locking is required.
Thanks,
Anshuman
Agreed. I will add this as a note in comments in next version.
Thanks & Regards,
Ankit
+
+ *offp += len;
+
+ return len;
+}
+
+static const struct file_operations i915_hdcp_ver_request_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_hdcp_ver_request_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_hdcp_ver_request_write
+};
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2215,6 +2281,8 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
debugfs_create_file("i915_hdcp_sink_capability",
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Add support for considering HDCP ver requested via debugfs
Hi Anshuman,
Thanks for the comments. Please find my response inline:
On 6/15/2020 9:59 AM, Anshuman Gupta wrote:
On 2020-06-08 at 15:31:02 +0530, Ankit Nautiyal wrote:
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The version
requested via debugfs needs to be stored in hdcp structure. This can
then be considered while enabling HDCP, provided the platform and the
display supports the requested version.
This patch adds the support for storing the version requested as a 32bit
flag. It also adds a helper function to check if a version is requested.
If a specific HDCP version is requested through the debugfs, the driver
chooses that version, instead of policy of choosing the highest HDCP
version supported.
v2: Initialize debugfs_ver_request flag with 0. (Jani Nikula)
Signed-off-by: Ankit Nautiyal
---
.../gpu/drm/i915/display/intel_display_types.h | 10 ++
drivers/gpu/drm/i915/display/intel_hdcp.c| 16 ++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9488449e4b94..cfa641c70717 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -408,6 +408,16 @@ struct intel_hdcp {
* Hence caching the transcoder here.
*/
enum transcoder cpu_transcoder;
+
+ /*
+* HDCP version requested from debugfs i915_hdcp_ver_request.
+* Kernel will read these bits and entertain the request, as per
+* the HDCP capability of the panel and platform.
+*/
+#define HDCP_VERSION_1_4 0x01
+#define HDCP_VERSION_2_2 0x02
+#define HDCP_VERSION_MASK 0x03
+ u32 debugfs_ver_request;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2cbc4619b4ce..a21ea9c2e9a7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1977,6 +1977,8 @@ int intel_hdcp_init(struct intel_connector *connector,
if (!shim)
return -EINVAL;
+ hdcp->debugfs_ver_request = 0;
+
if (is_hdcp2_supported(dev_priv))
intel_hdcp2_init(connector, shim);
@@ -1998,6 +2000,14 @@ int intel_hdcp_init(struct intel_connector *connector,
return 0;
}
+static bool hdcp_debugfs_requested(struct intel_hdcp *hdcp, u32 hdcp_version)
+{
+ if (!hdcp->debugfs_ver_request)
+ return true;
+
+ return hdcp->debugfs_ver_request & hdcp_version ? true : false;
+}
+
int intel_hdcp_enable(struct intel_connector *connector,
enum transcoder cpu_transcoder, u8 content_type)
{
@@ -2023,7 +2033,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
- if (intel_hdcp2_capable(connector)) {
+ if (hdcp_debugfs_requested(hdcp, HDCP_VERSION_2_2) &&
+ intel_hdcp2_capable(connector)) {
ret = _intel_hdcp2_enable(connector);
if (!ret)
check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
@@ -2033,7 +2044,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* When HDCP2.2 fails and Content Type is not Type1, HDCP1.4 will
* be attempted.
*/
- if (ret && intel_hdcp_capable(connector) &&
+ if (ret && hdcp_debugfs_requested(hdcp, HDCP_VERSION_1_4) &&
IMHO there is no case when both version HDCP 2.2 and HDCP 1.4 version
will be set, i believe for IGT if HDCP 2.2 fails and version is HDCP 2.2
it should have returen from above, no need to check a ret value and
HDCP 1.4 version. Could we simplify conditions here.
Thanks,
Anshuman Gupta.
I was trying to have minimum change in the present flow. So I had just
added a function
hdcp_debugfs_requested(). This will return true if there is no version
requested and the flow remains same.
In case a specific version is requested say HDCP 2.2, only that version
will be chosen. In case the HDCP2.2 fails,
the hdcp_debugfs_requested() condition will fail and the flow will skip
for HDCP1.4 part.
If not like this, we can try to have a separate code-block, for the case
where debugfs version is requested,
but this will lead to duplication of parts for enabling HDCP2.2/ HDCP1.4.
if (hdcp->debugfs_ver_request & HDCP_VERSION_2_2) {
/* enable HDCP2.2 */
}
else if (hdcp->debugfs_ver_request & HDCP_VERSION_1_4) {
/* enable HDCP1.4 */
}
else {
/* Existing policy of enabling HDCP2.2 if possible, or fall back to
HDCP1.4*/
}
So to avoid code duplication, IMHO, the current mechanism seems fine.
Perhaps the naming of the function
Re: [Intel-gfx] [PATCH 9/9] drm/shmem-helpers: Simplify dma-buf importing
Hi Daniel
this patch causes a segmentation fault.
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> - Ditch the ->pages array
> - Make it a private gem bo, which means no shmem object, which means
> fireworks if anyone calls drm_gem_object_get_pages. But we've just
> made sure that's all covered.
>
> Cc: Gerd Hoffmann
> Cc: Rob Herring
> Cc: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 59 ++
> 1 file changed, 23 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index f7011338813e..8c7d4f422b7b 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -35,22 +35,12 @@ static const struct drm_gem_object_funcs
> drm_gem_shmem_funcs = {
> .mmap = drm_gem_shmem_mmap,
> };
>
> -/**
> - * drm_gem_shmem_create - Allocate an object with the given size
> - * @dev: DRM device
> - * @size: Size of the object to allocate
> - *
> - * This function creates a shmem GEM object.
> - *
> - * Returns:
> - * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded
> negative
> - * error code on failure.
> - */
> -struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
> size_t size)
> +static struct drm_gem_shmem_object *
> +__drm_gem_shmem_create(struct drm_device *dev, size_t size, bool private)
> {
> struct drm_gem_shmem_object *shmem;
> struct drm_gem_object *obj;
> - int ret;
> + int ret = 0;
>
> size = PAGE_ALIGN(size);
>
> @@ -64,7 +54,10 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct
> drm_device *dev, size_t
> if (!obj->funcs)
> obj->funcs = _gem_shmem_funcs;
>
> - ret = drm_gem_object_init(dev, obj, size);
> + if (private)
> + drm_gem_private_object_init(dev, obj, size);
This call doesn't set obj->filp, which is dereferenced further below at
[1]. This happens from dumb_create().
Best regards
Thomas
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_shmem_helper.c?h=v5.8-rc1#n87
> + else
> + ret = drm_gem_object_init(dev, obj, size);
> if (ret)
> goto err_free;
>
> @@ -96,6 +89,21 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct
> drm_device *dev, size_t
>
> return ERR_PTR(ret);
> }
> +/**
> + * drm_gem_shmem_create - Allocate an object with the given size
> + * @dev: DRM device
> + * @size: Size of the object to allocate
> + *
> + * This function creates a shmem GEM object.
> + *
> + * Returns:
> + * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded
> negative
> + * error code on failure.
> + */
> +struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
> size_t size)
> +{
> + return __drm_gem_shmem_create(dev, size, false);
> +}
> EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>
> /**
> @@ -115,7 +123,6 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
> if (obj->import_attach) {
> shmem->pages_use_count--;
> drm_prime_gem_destroy(obj, shmem->sgt);
> - kvfree(shmem->pages);
> } else {
> if (shmem->sgt) {
> dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
> @@ -371,7 +378,7 @@ drm_gem_shmem_create_with_handle(struct drm_file
> *file_priv,
> struct drm_gem_shmem_object *shmem;
> int ret;
>
> - shmem = drm_gem_shmem_create(dev, size);
> + shmem = __drm_gem_shmem_create(dev, size, true);
> if (IS_ERR(shmem))
> return shmem;
>
> @@ -695,36 +702,16 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> *dev,
> struct sg_table *sgt)
> {
> size_t size = PAGE_ALIGN(attach->dmabuf->size);
> - size_t npages = size >> PAGE_SHIFT;
> struct drm_gem_shmem_object *shmem;
> - int ret;
>
> shmem = drm_gem_shmem_create(dev, size);
> if (IS_ERR(shmem))
> return ERR_CAST(shmem);
>
> - shmem->pages = kvmalloc_array(npages, sizeof(struct page *),
> GFP_KERNEL);
> - if (!shmem->pages) {
> - ret = -ENOMEM;
> - goto err_free_gem;
> - }
> -
> - ret = drm_prime_sg_to_page_addr_arrays(sgt, shmem->pages, NULL, npages);
> - if (ret < 0)
> - goto err_free_array;
> -
> shmem->sgt = sgt;
> - shmem->pages_use_count = 1; /* Permanently pinned from our point of
> view */
>
> DRM_DEBUG_PRIME("size = %zu\n", size);
>
> return >base;
> -
> -err_free_array:
> - kvfree(shmem->pages);
> -err_free_gem:
> - drm_gem_object_put_unlocked(>base);
> -
> - return ERR_PTR(ret);
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg,
Re: [Intel-gfx] [PATCH] drm/i915/icl+: Fix hotplug interrupt disabling after storm detection
On Fri, Jun 12, 2020 at 04:18:48PM +0300, Ville Syrjälä wrote: > On Fri, Jun 12, 2020 at 03:17:31PM +0300, Imre Deak wrote: > > Atm, hotplug interrupts on TypeC ports are left enabled after detecting > > an interrupt storm, fix this. > > > > Reported-by: Kunal Joshi > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/351 > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964 > > Cc: Kunal Joshi > > Cc: sta...@vger.kernel.org > > Signed-off-by: Imre Deak > > --- > > drivers/gpu/drm/i915/i915_irq.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > b/drivers/gpu/drm/i915/i915_irq.c > > index 8e823ba25f5f..710224d930c5 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > @@ -3132,6 +3132,7 @@ static void gen11_hpd_irq_setup(struct > > drm_i915_private *dev_priv) > > > > val = I915_READ(GEN11_DE_HPD_IMR); > > val &= ~hotplug_irqs; > > + val |= ~enabled_irqs & hotplug_irqs; > > I915_WRITE(GEN11_DE_HPD_IMR, val); > > POSTING_READ(GEN11_DE_HPD_IMR); > > Wondering if we should add a function for this just for consistency > with all the other platforms. Yes makes sense, or even abstract the hpd interrupt enabling using the hpd pin -> interrupt flag table. I think we could even extend that table with the pulse detection bits and register addresses. I'll check if something like this would work for all platforms. > Alhthough we don't strictly need one since we have no other users of > this register. So maybe not. > > Anyways, patch is > Reviewed-by: Ville Syrjälä Thanks, pushed. > > > > > -- > > 2.23.1 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
