Re: [Intel-gfx] [PATCH] drm/i915/selftest: Check that GPR are restored across noa_wait
On 10/07/2020 00:53, Chris Wilson wrote:
Perf implements a GPU delay (noa_wait) by looping until the CS timestamp
has passed a certain point. This use MI_MATH and the general purpose
registers of the user's context, and since it is clobbering the user
state it must carefully save and restore the user's data around the
noa_wait. We can verify this by loading some values in the GPR that we
know will be clobbered the noa_wait, and then inspecting the GPR after
the noa_wait completes and confirming that have been restored.
Signed-off-by: Chris Wilson
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
Reviewed-by: Lionel Landwerlin
Thanks a lot!
-Lionel
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 124 +
1 file changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index be54570c407c..be63cfe82feb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -280,11 +280,135 @@ static int live_noa_delay(void *arg)
return err;
}
+static int live_noa_gpr(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct i915_perf_stream *stream;
+ struct intel_context *ce;
+ struct i915_request *rq;
+ u32 *cs, *store;
+ void *scratch;
+ u32 gpr0;
+ int err;
+ int i;
+
+ /* Check that the delay does not clobber user context state (GPR) */
+
+ stream = test_stream(>perf);
+ if (!stream)
+ return -ENOMEM;
+
+ gpr0 = i915_mmio_reg_offset(GEN8_RING_CS_GPR(stream->engine->mmio_base,
0));
+
+ ce = intel_context_create(stream->engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ goto out;
+ }
+
+ scratch = kmap(ce->vm->scratch[0].base.page);
+ memset(scratch, POISON_FREE, PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_ce;
+ }
+ i915_request_get(rq);
+
+ if (rq->engine->emit_init_breadcrumb) {
+ err = rq->engine->emit_init_breadcrumb(rq);
+ if (err) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+ }
+
+ cs = intel_ring_begin(rq, 2 * 32 + 2);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ *cs++ = MI_LOAD_REGISTER_IMM(32);
+ for (i = 0; i < 32; i++) {
+ *cs++ = gpr0 + i * sizeof(u32);
+ *cs++ = STACK_MAGIC;
+ }
+ *cs++ = MI_NOOP;
+ intel_ring_advance(rq, cs);
+
+ err = rq->engine->emit_bb_start(rq,
+ i915_ggtt_offset(stream->noa_wait), 0,
+ I915_DISPATCH_SECURE);
+ if (err) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ store = memset32(rq->engine->status_page.addr + 512, 0, 32);
+ for (i = 0; i < 32; i++) {
+ u32 cmd;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ cmd = MI_STORE_REGISTER_MEM;
+ if (INTEL_GEN(i915) >= 8)
+ cmd++;
+ cmd |= MI_USE_GGTT;
+
+ *cs++ = cmd;
+ *cs++ = gpr0 + i * sizeof(u32);
+ *cs++ = i915_ggtt_offset(rq->engine->status_page.vma) +
+ offset_in_page(store) +
+ i * sizeof(u32);
+ *cs++ = 0;
+ intel_ring_advance(rq, cs);
+ }
+
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE, HZ / 2) < 0) {
+ intel_gt_set_wedged(stream->engine->gt);
+ err = -EIO;
+ goto out_rq;
+ }
+
+ for (i = 0; i < 32; i++) {
+ if (store[i] == STACK_MAGIC)
+ continue;
+
+ pr_err("GPR[%d] lost, found:%08x, expected:%08x!\n",
+ i, store[i], STACK_MAGIC);
+ err = -EINVAL;
+ }
+
+ if (memchr_inv(scratch, POISON_FREE, PAGE_SIZE)) {
+ pr_err("scratch page overwritten!\n");
+ igt_hexdump(scratch, 4096);
+ err = -EINVAL;
+ }
+
+out_rq:
+ i915_request_put(rq);
+out_ce:
+ kunmap(ce->vm->scratch[0].base.page);
+ intel_context_put(ce);
+out:
+ stream_destroy(stream);
+ return err;
+}
+
int i915_perf_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
SUBTEST(live_sanitycheck),
SUBTEST(live_noa_delay),
+ SUBTEST(live_noa_gpr),
};
struct i915_perf *perf = >perf;
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/perf: Use GTT when saving/restoring engine GPR
== Series Details == Series: series starting with [CI,1/2] drm/i915/perf: Use GTT when saving/restoring engine GPR URL : https://patchwork.freedesktop.org/series/79320/ State : success == Summary == CI Bug Log - changes from CI_DRM_8724_full -> Patchwork_18130_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18130_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2079]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-kbl3/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-kbl3/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-kbl4/igt@gem_exec_par...@invalid-fence-in.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-kbl2/igt@gem_exec_par...@invalid-fence-in.html * igt@i915_suspend@sysfs-reader: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-kbl4/igt@i915_susp...@sysfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-kbl7/igt@i915_susp...@sysfs-reader.html * igt@kms_color@pipe-a-ctm-red-to-blue: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#129]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl1/igt@kms_co...@pipe-a-ctm-red-to-blue.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-skl1/igt@kms_co...@pipe-a-ctm-red-to-blue.html * igt@kms_color@pipe-b-ctm-negative: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +12 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl8/igt@kms_co...@pipe-b-ctm-negative.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-skl3/igt@kms_co...@pipe-b-ctm-negative.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +15 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_crc@pipe-b-cursor-256x85-onscreen: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-256x85-onscreen.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-256x85-onscreen.html * igt@kms_cursor_edge_walk@pipe-b-128x128-left-edge: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-glk6/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-glk7/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][17] -> [FAIL][18] ([IGT#5]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-skl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-rgb565-render-ytiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-apl4/igt@kms_draw_...@draw-method-rgb565-render-ytiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-apl3/igt@kms_draw_...@draw-method-rgb565-render-ytiled.html * igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a1: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-glk7/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/shard-glk8/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-tglb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-tglb1/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-gtt.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag
== Series Details == Series: series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag URL : https://patchwork.freedesktop.org/series/79316/ State : success == Summary == CI Bug Log - changes from CI_DRM_8724_full -> Patchwork_18128_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18128_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@kms: - shard-glk: [PASS][1] -> [TIMEOUT][2] ([i915#1383] / [i915#1958] / [i915#2119]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-glk9/igt@gem_...@kms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-glk8/igt@gem_...@kms.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-kbl4/igt@gem_exec_par...@invalid-fence-in.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-kbl7/igt@gem_exec_par...@invalid-fence-in.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / [i915#95]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-glk2/igt@kms_big...@linear-64bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#1635] / [i915#95]) +16 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_edge_walk@pipe-b-128x128-left-edge: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-glk6/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-glk4/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html * igt@kms_flip@dpms-vs-vblank-race@a-hdmi-a1: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#407]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-glk7/igt@kms_flip@dpms-vs-vblank-r...@a-hdmi-a1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-glk7/igt@kms_flip@dpms-vs-vblank-r...@a-hdmi-a1.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-skl2/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-kbl4/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu: - shard-tglb: [PASS][17] -> [SKIP][18] ([i915#668]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-tglb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#49]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl4/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-skl2/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-blt.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#1188]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl6/igt@kms_...@bpc-switch.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/shard-skl10/igt@kms_...@bpc-switch.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: Use GTT when saving/restoring engine GPR
== Series Details == Series: drm/i915/perf: Use GTT when saving/restoring engine GPR URL : https://patchwork.freedesktop.org/series/79311/ State : success == Summary == CI Bug Log - changes from CI_DRM_8723_full -> Patchwork_18127_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18127_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#93] / [i915#95]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-kbl4/igt@gem_exec_par...@invalid-fence-in.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-kbl6/igt@gem_exec_par...@invalid-fence-in.html * igt@gem_exec_whisper@basic-forked-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-glk7/igt@gem_exec_whis...@basic-forked-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-glk4/igt@gem_exec_whis...@basic-forked-all.html * igt@i915_module_load@reload: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-tglb7/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-tglb8/igt@i915_module_l...@reload.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-iclb8/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-iclb4/igt@i915_pm...@dc6-psr.html * igt@kms_color@pipe-c-ctm-negative: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-skl8/igt@kms_co...@pipe-c-ctm-negative.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-skl10/igt@kms_co...@pipe-c-ctm-negative.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: [PASS][13] -> [FAIL][14] ([IGT#5]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-kbl4/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html * igt@kms_frontbuffer_tracking@basic: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-glk1/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-glk7/igt@kms_frontbuffer_track...@basic.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-mmap-wc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-tglb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-mmap-wc.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#1188]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-skl5/igt@kms_...@bpc-switch.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-skl7/igt@kms_...@bpc-switch.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/perf: Use GTT when saving/restoring engine GPR
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/perf: Use GTT when
saving/restoring engine GPR
URL : https://patchwork.freedesktop.org/series/79320/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8724 -> Patchwork_18130
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/index.html
Known issues
Here are the changes found in Patchwork_18130 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-y/igt@gem_flink_ba...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-byt-j1900/igt@i915_pm_...@module-reload.html
- fi-glk-dsi: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/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: [PASS][11] -> [DMESG-WARN][12] ([i915#402])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-tgl-y/igt@prime_v...@basic-fence-flip.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_8724/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-plain-flip@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +1 similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18130/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
* igt@prime_vgem@basic-fence-flip:
-
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftest: Check that GPR are restored across noa_wait
== Series Details == Series: drm/i915/selftest: Check that GPR are restored across noa_wait URL : https://patchwork.freedesktop.org/series/79317/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8724 -> Patchwork_18129 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18129 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18129, 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_18129/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18129: ### IGT changes ### Possible regressions * igt@i915_selftest@live@perf: - fi-kbl-8809g: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-kbl-8809g/igt@i915_selftest@l...@perf.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-kbl-8809g/igt@i915_selftest@l...@perf.html - fi-kbl-soraka: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-kbl-soraka/igt@i915_selftest@l...@perf.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-kbl-soraka/igt@i915_selftest@l...@perf.html - fi-kbl-guc: [PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-kbl-guc/igt@i915_selftest@l...@perf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-kbl-guc/igt@i915_selftest@l...@perf.html - fi-cml-u2: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-cml-u2/igt@i915_selftest@l...@perf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-cml-u2/igt@i915_selftest@l...@perf.html - fi-whl-u: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-whl-u/igt@i915_selftest@l...@perf.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-whl-u/igt@i915_selftest@l...@perf.html - fi-icl-y: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-icl-y/igt@i915_selftest@l...@perf.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-icl-y/igt@i915_selftest@l...@perf.html - fi-bxt-dsi: [PASS][13] -> [DMESG-FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-bxt-dsi/igt@i915_selftest@l...@perf.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-bxt-dsi/igt@i915_selftest@l...@perf.html - fi-cfl-guc: [PASS][15] -> [DMESG-FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-cfl-guc/igt@i915_selftest@l...@perf.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-cfl-guc/igt@i915_selftest@l...@perf.html - fi-cml-s: [PASS][17] -> [DMESG-FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-cml-s/igt@i915_selftest@l...@perf.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-cml-s/igt@i915_selftest@l...@perf.html - fi-skl-guc: [PASS][19] -> [DMESG-FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-skl-guc/igt@i915_selftest@l...@perf.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-skl-guc/igt@i915_selftest@l...@perf.html - fi-tgl-u2: [PASS][21] -> [DMESG-FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-u2/igt@i915_selftest@l...@perf.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-tgl-u2/igt@i915_selftest@l...@perf.html - fi-bsw-n3050: [PASS][23] -> [DMESG-FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-bsw-n3050/igt@i915_selftest@l...@perf.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-bsw-n3050/igt@i915_selftest@l...@perf.html - fi-bsw-kefka: [PASS][25] -> [DMESG-FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-bsw-kefka/igt@i915_selftest@l...@perf.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-bsw-kefka/igt@i915_selftest@l...@perf.html - fi-tgl-y: [PASS][27] -> [DMESG-FAIL][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-y/igt@i915_selftest@l...@perf.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18129/fi-tgl-y/igt@i915_selftest@l...@perf.html - fi-cfl-8700k: [PASS][29] -> [DMESG-FAIL][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-cfl-8700k/igt@i915_selftest@l...@perf.html [30]:
[Intel-gfx] [CI 2/2] drm/i915/selftest: Check that GPR are restored across noa_wait
Perf implements a GPU delay (noa_wait) by looping until the CS timestamp
has passed a certain point. This use MI_MATH and the general purpose
registers of the user's context, and since it is clobbering the user
state it must carefully save and restore the user's data around the
noa_wait. We can verify this by loading some values in the GPR that we
know will be clobbered the noa_wait, and then inspecting the GPR after
the noa_wait completes and confirming that have been restored.
Signed-off-by: Chris Wilson
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 124 +
1 file changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index be54570c407c..be63cfe82feb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -280,11 +280,135 @@ static int live_noa_delay(void *arg)
return err;
}
+static int live_noa_gpr(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct i915_perf_stream *stream;
+ struct intel_context *ce;
+ struct i915_request *rq;
+ u32 *cs, *store;
+ void *scratch;
+ u32 gpr0;
+ int err;
+ int i;
+
+ /* Check that the delay does not clobber user context state (GPR) */
+
+ stream = test_stream(>perf);
+ if (!stream)
+ return -ENOMEM;
+
+ gpr0 = i915_mmio_reg_offset(GEN8_RING_CS_GPR(stream->engine->mmio_base,
0));
+
+ ce = intel_context_create(stream->engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ goto out;
+ }
+
+ scratch = kmap(ce->vm->scratch[0].base.page);
+ memset(scratch, POISON_FREE, PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_ce;
+ }
+ i915_request_get(rq);
+
+ if (rq->engine->emit_init_breadcrumb) {
+ err = rq->engine->emit_init_breadcrumb(rq);
+ if (err) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+ }
+
+ cs = intel_ring_begin(rq, 2 * 32 + 2);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ *cs++ = MI_LOAD_REGISTER_IMM(32);
+ for (i = 0; i < 32; i++) {
+ *cs++ = gpr0 + i * sizeof(u32);
+ *cs++ = STACK_MAGIC;
+ }
+ *cs++ = MI_NOOP;
+ intel_ring_advance(rq, cs);
+
+ err = rq->engine->emit_bb_start(rq,
+ i915_ggtt_offset(stream->noa_wait), 0,
+ I915_DISPATCH_SECURE);
+ if (err) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ store = memset32(rq->engine->status_page.addr + 512, 0, 32);
+ for (i = 0; i < 32; i++) {
+ u32 cmd;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ cmd = MI_STORE_REGISTER_MEM;
+ if (INTEL_GEN(i915) >= 8)
+ cmd++;
+ cmd |= MI_USE_GGTT;
+
+ *cs++ = cmd;
+ *cs++ = gpr0 + i * sizeof(u32);
+ *cs++ = i915_ggtt_offset(rq->engine->status_page.vma) +
+ offset_in_page(store) +
+ i * sizeof(u32);
+ *cs++ = 0;
+ intel_ring_advance(rq, cs);
+ }
+
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE, HZ / 2) < 0) {
+ intel_gt_set_wedged(stream->engine->gt);
+ err = -EIO;
+ goto out_rq;
+ }
+
+ for (i = 0; i < 32; i++) {
+ if (store[i] == STACK_MAGIC)
+ continue;
+
+ pr_err("GPR[%d] lost, found:%08x, expected:%08x!\n",
+ i, store[i], STACK_MAGIC);
+ err = -EINVAL;
+ }
+
+ if (memchr_inv(scratch, POISON_FREE, PAGE_SIZE)) {
+ pr_err("scratch page overwritten!\n");
+ igt_hexdump(scratch, 4096);
+ err = -EINVAL;
+ }
+
+out_rq:
+ i915_request_put(rq);
+out_ce:
+ kunmap(ce->vm->scratch[0].base.page);
+ intel_context_put(ce);
+out:
+ stream_destroy(stream);
+ return err;
+}
+
int i915_perf_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
SUBTEST(live_sanitycheck),
SUBTEST(live_noa_delay),
+ SUBTEST(live_noa_gpr),
};
struct i915_perf *perf = >perf;
int err;
--
2.20.1
___
Intel-gfx mailing list
[Intel-gfx] [CI 1/2] drm/i915/perf: Use GTT when saving/restoring engine GPR
From: Umesh Nerlige Ramappa
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
translation to use when saving restoring the engine general purpose
registers to and from the GT scratch. Since GT scratch is mapped to
ggtt, we need to set an additional bit in the command to use GTT.
Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
configurations")
Suggested-by: Prathap Kumar Valsan
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index de69d430b1ed..c6f6370283cf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
u32 d;
cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
+ cmd |= MI_SRM_LRM_GLOBAL_GTT;
if (INTEL_GEN(stream->perf->i915) >= 8)
cmd++;
--
2.20.1
___
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 [CI,1/6] drm/i915: Add has_master_unit_irq flag
== Series Details == Series: series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag URL : https://patchwork.freedesktop.org/series/79316/ State : success == Summary == CI Bug Log - changes from CI_DRM_8724 -> Patchwork_18128 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/index.html Known issues Here are the changes found in Patchwork_18128 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@basic: - 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_8724/fi-tgl-y/igt@gem_flink_ba...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-glk-dsi/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@flip: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-y/igt@kms_busy@ba...@flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-tgl-y/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Possible fixes * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@kms_frontbuffer_tracking@basic: - fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html * igt@prime_vgem@basic-fence-flip: - 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_8724/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-tgl-y/igt@prime_v...@basic-fence-flip.html Warnings * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) -> [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][18] ([i915#62] / [i915#92]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8724/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18128/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (43 -> 37) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_8724 -> Patchwork_18128 CI-20190529: 20190529 CI_DRM_8724: 0165f1cb39da5c3253af7f640a886484f7846089 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5729: a048d54f58dd70b07dbeb4541b273ec230ddb586 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18128: 61af7546dbe0eff40180611a118b495f8024993c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 61af7546dbe0 drm/i915/dg1: Add fake PCH c618720612b5 drm/i915/dg1: Remove SHPD_FILTER_CNT
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Optimise aliasing-ppgtt allocations
== Series Details == Series: drm/i915/gt: Optimise aliasing-ppgtt allocations URL : https://patchwork.freedesktop.org/series/79307/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8721_full -> Patchwork_18126_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18126_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18126_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_18126_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues-forked-all: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-iclb1/igt@gem_exec_whis...@basic-queues-forked-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-iclb7/igt@gem_exec_whis...@basic-queues-forked-all.html Known issues Here are the changes found in Patchwork_18126_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-kbl6/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-kbl4/igt@gem_exec_par...@invalid-fence-in.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-kbl1/igt@gem_exec_par...@invalid-fence-in.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#198] / [i915#2110]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-skl3/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-skl10/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@y-tiled-16bpp-rotate-0: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-skl9/igt@kms_big...@y-tiled-16bpp-rotate-0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-skl5/igt@kms_big...@y-tiled-16bpp-rotate-0.html * igt@kms_color@pipe-a-ctm-red-to-blue: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#129]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-skl9/igt@kms_co...@pipe-a-ctm-red-to-blue.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-skl5/igt@kms_co...@pipe-a-ctm-red-to-blue.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / [i915#95]) +25 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html - shard-kbl: [PASS][15] -> [DMESG-FAIL][16] ([i915#54] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_crc@pipe-a-cursor-256x256-random: - shard-snb: [PASS][17] -> [TIMEOUT][18] ([i915#1958] / [i915#2119]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-256x256-random.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-snb4/igt@kms_cursor_...@pipe-a-cursor-256x256-random.html * igt@kms_cursor_edge_walk@pipe-b-128x128-left-edge: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-glk1/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/shard-glk4/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html * igt@kms_cursor_legacy@cursora-vs-flipa-varying-size: - shard-snb: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/shard-snb4/igt@kms_cursor_leg...@cursora-vs-flipa-varying-size.html [22]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag
== Series Details == Series: series starting with [CI,1/6] drm/i915: Add has_master_unit_irq flag URL : https://patchwork.freedesktop.org/series/79316/ State : warning == Summary == $ dim checkpatch origin/drm-tip e4cf5d2b2a11 drm/i915: Add has_master_unit_irq flag 343e6cd5cf65 drm/i915/dg1: add initial DG-1 definitions -:45: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #45: FILE: drivers/gpu/drm/i915/i915_drv.h:1566: +#define IS_DG1_REVID(p, since, until) \ + (IS_DG1(p) && IS_REVID(p, since, until)) total: 0 errors, 0 warnings, 1 checks, 53 lines checked f1b701facb7b drm/i915/dg1: Add DG1 PCI IDs eac5d1d298b5 drm/i915/dg1: add support for the master unit interrupt c618720612b5 drm/i915/dg1: Remove SHPD_FILTER_CNT register programming 61af7546dbe0 drm/i915/dg1: Add fake PCH ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftest: Check that GPR are restored across noa_wait
Perf implements a GPU delay (noa_wait) by looping until the CS timestamp
has passed a certain point. This use MI_MATH and the general purpose
registers of the user's context, and since it is clobbering the user
state it must carefully save and restore the user's data around the
noa_wait. We can verify this by loading some values in the GPR that we
know will be clobbered the noa_wait, and then inspecting the GPR after
the noa_wait completes and confirming that have been restored.
Signed-off-by: Chris Wilson
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 124 +
1 file changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index be54570c407c..be63cfe82feb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -280,11 +280,135 @@ static int live_noa_delay(void *arg)
return err;
}
+static int live_noa_gpr(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct i915_perf_stream *stream;
+ struct intel_context *ce;
+ struct i915_request *rq;
+ u32 *cs, *store;
+ void *scratch;
+ u32 gpr0;
+ int err;
+ int i;
+
+ /* Check that the delay does not clobber user context state (GPR) */
+
+ stream = test_stream(>perf);
+ if (!stream)
+ return -ENOMEM;
+
+ gpr0 = i915_mmio_reg_offset(GEN8_RING_CS_GPR(stream->engine->mmio_base,
0));
+
+ ce = intel_context_create(stream->engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ goto out;
+ }
+
+ scratch = kmap(ce->vm->scratch[0].base.page);
+ memset(scratch, POISON_FREE, PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_ce;
+ }
+ i915_request_get(rq);
+
+ if (rq->engine->emit_init_breadcrumb) {
+ err = rq->engine->emit_init_breadcrumb(rq);
+ if (err) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+ }
+
+ cs = intel_ring_begin(rq, 2 * 32 + 2);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ *cs++ = MI_LOAD_REGISTER_IMM(32);
+ for (i = 0; i < 32; i++) {
+ *cs++ = gpr0 + i * sizeof(u32);
+ *cs++ = STACK_MAGIC;
+ }
+ *cs++ = MI_NOOP;
+ intel_ring_advance(rq, cs);
+
+ err = rq->engine->emit_bb_start(rq,
+ i915_ggtt_offset(stream->noa_wait), 0,
+ I915_DISPATCH_SECURE);
+ if (err) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ store = memset32(rq->engine->status_page.addr + 512, 0, 32);
+ for (i = 0; i < 32; i++) {
+ u32 cmd;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ goto out_rq;
+ }
+
+ cmd = MI_STORE_REGISTER_MEM;
+ if (INTEL_GEN(i915) >= 8)
+ cmd++;
+ cmd |= MI_USE_GGTT;
+
+ *cs++ = cmd;
+ *cs++ = gpr0 + i * sizeof(u32);
+ *cs++ = i915_ggtt_offset(rq->engine->status_page.vma) +
+ offset_in_page(store) +
+ i * sizeof(u32);
+ *cs++ = 0;
+ intel_ring_advance(rq, cs);
+ }
+
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE, HZ / 2) < 0) {
+ intel_gt_set_wedged(stream->engine->gt);
+ err = -EIO;
+ goto out_rq;
+ }
+
+ for (i = 0; i < 32; i++) {
+ if (store[i] == STACK_MAGIC)
+ continue;
+
+ pr_err("GPR[%d] lost, found:%08x, expected:%08x!\n",
+ i, store[i], STACK_MAGIC);
+ err = -EINVAL;
+ }
+
+ if (memchr_inv(scratch, POISON_FREE, PAGE_SIZE)) {
+ pr_err("scratch page overwritten!\n");
+ igt_hexdump(scratch, 4096);
+ err = -EINVAL;
+ }
+
+out_rq:
+ i915_request_put(rq);
+out_ce:
+ kunmap(ce->vm->scratch[0].base.page);
+ intel_context_put(ce);
+out:
+ stream_destroy(stream);
+ return err;
+}
+
int i915_perf_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
SUBTEST(live_sanitycheck),
SUBTEST(live_noa_delay),
+ SUBTEST(live_noa_gpr),
};
struct i915_perf *perf = >perf;
int err;
--
2.20.1
___
Intel-gfx mailing list
[Intel-gfx] [CI 5/6] drm/i915/dg1: Remove SHPD_FILTER_CNT register programming
From: Anusha Srivatsa Bspec asks us to remove the special programming of the SHPD_FILTER_CNT register which we have been doing since CNP+. Bspec: 49305 Cc: Matt Roper Signed-off-by: Anusha Srivatsa Signed-off-by: Lucas De Marchi Reviewed-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_irq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 4c9d0a4a2476..1fa67700d8f4 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -3114,7 +3114,8 @@ static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv, hotplug_irqs = sde_ddi_mask | sde_tc_mask; enabled_irqs = intel_hpd_enabled_irqs(dev_priv, dev_priv->hotplug.pch_hpd); - I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ); + if (INTEL_PCH_TYPE(dev_priv) <= PCH_TGP) + I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ); ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/6] drm/i915: Add has_master_unit_irq flag
From: Stuart Summers
Add flag to differentiate platforms with and without the master
IRQ control bit.
Signed-off-by: Stuart Summers
Signed-off-by: Lucas De Marchi
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 21bb9f7cc452..42a9b231556a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1598,6 +1598,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
(INTEL_INFO(dev_priv)->has_logical_ring_preemption)
+#define HAS_MASTER_UNIT_IRQ(dev_priv)
(INTEL_INFO(dev_priv)->has_master_unit_irq)
+
#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
#define INTEL_PPGTT(dev_priv) (INTEL_INFO(dev_priv)->ppgtt_type)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 242d00862b1a..71edb396b31a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -122,6 +122,7 @@ enum intel_ppgtt_type {
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
+ func(has_master_unit_irq); \
func(has_pooled_eu); \
func(has_rc6); \
func(has_rc6p); \
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/6] drm/i915/dg1: add support for the master unit interrupt
DG1 has master unit interrupt register which is used to indicate the
correct source of interrupt.
v2: fix coding style on register definition
Cc: Radhakrishna Sripada
Cc: Daniele Spurio Ceraolo
Cc: Matt Roper
Signed-off-by: Lucas De Marchi
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +++
drivers/gpu/drm/i915/i915_irq.c | 56 +++--
drivers/gpu/drm/i915/i915_reg.h | 4 +++
3 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 78ebede51fb3..784219962193 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -495,6 +495,10 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
seq_printf(m, "PCU interrupt enable:\t%08x\n",
I915_READ(GEN8_PCU_IER));
} else if (INTEL_GEN(dev_priv) >= 11) {
+ if (HAS_MASTER_UNIT_IRQ(dev_priv))
+ seq_printf(m, "Master Unit Interrupt Control: %08x\n",
+ I915_READ(DG1_MSTR_UNIT_INTR));
+
seq_printf(m, "Master Interrupt Control: %08x\n",
I915_READ(GEN11_GFX_MSTR_IRQ));
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 562b43ed077f..4c9d0a4a2476 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2584,6 +2584,46 @@ static irqreturn_t gen11_irq_handler(int irq, void *arg)
gen11_master_intr_enable);
}
+static u32 dg1_master_intr_disable_and_ack(void __iomem * const regs)
+{
+ u32 val;
+
+ /* First disable interrupts */
+ raw_reg_write(regs, DG1_MSTR_UNIT_INTR, 0);
+
+ /* Get the indication levels and ack the master unit */
+ val = raw_reg_read(regs, DG1_MSTR_UNIT_INTR);
+ if (unlikely(!val))
+ return 0;
+
+ raw_reg_write(regs, DG1_MSTR_UNIT_INTR, val);
+
+ /*
+* Now with master disabled, get a sample of level indications
+* for this interrupt and ack them right away - we keep GEN11_MASTER_IRQ
+* out as this bit doesn't exist anymore for DG1
+*/
+ val = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ) & ~GEN11_MASTER_IRQ;
+ if (unlikely(!val))
+ return 0;
+
+ raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, val);
+
+ return val;
+}
+
+static inline void dg1_master_intr_enable(void __iomem * const regs)
+{
+ raw_reg_write(regs, DG1_MSTR_UNIT_INTR, DG1_MSTR_IRQ);
+}
+
+static irqreturn_t dg1_irq_handler(int irq, void *arg)
+{
+ return __gen11_irq_handler(arg,
+ dg1_master_intr_disable_and_ack,
+ dg1_master_intr_enable);
+}
+
/* Called from drm generic code, passed 'crtc' which
* we use as a pipe index
*/
@@ -2920,7 +2960,10 @@ static void gen11_irq_reset(struct drm_i915_private
*dev_priv)
{
struct intel_uncore *uncore = _priv->uncore;
- gen11_master_intr_disable(dev_priv->uncore.regs);
+ if (HAS_MASTER_UNIT_IRQ(dev_priv))
+ dg1_master_intr_disable_and_ack(dev_priv->uncore.regs);
+ else
+ gen11_master_intr_disable(dev_priv->uncore.regs);
gen11_gt_irq_reset(_priv->gt);
gen11_display_irq_reset(dev_priv);
@@ -3517,8 +3560,13 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE);
- gen11_master_intr_enable(uncore->regs);
- POSTING_READ(GEN11_GFX_MSTR_IRQ);
+ if (HAS_MASTER_UNIT_IRQ(dev_priv)) {
+ dg1_master_intr_enable(uncore->regs);
+ POSTING_READ(DG1_MSTR_UNIT_INTR);
+ } else {
+ gen11_master_intr_enable(uncore->regs);
+ POSTING_READ(GEN11_GFX_MSTR_IRQ);
+ }
}
static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
@@ -4043,6 +4091,8 @@ static irq_handler_t intel_irq_handler(struct
drm_i915_private *dev_priv)
else
return i8xx_irq_handler;
} else {
+ if (HAS_MASTER_UNIT_IRQ(dev_priv))
+ return dg1_irq_handler;
if (INTEL_GEN(dev_priv) >= 11)
return gen11_irq_handler;
else if (INTEL_GEN(dev_priv) >= 8)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 86a23ced051b..4e796ff4d7d0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7733,6 +7733,10 @@ enum {
#define GEN11_GT_DW1_IRQ (1 << 1)
#define GEN11_GT_DW0_IRQ (1 << 0)
+#define DG1_MSTR_UNIT_INTR _MMIO(0x190008)
+#define DG1_MSTR_IRQ REG_BIT(31)
+#define DG1_MSTR_UNIT(u) REG_BIT(u)
+
#define GEN11_DISPLAY_INT_CTL
[Intel-gfx] [CI 2/6] drm/i915/dg1: add initial DG-1 definitions
From: Abdiel Janulgue
Bspec: 33617, 33617
v2: s/intel_dg1_info/dg1_info/ as done for other platforms before and
try to shut up compiler about ununsed variable that we know
shouldn't be used (Lucas)
Cc: José Roberto de Souza
Cc: Daniele Ceraolo Spurio
Cc: Stuart Summers
Cc: Vanshidhar Konda
Cc: Lucas De Marchi
Cc: Aravind Iddamsetty
Cc: Matt Roper
Signed-off-by: Abdiel Janulgue
Signed-off-by: Lucas De Marchi
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_pci.c | 12
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
4 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 42a9b231556a..1f5bc0369dbd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1430,6 +1430,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
#define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
#define IS_ROCKETLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
+#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
#define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
#define IS_BDW_ULT(dev_priv) \
@@ -1558,6 +1559,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define IS_RKL_REVID(p, since, until) \
(IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
+#define DG1_REVID_A0 0x0
+#define DG1_REVID_B0 0x1
+
+#define IS_DG1_REVID(p, since, until) \
+ (IS_DG1(p) && IS_REVID(p, since, until))
+
#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
#define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
#define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index db916fff3f0d..f4059c3de8af 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -897,8 +897,20 @@ static const struct intel_device_info rkl_info = {
#define GEN12_DGFX_FEATURES \
GEN12_FEATURES, \
+ .memory_regions = REGION_SMEM | REGION_LMEM, \
+ .has_master_unit_irq = 1, \
.is_dgfx = 1
+static const struct intel_device_info dg1_info __attribute__((__unused__)) = {
+ GEN12_DGFX_FEATURES,
+ PLATFORM(INTEL_DG1),
+ .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
+ .require_force_probe = 1,
+ .platform_engine_mask =
+ BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
+ BIT(VCS0) | BIT(VCS2),
+};
+
#undef GEN
#undef PLATFORM
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 3f5dc37d2b7c..40c590db3c76 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -64,6 +64,7 @@ static const char * const platform_names[] = {
PLATFORM_NAME(ELKHARTLAKE),
PLATFORM_NAME(TIGERLAKE),
PLATFORM_NAME(ROCKETLAKE),
+ PLATFORM_NAME(DG1),
};
#undef PLATFORM_NAME
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 71edb396b31a..fd2385457ab6 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -82,6 +82,7 @@ enum intel_platform {
/* gen12 */
INTEL_TIGERLAKE,
INTEL_ROCKETLAKE,
+ INTEL_DG1,
INTEL_MAX_PLATFORMS
};
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 6/6] drm/i915/dg1: Add fake PCH
DG1 has the south engine display on the same PCI device. Ideally we
could use HAS_PCH_SPLIT(), but that macro is misused all across the
code base to rather signify a range of gens. So add a fake one for DG1
to be used where needed.
Cc: Aditya Swarup
Signed-off-by: Lucas De Marchi
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_pch.c | 6 ++
drivers/gpu/drm/i915/intel_pch.h | 4
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index c668e99eb2e4..6c97192e9ca8 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -188,6 +188,12 @@ void intel_detect_pch(struct drm_i915_private *dev_priv)
{
struct pci_dev *pch = NULL;
+ /* DG1 has south engine display on the same PCI device */
+ if (IS_DG1(dev_priv)) {
+ dev_priv->pch_type = PCH_DG1;
+ return;
+ }
+
/*
* The reason to probe ISA bridge instead of Dev31:Fun0 is to
* make graphics device passthrough work easy for VMM, that only
diff --git a/drivers/gpu/drm/i915/intel_pch.h b/drivers/gpu/drm/i915/intel_pch.h
index 3053d1ce398b..06d2cd50af0b 100644
--- a/drivers/gpu/drm/i915/intel_pch.h
+++ b/drivers/gpu/drm/i915/intel_pch.h
@@ -26,6 +26,9 @@ enum intel_pch {
PCH_JSP,/* Jasper Lake PCH */
PCH_MCC,/* Mule Creek Canyon PCH */
PCH_TGP,/* Tiger Lake PCH */
+
+ /* Fake PCHs, functionality handled on the same PCI dev */
+ PCH_DG1 = 1024,
};
#define INTEL_PCH_DEVICE_ID_MASK 0xff80
@@ -56,6 +59,7 @@ enum intel_pch {
#define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
#define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
+#define HAS_PCH_DG1(dev_priv) (INTEL_PCH_TYPE(dev_priv) ==
PCH_DG1)
#define HAS_PCH_JSP(dev_priv) (INTEL_PCH_TYPE(dev_priv) ==
PCH_JSP)
#define HAS_PCH_MCC(dev_priv) (INTEL_PCH_TYPE(dev_priv) ==
PCH_MCC)
#define HAS_PCH_TGP(dev_priv) (INTEL_PCH_TYPE(dev_priv) ==
PCH_TGP)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/6] drm/i915/dg1: Add DG1 PCI IDs
From: Abdiel Janulgue Add the PCI ID for DG1, but keep it out of the table we use to register the driver. At this point we can't consider the driver ready to bind to the device since we basically miss support for everything. When more support is merged we can enable it to work partially for example as a display-only driver. v2: remove DG1 from the pci table and reword commit message (Lucas) Bspec: 44463 Cc: Matthew Auld Cc: James Ausmus Cc: Joonas Lahtinen Cc: Matt Roper Signed-off-by: Abdiel Janulgue Signed-off-by: Lucas De Marchi Reviewed-by: José Roberto de Souza # v1 Acked-by: Daniel Vetter --- include/drm/i915_pciids.h | 4 1 file changed, 4 insertions(+) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index d6cb28992ba0..96e408b4bdc9 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -618,4 +618,8 @@ INTEL_VGA_DEVICE(0x4C90, info), \ INTEL_VGA_DEVICE(0x4C9A, info) +/* DG1 */ +#define INTEL_DG1_IDS(info) \ + INTEL_VGA_DEVICE(0x4905, info) + #endif /* _I915_PCIIDS_H */ -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Use GTT when saving/restoring engine GPR
Quoting Lionel Landwerlin (2020-07-09 21:50:30)
> On 09/07/2020 23:46, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-07-09 21:42:39)
> >> On 09/07/2020 23:37, Chris Wilson wrote:
> >>> Quoting Umesh Nerlige Ramappa (2020-07-09 20:58:37)
> MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
> translation to use when saving restoring the engine general purpose
> registers to and from the GT scratch. Since GT scratch is mapped to
> ggtt, we need to set an additional bit in the command to use GTT.
>
> Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
> configurations")
> Suggested-by: Prathap Kumar Valsan
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/i915_perf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index de69d430b1ed..c6f6370283cf 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct
> i915_perf_stream *stream, u32 *cs,
> u32 d;
>
> cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
> + cmd |= MI_SRM_LRM_GLOBAL_GTT;
> >>> Indeed.
> >>>
> >>> For bonus points, please write a selftest to verify that the user's GPR
> >>> are restored. Something as simple as live_noa_delay, but instead of
> >>> measuring the time; submit a request to write telltales into the GPR,
> >>> submit a request to run noa_wait; then readback the telltales from a
> >>> final request.
> >>>
> >>> Now since the noa_wait is being run from the GGTT, the address space
> >>> selector should be reading from the GGTT. So I am actually curious as to
> >>> whether we have a bug or not.
> >>> -Chris
> >> I'm not super competent on the PPGTT setup, but I assumed this worked
> >> because we wrote into the ppgtt scratch page.
> > It's not a STORE_INDEX, it's writing to an absolute address based on the
> > address space selector which is a combination of the batch address space
> > and the command bits. Certainly the batch itself is read from the GGTT,
> > but I can't off hand remember the rules for the various MI (whether they
> > could even access ppGTT when launched from GGTT).
> > -Chris
>
> My understanding was that from a GGTT batch you could read/write into PPGTT.
>
> But not the other way around (obvisously).
>
> I thought the kernel mapped a page throughout the entire PPGTT space to
> prevent pagefaults. Is that not the case?
Yes, a readonly page, where supported.
Ah, now I understand you meant *that* scratch page as opposed to a
page we allocated for the purpose of saving per-context state like the
gt->scratch page.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 03/28] drm/i915/dg1: Add DG1 PCI IDs
On Thu, Jul 9, 2020 at 1:01 PM Lucas De Marchi
wrote:
>
> On Wed, Jul 1, 2020 at 11:01 PM kernel test robot wrote:
> >
> > Hi Lucas,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on drm-intel/for-linux-next]
> > [also build test ERROR on drm-tip/drm-tip next-20200701]
> > [cannot apply to v5.8-rc3]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use as documented in
> > https://git-scm.com/docs/git-format-patch]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Lucas-De-Marchi/Introduce-DG1/20200702-075819
> > base: git://anongit.freedesktop.org/drm-intel for-linux-next
> > config: i386-randconfig-m021-20200701 (attached as .config)
> > compiler: gcc-9 (Debian 9.3.0-14) 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 >>):
> >
> > >> drivers/gpu/drm/i915/i915_pci.c:903:39: error: 'dg1_info' defined but
> > >> not used [-Werror=unused-const-variable=]
> > 903 | static const struct intel_device_info dg1_info = {
> > | ^~~~
>
> This is intentionally left unused. Wonder what the fix would be...
> __attribute__(__unused__) or force the warning
> to be ignored here
>
> with or without this change I don't get a warning in gcc 10 (using
> the same config attached).
Adding W=1 to the command line and this is sufficient to shut up the warning.
Lucas De Marchi
>
> Lucas De Marchi
>
> >cc1: all warnings being treated as errors
> >
> > vim +/dg1_info +903 drivers/gpu/drm/i915/i915_pci.c
> >
> >896
> >897 #define GEN12_DGFX_FEATURES \
> >898 GEN12_FEATURES, \
> >899 .memory_regions = REGION_SMEM | REGION_LMEM, \
> >900 .has_master_unit_irq = 1, \
> >901 .is_dgfx = 1
> >902
> > > 903 static const struct intel_device_info dg1_info = {
> >904 GEN12_DGFX_FEATURES,
> >905 PLATFORM(INTEL_DG1),
> >906 .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) |
> > BIT(PIPE_D),
> >907 .require_force_probe = 1,
> >908 .engine_mask =
> >909 BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
> >910 BIT(VCS0) | BIT(VCS2),
> >911 };
> >912
> >
> > ---
> > 0-DAY CI Kernel Test Service, Intel Corporation
> > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Lucas De Marchi
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Use GTT when saving/restoring engine GPR
On 09/07/2020 23:46, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-07-09 21:42:39)
On 09/07/2020 23:37, Chris Wilson wrote:
Quoting Umesh Nerlige Ramappa (2020-07-09 20:58:37)
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
translation to use when saving restoring the engine general purpose
registers to and from the GT scratch. Since GT scratch is mapped to
ggtt, we need to set an additional bit in the command to use GTT.
Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
configurations")
Suggested-by: Prathap Kumar Valsan
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index de69d430b1ed..c6f6370283cf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
u32 d;
cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
+ cmd |= MI_SRM_LRM_GLOBAL_GTT;
Indeed.
For bonus points, please write a selftest to verify that the user's GPR
are restored. Something as simple as live_noa_delay, but instead of
measuring the time; submit a request to write telltales into the GPR,
submit a request to run noa_wait; then readback the telltales from a
final request.
Now since the noa_wait is being run from the GGTT, the address space
selector should be reading from the GGTT. So I am actually curious as to
whether we have a bug or not.
-Chris
I'm not super competent on the PPGTT setup, but I assumed this worked
because we wrote into the ppgtt scratch page.
It's not a STORE_INDEX, it's writing to an absolute address based on the
address space selector which is a combination of the batch address space
and the command bits. Certainly the batch itself is read from the GGTT,
but I can't off hand remember the rules for the various MI (whether they
could even access ppGTT when launched from GGTT).
-Chris
My understanding was that from a GGTT batch you could read/write into PPGTT.
But not the other way around (obvisously).
I thought the kernel mapped a page throughout the entire PPGTT space to
prevent pagefaults. Is that not the case?
-Lionel
___
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/perf: Use GTT when saving/restoring engine GPR
== Series Details ==
Series: drm/i915/perf: Use GTT when saving/restoring engine GPR
URL : https://patchwork.freedesktop.org/series/79311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8723 -> Patchwork_18127
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/index.html
Known issues
Here are the changes found in Patchwork_18127 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_8723/fi-tgl-u2/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-tgl-u2/igt@i915_module_l...@reload.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_8723/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@vgem_basic@mmap:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/fi-tgl-y/igt@vgem_ba...@mmap.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-tgl-y/igt@vgem_ba...@mmap.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_8723/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/fi-byt-j1900/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@vgem_basic@setversion:
- 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_8723/fi-tgl-y/igt@vgem_ba...@setversion.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-tgl-y/igt@vgem_ba...@setversion.html
Warnings
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8723/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 37)
--
Additional (1): fi-ehl-1
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8723 -> Patchwork_18127
CI-20190529: 20190529
CI_DRM_8723: 75a99370a8038a14e093b260cacbbdc4f7655e21 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5729: a048d54f58dd70b07dbeb4541b273ec230ddb586 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18127: 8d6f9a7b8cec4411fbb068775123b068e776b759 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8d6f9a7b8cec drm/i915/perf: Use GTT when saving/restoring engine GPR
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18127/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Use GTT when saving/restoring engine GPR
Quoting Lionel Landwerlin (2020-07-09 21:42:39)
> On 09/07/2020 23:37, Chris Wilson wrote:
> > Quoting Umesh Nerlige Ramappa (2020-07-09 20:58:37)
> >> MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
> >> translation to use when saving restoring the engine general purpose
> >> registers to and from the GT scratch. Since GT scratch is mapped to
> >> ggtt, we need to set an additional bit in the command to use GTT.
> >>
> >> Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
> >> configurations")
> >> Suggested-by: Prathap Kumar Valsan
> >> Signed-off-by: Umesh Nerlige Ramappa
> >> ---
> >> drivers/gpu/drm/i915/i915_perf.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> >> b/drivers/gpu/drm/i915/i915_perf.c
> >> index de69d430b1ed..c6f6370283cf 100644
> >> --- a/drivers/gpu/drm/i915/i915_perf.c
> >> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >> @@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct
> >> i915_perf_stream *stream, u32 *cs,
> >> u32 d;
> >>
> >> cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
> >> + cmd |= MI_SRM_LRM_GLOBAL_GTT;
> > Indeed.
> >
> > For bonus points, please write a selftest to verify that the user's GPR
> > are restored. Something as simple as live_noa_delay, but instead of
> > measuring the time; submit a request to write telltales into the GPR,
> > submit a request to run noa_wait; then readback the telltales from a
> > final request.
> >
> > Now since the noa_wait is being run from the GGTT, the address space
> > selector should be reading from the GGTT. So I am actually curious as to
> > whether we have a bug or not.
> > -Chris
>
> I'm not super competent on the PPGTT setup, but I assumed this worked
> because we wrote into the ppgtt scratch page.
It's not a STORE_INDEX, it's writing to an absolute address based on the
address space selector which is a combination of the batch address space
and the command bits. Certainly the batch itself is read from the GGTT,
but I can't off hand remember the rules for the various MI (whether they
could even access ppGTT when launched from GGTT).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Use GTT when saving/restoring engine GPR
On 09/07/2020 23:37, Chris Wilson wrote:
Quoting Umesh Nerlige Ramappa (2020-07-09 20:58:37)
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
translation to use when saving restoring the engine general purpose
registers to and from the GT scratch. Since GT scratch is mapped to
ggtt, we need to set an additional bit in the command to use GTT.
Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
configurations")
Suggested-by: Prathap Kumar Valsan
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index de69d430b1ed..c6f6370283cf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
u32 d;
cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
+ cmd |= MI_SRM_LRM_GLOBAL_GTT;
Indeed.
For bonus points, please write a selftest to verify that the user's GPR
are restored. Something as simple as live_noa_delay, but instead of
measuring the time; submit a request to write telltales into the GPR,
submit a request to run noa_wait; then readback the telltales from a
final request.
Now since the noa_wait is being run from the GGTT, the address space
selector should be reading from the GGTT. So I am actually curious as to
whether we have a bug or not.
-Chris
I'm not super competent on the PPGTT setup, but I assumed this worked
because we wrote into the ppgtt scratch page.
Potentially trashing an app VM space if it executes a reconfiguration.
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Use GTT when saving/restoring engine GPR
On 09/07/2020 22:58, Umesh Nerlige Ramappa wrote:
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
translation to use when saving restoring the engine general purpose
registers to and from the GT scratch. Since GT scratch is mapped to
ggtt, we need to set an additional bit in the command to use GTT.
Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
configurations")
Suggested-by: Prathap Kumar Valsan
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
Thanks a lot!
---
drivers/gpu/drm/i915/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index de69d430b1ed..c6f6370283cf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
u32 d;
cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
+ cmd |= MI_SRM_LRM_GLOBAL_GTT;
if (INTEL_GEN(stream->perf->i915) >= 8)
cmd++;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Use GTT when saving/restoring engine GPR
Quoting Umesh Nerlige Ramappa (2020-07-09 20:58:37)
> MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
> translation to use when saving restoring the engine general purpose
> registers to and from the GT scratch. Since GT scratch is mapped to
> ggtt, we need to set an additional bit in the command to use GTT.
>
> Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
> configurations")
> Suggested-by: Prathap Kumar Valsan
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/i915_perf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index de69d430b1ed..c6f6370283cf 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct
> i915_perf_stream *stream, u32 *cs,
> u32 d;
>
> cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
> + cmd |= MI_SRM_LRM_GLOBAL_GTT;
Indeed.
For bonus points, please write a selftest to verify that the user's GPR
are restored. Something as simple as live_noa_delay, but instead of
measuring the time; submit a request to write telltales into the GPR,
submit a request to run noa_wait; then readback the telltales from a
final request.
Now since the noa_wait is being run from the GGTT, the address space
selector should be reading from the GGTT. So I am actually curious as to
whether we have a bug or not.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: WARN if max vswing/pre-emphasis violates the DP spec
On Thu, 2020-07-09 at 17:58 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> According to the DP spec a DPTX must support vswing/pre-emphasis
> up to and including level 2. Level 3 is optional (actually DP 1.4a
> seems to make even level 3 mandatory for HBR2/3, while leaving it
> optional for RBR/HBR1).
>
> WARN if out encoders' .voltage_max()/.preemph_max() return
> an illegal value.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 2493142a70e9..a23ed7290843 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -52,6 +52,7 @@ static u8 dp_voltage_max(u8 preemph)
> void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> const u8 link_status[DP_LINK_STATUS_SIZE])
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 v = 0;
> u8 p = 0;
> int lane;
> @@ -64,12 +65,20 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> }
>
> preemph_max = intel_dp->preemph_max(intel_dp);
> + drm_WARN_ON_ONCE(>drm,
> + preemph_max != DP_TRAIN_PRE_EMPH_LEVEL_2 &&
> + preemph_max != DP_TRAIN_PRE_EMPH_LEVEL_3);
Okay matches but I guess the preemph_max function should receive as parameter
the voltage level to it return the max preemph of that voltage level,
no?
> +
> if (p >= preemph_max)
> p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
>
> v = min(v, dp_voltage_max(p));
>
> voltage_max = intel_dp->voltage_max(intel_dp);
> + drm_WARN_ON_ONCE(>drm,
> + voltage_max != DP_TRAIN_VOLTAGE_SWING_LEVEL_2 &&
> + voltage_max != DP_TRAIN_VOLTAGE_SWING_LEVEL_3);
> +
> if (v >= voltage_max)
> v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 03/28] drm/i915/dg1: Add DG1 PCI IDs
On Wed, Jul 1, 2020 at 11:01 PM kernel test robot wrote:
>
> Hi Lucas,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on drm-tip/drm-tip next-20200701]
> [cannot apply to v5.8-rc3]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Lucas-De-Marchi/Introduce-DG1/20200702-075819
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
> config: i386-randconfig-m021-20200701 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-14) 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 >>):
>
> >> drivers/gpu/drm/i915/i915_pci.c:903:39: error: 'dg1_info' defined but not
> >> used [-Werror=unused-const-variable=]
> 903 | static const struct intel_device_info dg1_info = {
> | ^~~~
This is intentionally left unused. Wonder what the fix would be...
__attribute__(__unused__) or force the warning
to be ignored here
with or without this change I don't get a warning in gcc 10 (using
the same config attached).
Lucas De Marchi
>cc1: all warnings being treated as errors
>
> vim +/dg1_info +903 drivers/gpu/drm/i915/i915_pci.c
>
>896
>897 #define GEN12_DGFX_FEATURES \
>898 GEN12_FEATURES, \
>899 .memory_regions = REGION_SMEM | REGION_LMEM, \
>900 .has_master_unit_irq = 1, \
>901 .is_dgfx = 1
>902
> > 903 static const struct intel_device_info dg1_info = {
>904 GEN12_DGFX_FEATURES,
>905 PLATFORM(INTEL_DG1),
>906 .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) |
> BIT(PIPE_D),
>907 .require_force_probe = 1,
>908 .engine_mask =
>909 BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
>910 BIT(VCS0) | BIT(VCS2),
>911 };
>912
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: Use GTT when saving/restoring engine GPR
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
translation to use when saving restoring the engine general purpose
registers to and from the GT scratch. Since GT scratch is mapped to
ggtt, we need to set an additional bit in the command to use GTT.
Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa
configurations")
Suggested-by: Prathap Kumar Valsan
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index de69d430b1ed..c6f6370283cf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,6 +1592,7 @@ static u32 *save_restore_register(struct i915_perf_stream
*stream, u32 *cs,
u32 d;
cmd = save ? MI_STORE_REGISTER_MEM : MI_LOAD_REGISTER_MEM;
+ cmd |= MI_SRM_LRM_GLOBAL_GTT;
if (INTEL_GEN(stream->perf->i915) >= 8)
cmd++;
--
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/selftests: Fix compare functions provided for sorting
== Series Details == Series: drm/i915/selftests: Fix compare functions provided for sorting URL : https://patchwork.freedesktop.org/series/79304/ State : success == Summary == CI Bug Log - changes from CI_DRM_8719_full -> Patchwork_18125_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18125_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2079]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl4/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-kbl2/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_endless@dispatch@rcs0: - shard-kbl: [PASS][3] -> [INCOMPLETE][4] ([i915#2119]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl2/igt@gem_exec_endless@dispa...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-kbl4/igt@gem_exec_endless@dispa...@rcs0.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl7/igt@gem_exec_par...@invalid-fence-in.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-kbl3/igt@gem_exec_par...@invalid-fence-in.html * igt@i915_selftest@mock@requests: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([i915#1635] / [i915#2110]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl3/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-apl4/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@y-tiled-16bpp-rotate-0: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +9 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_big...@y-tiled-16bpp-rotate-0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-skl9/igt@kms_big...@y-tiled-16bpp-rotate-0.html * igt@kms_color@pipe-a-ctm-red-to-blue: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#129]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_co...@pipe-a-ctm-red-to-blue.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-skl9/igt@kms_co...@pipe-a-ctm-red-to-blue.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / [i915#95]) +26 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@flip-vs-blocking-wf-vblank@a-edp1: - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2122]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-tglb2/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-tglb8/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-tglb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#49]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-wc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-wc.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_...@bpc-switch-dpms.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/shard-skl10/igt@kms_...@bpc-switch-dpms.html *
Re: [Intel-gfx] [PATCH v4 4/5] drm/i915/display: Implement HOBL
On Thu, 2020-07-09 at 17:24 +0300, Ville Syrjälä wrote:
> On Wed, Jul 08, 2020 at 01:55:11PM -0700, José Roberto de Souza wrote:
> > Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> > supported motherboards to use a special voltage swing table for eDP
> > panels that uses less power.
> >
> > So here if supported by HW, OEM will set it in VBT and i915 will try
> > to train link with HOBL vswing table if link training fails it fall
> > back to the original table.
> >
> > intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag
> > instead of do something like is done in intel_ddi_dp_voltage_max()
> > because it is only called after the first entry of the voltage swing
> > table was loaded so the HOBL flag is valid at that point.
> >
> > v3:
> > - removed a few parameters of icl_ddi_combo_vswing_program() that
> > can be taken from encoder(TODO)
> >
> > v4:
> > - using the HOBL vswing table until training fails completely (Ville)
> >
> > BSpec: 49291
> > BSpec: 49399
> > Cc: Ville Syrjälä
> > Cc: Animesh Manna
> > Cc: Manasi Navare
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 37 ---
> > .../drm/i915/display/intel_display_types.h| 2 +
> > .../drm/i915/display/intel_dp_link_training.c | 5 +++
> > drivers/gpu/drm/i915/i915_reg.h | 2 +
> > 4 files changed, 41 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 2c484b55bcdf..bf86c588f726 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -706,6 +706,15 @@ static const struct cnl_ddi_buf_trans
> > tgl_combo_phy_ddi_translations_dp_hbr2[] =
> > { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> > };
> >
> > +static const struct cnl_ddi_buf_trans
> > tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
> > + { 0x6, 0x7F, 0x3F, 0x00, 0x00 }
> > +};
> > +
> > +static bool is_hobl_buf_trans(const struct cnl_ddi_buf_trans *table)
> > +{
> > + return table == tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> > +}
> > +
> > static const struct ddi_buf_trans *
> > bdw_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
> > {
> > @@ -1050,6 +1059,16 @@ static const struct cnl_ddi_buf_trans *
> > tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> > int *n_entries)
> > {
> > + if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > + if (!intel_dp->hobl_disabled && rate <= 54) {
> > + /* Same table applies to TGL, RKL and DG1 */
> > + *n_entries =
> > ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> > + return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> > + }
> > + }
> > +
> > if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
> > return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
> > } else if (rate > 27) {
> > @@ -2223,13 +2242,12 @@ static u8 intel_ddi_dp_voltage_max(struct intel_dp
> > *intel_dp)
> > DP_TRAIN_VOLTAGE_SWING_MASK;
> > }
> >
> > -/*
> > - * We assume that the full set of pre-emphasis values can be
> > - * used on all DDI platforms. Should that change we need to
> > - * rethink this code.
> > - */
> > static u8 intel_ddi_dp_preemph_max(struct intel_dp *intel_dp)
> > {
> > + /* HOBL voltage swing table only have one entry */
> > + if (intel_dp->hobl_active)
> > + return DP_TRAIN_PRE_EMPH_LEVEL_0;
>
> That's illegal. We need to claim support for at least all
> vswing/pre-emphasis levels 0-2. 3 is optional. Though there is
> some confusion around this in the eDP spec where it kinda seems suggest
> that even some of the level 2 things are optional. But it's so unclear
> I would defer to just trusting what the DP spec says.
Okay so in this case I should add more entries to
tgl_combo_phy_ddi_translations_edp_hbr2_hobl with the same values to match the
minimum required by
DP spec?
>
> /me goes to write the patch with the WARNs...
Will take a look.
>
>
> > +
> > return DP_TRAIN_PRE_EMPH_LEVEL_3;
> > }
> >
> > @@ -2392,6 +2410,15 @@ static void icl_ddi_combo_vswing_program(struct
> > intel_encoder *encoder,
> > level = n_entries - 1;
> > }
> >
> > + if (INTEL_GEN(dev_priv) >= 12 && type == INTEL_OUTPUT_EDP) {
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > + val = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
> > + intel_dp->hobl_active = is_hobl_buf_trans(ddi_translations);
> > + intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), val,
> > +intel_dp->hobl_active ? val : 0);
> > + }
>
> I'd still
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/5] drm/i915/display: Replace drm_i915_private in voltage swing functions by intel_encoder (rev2)
On Thu, 2020-07-09 at 18:59 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v4,1/5] drm/i915/display: Replace > drm_i915_private in voltage swing functions by intel_encoder (rev2) > URL : https://patchwork.freedesktop.org/series/79265/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8719_full -> Patchwork_18124_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Pushed the 3 first patches to dinq, thanks for the reviews. > > > > Known issues > > > Here are the changes found in Patchwork_18124_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_persistence@engines-mixed-process@vecs0: > - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl6/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html > > * igt@gem_eio@kms: > - shard-snb: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-snb1/igt@gem_...@kms.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-snb6/igt@gem_...@kms.html > > * igt@gem_exec_balancer@bonded-early: > - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2079]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl4/igt@gem_exec_balan...@bonded-early.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-kbl6/igt@gem_exec_balan...@bonded-early.html > > * igt@gem_exec_params@invalid-fence-in: > - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / > [i915#95]) +4 similar issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl7/igt@gem_exec_par...@invalid-fence-in.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-kbl2/igt@gem_exec_par...@invalid-fence-in.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_8719/shard-glk3/igt@gem_exec_re...@basic-concurrent0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-glk5/igt@gem_exec_re...@basic-concurrent0.html > > * igt@i915_pm_backlight@fade_with_suspend: > - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#69]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl5/igt@i915_pm_backlight@fade_with_suspend.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-skl1/igt@i915_pm_backlight@fade_with_suspend.html > > * igt@i915_selftest@mock@requests: > - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([i915#1635] / > [i915#2110]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl3/igt@i915_selftest@m...@requests.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-apl2/igt@i915_selftest@m...@requests.html > > * igt@kms_big_fb@x-tiled-64bpp-rotate-0: > - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl3/igt@kms_big...@x-tiled-64bpp-rotate-0.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-apl2/igt@kms_big...@x-tiled-64bpp-rotate-0.html > > * igt@kms_big_fb@y-tiled-16bpp-rotate-0: > - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +8 > similar issues >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_big...@y-tiled-16bpp-rotate-0.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-skl2/igt@kms_big...@y-tiled-16bpp-rotate-0.html > > * igt@kms_big_fb@y-tiled-64bpp-rotate-0: > - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#118] / > [i915#95]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-glk6/igt@kms_big...@y-tiled-64bpp-rotate-0.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html > > * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: > - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / > [i915#95]) +15 similar issues >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html > > * igt@kms_cursor_crc@pipe-a-cursor-suspend: > - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +4 > similar issues >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Optimise aliasing-ppgtt allocations
== Series Details ==
Series: drm/i915/gt: Optimise aliasing-ppgtt allocations
URL : https://patchwork.freedesktop.org/series/79307/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8721 -> Patchwork_18126
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/index.html
Known issues
Here are the changes found in Patchwork_18126 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@flink-lifetime:
- 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_8721/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [PASS][5] -> [DMESG-FAIL][6] ([i915#1233])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-icl-y: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-icl-y/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-icl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][11] ([i915#95]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-whl-u/igt@i915_pm_backli...@basic-brightness.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_8721/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_addfb_basic@invalid-set-prop-any:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-tgl-y/igt@kms_addfb_ba...@invalid-set-prop-any.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-tgl-y/igt@kms_addfb_ba...@invalid-set-prop-any.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-kbl-7560u/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][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/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_18126/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][21] ([fdo#109271]) -> [DMESG-FAIL][22]
([i915#62])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8721/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-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_8721/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18126/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275:
[Intel-gfx] [CI] drm/i915/gt: Optimise aliasing-ppgtt allocations
Since the aliasing-ppgtt remains the default for gen6/gen7, it is worth
optimising the ppgtt allocation for it. In this case, we do not need to
flush the GGTT page directories entries as they are fixed during setup.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 05497b50103f..cdc0b9c54305 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -183,13 +183,11 @@ static int gen6_alloc_va_range(struct i915_address_space
*vm,
struct gen6_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
struct i915_page_directory * const pd = ppgtt->base.pd;
struct i915_page_table *pt, *alloc = NULL;
- intel_wakeref_t wakeref;
+ bool flush = false;
u64 from = start;
unsigned int pde;
int ret = 0;
- wakeref = intel_runtime_pm_get(>i915->runtime_pm);
-
spin_lock(>lock);
gen6_for_each_pde(pt, pd, start, length, pde) {
const unsigned int count = gen6_pte_count(start, length);
@@ -214,14 +212,20 @@ static int gen6_alloc_va_range(struct i915_address_space
*vm,
alloc = pt;
pt = pd->entry[pde];
}
+
+ flush = true;
}
atomic_add(count, >used);
}
spin_unlock(>lock);
- if (i915_vma_is_bound(ppgtt->vma, I915_VMA_GLOBAL_BIND))
- gen6_flush_pd(ppgtt, from, start);
+ if (flush && i915_vma_is_bound(ppgtt->vma, I915_VMA_GLOBAL_BIND)) {
+ intel_wakeref_t wakeref;
+
+ with_intel_runtime_pm(>i915->runtime_pm, wakeref)
+ gen6_flush_pd(ppgtt, from, start);
+ }
goto out;
@@ -230,7 +234,6 @@ static int gen6_alloc_va_range(struct i915_address_space
*vm,
out:
if (alloc)
free_px(vm, alloc);
- intel_runtime_pm_put(>i915->runtime_pm, wakeref);
return ret;
}
--
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 series starting with [v4,1/5] drm/i915/display: Replace drm_i915_private in voltage swing functions by intel_encoder (rev2)
== Series Details == Series: series starting with [v4,1/5] drm/i915/display: Replace drm_i915_private in voltage swing functions by intel_encoder (rev2) URL : https://patchwork.freedesktop.org/series/79265/ State : success == Summary == CI Bug Log - changes from CI_DRM_8719_full -> Patchwork_18124_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18124_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@vecs0: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl6/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html * igt@gem_eio@kms: - shard-snb: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-snb1/igt@gem_...@kms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-snb6/igt@gem_...@kms.html * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2079]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl4/igt@gem_exec_balan...@bonded-early.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-kbl6/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl7/igt@gem_exec_par...@invalid-fence-in.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-kbl2/igt@gem_exec_par...@invalid-fence-in.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_8719/shard-glk3/igt@gem_exec_re...@basic-concurrent0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-glk5/igt@gem_exec_re...@basic-concurrent0.html * igt@i915_pm_backlight@fade_with_suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#69]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl5/igt@i915_pm_backlight@fade_with_suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-skl1/igt@i915_pm_backlight@fade_with_suspend.html * igt@i915_selftest@mock@requests: - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([i915#1635] / [i915#2110]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl3/igt@i915_selftest@m...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-apl2/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl3/igt@kms_big...@x-tiled-64bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-apl2/igt@kms_big...@x-tiled-64bpp-rotate-0.html * igt@kms_big_fb@y-tiled-16bpp-rotate-0: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_big...@y-tiled-16bpp-rotate-0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-skl2/igt@kms_big...@y-tiled-16bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#118] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-glk6/igt@kms_big...@y-tiled-64bpp-rotate-0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#95]) +15 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +4 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html - shard-glk: [PASS][25] -> [FAIL][26] ([i915#54]) [25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: WARN if max vswing/pre-emphasis violates the DP spec
== Series Details == Series: drm/i915: WARN if max vswing/pre-emphasis violates the DP spec URL : https://patchwork.freedesktop.org/series/79299/ State : success == Summary == CI Bug Log - changes from CI_DRM_8719_full -> Patchwork_18123_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18123_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2079]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl4/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-kbl4/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl7/igt@gem_exec_par...@invalid-fence-in.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-kbl2/igt@gem_exec_par...@invalid-fence-in.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#1930]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-glk3/igt@gem_exec_re...@basic-concurrent0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html * igt@i915_selftest@mock@requests: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([i915#1635] / [i915#2110]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl3/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-apl3/igt@i915_selftest@m...@requests.html * igt@kms_color@pipe-a-ctm-red-to-blue: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#129]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_co...@pipe-a-ctm-red-to-blue.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-skl4/igt@kms_co...@pipe-a-ctm-red-to-blue.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +20 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-apl1/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_flip@2x-flip-vs-absolute-wf_vblank@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2122]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-glk8/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-glk2/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-blocking-wf-vblank@a-edp1: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2122]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-tglb2/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-tglb6/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#198]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl5/igt@kms_flip@flip-vs-susp...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-skl3/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-kbl6/igt@kms_flip@flip-vs-susp...@c-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_flip@plain-flip-fb-recreate@a-edp1: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#2122]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl4/igt@kms_flip@plain-flip-fb-recre...@a-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/shard-skl7/igt@kms_flip@plain-flip-fb-recre...@a-edp1.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#49]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-wc.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index (rev2)
== Series Details == Series: series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index (rev2) URL : https://patchwork.freedesktop.org/series/77699/ State : success == Summary == CI Bug Log - changes from CI_DRM_8708_full -> Patchwork_18081_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18081_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_read@short-buffer-block: - shard-skl: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-skl5/igt@drm_r...@short-buffer-block.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl10/igt@drm_r...@short-buffer-block.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-skl: [PASS][3] -> ([PASS][4], [FAIL][5]) ([i915#1528]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][6] -> ([FAIL][7], [FAIL][8]) ([i915#1930]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [PASS][9] -> ([DMESG-WARN][10], [DMESG-WARN][11]) ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk1/igt@gem_exec_whis...@basic-contexts-forked.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-glk: [PASS][12] -> ([INCOMPLETE][13], [PASS][14]) ([i915#58] / [k.org#198133]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk3/igt@gem_mmap_...@cpuset-big-copy-xy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk4/igt@gem_mmap_...@cpuset-big-copy-xy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk7/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_partial_pwrite_pread@writes-after-reads-snoop: - shard-glk: [PASS][15] -> ([DMESG-WARN][16], [PASS][17]) ([i915#118] / [i915#95]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk7/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk9/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk4/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html * igt@gem_unfence_active_buffers: - shard-kbl: [PASS][18] -> ([DMESG-WARN][19], [DMESG-WARN][20]) ([i915#93] / [i915#95]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-kbl1/igt@gem_unfence_active_buffers.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl6/igt@gem_unfence_active_buffers.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl7/igt@gem_unfence_active_buffers.html * igt@kms_color@pipe-a-gamma: - shard-skl: [PASS][21] -> ([PASS][22], [FAIL][23]) ([i915#71]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-skl5/igt@kms_co...@pipe-a-gamma.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl10/igt@kms_co...@pipe-a-gamma.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl8/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][24] -> ([DMESG-WARN][25], [PASS][26]) ([i915#180]) +6 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index (rev2)
== Series Details == Series: series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index (rev2) URL : https://patchwork.freedesktop.org/series/77699/ State : success == Summary == CI Bug Log - changes from CI_DRM_8708_full -> Patchwork_18081_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18081_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_read@short-buffer-block: - shard-skl: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-skl5/igt@drm_r...@short-buffer-block.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl10/igt@drm_r...@short-buffer-block.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-skl: [PASS][3] -> ([PASS][4], [FAIL][5]) ([i915#1528]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][6] -> ([FAIL][7], [FAIL][8]) ([i915#1930]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [PASS][9] -> ([DMESG-WARN][10], [DMESG-WARN][11]) ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk1/igt@gem_exec_whis...@basic-contexts-forked.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-glk: [PASS][12] -> ([PASS][13], [INCOMPLETE][14]) ([i915#58] / [k.org#198133]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk3/igt@gem_mmap_...@cpuset-big-copy-xy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk7/igt@gem_mmap_...@cpuset-big-copy-xy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk4/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_partial_pwrite_pread@writes-after-reads-snoop: - shard-glk: [PASS][15] -> ([DMESG-WARN][16], [PASS][17]) ([i915#118] / [i915#95]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-glk7/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk9/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-glk4/igt@gem_partial_pwrite_pr...@writes-after-reads-snoop.html * igt@gem_unfence_active_buffers: - shard-kbl: [PASS][18] -> ([DMESG-WARN][19], [DMESG-WARN][20]) ([i915#93] / [i915#95]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-kbl1/igt@gem_unfence_active_buffers.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl6/igt@gem_unfence_active_buffers.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl7/igt@gem_unfence_active_buffers.html * igt@kms_color@pipe-a-gamma: - shard-skl: [PASS][21] -> ([PASS][22], [FAIL][23]) ([i915#71]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-skl5/igt@kms_co...@pipe-a-gamma.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl10/igt@kms_co...@pipe-a-gamma.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-skl8/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][24] -> ([DMESG-WARN][25], [PASS][26]) ([i915#180]) +6 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix compare functions provided for sorting
== Series Details ==
Series: drm/i915/selftests: Fix compare functions provided for sorting
URL : https://patchwork.freedesktop.org/series/79304/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8719 -> Patchwork_18125
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/index.html
Known issues
Here are the changes found in Patchwork_18125 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@kms_psr@sprite_plane_onoff:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +2 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-y/igt@kms_psr@sprite_plane_onoff.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-tgl-y/igt@kms_psr@sprite_plane_onoff.html
* igt@vgem_basic@dmabuf-fence-before:
- 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_8719/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html
Possible fixes
* igt@i915_module_load@reload:
- fi-bxt-dsi: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bxt-dsi/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-bxt-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
- fi-glk-dsi: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [INCOMPLETE][17] ([i915#1932] / [i915#2045]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@hangcheck:
- fi-bsw-n3050: [INCOMPLETE][19] ([i915#1506]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-n3050/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-bsw-n3050/igt@i915_selftest@l...@hangcheck.html
* igt@kms_addfb_basic@addfb25-bad-modifier:
- fi-tgl-y: [DMESG-WARN][21] ([i915#402]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18125/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26]
[25]:
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Implement WAs 18011464164 and 22010931296
On Thu, 2020-07-09 at 04:12 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/tgl: Implement WAs 18011464164 and 22010931296 > URL : https://patchwork.freedesktop.org/series/79268/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_8717_full -> Patchwork_18117_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_18117_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_18117_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_18117_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_vblank@pipe-a-wait-busy: > - shard-hsw: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-hsw6/igt@kms_vbl...@pipe-a-wait-busy.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-hsw4/igt@kms_vbl...@pipe-a-wait-busy.html > Not related as this changes only touch GT and TGL. Pushed to dinq, thanks for the review. > > Known issues > > > Here are the changes found in Patchwork_18117_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_balancer@bonded-early: > - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#926]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-iclb4/igt@gem_exec_balan...@bonded-early.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-iclb4/igt@gem_exec_balan...@bonded-early.html > > * igt@gem_exec_fence@basic-wait-all: > - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / > [i915#95]) +12 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-apl3/igt@gem_exec_fe...@basic-wait-all.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-apl4/igt@gem_exec_fe...@basic-wait-all.html > > * igt@gem_exec_reloc@basic-concurrent0: > - shard-glk: [PASS][7] -> [FAIL][8] ([i915#1930]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-glk3/igt@gem_exec_re...@basic-concurrent0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-glk9/igt@gem_exec_re...@basic-concurrent0.html > > * igt@gem_exec_whisper@basic-contexts: > - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / > [i915#95]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-glk4/igt@gem_exec_whis...@basic-contexts.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-glk6/igt@gem_exec_whis...@basic-contexts.html > > * igt@i915_module_load@reload: > - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-tglb2/igt@i915_module_l...@reload.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-tglb8/igt@i915_module_l...@reload.html > > * igt@i915_suspend@forcewake: > - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#636] / > [i915#69]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-skl4/igt@i915_susp...@forcewake.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-skl2/igt@i915_susp...@forcewake.html > > * igt@kms_big_fb@linear-16bpp-rotate-0: > - shard-kbl: [PASS][15] -> [DMESG-FAIL][16] ([i915#95]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-kbl1/igt@kms_big...@linear-16bpp-rotate-0.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-kbl3/igt@kms_big...@linear-16bpp-rotate-0.html > - shard-apl: [PASS][17] -> [DMESG-FAIL][18] ([i915#1635] / > [i915#95]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-apl7/igt@kms_big...@linear-16bpp-rotate-0.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-apl4/igt@kms_big...@linear-16bpp-rotate-0.html > > * igt@kms_color@pipe-b-ctm-negative: > - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +7 > similar issues >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8717/shard-skl6/igt@kms_co...@pipe-b-ctm-negative.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18117/shard-skl2/igt@kms_co...@pipe-b-ctm-negative.html > > * igt@kms_cursor_crc@pipe-b-cursor-128x128-rapid-movement: > - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#93] / > [i915#95]) +1 similar issue >[21]: >
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix compare functions provided for sorting
Quoting Sudeep Holla (2020-07-09 16:49:31)
> Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value
> at those pointers. This will result in incorrect/unsorted list. Fix it
> by deferencing the pointers before comparison.
>
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> Signed-off-by: Sudeep Holla
> ---
> drivers/gpu/drm/i915/gt/selftest_rps.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Hi,
>
> I am not sure if I can put 2 fixes tags, but these are the ones affected.
>
> Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS")
> Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency
> measurement")
Might as well tag the fixes, just in case anyone wants to use the tests.
> I made similar mistake and after I fixed it, just looked if there are any
> similar bugs and found this.
>
> Regards,
> Sudeep
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c
> b/drivers/gpu/drm/i915/gt/selftest_rps.c
> index 5049c3dd08a6..c91981e75ebf 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_rps.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
> @@ -44,9 +44,9 @@ static int cmp_u64(const void *A, const void *B)
> {
> const u64 *a = A, *b = B;
>
> - if (a < b)
> + if (*a < *b)
> return -1;
> - else if (a > b)
> + else if (*a > *b)
> return 1;
Oh my golly gosh.
Thanks, thanks and thrice thanks.
Reviewed-by: Chris Wilson
I better double check all my qsort-compare funcs for similar brianfarts.
-Chris
___
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 [v4,1/5] drm/i915/display: Replace drm_i915_private in voltage swing functions by intel_encoder (rev2)
== Series Details ==
Series: series starting with [v4,1/5] drm/i915/display: Replace
drm_i915_private in voltage swing functions by intel_encoder (rev2)
URL : https://patchwork.freedesktop.org/series/79265/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8719 -> Patchwork_18124
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/index.html
Known issues
Here are the changes found in Patchwork_18124 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_store@basic:
- 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_8719/fi-tgl-y/igt@gem_exec_st...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-tgl-y/igt@gem_exec_st...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.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_8719/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
Possible fixes
* igt@i915_module_load@reload:
- fi-bxt-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bxt-dsi/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-bxt-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][11] ([i915#95]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [INCOMPLETE][15] ([i915#1932] / [i915#2045]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_pm:
- fi-apl-guc: [DMESG-FAIL][17] ([i915#1751]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-bsw-n3050: [INCOMPLETE][19] ([i915#1506]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-n3050/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-bsw-n3050/igt@i915_selftest@l...@hangcheck.html
* igt@kms_addfb_basic@addfb25-bad-modifier:
- fi-tgl-y: [DMESG-WARN][21] ([i915#402]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18124/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26]
[25]:
[Intel-gfx] [PATCH] drm/i915/selftests: Fix compare functions provided for sorting
Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value
at those pointers. This will result in incorrect/unsorted list. Fix it
by deferencing the pointers before comparison.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Sudeep Holla
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Hi,
I am not sure if I can put 2 fixes tags, but these are the ones affected.
Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS")
Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency
measurement")
I made similar mistake and after I fixed it, just looked if there are any
similar bugs and found this.
Regards,
Sudeep
diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index 5049c3dd08a6..c91981e75ebf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -44,9 +44,9 @@ static int cmp_u64(const void *A, const void *B)
{
const u64 *a = A, *b = B;
- if (a < b)
+ if (*a < *b)
return -1;
- else if (a > b)
+ else if (*a > *b)
return 1;
else
return 0;
@@ -56,9 +56,9 @@ static int cmp_u32(const void *A, const void *B)
{
const u32 *a = A, *b = B;
- if (a < b)
+ if (*a < *b)
return -1;
- else if (a > b)
+ else if (*a > *b)
return 1;
else
return 0;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea
Am 09.07.20 um 14:31 schrieb Daniel Vetter: On Thu, Jul 9, 2020 at 2:11 PM Daniel Stone wrote: On Thu, 9 Jul 2020 at 09:05, Daniel Vetter wrote: On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote: On Tue, 7 Jul 2020 at 21:13, Daniel Vetter wrote: Comes up every few years, gets somewhat tedious to discuss, let's write this down once and for all. Thanks for writing this up! I wonder if any of the notes from my reply to the previous-version thread would be helpful to more explicitly encode the carrot of dma-fence's positive guarantees, rather than just the stick of 'don't do this'. ;) Either way, this is: I think the carrot should go into the intro section for dma-fence, this section here is very much just the "don't do this" part. The previous patches have an attempt at encoding this a bit, maybe see whether there's a place for your reply (or parts of it) to fit? Sounds good to me. Acked-by: Daniel Stone What I'm not sure about is whether the text should be more explicit in flat out mandating the amdkfd eviction fences for long running compute workloads or workloads where userspace fencing is allowed. ... or whether we just say that you can never use dma-fence in conjunction with userptr. Uh userptr is entirely different thing. That one is ok. It's userpsace fences or gpu futexes or future fences or whatever we want to call them. Or is there some other confusion here?. I mean generating a dma_fence from a batch which will try to page in userptr. Given that userptr could be backed by absolutely anything at all, it doesn't seem smart to allow fences to rely on a pointer to an mmap'ed NFS file. So it seems like batches should be mutually exclusive between arbitrary SVM userptr and generating a dma-fence? Locking is Tricky (tm) but essentially what at least amdgpu does is pull in the backing storage before we publish any dma-fence. And then some serious locking magic to make sure that doesn't race with a core mm invalidation event. So for your case here the cs ioctl just blocks until the nfs pages are pulled in. Yeah, we had some iterations until all was settled. Basic idea is the following: 1. Have a sequence counter increased whenever a change to the page tables happens. 2. During CS grab the current value of this counter. 3. Get all the pages you need in an array. 4. Prepare CS, grab the low level lock the MM notifier waits for and double check the counter. 5. If the counter is still the same all is well and the DMA-fence pushed to the hardware. 6. If the counter has changed repeat. Can result in a nice live lock when you constantly page things in/out, but that is expected behavior. Christian. Once we've committed for the dma-fence it's only the other way round, i.e. core mm will stall on the dma-fence if it wants to throw out these pages again. More or less at least. That way we never have a dma-fence depending upon any core mm operations. The only pain here is that this severely limits what you can do in the critical path towards signalling a dma-fence, because the tldr is "no interacting with core mm at all allowed". Speaking of entirely different things ... the virtio-gpu bit really doesn't belong in this patch. Oops, dunno where I lost that as a sparate patch. Will split out again :-( -Daniel Cheers, Daniel ___ 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 [v4,1/5] drm/i915/display: Replace drm_i915_private in voltage swing functions by intel_encoder (rev2)
== Series Details == Series: series starting with [v4,1/5] drm/i915/display: Replace drm_i915_private in voltage swing functions by intel_encoder (rev2) URL : https://patchwork.freedesktop.org/series/79265/ 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:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +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/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +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 +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
Re: [Intel-gfx] [PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0
Hi,
On 7/9/20 4:50 PM, Andy Shevchenko wrote:
On Wed, Jul 08, 2020 at 11:14:22PM +0200, Hans de Goede wrote:
The datasheet specifies that programming the base_unit part of the
ctrl register to 0 results in a contineous low signal.
Adjust the get_state method to reflect this by setting pwm_state.period
to 1 and duty_cycle to 0.
...
+ if (freq == 0) {
+ /* In this case the PWM outputs a continous low signal */
+ state->period = 1;
I guess this should be something like half of the range (so base unit calc
will give 128). Because with period = 1 (too small) it will give too small
base unit (if apply) and as a result we get high frequency pulses.
You are right, that if after this the user only changes the duty-cycle
things will work very poorly, we will end up with a base_unit value of
e.g 65535 and then have almost no duty-cycle resolution at all.
How about using a value here which results in a base_unit value of
256 (for 16 bit base-unit registers), that is the highest frequency we
can do while still having full duty-cycle resolution and it also
is the power-on-reset value, so using a higher period which translates
to a base_unit value of 256 (the por calue) seems like a sensible thing to do.
Uwe what do you think about this?
Regards,
Hans
+ state->duty_cycle = 0;
+ } else {
state->period = NSEC_PER_SEC / (unsigned long)freq;
+ on_time_div *= state->period;
+ do_div(on_time_div, 255);
+ state->duty_cycle = on_time_div;
+ }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/20] drm/i915/gem: Reintroduce multiple passes for reloc processing
On 06/07/2020 07:19, Chris Wilson wrote:
The prospect of locking the entire submission sequence under a wide
ww_mutex re-imposes some key restrictions, in particular that we must
not call copy_(from|to)_user underneath the mutex (as the faulthandlers
themselves may need to take the ww_mutex). To satisfy this requirement,
we need to split the relocation handling into multiple phases again.
After dropping the reservations, we need to allocate enough buffer space
to both copy the relocations from userspace into, and serve as the
relocation command buffer. Once we have finished copying the
relocations, we can then re-aquire all the objects for the execbuf and
rebind them, including our new relocations objects. After we have bound
all the new and old objects into their final locations, we can then
convert the relocation entries into the GPU commands to update the
relocated vma. Finally, once it is all over and we have dropped the
ww_mutex for the last time, we can then complete the update of the user
relocation entries.
Good text. :)
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 842 --
.../i915/gem/selftests/i915_gem_execbuffer.c | 195 ++--
2 files changed, 520 insertions(+), 517 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 629b736adf2c..fbf5c5cd51ca 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -35,6 +35,7 @@ struct eb_vma {
/** This vma's place in the execbuf reservation list */
struct drm_i915_gem_exec_object2 *exec;
+ u32 bias;
struct list_head bind_link;
struct list_head unbound_link;
@@ -60,15 +61,12 @@ struct eb_vma_array {
#define __EXEC_OBJECT_HAS_PIN BIT(31)
#define __EXEC_OBJECT_HAS_FENCE BIT(30)
#define __EXEC_OBJECT_NEEDS_MAP BIT(29)
-#define __EXEC_OBJECT_NEEDS_BIAS BIT(28)
-#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 28) /* all of the above */
+#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 29) /* all of the above */
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_INTERNAL_FLAGS (~0u << 31)
#define UPDATEPIN_OFFSET_FIXED
-#define BATCH_OFFSET_BIAS (256*1024)
-
#define __I915_EXEC_ILLEGAL_FLAGS \
(__I915_EXEC_UNKNOWN_FLAGS | \
I915_EXEC_CONSTANTS_MASK | \
@@ -266,20 +264,18 @@ struct i915_execbuffer {
* obj/page
*/
struct reloc_cache {
- struct drm_mm_node node; /** temporary GTT binding */
unsigned int gen; /** Cached value of INTEL_GEN */
bool use_64bit_reloc : 1;
- bool has_llc : 1;
bool has_fence : 1;
bool needs_unfenced : 1;
struct intel_context *ce;
- struct i915_vma *target;
- struct i915_request *rq;
- struct i915_vma *rq_vma;
- u32 *rq_cmd;
- unsigned int rq_size;
+ struct eb_relocs_link {
+ struct i915_vma *vma;
+ } head;
+ struct drm_i915_gem_relocation_entry *map;
+ unsigned int pos;
It's not trivial so please add some commentary around the new struct
members. List handling (is there a single linked list in kernel which
could be used for clarity?). Or maybe it is not a list.. Why is a list
of vma links inside a mapped GEM bo? What are pos, bufsz, later max,
etc. So a bit of high level operation and a bit of per field. I think
it's needed because it is not straightforward.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for dma-fence annotations, round 3 (rev6)
== Series Details == Series: dma-fence annotations, round 3 (rev6) URL : https://patchwork.freedesktop.org/series/79212/ State : success == Summary == CI Bug Log - changes from CI_DRM_8718_full -> Patchwork_18122_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18122_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2079]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl4/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-kbl7/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl3/igt@gem_exec_par...@invalid-fence-in.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-kbl3/igt@gem_exec_par...@invalid-fence-in.html * igt@gem_fenced_exec_thrash@2-spare-fences: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +67 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-skl5/igt@gem_fenced_exec_thr...@2-spare-fences.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-skl2/igt@gem_fenced_exec_thr...@2-spare-fences.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-tglb7/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-tglb1/igt@i915_module_l...@reload.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] / [i915#95]) +27 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_edge_walk@pipe-b-128x128-left-edge: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-glk9/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-glk6/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html * igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-tglb7/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-tglb1/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl3/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-kbl3/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank@c-edp1: - shard-skl: [PASS][19] -> [DMESG-FAIL][20] ([i915#1982] / [i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-skl10/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-edp1: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#198]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-skl2/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/shard-skl5/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#2122]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: WARN if max vswing/pre-emphasis violates the DP spec
== Series Details == Series: drm/i915: WARN if max vswing/pre-emphasis violates the DP spec URL : https://patchwork.freedesktop.org/series/79299/ State : success == Summary == CI Bug Log - changes from CI_DRM_8719 -> Patchwork_18123 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/index.html Known issues Here are the changes found in Patchwork_18123 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@basic: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-y/igt@gem_flink_ba...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-tgl-y/igt@gem_flink_ba...@basic.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_8719/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Possible fixes * igt@i915_module_load@reload: - fi-bxt-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bxt-dsi/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-bxt-dsi/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-bsw-n3050/igt@i915_pm_...@module-reload.html - fi-glk-dsi: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-glk-dsi/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gem_contexts: - fi-tgl-u2: [INCOMPLETE][15] ([i915#1932] / [i915#2045]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@gt_pm: - fi-apl-guc: [DMESG-FAIL][17] ([i915#1751]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-apl-guc/igt@i915_selftest@live@gt_pm.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-apl-guc/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - fi-bsw-n3050: [INCOMPLETE][19] ([i915#1506]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-bsw-n3050/igt@i915_selftest@l...@hangcheck.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-bsw-n3050/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@addfb25-bad-modifier: - fi-tgl-y: [DMESG-WARN][21] ([i915#402]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-y: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8719/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18123/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-icl-u2: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26] [25]:
Re: [Intel-gfx] [PATCH v1] vfio/pci: Refine Intel IGD OpRegion support
On Fri, 10 Jul 2020 01:37:07 +0800
Fred Gao wrote:
> Bypass the IGD initialization for Intel's dgfx devices with own expansion
> ROM and the host/LPC bridge config space are no longer accessed.
>
> Cc: Zhenyu Wang
> Cc: Xiong Zhang
> Cc: Hang Yuan
> Cc: Stuart Summers
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Fred Gao
> ---
> drivers/vfio/pci/vfio_pci.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index f634c81998bb..0f4a34849836 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -28,6 +28,8 @@
> #include
> #include
>
> +#include
> +
> #include "vfio_pci_private.h"
>
> #define DRIVER_VERSION "0.2"
> @@ -60,6 +62,12 @@ module_param(enable_sriov, bool, 0644);
> MODULE_PARM_DESC(enable_sriov, "Enable support for SR-IOV configuration.
> Enabling SR-IOV on a PF typically requires support of the userspace PF
> driver, enabling VFs without such support may result in non-functional VFs or
> PF.");
> #endif
>
> +/* Intel's dgfx is not IGD, so don't handle them the same way */
> +static const struct pci_device_id intel_dgfx_pciids[] = {
> + INTEL_DG1_IDS(0),
> + { }
> +};
> +
> static inline bool vfio_vga_disabled(void)
> {
> #ifdef CONFIG_VFIO_PCI_VGA
> @@ -339,7 +347,8 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
>
> if (vfio_pci_is_vga(pdev) &&
> pdev->vendor == PCI_VENDOR_ID_INTEL &&
> - IS_ENABLED(CONFIG_VFIO_PCI_IGD)) {
> + IS_ENABLED(CONFIG_VFIO_PCI_IGD) &&
> + !pci_match_id(intel_dgfx_pciids, pdev)) {
> ret = vfio_pci_igd_init(vdev);
> if (ret) {
> pci_warn(pdev, "Failed to setup Intel IGD regions\n");
Do we need to maintain specific IDs or could we simply test whether the
device is on the root bus to determine if it is integrated or discrete?
A discrete device should be connected to a downstream port rather than
appear on the root bus. Thanks,
Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
Hi, On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote: > Hi, > > On 7/9/20 4:14 PM, Sam Ravnborg wrote: > > Hi Hans. > > > > On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote: > > > Hi All, > > > > > > Here is v4 of my patch series converting the i915 driver's code for > > > controlling the panel's backlight with an external PWM controller to > > > use the atomic PWM API. See below for the changelog. > > > > Why is it that i915 cannot use the pwm_bl driver for backlight? > > I have not studied the code - just wondering. > > The intel_panel.c code deals with 7 different types of PWM controllers > which are built into the GPU + support for external PWM controllers > through the kernel's PWM subsystem. > > pwm_bl will work for the external PWM controller case, but not for > the others. On top of that the intel_panel code integrates which > the video BIOS, getting things like frequency, minimum value > and if the range is inverted (0% duty == backlight brightness max). > I'm not even sure if pwm_bl supports all of this, but even if it > does the intel_panel code handles this in a unified manner for > all supported PWM controllers, including the ones which are > an integral part of the GPU. Thanks for the explanation. This is a more complicated world than the usual embedded case with a single pwm, no BIOS etc. So it makes sense. Sam > > Regards, > > Hans > > > > > > Initially the plan was for this series to consist of 2 parts: > > > 1. convert the pwm-crc driver to support the atomic PWM API and > > > 2. convert the i915 driver's PWM code to use the atomic PWM API. > > > > > > But during testing I've found a number of bugs in the pwm-lpss and I > > > found that the acpi_lpss code needs some special handling because of > > > some ugliness found in most Cherry Trail DSDTs. > > > > > > So now this series has grown somewhat large and consists of 4 parts: > > > > > > 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness > > > 2. various fixes to the pwm-lpss driver > > > 3. convert the pwm-crc driver to support the atomic PWM API and > > > 4. convert the i915 driver's PWM code to use the atomic PWM API > > > > > > The involved acpi_lpss and pwm drivers do not see a whole lot of churn, > > > so the plan is to merge this all through drm-intel-next-queued (dinq) > > > once all the patches are reviewed / have acks. > > > > > > In v4 the ACPI patches have been Acked by Rafael and the i915 patches > > > have been acked by Jani. So that just leaves the PWM patches. > > > > > > Uwe can I get your ok / ack for merging this through the dinq branch > > > once you have acked al the PWM patches ? > > > > > > This series has been tested (and re-tested after adding various bug-fixes) > > > extensively. It has been tested on the following devices: > > > > > > -Asus T100TA BYT + CRC-PMIC PWM > > > -Toshiba WT8-A BYT + CRC-PMIC PWM > > > -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM > > > -Asus T100HA CHT + CRC-PMIC PWM > > > -Terra Pad 1061 BYT + LPSS PWM > > > -Trekstor Twin 10.1 BYT + LPSS PWM > > > -Asus T101HA CHT + CRC-PMIC PWM > > > -GPD Pocket CHT + CRC-PMIC PWM > > > > > > Changelog: > > > > > > Changes in v2: > > > - Fix coverletter subject > > > - Drop accidentally included debugging patch > > > - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only > > > once ( > > >- Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX > > > > > > Changes in v3: > > > - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit > > > register value" > > >- Use base_unit_range - 1 as maximum value for the clamp() > > > - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state > > > on resume" > > >- This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the > > > PWM" > > > patch from previous versions of this patch-set, which really was a > > > hack > > > working around the resume issue which this patch fixes properly. > > > - PATCH v3 6 - 11 pwm-crc changes: > > >- Various small changes resulting from the reviews by Andy and Uwe, > > > including some refactoring of the patches to reduce the amount of > > > churn > > > in the patch-set > > > > > > Changes in v4: > > > - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == > > > 0" > > >- This is a new patch in v4 of this patchset > > > - "[PATCH v4 12/16] pwm: crc: Implement get_state() method" > > >- Use DIV_ROUND_UP when calculating the period and duty_cycle values > > > - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an > > > external PWM controller" > > >- Add a note to the commit message about the changes in > > > pwm_disable_backlight() > > >- Use the pwm_set/get_relative_duty_cycle() helpers > > > > > > Regards, > > > > > > Hans > > > > > > ___ > > > dri-devel mailing list > > >
[Intel-gfx] [PATCH] drm/i915: WARN if max vswing/pre-emphasis violates the DP spec
From: Ville Syrjälä
According to the DP spec a DPTX must support vswing/pre-emphasis
up to and including level 2. Level 3 is optional (actually DP 1.4a
seems to make even level 3 mandatory for HBR2/3, while leaving it
optional for RBR/HBR1).
WARN if out encoders' .voltage_max()/.preemph_max() return
an illegal value.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 2493142a70e9..a23ed7290843 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -52,6 +52,7 @@ static u8 dp_voltage_max(u8 preemph)
void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8 link_status[DP_LINK_STATUS_SIZE])
{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 v = 0;
u8 p = 0;
int lane;
@@ -64,12 +65,20 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
}
preemph_max = intel_dp->preemph_max(intel_dp);
+ drm_WARN_ON_ONCE(>drm,
+preemph_max != DP_TRAIN_PRE_EMPH_LEVEL_2 &&
+preemph_max != DP_TRAIN_PRE_EMPH_LEVEL_3);
+
if (p >= preemph_max)
p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
v = min(v, dp_voltage_max(p));
voltage_max = intel_dp->voltage_max(intel_dp);
+ drm_WARN_ON_ONCE(>drm,
+voltage_max != DP_TRAIN_VOLTAGE_SWING_LEVEL_2 &&
+voltage_max != DP_TRAIN_VOLTAGE_SWING_LEVEL_3);
+
if (v >= voltage_max)
v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
--
2.26.2
___
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/edid: Allow looking for ext blocks starting from a specified index (rev2)
== Series Details ==
Series: series starting with [1/3] drm/edid: Allow looking for ext blocks
starting from a specified index (rev2)
URL : https://patchwork.freedesktop.org/series/77699/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8708 -> Patchwork_18081
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/index.html
Known issues
Here are the changes found in Patchwork_18081 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@gem_flink_ba...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-apl-guc/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-bsw-kefka/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_pm:
- fi-cml-s: [PASS][9] -> [DMESG-FAIL][10] ([i915#2111])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-cml-s/igt@i915_selftest@live@gt_pm.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-cml-s/igt@i915_selftest@live@gt_pm.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][15] ([i915#1888]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_render_linear_blits@basic:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {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_8708/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-dsi/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_8708/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][26] ([i915#62] / [i915#92]) +1 similar issue
[25]:
Re: [Intel-gfx] [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value
On Thu, Jul 09, 2020 at 04:33:50PM +0200, Hans de Goede wrote: > On 7/9/20 4:21 PM, Andy Shevchenko wrote: > > On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote: ... > > You can use clamp_val(). > > I did not know about that, that will work nicely I will switch to clamp_val > for the next version. I assume it is ok to keep your Reviewed-by with this > very minor change? Sure. -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0
On Wed, Jul 08, 2020 at 11:14:22PM +0200, Hans de Goede wrote:
> The datasheet specifies that programming the base_unit part of the
> ctrl register to 0 results in a contineous low signal.
>
> Adjust the get_state method to reflect this by setting pwm_state.period
> to 1 and duty_cycle to 0.
...
> + if (freq == 0) {
> + /* In this case the PWM outputs a continous low signal */
> + state->period = 1;
I guess this should be something like half of the range (so base unit calc
will give 128). Because with period = 1 (too small) it will give too small
base unit (if apply) and as a result we get high frequency pulses.
> + state->duty_cycle = 0;
> + } else {
> state->period = NSEC_PER_SEC / (unsigned long)freq;
> + on_time_div *= state->period;
> + do_div(on_time_div, 255);
> + state->duty_cycle = on_time_div;
> + }
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915: Add a couple of missing i915_active_fini()
== Series Details == Series: series starting with [1/6] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/79297/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8718_full -> Patchwork_18121_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18121_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18121_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_18121_full: ### IGT changes ### Warnings * igt@runner@aborted: - shard-tglb: ([FAIL][1], [FAIL][2]) ([i915#2110]) -> ([FAIL][3], [FAIL][4], [FAIL][5]) ([i915#1602] / [i915#1764] / [i915#2110]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-tglb7/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-tglb8/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-tglb3/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-tglb8/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-tglb7/igt@run...@aborted.html ### Piglit changes ### Possible regressions * spec@glsl-1.50@execution@built-in-functions@gs-op-assign-div-ivec2-int (NEW): - pig-snb-2600: NOTRUN -> [FAIL][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/pig-snb-2600/spec@glsl-1.50@execution@built-in-functi...@gs-op-assign-div-ivec2-int.html New tests - New tests have been introduced between CI_DRM_8718_full and Patchwork_18121_full: ### New Piglit tests (1) ### * spec@glsl-1.50@execution@built-in-functions@gs-op-assign-div-ivec2-int: - Statuses : 1 fail(s) - Exec time: [0.11] s Known issues Here are the changes found in Patchwork_18121_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl3/igt@gem_exec_par...@invalid-fence-in.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-kbl3/igt@gem_exec_par...@invalid-fence-in.html * igt@i915_module_load@reload: - shard-tglb: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-tglb7/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-tglb8/igt@i915_module_l...@reload.html - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-apl2/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-apl3/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([i915#151]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-hsw7/igt@i915_pm_...@system-suspend-execbuf.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-hsw4/igt@i915_pm_...@system-suspend-execbuf.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-skl7/igt@i915_susp...@fence-restore-tiled2untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-skl9/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / [i915#95]) +26 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_edge_walk@pipe-b-128x128-left-edge: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-glk9/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/shard-glk1/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#72]) [21]:
Re: [Intel-gfx] [PATCH v4 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
Hi, On 7/9/20 4:14 PM, Sam Ravnborg wrote: Hi Hans. On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote: Hi All, Here is v4 of my patch series converting the i915 driver's code for controlling the panel's backlight with an external PWM controller to use the atomic PWM API. See below for the changelog. Why is it that i915 cannot use the pwm_bl driver for backlight? I have not studied the code - just wondering. The intel_panel.c code deals with 7 different types of PWM controllers which are built into the GPU + support for external PWM controllers through the kernel's PWM subsystem. pwm_bl will work for the external PWM controller case, but not for the others. On top of that the intel_panel code integrates which the video BIOS, getting things like frequency, minimum value and if the range is inverted (0% duty == backlight brightness max). I'm not even sure if pwm_bl supports all of this, but even if it does the intel_panel code handles this in a unified manner for all supported PWM controllers, including the ones which are an integral part of the GPU. Regards, Hans Initially the plan was for this series to consist of 2 parts: 1. convert the pwm-crc driver to support the atomic PWM API and 2. convert the i915 driver's PWM code to use the atomic PWM API. But during testing I've found a number of bugs in the pwm-lpss and I found that the acpi_lpss code needs some special handling because of some ugliness found in most Cherry Trail DSDTs. So now this series has grown somewhat large and consists of 4 parts: 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness 2. various fixes to the pwm-lpss driver 3. convert the pwm-crc driver to support the atomic PWM API and 4. convert the i915 driver's PWM code to use the atomic PWM API The involved acpi_lpss and pwm drivers do not see a whole lot of churn, so the plan is to merge this all through drm-intel-next-queued (dinq) once all the patches are reviewed / have acks. In v4 the ACPI patches have been Acked by Rafael and the i915 patches have been acked by Jani. So that just leaves the PWM patches. Uwe can I get your ok / ack for merging this through the dinq branch once you have acked al the PWM patches ? This series has been tested (and re-tested after adding various bug-fixes) extensively. It has been tested on the following devices: -Asus T100TA BYT + CRC-PMIC PWM -Toshiba WT8-A BYT + CRC-PMIC PWM -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM -Asus T100HA CHT + CRC-PMIC PWM -Terra Pad 1061 BYT + LPSS PWM -Trekstor Twin 10.1 BYT + LPSS PWM -Asus T101HA CHT + CRC-PMIC PWM -GPD Pocket CHT + CRC-PMIC PWM Changelog: Changes in v2: - Fix coverletter subject - Drop accidentally included debugging patch - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once ( - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX Changes in v3: - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value" - Use base_unit_range - 1 as maximum value for the clamp() - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume" - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" patch from previous versions of this patch-set, which really was a hack working around the resume issue which this patch fixes properly. - PATCH v3 6 - 11 pwm-crc changes: - Various small changes resulting from the reviews by Andy and Uwe, including some refactoring of the patches to reduce the amount of churn in the patch-set Changes in v4: - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0" - This is a new patch in v4 of this patchset - "[PATCH v4 12/16] pwm: crc: Implement get_state() method" - Use DIV_ROUND_UP when calculating the period and duty_cycle values - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller" - Add a note to the commit message about the changes in pwm_disable_backlight() - Use the pwm_set/get_relative_duty_cycle() helpers Regards, Hans ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/20] drm/i915: Export a preallocate variant of i915_active_acquire()
Op 06-07-2020 om 08:19 schreef Chris Wilson:
> Sometimes we have to be very careful not to allocate underneath a mutex
> (or spinlock) and yet still want to track activity. Enter
> i915_active_acquire_for_context(). This raises the activity counter on
> i915_active prior to use and ensures that the fence-tree contains a slot
> for the context.
>
> Signed-off-by: Chris Wilson
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_timeline.c | 4 +-
> drivers/gpu/drm/i915/i915_active.c| 113 +++---
> drivers/gpu/drm/i915/i915_active.h| 14 ++-
> 4 files changed, 113 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1015c4fd9f3e..6d20be29ff3c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1789,7 +1789,7 @@ __parser_mark_active(struct i915_vma *vma,
> {
> struct intel_gt_buffer_pool_node *node = vma->private;
>
> - return i915_active_ref(>active, tl, fence);
> + return i915_active_ref(>active, tl->fence_context, fence);
> }
>
> static int
> diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
> b/drivers/gpu/drm/i915/gt/intel_timeline.c
> index 4546284fede1..e4a5326633b8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_timeline.c
> +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
> @@ -479,7 +479,9 @@ __intel_timeline_get_seqno(struct intel_timeline *tl,
>* free it after the current request is retired, which ensures that
>* all writes into the cacheline from previous requests are complete.
>*/
> - err = i915_active_ref(>hwsp_cacheline->active, tl, >fence);
> + err = i915_active_ref(>hwsp_cacheline->active,
> + tl->fence_context,
> + >fence);
> if (err)
> goto err_cacheline;
>
> diff --git a/drivers/gpu/drm/i915/i915_active.c
> b/drivers/gpu/drm/i915/i915_active.c
> index d960d0be5bd2..3f595446fd44 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -217,11 +217,10 @@ excl_retire(struct dma_fence *fence, struct
> dma_fence_cb *cb)
> }
>
> static struct i915_active_fence *
> -active_instance(struct i915_active *ref, struct intel_timeline *tl)
> +active_instance(struct i915_active *ref, u64 idx)
> {
> struct active_node *node, *prealloc;
> struct rb_node **p, *parent;
> - u64 idx = tl->fence_context;
>
> /*
>* We track the most recently used timeline to skip a rbtree search
> @@ -353,21 +352,17 @@ __active_del_barrier(struct i915_active *ref, struct
> active_node *node)
> return active_del_barrier(ref, node, barrier_to_engine(node));
> }
>
> -int i915_active_ref(struct i915_active *ref,
> - struct intel_timeline *tl,
> - struct dma_fence *fence)
> +int i915_active_ref(struct i915_active *ref, u64 idx, struct dma_fence
> *fence)
> {
> struct i915_active_fence *active;
> int err;
>
> - lockdep_assert_held(>mutex);
> -
> /* Prevent reaping in case we malloc/wait while building the tree */
> err = i915_active_acquire(ref);
> if (err)
> return err;
>
> - active = active_instance(ref, tl);
> + active = active_instance(ref, idx);
> if (!active) {
> err = -ENOMEM;
> goto out;
> @@ -384,32 +379,104 @@ int i915_active_ref(struct i915_active *ref,
> atomic_dec(>count);
> }
> if (!__i915_active_fence_set(active, fence))
> - atomic_inc(>count);
> + __i915_active_acquire(ref);
>
> out:
> i915_active_release(ref);
> return err;
> }
>
> -struct dma_fence *
> -i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
> +static struct dma_fence *
> +__i915_active_set_fence(struct i915_active *ref,
> + struct i915_active_fence *active,
> + struct dma_fence *fence)
> {
> struct dma_fence *prev;
>
> /* We expect the caller to manage the exclusive timeline ordering */
> GEM_BUG_ON(i915_active_is_idle(ref));
>
> + if (is_barrier(active)) { /* proto-node used by our idle barrier */
> + /*
> + * This request is on the kernel_context timeline, and so
> + * we can use it to substitute for the pending idle-barrer
> + * request that we want to emit on the kernel_context.
> + */
> + __active_del_barrier(ref, node_from_active(active));
> + RCU_INIT_POINTER(active->fence, NULL);
> + atomic_dec(>count);
> + }
> +
> rcu_read_lock();
> - prev = __i915_active_fence_set(>excl, f);
> + prev = __i915_active_fence_set(active, fence);
> if (prev)
> prev =
Re: [Intel-gfx] [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 7/9/20 4:21 PM, Andy Shevchenko wrote: On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote: On 7/9/20 2:53 PM, Andy Shevchenko wrote: On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote: When the user requests a high enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value of 0. But according to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. Adding 0 to the counter is a no-op. The data-sheet even explicitly states that writing 0 to the base_unit bits will result in the PWM outputting a continuous 0 signal. And I don't see how you can get duty 100% / 0% (I don't remember which one is equivalent to 0 in base unit) after this change. IIRC the problem here that base unit when non-zero is always being added to the counter and it will trigger the change of output at some point which is not what we want for 100% / 0% cases. The base_unit controls the output frequency, not the duty-cycle. So clamping the base_unit, as calculated from the period here, which also only configures output-frequency does not impact the duty-cycle at all. note that AFAICT currently no (in kernel) users actually try to set a period value which would hit the clamp, so for existing users the clamp is a no-op. I just added it to this patch-set for correctness sake and because userspace (sysfs interface) users could in theory set out of range values. As for the duty-cycle thing, first of all let me say that that is a question / issue which is completely orthogonal to this patch, this patch only impacts the period/output frequency NOT the duty-cycle, Unfortunately the base unit settings affects duty cycle. Documentation says about integer part and fractional, where integer is 8 bit and this what's being compared to on time divisor. Thus, if on time divisor is 255 and base unit is 1 (in integer part) or 0.25, we can't get 0%. (It looks like if 'on time divisor MOD base unit == 0' we won't get 0%) With that said, the documentation is not really helpful here, we need to set the on_time_div to 255 to get a duty-cycle close to 0 (and to 0 to get a duty cycle of 100%) but if setting this to 255 gives us a duty-cycle of really really 0%, or just close to 0% is uncleaer. It depends on base unit value. We could do a separate patch add ing a hack where if the user asks for 0% duty-cycle we program the base_unit to 0, but that seems like a bad idea for 2 reasons: 1. If the user really wants the output to be constantly 0 the user should just disable the pwm I can't take this as an argument. Disabling PWM is orthogonal to what duty cycle is. 2. New base_unit values are latched and not applied until the counter overflows, with a base_unit of 0 the counter never overflows. I have not tested this but I would not be surprised if after programming a base_unit value of 0, we are unable to ever change the value again through any other means then power-cycling the PWM controller. Even if I could test this on some revisions, we already know that not all revisions work the same wrt the latching. So it is best to just never set base_unit to 0, that is just a recipe asking for trouble. This what doc says about zeros: • Programming either the PWM_base_unit value or the PWM_on_time_divisor to ‘0’ will generate an always zero output. So, what I'm talking seems about correlation between base unit and on time divisor rather than zeros. I agree with this patch. Reviewed-by: Andy Shevchenko Thank you. When the user requestes a low enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value which is bigger then base_unit_range - 1. Currently the codes for this deals with this by applying a mask: base_unit &= (base_unit_range - 1); But this means that we let the value overflow the range, we throw away the higher bits and store whatever value is left in the lower bits into the register leading to a random output frequency, rather then clamping the output frequency to the highest frequency which the hardware can do. It would be nice to have an example of calculus here. This commit fixes both issues by clamping the base_unit value to be between 1 and (base_unit_range - 1). Eventually I sat and wrote all this on paper. I see now that the problem is in out of range of the period. And strongly we should clamp rather period to the supported range, but your solution is an equivalent. Right, the advantage of doing the clamping on the register value is that we avoid some tricky math with possible rounding errors and which is different per controller revision because the number of bits in the base unit being different per controller revision. ... + base_unit = clamp_t(unsigned long long, base_unit, 1, + base_unit_range - 1); A nit: one line.
Re: [Intel-gfx] [PATCH v4 4/5] drm/i915/display: Implement HOBL
On Wed, Jul 08, 2020 at 01:55:11PM -0700, José Roberto de Souza wrote:
> Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> supported motherboards to use a special voltage swing table for eDP
> panels that uses less power.
>
> So here if supported by HW, OEM will set it in VBT and i915 will try
> to train link with HOBL vswing table if link training fails it fall
> back to the original table.
>
> intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag
> instead of do something like is done in intel_ddi_dp_voltage_max()
> because it is only called after the first entry of the voltage swing
> table was loaded so the HOBL flag is valid at that point.
>
> v3:
> - removed a few parameters of icl_ddi_combo_vswing_program() that
> can be taken from encoder(TODO)
>
> v4:
> - using the HOBL vswing table until training fails completely (Ville)
>
> BSpec: 49291
> BSpec: 49399
> Cc: Ville Syrjälä
> Cc: Animesh Manna
> Cc: Manasi Navare
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 37 ---
> .../drm/i915/display/intel_display_types.h| 2 +
> .../drm/i915/display/intel_dp_link_training.c | 5 +++
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> 4 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2c484b55bcdf..bf86c588f726 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -706,6 +706,15 @@ static const struct cnl_ddi_buf_trans
> tgl_combo_phy_ddi_translations_dp_hbr2[] =
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +static const struct cnl_ddi_buf_trans
> tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 }
> +};
> +
> +static bool is_hobl_buf_trans(const struct cnl_ddi_buf_trans *table)
> +{
> + return table == tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> +}
> +
> static const struct ddi_buf_trans *
> bdw_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
> {
> @@ -1050,6 +1059,16 @@ static const struct cnl_ddi_buf_trans *
> tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> {
> + if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (!intel_dp->hobl_disabled && rate <= 54) {
> + /* Same table applies to TGL, RKL and DG1 */
> + *n_entries =
> ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> + return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> + }
> + }
> +
> if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
> return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
> } else if (rate > 27) {
> @@ -2223,13 +2242,12 @@ static u8 intel_ddi_dp_voltage_max(struct intel_dp
> *intel_dp)
> DP_TRAIN_VOLTAGE_SWING_MASK;
> }
>
> -/*
> - * We assume that the full set of pre-emphasis values can be
> - * used on all DDI platforms. Should that change we need to
> - * rethink this code.
> - */
> static u8 intel_ddi_dp_preemph_max(struct intel_dp *intel_dp)
> {
> + /* HOBL voltage swing table only have one entry */
> + if (intel_dp->hobl_active)
> + return DP_TRAIN_PRE_EMPH_LEVEL_0;
That's illegal. We need to claim support for at least all
vswing/pre-emphasis levels 0-2. 3 is optional. Though there is
some confusion around this in the eDP spec where it kinda seems suggest
that even some of the level 2 things are optional. But it's so unclear
I would defer to just trusting what the DP spec says.
/me goes to write the patch with the WARNs...
> +
> return DP_TRAIN_PRE_EMPH_LEVEL_3;
> }
>
> @@ -2392,6 +2410,15 @@ static void icl_ddi_combo_vswing_program(struct
> intel_encoder *encoder,
> level = n_entries - 1;
> }
>
> + if (INTEL_GEN(dev_priv) >= 12 && type == INTEL_OUTPUT_EDP) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + val = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
> + intel_dp->hobl_active = is_hobl_buf_trans(ddi_translations);
> + intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), val,
> + intel_dp->hobl_active ? val : 0);
> + }
I'd still suggest writing that unconditionally.
> +
> /* Set PORT_TX_DW5 */
> val = intel_de_read(dev_priv, ICL_PORT_TX_DW5_LN0(phy));
> val &= ~(SCALING_MODE_SEL_MASK | RTERM_SELECT_MASK |
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index e8f809161c75..fd4f0e4d0be7 100644
> ---
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index (rev2)
== Series Details ==
Series: series starting with [1/3] drm/edid: Allow looking for ext blocks
starting from a specified index (rev2)
URL : https://patchwork.freedesktop.org/series/77699/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8708 -> Patchwork_18081
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18081 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18081, 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_18081/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18081:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_pm:
- fi-cml-s: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-cml-s/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-cml-s/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_18081 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@gem_flink_ba...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-apl-guc/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-bsw-kefka/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][15] ([i915#1888]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_render_linear_blits@basic:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {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_8708/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-dsi/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_8708/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[23]:
Re: [Intel-gfx] [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value
On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote: > On 7/9/20 2:53 PM, Andy Shevchenko wrote: > > On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote: > > > When the user requests a high enough period ns value, then the > > > calculations in pwm_lpss_prepare() might result in a base_unit value of 0. > > > > > > But according to the data-sheet the way the PWM controller works is that > > > each input clock-cycle the base_unit gets added to a N bit counter and > > > that counter overflowing determines the PWM output frequency. Adding 0 > > > to the counter is a no-op. The data-sheet even explicitly states that > > > writing 0 to the base_unit bits will result in the PWM outputting a > > > continuous 0 signal. > > > > And I don't see how you can get duty 100% / 0% (I don't remember which one > > is > > equivalent to 0 in base unit) after this change. IIRC the problem here that > > base unit when non-zero is always being added to the counter and it will > > trigger the change of output at some point which is not what we want for > > 100% / > > 0% cases. > > The base_unit controls the output frequency, not the duty-cycle. So clamping > the base_unit, as calculated from the period here, which also only configures > output-frequency does not impact the duty-cycle at all. > > note that AFAICT currently no (in kernel) users actually try to set a period > value > which would hit the clamp, so for existing users the clamp is a no-op. I just > added it to this patch-set for correctness sake and because userspace > (sysfs interface) users could in theory set out of range values. > > As for the duty-cycle thing, first of all let me say that that is a > question / issue which is completely orthogonal to this patch, this > patch only impacts the period/output frequency NOT the duty-cycle, Unfortunately the base unit settings affects duty cycle. Documentation says about integer part and fractional, where integer is 8 bit and this what's being compared to on time divisor. Thus, if on time divisor is 255 and base unit is 1 (in integer part) or 0.25, we can't get 0%. (It looks like if 'on time divisor MOD base unit == 0' we won't get 0%) > With that said, the documentation is not really helpful here, > we need to set the on_time_div to 255 to get a duty-cycle close to 0 > (and to 0 to get a duty cycle of 100%) but if setting this to 255 gives > us a duty-cycle of really really 0%, or just close to 0% is uncleaer. It depends on base unit value. > We could do a separate patch add ing a hack where if the user asks for > 0% duty-cycle we program the base_unit to 0, but that seems like a bad > idea for 2 reasons: > 1. If the user really wants the output to be constantly 0 the user should > just disable the pwm I can't take this as an argument. Disabling PWM is orthogonal to what duty cycle is. > 2. New base_unit values are latched and not applied until the counter > overflows, with a base_unit of 0 the counter never overflows. I have > not tested this but I would not be surprised if after programming a > base_unit value of 0, we are unable to ever change the value again > through any other means then power-cycling the PWM controller. > Even if I could test this on some revisions, we already know that > not all revisions work the same wrt the latching. So it is best to > just never set base_unit to 0, that is just a recipe asking for trouble. This what doc says about zeros: • Programming either the PWM_base_unit value or the PWM_on_time_divisor to ‘0’ will generate an always zero output. So, what I'm talking seems about correlation between base unit and on time divisor rather than zeros. I agree with this patch. Reviewed-by: Andy Shevchenko > > > When the user requestes a low enough period ns value, then the > > > calculations in pwm_lpss_prepare() might result in a base_unit value > > > which is bigger then base_unit_range - 1. Currently the codes for this > > > deals with this by applying a mask: > > > > > > base_unit &= (base_unit_range - 1); > > > > > > But this means that we let the value overflow the range, we throw away the > > > higher bits and store whatever value is left in the lower bits into the > > > register leading to a random output frequency, rather then clamping the > > > output frequency to the highest frequency which the hardware can do. > > > > It would be nice to have an example of calculus here. > > > > > This commit fixes both issues by clamping the base_unit value to be > > > between 1 and (base_unit_range - 1). > > > > Eventually I sat and wrote all this on paper. I see now that the problem > > is in out of range of the period. And strongly we should clamp rather period > > to the supported range, but your solution is an equivalent. > > Right, the advantage of doing the clamping on the register value is that we > avoid some tricky math with possible rounding errors and which is different > per controller revision because the number of bits in the base
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
Am 09.07.20 um 15:54 schrieb Steven Price: On 09/07/2020 09:48, Christian König wrote: Am 08.07.20 um 18:19 schrieb Daniel Vetter: On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter wrote: On Wed, Jul 8, 2020 at 5:05 PM Christian König wrote: Am 08.07.20 um 17:01 schrieb Daniel Vetter: On Wed, Jul 8, 2020 at 4:37 PM Christian König wrote: Am 08.07.20 um 11:54 schrieb Daniel Vetter: On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote: Am 07.07.20 um 20:35 schrieb Chris Wilson: Quoting lepton (2020-07-07 19:17:51) On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: Quoting lepton (2020-07-07 18:05:21) On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote: If we assign obj->filp, we believe that the create vgem bo is native and allow direct operations like mmap() assuming it behaves as backed by a shmemfs inode. When imported from a dmabuf, the obj->pages are not always meaningful and the shmemfs backing store misleading. Note, that regular mmap access to a vgem bo is via the dumb buffer API, and that rejects attempts to mmap an imported dmabuf, What do you mean by "regular mmap access" here? It looks like vgem is using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call drm_gem_dumb_map_offset As I too found out, and so had to correct my story telling. By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer API] as opposed to mmap() via an exported dma-buf fd. I had to look at igt to see how it was being used. Now it seems your fix is to disable "regular mmap" on imported dma buf for vgem. I am not really a graphic guy, but then the api looks like: for a gem handle, user space has to guess to find out the way to mmap it. If user space guess wrong, then it will fail to mmap. Is this the expected way for people to handle gpu buffer? You either have a dumb buffer handle, or a dma-buf fd. If you have the handle, you have to use the dumb buffer API, there's no other way to mmap it. If you have the dma-buf fd, you should mmap it directly. Those two are clear. It's when you import the dma-buf into vgem and create a handle out of it, that's when the handle is no longer first class and certain uAPI [the dumb buffer API in particular] fail. It's not brilliant, as you say, it requires the user to remember the difference between the handles, but at the same time it does prevent them falling into coherency traps by forcing them to use the right driver to handle the object, and have to consider the additional ioctls that go along with that access. Yes, Chris is right. Mapping DMA-buf through the mmap() APIs of an importer is illegal. What we could maybe try to do is to redirect this mmap() API call on the importer to the exporter, but I'm pretty sure that the fs layer wouldn't like that without changes. We already do that, there's a full helper-ified path from I think shmem helpers through prime helpers to forward this all. Including handling buffer offsets and all the other lolz back Oh, that most likely won't work correctly with unpinned DMA-bufs and needs to be avoided. Each file descriptor is associated with an struct address_space. And when you mmap() through the importer by redirecting the system call to the exporter you end up with the wrong struct address_space in your VMA. That in turn can go up easily in flames when the exporter tries to invalidate the CPU mappings for its DMA-buf while moving it. Where are we doing this? My last status was that this is forbidden. Hm I thought we're doing all that already, but looking at the code again we're only doing this when opening a new drm fd or dma-buf fd. So the right file->f_mapping is always set at file creation time. And we indeed don't frob this more when going another indirection ... Maybe we screwed up something somewhere :-/ Also I thought the mapping is only taken after the vma is instatiated, otherwise the tricks we're playing with dma-buf already wouldn't work: dma-buf has the buffer always at offset 0, whereas gem drm_fd mmap has it somewhere else. We already adjust vma->vm_pgoff, so I'm wondering whether we could adjust vm_file too. Or is that the thing that's forbidden? Yes, exactly. Modifying vm_pgoff is harmless, tons of code does that. But changing vma->vm_file, that's something I haven't seen before and most likely could blow up badly. Ok, I read the shmem helpers again, I think those are the only ones which do the importer mmap -> dma_buf_mmap() forwarding, and hence break stuff all around here. They also remove the vma->vm_pgoff offset, which means unmap_mapping_range wont work anyway. I guess for drivers which use shmem helpers the hard assumption is that a) can't use p2p dma and b) pin everything into system memory. So not a problem. But something to keep in mind. I'll try to do a kerneldoc patch to note this somewhere. btw on that, did the timeline/syncobj documentation patch land by now? Just trying to make sure that doesn't
Re: [Intel-gfx] [PATCH v4 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
Hi Hans. On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote: > Hi All, > > Here is v4 of my patch series converting the i915 driver's code for > controlling the panel's backlight with an external PWM controller to > use the atomic PWM API. See below for the changelog. Why is it that i915 cannot use the pwm_bl driver for backlight? I have not studied the code - just wondering. Sam > > Initially the plan was for this series to consist of 2 parts: > 1. convert the pwm-crc driver to support the atomic PWM API and > 2. convert the i915 driver's PWM code to use the atomic PWM API. > > But during testing I've found a number of bugs in the pwm-lpss and I > found that the acpi_lpss code needs some special handling because of > some ugliness found in most Cherry Trail DSDTs. > > So now this series has grown somewhat large and consists of 4 parts: > > 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness > 2. various fixes to the pwm-lpss driver > 3. convert the pwm-crc driver to support the atomic PWM API and > 4. convert the i915 driver's PWM code to use the atomic PWM API > > The involved acpi_lpss and pwm drivers do not see a whole lot of churn, > so the plan is to merge this all through drm-intel-next-queued (dinq) > once all the patches are reviewed / have acks. > > In v4 the ACPI patches have been Acked by Rafael and the i915 patches > have been acked by Jani. So that just leaves the PWM patches. > > Uwe can I get your ok / ack for merging this through the dinq branch > once you have acked al the PWM patches ? > > This series has been tested (and re-tested after adding various bug-fixes) > extensively. It has been tested on the following devices: > > -Asus T100TA BYT + CRC-PMIC PWM > -Toshiba WT8-A BYT + CRC-PMIC PWM > -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM > -Asus T100HA CHT + CRC-PMIC PWM > -Terra Pad 1061 BYT + LPSS PWM > -Trekstor Twin 10.1 BYT + LPSS PWM > -Asus T101HA CHT + CRC-PMIC PWM > -GPD Pocket CHT + CRC-PMIC PWM > > Changelog: > > Changes in v2: > - Fix coverletter subject > - Drop accidentally included debugging patch > - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only > once ( > - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX > > Changes in v3: > - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit > register value" > - Use base_unit_range - 1 as maximum value for the clamp() > - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on > resume" > - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" > patch from previous versions of this patch-set, which really was a hack > working around the resume issue which this patch fixes properly. > - PATCH v3 6 - 11 pwm-crc changes: > - Various small changes resulting from the reviews by Andy and Uwe, > including some refactoring of the patches to reduce the amount of churn > in the patch-set > > Changes in v4: > - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0" > - This is a new patch in v4 of this patchset > - "[PATCH v4 12/16] pwm: crc: Implement get_state() method" > - Use DIV_ROUND_UP when calculating the period and duty_cycle values > - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an > external PWM controller" > - Add a note to the commit message about the changes in > pwm_disable_backlight() > - Use the pwm_set/get_relative_duty_cycle() helpers > > Regards, > > Hans > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/5] drm/i915/display: Remove port and phy from voltage swing functions
On Wed, Jul 08, 2020 at 01:55:09PM -0700, José Roberto de Souza wrote:
> This information can be get directly from intel_encoder so no need
> of those parameters.
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 33 ++--
> 1 file changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index e80319aa7cf0..2c484b55bcdf 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -815,8 +815,7 @@ static int skl_buf_trans_num_entries(enum port port, int
> n_entries)
> }
>
> static const struct ddi_buf_trans *
> -intel_ddi_get_buf_trans_dp(struct intel_encoder *encoder,
> -enum port port, int *n_entries)
> +intel_ddi_get_buf_trans_dp(struct intel_encoder *encoder, int *n_entries)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>
> @@ -825,12 +824,12 @@ intel_ddi_get_buf_trans_dp(struct intel_encoder
> *encoder,
> IS_COMETLAKE(dev_priv)) {
> const struct ddi_buf_trans *ddi_translations =
> kbl_get_buf_trans_dp(encoder, n_entries);
> - *n_entries = skl_buf_trans_num_entries(port, *n_entries);
> + *n_entries = skl_buf_trans_num_entries(encoder->port,
> *n_entries);
> return ddi_translations;
> } else if (IS_SKYLAKE(dev_priv)) {
> const struct ddi_buf_trans *ddi_translations =
> skl_get_buf_trans_dp(encoder, n_entries);
> - *n_entries = skl_buf_trans_num_entries(port, *n_entries);
> + *n_entries = skl_buf_trans_num_entries(encoder->port,
> *n_entries);
> return ddi_translations;
> } else if (IS_BROADWELL(dev_priv)) {
> *n_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> @@ -845,15 +844,14 @@ intel_ddi_get_buf_trans_dp(struct intel_encoder
> *encoder,
> }
>
> static const struct ddi_buf_trans *
> -intel_ddi_get_buf_trans_edp(struct intel_encoder *encoder,
> - enum port port, int *n_entries)
> +intel_ddi_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>
> if (IS_GEN9_BC(dev_priv)) {
> const struct ddi_buf_trans *ddi_translations =
> skl_get_buf_trans_edp(encoder, n_entries);
> - *n_entries = skl_buf_trans_num_entries(port, *n_entries);
> + *n_entries = skl_buf_trans_num_entries(encoder->port,
> *n_entries);
> return ddi_translations;
> } else if (IS_BROADWELL(dev_priv)) {
> return bdw_get_buf_trans_edp(encoder, n_entries);
> @@ -1152,10 +1150,10 @@ static void intel_prepare_dp_ddi_buffers(struct
> intel_encoder *encoder,
> ddi_translations = intel_ddi_get_buf_trans_fdi(dev_priv,
> _entries);
> else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP))
> - ddi_translations = intel_ddi_get_buf_trans_edp(encoder, port,
> + ddi_translations = intel_ddi_get_buf_trans_edp(encoder,
> _entries);
> else
> - ddi_translations = intel_ddi_get_buf_trans_dp(encoder, port,
> + ddi_translations = intel_ddi_get_buf_trans_dp(encoder,
> _entries);
>
> /* If we're boosting the current, set bit 31 of trans1 */
> @@ -2106,7 +2104,6 @@ static void skl_ddi_set_iboost(struct intel_encoder
> *encoder,
> {
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum port port = encoder->port;
> u8 iboost;
>
> if (type == INTEL_OUTPUT_HDMI)
> @@ -2122,11 +2119,9 @@ static void skl_ddi_set_iboost(struct intel_encoder
> *encoder,
> ddi_translations =
> intel_ddi_get_buf_trans_hdmi(encoder, _entries);
> else if (type == INTEL_OUTPUT_EDP)
> ddi_translations = intel_ddi_get_buf_trans_edp(encoder,
> -port,
>
> _entries);
> else
> ddi_translations = intel_ddi_get_buf_trans_dp(encoder,
> - port,
>
> _entries);
>
> if (drm_WARN_ON_ONCE(_priv->drm, !ddi_translations))
> @@ -2143,9 +2138,9 @@ static void skl_ddi_set_iboost(struct intel_encoder
> *encoder,
> return;
> }
>
> -
Re: [Intel-gfx] [PATCH v4 1/5] drm/i915/display: Replace drm_i915_private in voltage swing functions by intel_encoder
On Wed, Jul 08, 2020 at 01:55:08PM -0700, José Roberto de Souza wrote:
> intel_encoder will be needed inside of vswing functions in a future
> patch, so here doing this change in all vswing functions since HSW.
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 164 +--
> 1 file changed, 95 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 5773ebefffc7..e80319aa7cf0 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -707,8 +707,10 @@ static const struct cnl_ddi_buf_trans
> tgl_combo_phy_ddi_translations_dp_hbr2[] =
> };
>
> static const struct ddi_buf_trans *
> -bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> +bdw_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> if (dev_priv->vbt.edp.low_vswing) {
> *n_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> return bdw_ddi_translations_edp;
> @@ -719,8 +721,10 @@ bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv,
> int *n_entries)
> }
>
> static const struct ddi_buf_trans *
> -skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> +skl_get_buf_trans_dp(struct intel_encoder *encoder, int *n_entries)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> if (IS_SKL_ULX(dev_priv)) {
> *n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
> return skl_y_ddi_translations_dp;
> @@ -734,8 +738,10 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv,
> int *n_entries)
> }
>
> static const struct ddi_buf_trans *
> -kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> +kbl_get_buf_trans_dp(struct intel_encoder *encoder, int *n_entries)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> if (IS_KBL_ULX(dev_priv) ||
> IS_CFL_ULX(dev_priv) ||
> IS_CML_ULX(dev_priv)) {
> @@ -753,8 +759,10 @@ kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv,
> int *n_entries)
> }
>
> static const struct ddi_buf_trans *
> -skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> +skl_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> if (dev_priv->vbt.edp.low_vswing) {
> if (IS_SKL_ULX(dev_priv) ||
> IS_KBL_ULX(dev_priv) ||
> @@ -777,9 +785,9 @@ skl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
> int *n_entries)
> if (IS_KABYLAKE(dev_priv) ||
> IS_COFFEELAKE(dev_priv) ||
> IS_COMETLAKE(dev_priv))
> - return kbl_get_buf_trans_dp(dev_priv, n_entries);
> + return kbl_get_buf_trans_dp(encoder, n_entries);
> else
> - return skl_get_buf_trans_dp(dev_priv, n_entries);
> + return skl_get_buf_trans_dp(encoder, n_entries);
> }
>
> static const struct ddi_buf_trans *
> @@ -807,19 +815,21 @@ static int skl_buf_trans_num_entries(enum port port,
> int n_entries)
> }
>
> static const struct ddi_buf_trans *
> -intel_ddi_get_buf_trans_dp(struct drm_i915_private *dev_priv,
> +intel_ddi_get_buf_trans_dp(struct intel_encoder *encoder,
> enum port port, int *n_entries)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> if (IS_KABYLAKE(dev_priv) ||
> IS_COFFEELAKE(dev_priv) ||
> IS_COMETLAKE(dev_priv)) {
> const struct ddi_buf_trans *ddi_translations =
> - kbl_get_buf_trans_dp(dev_priv, n_entries);
> + kbl_get_buf_trans_dp(encoder, n_entries);
> *n_entries = skl_buf_trans_num_entries(port, *n_entries);
> return ddi_translations;
> } else if (IS_SKYLAKE(dev_priv)) {
> const struct ddi_buf_trans *ddi_translations =
> - skl_get_buf_trans_dp(dev_priv, n_entries);
> + skl_get_buf_trans_dp(encoder, n_entries);
> *n_entries = skl_buf_trans_num_entries(port, *n_entries);
> return ddi_translations;
> } else if (IS_BROADWELL(dev_priv)) {
> @@ -835,16 +845,18 @@ intel_ddi_get_buf_trans_dp(struct drm_i915_private
> *dev_priv,
> }
>
> static const struct ddi_buf_trans *
> -intel_ddi_get_buf_trans_edp(struct drm_i915_private *dev_priv,
> +intel_ddi_get_buf_trans_edp(struct intel_encoder *encoder,
> enum port port, int *n_entries)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> if (IS_GEN9_BC(dev_priv)) {
> const struct ddi_buf_trans *ddi_translations =
> -
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index (rev2)
== Series Details ==
Series: series starting with [1/3] drm/edid: Allow looking for ext blocks
starting from a specified index (rev2)
URL : https://patchwork.freedesktop.org/series/77699/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8708 -> Patchwork_18081
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18081 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18081, 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_18081/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18081:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_pm:
- fi-cml-s: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-cml-s/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-cml-s/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_18081 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@gem_flink_ba...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-apl-guc/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-bsw-kefka/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][15] ([i915#1888]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_render_linear_blits@basic:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8708/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {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_8708/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-tgl-dsi/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_8708/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18081/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[23]:
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Implement WAs 18011464164 and 22010931296
On Wed, Jul 08, 2020 at 02:29:47PM -0700, José Roberto de Souza wrote:
> As today those 2 WAs have different implementation between TGL and DG1
> WA pages but checking the HSD it is clear that DG1 implementation
> should be used for both,
I couldn't really find any conclusions in any of the hsds to say that
disabling the TE DOP clock gating is sufficient to deal with the other
issues. However the dg1 w/a page does say that, so I guess it's good
enough.
Reviewed-by: Ville Syrjälä
> also to do so is easier as we just need to
> extend WA 1407928979 to B* stepping.
>
> Both WAs are need to fix some possible render corruptions.
>
> DG1 initial patches were not merged yet, as soon it is this WAs should
> be applied to DG1 as well.
>
> BSpec: 53508
> BSpec: 52890
> Cc: Lucas De Marchi
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 2da366821dda..3d31b763d9c9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1649,11 +1649,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> GEN7_SARCHKMD,
> GEN7_DISABLE_SAMPLER_PREFETCH);
>
> - /* Wa_1407928979:tgl */
> - wa_write_or(wal,
> - GEN7_FF_THREAD_MODE,
> - GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
> -
> /* Wa_1408615072:tgl */
> wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
> VSUNIT_CLKGATE_DIS_TGL);
> @@ -1677,6 +1672,14 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>* Wa_14010229206:tgl
>*/
> wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN12_DISABLE_TDL_PUSH);
> +
> + /*
> + * Wa_1407928979:tgl A*
> + * Wa_18011464164:tgl B0+
> + * Wa_22010931296:tgl B0+
> + */
> + wa_write_or(wal, GEN7_FF_THREAD_MODE,
> + GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
> }
>
> if (IS_GEN(i915, 11)) {
> --
> 2.27.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/20] drm/i915/gem: Replace i915_gem_object.mm.mutex with reservation_ww_class
Op 06-07-2020 om 08:19 schreef Chris Wilson:
> Our goal is to pull all memory reservations (next iteration
> obj->ops->get_pages()) under a ww_mutex, and to align those reservations
> with other drivers, i.e. control all such allocations with the
> reservation_ww_class. Currently, this is under the purview of the
> obj->mm.mutex, and while obj->mm remains an embedded struct we can
> "simply" switch to using the reservation_ww_class obj->base.resv->lock
>
> The major consequence is the impact on the shrinker paths as the
> reservation_ww_class is used to wrap allocations, and a ww_mutex does
> not support subclassing so we cannot do our usual trick of knowing that
> we never recurse inside the shrinker and instead have to finish the
> reclaim with a trylock. This may result in us failing to release the
> pages after having released the vma. This will have to do until a better
> idea comes along.
>
> However, this step only converts the mutex over and continues to treat
> everything as a single allocation and pinning the pages. With the
> ww_mutex in place we can remove the temporary pinning, as we can then
> reserve all storage en masse.
>
> One last thing to do: kill the implict page pinning for active vma.
> This will require us to invalidate the vma->pages when the backing store
> is removed (and we expect that while the vma is active, we mark the
> backing store as active so that it cannot be removed while the HW is
> busy.)
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 20 +-
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 18 +-
> drivers/gpu/drm/i915/gem/i915_gem_domain.c| 65 ++---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 44 +++-
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 8 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 37 +--
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 -
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 136 +--
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 13 +-
> drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 -
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 15 +-
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 32 ++-
> .../i915/gem/selftests/i915_gem_coherency.c | 14 +-
> .../drm/i915/gem/selftests/i915_gem_context.c | 10 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +
> drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 -
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 1 -
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 5 +-
> drivers/gpu/drm/i915/gt/intel_gtt.h | 2 -
> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 16 +-
> drivers/gpu/drm/i915/i915_vma.c | 225 +++---
> drivers/gpu/drm/i915/i915_vma_types.h | 6 -
> drivers/gpu/drm/i915/mm/i915_acquire_ctx.c| 11 +-
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +-
> .../drm/i915/selftests/intel_memory_region.c | 17 +-
> 27 files changed, 319 insertions(+), 396 deletions(-)]
It's trivial to do a search and replace for obj->mm.lock, but that won't solve
the locking issue we need to solve with actually using ww_mutex correctly.
We shouldn't return -EAGAIN in userptr if trylock fails, but it should use
proper locking. That should be the entire goal of the removal, not just a quick
search/replace job. :)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> index bc0223716906..a32fd0d5570b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> @@ -27,16 +27,8 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
> static int clflush_work(struct dma_fence_work *base)
> {
> struct clflush *clflush = container_of(base, typeof(*clflush), base);
> - struct drm_i915_gem_object *obj = clflush->obj;
> - int err;
> -
> - err = i915_gem_object_pin_pages(obj);
> - if (err)
> - return err;
> -
> - __do_clflush(obj);
> - i915_gem_object_unpin_pages(obj);
>
> + __do_clflush(clflush->obj);
> return 0;
> }
>
> @@ -44,7 +36,7 @@ static void clflush_release(struct dma_fence_work *base)
> {
> struct clflush *clflush = container_of(base, typeof(*clflush), base);
>
> - i915_gem_object_put(clflush->obj);
> + i915_gem_object_unpin_pages(clflush->obj);
> }
>
> static const struct dma_fence_work_ops clflush_ops = {
> @@ -63,8 +55,14 @@ static struct clflush *clflush_work_create(struct
> drm_i915_gem_object *obj)
> if (!clflush)
> return NULL;
>
> + if (__i915_gem_object_get_pages_locked(obj)) {
> + kfree(clflush);
> + return NULL;
> + }
> +
> dma_fence_work_init(>base, _ops);
> - clflush->obj = i915_gem_object_get(obj); /* obj <-> clflush cycle */
> +
Re: [Intel-gfx] [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function
On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
>
> This avoids me having to roll out dma-fence critical section
> annotations to this copy.
>
> Signed-off-by: Daniel Vetter
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 20
> 1 file changed, 20 deletions(-)
Very nice catch:
Reviewed-by: Sam Ravnborg
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index f3ce49c5a34c..af55b334be2f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device
> *dev,
> return _gpu_fb->base;
> }
>
> -static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
> -{
> - struct drm_device *dev = state->dev;
> -
> - drm_atomic_helper_commit_modeset_disables(dev, state);
> - drm_atomic_helper_commit_modeset_enables(dev, state);
> - drm_atomic_helper_commit_planes(dev, state, 0);
> -
> - drm_atomic_helper_fake_vblank(state);
> - drm_atomic_helper_commit_hw_done(state);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, state);
> - drm_atomic_helper_cleanup_planes(dev, state);
> -}
> -
> -static const struct drm_mode_config_helper_funcs virtio_mode_config_helpers
> = {
> - .atomic_commit_tail = vgdev_atomic_commit_tail,
> -};
> -
> static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = {
> .fb_create = virtio_gpu_user_framebuffer_create,
> .atomic_check = drm_atomic_helper_check,
> @@ -346,7 +327,6 @@ void virtio_gpu_modeset_init(struct virtio_gpu_device
> *vgdev)
> drm_mode_config_init(vgdev->ddev);
> vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
> vgdev->ddev->mode_config.funcs = _gpu_mode_funcs;
> - vgdev->ddev->mode_config.helper_private = _mode_config_helpers;
>
> /* modes will be validated against the framebuffer size */
> vgdev->ddev->mode_config.min_width = XRES_MIN;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Don't do WaFbcTurnOffFbcWatermark for glk
On Thu, Jul 09, 2020 at 12:19:07AM +, Souza, Jose wrote: > On Wed, 2020-07-08 at 16:12 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > GLK supposedly does not need WaFbcTurnOffFbcWatermark, > > so let's not apply it. > > WA 0562 from BSpec 21664 says it applies to all GEN9 but it is probably > referring to all display GEN9. Yeah, and it doesn't show the GLK tag, nor does it show up if you filter for GLK. > > Reviewed-by: José Roberto de Souza Thanks. Series pushed. > > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_pm.c | 18 -- > > 1 file changed, 16 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index 63d1a4882727..8760e1ba1eee 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -94,10 +94,8 @@ static void gen9_init_clock_gating(struct > > drm_i915_private *dev_priv) > > I915_WRITE(GEN8_CHICKEN_DCPR_1, > >I915_READ(GEN8_CHICKEN_DCPR_1) | MASK_WAKEMEM); > > > > - /* WaFbcTurnOffFbcWatermark:skl,bxt,kbl,cfl */ > > /* WaFbcWakeMemOn:skl,bxt,kbl,glk,cfl */ > > I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) | > > - DISP_FBC_WM_DIS | > >DISP_FBC_MEMORY_WAKE); > > > > /* WaFbcHighMemBwCorruptionAvoidance:skl,bxt,kbl,cfl */ > > @@ -140,6 +138,10 @@ static void bxt_init_clock_gating(struct > > drm_i915_private *dev_priv) > > * application, using batch buffers or any other means. > > */ > > I915_WRITE(RM_TIMEOUT, MMIO_TIMEOUT_US(950)); > > + > > + /* WaFbcTurnOffFbcWatermark:bxt */ > > + I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) | > > + DISP_FBC_WM_DIS); > > } > > > > static void glk_init_clock_gating(struct drm_i915_private *dev_priv) > > @@ -7189,6 +7191,10 @@ static void cfl_init_clock_gating(struct > > drm_i915_private *dev_priv) > > cnp_init_clock_gating(dev_priv); > > gen9_init_clock_gating(dev_priv); > > > > + /* WaFbcTurnOffFbcWatermark:cfl */ > > + I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) | > > + DISP_FBC_WM_DIS); > > + > > /* WaFbcNukeOnHostModify:cfl */ > > I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) | > >ILK_DPFC_NUKE_ON_ANY_MODIFICATION); > > @@ -7208,6 +7214,10 @@ static void kbl_init_clock_gating(struct > > drm_i915_private *dev_priv) > > I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | > >GEN6_GAMUNIT_CLOCK_GATE_DISABLE); > > > > + /* WaFbcTurnOffFbcWatermark:kbl */ > > + I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) | > > + DISP_FBC_WM_DIS); > > + > > /* WaFbcNukeOnHostModify:kbl */ > > I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) | > >ILK_DPFC_NUKE_ON_ANY_MODIFICATION); > > @@ -7221,6 +7231,10 @@ static void skl_init_clock_gating(struct > > drm_i915_private *dev_priv) > > I915_WRITE(FBC_LLC_READ_CTRL, I915_READ(FBC_LLC_READ_CTRL) | > >FBC_LLC_FULLY_OPEN); > > > > + /* WaFbcTurnOffFbcWatermark:skl */ > > + I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) | > > + DISP_FBC_WM_DIS); > > + > > /* WaFbcNukeOnHostModify:skl */ > > I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) | > >ILK_DPFC_NUKE_ON_ANY_MODIFICATION); -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On 09/07/2020 09:48, Christian König wrote: Am 08.07.20 um 18:19 schrieb Daniel Vetter: On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter wrote: On Wed, Jul 8, 2020 at 5:05 PM Christian König wrote: Am 08.07.20 um 17:01 schrieb Daniel Vetter: On Wed, Jul 8, 2020 at 4:37 PM Christian König wrote: Am 08.07.20 um 11:54 schrieb Daniel Vetter: On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote: Am 07.07.20 um 20:35 schrieb Chris Wilson: Quoting lepton (2020-07-07 19:17:51) On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: Quoting lepton (2020-07-07 18:05:21) On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote: If we assign obj->filp, we believe that the create vgem bo is native and allow direct operations like mmap() assuming it behaves as backed by a shmemfs inode. When imported from a dmabuf, the obj->pages are not always meaningful and the shmemfs backing store misleading. Note, that regular mmap access to a vgem bo is via the dumb buffer API, and that rejects attempts to mmap an imported dmabuf, What do you mean by "regular mmap access" here? It looks like vgem is using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call drm_gem_dumb_map_offset As I too found out, and so had to correct my story telling. By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer API] as opposed to mmap() via an exported dma-buf fd. I had to look at igt to see how it was being used. Now it seems your fix is to disable "regular mmap" on imported dma buf for vgem. I am not really a graphic guy, but then the api looks like: for a gem handle, user space has to guess to find out the way to mmap it. If user space guess wrong, then it will fail to mmap. Is this the expected way for people to handle gpu buffer? You either have a dumb buffer handle, or a dma-buf fd. If you have the handle, you have to use the dumb buffer API, there's no other way to mmap it. If you have the dma-buf fd, you should mmap it directly. Those two are clear. It's when you import the dma-buf into vgem and create a handle out of it, that's when the handle is no longer first class and certain uAPI [the dumb buffer API in particular] fail. It's not brilliant, as you say, it requires the user to remember the difference between the handles, but at the same time it does prevent them falling into coherency traps by forcing them to use the right driver to handle the object, and have to consider the additional ioctls that go along with that access. Yes, Chris is right. Mapping DMA-buf through the mmap() APIs of an importer is illegal. What we could maybe try to do is to redirect this mmap() API call on the importer to the exporter, but I'm pretty sure that the fs layer wouldn't like that without changes. We already do that, there's a full helper-ified path from I think shmem helpers through prime helpers to forward this all. Including handling buffer offsets and all the other lolz back Oh, that most likely won't work correctly with unpinned DMA-bufs and needs to be avoided. Each file descriptor is associated with an struct address_space. And when you mmap() through the importer by redirecting the system call to the exporter you end up with the wrong struct address_space in your VMA. That in turn can go up easily in flames when the exporter tries to invalidate the CPU mappings for its DMA-buf while moving it. Where are we doing this? My last status was that this is forbidden. Hm I thought we're doing all that already, but looking at the code again we're only doing this when opening a new drm fd or dma-buf fd. So the right file->f_mapping is always set at file creation time. And we indeed don't frob this more when going another indirection ... Maybe we screwed up something somewhere :-/ Also I thought the mapping is only taken after the vma is instatiated, otherwise the tricks we're playing with dma-buf already wouldn't work: dma-buf has the buffer always at offset 0, whereas gem drm_fd mmap has it somewhere else. We already adjust vma->vm_pgoff, so I'm wondering whether we could adjust vm_file too. Or is that the thing that's forbidden? Yes, exactly. Modifying vm_pgoff is harmless, tons of code does that. But changing vma->vm_file, that's something I haven't seen before and most likely could blow up badly. Ok, I read the shmem helpers again, I think those are the only ones which do the importer mmap -> dma_buf_mmap() forwarding, and hence break stuff all around here. They also remove the vma->vm_pgoff offset, which means unmap_mapping_range wont work anyway. I guess for drivers which use shmem helpers the hard assumption is that a) can't use p2p dma and b) pin everything into system memory. So not a problem. But something to keep in mind. I'll try to do a kerneldoc patch to note this somewhere. btw on that, did the timeline/syncobj documentation patch land by now? Just trying to make sure that doesn't get lost for another few months or so :-/ Ok, so
Re: [Intel-gfx] [PATCH v4 05/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
Hi,
On 7/9/20 3:36 PM, Andy Shevchenko wrote:
On Wed, Jul 08, 2020 at 11:14:21PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.
The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.
The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.
Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.
All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit makes the resume handler use pwm_lpss_apply() to
restore the settings when necessary. This fixes the output-freq and
duty-cycle being reset to their defaults on resume.
...
+static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state, bool from_resume)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret;
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
- pm_runtime_get_sync(chip->dev);
+ if (!from_resume)
+ pm_runtime_get_sync(chip->dev);
+
ret = pwm_lpss_is_updating(pwm);
if (ret) {
- pm_runtime_put(chip->dev);
+ if (!from_resume)
+ pm_runtime_put(chip->dev);
+
return ret;
}
pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
state->period);
pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
ret = pwm_lpss_wait_for_update(pwm);
if (ret) {
- pm_runtime_put(chip->dev);
+ if (!from_resume)
+ pm_runtime_put(chip->dev);
+
return ret;
}
pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
- pm_runtime_put(chip->dev);
+
+ if (!from_resume)
+ pm_runtime_put(chip->dev);
}
I'm wondering if splitting more will make this look better, like:
...
if (from_resume) {
ret = pwm_lpss_prepare_enable(...); // whatever name you think
suits better
} else {
pm_runtime_get_sync(...);
ret = pwm_lpss_prepare_enable(...);
if (ret)
pm_runtime_put(...);
}
...
That is a good idea, I like it. We already had multiple pm_runtime_put() calls
before for the error handlig and this patch did not make it any better.
So adding a pwm_lpss_prepare_enable() helper (the name works for)
will also cleanup the original code. I will add this helper as
a separate preparation patch for this one in v5 of the patch-set.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 05/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
On Wed, Jul 08, 2020 at 11:14:21PM +0200, Hans de Goede wrote:
> Before this commit a suspend + resume of the LPSS PWM controller
> would result in the controller being reset to its defaults of
> output-freq = clock/256, duty-cycle=100%, until someone changes
> to the output-freq and/or duty-cycle are made.
>
> This problem has been masked so far because the main consumer
> (the i915 driver) was always making duty-cycle changes on resume.
> With the conversion of the i915 driver to the atomic PWM API the
> driver now only disables/enables the PWM on suspend/resume leaving
> the output-freq and duty as is, triggering this problem.
>
> The LPSS PWM controller has a mechanism where the ctrl register value
> and the actual base-unit and on-time-div values used are latched. When
> software sets the SW_UPDATE bit then at the end of the current PWM cycle,
> the new values from the ctrl-register will be latched into the actual
> registers, and the SW_UPDATE bit will be cleared.
>
> The problem is that before this commit our suspend/resume handling
> consisted of simply saving the PWM ctrl register on suspend and
> restoring it on resume, without setting the PWM_SW_UPDATE bit.
> When the controller has lost its state over a suspend/resume and thus
> has been reset to the defaults, just restoring the register is not
> enough. We must also set the SW_UPDATE bit to tell the controller to
> latch the restored values into the actual registers.
>
> Fixing this problem is not as simple as just or-ing in the value which
> is being restored with SW_UPDATE. If the PWM was enabled before we must
> write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
> We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
> model we must do this either before or after the setting of PWM_ENABLE.
>
> All the necessary logic for doing this is already present inside
> pwm_lpss_apply(), so instead of duplicating this inside the resume
> handler, this commit makes the resume handler use pwm_lpss_apply() to
> restore the settings when necessary. This fixes the output-freq and
> duty-cycle being reset to their defaults on resume.
...
> +static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state, bool from_resume)
> {
> struct pwm_lpss_chip *lpwm = to_lpwm(chip);
> int ret;
>
> if (state->enabled) {
> if (!pwm_is_enabled(pwm)) {
> - pm_runtime_get_sync(chip->dev);
> + if (!from_resume)
> + pm_runtime_get_sync(chip->dev);
> +
> ret = pwm_lpss_is_updating(pwm);
> if (ret) {
> - pm_runtime_put(chip->dev);
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
> +
> return ret;
> }
> pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
> state->period);
> pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
> ret = pwm_lpss_wait_for_update(pwm);
> if (ret) {
> - pm_runtime_put(chip->dev);
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
> +
> return ret;
> }
> pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
> }
> } else if (pwm_is_enabled(pwm)) {
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> - pm_runtime_put(chip->dev);
> +
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
> }
I'm wondering if splitting more will make this look better, like:
...
if (from_resume) {
ret = pwm_lpss_prepare_enable(...); // whatever name you think
suits better
} else {
pm_runtime_get_sync(...);
ret = pwm_lpss_prepare_enable(...);
if (ret)
pm_runtime_put(...);
}
...
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-fence annotations, round 3 (rev6)
== Series Details ==
Series: dma-fence annotations, round 3 (rev6)
URL : https://patchwork.freedesktop.org/series/79212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8718 -> Patchwork_18122
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/index.html
Known issues
Here are the changes found in Patchwork_18122 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_8718/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-apl-guc/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-kbl-soraka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +2 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-kbl-soraka/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@prime_vgem@basic-fence-flip:
- fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][13] ([i915#1888]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.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_8718/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_pm:
- fi-apl-guc: [DMESG-FAIL][17] ([i915#1751]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-tgl-y/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-kbl-7560u}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18122/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-plain-flip@d-dsi1:
- {fi-tgl-dsi}: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26] +2
similar issues
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
[26]:
Re: [Intel-gfx] [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value
Hi,
On 7/9/20 2:53 PM, Andy Shevchenko wrote:
On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote:
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.
And I don't see how you can get duty 100% / 0% (I don't remember which one is
equivalent to 0 in base unit) after this change. IIRC the problem here that
base unit when non-zero is always being added to the counter and it will
trigger the change of output at some point which is not what we want for 100% /
0% cases.
The base_unit controls the output frequency, not the duty-cycle. So clamping
the base_unit, as calculated from the period here, which also only configures
output-frequency does not impact the duty-cycle at all.
note that AFAICT currently no (in kernel) users actually try to set a period
value
which would hit the clamp, so for existing users the clamp is a no-op. I just
added it to this patch-set for correctness sake and because userspace
(sysfs interface) users could in theory set out of range values.
As for the duty-cycle thing, first of all let me say that that is a
question / issue which is completely orthogonal to this patch, this
patch only impacts the period/output frequency NOT the duty-cycle,
With that said, the documentation is not really helpful here,
we need to set the on_time_div to 255 to get a duty-cycle close to 0
(and to 0 to get a duty cycle of 100%) but if setting this to 255 gives
us a duty-cycle of really really 0%, or just close to 0% is uncleaer.
We could do a separate patch add ing a hack where if the user asks for
0% duty-cycle we program the base_unit to 0, but that seems like a bad
idea for 2 reasons:
1. If the user really wants the output to be constantly 0 the user should
just disable the pwm
2. New base_unit values are latched and not applied until the counter
overflows, with a base_unit of 0 the counter never overflows. I have
not tested this but I would not be surprised if after programming a
base_unit value of 0, we are unable to ever change the value again
through any other means then power-cycling the PWM controller.
Even if I could test this on some revisions, we already know that
not all revisions work the same wrt the latching. So it is best to
just never set base_unit to 0, that is just a recipe asking for trouble.
When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:
base_unit &= (base_unit_range - 1);
But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.
It would be nice to have an example of calculus here.
This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).
Eventually I sat and wrote all this on paper. I see now that the problem
is in out of range of the period. And strongly we should clamp rather period
to the supported range, but your solution is an equivalent.
Right, the advantage of doing the clamping on the register value is that we
avoid some tricky math with possible rounding errors and which is different
per controller revision because the number of bits in the base unit being
different per controller revision.
Only question is about the 100% / 0% duty cycle.
See my answer to that above.
Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Signed-off-by: Hans de Goede
---
Changes in v3:
- Change upper limit of clamp to (base_unit_range - 1)
- Add Fixes tag
---
drivers/pwm/pwm-lpss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b1fc634af1..80d0f9c64f9d 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
freq *= base_unit_range;
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
+ /* base_unit must not be 0 and we also want to avoid overflowing it */
+ base_unit = clamp_t(unsigned long long, base_unit, 1,
+ base_unit_range - 1);
A nit: one line.
Doesn't fit in 80 chars, I guess we could make this one line now with the new
100 chars
limit, but that does make it harder
Re: [Intel-gfx] [PATCH v7 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
On 2020-07-02 at 20:07:36 +0530, Anshuman Gupta wrote:
> On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> > wrote:
> > >
> > > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote:
> > > Hi Sean,
> > > I am new to DP MST stuff, I am looking to DP MST spec DP v1.2a.
> > > I have looked the entire series, i will take up this opportunity to review
> > > the series from HDCP over DP MST POV.
> > > I think theoretically this series should work or Gen12 as well, as DP MST
> > > streams
> > > are getting encrypted by QUERY_STREAM_ENCRYPTION_STATUS reply tranaction
> > > msg
> > > (generating Stream State Signature L’).
> > > I will test this on Gen12 H/W with DP MST support and will provide my
> > > inputs.
> > >
> > > Meanwhile while going through DP MST v1.2a specs(Page 262) came to know
> > > about
> > > a DP irq vector LINK_SERVICE_IRQ_VECTOR_ESI0 (02005h),
> > > Bit 2 : STREAM_STATUS_CHANGED.
> > > When this bit set to ‘1’ indicates the source must re-check the Stream
> > > Status
> > > with the QUERY_STREAM_ENCRYPTION_STATUS message.
> > > Currently i feel this irq support is missing, do we require to support
> > > above IRQ vector for DP MST stream encryption.
> > >
> >
> > Hi Anshuman,
> > Thank you for your comments.
> >
> > QUERY_STREAM_ENCRYPTION_STATUS is not necessary for HDCP 1.x, I added
> > this as a safety check to ensure that the streams were being
> > encrypted. As such, the existing integrity checks in place for DP are
> > sufficient to satisfy spec. When HDCP 2.2 support is added for MST,
> > handling QSES will need to be addressed to meet spec. Note also that
> > we're not validating the QSES signature for the same reason.
> Thanks sean for the explanation,
> overall patch looks good to me but i have couple of doubt see below.
> >
> > Sean
> >
> >
> > > Thanks,
> > > Anshuman Gupta.
> > >
> > > > From: Sean Paul
> > > >
> > > > Used to query whether an MST stream is encrypted or not.
> > > >
> > > > Signed-off-by: Sean Paul
> > > >
> > > > Link:
> > > > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> > > > #v4
> > > > Link:
> > > > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
> > > > #v5
> > > > Link:
> > > > https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
> > > > #v6
> > > >
> > > > Changes in v4:
> > > > -Added to the set
> > > > Changes in v5:
> > > > -None
> > > > Changes in v6:
> > > > -Use FIELD_PREP to generate request buffer bitfields (Lyude)
> > > > -Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
> > > > Changes in v7:
> > > > -None
> > > > ---
> > > > drivers/gpu/drm/drm_dp_mst_topology.c | 142 ++
> > > > .../drm/selftests/test-drm_dp_mst_helper.c| 17 +++
> > > > include/drm/drm_dp_helper.h | 3 +
> > > > include/drm/drm_dp_mst_helper.h | 44 ++
> > > > 4 files changed, 206 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index b2f5a84b4cfb..fc68478eaeb4 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -20,11 +20,13 @@
> > > > * OF THIS SOFTWARE.
> > > > */
> > > >
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -419,6 +421,22 @@ drm_dp_encode_sideband_req(const struct
> > > > drm_dp_sideband_msg_req_body *req,
> > > > memcpy([idx], req->u.i2c_write.bytes,
> > > > req->u.i2c_write.num_bytes);
> > > > idx += req->u.i2c_write.num_bytes;
> > > > break;
> > > > + case DP_QUERY_STREAM_ENC_STATUS: {
> > > > + const struct drm_dp_query_stream_enc_status *msg;
> > > > +
> > > > + msg = >u.enc_status;
> > > > + buf[idx] = msg->stream_id;
> > > > + idx++;
> > > > + memcpy([idx], msg->client_id, sizeof(msg->client_id));
> > > > + idx += sizeof(msg->client_id);
> > > > + buf[idx] = 0;
> > > > + buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
> > > > + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> > > > + buf[idx] |= FIELD_PREP(GENMASK(4, 3),
> > > > msg->stream_behavior);
> > > > + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> > > > + idx++;
> > > > + }
> > > > + break;
> > > > }
> > > > raw->cur_len = idx;
> > > > }
> > > > @@ -547,6 +565,20 @@ drm_dp_decode_sideband_req(const struct
> > > > drm_dp_sideband_msg_tx *raw,
> > > > return -ENOMEM;
> > > > }
> > > > break;
> > > > + case
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-fence annotations, round 3 (rev6)
== Series Details == Series: dma-fence annotations, round 3 (rev6) URL : https://patchwork.freedesktop.org/series/79212/ 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/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning: cast to restricted __le16
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-fence annotations, round 3 (rev6)
== Series Details ==
Series: dma-fence annotations, round 3 (rev6)
URL : https://patchwork.freedesktop.org/series/79212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6993be4b66a4 dma-fence: basic lockdep annotations
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e91498589746
("locking/lockdep/selftests: Add mixed read-write ABBA tests")'
#23:
commit e91498589746065e3ae95d9a00b068e525eec34f
-:97: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e966eaeeb623 ("locking/lockdep:
Remove the cross-release locking checks")'
#97:
commit e966eaeeb623f09975ef362c2866fae6f86844f9
-:103: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#103:
This code (CONFIG_LOCKDEP_CROSSRELEASE=y and
CONFIG_LOCKDEP_COMPLETIONS=y),
-:303: ERROR:IN_ATOMIC: do not use in_atomic in drivers
#303: FILE: drivers/dma-buf/dma-fence.c:228:
+ if (in_atomic())
-:341: CHECK:LINE_SPACING: Please don't use multiple blank lines
#341: FILE: drivers/dma-buf/dma-fence.c:266:
+
+
-:390: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#390: FILE: include/linux/dma-fence.h:368:
+}
+static inline void dma_fence_end_signalling(bool cookie) {}
-:396: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 3 errors, 2 warnings, 2 checks, 217 lines checked
550e03fe8f5d dma-fence: prime lockdep annotations
-:31: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 23b68395c7c7 ("mm/mmu_notifiers:
add a lockdep map for invalidate_range_start/end")'
#31:
commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
-:193: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 91 lines checked
235ccf350083 drm/virtio: Remove open-coded commit-tail function
-:54: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 32 lines checked
f5a16e131fbb drm/vkms: Annotate vblank timer
-:59: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 25 lines checked
855bf7ca2525 drm/vblank: Annotate with dma-fence signalling section
-:71: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 38 lines checked
37fe1fb7e37d drm/amdgpu: add dma-fence annotations to atomic commit path
-:52: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 24 lines checked
5d76f227525e drm/komdea: Annotate dma-fence critical section in commit path
-:47: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 15 lines checked
8925fab7b0c5 drm/malidp: Annotate dma-fence critical section in commit path
-:38: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 15 lines checked
75d8ed548bbf drm/atmel: Use drm_atomic_helper_commit
-:213: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 170 lines checked
5b7ea987488e drm/imx: Annotate dma-fence critical section in commit path
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 21a01abbe32a ("drm/atomic: Fix
freeing connector/plane state too early by tracking commits, v3.")'
#14:
commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648
-:50: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
d525fd5dc000 drm/omapdrm: Annotate dma-fence critical section in commit path
-:54: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 29 lines checked
49148da69b74 drm/rcar-du: Annotate dma-fence critical section in commit path
-:34: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
627ff2bada55 drm/tegra: Annotate dma-fence critical section in commit path
-:34: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
ee1ca3dd92f2 drm/tidss: Annotate dma-fence critical section in commit path
-:41: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author
Re: [Intel-gfx] [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value
On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote:
> When the user requests a high enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
>
> But according to the data-sheet the way the PWM controller works is that
> each input clock-cycle the base_unit gets added to a N bit counter and
> that counter overflowing determines the PWM output frequency. Adding 0
> to the counter is a no-op. The data-sheet even explicitly states that
> writing 0 to the base_unit bits will result in the PWM outputting a
> continuous 0 signal.
And I don't see how you can get duty 100% / 0% (I don't remember which one is
equivalent to 0 in base unit) after this change. IIRC the problem here that
base unit when non-zero is always being added to the counter and it will
trigger the change of output at some point which is not what we want for 100% /
0% cases.
> When the user requestes a low enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value
> which is bigger then base_unit_range - 1. Currently the codes for this
> deals with this by applying a mask:
>
> base_unit &= (base_unit_range - 1);
>
> But this means that we let the value overflow the range, we throw away the
> higher bits and store whatever value is left in the lower bits into the
> register leading to a random output frequency, rather then clamping the
> output frequency to the highest frequency which the hardware can do.
It would be nice to have an example of calculus here.
> This commit fixes both issues by clamping the base_unit value to be
> between 1 and (base_unit_range - 1).
Eventually I sat and wrote all this on paper. I see now that the problem
is in out of range of the period. And strongly we should clamp rather period
to the supported range, but your solution is an equivalent.
Only question is about the 100% / 0% duty cycle.
> Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Change upper limit of clamp to (base_unit_range - 1)
> - Add Fixes tag
> ---
> drivers/pwm/pwm-lpss.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 43b1fc634af1..80d0f9c64f9d 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
> struct pwm_device *pwm,
> freq *= base_unit_range;
>
> base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
> + /* base_unit must not be 0 and we also want to avoid overflowing it */
> + base_unit = clamp_t(unsigned long long, base_unit, 1,
> + base_unit_range - 1);
A nit: one line.
> on_time_div = 255ULL * duty_ns;
> do_div(on_time_div, period_ns);
> @@ -105,7 +108,6 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
> struct pwm_device *pwm,
> orig_ctrl = ctrl = pwm_lpss_read(pwm);
> ctrl &= ~PWM_ON_TIME_DIV_MASK;
> ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
> - base_unit &= (base_unit_range - 1);
> ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
> ctrl |= on_time_div;
>
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function
On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote: > Exactly matches the one in the helpers. > > This avoids me having to roll out dma-fence critical section > annotations to this copy. > > Signed-off-by: Daniel Vetter > Cc: David Airlie > Cc: Gerd Hoffmann > Cc: virtualizat...@lists.linux-foundation.org Acked-by: Gerd Hoffmann ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
Hi,
On 7/8/20 11:25 PM, Alex Deucher wrote:
On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede wrote:
Hi All,
Here is the privacy-screen related code which we discussed a while ago.
This series consists of a number of different parts:
1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties
2. Since on most devices the privacy screen is actually controlled by
some vendor specific ACPI/WMI interface which has a driver under
drivers/platform/x86, we need some "glue" code to make this functionality
available to KMS drivers. Patches 3-5 add a new privacy-screen class for
this, which allows non KMS drivers (and possibly KMS drivers too) to
register a privacy-screen device and also adds an interface for KMS drivers
to get access to the privacy-screen associated with a specific connector.
This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
kernel, including separate includes for consumers and providers(drivers).
3. Some drm_connector helper functions to keep the actual changes needed
for this in individual KMS drivers as small as possible (patch 6).
4. Make the thinkpad_acpi code register a privacy-screen device on
ThinkPads with a privacy-screen (patches 7-8)
5. Make the i915 driver export the privacy-screen functionality through
the connector properties on the eDP connector.
Care to create a patch 10 for amdgpu? Lenovo sells AMD thinkpads with
a privacy screen as well, presumably it works
the same way.
Yes the AMD based Thinkpads should work the same way.
We will need similar changes for amdgpu and very likely also for
nouveau. The problem is I don't really have hw to test this.
Do you have access to a recent thinkpad with amdgpu ? It does not need
to have a privacy screen, as long as it is new enough that the ACPI
tables have the GSSS and methods you can test by ignoring
the presence bit for the privacy-screen, I use this little change for
that:
From 9438bababe77dfccbade5c2377bdc7d6a777a6c6 Mon Sep 17 00:00:00 2001
From: Hans de Goede
Date: Wed, 27 May 2020 14:38:42 +0200
Subject: [PATCH] platform/x86: thinkpad_acpi: Hack to allow testing
on devices without a privacy-screen
Hack to allow testing on devices without a privacy-screen.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen_x86.c | 4
drivers/platform/x86/thinkpad_acpi.c | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c
b/drivers/gpu/drm/drm_privacy_screen_x86.c
index f486d9087819..87725766a90d 100644
--- a/drivers/gpu/drm/drm_privacy_screen_x86.c
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -41,7 +41,11 @@ static bool __init detect_thinkpad_privacy_screen(void)
if (ACPI_FAILURE(status))
return false;
+#if 1
+ return true;
+#else
return (output & 0x1) ? true : false;
+#endif
}
static const struct arch_init_data arch_init_data[] __initconst = {
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 1583c18f7f77..92aad746d1f8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9747,8 +9747,8 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct
*iibm)
if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0))
return -EIO;
- if (!(output & 0x1))
- return 0;
+// if (!(output & 0x1))
+// return 0;
lcdshadow_dev = drm_privacy_screen_register(_pdev->dev,
_ops);
--
2.26.2
So if you have a machine with an AMDGPU and with the mentioned ACPI methods,
then you should be able to implement this yourself. You can read/write the new
props under X11 with xrandr. And you monitor if the changes make it to the
hardware by doing:
cat /proc/acpi/ibm/lcdshadow
And you can simulate external changes (like through a hotkey handled by the
embedded-controller) by doing:
echo 0 > /proc/acpi/ibm/lcdshadow
echo 1 > /proc/acpi/ibm/lcdshadow
When you do this you should see udev change events for the properties, you
can test for those by doing:
sudo udevadm monitor -u -p
###
With all that said, I can take a shot at blindly implementing this for amdgpu
but I would greatly prefer an actually tested patch, even if it is tested in
the way described above. When the patch is ready you can just send it to me
and I'll add my s-o-b and add it as patch 10 in the patch-set for the next
version.
Regards,
Hans
I was a bit in doubt if I should calls this series a RFC, or just call
it v1, since there is no real userspace code using this yet. It was
tested using xrandr property access and udevadm event monitoring.
I do expect / hope we will have patches for a userspace consumer of the
new properties (mutter) ready soon.
But since the code is completely ready, including API documentation,
I've decided to just call
Re: [Intel-gfx] [PATCH v7 17/17] drm/i915: Add HDCP 1.4 support for MST connectors
On 2020-07-09 at 16:07:12 +0530, Ramalingam C wrote:
> On 2020-06-23 at 11:59:07 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> > MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> > support is the same as the DP case, so we'll re-use those callbacks
> >
> > Cc: Juston Li
> > Signed-off-by: Sean Paul
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
> > #v1
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
> > #v2
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
> > #v3
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
> > #v4
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
> > #v5
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
> > #v6
> >
> > Changes in v2:
> > -Toggle HDCP from encoder disable/enable
> > -Don't disable HDCP on MST connector destroy, leave that for encoder
> > disable, just ensure the check_work routine isn't running any longer
> > Changes in v3:
> > -Place the shim in the new intel_dp_hdcp.c file (Ville)
> > Changes in v4:
> > -Actually use the mst shim for mst connections (Juston)
> > -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
> > Changes in v5:
> > -Add sleep on disable signalling to match hdmi delay
> > Changes in v6:
> > -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
> > don't have hardware to test it
> > Changes in v7:
> > -Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++
> > drivers/gpu/drm/i915/display/intel_hdcp.c| 2 +-
> > 3 files changed, 84 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index 43446a6cae8d..3f67bd27fc3c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -7,10 +7,12 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > #include "intel_display_types.h"
> > +#include "intel_ddi.h"
> > #include "intel_dp.h"
> > #include "intel_hdcp.h"
> >
> > @@ -618,6 +620,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim
> > = {
> > .protocol = HDCP_PROTOCOL_DP,
> > };
> >
> > +static int
> > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> > *intel_dig_port,
> > + enum transcoder cpu_transcoder,
> > + bool enable)
> > +{
> > + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> > + int ret;
> > +
> > + if (!enable)
> > + usleep_range(6, 60); /* Bspec says >= 6us */
> > +
> > + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base,
> > + cpu_transcoder, enable);
> Sean,
>
> This function toggles the TRANS_DDI_HDCP_SIGNALLING (9th)bit of
> TRANS_DDI_FUNC_CTL(tran)
> But in the hw specification this bit is mentioned to be ignored for non
> HDMI/DVI modes of the TRANS DDI.
>
> Any reason why we need this? Did you try with out this function?
>
> Apart from that Patch looks good to me.
IMHO it seems we are still missing to enable the Multistream HDCP Select
bit (5) in TRANS_DDI_FUNC_CTL register which is required to enable the
stream encryption.
Thanks,
Anshuman Gupta.
>
> -Ram
>
> > + if (ret)
> > + drm_dbg_kms(>drm, "%s HDCP signalling failed (%d)\n",
> > + enable ? "Enable" : "Disable", ret);
> > + return ret;
> > +}
> > +
> > +static
> > +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port
> > *intel_dig_port,
> > + struct intel_connector *connector)
> > +{
> > + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> > + struct intel_dp *intel_dp = _dig_port->dp;
> > + struct drm_dp_query_stream_enc_status_ack_reply reply;
> > + int ret;
> > +
> > + if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
> > + return false;
> > +
> > + ret = drm_dp_send_query_stream_enc_status(_dp->mst_mgr,
> > + connector->port, );
> > + if (ret) {
> > + drm_dbg_kms(>drm,
> > + "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> > + connector->base.base.id, connector->base.name, ret);
> > + return false;
> > + }
> > +
> > + return reply.auth_completed && reply.encryption_enabled;
> > +}
> > +
> > +static const struct
[Intel-gfx] [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function
Exactly matches the one in the helpers.
This avoids me having to roll out dma-fence critical section
annotations to this copy.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_display.c | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..af55b334be2f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return _gpu_fb->base;
}
-static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
-{
- struct drm_device *dev = state->dev;
-
- drm_atomic_helper_commit_modeset_disables(dev, state);
- drm_atomic_helper_commit_modeset_enables(dev, state);
- drm_atomic_helper_commit_planes(dev, state, 0);
-
- drm_atomic_helper_fake_vblank(state);
- drm_atomic_helper_commit_hw_done(state);
-
- drm_atomic_helper_wait_for_vblanks(dev, state);
- drm_atomic_helper_cleanup_planes(dev, state);
-}
-
-static const struct drm_mode_config_helper_funcs virtio_mode_config_helpers = {
- .atomic_commit_tail = vgdev_atomic_commit_tail,
-};
-
static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = {
.fb_create = virtio_gpu_user_framebuffer_create,
.atomic_check = drm_atomic_helper_check,
@@ -346,7 +327,6 @@ void virtio_gpu_modeset_init(struct virtio_gpu_device
*vgdev)
drm_mode_config_init(vgdev->ddev);
vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
vgdev->ddev->mode_config.funcs = _gpu_mode_funcs;
- vgdev->ddev->mode_config.helper_private = _mode_config_helpers;
/* modes will be validated against the framebuffer size */
vgdev->ddev->mode_config.min_width = XRES_MIN;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.
v2: Now with dot graph!
v3: Typo (Dave Airlie)
Acked-by: Christian König
Acked-by: Daniel Stone
Cc: Jesse Natalie
Cc: Steve Pronovost
Cc: Jason Ekstrand
Cc: Felix Kuehling
Cc: Mika Kuoppala
Cc: Thomas Hellstrom
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/dma-buf.rst | 70
1 file changed, 70 insertions(+)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index f8f6decde359..100bfd227265 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
.. kernel-doc:: include/linux/sync_file.h
:internal:
+Indefinite DMA Fences
+
+
+At various times _fence with an indefinite time until dma_fence_wait()
+finishes have been proposed. Examples include:
+
+* Future fences, used in HWC1 to signal when a buffer isn't used by the display
+ any longer, and created with the screen update that makes the buffer visible.
+ The time this fence completes is entirely under userspace's control.
+
+* Proxy fences, proposed to handle _syncobj for which the fence has not yet
+ been set. Used to asynchronously delay command submission.
+
+* Userspace fences or gpu futexes, fine-grained locking within a command buffer
+ that userspace uses for synchronization across engines or with the CPU, which
+ are then imported as a DMA fence for integration into existing winsys
+ protocols.
+
+* Long-running compute command buffers, while still using traditional end of
+ batch DMA fences for memory management instead of context preemption DMA
+ fences which get reattached when the compute job is rescheduled.
+
+Common to all these schemes is that userspace controls the dependencies of
these
+fences and controls when they fire. Mixing indefinite fences with normal
+in-kernel DMA fences does not work, even when a fallback timeout is included to
+protect against malicious userspace:
+
+* Only the kernel knows about all DMA fence dependencies, userspace is not
aware
+ of dependencies injected due to memory management or scheduler decisions.
+
+* Only userspace knows about all dependencies in indefinite fences and when
+ exactly they will complete, the kernel has no visibility.
+
+Furthermore the kernel has to be able to hold up userspace command submission
+for memory management needs, which means we must support indefinite fences
being
+dependent upon DMA fences. If the kernel also support indefinite fences in the
+kernel like a DMA fence, like any of the above proposal would, there is the
+potential for deadlocks.
+
+.. kernel-render:: DOT
+ :alt: Indefinite Fencing Dependency Cycle
+ :caption: Indefinite Fencing Dependency Cycle
+
+ digraph "Fencing Cycle" {
+ node [shape=box bgcolor=grey style=filled]
+ kernel [label="Kernel DMA Fences"]
+ userspace [label="userspace controlled fences"]
+ kernel -> userspace [label="memory management"]
+ userspace -> kernel [label="Future fence, fence proxy, ..."]
+
+ { rank=same; kernel userspace }
+ }
+
+This means that the kernel might accidentally create deadlocks
+through memory management dependencies which userspace is unaware of, which
+randomly hangs workloads until the timeout kicks in. Workloads, which from
+userspace's perspective, do not contain a deadlock. In such a mixed fencing
+architecture there is no single entity with knowledge of all dependencies.
+Thefore preventing such deadlocks from within the kernel is not possible.
+
+The only solution to avoid dependencies loops is by not allowing indefinite
+fences in the kernel. This means:
+
+* No future fences, proxy fences or userspace fences imported as DMA fences,
+ with or without a timeout.
+
+* No DMA fences that signal end of batchbuffer for command submission where
+ userspace is allowed to use userspace fencing or long running compute
+ workloads. This also means no implicit fencing for shared buffers in these
+ cases.
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea
On Thu, Jul 9, 2020 at 2:11 PM Daniel Stone wrote: > > On Thu, 9 Jul 2020 at 09:05, Daniel Vetter wrote: > > On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote: > > > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter wrote: > > > > Comes up every few years, gets somewhat tedious to discuss, let's > > > > write this down once and for all. > > > > > > Thanks for writing this up! I wonder if any of the notes from my reply > > > to the previous-version thread would be helpful to more explicitly > > > encode the carrot of dma-fence's positive guarantees, rather than just > > > the stick of 'don't do this'. ;) Either way, this is: > > > > I think the carrot should go into the intro section for dma-fence, this > > section here is very much just the "don't do this" part. The previous > > patches have an attempt at encoding this a bit, maybe see whether there's > > a place for your reply (or parts of it) to fit? > > Sounds good to me. > > > > Acked-by: Daniel Stone > > > > > > > What I'm not sure about is whether the text should be more explicit in > > > > flat out mandating the amdkfd eviction fences for long running compute > > > > workloads or workloads where userspace fencing is allowed. > > > > > > ... or whether we just say that you can never use dma-fence in > > > conjunction with userptr. > > > > Uh userptr is entirely different thing. That one is ok. It's userpsace > > fences or gpu futexes or future fences or whatever we want to call them. > > Or is there some other confusion here?. > > I mean generating a dma_fence from a batch which will try to page in > userptr. Given that userptr could be backed by absolutely anything at > all, it doesn't seem smart to allow fences to rely on a pointer to an > mmap'ed NFS file. So it seems like batches should be mutually > exclusive between arbitrary SVM userptr and generating a dma-fence? Locking is Tricky (tm) but essentially what at least amdgpu does is pull in the backing storage before we publish any dma-fence. And then some serious locking magic to make sure that doesn't race with a core mm invalidation event. So for your case here the cs ioctl just blocks until the nfs pages are pulled in. Once we've committed for the dma-fence it's only the other way round, i.e. core mm will stall on the dma-fence if it wants to throw out these pages again. More or less at least. That way we never have a dma-fence depending upon any core mm operations. The only pain here is that this severely limits what you can do in the critical path towards signalling a dma-fence, because the tldr is "no interacting with core mm at all allowed". > Speaking of entirely different things ... the virtio-gpu bit really > doesn't belong in this patch. Oops, dunno where I lost that as a sparate patch. Will split out again :-( -Daniel > > Cheers, > Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for vfio/pci: Refine Intel IGD OpRegion support
== Series Details == Series: vfio/pci: Refine Intel IGD OpRegion support URL : https://patchwork.freedesktop.org/series/79293/ State : success == Summary == CI Bug Log - changes from CI_DRM_8718_full -> Patchwork_18120_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_18120_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18120_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_18120_full: ### IGT changes ### Warnings * igt@runner@aborted: - shard-tglb: ([FAIL][1], [FAIL][2]) ([i915#2110]) -> ([FAIL][3], [FAIL][4]) ([i915#1764] / [i915#2110]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-tglb7/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-tglb8/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-tglb3/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-tglb7/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18120_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#1528]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl2/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-kbl1/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_exec_params@invalid-fence-in: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl3/igt@gem_exec_par...@invalid-fence-in.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-kbl3/igt@gem_exec_par...@invalid-fence-in.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#198] / [i915#2110]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-skl2/igt@i915_selftest@m...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-skl1/igt@i915_selftest@m...@requests.html * igt@i915_suspend@fence-restore-untiled: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#165]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl4/igt@i915_susp...@fence-restore-untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-kbl6/igt@i915_susp...@fence-restore-untiled.html * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing@edp-1-pipe-a: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +9 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-skl3/igt@kms_atomic_transition@plane-all-transition-nonblocking-fenc...@edp-1-pipe-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-skl2/igt@kms_atomic_transition@plane-all-transition-nonblocking-fenc...@edp-1-pipe-a.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1635] / [i915#95]) +14 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-apl2/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_edge_walk@pipe-b-128x128-left-edge: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-glk9/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18120/shard-glk4/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html * igt@kms_cursor_edge_walk@pipe-b-256x256-top-edge: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/shard-apl4/igt@kms_cursor_edge_w...@pipe-b-256x256-top-edge.html [22]:
Re: [Intel-gfx] [PATCH 7/9] drm/i915/sdvo: Make SDVO deal with HDMI pixel repeat
On Thu, Jul 09, 2020 at 02:47:10PM +0300, Imre Deak wrote:
> On Wed, Jan 08, 2020 at 08:12:40PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > With SDVO the pipe config pixel_multiplier only concerns itself with the
> > data on the SDVO bus. Any HDMI specific pixel repeat must be handled by
> > the SDVO device itself. To do that simply configure the SDVO pixel
> > replication factor appropriately. We already set up the infoframe PRB
> > values correctly via the infoframe helpers.
> >
> > There is no cap we can check for this. The spec says that 1X,2X,4X are
> > mandatory, anything else is optional. 1X and 2X are all we need so
> > we should be able to assume they work.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Imre Deak
>
> Shouldn't DRM_MODE_FLAG_DBLCLK be set for the read-out mode in
> intel_sdvo_get_config()?
Apparently we don't do that for HDMI either, and we don't check
it it in intel_pipe_config_compare() either. I guess we could add
the readout+check.
Although I've been actually tempted to just remove this flag
entirely since it only really should be set to boost the clock
above the magic 25MHz limit. Hmm, now I wonder if that limit
is about the TMDS clock or the dotclock actually. Would need to
read the spec once again. Anyways, the reason why I haven't
deprecated this flag yet is that IIRC some other drivers was
also using it for other purposes, and I was too lazy to figure
out what's going on there.
>
> > ---
> > drivers/gpu/drm/i915/display/intel_sdvo.c | 27 +++
> > 1 file changed, 23 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > index a0bbd728aa54..34d5bd750de8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > @@ -943,6 +943,13 @@ static bool intel_sdvo_set_colorimetry(struct
> > intel_sdvo *intel_sdvo,
> > return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_COLORIMETRY,
> > , 1);
> > }
> >
> > +static bool intel_sdvo_set_pixel_replication(struct intel_sdvo *intel_sdvo,
> > +u8 pixel_repeat)
> > +{
> > + return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_PIXEL_REPLI,
> > + _repeat, 1);
> > +}
> > +
> > static bool intel_sdvo_set_audio_state(struct intel_sdvo *intel_sdvo,
> >u8 audio_state)
> > {
> > @@ -1493,6 +1500,9 @@ static void intel_sdvo_pre_enable(struct
> > intel_encoder *intel_encoder,
> >SDVO_COLORIMETRY_RGB220 :
> >SDVO_COLORIMETRY_RGB256);
> > intel_sdvo_set_avi_infoframe(intel_sdvo, crtc_state);
> > + intel_sdvo_set_pixel_replication(intel_sdvo,
> > +!!(adjusted_mode->flags &
> > + DRM_MODE_FLAG_DBLCLK));
> > } else
> > intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_DVI);
> >
> > @@ -1839,17 +1849,26 @@ intel_sdvo_mode_valid(struct drm_connector
> > *connector,
> > struct intel_sdvo_connector *intel_sdvo_connector =
> > to_intel_sdvo_connector(connector);
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > + bool has_hdmi_sink = intel_has_hdmi_sink(intel_sdvo, connector->state);
> > + int clock = mode->clock;
> >
> > if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > return MODE_NO_DBLESCAN;
> >
> > - if (intel_sdvo->pixel_clock_min > mode->clock)
> > - return MODE_CLOCK_LOW;
> >
> > - if (intel_sdvo->pixel_clock_max < mode->clock)
> > + if (clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> >
> > - if (mode->clock > max_dotclk)
> > + if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
> > + if (!has_hdmi_sink)
> > + return MODE_CLOCK_LOW;
> > + clock *= 2;
> > + }
> > +
> > + if (intel_sdvo->pixel_clock_min > clock)
> > + return MODE_CLOCK_LOW;
> > +
> > + if (intel_sdvo->pixel_clock_max < clock)
> > return MODE_CLOCK_HIGH;
> >
> > if (IS_LVDS(intel_sdvo_connector)) {
> > --
> > 2.24.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
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Add a couple of missing i915_active_fini()
== Series Details ==
Series: series starting with [1/6] drm/i915: Add a couple of missing
i915_active_fini()
URL : https://patchwork.freedesktop.org/series/79297/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8718 -> Patchwork_18121
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/index.html
Known issues
Here are the changes found in Patchwork_18121 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_8718/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@kms_addfb_basic@invalid-get-prop-any:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-tgl-y/igt@kms_addfb_ba...@invalid-get-prop-any.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-tgl-y/igt@kms_addfb_ba...@invalid-get-prop-any.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_8718/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_18121/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_8718/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_pm:
- fi-apl-guc: [DMESG-FAIL][11] ([i915#1751]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
* igt@kms_flip@basic-plain-flip@d-dsi1:
- {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_8718/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-tgl-y/igt@vgem_ba...@setversion.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-tgl-y/igt@vgem_ba...@setversion.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#1982] / [i915#62] / [i915#92])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][19] ([fdo#109271]) -> [DMESG-FAIL][20]
([i915#62] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8718/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18121/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- 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_8718/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
[24]:
Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea
On Thu, 9 Jul 2020 at 09:05, Daniel Vetter wrote: > On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote: > > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter wrote: > > > Comes up every few years, gets somewhat tedious to discuss, let's > > > write this down once and for all. > > > > Thanks for writing this up! I wonder if any of the notes from my reply > > to the previous-version thread would be helpful to more explicitly > > encode the carrot of dma-fence's positive guarantees, rather than just > > the stick of 'don't do this'. ;) Either way, this is: > > I think the carrot should go into the intro section for dma-fence, this > section here is very much just the "don't do this" part. The previous > patches have an attempt at encoding this a bit, maybe see whether there's > a place for your reply (or parts of it) to fit? Sounds good to me. > > Acked-by: Daniel Stone > > > > > What I'm not sure about is whether the text should be more explicit in > > > flat out mandating the amdkfd eviction fences for long running compute > > > workloads or workloads where userspace fencing is allowed. > > > > ... or whether we just say that you can never use dma-fence in > > conjunction with userptr. > > Uh userptr is entirely different thing. That one is ok. It's userpsace > fences or gpu futexes or future fences or whatever we want to call them. > Or is there some other confusion here?. I mean generating a dma_fence from a batch which will try to page in userptr. Given that userptr could be backed by absolutely anything at all, it doesn't seem smart to allow fences to rely on a pointer to an mmap'ed NFS file. So it seems like batches should be mutually exclusive between arbitrary SVM userptr and generating a dma-fence? Speaking of entirely different things ... the virtio-gpu bit really doesn't belong in this patch. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/20] drm/i915/gem: Assign context id for async work
Quoting Tvrtko Ursulin (2020-07-09 12:59:51) > > On 09/07/2020 12:07, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-07-09 12:01:29) > >> > >> On 08/07/2020 16:36, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2020-07-08 15:24:20) > And what is the effective behaviour you get with N contexts - emit N > concurrent operations and for N + 1 block in execbuf? > >>> > >>> Each context defines a timeline. A task is not ready to run until the > >>> task before it in its timeline is completed. So we don't block in > >>> execbuf, the scheduler waits until the request is ready before putting > >>> it into the HW queues -- i.e. the number chain of fences with everything > >>> that entails about ensuring it runs to completion [whether successfully > >>> or not, if not we then rely on the error propagation to limit the damage > >>> and report it back to the user if they kept a fence around to inspect]. > >> > >> Okay but what is the benefit of N contexts in this series, before the > >> work is actually spread over ctx async width CPUs? Is there any? If not > >> I would prefer this patch is delayed until the time some actual > >> parallelism is ready to be added. > > > > We currently submit an unbounded amount of work. This patch is added > > along with its user to restrict the amount of work allowed to run in > > parallel, and also is used to [crudely] serialise the multiple threads > > attempting to allocate space in the vm when we completely exhaust that > > address space. We need at least one fence-context id for each user, this > > took the opportunity to generalise that to N ids for each user. > > Right, this is what I asked at the beginning - restricting amount of > work run in parallel - does mean there is some "blocking"/serialisation > during execbuf? Or it is all async but then what is restricted? It's all* async, so the number of workqueues we utilise is restricted, and so limits the number of CPUs we allow the one context to spread across with multiple execbufs. *fsvo all. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915: Reject DRM_MODE_FLAG_DBLCLK with DVI sinks
On Thu, Jul 09, 2020 at 02:01:19PM +0300, Imre Deak wrote:
> On Wed, Jan 08, 2020 at 08:12:39PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The code assumes that DRM_MODE_FLAG_DBLCLK means that we enable the
> > pixel repeat feature. That only works with HDMI since it requires
> > AVI infoframe to signal the information to the sink. Hence even if
> > the mode dotclock would be valid we cannot currently assume that
> > we can just ignore the DBLCLK flag. Reject it for DVI sinks.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Imre Deak
>
> > ---
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > index 85c5f840a0fc..a62dd3348301 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > @@ -2185,8 +2185,11 @@ intel_hdmi_mode_valid(struct drm_connector
> > *connector,
> > if (clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> >
> > - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > + if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
> > + if (!has_hdmi_sink)
> > + return MODE_CLOCK_LOW;
>
> MODE_H_ILLEGAL is used elsewhere for this case, and also an odd MODE_BAD
> at one place.
Not seeing the MODE_BAD. The MODE_H_ILLEGAL cases are in the DP code.
I think that check is kinda wrong for DP anyway, except possinbly when
driving a HDMI sink via the protocol converter. Can't be sure since
IIRC the DP spec doesn't really say whether protocol converters are
supposed to enable pixel repeat for the HDMI part or not.
I think I migth have had a patch somewhere to ignore this for non-HDMI
sinks in the DP code. Which at least should be safe.
>
> > clock *= 2;
> > + }
> >
> > if (drm_mode_is_420_only(>display_info, mode))
> > clock /= 2;
> > --
> > 2.24.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
Re: [Intel-gfx] [PATCH 09/20] drm/i915/gem: Assign context id for async work
On 09/07/2020 12:07, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-07-09 12:01:29) On 08/07/2020 16:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-07-08 15:24:20) And what is the effective behaviour you get with N contexts - emit N concurrent operations and for N + 1 block in execbuf? Each context defines a timeline. A task is not ready to run until the task before it in its timeline is completed. So we don't block in execbuf, the scheduler waits until the request is ready before putting it into the HW queues -- i.e. the number chain of fences with everything that entails about ensuring it runs to completion [whether successfully or not, if not we then rely on the error propagation to limit the damage and report it back to the user if they kept a fence around to inspect]. Okay but what is the benefit of N contexts in this series, before the work is actually spread over ctx async width CPUs? Is there any? If not I would prefer this patch is delayed until the time some actual parallelism is ready to be added. We currently submit an unbounded amount of work. This patch is added along with its user to restrict the amount of work allowed to run in parallel, and also is used to [crudely] serialise the multiple threads attempting to allocate space in the vm when we completely exhaust that address space. We need at least one fence-context id for each user, this took the opportunity to generalise that to N ids for each user. Right, this is what I asked at the beginning - restricting amount of work run in parallel - does mean there is some "blocking"/serialisation during execbuf? Or it is all async but then what is restricted? Regards, Tvrtko ___ 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 [1/6] drm/i915: Add a couple of missing i915_active_fini()
== Series Details == Series: series starting with [1/6] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/79297/ State : warning == Summary == $ dim checkpatch origin/drm-tip b4522cf919dd drm/i915: Add a couple of missing i915_active_fini() 368626fcdf2a drm/i915: Skip taking acquire mutex for no ref->active callback 747b770c0842 drm/i915: Export a preallocate variant of i915_active_acquire() 4934a21dfe00 drm/i915: Keep the most recently used active-fence upon discard 584e2a308747 drm/i915: Make the stale cached active node available for any timeline -:10: WARNING:TYPO_SPELLING: 'compatability' may be misspelled - perhaps 'compatibility'? #10: on 32b, so for compatability we just fallback to keeping the cached node total: 0 errors, 1 warnings, 0 checks, 34 lines checked 401b721f69ea drm/i915: Provide a fastpath for waiting on vma bindings ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea
Am 07.07.20 um 22:12 schrieb Daniel Vetter:
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.
v2: Now with dot graph!
Cc: Jesse Natalie
Cc: Steve Pronovost
Cc: Jason Ekstrand
Cc: Felix Kuehling
Cc: Mika Kuoppala
Cc: Thomas Hellstrom
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
Acked-by: Christian König
---
Documentation/driver-api/dma-buf.rst | 70
drivers/gpu/drm/virtio/virtgpu_display.c | 20 ---
2 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index f8f6decde359..037ba0078bb4 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
.. kernel-doc:: include/linux/sync_file.h
:internal:
+Idefinite DMA Fences
+
+
+At various times _fence with an indefinite time until dma_fence_wait()
+finishes have been proposed. Examples include:
+
+* Future fences, used in HWC1 to signal when a buffer isn't used by the display
+ any longer, and created with the screen update that makes the buffer visible.
+ The time this fence completes is entirely under userspace's control.
+
+* Proxy fences, proposed to handle _syncobj for which the fence has not yet
+ been set. Used to asynchronously delay command submission.
+
+* Userspace fences or gpu futexes, fine-grained locking within a command buffer
+ that userspace uses for synchronization across engines or with the CPU, which
+ are then imported as a DMA fence for integration into existing winsys
+ protocols.
+
+* Long-running compute command buffers, while still using traditional end of
+ batch DMA fences for memory management instead of context preemption DMA
+ fences which get reattached when the compute job is rescheduled.
+
+Common to all these schemes is that userspace controls the dependencies of
these
+fences and controls when they fire. Mixing indefinite fences with normal
+in-kernel DMA fences does not work, even when a fallback timeout is included to
+protect against malicious userspace:
+
+* Only the kernel knows about all DMA fence dependencies, userspace is not
aware
+ of dependencies injected due to memory management or scheduler decisions.
+
+* Only userspace knows about all dependencies in indefinite fences and when
+ exactly they will complete, the kernel has no visibility.
+
+Furthermore the kernel has to be able to hold up userspace command submission
+for memory management needs, which means we must support indefinite fences
being
+dependent upon DMA fences. If the kernel also support indefinite fences in the
+kernel like a DMA fence, like any of the above proposal would, there is the
+potential for deadlocks.
+
+.. kernel-render:: DOT
+ :alt: Indefinite Fencing Dependency Cycle
+ :caption: Indefinite Fencing Dependency Cycle
+
+ digraph "Fencing Cycle" {
+ node [shape=box bgcolor=grey style=filled]
+ kernel [label="Kernel DMA Fences"]
+ userspace [label="userspace controlled fences"]
+ kernel -> userspace [label="memory management"]
+ userspace -> kernel [label="Future fence, fence proxy, ..."]
+
+ { rank=same; kernel userspace }
+ }
+
+This means that the kernel might accidentally create deadlocks
+through memory management dependencies which userspace is unaware of, which
+randomly hangs workloads until the timeout kicks in. Workloads, which from
+userspace's perspective, do not contain a deadlock. In such a mixed fencing
+architecture there is no single entity with knowledge of all dependencies.
+Thefore preventing such deadlocks from within the kernel is not possible.
+
+The only solution to avoid dependencies loops is by not allowing indefinite
+fences in the kernel. This means:
+
+* No future fences, proxy fences or userspace fences imported as DMA fences,
+ with or without a timeout.
+
+* No DMA fences that signal end of batchbuffer for command submission where
+ userspace is allowed to use userspace fencing or long running compute
+ workloads. This also means no implicit fencing for shared buffers in these
+ cases.
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..af55b334be2f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return _gpu_fb->base;
}
-static void
Re: [Intel-gfx] [PATCH 9/9] drm/i915/dvo: Make .get_modes() return the number of modes
On Wed, Jan 08, 2020 at 08:12:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> .get_modes() is supposed to return the number of modes added to the
> probed_modes list (not that anyone actually checks for anything
> except zero vs. not zero). Let's do that.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dvo.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c
> b/drivers/gpu/drm/i915/display/intel_dvo.c
> index a74dc5b915d1..3ce9f72d12e5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_dvo.c
> @@ -322,6 +322,7 @@ static int intel_dvo_get_modes(struct drm_connector
> *connector)
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> const struct drm_display_mode *fixed_mode =
> to_intel_connector(connector)->panel.fixed_mode;
> + int num_modes;
>
> /*
>* We should probably have an i2c driver get_modes function for those
> @@ -329,21 +330,22 @@ static int intel_dvo_get_modes(struct drm_connector
> *connector)
>* (TV-out, for example), but for now with just TMDS and LVDS,
>* that's not the case.
>*/
> - intel_ddc_get_modes(connector,
> - intel_gmbus_get_adapter(dev_priv, GMBUS_PIN_DPC));
> - if (!list_empty(>probed_modes))
> - return 1;
> + num_modes = intel_ddc_get_modes(connector,
> + intel_gmbus_get_adapter(dev_priv,
> GMBUS_PIN_DPC));
> + if (num_modes)
> + return num_modes;
>
> if (fixed_mode) {
> struct drm_display_mode *mode;
> +
> mode = drm_mode_duplicate(connector->dev, fixed_mode);
> if (mode) {
> drm_mode_probed_add(connector, mode);
> - return 1;
> + num_modes++;
> }
> }
>
> - return 0;
> + return num_modes;
> }
>
> static const struct drm_connector_funcs intel_dvo_connector_funcs = {
> --
> 2.24.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 8/9] drm/i915/sdvo: Make .get_modes() return the number of modes
On Wed, Jan 08, 2020 at 08:12:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> .get_modes() is supposed to return the number of modes added to the
> probed_modes list (not that anyone actually checks for anything
> except zero vs. not zero). Let's do that. Also switch over to using
> intel_connector_update_modes() instead of hand rolling it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 56 +--
> 1 file changed, 33 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 34d5bd750de8..69ff297156cf 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2120,8 +2120,9 @@ intel_sdvo_detect(struct drm_connector *connector, bool
> force)
> return ret;
> }
>
> -static void intel_sdvo_get_ddc_modes(struct drm_connector *connector)
> +static int intel_sdvo_get_ddc_modes(struct drm_connector *connector)
> {
> + int num_modes = 0;
> struct edid *edid;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> @@ -2136,18 +2137,19 @@ static void intel_sdvo_get_ddc_modes(struct
> drm_connector *connector)
>* DDC fails, check to see if the analog output is disconnected, in
>* which case we'll look there for the digital DDC data.
>*/
> - if (edid == NULL)
> + if (!edid)
> edid = intel_sdvo_get_analog_edid(connector);
>
> - if (edid != NULL) {
> - if
> (intel_sdvo_connector_matches_edid(to_intel_sdvo_connector(connector),
> - edid)) {
> - drm_connector_update_edid_property(connector, edid);
> - drm_add_edid_modes(connector, edid);
> - }
> + if (!edid)
> + return 0;
>
> - kfree(edid);
> - }
> + if
> (intel_sdvo_connector_matches_edid(to_intel_sdvo_connector(connector),
> + edid))
> + num_modes += intel_connector_update_modes(connector, edid);
> +
> + kfree(edid);
> +
> + return num_modes;
> }
>
> /*
> @@ -2215,12 +2217,13 @@ static const struct drm_display_mode sdvo_tv_modes[]
> = {
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> };
>
> -static void intel_sdvo_get_tv_modes(struct drm_connector *connector)
> +static int intel_sdvo_get_tv_modes(struct drm_connector *connector)
> {
> struct intel_sdvo *intel_sdvo = intel_attached_sdvo(connector);
> const struct drm_connector_state *conn_state = connector->state;
> struct intel_sdvo_sdtv_resolution_request tv_res;
> u32 reply = 0, format_map = 0;
> + int num_modes = 0;
> int i;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> @@ -2235,31 +2238,37 @@ static void intel_sdvo_get_tv_modes(struct
> drm_connector *connector)
> min(sizeof(format_map), sizeof(struct
> intel_sdvo_sdtv_resolution_request)));
>
> if (!intel_sdvo_set_target_output(intel_sdvo,
> intel_sdvo->attached_output))
> - return;
> + return 0;
>
> BUILD_BUG_ON(sizeof(tv_res) != 3);
> if (!intel_sdvo_write_cmd(intel_sdvo,
> SDVO_CMD_GET_SDTV_RESOLUTION_SUPPORT,
> _res, sizeof(tv_res)))
> - return;
> + return 0;
> if (!intel_sdvo_read_response(intel_sdvo, , 3))
> - return;
> + return 0;
>
> - for (i = 0; i < ARRAY_SIZE(sdvo_tv_modes); i++)
> + for (i = 0; i < ARRAY_SIZE(sdvo_tv_modes); i++) {
> if (reply & (1 << i)) {
> struct drm_display_mode *nmode;
> nmode = drm_mode_duplicate(connector->dev,
> _tv_modes[i]);
> - if (nmode)
> + if (nmode) {
> drm_mode_probed_add(connector, nmode);
> + num_modes++;
> + }
> }
> + }
> +
> + return num_modes;
> }
>
> -static void intel_sdvo_get_lvds_modes(struct drm_connector *connector)
> +static int intel_sdvo_get_lvds_modes(struct drm_connector *connector)
> {
> struct intel_sdvo *intel_sdvo = intel_attached_sdvo(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> struct drm_display_mode *newmode;
> + int num_modes = 0;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -2276,6 +2285,7 @@ static void intel_sdvo_get_lvds_modes(struct
> drm_connector *connector)
> newmode->type = (DRM_MODE_TYPE_PREFERRED |
>DRM_MODE_TYPE_DRIVER);
> drm_mode_probed_add(connector, newmode);
> +
Re: [Intel-gfx] [PATCH 7/9] drm/i915/sdvo: Make SDVO deal with HDMI pixel repeat
On Wed, Jan 08, 2020 at 08:12:40PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> With SDVO the pipe config pixel_multiplier only concerns itself with the
> data on the SDVO bus. Any HDMI specific pixel repeat must be handled by
> the SDVO device itself. To do that simply configure the SDVO pixel
> replication factor appropriately. We already set up the infoframe PRB
> values correctly via the infoframe helpers.
>
> There is no cap we can check for this. The spec says that 1X,2X,4X are
> mandatory, anything else is optional. 1X and 2X are all we need so
> we should be able to assume they work.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
Shouldn't DRM_MODE_FLAG_DBLCLK be set for the read-out mode in
intel_sdvo_get_config()?
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 27 +++
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index a0bbd728aa54..34d5bd750de8 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -943,6 +943,13 @@ static bool intel_sdvo_set_colorimetry(struct intel_sdvo
> *intel_sdvo,
> return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_COLORIMETRY,
> , 1);
> }
>
> +static bool intel_sdvo_set_pixel_replication(struct intel_sdvo *intel_sdvo,
> + u8 pixel_repeat)
> +{
> + return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_PIXEL_REPLI,
> + _repeat, 1);
> +}
> +
> static bool intel_sdvo_set_audio_state(struct intel_sdvo *intel_sdvo,
> u8 audio_state)
> {
> @@ -1493,6 +1500,9 @@ static void intel_sdvo_pre_enable(struct intel_encoder
> *intel_encoder,
> SDVO_COLORIMETRY_RGB220 :
> SDVO_COLORIMETRY_RGB256);
> intel_sdvo_set_avi_infoframe(intel_sdvo, crtc_state);
> + intel_sdvo_set_pixel_replication(intel_sdvo,
> + !!(adjusted_mode->flags &
> + DRM_MODE_FLAG_DBLCLK));
> } else
> intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_DVI);
>
> @@ -1839,17 +1849,26 @@ intel_sdvo_mode_valid(struct drm_connector *connector,
> struct intel_sdvo_connector *intel_sdvo_connector =
> to_intel_sdvo_connector(connector);
> int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> + bool has_hdmi_sink = intel_has_hdmi_sink(intel_sdvo, connector->state);
> + int clock = mode->clock;
>
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> return MODE_NO_DBLESCAN;
>
> - if (intel_sdvo->pixel_clock_min > mode->clock)
> - return MODE_CLOCK_LOW;
>
> - if (intel_sdvo->pixel_clock_max < mode->clock)
> + if (clock > max_dotclk)
> return MODE_CLOCK_HIGH;
>
> - if (mode->clock > max_dotclk)
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
> + if (!has_hdmi_sink)
> + return MODE_CLOCK_LOW;
> + clock *= 2;
> + }
> +
> + if (intel_sdvo->pixel_clock_min > clock)
> + return MODE_CLOCK_LOW;
> +
> + if (intel_sdvo->pixel_clock_max < clock)
> return MODE_CLOCK_HIGH;
>
> if (IS_LVDS(intel_sdvo_connector)) {
> --
> 2.24.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] [PATCH 4/6] drm/i915: Keep the most recently used active-fence upon discard
Whenever an i915_active idles, we prune its tree of old fence slots to
prevent a gradual leak should it be used to track many, many timelines.
The downside is that we then have to frequently reallocate the rbtree.
A compromise is that we keep the most recently used fence slot, and
reuse that for the next active reference as that is the most likely
timeline to be reused.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 27 ---
drivers/gpu/drm/i915/i915_active.h | 4
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index a3a9295b22f7..46fdc7d98f40 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -130,8 +130,8 @@ static inline void debug_active_assert(struct i915_active
*ref) { }
static void
__active_retire(struct i915_active *ref)
{
+ struct rb_root root = RB_ROOT;
struct active_node *it, *n;
- struct rb_root root;
unsigned long flags;
GEM_BUG_ON(i915_active_is_idle(ref));
@@ -143,9 +143,21 @@ __active_retire(struct i915_active *ref)
GEM_BUG_ON(rcu_access_pointer(ref->excl.fence));
debug_active_deactivate(ref);
- root = ref->tree;
- ref->tree = RB_ROOT;
- ref->cache = NULL;
+ /* Even if we have not used the cache, we may still have a barrier */
+ if (!ref->cache)
+ ref->cache = fetch_node(ref->tree.rb_node);
+
+ /* Keep the MRU cached node for reuse */
+ if (ref->cache) {
+ /* Discard all other nodes in the tree */
+ rb_erase(>cache->node, >tree);
+ root = ref->tree;
+
+ /* Rebuild the tree with only the cached node */
+ rb_link_node(>cache->node, NULL, >tree.rb_node);
+ rb_insert_color(>cache->node, >tree);
+ GEM_BUG_ON(ref->tree.rb_node != >cache->node);
+ }
spin_unlock_irqrestore(>tree_lock, flags);
@@ -156,6 +168,7 @@ __active_retire(struct i915_active *ref)
/* ... except if you wait on it, you must manage your own references! */
wake_up_var(ref);
+ /* Finally free the discarded timeline tree */
rbtree_postorder_for_each_entry_safe(it, n, , node) {
GEM_BUG_ON(i915_active_fence_isset(>base));
kmem_cache_free(global.slab_cache, it);
@@ -729,16 +742,16 @@ int i915_sw_fence_await_active(struct i915_sw_fence
*fence,
return await_active(ref, flags, sw_await_fence, fence, fence);
}
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
void i915_active_fini(struct i915_active *ref)
{
debug_active_fini(ref);
GEM_BUG_ON(atomic_read(>count));
GEM_BUG_ON(work_pending(>work));
- GEM_BUG_ON(!RB_EMPTY_ROOT(>tree));
mutex_destroy(>mutex);
+
+ if (ref->cache)
+ kmem_cache_free(global.slab_cache, ref->cache);
}
-#endif
static inline bool is_idle_barrier(struct active_node *node, u64 idx)
{
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 73ded3c52a04..b9e0394e2975 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -217,11 +217,7 @@ i915_active_is_idle(const struct i915_active *ref)
return !atomic_read(>count);
}
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
void i915_active_fini(struct i915_active *ref);
-#else
-static inline void i915_active_fini(struct i915_active *ref) { }
-#endif
int i915_active_acquire_preallocate_barrier(struct i915_active *ref,
struct intel_engine_cs *engine);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Skip taking acquire mutex for no ref->active callback
If no active callback is defined for i915_active, we do not need to
serialise its enabling with the mutex. We still do only want to call the
debug activate once, and must still serialise with a concurrent retire.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d960d0be5bd2..841b5c30950a 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -416,6 +416,14 @@ bool i915_active_acquire_if_busy(struct i915_active *ref)
return atomic_add_unless(>count, 1, 0);
}
+static void __i915_active_activate(struct i915_active *ref)
+{
+ spin_lock_irq(>tree_lock); /* __active_retire() */
+ if (!atomic_fetch_inc(>count))
+ debug_active_activate(ref);
+ spin_unlock_irq(>tree_lock);
+}
+
int i915_active_acquire(struct i915_active *ref)
{
int err;
@@ -423,23 +431,22 @@ int i915_active_acquire(struct i915_active *ref)
if (i915_active_acquire_if_busy(ref))
return 0;
+ if (!ref->active) {
+ __i915_active_activate(ref);
+ return 0;
+ }
+
err = mutex_lock_interruptible(>mutex);
if (err)
return err;
if (likely(!i915_active_acquire_if_busy(ref))) {
- if (ref->active)
- err = ref->active(ref);
- if (!err) {
- spin_lock_irq(>tree_lock); /* __active_retire() */
- debug_active_activate(ref);
- atomic_inc(>count);
- spin_unlock_irq(>tree_lock);
- }
+ err = ref->active(ref);
+ if (!err)
+ __i915_active_activate(ref);
}
mutex_unlock(>mutex);
-
return err;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
