Re: [Intel-gfx] [git pull] drm fixes (regression special)
On Wed, Apr 24, 2019 at 3:21 AM Dave Airlie wrote: > > Hey Linus, > > We interrupt your regularly scheduled drm fixes for a regression special. > > The first is for a fix in i915 that had unexpected side effects > fallout in the userspace X.org modesetting driver where X would no > longer start. I got tired of the nitpicking and issued a large hammer > on it. The X.org driver is buggy, but blackscreen regressions are > worse. > > The second was an oversight that myself and Gerd should have noticed > better, Gerd is trying to fix this properly, but the regression is too > large to leave, even if the original behaviour is bad in some cases, > it's clearly bad to break a bunch of working use cases. > > I'll likely have a regular fixes pull later, but I really wanted to > highlight these. > > Dave. > > drm-fixes-2019-04-24: > drm regression fixes (i915 and virtio-gpu) > The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb: > > Linux 5.1-rc6 (2019-04-21 10:45:57 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-24 > > for you to fetch changes up to a0cecc23cfcbf2626497a8c8770856dd56b67917: > > Revert "drm/virtio: drop prime import/export callbacks" (2019-04-24 > 10:52:52 +1000) > > > drm regression fixes (i915 and virtio-gpu) > > > Dave Airlie (2): > Revert "drm/i915/fbdev: Actually configure untiled displays" This will conflict badly with the refactor in drm-next: commit 09ded8af57bcef7287b8242087d3e7556380de62 Author: Noralf Trønnes Date: Sun Apr 7 18:52:34 2019 +0200 drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper Probably best if we cherry-pick the revert over to avoid accidentally reintroducing this regression in the next merge window? Since the code moved I think a backmerge is to non-obvious about what's going on ... Adding Noralf. -Daniel > Revert "drm/virtio: drop prime import/export callbacks" > > drivers/gpu/drm/i915/intel_fbdev.c | 12 +--- > drivers/gpu/drm/virtio/virtgpu_drv.c | 4 > drivers/gpu/drm/virtio/virtgpu_drv.h | 4 > drivers/gpu/drm/virtio/virtgpu_prime.c | 12 > 4 files changed, 25 insertions(+), 7 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 drm/i915: Engine relative MMIO (rev4)
== Series Details == Series: drm/i915: Engine relative MMIO (rev4) URL : https://patchwork.freedesktop.org/series/57117/ State : success == Summary == CI Bug Log - changes from CI_DRM_5979_full -> Patchwork_12857_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12857_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@bsd2: - shard-iclb: NOTRUN -> [SKIP][1] ([fdo#109276]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-iclb4/igt@gem_exec_paral...@bsd2.html * igt@i915_pm_rpm@gem-execbuf-stress: - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([fdo#107803] / [fdo#107807]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5979/shard-skl9/igt@i915_pm_...@gem-execbuf-stress.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-skl9/igt@i915_pm_...@gem-execbuf-stress.html * igt@i915_pm_rpm@gem-mmap-cpu: - shard-skl: NOTRUN -> [INCOMPLETE][4] ([fdo#107807]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-skl3/igt@i915_pm_...@gem-mmap-cpu.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5979/shard-apl7/igt@i915_susp...@sysfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking: - shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#109278]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-apl4/igt@kms_atomic_transit...@3x-modeset-transitions-nonblocking.html * igt@kms_busy@extended-modeset-hang-oldfb-render-f: - shard-skl: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#109278]) +7 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-skl5/igt@kms_b...@extended-modeset-hang-oldfb-render-f.html * igt@kms_cursor_crc@cursor-512x512-random: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109279]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-iclb4/igt@kms_cursor_...@cursor-512x512-random.html * igt@kms_cursor_edge_walk@pipe-c-64x64-top-edge: - shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#109278]) +6 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-snb2/igt@kms_cursor_edge_w...@pipe-c-64x64-top-edge.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109349]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5979/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-iclb5/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_frontbuffer_tracking@fbc-1p-indfb-fliptrack: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108040]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5979/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-indfb-fliptrack.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-skl3/igt@kms_frontbuffer_track...@fbc-1p-indfb-fliptrack.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271]) +71 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-skl3/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][16] -> [FAIL][17] ([fdo#103167]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5979/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271]) +30 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-snb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271]) +24 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/shard-apl4/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-cur-indfb-move.html * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-render: - shard-iclb: NOTRUN -> [SKIP][20] ([fdo#109280]) [20]: https://intel-gfx-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Engine relative MMIO (rev4)
== Series Details == Series: drm/i915: Engine relative MMIO (rev4) URL : https://patchwork.freedesktop.org/series/57117/ State : success == Summary == CI Bug Log - changes from CI_DRM_5979 -> Patchwork_12857 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57117/revisions/4/mbox/ Known issues Here are the changes found in Patchwork_12857 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-icl-y: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-icl-y/igt@amdgpu/amd_cs_...@fork-compute0.html * igt@gem_ctx_create@basic-files: - fi-gdg-551: NOTRUN -> [SKIP][2] ([fdo#109271]) +101 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-gdg-551/igt@gem_ctx_cre...@basic-files.html * igt@gem_exec_basic@basic-bsd2: - fi-icl-y: NOTRUN -> [SKIP][3] ([fdo#109276]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-icl-y/igt@gem_exec_ba...@basic-bsd2.html * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +71 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-pnv-d510/igt@gem_exec_ba...@readonly-bsd2.html * igt@gem_exec_parse@basic-rejected: - fi-icl-y: NOTRUN -> [SKIP][5] ([fdo#109289]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-icl-y/igt@gem_exec_pa...@basic-rejected.html * igt@kms_busy@basic-flip-c: - fi-gdg-551: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#109278]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-gdg-551/igt@kms_b...@basic-flip-c.html - fi-pnv-d510:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#109278]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-pnv-d510/igt@kms_b...@basic-flip-c.html * igt@kms_chamelium@dp-crc-fast: - fi-icl-y: NOTRUN -> [SKIP][8] ([fdo#109284]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-y: NOTRUN -> [SKIP][9] ([fdo#109285]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-icl-y/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - fi-byt-clapper: [PASS][10] -> [FAIL][11] ([fdo#103191]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5979/fi-byt-clapper/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-byt-clapper/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html * igt@kms_psr@primary_mmap_gtt: - fi-icl-y: NOTRUN -> [SKIP][12] ([fdo#110189]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-icl-y/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-fence-flip: - fi-icl-y: NOTRUN -> [SKIP][13] ([fdo#109294]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-icl-y/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [DMESG-FAIL][14] ([fdo#110235 ]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5979/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12857/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (47 -> 43) -- Additional (3): fi-icl-y fi-gdg-551 fi-pnv-d510 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5979 -> Patchwork_12857 CI_DRM_5979: b9faf41db57725605f502c2074b35eb4266643b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4959: 504367d33b787de2ba8e007a5b620cfd6f0
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Engine relative MMIO (rev4)
== Series Details ==
Series: drm/i915: Engine relative MMIO (rev4)
URL : https://patchwork.freedesktop.org/series/57117/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f8a1f0afe196 drm/i915: Engine relative MMIO
-:92: ERROR:SPACING: space prohibited after that open parenthesis '('
#92: FILE: drivers/gpu/drm/i915/i915_cmd_parser.c:223:
+ CMD( __MI_LOAD_REGISTER_IMM(1),SMI, !F, 0xFF, W,
-:93: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#93: FILE: drivers/gpu/drm/i915/i915_cmd_parser.c:224:
+ CMD( __MI_LOAD_REGISTER_IMM(1),SMI, !F, 0xFF, W,
.reg = { .offset = 1, .mask = 0x007C, .step = 2 }),
-:250: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#250: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:130:
+#define __MI_LOAD_REGISTER_IMM(x) MI_INSTR(0x22, 2*(x)-1)
^
-:250: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#250: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:130:
+#define __MI_LOAD_REGISTER_IMM(x) MI_INSTR(0x22, 2*(x)-1)
^
-:252: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#252: FILE: drivers/gpu/drm/i915/intel_gpu_commands.h:132:
+#define MI_LRI_ADD_CS_MMIO_START_GEN11 (1<<19)
^
-:395: ERROR:CODE_INDENT: code indent should use tabs where possible
#395: FILE: drivers/gpu/drm/i915/intel_lrc.c:2789:
+ ^ICTX_REG(engine, regs, CTX_PDP3_UDW, GEN8_RING_PDP_UDW(base, 3), 0);$
-:395: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#395: FILE: drivers/gpu/drm/i915/intel_lrc.c:2789:
+ ^ICTX_REG(engine, regs, CTX_PDP3_UDW, GEN8_RING_PDP_UDW(base, 3), 0);$
-:395: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#395: FILE: drivers/gpu/drm/i915/intel_lrc.c:2789:
+ ^ICTX_REG(engine, regs, CTX_PDP3_UDW, GEN8_RING_PDP_UDW(base, 3), 0);$
-:539: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#539: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:1762:
+ *cs++ = i915_get_lri_cmd(rq->engine, GEN7_L3LOG_SIZE/4);
^
-:607: CHECK:CAMELCASE: Avoid CamelCase:
#607: FILE: drivers/gpu/drm/i915/selftests/intel_workarounds.c:447:
+ u32 regLRI = i915_get_lri_reg(engine,
engine->whitelist.list[i].reg);
total: 2 errors, 2 warnings, 6 checks, 503 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Engine relative MMIO
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engine
and not absolute addresses.
The LRI command has support for engine relative addressing. However,
the mechanism is not transparent to the driver. The scheme for Gen11
(MI_LRI_ADD_CS_MMIO_START) requires the LRI address to have no
absolute engine base component. The hardware then adds on the correct
engine offset at execution time.
Due to the non-trivial and differing schemes on different hardware, it
is not possible to simply update the code that creates the LRI
commands to set a remap flag and let the hardware get on with it.
Instead, this patch adds function wrappers for generating the LRI
command itself and then for constructing the correct address to use
with the LRI.
v2: Fix build break in GVT. Remove flags parameter [review feedback
from Chris W].
v3: Fix build break in selftest. Rebase to newer base tree and fix
merge conflict.
v4: More rebasing. Rmoved relative addressing support from Gen7-9 only
code paths [review feedback from Chris W].
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gvt/mmio_context.c | 16 +++-
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_gem_context.c | 12 +--
drivers/gpu/drm/i915/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_perf.c | 19 +++--
drivers/gpu/drm/i915/intel_engine_cs.c| 11 +++
drivers/gpu/drm/i915/intel_gpu_commands.h | 6 +-
drivers/gpu/drm/i915/intel_lrc.c | 79 ++-
drivers/gpu/drm/i915/intel_lrc_reg.h | 4 +-
drivers/gpu/drm/i915/intel_mocs.c | 17 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 45 +--
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
drivers/gpu/drm/i915/intel_workarounds.c | 4 +-
.../drm/i915/selftests/intel_workarounds.c| 9 ++-
14 files changed, 154 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index e7e14c842be4..1b4d78e55ed6 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -199,14 +199,14 @@ restore_context_mmio_for_inhibit(struct intel_vgpu *vgpu,
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(count);
+ *cs++ = i915_get_lri_cmd(req->engine, count);
for (mmio = gvt->engine_mmio_list.mmio;
i915_mmio_reg_valid(mmio->reg); mmio++) {
if (mmio->ring_id != ring_id ||
!mmio->in_context)
continue;
- *cs++ = i915_mmio_reg_offset(mmio->reg);
+ *cs++ = i915_get_lri_reg(req->engine, mmio->reg);
*cs++ = vgpu_vreg_t(vgpu, mmio->reg) |
(mmio->mask << 16);
gvt_dbg_core("add lri reg pair 0x%x:0x%x in inhibit ctx,
vgpu:%d, rind_id:%d\n",
@@ -234,7 +234,11 @@ restore_render_mocs_control_for_inhibit(struct intel_vgpu
*vgpu,
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE);
+ /*
+* GEN9_GFX_MOCS is not engine relative, therefore there is no
+* need for relative addressing.
+*/
+ *cs++ = __MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE);
for (index = 0; index < GEN9_MOCS_SIZE; index++) {
*cs++ = i915_mmio_reg_offset(GEN9_GFX_MOCS(index));
@@ -261,7 +265,11 @@ restore_render_mocs_l3cc_for_inhibit(struct intel_vgpu
*vgpu,
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE / 2);
+ /*
+* GEN9_LNCFCMOCS is not engine relative, therefore there is no
+* need for relative addressing.
+*/
+ *cs++ = __MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE / 2);
for (index = 0; index < GEN9_MOCS_SIZE / 2; index++) {
*cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(index));
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 503d548a55f7..91ebe18aacc6 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -220,7 +220,7 @@ static const struct drm_i915_cmd_descriptor common_cmds[] =
{
CMD( MI_SUSPEND_FLUSH, SMI,F, 1, S ),
CMD( MI_SEMAPHORE_MBOX,SMI, !F, 0xFF, R ),
CMD( MI_STORE_DWORD_INDEX, SMI, !F, 0xFF, R ),
- CMD( MI_LOAD_REGISTER_IMM(1), SMI, !F, 0xFF, W,
+ CMD( __MI_LOAD_REGISTER_IMM(1),SMI, !F, 0xFF, W,
.reg = { .offset = 1, .mask = 0x007C, .step = 2 }),
CMD(
[Intel-gfx] [git pull] drm fixes (regression special)
Hey Linus, We interrupt your regularly scheduled drm fixes for a regression special. The first is for a fix in i915 that had unexpected side effects fallout in the userspace X.org modesetting driver where X would no longer start. I got tired of the nitpicking and issued a large hammer on it. The X.org driver is buggy, but blackscreen regressions are worse. The second was an oversight that myself and Gerd should have noticed better, Gerd is trying to fix this properly, but the regression is too large to leave, even if the original behaviour is bad in some cases, it's clearly bad to break a bunch of working use cases. I'll likely have a regular fixes pull later, but I really wanted to highlight these. Dave. drm-fixes-2019-04-24: drm regression fixes (i915 and virtio-gpu) The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb: Linux 5.1-rc6 (2019-04-21 10:45:57 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-24 for you to fetch changes up to a0cecc23cfcbf2626497a8c8770856dd56b67917: Revert "drm/virtio: drop prime import/export callbacks" (2019-04-24 10:52:52 +1000) drm regression fixes (i915 and virtio-gpu) Dave Airlie (2): Revert "drm/i915/fbdev: Actually configure untiled displays" Revert "drm/virtio: drop prime import/export callbacks" drivers/gpu/drm/i915/intel_fbdev.c | 12 +--- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 drivers/gpu/drm/virtio/virtgpu_drv.h | 4 drivers/gpu/drm/virtio/virtgpu_prime.c | 12 4 files changed, 25 insertions(+), 7 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Actually configure untiled displays
This patch broke userspace. I'm reverting it.
I know userspace was broken, but since it's a userspace lots of people
are using we shouldn't break it.
We either need to add this as a config option that we can let people
pick the breakage, or detect broken userspace somehow and magic around
it.
But breaking it isn't happening here. I reported this weeks ago, and I
got regression dodging behaviour.
Dave.
On Sun, 17 Feb 2019 at 03:09, Chris Wilson wrote:
>
> Quoting Chris Wilson (2019-02-15 16:06:59)
> > Quoting Maarten Lankhorst (2019-02-15 16:02:40)
> > > Op 15-02-2019 om 13:30 schreef Chris Wilson:
> > > > If we skipped all the connectors that were not part of a tile, we would
> > > > leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> > > > had stagnated in our configuration attempts. Avoid this situation by
> > > > starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
> > > > connectors to configure.
> > > >
> > > > Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration
> > > > on stagnation")
> > > > Reported-by: Maarten Lankhorst
> > > > Signed-off-by: Chris Wilson
> > > > Cc: Maarten Lankhorst
> > > > ---
> > > > drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
> > > > 1 file changed, 7 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > index 376ffe842e26..e8f694b57b8a 100644
> > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > > @@ -338,8 +338,8 @@ static bool intel_fb_initial_config(struct
> > > > drm_fb_helper *fb_helper,
> > > > bool *enabled, int width, int height)
> > > > {
> > > > struct drm_i915_private *dev_priv = to_i915(fb_helper->dev);
> > > > - unsigned long conn_configured, conn_seq, mask;
> > > > unsigned int count = min(fb_helper->connector_count,
> > > > BITS_PER_LONG);
> > > > + unsigned long conn_configured, conn_seq;
> > > > int i, j;
> > > > bool *save_enabled;
> > > > bool fallback = true, ret = true;
> > > > @@ -357,10 +357,9 @@ static bool intel_fb_initial_config(struct
> > > > drm_fb_helper *fb_helper,
> > > > drm_modeset_backoff(&ctx);
> > > >
> > > > memcpy(save_enabled, enabled, count);
> > > > - mask = GENMASK(count - 1, 0);
> > > > + conn_seq = GENMASK(count - 1, 0);
> > > > conn_configured = 0;
> > > > retry:
> > > > - conn_seq = conn_configured;
> > > > for (i = 0; i < count; i++) {
> > > > struct drm_fb_helper_connector *fb_conn;
> > > > struct drm_connector *connector;
> > > > @@ -373,7 +372,8 @@ static bool intel_fb_initial_config(struct
> > > > drm_fb_helper *fb_helper,
> > > > if (conn_configured & BIT(i))
> > > > continue;
> > > >
> > > > - if (conn_seq == 0 && !connector->has_tile)
> > > > + /* First pass, only consider tiled connectors */
> > > > + if (conn_seq == GENMASK(count - 1, 0) &&
> > > > !connector->has_tile)
> > > > continue;
> > > >
> > > > if (connector->status == connector_status_connected)
> > > > @@ -477,8 +477,10 @@ static bool intel_fb_initial_config(struct
> > > > drm_fb_helper *fb_helper,
> > > > conn_configured |= BIT(i);
> > > > }
> > > >
> > > > - if ((conn_configured & mask) != mask && conn_configured !=
> > > > conn_seq)
> > > > + if (conn_configured != conn_seq) { /* repeat until no more are
> > > > found */
> > > > + conn_seq = conn_configured;
> > > > goto retry;
> > > > + }
> > > >
> > > > /*
> > > >* If the BIOS didn't enable everything it could, fall back to
> > > > have the
> > >
> > > Also Cc: # v3.19+ , because it fixes a previous
> > > stable fix?
> >
> > I put the fixes there, the rest I leave to maintainers and AUTOSEL :-p
>
> Pushed with cc:stable. Thanks for spotting it,
> -Chris
> ___
> 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] drm/i915/ehl: Add support for DPLL4 (v4)
On Wed, 17 Apr 2019 16:06:11 +0300
Ville Syrjälä wrote:
Hi Ville,
> On Thu, Apr 11, 2019 at 04:36:00PM -0700, Vivek Kasireddy wrote:
> > This patch adds support for DPLL4 on EHL that include the
> > following restrictions:
> >
> > - DPLL4 cannot be used with DDIA (combo port A internal eDP usage).
> > DPLL4 can be used with other DDIs, including DDID
> > (combo port A external usage).
> >
> > - DPLL4 cannot be enabled when DC5 or DC6 are enabled.
> >
> > - The DPLL4 enable, lock, power enabled, and power state are
> > connected to the MGPLL1_ENABLE register.
> >
> > v2: (suggestions from Bob Paauwe)
> > - Rework ehl_get_dpll() function to call intel_find_shared_dpll()
> > and iterate twice: once for Combo plls and once for MG plls.
> >
> > - Use MG pll funcs for DPLL4 instead of creating new ones and modify
> > mg_pll_enable to include the restrictions for EHL.
> >
> > v3: Fix compilation error
> >
> > v4: (suggestions from Lucas and Ville)
> > - Treat DPLL4 as a combo phy PLL and not as MG PLL
> > - Disable DC states when this DPLL is being enabled
> > - Reuse icl_get_dpll instead of creating a separate one for EHL
> >
> > Cc: Lucas De Marchi
> > Cc: José Roberto de Souza
> > Cc: Bob Paauwe
> > Signed-off-by: Vivek Kasireddy
> > ---
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 35
> > ---
> > drivers/gpu/drm/i915/intel_dpll_mgr.h | 4 2 files changed, 36
> > insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c index
> > e01c057ce50b..207af4af4978 100644 ---
> > a/drivers/gpu/drm/i915/intel_dpll_mgr.c +++
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c @@ -2825,6 +2825,12 @@
> > icl_get_dpll(struct intel_crtc_state *crtc_state, if
> > (intel_port_is_combophy(dev_priv, port)) { min = DPLL_ID_ICL_DPLL0;
> > max = DPLL_ID_ICL_DPLL1;
> > +
> > + if (IS_ELKHARTLAKE(dev_priv)) {
> > + if (encoder->type != INTEL_OUTPUT_EDP)
> > + max = DPLL_ID_EHL_DPLL4;
> > + }
> > +
> > ret = icl_calc_dpll_state(crtc_state, encoder);
> > } else if (intel_port_is_tc(dev_priv, port)) {
> > if (encoder->type == INTEL_OUTPUT_DP_MST) {
> > @@ -2964,8 +2970,14 @@ static bool combo_pll_get_hw_state(struct
> > drm_i915_private *dev_priv, struct intel_shared_dpll *pll,
> >struct intel_dpll_hw_state
> > *hw_state) {
> > - return icl_pll_get_hw_state(dev_priv, pll, hw_state,
> > -
> > CNL_DPLL_ENABLE(pll->info->id));
> > + i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> > +
> > + if (IS_ELKHARTLAKE(dev_priv) &&
> > + pll->info->id == DPLL_ID_EHL_DPLL4) {
> > + enable_reg = MG_PLL_ENABLE(0);
> > + }
> > +
> > + return icl_pll_get_hw_state(dev_priv, pll, hw_state,
> > enable_reg); }
> >
> > static bool tbt_pll_get_hw_state(struct drm_i915_private *dev_priv,
> > @@ -3076,6 +3088,14 @@ static void combo_pll_enable(struct
> > drm_i915_private *dev_priv, {
> > i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> >
> > + if (IS_ELKHARTLAKE(dev_priv) &&
> > + pll->info->id == DPLL_ID_EHL_DPLL4) {
> > + enable_reg = MG_PLL_ENABLE(0);
> > +
> > + /* Need to disable DC states when this DPLL is
> > enabled. */
> > + bxt_disable_dc9(dev_priv);
>
> You can't simply call that from random places. It needs to be handled
> by the power domain stuff.
The only other places in the driver, the functions bxt_disable/enable_dc9
are called are intel_runtime_suspend/resume and
i915_drm_suspend_late/resume_early. Are you suggesting that I call one
of these functions instead? Or, do you simply want me to pair
bxt_*able_dc9 with intel_power_domains_suspend/resume and/or other
functions similar to what the above mentioned functions do?
Thanks,
Vivek
>
> > + }
> > +
> > icl_pll_power_enable(dev_priv, pll, enable_reg);
> >
> > icl_dpll_write(dev_priv, pll);
> > @@ -3171,7 +3191,15 @@ static void icl_pll_disable(struct
> > drm_i915_private *dev_priv, static void combo_pll_disable(struct
> > drm_i915_private *dev_priv, struct intel_shared_dpll *pll)
> > {
> > - icl_pll_disable(dev_priv, pll,
> > CNL_DPLL_ENABLE(pll->info->id));
> > + i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> > +
> > + if (IS_ELKHARTLAKE(dev_priv) &&
> > + pll->info->id == DPLL_ID_EHL_DPLL4) {
> > + enable_reg = MG_PLL_ENABLE(0);
> > + bxt_enable_dc9(dev_priv);
> > + }
> > +
> > + icl_pll_disable(dev_priv, pll, enable_reg);
> > }
> >
> > static void tbt_pll_disable(struct drm_i915_private *dev_priv,
> > @@ -3249,6 +3277,7 @@ static const struct intel_dpll_mgr
> > icl_pll_mgr = { static const struct dpll_info ehl_plls[] = {
> > { "DPLL 0", &combo_pll_funcs, DPLL_ID_ICL_DPLL0, 0 },
> > { "DPLL 1", &combo_pll_funcs, DPLL_ID_ICL_DPLL1, 0 },
> > + { "DPLL 4", &combo_pll_funcs,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen11: enable support for headerless msgs
== Series Details == Series: drm/i915/gen11: enable support for headerless msgs URL : https://patchwork.freedesktop.org/series/59839/ State : success == Summary == CI Bug Log - changes from CI_DRM_5973_full -> Patchwork_12856_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12856_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_bad_reloc@negative-reloc-lut-bsd1: - shard-iclb: NOTRUN -> [SKIP][1] ([fdo#109276]) +14 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb4/igt@gem_bad_re...@negative-reloc-lut-bsd1.html * igt@gem_exec_parse@basic-rejected: - shard-iclb: NOTRUN -> [SKIP][2] ([fdo#109289]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb2/igt@gem_exec_pa...@basic-rejected.html * igt@gem_mmap_gtt@coherency: - shard-iclb: NOTRUN -> [SKIP][3] ([fdo#109292]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb5/igt@gem_mmap_...@coherency.html * igt@gem_mocs_settings@mocs-reset-ctx-dirty-render: - shard-iclb: NOTRUN -> [SKIP][4] ([fdo#110206]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb2/igt@gem_mocs_setti...@mocs-reset-ctx-dirty-render.html * igt@gem_stolen@stolen-no-mmap: - shard-iclb: NOTRUN -> [SKIP][5] ([fdo#109277]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb5/igt@gem_sto...@stolen-no-mmap.html * igt@gem_userptr_blits@readonly-pwrite-unsync: - shard-iclb: NOTRUN -> [SKIP][6] ([fdo#110426]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb3/igt@gem_userptr_bl...@readonly-pwrite-unsync.html * igt@i915_pm_rpm@gem-evict-pwrite: - shard-skl: NOTRUN -> [INCOMPLETE][7] ([fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-skl5/igt@i915_pm_...@gem-evict-pwrite.html * igt@i915_pm_rpm@pc8-residency: - shard-iclb: NOTRUN -> [SKIP][8] ([fdo#109293]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb4/igt@i915_pm_...@pc8-residency.html * igt@i915_query@query-topology-known-pci-ids: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109303]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb3/igt@i915_qu...@query-topology-known-pci-ids.html * igt@i915_selftest@live_active: - shard-skl: [PASS][10] -> [DMESG-WARN][11] ([fdo#110385]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5973/shard-skl8/igt@i915_selftest@live_active.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-skl4/igt@i915_selftest@live_active.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([fdo#108566]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5973/shard-apl2/igt@i915_susp...@debugfs-reader.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-apl6/igt@i915_susp...@debugfs-reader.html * igt@kms_chamelium@dp-frame-dump: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109284]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb2/igt@kms_chamel...@dp-frame-dump.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#104873]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5973/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109274]) +11 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb2/igt@kms_cursor_leg...@cursora-vs-flipb-varying-size.html * igt@kms_flip@2x-wf_vblank-ts-check: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271]) +69 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-snb4/igt@kms_flip@2x-wf_vblank-ts-check.html * igt@kms_flip_tiling@flip-to-x-tiled: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#108134]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5973/shard-iclb3/igt@kms_flip_til...@flip-to-x-tiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/shard-iclb6/igt@kms_flip_til...@flip-to-x-tiled.html * igt@kms_flip_tiling@flip-x-tiled: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108303]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5973/shard-iclb4/igt@kms_flip_til...@flip-x-tiled.html [22]: ht
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/fb-helper: Move modesetting code to drm_client (rev4)
== Series Details == Series: drm/fb-helper: Move modesetting code to drm_client (rev4) URL : https://patchwork.freedesktop.org/series/58597/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5971_full -> Patchwork_12854_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12854_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12854_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_12854_full: ### IGT changes ### Possible regressions * igt@kms_fbcon_fbt@psr-suspend: - shard-iclb: [PASS][1] -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb5/igt@kms_fbcon_...@psr-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-iclb2/igt@kms_fbcon_...@psr-suspend.html - shard-skl: [PASS][3] -> [FAIL][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-skl4/igt@kms_fbcon_...@psr-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-skl4/igt@kms_fbcon_...@psr-suspend.html Known issues Here are the changes found in Patchwork_12854_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#108686]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk5/igt@gem_tiled_swapp...@non-threaded.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-glk4/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@modeset-stress-extra-wait: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-skl7/igt@i915_pm_...@modeset-stress-extra-wait.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-skl8/igt@i915_pm_...@modeset-stress-extra-wait.html * igt@kms_busy@extended-modeset-hang-oldfb-render-f: - shard-skl: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#109278]) +14 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-skl4/igt@kms_b...@extended-modeset-hang-oldfb-render-f.html * igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][10] -> [FAIL][11] ([fdo#106509] / [fdo#107409]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk2/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-glk6/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][12] -> [FAIL][13] ([fdo#105363]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][14] -> [FAIL][15] ([fdo#105363]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-indfb-fliptrack: - shard-skl: [PASS][16] -> [FAIL][17] ([fdo#103167]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-skl2/igt@kms_frontbuffer_track...@fbc-1p-indfb-fliptrack.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-skl1/igt@kms_frontbuffer_track...@fbc-1p-indfb-fliptrack.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-glk: [PASS][18] -> [FAIL][19] ([fdo#103167]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-glk3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][20] -> [DMESG-WARN][21] ([fdo#108566]) +4 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-apl7/igt@kms_frontbuffer_track...@fbc-suspend.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/shard-apl7/igt@kms_frontbuffer_track...@fb
Re: [Intel-gfx] [PATCH] drm/i915/gen11: enable support for headerless msgs
Quoting Dongwon Kim (2019-04-23 20:05:03) > set bit5 (Headerless Message for Pre-emptable Contexts) in SAMPLER_MODE > register while initializing render ring to enable support for headerless > messages for preemptable GPGPU contexts on Gen11. See icl_ctx_workarounds_init() and explain why we must set the default value as userspace is already given access to SAMPLER_MODE. Does changing the default break other workloads? -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 drm/i915/gen11: enable support for headerless msgs
== Series Details == Series: drm/i915/gen11: enable support for headerless msgs URL : https://patchwork.freedesktop.org/series/59839/ State : success == Summary == CI Bug Log - changes from CI_DRM_5973 -> Patchwork_12856 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59839/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12856 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-icl-u3: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-icl-u3/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_basic@gtt-bsd1: - fi-icl-u3: NOTRUN -> [SKIP][2] ([fdo#109276]) +7 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-icl-u3/igt@gem_exec_ba...@gtt-bsd1.html * igt@gem_exec_parse@basic-rejected: - fi-icl-u3: NOTRUN -> [SKIP][3] ([fdo#109289]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-icl-u3/igt@gem_exec_pa...@basic-rejected.html * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [PASS][4] -> [DMESG-FAIL][5] ([fdo#110235 ]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5973/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_chamelium@hdmi-edid-read: - fi-icl-u3: NOTRUN -> [SKIP][6] ([fdo#109284]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-icl-u3/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_force_connector_basic@prune-stale-modes: - fi-icl-u3: NOTRUN -> [SKIP][7] ([fdo#109285]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-icl-u3/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: NOTRUN -> [FAIL][8] ([fdo#103167]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html * igt@kms_psr@cursor_plane_move: - fi-skl-6260u: NOTRUN -> [SKIP][9] ([fdo#109271]) +37 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-skl-6260u/igt@kms_psr@cursor_plane_move.html Possible fixes * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [DMESG-FAIL][10] ([fdo#110235 ]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5973/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (48 -> 43) -- Additional (2): fi-skl-6260u fi-icl-u3 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-8700k fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5973 -> Patchwork_12856 CI_DRM_5973: ef44300e9fca20a6e9fd2d3c5909bec18dfd410e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4959: 504367d33b787de2ba8e007a5b620cfd6f0b3074 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12856: 2f58a29e79fdaa0c4aacb2f5cd1b8792a34c6027 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2f58a29e79fd drm/i915/gen11: enable support for headerless msgs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12856/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gen11: enable support for headerless msgs
== Series Details == Series: drm/i915/gen11: enable support for headerless msgs URL : https://patchwork.freedesktop.org/series/59839/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2f58a29e79fd drm/i915/gen11: enable support for headerless msgs -:8: WARNING:TYPO_SPELLING: 'preemptable' may be misspelled - perhaps 'preemptible'? #8: messages for preemptable GPGPU contexts on Gen11. total: 0 errors, 1 warnings, 0 checks, 37 lines checked ___ 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 [1/3] lib/igt_dummyload: Introduce igt_spin_reset (rev2)
== Series Details == Series: series starting with [1/3] lib/igt_dummyload: Introduce igt_spin_reset (rev2) URL : https://patchwork.freedesktop.org/series/59830/ State : success == Summary == CI Bug Log - changes from CI_DRM_5971_full -> IGTPW_2906_full Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59830/revisions/2/mbox/ Known issues Here are the changes found in IGTPW_2906_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_swapping@non-threaded: - shard-hsw: [PASS][1] -> [FAIL][2] ([fdo#108686]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-hsw1/igt@gem_tiled_swapp...@non-threaded.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-hsw8/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-apl3/igt@i915_susp...@debugfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-apl1/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-apl: [PASS][5] -> [FAIL][6] ([fdo#103232]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-apl1/igt@kms_cursor_...@cursor-256x256-dpms.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-apl7/igt@kms_cursor_...@cursor-256x256-dpms.html - shard-kbl: [PASS][7] -> [FAIL][8] ([fdo#103232]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-kbl1/igt@kms_cursor_...@cursor-256x256-dpms.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-kbl7/igt@kms_cursor_...@cursor-256x256-dpms.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][9] -> [FAIL][10] ([fdo#105363]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-apl: [PASS][13] -> [FAIL][14] ([fdo#103167]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-apl8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-onoff.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-apl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-onoff.html - shard-kbl: [PASS][15] -> [FAIL][16] ([fdo#103167]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-kbl4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-onoff.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-kbl3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-onoff.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-gtt: - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#103167]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk2/igt@kms_frontbuffer_track...@fbc-2p-primscrn-cur-indfb-draw-mmap-gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-glk7/igt@kms_frontbuffer_track...@fbc-2p-primscrn-cur-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-plflip-blt: - shard-hsw: NOTRUN -> [SKIP][19] ([fdo#109271]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-hsw7/igt@kms_frontbuffer_track...@psr-2p-scndscrn-indfb-plflip-blt.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-hsw: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#109278]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-hsw7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103166]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb1/igt@kms_plane_low...@pipe-a-tiling-y.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: [PASS][23] ->
[Intel-gfx] [PATCH] drm/i915/gen11: enable support for headerless msgs
set bit5 (Headerless Message for Pre-emptable Contexts) in SAMPLER_MODE
register while initializing render ring to enable support for headerless
messages for preemptable GPGPU contexts on Gen11.
Signed-off-by: Dongwon Kim
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b74824f0b5b1..b45042f71c0a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8862,6 +8862,7 @@ enum {
#define GEN11_LSN_UNSLCVC_GAFS_HALF_SF_MAXALLOC (1 << 7)
#define GEN10_SAMPLER_MODE _MMIO(0xE18C)
+#define GEN11_SAMPLER_ENABLE_HEADLESS_MSG(1 << 5)
/* IVYBRIDGE DPF */
#define GEN7_L3CDERRST1(slice) _MMIO(0xB008 + (slice) * 0x200) /* L3CD
Error Status 1 */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4e0a351bfbca..07c8fe2a5549 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1807,6 +1807,21 @@ static int gen8_init_common_ring(struct intel_engine_cs
*engine)
return 0;
}
+static int gen11_init_render_ring(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ int ret;
+
+ ret = gen8_init_common_ring(engine);
+ if (ret)
+ return ret;
+
+ /* allow headerless messages for pre-emptable GPGPU contexts */
+ I915_WRITE(GEN10_SAMPLER_MODE,
_MASKED_BIT_ENABLE(GEN11_SAMPLER_ENABLE_HEADLESS_MSG));
+
+ return 0;
+}
+
static void execlists_reset_prepare(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -2516,6 +2531,9 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
return ret;
/* Override some for render ring. */
+ if (INTEL_GEN(engine->i915) == 11)
+ engine->init_hw = gen11_init_render_ring;
+
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_rcs;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8] drm/i915/icl: Fix clockgating issue when using scalers
On Wed, Apr 17, 2019 at 11:59:01AM -0700, Radhakrishna Sripada wrote:
> Fixes the clock-gating issue when pipe scaling is enabled.
> (Lineage #2006604312)
>
> V2: Fix typo in headline(Chris)
> Handle the non double buffered nature of the register(Ville)
> V3: Fix checkpatch warning. BAT failure for V2 on gen3 looks unrelated.
> V4: Split the icl and skl wa's(Ville)
> V5: Split the checks for icl and skl(Ville)
> V6: Correct the flipped checks in intel_pre_plane_update(Ville)
> V7: Use enum for pipe and extend the WA for plane scalers(Ville)
> V8: Eliminate the redundant use of pch_pfit(Ville)
>
> Cc: Chris Wilson
> Cc: Ville Syrjala
> Cc: Rodrigo Vivi
> Cc: Clint Taylor
> Cc: Aditya Swarup
> Signed-off-by: Radhakrishna Sripada
Pushed to dinq. Thanks for the patch.
> ---
> drivers/gpu/drm/i915/intel_display.c | 40
> 1 file changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3bd40a4a6739..dbd7640de895 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -476,6 +476,7 @@ static const struct intel_limit intel_limits_bxt = {
> .p2 = { .p2_slow = 1, .p2_fast = 20 },
> };
>
> +/* WA Display #0827: Gen9:all */
> static void
> skl_wa_827(struct drm_i915_private *dev_priv, int pipe, bool enable)
> {
> @@ -489,6 +490,19 @@ skl_wa_827(struct drm_i915_private *dev_priv, int pipe,
> bool enable)
> ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> }
>
> +/* Wa_2006604312:icl */
> +static void
> +icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, enum pipe pipe,
> +bool enable)
> +{
> + if (enable)
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> +I915_READ(CLKGATE_DIS_PSL(pipe)) | DPFR_GATING_DIS);
> + else
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> +I915_READ(CLKGATE_DIS_PSL(pipe)) & ~DPFR_GATING_DIS);
> +}
> +
> static bool
> needs_modeset(const struct drm_crtc_state *state)
> {
> @@ -5505,6 +5519,16 @@ static bool needs_nv12_wa(struct drm_i915_private
> *dev_priv,
> return false;
> }
>
> +static bool needs_scalerclk_wa(struct drm_i915_private *dev_priv,
> +const struct intel_crtc_state *crtc_state)
> +{
> + /* Wa_2006604312:icl */
> + if (crtc_state->scaler_state.scaler_users > 0 && IS_ICELAKE(dev_priv))
> + return true;
> +
> + return false;
> +}
> +
> static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> @@ -5538,11 +5562,13 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
> intel_post_enable_primary(&crtc->base, pipe_config);
> }
>
> - /* Display WA 827 */
> if (needs_nv12_wa(dev_priv, old_crtc_state) &&
> - !needs_nv12_wa(dev_priv, pipe_config)) {
> + !needs_nv12_wa(dev_priv, pipe_config))
> skl_wa_827(dev_priv, crtc->pipe, false);
> - }
> +
> + if (needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> + !needs_scalerclk_wa(dev_priv, pipe_config))
> + icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
> }
>
> static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
> @@ -5579,9 +5605,13 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>
> /* Display WA 827 */
> if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
> - needs_nv12_wa(dev_priv, pipe_config)) {
> + needs_nv12_wa(dev_priv, pipe_config))
> skl_wa_827(dev_priv, crtc->pipe, true);
> - }
> +
> + /* Wa_2006604312:icl */
> + if (!needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> + needs_scalerclk_wa(dev_priv, pipe_config))
> + icl_wa_scalerclkgating(dev_priv, crtc->pipe, true);
>
> /*
>* Vblank time updates from the shadow to live plane control register
> --
> 2.20.0.rc2.7.g965798d1f299
--
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] drm/i915: Configurable GT idle frequency
On Tue, 16 Apr 2019 16:56:26 +0100 Chris Wilson wrote: > Quoting Bob Paauwe (2019-04-16 00:05:26) > > There are real-time use cases where having deterministic CPU processes > > can be more important than GPU power/performance. Parking the GPU at a > > specific freqency by setting idle, min and max prohibits the normal > > dynamic GPU frequency switching which can introduce significant PCI-E > > latency. This adds the ability to configure the GPU "idle" frequecy > > using the same method that already exists for minimum and maximum > > frequencies. > > What exactly is the problem? We never use idle frequency while active, > always restarting at max(cur, rpe). So for the simple minded among us, > where is the igt demonstrating the issue? > -Chris To follow up and close this. When I requested more details on the use case and data for this request, I was informed that a different solution is being pursued and this patch is no longer needed. Thanks for the reviews and comments. Bob -- -- Bob Paauwe bob.j.paa...@intel.com IOTG / PED Software Organization Intel Corp. Folsom, CA (916) 356-6193 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Merge sbi read/write into a single accessor
On Fri, Apr 19, 2019 at 06:14:00PM +0100, Chris Wilson wrote:
> Since intel_sideband_read and intel_sideband_write differ by only a
> couple of lines (depending on whether we feed the value in or out),
> merge the two into a single common accessor.
>
> v2: Restore vlv_flisdsi_read() lost during rebasing.
>
> Signed-off-by: Chris Wilson
Looks equivalent
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sideband.c | 94 +++
> 1 file changed, 38 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 5c3ae5185a01..7113fb8850d6 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -273,81 +273,63 @@ void vlv_flisdsi_write(struct drm_i915_private *i915,
> u32 reg, u32 val)
> }
>
> /* SBI access */
> -u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
> -enum intel_sbi_destination destination)
> +static int intel_sbi_rw(struct drm_i915_private *i915, u16 reg,
> + enum intel_sbi_destination destination,
> + u32 *val, bool is_read)
> {
> - u32 value = 0;
> + struct intel_uncore *uncore = &i915->uncore;
> + u32 cmd;
>
> - lockdep_assert_held(&dev_priv->sb_lock);
> + lockdep_assert_held(&i915->sb_lock);
>
> - if (intel_wait_for_register(&dev_priv->uncore,
> - SBI_CTL_STAT, SBI_BUSY, 0,
> - 100)) {
> + if (intel_wait_for_register_fw(uncore,
> +SBI_CTL_STAT, SBI_BUSY, 0,
> +100)) {
> DRM_ERROR("timeout waiting for SBI to become ready\n");
> - return 0;
> + return -EBUSY;
> }
>
> - I915_WRITE(SBI_ADDR, (reg << 16));
> - I915_WRITE(SBI_DATA, 0);
> + intel_uncore_write_fw(uncore, SBI_ADDR, (u32)reg << 16);
> + intel_uncore_write_fw(uncore, SBI_DATA, is_read ? 0 : *val);
>
> if (destination == SBI_ICLK)
> - value = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRRD;
> + cmd = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRRD;
> else
> - value = SBI_CTL_DEST_MPHY | SBI_CTL_OP_IORD;
> - I915_WRITE(SBI_CTL_STAT, value | SBI_BUSY);
> -
> - if (intel_wait_for_register(&dev_priv->uncore,
> - SBI_CTL_STAT,
> - SBI_BUSY,
> - 0,
> - 100)) {
> + cmd = SBI_CTL_DEST_MPHY | SBI_CTL_OP_IORD;
> + if (!is_read)
> + cmd |= BIT(8);
> + intel_uncore_write_fw(uncore, SBI_CTL_STAT, cmd | SBI_BUSY);
> +
> + if (__intel_wait_for_register_fw(uncore,
> + SBI_CTL_STAT, SBI_BUSY, 0,
> + 100, 100, &cmd)) {
> DRM_ERROR("timeout waiting for SBI to complete read\n");
> - return 0;
> + return -ETIMEDOUT;
> }
>
> - if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
> + if (cmd & SBI_RESPONSE_FAIL) {
> DRM_ERROR("error during SBI read of reg %x\n", reg);
> - return 0;
> + return -ENXIO;
> }
>
> - return I915_READ(SBI_DATA);
> + if (is_read)
> + *val = intel_uncore_read_fw(uncore, SBI_DATA);
> +
> + return 0;
> }
>
> -void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
> - enum intel_sbi_destination destination)
> +u32 intel_sbi_read(struct drm_i915_private *i915, u16 reg,
> +enum intel_sbi_destination destination)
> {
> - u32 tmp;
> + u32 result = 0;
>
> - lockdep_assert_held(&dev_priv->sb_lock);
> + intel_sbi_rw(i915, reg, destination, &result, true);
>
> - if (intel_wait_for_register(&dev_priv->uncore,
> - SBI_CTL_STAT, SBI_BUSY, 0,
> - 100)) {
> - DRM_ERROR("timeout waiting for SBI to become ready\n");
> - return;
> - }
> -
> - I915_WRITE(SBI_ADDR, (reg << 16));
> - I915_WRITE(SBI_DATA, value);
> -
> - if (destination == SBI_ICLK)
> - tmp = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRWR;
> - else
> - tmp = SBI_CTL_DEST_MPHY | SBI_CTL_OP_IOWR;
> - I915_WRITE(SBI_CTL_STAT, SBI_BUSY | tmp);
> -
> - if (intel_wait_for_register(&dev_priv->uncore,
> - SBI_CTL_STAT,
> - SBI_BUSY,
> - 0,
> - 100)) {
> - DRM_ERROR("timeout waiting for SBI to complete write\n");
> - return;
> - }
> + return result;
> +}
>
> - if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
> - DRM_ERROR("error during SBI write of %x to reg %x\n",
> -
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Move sandybride pcode access to intel_sideband.c
On Fri, Apr 19, 2019 at 06:14:02PM +0100, Chris Wilson wrote:
> sandybride_pcode is another sideband, so move it to their new home.
Close enough.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 10 --
> drivers/gpu/drm/i915/intel_hdcp.c | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 195 -
> drivers/gpu/drm/i915/intel_sideband.c | 196 ++
> drivers/gpu/drm/i915/intel_sideband.h | 10 ++
> 5 files changed, 207 insertions(+), 205 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f4879fb41aa6..45c998870b87 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3427,16 +3427,6 @@ intel_display_capture_error_state(struct
> drm_i915_private *dev_priv);
> extern void intel_display_print_error_state(struct drm_i915_error_state_buf
> *e,
> struct intel_display_error_state
> *error);
>
> -int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
> *val);
> -int sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv, u32
> mbox,
> - u32 val, int fast_timeout_us,
> - int slow_timeout_ms);
> -#define sandybridge_pcode_write(dev_priv, mbox, val) \
> - sandybridge_pcode_write_timeout(dev_priv, mbox, val, 500, 0)
> -
> -int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> request,
> - u32 reply_mask, u32 reply, int timeout_base_ms);
> -
> /* intel_dpio_phy.c */
> void bxt_port_to_phy_channel(struct drm_i915_private *dev_priv, enum port
> port,
>enum dpio_phy *phy, enum dpio_channel *ch);
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 2476e867981d..ca5982e45e3e 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -16,6 +16,7 @@
> #include "i915_reg.h"
> #include "intel_drv.h"
> #include "intel_hdcp.h"
> +#include "intel_sideband.h"
>
> #define KEY_LOAD_TRIES 5
> #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index c9a321aa5d26..0904f5ff2deb 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -9714,201 +9714,6 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
> }
> }
>
> -static inline int gen6_check_mailbox_status(struct drm_i915_private
> *dev_priv,
> - u32 mbox)
> -{
> - switch (mbox & GEN6_PCODE_ERROR_MASK) {
> - case GEN6_PCODE_SUCCESS:
> - return 0;
> - case GEN6_PCODE_UNIMPLEMENTED_CMD:
> - return -ENODEV;
> - case GEN6_PCODE_ILLEGAL_CMD:
> - return -ENXIO;
> - case GEN6_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
> - case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
> - return -EOVERFLOW;
> - case GEN6_PCODE_TIMEOUT:
> - return -ETIMEDOUT;
> - default:
> - MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
> - return 0;
> - }
> -}
> -
> -static inline int gen7_check_mailbox_status(struct drm_i915_private
> *dev_priv,
> - u32 mbox)
> -{
> - switch (mbox & GEN6_PCODE_ERROR_MASK) {
> - case GEN6_PCODE_SUCCESS:
> - return 0;
> - case GEN6_PCODE_ILLEGAL_CMD:
> - return -ENXIO;
> - case GEN7_PCODE_TIMEOUT:
> - return -ETIMEDOUT;
> - case GEN7_PCODE_ILLEGAL_DATA:
> - return -EINVAL;
> - case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
> - return -EOVERFLOW;
> - default:
> - MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
> - return 0;
> - }
> -}
> -
> -static int __sandybridge_pcode_rw(struct drm_i915_private *dev_priv,
> - u32 mbox, u32 *val,
> - int fast_timeout_us,
> - int slow_timeout_ms,
> - bool is_read)
> -{
> - lockdep_assert_held(&dev_priv->sb_lock);
> -
> - /*
> - * GEN6_PCODE_* are outside of the forcewake domain, we can
> - * use te fw I915_READ variants to reduce the amount of work
> - * required when reading/writing.
> - */
> -
> - if (I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY)
> - return -EAGAIN;
> -
> - I915_WRITE_FW(GEN6_PCODE_DATA, *val);
> - I915_WRITE_FW(GEN6_PCODE_DATA1, 0);
> - I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);
> -
> - if (__intel_wait_for_register_fw(&dev_priv->uncore,
> - GEN6_PCODE_MAILBOX, GEN6_PCODE_READY,
> 0,
> - fast_timeout_us,
> -
Re: [Intel-gfx] [PATCH 07/10] drm/i915: Separate sideband declarations to intel_sideband.h
On Fri, Apr 19, 2019 at 06:13:59PM +0100, Chris Wilson wrote:
> Split the sideback declarations out of the ginormous i915_drv.h
Ah, it was here all along :)
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Makefile.header-test | 1 +
> drivers/gpu/drm/i915/i915_debugfs.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 120
> drivers/gpu/drm/i915/i915_sysfs.c | 2 +
> drivers/gpu/drm/i915/intel_cdclk.c| 1 +
> drivers/gpu/drm/i915/intel_display.c | 1 +
> drivers/gpu/drm/i915/intel_dp.c | 2 +
> drivers/gpu/drm/i915/intel_dpio_phy.c | 1 +
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 13 ++-
> drivers/gpu/drm/i915/intel_hdmi.c | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 1 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
> drivers/gpu/drm/i915/intel_sideband.c | 2 +
> drivers/gpu/drm/i915/intel_sideband.h | 130 ++
> drivers/gpu/drm/i915/vlv_dsi.c| 2 +-
> drivers/gpu/drm/i915/vlv_dsi_pll.c| 4 +-
> 16 files changed, 157 insertions(+), 126 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_sideband.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile.header-test
> b/drivers/gpu/drm/i915/Makefile.header-test
> index c1c391816fa7..20ee9321dbb3 100644
> --- a/drivers/gpu/drm/i915/Makefile.header-test
> +++ b/drivers/gpu/drm/i915/Makefile.header-test
> @@ -31,6 +31,7 @@ header_test := \
> intel_pipe_crc.h \
> intel_pm.h \
> intel_psr.h \
> + intel_sideband.h \
> intel_sdvo.h \
> intel_sprite.h \
> intel_tv.h \
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 93fd82a6ac2b..850ad072d1e0 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -41,6 +41,7 @@
> #include "intel_hdmi.h"
> #include "intel_pm.h"
> #include "intel_psr.h"
> +#include "intel_sideband.h"
>
> static inline struct drm_i915_private *node_to_i915(struct drm_info_node
> *node)
> {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6eb12f11ab65..f4879fb41aa6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -541,11 +541,6 @@ enum intel_pch {
> PCH_ICP,/* Ice Lake PCH */
> };
>
> -enum intel_sbi_destination {
> - SBI_ICLK,
> - SBI_MPHY,
> -};
> -
> #define QUIRK_LVDS_SSC_DISABLE (1<<1)
> #define QUIRK_INVERT_BRIGHTNESS (1<<2)
> #define QUIRK_BACKLIGHT_PRESENT (1<<3)
> @@ -3442,121 +3437,6 @@ int sandybridge_pcode_write_timeout(struct
> drm_i915_private *dev_priv, u32 mbox,
> int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> request,
> u32 reply_mask, u32 reply, int timeout_base_ms);
>
> -/* intel_sideband.c */
> -
> -enum {
> - VLV_IOSF_SB_BUNIT,
> - VLV_IOSF_SB_CCK,
> - VLV_IOSF_SB_CCU,
> - VLV_IOSF_SB_DPIO,
> - VLV_IOSF_SB_FLISDSI,
> - VLV_IOSF_SB_GPIO,
> - VLV_IOSF_SB_NC,
> - VLV_IOSF_SB_PUNIT,
> -};
> -
> -void vlv_iosf_sb_get(struct drm_i915_private *i915, unsigned long ports);
> -u32 vlv_iosf_sb_read(struct drm_i915_private *i915, u8 port, u32 reg);
> -void vlv_iosf_sb_write(struct drm_i915_private *i915,
> -u8 port, u32 reg, u32 val);
> -void vlv_iosf_sb_put(struct drm_i915_private *i915, unsigned long ports);
> -
> -static inline void vlv_bunit_get(struct drm_i915_private *i915)
> -{
> - vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_BUNIT));
> -}
> -
> -u32 vlv_bunit_read(struct drm_i915_private *i915, u32 reg);
> -void vlv_bunit_write(struct drm_i915_private *i915, u32 reg, u32 val);
> -
> -static inline void vlv_bunit_put(struct drm_i915_private *i915)
> -{
> - vlv_iosf_sb_put(i915, BIT(VLV_IOSF_SB_BUNIT));
> -}
> -
> -static inline void vlv_cck_get(struct drm_i915_private *i915)
> -{
> - vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_CCK));
> -}
> -
> -u32 vlv_cck_read(struct drm_i915_private *i915, u32 reg);
> -void vlv_cck_write(struct drm_i915_private *i915, u32 reg, u32 val);
> -
> -static inline void vlv_cck_put(struct drm_i915_private *i915)
> -{
> - vlv_iosf_sb_put(i915, BIT(VLV_IOSF_SB_CCK));
> -}
> -
> -static inline void vlv_ccu_get(struct drm_i915_private *i915)
> -{
> - vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_CCU));
> -}
> -
> -u32 vlv_ccu_read(struct drm_i915_private *i915, u32 reg);
> -void vlv_ccu_write(struct drm_i915_private *i915, u32 reg, u32 val);
> -
> -static inline void vlv_ccu_put(struct drm_i915_private *i915)
> -{
> - vlv_iosf_sb_put(i915, BIT(VLV_IOSF_SB_CCU));
> -}
> -
> -static inline void vlv_dpio_get(struct drm_i915_private *i915)
> -{
> - vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_DPIO));
> -}
> -
> -u32 vlv_dpio_read(struct drm_i915_private *i915, enum pipe pipe, int reg);
> -void vlv_dpio_write(struct drm_i915_private *i915,
> -
Re: [Intel-gfx] [PATCH 04/10] drm/i915: Reduce RPS update frequency on Valleyview/Cherryview
On Fri, Apr 19, 2019 at 06:13:56PM +0100, Chris Wilson wrote:
> Valleyview and Cherryview update the GPU frequency via the punit, which
> is very expensive as we have to ensure the cores do not sleep during the
> comms. If we perform frequent RPS evaluations, the frequent punit
> requests cause measurable system overhead for little benefit, so
> increase the evaluation intervals to reduce the number of times we try
> and change frequency.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_pm.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9db39ea9bd83..ba6d3d1adf6c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6593,6 +6593,19 @@ static void rps_set_power(struct drm_i915_private
> *dev_priv, int new_power)
> break;
> }
>
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
Since you added the qos only for vlv do we still want to keep chv here?
> + /*
> + * Baytrail and Braswell control the gpu frequency via the
> + * punit, which is very slow and expensive to communicate with,
> + * as we synchronously force the package to C0. If we try and
> + * update the gpufreq too often we cause measurable system
> + * load for little benefit (effectively stealing CPU time for
> + * the GPU, negatively impacting overall throughput).
> + */
> + ei_up <<= 2;
> + ei_down <<= 2;
> + }
> +
> /* When byt can survive without system hang with dynamic
>* sw freq adjustments, this restriction can be lifted.
>*/
> --
> 2.20.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 03/10] drm/i915: Lift sideband locking for vlv_punit_(read|write)
On Fri, Apr 19, 2019 at 06:13:55PM +0100, Chris Wilson wrote:
> Lift the sideband acquisition for vlv_punit_read and vlv_punit_write
> into their callers, so that we can lock the sideband once for a sequence
> of operations, rather than perform the heavyweight acquisition on each
> request.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 5 +++
> drivers/gpu/drm/i915/i915_sysfs.c | 14
> drivers/gpu/drm/i915/intel_cdclk.c | 23 ++---
> drivers/gpu/drm/i915/intel_display.c| 16 +
> drivers/gpu/drm/i915/intel_pm.c | 46 -
> drivers/gpu/drm/i915/intel_runtime_pm.c | 10 ++
> drivers/gpu/drm/i915/intel_sideband.c | 18 ++
> 7 files changed, 89 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5823ffb17821..83253928e69d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1056,7 +1056,10 @@ static int i915_frequency_info(struct seq_file *m,
> void *unused)
> yesno((rpmodectl & GEN6_RP_MEDIA_MODE_MASK) ==
> GEN6_RP_MEDIA_SW_MODE));
>
> + vlv_punit_get(dev_priv);
> freq_sts = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
> + vlv_punit_put(dev_priv);
> +
> seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts);
> seq_printf(m, "DDR freq: %d MHz\n", dev_priv->mem_freq);
>
> @@ -2029,8 +2032,10 @@ static int i915_rps_boost_info(struct seq_file *m,
> void *data)
> with_intel_runtime_pm_if_in_use(dev_priv, wakeref) {
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> mutex_lock(&dev_priv->pcu_lock);
> + vlv_punit_get(dev_priv);
> act_freq = vlv_punit_read(dev_priv,
> PUNIT_REG_GPU_FREQ_STS);
> + vlv_punit_put(dev_priv);
> act_freq = (act_freq >> 8) & 0xff;
> mutex_unlock(&dev_priv->pcu_lock);
> } else {
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 41313005af42..bfabb3de4808 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -259,25 +259,25 @@ static ssize_t gt_act_freq_mhz_show(struct device *kdev,
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> intel_wakeref_t wakeref;
> - int ret;
> + u32 freq;
>
> wakeref = intel_runtime_pm_get(dev_priv);
>
> mutex_lock(&dev_priv->pcu_lock);
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> - u32 freq;
> + vlv_punit_get(dev_priv);
> freq = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
> - ret = intel_gpu_freq(dev_priv, (freq >> 8) & 0xff);
> + vlv_punit_put(dev_priv);
> +
> + freq = (freq >> 8) & 0xff;
> } else {
> - ret = intel_gpu_freq(dev_priv,
> - intel_get_cagf(dev_priv,
> - I915_READ(GEN6_RPSTAT1)));
> + freq = intel_get_cagf(dev_priv, I915_READ(GEN6_RPSTAT1));
> }
> mutex_unlock(&dev_priv->pcu_lock);
>
> intel_runtime_pm_put(dev_priv, wakeref);
>
> - return snprintf(buf, PAGE_SIZE, "%d\n", ret);
> + return snprintf(buf, PAGE_SIZE, "%d\n", intel_gpu_freq(dev_priv, freq));
> }
>
> static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 5845d0a37599..9dd22203a7e8 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -464,13 +464,19 @@ static void vlv_get_cdclk(struct drm_i915_private
> *dev_priv,
> {
> u32 val;
>
> + mutex_lock(&dev_priv->pcu_lock);
> + vlv_iosf_sb_get(dev_priv,
> + BIT(VLV_IOSF_SB_CCK) | BIT(VLV_IOSF_SB_PUNIT));
> +
> cdclk_state->vco = vlv_get_hpll_vco(dev_priv);
> cdclk_state->cdclk = vlv_get_cck_clock(dev_priv, "cdclk",
> CCK_DISPLAY_CLOCK_CONTROL,
> cdclk_state->vco);
>
> - mutex_lock(&dev_priv->pcu_lock);
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM);
> +
> + vlv_iosf_sb_put(dev_priv,
> + BIT(VLV_IOSF_SB_CCK) | BIT(VLV_IOSF_SB_PUNIT));
> mutex_unlock(&dev_priv->pcu_lock);
>
> if (IS_VALLEYVIEW(dev_priv))
> @@ -545,6 +551,11 @@ static void vlv_set_cdclk(struct drm_i915_private
> *dev_priv,
>*/
> wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
>
> + vlv_iosf_sb_get(dev_priv,
> +
[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable Transcoder Port Sync feature for Tiled displays
== Series Details == Series: Enable Transcoder Port Sync feature for Tiled displays URL : https://patchwork.freedesktop.org/series/59837/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5971 -> Patchwork_12855 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12855 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12855, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/59837/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12855: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s3: - fi-kbl-r: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html - fi-skl-6600u: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html * igt@runner@aborted: - fi-bxt-j4205: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-bxt-j4205/igt@run...@aborted.html - fi-whl-u: NOTRUN -> [FAIL][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-whl-u/igt@run...@aborted.html - fi-apl-guc: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-apl-guc/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_12855 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-skl-iommu: [PASS][8] -> [INCOMPLETE][9] ([fdo#104108] / [fdo#107773]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-skl-iommu/igt@gem_exec_susp...@basic-s3.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-skl-iommu/igt@gem_exec_susp...@basic-s3.html * igt@kms_busy@basic-flip-b: - fi-icl-y: [PASS][10] -> [INCOMPLETE][11] ([fdo#107713]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-icl-y/igt@kms_b...@basic-flip-b.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-icl-y/igt@kms_b...@basic-flip-b.html * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: [PASS][12] -> [FAIL][13] ([fdo#103191]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-byt-clapper/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-byt-clapper/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html * igt@runner@aborted: - fi-cfl-8109u: NOTRUN -> [FAIL][14] ([k.org#202107] / [k.org#202109]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-cfl-8109u/igt@run...@aborted.html - fi-kbl-7567u: NOTRUN -> [FAIL][15] ([fdo#108903] / [fdo#108904] / [fdo#108905]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-kbl-7567u/igt@run...@aborted.html - fi-kbl-x1275: NOTRUN -> [FAIL][16] ([fdo#108903] / [fdo#108904] / [fdo#108905]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-kbl-x1275/igt@run...@aborted.html - fi-skl-6600u: NOTRUN -> [FAIL][17] ([fdo#104108]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-skl-6600u/igt@run...@aborted.html - fi-skl-lmem:NOTRUN -> [FAIL][18] ([fdo#104108]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-skl-lmem/igt@run...@aborted.html - fi-kbl-r: NOTRUN -> [FAIL][19] ([fdo#109383]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-kbl-r/igt@run...@aborted.html - fi-skl-6770hq: NOTRUN -> [FAIL][20] ([fdo#104108]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-skl-6770hq/igt@run...@aborted.html - fi-skl-gvtdvm: NOTRUN -> [FAIL][21] ([fdo#104108]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-skl-gvtdvm/igt@run...@aborted.html Warnings * igt@gem_exec_suspend@basic-s3: - fi-whl-u: [FAIL][22] ([fdo#103375]) -> [DMESG-FAIL][23] ([fdo#103375]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-whl-u/igt@gem_exec_susp...@basic-s3.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12855/fi-whl-u/igt@gem_exec_susp...@basic-s3.html * igt@runner@aborted: - fi-kbl-7500u: [FAIL][24] ([fdo#10384
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Lift acquiring the vlv punit magic to a common sb-get
On Fri, Apr 19, 2019 at 06:13:54PM +0100, Chris Wilson wrote:
> As we now employ a very heavy pm_qos around the punit access, we want to
> minimise the number of synchronous requests by performing one for the
> whole punit sequence rather than around individual accesses. The
> sideband lock is used for this, so push the pm_qos into the sideband
> lock acquisition and release, moving it from the lowlevel punit rw
> routine to the callers. In the first step, we move the punit magic into
> the common sideband lock so that we can acquire a bunch of ports
> simultaneously, and if need be extend the workaround protection later.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 124 +---
> drivers/gpu/drm/i915/intel_cdclk.c | 6 +-
> drivers/gpu/drm/i915/intel_display.c| 37 +++
> drivers/gpu/drm/i915/intel_dp.c | 4 +-
> drivers/gpu/drm/i915/intel_dpio_phy.c | 37 +++
> drivers/gpu/drm/i915/intel_dsi_vbt.c| 8 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 4 +-
> drivers/gpu/drm/i915/intel_pm.c | 4 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 8 +-
> drivers/gpu/drm/i915/intel_sideband.c | 45 ++---
> drivers/gpu/drm/i915/vlv_dsi.c | 8 +-
> drivers/gpu/drm/i915/vlv_dsi_pll.c | 14 +--
> 12 files changed, 206 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index afb979ff416f..162d988dbceb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3449,25 +3449,119 @@ int skl_pcode_request(struct drm_i915_private
> *dev_priv, u32 mbox, u32 request,
> u32 reply_mask, u32 reply, int timeout_base_ms);
>
> /* intel_sideband.c */
Introduce intel_sideband.h maybe?
> -u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> -int vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
> -u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
> -u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
> -void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg,
> u32 val);
> -u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int
> reg);
> -void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int
> reg, u32 val);
> +
> +enum {
> + VLV_IOSF_SB_BUNIT,
> + VLV_IOSF_SB_CCK,
> + VLV_IOSF_SB_CCU,
> + VLV_IOSF_SB_DPIO,
> + VLV_IOSF_SB_FLISDSI,
> + VLV_IOSF_SB_GPIO,
> + VLV_IOSF_SB_NC,
> + VLV_IOSF_SB_PUNIT,
> +};
Hopefully no one will confuse these with the IOSF SB port numbers.
> +
> +void vlv_iosf_sb_get(struct drm_i915_private *i915, unsigned long ports);
> +u32 vlv_iosf_sb_read(struct drm_i915_private *i915, u8 port, u32 reg);
> +void vlv_iosf_sb_write(struct drm_i915_private *i915,
> +u8 port, u32 reg, u32 val);
> +void vlv_iosf_sb_put(struct drm_i915_private *i915, unsigned long ports);
> +
> +static inline void vlv_bunit_get(struct drm_i915_private *i915)
> +{
> + vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_BUNIT));
> +}
> +
> +u32 vlv_bunit_read(struct drm_i915_private *i915, u32 reg);
> +void vlv_bunit_write(struct drm_i915_private *i915, u32 reg, u32 val);
> +
> +static inline void vlv_bunit_put(struct drm_i915_private *i915)
> +{
> + vlv_iosf_sb_put(i915, BIT(VLV_IOSF_SB_BUNIT));
> +}
> +
> +static inline void vlv_cck_get(struct drm_i915_private *i915)
> +{
> + vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_CCK));
> +}
> +
> +u32 vlv_cck_read(struct drm_i915_private *i915, u32 reg);
> +void vlv_cck_write(struct drm_i915_private *i915, u32 reg, u32 val);
> +
> +static inline void vlv_cck_put(struct drm_i915_private *i915)
> +{
> + vlv_iosf_sb_put(i915, BIT(VLV_IOSF_SB_CCK));
> +}
> +
> +static inline void vlv_ccu_get(struct drm_i915_private *i915)
> +{
> + vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_CCU));
> +}
> +
> +u32 vlv_ccu_read(struct drm_i915_private *i915, u32 reg);
> +void vlv_ccu_write(struct drm_i915_private *i915, u32 reg, u32 val);
> +
> +static inline void vlv_ccu_put(struct drm_i915_private *i915)
> +{
> + vlv_iosf_sb_put(i915, BIT(VLV_IOSF_SB_CCU));
> +}
> +
> +static inline void vlv_dpio_get(struct drm_i915_private *i915)
> +{
> + vlv_iosf_sb_get(i915, BIT(VLV_IOSF_SB_DPIO));
> +}
> +
> +u32 vlv_dpio_read(struct drm_i915_private *i915, enum pipe pipe, int reg);
> +void vlv_dpio_write(struct drm_i915_private *i915,
> + enum pipe pipe, int reg,
Re: [Intel-gfx] [PATCH 01/10] drm/i915: Disable preemption and sleeping while using the punit sideband
On Fri, Apr 19, 2019 at 06:13:53PM +0100, Chris Wilson wrote:
> While we talk to the punit over its sideband, we need to prevent the cpu
> from sleeping in order to prevent a potential machine hang.
>
> Note that by itself, it appears that pm_qos_update_request (via
> intel_idle) doesn't provide a sufficient barrier to ensure that all core
> are indeed awake (out of Cstate) and that the package is awake. To do so,
> we need to supplement the pm_qos with a manual ping on_each_cpu.
>
> v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there
> is insufficient evidence to implicate a wider problem atm. Similarly,
> restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre
> of users.
>
> The working theory, courtesy of Ville and Hans, is the issue lies within
> the power delivery and so is likely to be unit and board specific and
> occurs when both the unit/fw require extra power at the same time as the
> cpu package is changing its own power state.
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
> References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
> References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Hans de Goede
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_sideband.c | 203 +-
> 3 files changed, 139 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5e2ae2300454..9e657a0410c2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -884,6 +884,9 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv)
> mutex_init(&dev_priv->backlight_lock);
>
> mutex_init(&dev_priv->sb_lock);
> + pm_qos_add_request(&dev_priv->sb_qos,
> +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
> +
> mutex_init(&dev_priv->av_mutex);
> mutex_init(&dev_priv->wm.wm_mutex);
> mutex_init(&dev_priv->pps_mutex);
> @@ -943,6 +946,9 @@ static void i915_driver_cleanup_early(struct
> drm_i915_private *dev_priv)
> i915_gem_cleanup_early(dev_priv);
> i915_workqueues_cleanup(dev_priv);
> i915_engines_cleanup(dev_priv);
> +
> + pm_qos_remove_request(&dev_priv->sb_qos);
> + mutex_destroy(&dev_priv->sb_lock);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 71612e7fc8bc..afb979ff416f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1561,6 +1561,7 @@ struct drm_i915_private {
>
> /* Sideband mailbox protection */
> struct mutex sb_lock;
> + struct pm_qos_request sb_qos;
Should we call it punit_qos maybe?
I'm a bit sad to all the complexity for this, but no one has come up
with a way to really fix it so I guess we just have to swallow this.
Reviewed-by: Ville Syrjälä
>
> /** Cached value of IMR to avoid reads in updating the bitfield */
> union {
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 57de41b1f989..fc8913461622 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -22,6 +22,8 @@
> *
> */
>
> +#include
> +
> #include "i915_drv.h"
> #include "intel_drv.h"
>
> @@ -39,19 +41,50 @@
> /* Private register write, double-word addressing, non-posted */
> #define SB_CRWRDA_NP 0x07
>
> -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
> -u32 port, u32 opcode, u32 addr, u32 *val)
> +static void ping(void *info)
> {
> - u32 cmd, be = 0xf, bar = 0;
> - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> +}
>
> - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
> - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
> - (bar << IOSF_BAR_SHIFT);
> +static void __vlv_punit_get(struct drm_i915_private *i915)
> +{
> + iosf_mbi_punit_acquire();
>
> - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock));
> + /*
> + * Prevent the cpu from sleeping while we use this sideband, otherwise
> + * the punit may cause a machine hang. The issue appears to be isolated
> + * with changing the power state of the CPU package while changing
> + * the power state via the punit, and we have only observed it
> + * reliably on 4-core Baytail systems suggesting the issue is in the
> + * power delivery mechanism and likely to be be board/function
> + * specific. Hence we presume the workaround needs only be applied
> + * to the Valleyview P-unit and not all sideband communications.
> + */
> + if (IS_VALLEYVIEW(i915)) {
> + pm_qos_update_request(&i915->sb_qos, 0);
>
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/sdvo: Check that we have space for the infoframe
On Tue, 2019-04-23 at 17:34 +0300, Ville Syrjälä wrote:
> On Mon, Apr 22, 2019 at 06:37:48PM +, Sripada, Radhakrishna
> wrote:
> > On Wed, 2019-04-10 at 20:08 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Before we go writing the infoframe let's make sure we have
> > > the space for it. Not that it really matters since the write
> > > loop would just terminate early in that case.
> > >
> > > v2: Check after the debug print and ++ (Chris)
> > >
> > > Signed-off-by: Ville Syrjälä
> > > Reviewed-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/intel_sdvo.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > > b/drivers/gpu/drm/i915/intel_sdvo.c
> > > index 7f64352a3413..14348dfb024a 100644
> > > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > > @@ -976,6 +976,9 @@ static bool intel_sdvo_write_infoframe(struct
> > > intel_sdvo *intel_sdvo,
> > > DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size:
> > > %i\n",
> > > if_index, length, hbuf_size);
> >
> > If the above line is newly added why dont I See a + at the
> > beginning of
> > the line? Is it from a previous version of the patch?
>
> It's not newly added. What gave you the idea that it was?
NVM. I was comparing the raw diffs between v1 and v2 of the patch and
missed the above line in the context lines in v1 of the patch. Just a
minor code move around. Will be cautious in future reviews.
LGTM.
Reviewed-by: Radhakrishna Sripada
>
> >
> > -Radhakrishna(RK) Sripada
> > >
> > > + if (hbuf_size < length)
> > > + return false;
> > > +
> > > for (i = 0; i < hbuf_size; i += 8) {
> > > memset(tmp, 0, 8);
> > > if (i < length)
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/32] drm/i915: Move GraphicsTechnology files under gt/
On Tue, Apr 23, 2019 at 12:40:10PM +0300, Jani Nikula wrote: > > I'll want two things: > > * Explicit ack from Rodrigo too Acked-by: Rodrigo Vivi (sorry for being late here) > > * The dependencies merged first, and this one posted as a single > patch. I really want this to stand out better, instead of semi-hidden > in the middle of a 30+ patch series. +1. > > > Acked-by: Jani Nikula > > > On Tue, 23 Apr 2019, Joonas Lahtinen wrote: > > Quoting Joonas Lahtinen (2019-04-18 15:04:49) > >> + Jani and Rodrigo to comment > > > > No objection here and drm-intel-next was freshly tagged, so this is: > > > > Acked-by: Joonas Lahtinen > > > > Regards, Joonas > > > >> > >> I'm definitely all for doing this, so it's only a matter of the timing. > >> > >> Question is, do we want to do it right now after last drm-intel-next was > >> tagged, or do we want to wait a couple of release candidates. > >> > >> I'm leaning towards doing this ASAP, as git cherry-pick should > >> understand that they're just renames, so there should be no issue with > >> doing the -fixes. > >> > >> Regards, Joonas > >> > >> Quoting Chris Wilson (2019-04-17 10:56:32) > >> > Start partitioning off the code that talks to the hardware (GT) from the > >> > uapi layers and move the device facing code under gt/ > >> > > >> > One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to > >> > subdivide that header and body further (and split out the submission > >> > code from the ringbuffer and logical context handling). This patch aims > >> > to be simple motion so git can fixup inflight patches with little mess. > >> > > >> > Signed-off-by: Chris Wilson > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] [v4] drm/i915: Extract i9xx_get_color_config()
On Wed, Apr 17, 2019 at 07:33:25PM +0530, Swati Sharma wrote:
> v4: -No need to initialize *blob [Jani]
> -Removed right shifts [Jani]
> -Dropped dev local var [Jani]
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h| 3 +++
> drivers/gpu/drm/i915/intel_color.c | 50
> ++
> 2 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9c206e8..8f2ae8a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7175,6 +7175,9 @@ enum {
> /* legacy palette */
> #define _LGC_PALETTE_A 0x4a000
> #define _LGC_PALETTE_B 0x4a800
> +#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
> +#define LGC_PALETTE_GREEN_MASK REG_GENMASK(15, 8)
> +#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0)
> #define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A,
> _LGC_PALETTE_B) + (i) * 4)
>
> /* ilk/snb precision palette */
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 309f714..33223e0 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -1229,6 +1229,55 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
> return 0;
> }
>
> +/* convert hw value with given bit_precision to lut property val */
> +static u32 intel_color_lut_pack(u32 val, u32 bit_precision)
> +{
> + u32 max = 0x >> (16 - bit_precision);
> +
> + val = clamp_val(val, 0, max);
> +
> + if (bit_precision < 16)
> + val <<= 16 - bit_precision;
> +
> + return val;
> +}
> +
> +static void i9xx_get_config_internal(struct intel_crtc_state *crtc_state)
The naming of these functions isn't particularly descriptive. I would
probably go for eg. i9xx_read_lut_8(), chv_read_cgm_gamma_lut(), etc.
AFAICS the series is also missing readout for degamma LUTs entirely.
We could also make these functions just return the blob instead of
assigning it internally. That way we can have the higher level
.get_color_config() implementation assign each gamma/degamma lut
apporpriately. Eg. might looks something like this for bdw:
bdw_get_color_config()
{
if (gamma_mode == 8bit) {
crtc_state->gamma_lut = i9xx_read_lut_8();
} else if (gamma_mode == split) {
crtc_state->degamma_lut = bdw_read_lut_10(SPLIT | 0);
crtc_state->gamma_lut = bdw_read_lut_10(SPLIT | 512);
} else if (csc_mode == gamma_before_csc) {
crtc_state->degamma_lut = bdw_read_lut_10(0);
} else {
crtc_state->gamma_lut = bdw_read_lut_10(0);
}
}
The tricky part will be to figure out how the gamma vs. degamma gets
assigned and/or checked since the choice depends on the presence of
the ctm, rgb limit range, and rgb->ycbcr conversion.
Oh, and most (all maybe?) patches seem to be missing a proper commit
message.
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + struct drm_property_blob *blob;
> + struct drm_color_lut *blob_data;
> + u32 i, val;
> +
> + blob = drm_property_create_blob(&dev_priv->drm,
> + sizeof(struct drm_color_lut) * 256,
> + NULL);
> + if (IS_ERR(blob))
> + return;
> +
> + blob_data = blob->data;
> +
> + for (i = 0; i < 256; i++) {
> + if (HAS_GMCH(dev_priv))
> + val = I915_READ(PALETTE(pipe, i));
> + else
> + val = I915_READ(LGC_PALETTE(pipe, i));
> +
> + blob_data[i].red =
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, val), 8);
> + blob_data[i].green =
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
> + blob_data[i].blue =
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, val), 8);
> + }
> +
> + crtc_state->base.gamma_lut = blob;
> +}
> +
> +static void i9xx_get_color_config(struct intel_crtc_state *crtc_state)
> +{
> + i9xx_get_config_internal(crtc_state);
> +}
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> @@ -1249,6 +1298,7 @@ void intel_color_init(struct intel_crtc *crtc)
> dev_priv->display.color_check = i9xx_color_check;
> dev_priv->display.color_commit = i9xx_color_commit;
> dev_priv->display.load_luts = i9xx_load_luts;
> + dev_priv->display.get_color_config =
> i9xx_get_color_config;
> }
> } else {
> if (INTEL_GEN(dev_priv) >= 11)
> --
> 1.9.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailin
Re: [Intel-gfx] [PATCH 02/11] [v4] drm/i915: Enable intel_color_get_config()
On Wed, Apr 17, 2019 at 07:33:24PM +0530, Swati Sharma wrote:
> v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
> -Added the user early on such that support for get_color_config()
> can be added platform by platform incrementally [Jani]
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f29a348..0715b4e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8275,6 +8275,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->cgm_mode = I915_READ(CGM_PIPE_MODE(crtc->pipe));
>
> i9xx_get_pipe_color_config(pipe_config);
> + intel_color_get_config(pipe_config);
>
> if (INTEL_GEN(dev_priv) < 4)
> pipe_config->double_wide = tmp & PIPECONF_DOUBLE_WIDE;
> @@ -9348,6 +9349,7 @@ static bool ironlake_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->csc_mode = I915_READ(PIPE_CSC_MODE(crtc->pipe));
>
> i9xx_get_pipe_color_config(pipe_config);
> + intel_color_get_config(pipe_config);
>
> if (I915_READ(PCH_TRANSCONF(crtc->pipe)) & TRANS_ENABLE) {
> struct intel_shared_dpll *pll;
> @@ -10011,6 +10013,7 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->csc_enable = true;
> } else {
> i9xx_get_pipe_color_config(pipe_config);
> + intel_color_get_config(pipe_config);
That's not the right place for it if you want to cover all the
platforms.
> }
>
> power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> --
> 1.9.1
--
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.CHECKPATCH: warning for Enable Transcoder Port Sync feature for Tiled displays
== Series Details ==
Series: Enable Transcoder Port Sync feature for Tiled displays
URL : https://patchwork.freedesktop.org/series/59837/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3288bd9171c1 drm/i915/icl: Assign Master slave crtc links for Transcoder Port
Sync
-:109: WARNING:TYPO_SPELLING: 'bitmast' may be misspelled - perhaps 'bitmask'?
#109: FILE: drivers/gpu/drm/i915/intel_display.c:11390:
+ DRM_DEBUG_KMS("Master CRTC = %d added for Slave CRTC = %d\n,
slave bitmast = %d",
total: 0 errors, 1 warnings, 0 checks, 119 lines checked
40e43568332f drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays
across separate ports
8be6467cdfa9 drm/i915/dp: Trigger modeset if master_crtc or slaves bitmask
changes
2d882b36c3ec drm/i915/dp: Enable master-slaves in trans port sync mode in
correct order
___
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/fb-helper: Move modesetting code to drm_client (rev4)
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev4)
URL : https://patchwork.freedesktop.org/series/58597/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5971 -> Patchwork_12854
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/58597/revisions/4/mbox/
Known issues
Here are the changes found in Patchwork_12854 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] /
[fdo#108744])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-byt-clapper/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/fi-byt-clapper/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: [PASS][7] -> [FAIL][8] ([fdo#103191])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-byt-clapper/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/fi-byt-clapper/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@runner@aborted:
- fi-skl-iommu: NOTRUN -> [FAIL][9] ([fdo#104108] / [fdo#108602])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/fi-skl-iommu/igt@run...@aborted.html
Possible fixes
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bwr-2160:[FAIL][10] ([fdo#100368]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
Participating hosts (50 -> 42)
--
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-skl-6260u fi-ctg-p8600 fi-bdw-samus fi-skl-6600u
Build changes
-
* Linux: CI_DRM_5971 -> Patchwork_12854
CI_DRM_5971: e91b848a66e8672c48ea65d082b260f13f2c86b9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4959: 504367d33b787de2ba8e007a5b620cfd6f0b3074 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12854: 9bbead190cb62245d4b2290a3bc905a1505f7429 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9bbead190cb6 drm/client: Hack: Add bootsplash example
eaf53f44dd76 drm/fb-helper: Move out modeset config code
d349e5c6cae5 drm/fb-helper: Prepare to move out modeset config code
f4c1616a9e77 drm/fb-helper: Remove drm_fb_helper_connector
e7bc8d3f4204 drm/fb-helper: Move out commit code
fc2de5684c87 drm/fb-helper: Prepare to move out commit code
6877829f5db8 drm/fb-helper: Remove drm_fb_helper_crtc
433f6bb5a950 drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
faf3b22de68a drm/fb-helper: No need to cache rotation and sw_rotations
0ba328ef9996 drm/fb-helper: Avoid race with DRM userspace
4a9806c7e6fe drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12854/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915/icl: Assign Master slave crtc links for Transcoder Port Sync
In case of tiled displays when the two tiles are sent across two CRTCs
over two separate DP SST connectors, we need a mechanism to synchronize
the two CRTCs and their corresponding transcoders.
So use the master-slave mode where there is one master corresponding
to last horizontal and vertical tile that needs to be genlocked with
all other slave tiles.
This patch identifies saves the master CRTC pointer in all the slave
CRTC states. This pointer is needed to select the master CRTC/transcoder
while configuring transcoder port sync for the corresponding slaves.
v2:
* Move this to intel_mode_set_pipe_config(Jani N, Ville)
* Use slave_bitmask to save associated slaves in master crtc state (Ville)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_display.c | 89
drivers/gpu/drm/i915/intel_drv.h | 6 ++
2 files changed, 95 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b276345779e6..92dea2231499 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11316,6 +11316,86 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
return 0;
}
+static int icl_add_genlock_crtcs(struct drm_crtc *crtc,
+struct intel_crtc_state *crtc_state,
+struct drm_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_connector *master_connector, *connector;
+ struct drm_connector_state *connector_state;
+ struct drm_connector_list_iter conn_iter;
+ struct drm_crtc *master_crtc = NULL;
+ struct drm_crtc_state *master_crtc_state;
+ int i, tile_group_id;
+
+ if (INTEL_GEN(dev_priv) < 11)
+ return 0;
+
+ /*
+* In case of tiled displays there could be one or more slaves but
there is
+* only one master. Lets make the CRTC used by the connector
corresponding
+* to the last horizonal and last vertical tile a master/genlock CRTC.
+* All the other CRTCs corresponding to other tiles of the same Tile
group
+* are the slave CRTCs and hold a pointer to their genlock CRTC.
+*/
+ for_each_new_connector_in_state(state, connector, connector_state, i) {
+ if (connector_state->crtc != crtc)
+ continue;
+ if (!connector->has_tile)
+ continue;
+ if (connector->tile_h_loc == connector->num_h_tile - 1 &&
+ connector->tile_v_loc == connector->num_v_tile - 1)
+ continue;
+ crtc_state->master_crtc = NULL;
+ tile_group_id = connector->tile_group->id;
+ drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
+ drm_for_each_connector_iter(master_connector, &conn_iter) {
+ struct drm_connector_state *master_conn_state = NULL;
+
+ if (!master_connector->has_tile)
+ continue;
+ if (master_connector->tile_h_loc !=
master_connector->num_h_tile - 1 ||
+ master_connector->tile_v_loc !=
master_connector->num_v_tile - 1)
+ continue;
+ if (master_connector->tile_group->id != tile_group_id)
+ continue;
+
+ master_conn_state =
drm_atomic_get_connector_state(state,
+
master_connector);
+ if (IS_ERR(master_conn_state)) {
+ drm_connector_list_iter_end(&conn_iter);
+ return PTR_ERR(master_conn_state);
+ }
+ if (master_conn_state->crtc) {
+ master_crtc = master_conn_state->crtc;
+ break;
+ }
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ if (!master_crtc) {
+ DRM_DEBUG_KMS("Could not add Master CRTC for Slave CRTC
%d\n",
+ connector_state->crtc->base.id);
+ return -EINVAL;
+ }
+
+ master_crtc_state = drm_atomic_get_crtc_state(state,
+ master_crtc);
+ if (IS_ERR(master_crtc_state))
+ return PTR_ERR(master_crtc_state);
+
+ crtc_state->master_crtc = to_intel_crtc(master_crtc);
+ to_intel_crtc_state(master_crtc_state)->trans_port_sync_slaves
|=
+ BIT(to_intel_crtc(crtc)->pipe);
+ DRM_DEBUG_KMS("Mas
[Intel-gfx] [PATCH v2 4/4] drm/i915/dp: Enable master-slaves in trans port sync mode in correct order
As per the display enable sequence, we need to follow the enable sequence
for slaves first with DP_TP_CTL set to Idle and configure the transcoder
port sync register to select the corersponding master, then follow the
enable sequence for master leaving DP_TP_CTL to idle.
At this point the transcoder port sync mode is configured and enabled
and the Vblanks of both ports are synchronized so then set DP_TP_CTL
for the slave and master to Normal and do post crtc enable updates.
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/intel_display.c | 122 +++
2 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 24f9106efcc6..0b326b2c274d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3120,7 +3120,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
true);
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_start_link_train(intel_dp);
- if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
+ if ((port != PORT_A || INTEL_GEN(dev_priv) >= 9) &&
+ INTEL_GEN(dev_priv) < 11)
intel_dp_stop_link_train(intel_dp);
intel_ddi_enable_fec(encoder, crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4bd23e61c6fd..bd00549a9e00 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13488,6 +13488,7 @@ static void skl_update_crtcs(struct drm_atomic_state
*state)
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
bool vbl_wait = false;
unsigned int cmask = drm_crtc_mask(crtc);
+ bool modeset = needs_modeset(new_crtc_state);
intel_crtc = to_intel_crtc(crtc);
cstate = to_intel_crtc_state(new_crtc_state);
@@ -13496,6 +13497,12 @@ static void skl_update_crtcs(struct drm_atomic_state
*state)
if (updated & cmask || !cstate->base.active)
continue;
+ if (modeset && INTEL_GEN(dev_priv) >= 11) {
+ DRM_DEBUG_KMS("Pushing the Tiled CRTC %d %s
that needs update to separate loop\n",
+ intel_crtc->base.base.id,
intel_crtc->base.name);
+ continue;
+ }
+
if (skl_ddb_allocation_overlaps(&cstate->wm.skl.ddb,
entries,
INTEL_INFO(dev_priv)->num_pipes, i))
@@ -13526,6 +13533,121 @@ static void skl_update_crtcs(struct drm_atomic_state
*state)
}
} while (progress);
+ /* Separate loop for updating Slave CRTCs that need modeset.
+* We need to loop through all slaves of tiled display first and
+* follow enable sequence with DP_TP_CTL left Idle until the master
+* is ready.
+*/
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ bool modeset = needs_modeset(new_crtc_state);
+ struct intel_crtc_state *pipe_config =
to_intel_crtc_state(new_crtc_state);
+
+ intel_crtc = to_intel_crtc(crtc);
+
+ if (!pipe_config->base.active)
+ continue;
+ if (!modeset)
+ continue;
+ if (!pipe_config->master_crtc)
+ continue;
+
+ update_scanline_offset(pipe_config);
+ dev_priv->display.crtc_enable(pipe_config, state);
+ }
+ /* Now do the display enable sequence for master CRTC */
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ bool modeset = needs_modeset(new_crtc_state);
+ struct intel_crtc_state *pipe_config =
to_intel_crtc_state(new_crtc_state);
+
+ intel_crtc = to_intel_crtc(crtc);
+
+ if (!pipe_config->base.active)
+ continue;
+ if (!modeset)
+ continue;
+ if (pipe_config->master_crtc)
+ continue;
+
+ update_scanline_offset(pipe_config);
+ dev_priv->display.crtc_enable(pipe_config, state);
+ }
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ struct drm_connector_state *conn_state;
+ struct drm_connector *conn;
+ bool modeset = needs_modeset(new_crtc_state);
+ str
[Intel-gfx] [PATCH v2 0/4] Enable Transcoder Port Sync feature for Tiled displays
In case of tiled displays, each tile is sent across a separate CRTC and a separate port/connector connected to the monitor. In this case we need to make sure that the timings across these transcoders/ports are synchronized else the two tile displays can be off. Transcoder Port Sync is a transcoder level feature. This mode forces two or more transcoders to be in sync with one transcoder master and one or more transcoder slaves. In the case of DP/eDP, the master is unaware that it is operating in Port Sync mode, only the slave is aware that it is operating in this mode. Hence in this configuration, we need to do a mdoeset on slaves first and configure the port sync in slave transcoder. Manasi Navare (4): drm/i915/icl: Assign Master slave crtc links for Transcoder Port Sync drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports drm/i915/dp: Trigger modeset if master_crtc or slaves bitmask changes drm/i915/dp: Enable master-slaves in trans port sync mode in correct order drivers/gpu/drm/i915/intel_ddi.c | 3 +- drivers/gpu/drm/i915/intel_display.c | 274 +++ drivers/gpu/drm/i915/intel_drv.h | 6 + 3 files changed, 282 insertions(+), 1 deletion(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
In case of tiled displays where different tiles are displayed across
different ports, we need to synchronize the transcoders involved.
This patch implements the transcoder port sync feature for
synchronizing one master transcoder with one or more slave
transcoders. This is only enbaled in slave transcoder
and the master transcoder is unaware that it is operating
in this mode.
This has been tested with tiled display connected to ICL.
v2:
* Do not use RMW, just write to the register in commit (Jani N)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_display.c | 58
1 file changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 92dea2231499..81e8cb9fe221 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4020,6 +4020,61 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
}
+static void icl_set_transcoder_port_sync(struct intel_atomic_state
*old_intel_state,
+const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_crtc_state *master_crtc_state = NULL;
+ enum transcoder master_transcoder;
+ u32 trans_ddi_func_ctl2_val;
+ u8 master_select;
+
+ /*
+* Port Sync Mode cannot be enabled for DP MST
+*/
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
+ return;
+
+ /*
+* Configure the master select and enable Transcoder Port Sync for
+* Slave CRTCs transcoder.
+*/
+ if (!crtc_state->master_crtc)
+ return;
+
+ master_crtc_state = intel_atomic_get_new_crtc_state(old_intel_state,
+
crtc_state->master_crtc);
+ if (WARN_ON(!master_crtc_state))
+ return;
+
+ master_transcoder = master_crtc_state->cpu_transcoder;
+ switch (master_transcoder) {
+ case TRANSCODER_A:
+ master_select = 1;
+ break;
+ case TRANSCODER_B:
+ master_select = 2;
+ break;
+ case TRANSCODER_C:
+ master_select = 3;
+ break;
+ case TRANSCODER_EDP:
+ default:
+ master_select = 0;
+ break;
+ }
+ /* Set the master select bits for Tranascoder Port Sync */
+ trans_ddi_func_ctl2_val = (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
+ PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
+ PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
+ /* Enable Transcoder Port Sync */
+ trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
+
+ I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
+ trans_ddi_func_ctl2_val);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -5971,6 +6026,9 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
if (!transcoder_is_dsi(cpu_transcoder))
intel_set_pipe_timings(pipe_config);
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_set_transcoder_port_sync(old_intel_state, pipe_config);
+
intel_set_pipe_src_size(pipe_config);
if (cpu_transcoder != TRANSCODER_EDP &&
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/dp: Trigger modeset if master_crtc or slaves bitmask changes
Add the comparison between the current state and new_crtc_state for
newly added master_crtc pointer and slave bitmask so that
if any of those change then the curernt master-slave links have
changed and we need to reconfigure the transcoder port sync register
and hence trigger a full modeset.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 81e8cb9fe221..4bd23e61c6fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12524,6 +12524,11 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
PIPE_CONF_CHECK_INFOFRAME(spd);
PIPE_CONF_CHECK_INFOFRAME(hdmi);
+ if (INTEL_GEN(dev_priv) >= 11) {
+ PIPE_CONF_CHECK_I(trans_port_sync_slaves);
+ PIPE_CONF_CHECK_P(master_crtc);
+ }
+
#undef PIPE_CONF_CHECK_X
#undef PIPE_CONF_CHECK_I
#undef PIPE_CONF_CHECK_BOOL
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/fb-helper: Move modesetting code to drm_client (rev4)
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev4)
URL : https://patchwork.freedesktop.org/series/58597/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
Okay!
Commit: drm/fb-helper: Avoid race with DRM userspace
Okay!
Commit: drm/fb-helper: No need to cache rotation and sw_rotations
Okay!
Commit: drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
-O:drivers/gpu/drm/drm_fb_helper.c:2035:40: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2035:40: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2036:40: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2036:40: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2035:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2035:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2036:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2036:40: warning: expression using sizeof(void)
Commit: drm/fb-helper: Remove drm_fb_helper_crtc
-O:drivers/gpu/drm/drm_fb_helper.c:2052:43: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2052:43: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2015:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2015:43: warning: expression using sizeof(void)
-./include/linux/slab.h:666:13: error: not a function
+./include/linux/slab.h:666:13: error: undefined identifier
'__builtin_mul_overflow'
+./include/linux/slab.h:666:13: warning: call with no type!
Commit: drm/fb-helper: Prepare to move out commit code
+drivers/gpu/drm/drm_fb_helper.c:404:6: warning: symbol
'drm_client_panel_rotation' was not declared. Should it be static?
+drivers/gpu/drm/drm_fb_helper.c:579:5: warning: symbol
'drm_client_modeset_commit_force' was not declared. Should it be static?
+drivers/gpu/drm/drm_fb_helper.c:603:5: warning: symbol
'drm_client_modeset_commit' was not declared. Should it be static?
+drivers/gpu/drm/drm_fb_helper.c:739:5: warning: symbol
'drm_client_modeset_dpms' was not declared. Should it be static?
Commit: drm/fb-helper: Move out commit code
+drivers/gpu/drm/drm_fb_helper.c:1756:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1756:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1757:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1757:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1771:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1771:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1773:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1773:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2277:30: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:3223:12: warning: symbol
'drm_fb_helper_modinit' was not declared. Should it be static?
-drivers/gpu/drm/drm_fb_helper.c:1756:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1756:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1757:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1757:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1771:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1771:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1773:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1773:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:2277:30: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:404:6: warning: symbol
'drm_client_panel_rotation' was not declared. Should it be static?
-O:drivers/gpu/drm/drm_fb_helper.c:579:5: warning: symbol
'drm_client_modeset_commit_force' was not declared. Should it be static?
-O:drivers/gpu/drm/drm_fb_helper.c:603:5: warning: symbol
'drm_client_modeset_commit' was not declared. Should it be static?
-O:drivers/gpu/drm/drm_fb_helper.c:739:5: warning: symbol
'drm_client_modeset_dpms' was not declared. Should it be static?
Commit: drm/fb-helper: Remove drm_fb_helper_connector
-O:drivers/gpu/drm/drm_fb_helper.c:2277:30: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2076:30: warning: expression using sizeof(void)
-./include/linux/slab.h:666:13: error: not a function
Commit: drm/fb-helper: Prepare to move out modeset config code
-O:drivers/gpu/drm/drm_fb_helper.c:2076:30: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2080:30: warning: expression using sizeof(void)
Commit: drm/fb-helper: Move out modeset config code
+d
Re: [Intel-gfx] [PATCH 1/3] drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch context
On Fri, Apr 19, 2019 at 12:17:47PM +0100, Chris Wilson wrote:
> Despite what I think the prm recommends, commit f2253bd9859b
> ("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
> to be a huge mistake when enabling Ironlake contexts as the GPU would
> hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
> MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g.
> simple rendercopies with igt, do not suffer).
Where is the recommendation you mention? I couldn't immediately find it
in the docs. I did find the following statemtement:
"[DevCTG+]: For the invalidate operation of the pipe control, the
following pointers are affected. The
invalidate operation affects the restore of these packets. If the pipe
control invalidate operation is completed
before the context save, the indirect pointers will not be restored from
memory.
1. Pipeline State Pointer
2. Media State Pointer
3. Constant Buffer Packet"
Which maybe has something to do with this ordering?
But it's all black magic anyways. If it works it works.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 3844581f622c..8feb2d9b7b60 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1882,12 +1882,12 @@ static int ring_request_alloc(struct i915_request
> *request)
>*/
> request->reserved_space += LEGACY_REQUEST_SIZE;
>
> - ret = switch_context(request);
> + /* Unconditionally invalidate GPU caches and TLBs. */
> + ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
> if (ret)
> return ret;
>
> - /* Unconditionally invalidate GPU caches and TLBs. */
> - ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
> + ret = switch_context(request);
> if (ret)
> return ret;
>
> --
> 2.20.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.CHECKPATCH: warning for drm/fb-helper: Move modesetting code to drm_client (rev4)
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev4)
URL : https://patchwork.freedesktop.org/series/58597/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4a9806c7e6fe drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
0ba328ef9996 drm/fb-helper: Avoid race with DRM userspace
faf3b22de68a drm/fb-helper: No need to cache rotation and sw_rotations
433f6bb5a950 drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
6877829f5db8 drm/fb-helper: Remove drm_fb_helper_crtc
-:127: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#127:
new file mode 100644
-:204: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#204: FILE: drivers/gpu/drm/drm_client_modeset.c:73:
+}
+/* TODO: Remove export when modeset code has been moved over */
-:234: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#234: FILE: drivers/gpu/drm/drm_client_modeset.c:103:
+}
+/* TODO: Remove export when modeset code has been moved over */
-:928: WARNING:LONG_LINE: line over 100 characters
#928: FILE: drivers/gpu/drm/drm_fb_helper.c:2755:
+ if (WARN_ON_ONCE(modeset->num_connectors ==
DRM_CLIENT_MAX_CLONED_CONNECTORS ||
-:929: WARNING:LONG_LINE: line over 100 characters
#929: FILE: drivers/gpu/drm/drm_fb_helper.c:2756:
+(dev->mode_config.num_crtc > 1 &&
modeset->num_connectors == 1)))
-:1063: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'modeset' - possible
side-effects?
#1063: FILE: include/drm/drm_client.h:164:
+#define drm_client_for_each_modeset(modeset, client) \
+ for (({ lockdep_assert_held(&(client)->modeset_mutex); }), \
+modeset = (client)->modesets; modeset->crtc; modeset++)
-:1063: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'client' - possible
side-effects?
#1063: FILE: include/drm/drm_client.h:164:
+#define drm_client_for_each_modeset(modeset, client) \
+ for (({ lockdep_assert_held(&(client)->modeset_mutex); }), \
+modeset = (client)->modesets; modeset->crtc; modeset++)
total: 0 errors, 3 warnings, 4 checks, 962 lines checked
fc2de5684c87 drm/fb-helper: Prepare to move out commit code
e7bc8d3f4204 drm/fb-helper: Move out commit code
-:152: WARNING:LONG_LINE: line over 100 characters
#152: FILE: drivers/gpu/drm/drm_client_modeset.c:223:
+ struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
-:285: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#285: FILE: drivers/gpu/drm/drm_client_modeset.c:356:
+ drm_object_property_set_value(&connector->base,
+ dev->mode_config.dpms_property, dpms_mode);
total: 0 errors, 1 warnings, 1 checks, 610 lines checked
f4c1616a9e77 drm/fb-helper: Remove drm_fb_helper_connector
-:588: WARNING:LONG_LINE: line over 100 characters
#588: FILE: drivers/gpu/drm/drm_fb_helper.c:1959:
+ connector->base.id, connector->tile_group
? connector->tile_group->id : 0);
-:945: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#945: FILE: include/drm/drm_client.h:183:
+#define drm_client_for_each_connector_iter(connector, iter) \
+ drm_for_each_connector_iter(connector, iter) \
+ if (connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
-:945: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'connector' - possible
side-effects?
#945: FILE: include/drm/drm_client.h:183:
+#define drm_client_for_each_connector_iter(connector, iter) \
+ drm_for_each_connector_iter(connector, iter) \
+ if (connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
total: 1 errors, 1 warnings, 1 checks, 1006 lines checked
d349e5c6cae5 drm/fb-helper: Prepare to move out modeset config code
-:169: WARNING:LONG_LINE: line over 100 characters
#169: FILE: drivers/gpu/drm/drm_fb_helper.c:2351:
+(dev->mode_config.num_crtc > 1 &&
modeset->num_connectors == 1))) {
total: 0 errors, 1 warnings, 0 checks, 179 lines checked
eaf53f44dd76 drm/fb-helper: Move out modeset config code
-:99: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#99: FILE: drivers/gpu/drm/drm_client_modeset.c:140:
+ if (cmdline_mode->specified == false)
-:170: WARNING:LONG_LINE: line over 100 characters
#170: FILE: drivers/gpu/drm/drm_client_modeset.c:211:
+ connector->display_info.non_desktop ? "non
desktop" : enabled[i] ? "yes" : "no");
-:314: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#314: FILE: drivers/gpu/drm/drm_client_modeset.c:355:
+ if (enabled[i] == false) {
-:348: WARNING:LONG_LINE: line over 100 characters
#348: FILE: drivers/gpu/drm/drm_client_modeset.c:389:
+ connector->base.
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib/igt_dummyload: Introduce igt_spin_reset (rev2)
== Series Details == Series: series starting with [1/3] lib/igt_dummyload: Introduce igt_spin_reset (rev2) URL : https://patchwork.freedesktop.org/series/59830/ State : success == Summary == CI Bug Log - changes from CI_DRM_5971 -> IGTPW_2906 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59830/revisions/2/mbox/ Known issues Here are the changes found in IGTPW_2906 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235 ]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html * igt@i915_selftest@live_execlists: - fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] / [fdo#109720]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-apl-guc/igt@i915_selftest@live_execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/fi-apl-guc/igt@i915_selftest@live_execlists.html * igt@runner@aborted: - fi-apl-guc: NOTRUN -> [FAIL][5] ([fdo#108622] / [fdo#109720]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (50 -> 39) -- Missing(11): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-kbl-7500u fi-ctg-p8600 fi-pnv-d510 fi-icl-y fi-bdw-samus Build changes - * IGT: IGT_4959 -> IGTPW_2906 CI_DRM_5971: e91b848a66e8672c48ea65d082b260f13f2c86b9 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_2906: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/ IGT_4959: 504367d33b787de2ba8e007a5b620cfd6f0b3074 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2906/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/3] lib/igt_dummyload: Send batch as first
Quoting Mika Kuoppala (2019-04-23 15:00:38)
> @@ -41,8 +42,13 @@ typedef struct igt_spin {
> uint32_t cmd_precondition;
>
> int out_fence;
> - struct drm_i915_gem_exec_object2 obj[2];
> +
> + struct drm_i915_gem_exec_object2 _obj[3];
> +#define SPIN_OBJ_BATCH 0
> +#define SPIN_OBJ_POLL 1
> +#define SPIN_OBJ_DEP 2
I don't see the purpose in _obj[] if we keep on using it directly. Can
you please split this into a separate patch (the introduction of the
named indices and conversion of callers, but keep spin->obj[]).
If you have reason later to hide spin->obj[], by all means do introduce
spin->__obj[] with the helpers to hide it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/12] drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper
Den 23.04.2019 16.17, skrev Thomas Zimmermann:
> Hi
>
> Am 07.04.19 um 18:52 schrieb Noralf Trønnes:
>> It is generic code and having it in the helper will let other drivers
>> benefit from it.
>>
>> One change was necessary assuming this to be true:
>> INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc
>>
>> Suggested-by: Daniel Vetter
>> Cc: Jani Nikula
>> Cc: Joonas Lahtinen
>> Cc: Rodrigo Vivi
>> Cc: intel-gfx@lists.freedesktop.org
>> Signed-off-by: Noralf Trønnes
>> Reviewed-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_fb_helper.c| 194 -
>> drivers/gpu/drm/i915/intel_fbdev.c | 218 -
>> include/drm/drm_fb_helper.h| 23 ---
>> 3 files changed, 190 insertions(+), 245 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index a6be09ae899b..eda8b63f350d 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -2556,6 +2556,194 @@ static void drm_setup_crtc_rotation(struct
>> drm_fb_helper *fb_helper,
>> fb_helper->sw_rotations |= DRM_MODE_ROTATE_0;
>> }
>>
>> +static struct drm_fb_helper_crtc *
>> +drm_fb_helper_crtc(struct drm_fb_helper *fb_helper, struct drm_crtc *crtc)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < fb_helper->crtc_count; i++)
>> +if (fb_helper->crtc_info[i].mode_set.crtc == crtc)
>> +return &fb_helper->crtc_info[i];
>> +
>> +return NULL;
>> +}
>> +
>> +/* Try to read the BIOS display configuration and use it for the initial
>> config */
>> +static bool drm_fb_helper_firmware_config(struct drm_fb_helper *fb_helper,
>> + struct drm_fb_helper_crtc **crtcs,
>> + struct drm_display_mode **modes,
>> + struct drm_fb_offset *offsets,
>> + bool *enabled, int width, int height)
>> +{
>> +struct drm_device *dev = fb_helper->dev;
>> +unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
>> +unsigned long conn_configured, conn_seq;
>> +int i, j;
>> +bool *save_enabled;
>> +bool fallback = true, ret = true;
>> +int num_connectors_enabled = 0;
>> +int num_connectors_detected = 0;
>> +struct drm_modeset_acquire_ctx ctx;
>> +
>> +save_enabled = kcalloc(count, sizeof(bool), GFP_KERNEL);
>> +if (!save_enabled)
>> +return false;
>> +
>> +drm_modeset_acquire_init(&ctx, 0);
>> +
>> +while (drm_modeset_lock_all_ctx(dev, &ctx) != 0)
>> +drm_modeset_backoff(&ctx);
>> +
>> +memcpy(save_enabled, enabled, count);
>> +conn_seq = GENMASK(count - 1, 0);
>> +conn_configured = 0;
>> +retry:
>> +for (i = 0; i < count; i++) {
>> +struct drm_fb_helper_connector *fb_conn;
>> +struct drm_connector *connector;
>> +struct drm_encoder *encoder;
>> +struct drm_fb_helper_crtc *new_crtc;
>> +
>> +fb_conn = fb_helper->connector_info[i];
>> +connector = fb_conn->connector;
>> +
>> +if (conn_configured & BIT(i))
>> +continue;
>> +
>> +/* First pass, only consider tiled connectors */
>> +if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
>> +continue;
>> +
>> +if (connector->status == connector_status_connected)
>> +num_connectors_detected++;
>> +
>> +if (!enabled[i]) {
>> +DRM_DEBUG_KMS("connector %s not enabled, skipping\n",
>> + connector->name);
>> +conn_configured |= BIT(i);
>> +continue;
>> +}
>> +
>> +if (connector->force == DRM_FORCE_OFF) {
>> +DRM_DEBUG_KMS("connector %s is disabled by user,
>> skipping\n",
>> + connector->name);
>> +enabled[i] = false;
>> +continue;
>> +}
>> +
>> +encoder = connector->state->best_encoder;
>
> This patch breaks ast right here. Ast is a non-atomic driver and has
> connector->state set to NULL. Reading best_encoder gives a NULL-pointer
> dereference and the display turns black. Stack trace is below.
>
Thanks for the report, I've sent a fix.
Noralf.
> Best regards
> Thomas
>
>
> [ 29.583012] [drm:drm_fb_helper_firmware_config.isra.37
> [drm_kms_helper]] *ERROR* drivers/gpu/drm/drm_fb_helper.c:2649
> connector=db73d0b1
> [ 29.583048] [drm:drm_fb_helper_firmware_config.isra.37
> [drm_kms_helper]] *ERROR* drivers/gpu/drm/drm_fb_helper.c:2650
> connector->state= (null)
> 0m] Found device[ 29.609593] BUG: unable to handle kernel NULL pointer
> dereference at 0010
> [ 29.609594] #PF error: [normal kernel read fault]
> [ 29.609595] PGD 0 P4D 0
> [ 29.
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/sdvo: Check that we have space for the infoframe
On Mon, Apr 22, 2019 at 06:37:48PM +, Sripada, Radhakrishna wrote:
> On Wed, 2019-04-10 at 20:08 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Before we go writing the infoframe let's make sure we have
> > the space for it. Not that it really matters since the write
> > loop would just terminate early in that case.
> >
> > v2: Check after the debug print and ++ (Chris)
> >
> > Signed-off-by: Ville Syrjälä
> > Reviewed-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_sdvo.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index 7f64352a3413..14348dfb024a 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -976,6 +976,9 @@ static bool intel_sdvo_write_infoframe(struct
> > intel_sdvo *intel_sdvo,
> > DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size:
> > %i\n",
> > if_index, length, hbuf_size);
> If the above line is newly added why dont I See a + at the beginning of
> the line? Is it from a previous version of the patch?
It's not newly added. What gave you the idea that it was?
>
> -Radhakrishna(RK) Sripada
> >
> > + if (hbuf_size < length)
> > + return false;
> > +
> > for (i = 0; i < hbuf_size; i += 8) {
> > memset(tmp, 0, 8);
> > if (i < length)
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 i-g-t] tests/kms_flip: Skip VBlank tests in modules without VBlank
The kms_flip test relies on VBlank support, and this situation may
exclude some virtual drivers to take advantage of this set of tests.
This commit adds a mechanism that checks if a module has VBlank. If the
target module has VBlank support, kms_flip will run all the VBlank
tests; otherwise, the VBlank tests will be skipped. Additionally, this
commit improves the test coverage by checks if the function
drmWaitVBlank() returns EOPNOTSUPP (i.e., no VBlank support).
V6: Set errno to zero before call drmWaitVBlank()
V5: Drop the DRM_VBLANK_NEXTONMISS (Chris Wilson)
V4: Replace DRM_VBLANK_ABSOLUTE by DRM_VBLANK_RELATIVE and
DRM_VBLANK_NEXTONMISS
V3: Add documentation (Daniel Vetter)
V2: Add new branch coverage to check if VBlank is enabled or not and
update commit message
V1: Chris Wilson
- Change function name from igt_there_is_vblank to kms_has_vblank
- Move vblank function check from igt_aux to igt_kms
- Utilizes memset in dummy_vbl variable
- Directly return the result of drmWaitVBlank()
Signed-off-by: Rodrigo Siqueira
---
lib/igt_kms.c| 21 +
lib/igt_kms.h| 2 ++
tests/kms_flip.c | 22 ++
3 files changed, 45 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index df9aafd2..ca3073a0 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1656,6 +1656,27 @@ void igt_assert_plane_visible(int fd, enum pipe pipe,
int plane_index, bool visi
igt_assert_eq(visible, visibility);
}
+/**
+ * kms_has_vblank:
+ * @fd: DRM fd
+ *
+ * Get the VBlank errno after an attempt to call drmWaitVBlank(). This
+ * function is useful for checking if a driver has support or not for VBlank.
+ *
+ * Returns: true if target driver has VBlank support, otherwise return false.
+ */
+bool kms_has_vblank(int fd)
+{
+ drmVBlank dummy_vbl;
+
+ memset(&dummy_vbl, 0, sizeof(drmVBlank));
+ dummy_vbl.request.type = DRM_VBLANK_RELATIVE;
+
+ errno = 0;
+ drmWaitVBlank(fd, &dummy_vbl);
+ return (errno != EOPNOTSUPP);
+}
+
/*
* A small modeset API
*/
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 38bdc08f..b0ff79ab 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -230,6 +230,8 @@ void kmstest_wait_for_pageflip(int fd);
unsigned int kmstest_get_vblank(int fd, int pipe, unsigned int flags);
void igt_assert_plane_visible(int fd, enum pipe pipe, int plane_index, bool
visibility);
+bool kms_has_vblank(int fd);
+
/*
* A small modeset API
*/
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6287ce14..4e0471a9 100755
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -71,6 +71,7 @@
#define TEST_SUSPEND (1 << 26)
#define TEST_BO_TOOBIG (1 << 28)
+#define TEST_NO_VBLANK (1 << 29)
#define TEST_BASIC (1 << 30)
#define EVENT_FLIP (1 << 0)
@@ -126,6 +127,18 @@ struct event_state {
int seq_step;
};
+static bool vblank_dependence(int flags)
+{
+ int vblank_flags = TEST_VBLANK | TEST_VBLANK_BLOCK |
+ TEST_VBLANK_ABSOLUTE | TEST_VBLANK_EXPIRED_SEQ |
+ TEST_CHECK_TS | TEST_VBLANK_RACE;
+
+ if (flags & vblank_flags)
+ return true;
+
+ return false;
+}
+
static float timeval_float(const struct timeval *tv)
{
return tv->tv_sec + tv->tv_usec / 100.0f;
@@ -1176,6 +1189,7 @@ static void run_test_on_crtc_set(struct test_output *o,
int *crtc_idxs,
unsigned bo_size = 0;
uint64_t tiling;
int i;
+ bool vblank = true;
switch (crtc_count) {
case RUN_TEST:
@@ -1259,6 +1273,14 @@ static void run_test_on_crtc_set(struct test_output *o,
int *crtc_idxs,
}
igt_assert(fb_is_bound(o, o->fb_ids[0]));
+ vblank = kms_has_vblank(drm_fd);
+ if (!vblank) {
+ if (vblank_dependence(o->flags))
+ igt_require_f(vblank, "There is no VBlank\n");
+ else
+ o->flags |= TEST_NO_VBLANK;
+ }
+
/* quiescent the hw a bit so ensure we don't miss a single frame */
if (o->flags & TEST_CHECK_TS)
calibrate_ts(o, crtc_idxs[0]);
--
2.21.0
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/12] drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper
Hi
Am 07.04.19 um 18:52 schrieb Noralf Trønnes:
> It is generic code and having it in the helper will let other drivers
> benefit from it.
>
> One change was necessary assuming this to be true:
> INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc
>
> Suggested-by: Daniel Vetter
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Noralf Trønnes
> Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_fb_helper.c| 194 -
> drivers/gpu/drm/i915/intel_fbdev.c | 218 -
> include/drm/drm_fb_helper.h| 23 ---
> 3 files changed, 190 insertions(+), 245 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index a6be09ae899b..eda8b63f350d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2556,6 +2556,194 @@ static void drm_setup_crtc_rotation(struct
> drm_fb_helper *fb_helper,
> fb_helper->sw_rotations |= DRM_MODE_ROTATE_0;
> }
>
> +static struct drm_fb_helper_crtc *
> +drm_fb_helper_crtc(struct drm_fb_helper *fb_helper, struct drm_crtc *crtc)
> +{
> + int i;
> +
> + for (i = 0; i < fb_helper->crtc_count; i++)
> + if (fb_helper->crtc_info[i].mode_set.crtc == crtc)
> + return &fb_helper->crtc_info[i];
> +
> + return NULL;
> +}
> +
> +/* Try to read the BIOS display configuration and use it for the initial
> config */
> +static bool drm_fb_helper_firmware_config(struct drm_fb_helper *fb_helper,
> + struct drm_fb_helper_crtc **crtcs,
> + struct drm_display_mode **modes,
> + struct drm_fb_offset *offsets,
> + bool *enabled, int width, int height)
> +{
> + struct drm_device *dev = fb_helper->dev;
> + unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
> + unsigned long conn_configured, conn_seq;
> + int i, j;
> + bool *save_enabled;
> + bool fallback = true, ret = true;
> + int num_connectors_enabled = 0;
> + int num_connectors_detected = 0;
> + struct drm_modeset_acquire_ctx ctx;
> +
> + save_enabled = kcalloc(count, sizeof(bool), GFP_KERNEL);
> + if (!save_enabled)
> + return false;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> +
> + while (drm_modeset_lock_all_ctx(dev, &ctx) != 0)
> + drm_modeset_backoff(&ctx);
> +
> + memcpy(save_enabled, enabled, count);
> + conn_seq = GENMASK(count - 1, 0);
> + conn_configured = 0;
> +retry:
> + for (i = 0; i < count; i++) {
> + struct drm_fb_helper_connector *fb_conn;
> + struct drm_connector *connector;
> + struct drm_encoder *encoder;
> + struct drm_fb_helper_crtc *new_crtc;
> +
> + fb_conn = fb_helper->connector_info[i];
> + connector = fb_conn->connector;
> +
> + if (conn_configured & BIT(i))
> + continue;
> +
> + /* First pass, only consider tiled connectors */
> + if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
> + continue;
> +
> + if (connector->status == connector_status_connected)
> + num_connectors_detected++;
> +
> + if (!enabled[i]) {
> + DRM_DEBUG_KMS("connector %s not enabled, skipping\n",
> + connector->name);
> + conn_configured |= BIT(i);
> + continue;
> + }
> +
> + if (connector->force == DRM_FORCE_OFF) {
> + DRM_DEBUG_KMS("connector %s is disabled by user,
> skipping\n",
> + connector->name);
> + enabled[i] = false;
> + continue;
> + }
> +
> + encoder = connector->state->best_encoder;
This patch breaks ast right here. Ast is a non-atomic driver and has
connector->state set to NULL. Reading best_encoder gives a NULL-pointer
dereference and the display turns black. Stack trace is below.
Best regards
Thomas
[ 29.583012] [drm:drm_fb_helper_firmware_config.isra.37
[drm_kms_helper]] *ERROR* drivers/gpu/drm/drm_fb_helper.c:2649
connector=db73d0b1
[ 29.583048] [drm:drm_fb_helper_firmware_config.isra.37
[drm_kms_helper]] *ERROR* drivers/gpu/drm/drm_fb_helper.c:2650
connector->state= (null)
0m] Found device[ 29.609593] BUG: unable to handle kernel NULL pointer
dereference at 0010
[ 29.609594] #PF error: [normal kernel read fault]
[ 29.609595] PGD 0 P4D 0
[ 29.609597] Oops: [#1] SMP PTI
[ 29.609599] CPU: 1 PID: 354 Comm: systemd-udevd Tainted: G
E 5.1.0-rc5-1-default+ #11
[ 29.609600] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN
FIR
[Intel-gfx] [PATCH i-g-t 1/3] lib/igt_dummyload: Introduce igt_spin_reset
Libify resetting a spin for reuse.
v2: use also in perf_pmu
v3: s/cmd_spin/cmd_precondition
v4: remove early return for !spin (Chris)
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
lib/igt_dummyload.c | 17 +
lib/igt_dummyload.h | 2 ++
tests/i915/gem_exec_latency.c | 19 ---
tests/i915/gem_sync.c | 34 ++
tests/perf_pmu.c | 10 +-
5 files changed, 38 insertions(+), 44 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 1d57a53c..65957ed1 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -260,6 +260,8 @@ emit_recursive_batch(igt_spin_t *spin,
obj[SCRATCH].flags = EXEC_OBJECT_PINNED;
obj[BATCH].flags = EXEC_OBJECT_PINNED;
+ spin->cmd_precondition = *spin->batch;
+
return fence_fd;
}
@@ -366,6 +368,21 @@ void igt_spin_set_timeout(igt_spin_t *spin, int64_t ns)
spin->timer = timer;
}
+/**
+ * igt_spin_reset:
+ * @spin: spin state from igt_spin_new()
+ *
+ * Reset the state of spin, allowing its reuse.
+ */
+void igt_spin_reset(igt_spin_t *spin)
+{
+ if (igt_spin_has_poll(spin))
+ spin->poll[SPIN_POLL_START_IDX] = 0;
+
+ *spin->batch = spin->cmd_precondition;
+ __sync_synchronize();
+}
+
/**
* igt_spin_end:
* @spin: spin state from igt_spin_new()
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index d6482089..34537f27 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -37,6 +37,7 @@ typedef struct igt_spin {
timer_t timer;
struct igt_list link;
uint32_t *batch;
+ uint32_t cmd_precondition;
int out_fence;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_execbuffer2 execbuf;
@@ -68,6 +69,7 @@ igt_spin_factory(int fd, const struct igt_spin_factory *opts);
igt_spin_factory(fd, &((struct igt_spin_factory){__VA_ARGS__}))
void igt_spin_set_timeout(igt_spin_t *spin, int64_t ns);
+void igt_spin_reset(igt_spin_t *spin);
void igt_spin_end(igt_spin_t *spin);
void igt_spin_free(int fd, igt_spin_t *spin);
diff --git a/tests/i915/gem_exec_latency.c b/tests/i915/gem_exec_latency.c
index 6b7dfbc0..2cfb78bf 100644
--- a/tests/i915/gem_exec_latency.c
+++ b/tests/i915/gem_exec_latency.c
@@ -73,19 +73,17 @@ poll_ring(int fd, unsigned ring, const char *name)
unsigned long cycles;
igt_spin_t *spin[2];
uint64_t elapsed;
- uint32_t cmd;
gem_require_ring(fd, ring);
igt_require(gem_can_store_dword(fd, ring));
spin[0] = __igt_spin_factory(fd, &opts);
igt_assert(igt_spin_has_poll(spin[0]));
- cmd = *spin[0]->batch;
spin[1] = __igt_spin_factory(fd, &opts);
igt_assert(igt_spin_has_poll(spin[1]));
- igt_assert(cmd == *spin[1]->batch);
+ igt_assert(*spin[0]->batch == *spin[1]->batch);
igt_spin_end(spin[0]);
igt_spin_busywait_until_started(spin[1]);
@@ -96,8 +94,8 @@ poll_ring(int fd, unsigned ring, const char *name)
while ((elapsed = igt_nsec_elapsed(&tv)) < 2ull << 30) {
const unsigned int idx = cycles++ & 1;
- *spin[idx]->batch = cmd;
- spin[idx]->poll[SPIN_POLL_START_IDX] = 0;
+ igt_spin_reset(spin[idx]);
+
gem_execbuf(fd, &spin[idx]->execbuf);
igt_spin_end(spin[!idx]);
@@ -414,15 +412,6 @@ static void latency_from_ring(int fd,
}
}
-static void __rearm_spin(igt_spin_t *spin)
-{
- const uint32_t mi_arb_chk = 0x5 << 23;
-
- *spin->batch = mi_arb_chk;
- spin->poll[SPIN_POLL_START_IDX] = 0;
- __sync_synchronize();
-}
-
static void
__submit_spin(int fd, igt_spin_t *spin, unsigned int flags)
{
@@ -557,7 +546,7 @@ rthog_latency_on_ring(int fd, unsigned int engine, const
char *name, unsigned in
if (nengine > 1)
usleep(10*nengine);
- __rearm_spin(spin);
+ igt_spin_reset(spin);
igt_nsec_elapsed(&ts);
__submit_spin(fd, spin, engine);
diff --git a/tests/i915/gem_sync.c b/tests/i915/gem_sync.c
index f17ecd0b..8c5aaa14 100644
--- a/tests/i915/gem_sync.c
+++ b/tests/i915/gem_sync.c
@@ -209,7 +209,6 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
struct drm_i915_gem_execbuffer2 execbuf;
double end, this, elapsed, now, baseline;
unsigned long cycles;
- uint32_t cmd;
igt_spin_t *spin;
memset(&object, 0, sizeof(object));
@@ -226,7 +225,6 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
.flags = (IGT_SPIN_POLL_RUN |
IGT_SPIN
Re: [Intel-gfx] [PATCH i-g-t 2/3] lib/igt_dummyload: Clarify batch mapping
Quoting Mika Kuoppala (2019-04-23 15:00:37) > Use spin->condition to mark the spot we have > saved for manipulating the looping condition. ... to make the batch variable available for later reuse as a pointer to the object instead. Tell use why! Then tell us how you went about to accomplish that goal and what problems had to be resolved en route. > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/igt_dummyload: Introduce igt_spin_reset
Quoting Mika Kuoppala (2019-04-23 15:00:36)
> Libify resetting a spin for reuse.
>
> v2: use also in perf_pmu
> v3: s/cmd_spin/cmd_precondition
>
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Signed-off-by: Mika Kuoppala
> ---
> lib/igt_dummyload.c | 20
> lib/igt_dummyload.h | 2 ++
> tests/i915/gem_exec_latency.c | 19 ---
> tests/i915/gem_sync.c | 34 ++
> tests/perf_pmu.c | 10 +-
> 5 files changed, 41 insertions(+), 44 deletions(-)
>
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index 1d57a53c..12465024 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -260,6 +260,8 @@ emit_recursive_batch(igt_spin_t *spin,
> obj[SCRATCH].flags = EXEC_OBJECT_PINNED;
> obj[BATCH].flags = EXEC_OBJECT_PINNED;
>
> + spin->cmd_precondition = *spin->batch;
> +
> return fence_fd;
> }
>
> @@ -366,6 +368,24 @@ void igt_spin_set_timeout(igt_spin_t *spin, int64_t ns)
> spin->timer = timer;
> }
>
> +/**
> + * igt_spin_reset:
> + * @spin: spin state from igt_spin_new()
> + *
> + * Reset the state of spin, allowing its reuse.
> + */
> +void igt_spin_reset(igt_spin_t *spin)
> +{
> + if (!spin)
> + return;
Do we need to be defensive here? Being kind for cleanup, yes, but this
is runtime and users should have a valid spinner.
Other than that nit,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/3] lib/igt_dummyload: Send batch as first
To simplify emitting the recursive batch, make batch
always the first object on the execbuf list.
v2: set handles early, poll_ptr indecency (Chris)
v3: allow dep with poll
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
lib/igt_dummyload.c | 124
lib/igt_dummyload.h | 8 ++-
tests/i915/gem_concurrent_all.c | 3 +-
tests/i915/gem_exec_schedule.c | 14 ++--
tests/i915/gem_softpin.c| 2 +-
tests/i915/gem_spin_batch.c | 16 ++---
tests/i915/i915_hangman.c | 2 +-
7 files changed, 86 insertions(+), 83 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 8b0a2a17..dbcc3711 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -62,6 +62,7 @@
#define MI_ARB_CHK (0x5 << 23)
static const int BATCH_SIZE = 4096;
+static const int POLL_SIZE = 4096;
static const int LOOP_START_OFFSET = 64;
static IGT_LIST(spin_list);
@@ -71,16 +72,19 @@ static int
emit_recursive_batch(igt_spin_t *spin,
int fd, const struct igt_spin_factory *opts)
{
-#define SCRATCH 0
-#define BATCH 1
const int gen = intel_gen(intel_get_drm_devid(fd));
- struct drm_i915_gem_relocation_entry relocs[2], *r;
+ struct drm_i915_gem_exec_object2 * const batch =
+ &spin->_obj[SPIN_OBJ_BATCH];
+ struct drm_i915_gem_exec_object2 * const poll =
+ &spin->_obj[SPIN_OBJ_POLL];
+ struct drm_i915_gem_exec_object2 * const dep =
+ &spin->_obj[SPIN_OBJ_DEP];
+ struct drm_i915_gem_relocation_entry relocs[3], *r;
struct drm_i915_gem_execbuffer2 *execbuf;
- struct drm_i915_gem_exec_object2 *obj;
unsigned int engines[16];
unsigned int nengine;
int fence_fd = -1;
- uint32_t *cs, *batch;
+ uint32_t *cs, *batch_start;
int i;
nengine = 0;
@@ -101,65 +105,49 @@ emit_recursive_batch(igt_spin_t *spin,
memset(&spin->execbuf, 0, sizeof(spin->execbuf));
execbuf = &spin->execbuf;
- memset(spin->obj, 0, sizeof(spin->obj));
- obj = spin->obj;
+ memset(spin->_obj, 0, sizeof(spin->_obj));
memset(relocs, 0, sizeof(relocs));
- obj[BATCH].handle = gem_create(fd, BATCH_SIZE);
- batch = __gem_mmap__wc(fd, obj[BATCH].handle,
- 0, BATCH_SIZE, PROT_WRITE);
- if (!batch)
- batch = gem_mmap__gtt(fd, obj[BATCH].handle,
- BATCH_SIZE, PROT_WRITE);
+ batch->handle = gem_create(fd, BATCH_SIZE);
+ spin->handle = batch->handle;
- gem_set_domain(fd, obj[BATCH].handle,
+ batch_start = __gem_mmap__wc(fd, batch->handle,
+0, BATCH_SIZE, PROT_WRITE);
+ if (!batch_start)
+ batch_start = gem_mmap__gtt(fd, batch->handle,
+ BATCH_SIZE, PROT_WRITE);
+ gem_set_domain(fd, batch->handle,
I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
execbuf->buffer_count++;
- cs = batch;
+ cs = batch_start;
- if (opts->dependency) {
- igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN));
-
- r = &relocs[obj[BATCH].relocation_count++];
-
- /* dummy write to dependency */
- obj[SCRATCH].handle = opts->dependency;
- r->presumed_offset = 0;
- r->target_handle = obj[SCRATCH].handle;
- r->offset = sizeof(uint32_t) * 1020;
- r->delta = 0;
- r->read_domains = I915_GEM_DOMAIN_RENDER;
- r->write_domain = I915_GEM_DOMAIN_RENDER;
-
- execbuf->buffer_count++;
- } else if (opts->flags & IGT_SPIN_POLL_RUN) {
- r = &relocs[obj[BATCH].relocation_count++];
+ poll->handle = gem_create(fd, POLL_SIZE);
+ spin->poll_handle = poll->handle;
+ execbuf->buffer_count++;
- igt_assert(!opts->dependency);
+ if (opts->flags & IGT_SPIN_POLL_RUN) {
+ r = &relocs[batch->relocation_count++];
if (gen == 4 || gen == 5) {
execbuf->flags |= I915_EXEC_SECURE;
igt_require(__igt_device_set_master(fd) == 0);
}
- spin->poll_handle = gem_create(fd, 4096);
- obj[SCRATCH].handle = spin->poll_handle;
-
- if (__gem_set_caching(fd, spin->poll_handle,
+ if (__gem_set_caching(fd, poll->handle,
I915_CACHING_CACHED) == 0)
- spin->poll = gem_mmap__cpu(fd, spin->poll_handle,
- 0, 4096,
+ spin->poll = gem_mmap__cpu(fd, poll->handle,
+ 0, POLL_SIZE,
PROT_READ | PROT_WRITE);
else
-
[Intel-gfx] [PATCH i-g-t 1/3] lib/igt_dummyload: Introduce igt_spin_reset
Libify resetting a spin for reuse.
v2: use also in perf_pmu
v3: s/cmd_spin/cmd_precondition
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Mika Kuoppala
---
lib/igt_dummyload.c | 20
lib/igt_dummyload.h | 2 ++
tests/i915/gem_exec_latency.c | 19 ---
tests/i915/gem_sync.c | 34 ++
tests/perf_pmu.c | 10 +-
5 files changed, 41 insertions(+), 44 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 1d57a53c..12465024 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -260,6 +260,8 @@ emit_recursive_batch(igt_spin_t *spin,
obj[SCRATCH].flags = EXEC_OBJECT_PINNED;
obj[BATCH].flags = EXEC_OBJECT_PINNED;
+ spin->cmd_precondition = *spin->batch;
+
return fence_fd;
}
@@ -366,6 +368,24 @@ void igt_spin_set_timeout(igt_spin_t *spin, int64_t ns)
spin->timer = timer;
}
+/**
+ * igt_spin_reset:
+ * @spin: spin state from igt_spin_new()
+ *
+ * Reset the state of spin, allowing its reuse.
+ */
+void igt_spin_reset(igt_spin_t *spin)
+{
+ if (!spin)
+ return;
+
+ if (igt_spin_has_poll(spin))
+ spin->poll[SPIN_POLL_START_IDX] = 0;
+
+ *spin->batch = spin->cmd_precondition;
+ __sync_synchronize();
+}
+
/**
* igt_spin_end:
* @spin: spin state from igt_spin_new()
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index d6482089..34537f27 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -37,6 +37,7 @@ typedef struct igt_spin {
timer_t timer;
struct igt_list link;
uint32_t *batch;
+ uint32_t cmd_precondition;
int out_fence;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_execbuffer2 execbuf;
@@ -68,6 +69,7 @@ igt_spin_factory(int fd, const struct igt_spin_factory *opts);
igt_spin_factory(fd, &((struct igt_spin_factory){__VA_ARGS__}))
void igt_spin_set_timeout(igt_spin_t *spin, int64_t ns);
+void igt_spin_reset(igt_spin_t *spin);
void igt_spin_end(igt_spin_t *spin);
void igt_spin_free(int fd, igt_spin_t *spin);
diff --git a/tests/i915/gem_exec_latency.c b/tests/i915/gem_exec_latency.c
index 6b7dfbc0..2cfb78bf 100644
--- a/tests/i915/gem_exec_latency.c
+++ b/tests/i915/gem_exec_latency.c
@@ -73,19 +73,17 @@ poll_ring(int fd, unsigned ring, const char *name)
unsigned long cycles;
igt_spin_t *spin[2];
uint64_t elapsed;
- uint32_t cmd;
gem_require_ring(fd, ring);
igt_require(gem_can_store_dword(fd, ring));
spin[0] = __igt_spin_factory(fd, &opts);
igt_assert(igt_spin_has_poll(spin[0]));
- cmd = *spin[0]->batch;
spin[1] = __igt_spin_factory(fd, &opts);
igt_assert(igt_spin_has_poll(spin[1]));
- igt_assert(cmd == *spin[1]->batch);
+ igt_assert(*spin[0]->batch == *spin[1]->batch);
igt_spin_end(spin[0]);
igt_spin_busywait_until_started(spin[1]);
@@ -96,8 +94,8 @@ poll_ring(int fd, unsigned ring, const char *name)
while ((elapsed = igt_nsec_elapsed(&tv)) < 2ull << 30) {
const unsigned int idx = cycles++ & 1;
- *spin[idx]->batch = cmd;
- spin[idx]->poll[SPIN_POLL_START_IDX] = 0;
+ igt_spin_reset(spin[idx]);
+
gem_execbuf(fd, &spin[idx]->execbuf);
igt_spin_end(spin[!idx]);
@@ -414,15 +412,6 @@ static void latency_from_ring(int fd,
}
}
-static void __rearm_spin(igt_spin_t *spin)
-{
- const uint32_t mi_arb_chk = 0x5 << 23;
-
- *spin->batch = mi_arb_chk;
- spin->poll[SPIN_POLL_START_IDX] = 0;
- __sync_synchronize();
-}
-
static void
__submit_spin(int fd, igt_spin_t *spin, unsigned int flags)
{
@@ -557,7 +546,7 @@ rthog_latency_on_ring(int fd, unsigned int engine, const
char *name, unsigned in
if (nengine > 1)
usleep(10*nengine);
- __rearm_spin(spin);
+ igt_spin_reset(spin);
igt_nsec_elapsed(&ts);
__submit_spin(fd, spin, engine);
diff --git a/tests/i915/gem_sync.c b/tests/i915/gem_sync.c
index f17ecd0b..8c5aaa14 100644
--- a/tests/i915/gem_sync.c
+++ b/tests/i915/gem_sync.c
@@ -209,7 +209,6 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
struct drm_i915_gem_execbuffer2 execbuf;
double end, this, elapsed, now, baseline;
unsigned long cycles;
- uint32_t cmd;
igt_spin_t *spin;
memset(&object, 0, sizeof(object));
@@ -226,7 +225,6 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
.flags = (IGT_SPIN_POLL_RUN |
IGT_SPIN_FAST));
[Intel-gfx] [PATCH i-g-t 2/3] lib/igt_dummyload: Clarify batch mapping
Use spin->condition to mark the spot we have
saved for manipulating the looping condition.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
lib/igt_dummyload.c | 66 ---
lib/igt_dummyload.h | 4 ++-
tests/i915/gem_exec_latency.c | 2 --
3 files changed, 40 insertions(+), 32 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 12465024..8b0a2a17 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -62,6 +62,8 @@
#define MI_ARB_CHK (0x5 << 23)
static const int BATCH_SIZE = 4096;
+static const int LOOP_START_OFFSET = 64;
+
static IGT_LIST(spin_list);
static pthread_mutex_t list_lock = PTHREAD_MUTEX_INITIALIZER;
@@ -78,7 +80,7 @@ emit_recursive_batch(igt_spin_t *spin,
unsigned int engines[16];
unsigned int nengine;
int fence_fd = -1;
- uint32_t *batch, *batch_start;
+ uint32_t *cs, *batch;
int i;
nengine = 0;
@@ -108,11 +110,12 @@ emit_recursive_batch(igt_spin_t *spin,
0, BATCH_SIZE, PROT_WRITE);
if (!batch)
batch = gem_mmap__gtt(fd, obj[BATCH].handle,
- BATCH_SIZE, PROT_WRITE);
+ BATCH_SIZE, PROT_WRITE);
+
gem_set_domain(fd, obj[BATCH].handle,
- I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+ I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
execbuf->buffer_count++;
- batch_start = batch;
+ cs = batch;
if (opts->dependency) {
igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN));
@@ -160,31 +163,34 @@ emit_recursive_batch(igt_spin_t *spin,
r->offset = sizeof(uint32_t) * 1;
r->delta = sizeof(uint32_t) * SPIN_POLL_START_IDX;
- *batch++ = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22 : 0);
+ *cs++ = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22 : 0);
if (gen >= 8) {
- *batch++ = r->presumed_offset + r->delta;
- *batch++ = 0;
+ *cs++ = r->presumed_offset + r->delta;
+ *cs++ = 0;
} else if (gen >= 4) {
- *batch++ = 0;
- *batch++ = r->presumed_offset + r->delta;
+ *cs++ = 0;
+ *cs++ = r->presumed_offset + r->delta;
r->offset += sizeof(uint32_t);
} else {
- batch[-1]--;
- *batch++ = r->presumed_offset + r->delta;
+ cs[-1]--;
+ *cs++ = r->presumed_offset + r->delta;
}
- *batch++ = 1;
+ *cs++ = 1;
execbuf->buffer_count++;
}
- spin->batch = batch = batch_start + 64 / sizeof(*batch);
spin->handle = obj[BATCH].handle;
+ igt_assert_lt(cs - batch, LOOP_START_OFFSET / sizeof(*cs));
+ spin->condition = batch + LOOP_START_OFFSET / sizeof(*cs);
+ cs = spin->condition;
+
/* Allow ourselves to be preempted */
if (!(opts->flags & IGT_SPIN_NO_PREEMPTION))
- *batch++ = MI_ARB_CHK;
+ *cs++ = MI_ARB_CHK;
/* Pad with a few nops so that we do not completely hog the system.
*
@@ -198,27 +204,27 @@ emit_recursive_batch(igt_spin_t *spin,
* trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
*/
if (!(opts->flags & IGT_SPIN_FAST))
- batch += 1000;
+ cs += 1000;
/* recurse */
r = &relocs[obj[BATCH].relocation_count++];
r->target_handle = obj[BATCH].handle;
- r->offset = (batch + 1 - batch_start) * sizeof(*batch);
+ r->offset = (cs + 1 - batch) * sizeof(*cs);
r->read_domains = I915_GEM_DOMAIN_COMMAND;
- r->delta = 64;
+ r->delta = LOOP_START_OFFSET;
if (gen >= 8) {
- *batch++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
- *batch++ = r->delta;
- *batch++ = 0;
+ *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
+ *cs++ = r->delta;
+ *cs++ = 0;
} else if (gen >= 6) {
- *batch++ = MI_BATCH_BUFFER_START | 1 << 8;
- *batch++ = r->delta;
+ *cs++ = MI_BATCH_BUFFER_START | 1 << 8;
+ *cs++ = r->delta;
} else {
- *batch++ = MI_BATCH_BUFFER_START | 2 << 6;
+ *cs++ = MI_BATCH_BUFFER_START | 2 << 6;
if (gen < 4)
r->delta |= 1;
- *batch = r->delta;
- batch++;
+ *cs = r->delta;
+ cs++;
}
obj[BATCH].relocs_ptr = to_user_pointer(relocs);
@@ -252,6 +258,8 @@ emit_recursive_batch(igt_spin_t *spin,
}
}
+ igt_assert_lt(c
Re: [Intel-gfx] [PATCH 12/32] drm/i915: Invert the GEM wakeref hierarchy
On 17/04/2019 08:56, Chris Wilson wrote: In the current scheme, on submitting a request we take a single global GEM wakeref, which trickles down to wake up all GT power domains. This is undesirable as we would like to be able to localise our power management to the available power domains and to remove the global GEM operations from the heart of the driver. (The intent there is to push global GEM decisions to the boundary as used by the GEM user interface.) Now during request construction, each request is responsible via its logical context to acquire a wakeref on each power domain it intends to utilize. Currently, each request takes a wakeref on the engine(s) and the engines themselves take a chipset wakeref. This gives us a transition on each engine which we can extend if we want to insert more powermangement control (such as soft rc6). The global GEM operations that currently require a struct_mutex are reduced to listening to pm events from the chipset GT wakeref. As we reduce the struct_mutex requirement, these listeners should evaporate. Perhaps the biggest immediate change is that this removes the struct_mutex requirement around GT power management, allowing us greater flexibility in request construction. Another important knock-on effect, is that by tracking engine usage, we can insert a switch back to the kernel context on that engine immediately, avoiding any extra delay or inserting global synchronisation barriers. This makes tracking when an engine and its associated contexts are idle much easier -- important for when we forgo our assumed execution ordering and need idle barriers to unpin used contexts. In the process, it means we remove a large chunk of code whose only purpose was to switch back to the kernel context. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Imre Deak There will be some inconsequential changes after rebase, but in principle: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko --- drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/gt/intel_context.c | 18 +- drivers/gpu/drm/i915/gt/intel_engine.h| 9 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 142 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 153 ++ drivers/gpu/drm/i915/gt/intel_engine_pm.h | 20 ++ drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 143 ++ drivers/gpu/drm/i915/gt/intel_gt_pm.h | 27 ++ drivers/gpu/drm/i915/gt/intel_hangcheck.c | 7 + drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +- drivers/gpu/drm/i915/gt/intel_reset.c | 101 +-- drivers/gpu/drm/i915/gt/intel_reset.h | 1 - drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 16 +- drivers/gpu/drm/i915/gt/mock_engine.c | 3 + drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 49 +--- .../gpu/drm/i915/gt/selftest_workarounds.c| 5 +- drivers/gpu/drm/i915/i915_debugfs.c | 16 +- drivers/gpu/drm/i915/i915_drv.c | 5 +- drivers/gpu/drm/i915/i915_drv.h | 8 +- drivers/gpu/drm/i915/i915_gem.c | 41 +-- drivers/gpu/drm/i915/i915_gem.h | 3 - drivers/gpu/drm/i915/i915_gem_context.c | 85 +- drivers/gpu/drm/i915/i915_gem_context.h | 4 - drivers/gpu/drm/i915/i915_gem_evict.c | 47 +--- drivers/gpu/drm/i915/i915_gem_pm.c| 264 ++ drivers/gpu/drm/i915/i915_gem_pm.h| 3 - drivers/gpu/drm/i915/i915_gpu_error.h | 4 - drivers/gpu/drm/i915/i915_request.c | 10 +- drivers/gpu/drm/i915/i915_request.h | 2 +- drivers/gpu/drm/i915/intel_uc.c | 22 +- drivers/gpu/drm/i915/intel_uc.h | 2 +- drivers/gpu/drm/i915/selftests/i915_gem.c | 16 +- .../gpu/drm/i915/selftests/i915_gem_context.c | 114 +--- .../gpu/drm/i915/selftests/i915_gem_object.c | 29 +- .../gpu/drm/i915/selftests/igt_flush_test.c | 32 ++- .../gpu/drm/i915/selftests/mock_gem_device.c | 15 +- 37 files changed, 598 insertions(+), 833 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pm.c create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_pm.h create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 858642c7bc40..dd8d923aa1c6 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -71,6 +71,8 @@ gt-y += \ gt/intel_breadcrumbs.o \ gt/intel_context.o \ gt/intel_engine_cs.o \ + gt/intel_engine_pm.o \ + gt/intel_gt_pm.o \ gt/intel_hangcheck.o \ gt/intel_lrc.o \ gt/intel_reset.o \ diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 4410e20e8e13..298e463ad0
Re: [Intel-gfx] [PATCH 01/32] drm/i915: Seal races between async GPU cancellation, retirement and signaling
On 17/04/2019 08:56, Chris Wilson wrote:
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an interrupt for that request while it
is no longer in flight.
CPU0CPU1
intel_engine_breadcrumbs_irq
(queue request completion)
i915_request_cancel_signaling
... ...
i915_request_enable_signaling
dma_fence_signal
Hence in the time it took us to drop the lock to signal the request, a
preemption event may have occurred and re-queued the request. In the
process, that request would have seen I915_FENCE_FLAG_SIGNAL clear and
so reused the rq->signal_link that was in use on CPU0, leading to bad
pointer chasing in intel_engine_breadcrumbs_irq.
A related issue was that if someone started listening for a signal on a
completed but no longer in-flight request, we missed the opportunity to
immediately signal that request.
Furthermore, as intel_contexts may be immediately released during
request retirement, in order to be entirely sure that
intel_engine_breadcrumbs_irq may no longer dereference the intel_context
(ce->signals and ce->signal_link), we must wait for irq spinlock.
In order to prevent the race, we use a bit in the fence.flags to signal
the transfer onto the signal list inside intel_engine_breadcrumbs_irq.
For simplicity, we use the DMA_FENCE_FLAG_SIGNALED_BIT as it then
quickly signals to any outside observer that the fence is indeed signaled.
Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context
interrupt tracking")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 1 +
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 52 ++--
3 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 3aa8733f832a..9bf06042619a 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -29,6 +29,7 @@
EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
static DEFINE_SPINLOCK(dma_fence_stub_lock);
static struct dma_fence dma_fence_stub;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index b836721d3b13..e0efc334463b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -432,6 +432,7 @@ void __i915_request_submit(struct i915_request *request)
set_bit(I915_FENCE_FLAG_ACTIVE, &request->fence.flags);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags) &&
+ !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &request->fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_queue_breadcrumbs(engine);
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3cbffd400b1b..e19f84b006cc 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include "i915_drv.h"
@@ -83,6 +84,7 @@ static inline bool __request_completed(const struct
i915_request *rq)
void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ const ktime_t timestamp = ktime_get();
struct intel_context *ce, *cn;
struct list_head *pos, *next;
LIST_HEAD(signal);
@@ -104,6 +106,11 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_SIGNAL,
&rq->fence.flags));
+ clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
+
+ if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+&rq->fence.flags))
+ continue;
From here to below is intimate coupling with the dma_fence_signal
implementation, via open-coding it (with some optimizations as well).
I am thinking about this solution.. here we put:
if (!__dma_fence_maybe_signal(&rq->fence))
continue;
Add the low-level helper to dma-fence.c and export it.
And below..
/*
* Queue for execution after dropping the signaling
@@ -111,14 +118,6 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
* more signalers to the same context or engine.
*/
i915_request_get(rq);
-
-
Re: [Intel-gfx] [PATCH v5 04/12] drm/i915: Attach content type property
On Tue, Apr 23, 2019 at 1:15 PM Ramalingam C wrote:
>
> On 2019-04-23 at 10:11:48 +0200, Daniel Vetter wrote:
> > On Thu, Apr 18, 2019 at 02:27:57PM +0530, Ramalingam C wrote:
> > > Attaches the content type property for HDCP2.2 capable connectors.
> > >
> > > Implements the update of content type from property and apply the
> > > restriction on HDCP version selection.
> > >
> > > v2:
> > > s/cp_content_type/content_protection_type [daniel]
> > > disable at hdcp_atomic_check to avoid check at atomic_set_property
> > > [Maarten]
> > > v3:
> > > s/content_protection_type/hdcp_content_type [Pekka]
> > > v4:
> > > hdcp disable incase of type change is moved into commit [daniel].
> > >
> > > Signed-off-by: Ramalingam C
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c | 38 ---
> > > drivers/gpu/drm/i915/intel_hdcp.c | 43 ---
> > > drivers/gpu/drm/i915/intel_hdcp.h | 2 +-
> > > 3 files changed, 63 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 24f9106efcc6..dd9bea840937 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -3476,7 +3476,8 @@ static void intel_enable_ddi(struct intel_encoder
> > > *encoder,
> > > /* Enable hdcp if it's desired */
> > > if (conn_state->content_protection ==
> > > DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > > - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> > > + intel_hdcp_enable(to_intel_connector(conn_state->connector),
> > > + (u8)conn_state->hdcp_content_type);
> > > }
> > >
> > > static void intel_disable_ddi_dp(struct intel_encoder *encoder,
> > > @@ -3545,15 +3546,44 @@ static void intel_ddi_update_pipe(struct
> > > intel_encoder *encoder,
> > > const struct intel_crtc_state *crtc_state,
> > > const struct drm_connector_state
> > > *conn_state)
> > > {
> > > + struct intel_connector *connector =
> > > + to_intel_connector(conn_state->connector);
> > > + struct intel_hdcp *hdcp = &connector->hdcp;
> > > + bool re_enable_hdcp = false;
> > > + int ret = -EINVAL;
> > > +
> > > if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > > intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
> > >
> > > + /*
> > > +* During the HDCP encryption session if Type change is requested,
> > > +* disable the HDCP and reenable it with new TYPE value.
> > > +*/
> > > if (conn_state->content_protection ==
> > > - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > > - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> > > + DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > > + conn_state->hdcp_content_type != hdcp->content_type) {
> > > + intel_hdcp_disable(to_intel_connector(conn_state->connector));
> > > + re_enable_hdcp = true;
> > > + }
> > > +
> > > + if (conn_state->content_protection ==
> > > + DRM_MODE_CONTENT_PROTECTION_DESIRED || re_enable_hdcp)
> > > + ret = intel_hdcp_enable(connector,
> > > + (u8)conn_state->hdcp_content_type);
> > > else if (conn_state->content_protection ==
> > > DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> > > - intel_hdcp_disable(to_intel_connector(conn_state->connector));
> > > + intel_hdcp_disable(connector);
> > > +
> > > + /*
> > > +* During Type change handling re-enabling of the HDCP failed. Hence
> > > +* changes state as ENABLED->DESIRED.
> > > +*/
> > > + if (ret && re_enable_hdcp) {
> > > + mutex_lock(&hdcp->mutex);
> > > + hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > > + schedule_work(&hdcp->prop_work);
> > > + mutex_unlock(&hdcp->mutex);
> > > + }
> >
> > I'm unhappy with the convoluted logic here. It's correct I think but
> > fairly hard to follow. What about this instead?
> >
> > unsigned int content_protection = conn_state->content_protection;
> > bool content_protection_type_changed =
> > conn_state->hdcp_content_type != hdcp->content_type;
> >
> > if (conn_state->content_protection ==
> >DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
> > content_protection_type_changed)
> > intel_hdcp_disable(to_intel_connector(conn_state->connector));
> >
> > /* Make sure we pick up type changes */
> > if (content_protection_type_changed) {
> > mutex_lock(&hdcp->mutex);
> > hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > schedule_work(&hdcp->prop_work);
> > mutex_unlock(&hdcp->mutex);
> > }
> >
> > if (conn_state->content_protection ==
> > DRM_MODE_CONTENT_PROTECTION_DESI
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores
Check that we can reorder batches around userspace sempahore waits by
injecting a semaphore that is only released by a later context.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 143 +
1 file changed, 143 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 9a0795281..812197770 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -52,6 +52,15 @@
#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+#define MI_SEMAPHORE_WAIT (0x1c << 23)
+#define MI_SEMAPHORE_POLL (1 << 15)
+#define MI_SEMAPHORE_SAD_GT_SDD (0 << 12)
+#define MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
+#define MI_SEMAPHORE_SAD_LT_SDD (2 << 12)
+#define MI_SEMAPHORE_SAD_LTE_SDD (3 << 12)
+#define MI_SEMAPHORE_SAD_EQ_SDD (4 << 12)
+#define MI_SEMAPHORE_SAD_NEQ_SDD (5 << 12)
+
IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
static inline
@@ -463,6 +472,138 @@ static void semaphore_codependency(int i915)
}
}
+static unsigned int offset_in_page(void *addr)
+{
+ return (uintptr_t)addr & 4095;
+}
+
+static void semaphore_resolve(int i915)
+{
+ const uint32_t SEMAPHORE_ADDR = 64 << 10;
+ uint32_t semaphore, outer, inner, *sema;
+ unsigned int engine;
+
+ /*
+* Userspace may submit batches that wait upon unresolved
+* semaphores. Ideally, we want to put those blocking batches
+* to the back of the execution queue if we have something else
+* that is ready to run right away. This test exploits a failure
+* to reorder batches around a blocking semaphore by submitting
+* the release of that semaphore from a later context.
+*/
+
+ igt_require(gem_scheduler_has_preemption(i915));
+ igt_assert(intel_get_drm_devid(i915) >= 8);
+
+ outer = gem_context_create(i915);
+ inner = gem_context_create(i915);
+
+ semaphore = gem_create(i915, 4096);
+ sema = gem_mmap__wc(i915, semaphore, 0, 4096, PROT_WRITE);
+
+ for_each_physical_engine(i915, engine) {
+ struct drm_i915_gem_exec_object2 obj[3];
+ struct drm_i915_gem_execbuffer2 eb;
+ uint32_t handle, cancel;
+ uint32_t *cs, *map;
+ igt_spin_t *spin;
+
+ if (!gem_can_store_dword(i915, engine))
+ continue;
+
+ spin = __igt_spin_new(i915, .engine = engine);
+ cancel = *spin->batch;
+ igt_spin_end(spin); /* we just want its address for later */
+ gem_sync(i915, spin->handle);
+ *spin->batch = cancel;
+
+ handle = gem_create(i915, 4096);
+ cs = map = gem_mmap__cpu(i915, handle, 0, 4096, PROT_WRITE);
+
+ /* Set semaphore initially to 1 for polling and signaling */
+ *cs++ = MI_STORE_DWORD_IMM;
+ *cs++ = SEMAPHORE_ADDR;
+ *cs++ = 0;
+ *cs++ = 1;
+
+ /* Wait until another batch writes to our semaphore */
+ *cs++ = MI_SEMAPHORE_WAIT |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_EQ_SDD |
+ (4 - 2);
+ *cs++ = 0;
+ *cs++ = SEMAPHORE_ADDR;
+ *cs++ = 0;
+
+ /* Then cancel the spinner */
+ *cs++ = MI_STORE_DWORD_IMM;
+ *cs++ = spin->obj[1].offset + offset_in_page(spin->batch);
+ *cs++ = 0;
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ *cs++ = MI_BATCH_BUFFER_END;
+ munmap(map, 4096);
+
+ memset(&eb, 0, sizeof(eb));
+
+ /* First up is our spinning semaphore */
+ memset(obj, 0, sizeof(obj));
+ obj[0] = spin->obj[1];
+ obj[1].handle = semaphore;
+ obj[1].offset = SEMAPHORE_ADDR;
+ obj[1].flags = EXEC_OBJECT_PINNED;
+ obj[2].handle = handle;
+ eb.buffer_count = 3;
+ eb.buffers_ptr = to_user_pointer(obj);
+ eb.rsvd1 = outer;
+ gem_execbuf(i915, &eb);
+
+ /* Then add the GPU hang intermediatory */
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = handle;
+ obj[0].flags = EXEC_OBJECT_WRITE; /* always after semaphore */
+ obj[1] = spin->obj[1];
+ eb.buffer_count = 2;
+ eb.rsvd1 = 0;
+ gem_execbuf(i915, &eb);
+
+ while (READ_ONCE(*sema) == 0)
+ ;
+
+ /* Now the semaphore is spinning, cancel it */
+ cancel = gem_create(i915, 4096);
+ cs = map = gem_mmap__cpu
Re: [Intel-gfx] [PATCH v5 04/12] drm/i915: Attach content type property
On 2019-04-23 at 10:11:48 +0200, Daniel Vetter wrote:
> On Thu, Apr 18, 2019 at 02:27:57PM +0530, Ramalingam C wrote:
> > Attaches the content type property for HDCP2.2 capable connectors.
> >
> > Implements the update of content type from property and apply the
> > restriction on HDCP version selection.
> >
> > v2:
> > s/cp_content_type/content_protection_type [daniel]
> > disable at hdcp_atomic_check to avoid check at atomic_set_property
> > [Maarten]
> > v3:
> > s/content_protection_type/hdcp_content_type [Pekka]
> > v4:
> > hdcp disable incase of type change is moved into commit [daniel].
> >
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 38 ---
> > drivers/gpu/drm/i915/intel_hdcp.c | 43 ---
> > drivers/gpu/drm/i915/intel_hdcp.h | 2 +-
> > 3 files changed, 63 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 24f9106efcc6..dd9bea840937 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3476,7 +3476,8 @@ static void intel_enable_ddi(struct intel_encoder
> > *encoder,
> > /* Enable hdcp if it's desired */
> > if (conn_state->content_protection ==
> > DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> > + intel_hdcp_enable(to_intel_connector(conn_state->connector),
> > + (u8)conn_state->hdcp_content_type);
> > }
> >
> > static void intel_disable_ddi_dp(struct intel_encoder *encoder,
> > @@ -3545,15 +3546,44 @@ static void intel_ddi_update_pipe(struct
> > intel_encoder *encoder,
> > const struct intel_crtc_state *crtc_state,
> > const struct drm_connector_state *conn_state)
> > {
> > + struct intel_connector *connector =
> > + to_intel_connector(conn_state->connector);
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > + bool re_enable_hdcp = false;
> > + int ret = -EINVAL;
> > +
> > if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
> >
> > + /*
> > +* During the HDCP encryption session if Type change is requested,
> > +* disable the HDCP and reenable it with new TYPE value.
> > +*/
> > if (conn_state->content_protection ==
> > - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> > + DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > + conn_state->hdcp_content_type != hdcp->content_type) {
> > + intel_hdcp_disable(to_intel_connector(conn_state->connector));
> > + re_enable_hdcp = true;
> > + }
> > +
> > + if (conn_state->content_protection ==
> > + DRM_MODE_CONTENT_PROTECTION_DESIRED || re_enable_hdcp)
> > + ret = intel_hdcp_enable(connector,
> > + (u8)conn_state->hdcp_content_type);
> > else if (conn_state->content_protection ==
> > DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> > - intel_hdcp_disable(to_intel_connector(conn_state->connector));
> > + intel_hdcp_disable(connector);
> > +
> > + /*
> > +* During Type change handling re-enabling of the HDCP failed. Hence
> > +* changes state as ENABLED->DESIRED.
> > +*/
> > + if (ret && re_enable_hdcp) {
> > + mutex_lock(&hdcp->mutex);
> > + hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > + schedule_work(&hdcp->prop_work);
> > + mutex_unlock(&hdcp->mutex);
> > + }
>
> I'm unhappy with the convoluted logic here. It's correct I think but
> fairly hard to follow. What about this instead?
>
> unsigned int content_protection = conn_state->content_protection;
> bool content_protection_type_changed =
> conn_state->hdcp_content_type != hdcp->content_type;
>
> if (conn_state->content_protection ==
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
> content_protection_type_changed)
> intel_hdcp_disable(to_intel_connector(conn_state->connector));
>
> /* Make sure we pick up type changes */
> if (content_protection_type_changed) {
> mutex_lock(&hdcp->mutex);
> hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> schedule_work(&hdcp->prop_work);
> mutex_unlock(&hdcp->mutex);
> }
>
> if (conn_state->content_protection ==
> DRM_MODE_CONTENT_PROTECTION_DESIRED ||
> content_protection_type_changed)
> intel_hdcp_enable(to_intel_connector(conn_state->connector));
>
> Idea is to only have one disable and one enable call, and make sure the
> enable picks up our content type change no matter what.
Re: [Intel-gfx] [PATCH v3 00/11] drm/fb-helper: Move modesetting code to drm_client
On 20/04/2019 20:24, Noralf Trønnes wrote:
>
>
> Den 20.04.2019 12.45, skrev Noralf Trønnes:
>> This moves the modesetting code from drm_fb_helper to drm_client so it
>> can be shared by all internal clients.
>>
>> Changes this time:
>> - Use full drm_client_init/release for the modesets (Daniel Vetter)
>> - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter)
>> - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter)
>>
>
> I got Fi.CI.IGT failures on this one:
>
> * igt@kms_fbcon_fbt@psr:
> - shard-skl: PASS -> FAIL
>
> * igt@kms_fbcon_fbt@psr-suspend:
> - shard-iclb: PASS -> FAIL +1
> - shard-skl: NOTRUN -> FAIL
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12850/
> https://patchwork.freedesktop.org/series/58597/
>
> The previous version of this series reported success:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12720/
> But AFAICT those fbcon tests didn't succeed when I look at the details.
>
> I'd appreciate if someone with Intel CI knowledge could have a look at this.
The issue is real, but I honestly can't tell if this is due to your
patches or not. There was a regression last week and we reworked some
filters that may not apply anymore to the base that was selected to test
your patches.
I queued a re-run! We should have the results in the next 6-12 hours.
Sorry for the delay!
Martin
>
> Noralf.
>
>> Noralf.
>>
>> Noralf Trønnes (11):
>> drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
>> drm/fb-helper: Avoid race with DRM userspace
>> drm/fb-helper: No need to cache rotation and sw_rotations
>> drm/fb-helper: Remove drm_fb_helper_crtc->{x,y,desired_mode}
>> drm/fb-helper: Remove drm_fb_helper_crtc
>> drm/fb-helper: Prepare to move out commit code
>> drm/fb-helper: Move out commit code
>> drm/fb-helper: Remove drm_fb_helper_connector
>> drm/fb-helper: Prepare to move out modeset config code
>> drm/fb-helper: Move out modeset config code
>> drm/client: Hack: Add bootsplash example
>>
>> Documentation/gpu/drm-client.rst |3 +
>> Documentation/gpu/todo.rst | 10 +
>> drivers/gpu/drm/Kconfig |5 +
>> drivers/gpu/drm/Makefile |3 +-
>> drivers/gpu/drm/drm_atomic.c | 168
>> drivers/gpu/drm/drm_atomic_helper.c | 164 ---
>> drivers/gpu/drm/drm_auth.c | 20 +
>> drivers/gpu/drm/drm_bootsplash.c | 362 +++
>> drivers/gpu/drm/drm_client.c | 17 +-
>> drivers/gpu/drm/drm_client_modeset.c | 1085
>> drivers/gpu/drm/drm_crtc_internal.h |5 +
>> drivers/gpu/drm/drm_drv.c|4 +
>> drivers/gpu/drm/drm_fb_helper.c | 1381 +++---
>> drivers/gpu/drm/drm_internal.h |2 +
>> include/drm/drm_atomic_helper.h |4 -
>> include/drm/drm_client.h | 49 +
>> include/drm/drm_fb_helper.h | 102 +-
>> 17 files changed, 1864 insertions(+), 1520 deletions(-)
>> create mode 100644 drivers/gpu/drm/drm_bootsplash.c
>> create mode 100644 drivers/gpu/drm/drm_client_modeset.c
>>
> ___
> 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] ✗ Fi.CI.BAT: failure for drm/i915: adding state checker for gamma lut values (rev6)
On Thu, Apr 18, 2019 at 10:31:32AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: adding state checker for gamma lut values (rev6)
> URL : https://patchwork.freedesktop.org/series/58039/
> State : failure
Hey,
This series is a rerun, which means that someone went to patchwork web
interface and clicked on "test this series again". This should be used
only when you thing there is something seriously wrong with CI results.
If you have something that looks like a false positive (e.g. a failure
in tests that your change should not affect see below).
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5952 -> Patchwork_12827
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_12827 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_12827, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/58039/revisions/6/mbox/
This is the relevant part about false positives. Just provide some
explanation why you think this is a false positive and CC:
Martin and/or
Lakshmi
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_12827:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@runner@aborted:
> - fi-ilk-650: NOTRUN -> FAIL
> - fi-pnv-d510:NOTRUN -> FAIL
> - fi-bdw-gvtdvm: NOTRUN -> FAIL
> - fi-hsw-peppy: NOTRUN -> FAIL
> - fi-gdg-551: NOTRUN -> FAIL
> - fi-snb-2520m: NOTRUN -> FAIL
> - fi-hsw-4770:NOTRUN -> FAIL
> - fi-bxt-j4205: NOTRUN -> FAIL
> - fi-whl-u: NOTRUN -> FAIL
> - fi-icl-u3: NOTRUN -> FAIL
> - fi-ivb-3770:NOTRUN -> FAIL
> - fi-bxt-dsi: NOTRUN -> FAIL
> - fi-byt-j1900: NOTRUN -> FAIL
> - fi-icl-y: NOTRUN -> FAIL
> - fi-blb-e6850: NOTRUN -> FAIL
> - fi-bsw-kefka: NOTRUN -> FAIL
> - fi-hsw-4770r: NOTRUN -> FAIL
> - fi-byt-clapper: NOTRUN -> FAIL
> - fi-bdw-5557u: NOTRUN -> FAIL
> - fi-bwr-2160:NOTRUN -> FAIL
> - fi-elk-e7500: NOTRUN -> FAIL
This looks like a real issue though. Seems like igt_runner has aborted
execution on almost all the machines due to hitting a WARN.
Let's see the logs:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12822/fi-cfl-8700k/igt@run...@aborted.html
--
Aborting.
Previous test: nothing
Next test: core_auth (basic-auth)
Kernel badly tainted (0x200) (check dmesg for details):
(0x200) TAINT_WARN: WARN_ON has happened.
--
(You can get them through patchwork -> see full logs -> red cell in the
igt@runner@aborted row, on a machcine that has not aborted prior to that.)
This tells us that the kernel was tainted in a way that may cause
unexpeted behavior if testing would coninued (TAINT_WARN), so we abort.
Here it happned before we even run a single tests ("Previous test:
nothing"), so we have to look for the result in the boot dmesg. Link to
boot log is on top of the page with the result (boot0).
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12822/fi-cfl-8700k/boot0.log
--
<4>[3.842910] [ cut here ]
<4>[3.842911] pipe state doesn't match!
<4>[3.842952] WARNING: CPU: 3 PID: 224 at
drivers/gpu/drm/i915/intel_display.c:12700
intel_atomic_commit_tail+0x127d/0x12e0 [i915]
<4>[3.842953] Modules linked in: i915 x86_pkg_temp_thermal mei_hdcp
coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec snd_hwdep snd_hda_core
crc32_pclmul e1000e snd_pcm mei_me ghash_clmulni_intel mei ptp pps_core
prime_numbers
<4>[3.842961] CPU: 3 PID: 224 Comm: kworker/u24:7 Not tainted
5.1.0-rc5-CI-Patchwork_12822+ #1
<4>[3.842962] Hardware name: Micro-Star International Co., Ltd.
MS-7B54/Z370M MORTAR (MS-7B54), BIOS 1.00 10/31/2017
<4>[3.842964] Workqueue: events_unbound async_run_entry_fn
<4>[3.842993] RIP: 0010:intel_atomic_commit_tail+0x127d/0x12e0 [i915]
<4>[3.842995] Code: 45 0f b6 84 24 d2 07 00 00 e8 3f 36 3d e1 5e 5f e9 80
fa ff ff e8 d3 8d e2 e0 0f 0b 0f b6 0c 24 e9 42 fc ff ff e8 c3 8d e2 e0 <0f> 0b
e9 d2 f3 ff ff e8 b7 8d e2 e0 0f 0b 49 8b 44 24 50 e9 ae fc
<4>[3.842996] RSP: 0018:c90001aa7998 EFLAGS: 00010282
<4>[3.842997] RAX: RBX: 888253eb92a8 RCX:
<4>[3.842998] RDX: 0007 RSI: 88826274d9f8 RDI:
<4>[3.842998] RBP: 888255fe9158 R08: 38571494 R09:
0
Re: [Intel-gfx] [PATCH 07/32] drm/i915: Move GraphicsTechnology files under gt/
I'll want two things: * Explicit ack from Rodrigo too * The dependencies merged first, and this one posted as a single patch. I really want this to stand out better, instead of semi-hidden in the middle of a 30+ patch series. Acked-by: Jani Nikula On Tue, 23 Apr 2019, Joonas Lahtinen wrote: > Quoting Joonas Lahtinen (2019-04-18 15:04:49) >> + Jani and Rodrigo to comment > > No objection here and drm-intel-next was freshly tagged, so this is: > > Acked-by: Joonas Lahtinen > > Regards, Joonas > >> >> I'm definitely all for doing this, so it's only a matter of the timing. >> >> Question is, do we want to do it right now after last drm-intel-next was >> tagged, or do we want to wait a couple of release candidates. >> >> I'm leaning towards doing this ASAP, as git cherry-pick should >> understand that they're just renames, so there should be no issue with >> doing the -fixes. >> >> Regards, Joonas >> >> Quoting Chris Wilson (2019-04-17 10:56:32) >> > Start partitioning off the code that talks to the hardware (GT) from the >> > uapi layers and move the device facing code under gt/ >> > >> > One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to >> > subdivide that header and body further (and split out the submission >> > code from the ringbuffer and logical context handling). This patch aims >> > to be simple motion so git can fixup inflight patches with little mess. >> > >> > Signed-off-by: Chris Wilson -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/32] drm/i915: Move GraphicsTechnology files under gt/
Quoting Joonas Lahtinen (2019-04-18 15:04:49)
> + Jani and Rodrigo to comment
No objection here and drm-intel-next was freshly tagged, so this is:
Acked-by: Joonas Lahtinen
Regards, Joonas
>
> I'm definitely all for doing this, so it's only a matter of the timing.
>
> Question is, do we want to do it right now after last drm-intel-next was
> tagged, or do we want to wait a couple of release candidates.
>
> I'm leaning towards doing this ASAP, as git cherry-pick should
> understand that they're just renames, so there should be no issue with
> doing the -fixes.
>
> Regards, Joonas
>
> Quoting Chris Wilson (2019-04-17 10:56:32)
> > Start partitioning off the code that talks to the hardware (GT) from the
> > uapi layers and move the device facing code under gt/
> >
> > One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to
> > subdivide that header and body further (and split out the submission
> > code from the ringbuffer and logical context handling). This patch aims
> > to be simple motion so git can fixup inflight patches with little mess.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/Makefile | 46 ---
> > drivers/gpu/drm/i915/Makefile.header-test | 6 +--
> > drivers/gpu/drm/i915/gt/Makefile | 2 +
> > drivers/gpu/drm/i915/gt/Makefile.header-test | 16 +++
> > .../gpu/drm/i915/{ => gt}/intel_breadcrumbs.c | 0
> > drivers/gpu/drm/i915/{ => gt}/intel_context.c | 3 +-
> > drivers/gpu/drm/i915/{ => gt}/intel_context.h | 0
> > .../drm/i915/{ => gt}/intel_context_types.h | 0
> > .../{intel_ringbuffer.h => gt/intel_engine.h} | 0
> > .../gpu/drm/i915/{ => gt}/intel_engine_cs.c | 8 ++--
> > .../drm/i915/{ => gt}/intel_engine_types.h| 5 +-
> > .../drm/i915/{ => gt}/intel_gpu_commands.h| 0
> > .../gpu/drm/i915/{ => gt}/intel_hangcheck.c | 4 +-
> > drivers/gpu/drm/i915/{ => gt}/intel_lrc.c | 5 +-
> > drivers/gpu/drm/i915/{ => gt}/intel_lrc.h | 4 +-
> > drivers/gpu/drm/i915/{ => gt}/intel_lrc_reg.h | 0
> > drivers/gpu/drm/i915/{ => gt}/intel_mocs.c| 4 +-
> > drivers/gpu/drm/i915/{ => gt}/intel_mocs.h| 4 +-
> > .../i915/{i915_reset.c => gt/intel_reset.c} | 2 +-
> > .../i915/{i915_reset.h => gt/intel_reset.h} | 2 +-
> > .../gpu/drm/i915/{ => gt}/intel_ringbuffer.c | 3 +-
> > drivers/gpu/drm/i915/{ => gt}/intel_sseu.c| 0
> > drivers/gpu/drm/i915/{ => gt}/intel_sseu.h| 0
> > .../gpu/drm/i915/{ => gt}/intel_workarounds.c | 2 +-
> > .../gpu/drm/i915/{ => gt}/intel_workarounds.h | 8 +++-
> > .../i915/{ => gt}/intel_workarounds_types.h | 0
> > .../drm/i915/{selftests => gt}/mock_engine.c | 10 ++--
> > .../drm/i915/{selftests => gt}/mock_engine.h | 2 +-
> > .../selftest_engine_cs.c} | 0
> > .../selftest_hangcheck.c} | 16 +++
> > .../intel_lrc.c => gt/selftest_lrc.c} | 16 +++
> > .../selftest_workarounds.c} | 18
> > drivers/gpu/drm/i915/i915_cmd_parser.c| 3 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
> > drivers/gpu/drm/i915/i915_drv.c | 5 +-
> > drivers/gpu/drm/i915/i915_drv.h | 7 +--
> > drivers/gpu/drm/i915/i915_gem.c | 7 +--
> > drivers/gpu/drm/i915/i915_gem_context.c | 7 ++-
> > drivers/gpu/drm/i915/i915_gem_context.h | 3 +-
> > drivers/gpu/drm/i915/i915_gem_context_types.h | 3 +-
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 1 -
> > drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
> > drivers/gpu/drm/i915/i915_gpu_error.h | 3 +-
> > drivers/gpu/drm/i915/i915_perf.c | 3 +-
> > drivers/gpu/drm/i915/i915_pmu.c | 4 +-
> > drivers/gpu/drm/i915/i915_request.c | 1 -
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 2 +-
> > drivers/gpu/drm/i915/i915_trace.h | 3 +-
> > drivers/gpu/drm/i915/i915_vma.c | 3 +-
> > drivers/gpu/drm/i915/intel_device_info.h | 6 ++-
> > drivers/gpu/drm/i915/intel_display.c | 1 -
> > drivers/gpu/drm/i915/intel_guc_submission.c | 3 +-
> > drivers/gpu/drm/i915/intel_guc_submission.h | 3 +-
> > drivers/gpu/drm/i915/intel_uc.c | 2 +-
> > .../gpu/drm/i915/selftests/i915_gem_context.c | 5 +-
> > drivers/gpu/drm/i915/selftests/igt_reset.c| 3 +-
> > drivers/gpu/drm/i915/selftests/igt_spinner.h | 3 +-
> > .../gpu/drm/i915/selftests/mock_gem_device.c | 3 +-
> > drivers/gpu/drm/i915/selftests/mock_request.c | 3 +-
> > 59 files changed, 166 insertions(+), 112 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/gt/Makefile
> > create mode 100644 drivers/gpu/drm/i915/gt/Makefile.header-test
> > rename drivers/gpu/drm/i915/{ => gt}/intel_breadcrumbs.c (100%)
> > rename drivers/gpu/drm/i915/{ => gt}/intel_context.c (99%)
> > rename drivers/gpu/drm/i915/{ => gt}/intel_context.h
Re: [Intel-gfx] [PATCH] dma-buf: Remove unused sync_dump()
Quoting Daniel Vetter (2019-04-23 09:21:16) > On Fri, Apr 19, 2019 at 07:19:04PM +0100, Chris Wilson wrote: > > sync_dump() is an unused, unexported, function that adds 64k to the > > kernel image and doesn't even provide locking around the global array it > > uses. > > > > add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734) > > Function old new delta > > sync_dump198 --198 > > sync_dump_buf 65536 - -65536 > > > > Signed-off-by: Chris Wilson > > Cc: Sumit Semwal > > Cc: Gustavo Padovan [snip] > Oh dear, good riddance! > > Reviewed-by: Daniel Vetter Applied to drm-misc-next, hopefully that's the right spot! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Remove unused sync_dump()
On Fri, Apr 19, 2019 at 07:19:04PM +0100, Chris Wilson wrote:
> sync_dump() is an unused, unexported, function that adds 64k to the
> kernel image and doesn't even provide locking around the global array it
> uses.
>
> add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
> Function old new delta
> sync_dump198 --198
> sync_dump_buf 65536 - -65536
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> ---
> drivers/dma-buf/sync_debug.c | 26 --
> drivers/dma-buf/sync_debug.h | 1 -
> 2 files changed, 27 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> index c0abf37df88b..434a66518e0d 100644
> --- a/drivers/dma-buf/sync_debug.c
> +++ b/drivers/dma-buf/sync_debug.c
> @@ -197,29 +197,3 @@ static __init int sync_debugfs_init(void)
> return 0;
> }
> late_initcall(sync_debugfs_init);
> -
> -#define DUMP_CHUNK 256
> -static char sync_dump_buf[64 * 1024];
> -void sync_dump(void)
> -{
> - struct seq_file s = {
> - .buf = sync_dump_buf,
> - .size = sizeof(sync_dump_buf) - 1,
> - };
> - int i;
> -
> - sync_info_debugfs_show(&s, NULL);
> -
> - for (i = 0; i < s.count; i += DUMP_CHUNK) {
> - if ((s.count - i) > DUMP_CHUNK) {
> - char c = s.buf[i + DUMP_CHUNK];
> -
> - s.buf[i + DUMP_CHUNK] = 0;
> - pr_cont("%s", s.buf + i);
> - s.buf[i + DUMP_CHUNK] = c;
> - } else {
> - s.buf[s.count] = 0;
> - pr_cont("%s", s.buf + i);
> - }
> - }
> -}
Oh dear, good riddance!
Reviewed-by: Daniel Vetter
> diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
> index 05e33f937ad0..6176e52ba2d7 100644
> --- a/drivers/dma-buf/sync_debug.h
> +++ b/drivers/dma-buf/sync_debug.h
> @@ -68,6 +68,5 @@ void sync_timeline_debug_add(struct sync_timeline *obj);
> void sync_timeline_debug_remove(struct sync_timeline *obj);
> void sync_file_debug_add(struct sync_file *fence);
> void sync_file_debug_remove(struct sync_file *fence);
> -void sync_dump(void);
>
> #endif /* _LINUX_SYNC_H */
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
Re: [Intel-gfx] [patch V2 25/29] livepatch: Simplify stack trace retrieval
On Thu, 18 Apr 2019, Thomas Gleixner wrote: > Replace the indirection through struct stack_trace by using the storage > array based interfaces. > > Signed-off-by: Thomas Gleixner Acked-by: Miroslav Benes Feel free to take it through tip or let us know to pick it up. Miroslav ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix MG_DP_MODE() register programming
On Fri, Apr 19, 2019 at 08:55:02AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl: Fix MG_DP_MODE() register programming
> URL : https://patchwork.freedesktop.org/series/59744/
> State : success
Thanks for the reviews, pushed to -dinq adding the not to the commit
message about simplifying things.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5954_full -> Patchwork_12840_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_12840_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@audio@hdmi-integrity-after-suspend}:
> - shard-glk: TIMEOUT -> FAIL
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_12840_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_ctx_isolation@rcs0-s3:
> - shard-apl: PASS -> DMESG-WARN [fdo#108566] +3
>
> * igt@i915_pm_rpm@gem-execbuf-stress:
> - shard-skl: PASS -> INCOMPLETE [fdo#107803] / [fdo#107807]
>
> * igt@i915_pm_rpm@system-suspend:
> - shard-kbl: PASS -> INCOMPLETE [fdo#103665] / [fdo#107807]
>
> * igt@kms_busy@basic-flip-e:
> - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1
>
> * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-f:
> - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2
>
> * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic:
> - shard-glk: PASS -> FAIL [fdo#104873]
>
> * igt@kms_dp_dsc@basic-dsc-enable-edp:
> - shard-iclb: PASS -> SKIP [fdo#109349]
>
> * igt@kms_draw_crc@draw-method-rgb565-pwrite-ytiled:
> - shard-skl: NOTRUN -> FAIL [fdo#103184]
>
> * igt@kms_fbcon_fbt@fbc-suspend:
> - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +1
>
> * igt@kms_force_connector_basic@prune-stale-modes:
> - shard-apl: NOTRUN -> SKIP [fdo#109271] +19
>
> * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite:
> - shard-iclb: PASS -> FAIL [fdo#103167] +3
>
> * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render:
> - shard-snb: NOTRUN -> SKIP [fdo#109271] +117
>
> * igt@kms_lease@atomic_implicit_crtc:
> - shard-snb: NOTRUN -> FAIL [fdo#110279]
>
> * igt@kms_lease@setcrtc_implicit_plane:
> - shard-snb: NOTRUN -> FAIL [fdo#110281]
>
> * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-e:
> - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +10
>
> * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
> - shard-glk: PASS -> SKIP [fdo#109271]
>
> * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
> - shard-apl: NOTRUN -> FAIL [fdo#108145]
>
> * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
> - shard-skl: NOTRUN -> FAIL [fdo#108145] +2
>
> * igt@kms_plane_lowres@pipe-a-tiling-x:
> - shard-iclb: PASS -> FAIL [fdo#103166]
>
> * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format:
> - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278]
>
> * igt@kms_psr@psr2_cursor_mmap_cpu:
> - shard-iclb: PASS -> SKIP [fdo#109441] +2
>
> * igt@kms_vrr@flip-suspend:
> - shard-skl: NOTRUN -> SKIP [fdo#109271] +40
>
> * igt@perf_pmu@rc6:
> - shard-kbl: PASS -> SKIP [fdo#109271]
>
>
> Possible fixes
>
> * igt@gem_softpin@noreloc-s3:
> - shard-apl: DMESG-WARN [fdo#108566] -> PASS +2
>
> * igt@kms_cursor_crc@cursor-64x64-suspend:
> - shard-kbl: DMESG-WARN [fdo#108566] -> PASS
>
> * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
> - shard-iclb: FAIL [fdo#103167] -> PASS +5
>
> * igt@kms_plane@pixel-format-pipe-c-planes:
> - shard-glk: SKIP [fdo#109271] -> PASS
>
> * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
> - shard-skl: FAIL [fdo#108145] -> PASS
>
> * igt@kms_plane_scaling@pipe-c-scaler-with-rotation:
> - shard-glk: SKIP [fdo#109271] / [fdo#109278] -> PASS +1
>
> * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
> - shard-kbl: DMESG-FAIL [fdo#105763] -> PASS
>
> * igt@kms_sysfs_edid_timing:
> - shard-iclb: FAIL [fdo#100047] -> PASS
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
> [fdo#103166]: https://bugs.freedesktop.org/show_bug.c
Re: [Intel-gfx] [PATCH v5 04/12] drm/i915: Attach content type property
On Thu, Apr 18, 2019 at 02:27:57PM +0530, Ramalingam C wrote:
> Attaches the content type property for HDCP2.2 capable connectors.
>
> Implements the update of content type from property and apply the
> restriction on HDCP version selection.
>
> v2:
> s/cp_content_type/content_protection_type [daniel]
> disable at hdcp_atomic_check to avoid check at atomic_set_property
> [Maarten]
> v3:
> s/content_protection_type/hdcp_content_type [Pekka]
> v4:
> hdcp disable incase of type change is moved into commit [daniel].
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 38 ---
> drivers/gpu/drm/i915/intel_hdcp.c | 43 ---
> drivers/gpu/drm/i915/intel_hdcp.h | 2 +-
> 3 files changed, 63 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 24f9106efcc6..dd9bea840937 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3476,7 +3476,8 @@ static void intel_enable_ddi(struct intel_encoder
> *encoder,
> /* Enable hdcp if it's desired */
> if (conn_state->content_protection ==
> DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> + intel_hdcp_enable(to_intel_connector(conn_state->connector),
> + (u8)conn_state->hdcp_content_type);
> }
>
> static void intel_disable_ddi_dp(struct intel_encoder *encoder,
> @@ -3545,15 +3546,44 @@ static void intel_ddi_update_pipe(struct
> intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state)
> {
> + struct intel_connector *connector =
> + to_intel_connector(conn_state->connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + bool re_enable_hdcp = false;
> + int ret = -EINVAL;
> +
> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
>
> + /*
> + * During the HDCP encryption session if Type change is requested,
> + * disable the HDCP and reenable it with new TYPE value.
> + */
> if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> + DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> + conn_state->hdcp_content_type != hdcp->content_type) {
> + intel_hdcp_disable(to_intel_connector(conn_state->connector));
> + re_enable_hdcp = true;
> + }
> +
> + if (conn_state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_DESIRED || re_enable_hdcp)
> + ret = intel_hdcp_enable(connector,
> + (u8)conn_state->hdcp_content_type);
> else if (conn_state->content_protection ==
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> - intel_hdcp_disable(to_intel_connector(conn_state->connector));
> + intel_hdcp_disable(connector);
> +
> + /*
> + * During Type change handling re-enabling of the HDCP failed. Hence
> + * changes state as ENABLED->DESIRED.
> + */
> + if (ret && re_enable_hdcp) {
> + mutex_lock(&hdcp->mutex);
> + hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + schedule_work(&hdcp->prop_work);
> + mutex_unlock(&hdcp->mutex);
> + }
I'm unhappy with the convoluted logic here. It's correct I think but
fairly hard to follow. What about this instead?
unsigned int content_protection = conn_state->content_protection;
bool content_protection_type_changed =
conn_state->hdcp_content_type != hdcp->content_type;
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
content_protection_type_changed)
intel_hdcp_disable(to_intel_connector(conn_state->connector));
/* Make sure we pick up type changes */
if (content_protection_type_changed) {
mutex_lock(&hdcp->mutex);
hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
schedule_work(&hdcp->prop_work);
mutex_unlock(&hdcp->mutex);
}
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED ||
content_protection_type_changed)
intel_hdcp_enable(to_intel_connector(conn_state->connector));
Idea is to only have one disable and one enable call, and make sure the
enable picks up our content type change no matter what. But not sure that
it's really clearer. Thoughts?
Aside from this lgtm.
-Daniel
> }
>
> static void intel_ddi_set_fia_lane_count(struct intel_en
Re: [Intel-gfx] [PATCH v5 03/12] drm: Add Content protection type property
On Thu, Apr 18, 2019 at 02:27:56PM +0530, Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content providers.
> Type 0 content can be rendered on any HDCP protected display wires.
> But Type 1 content can be rendered only on HDCP2.2 protected paths.
>
> So when a userspace sets this property to Type 1 and starts the HDCP
> enable, kernel will honour it only if HDCP2.2 authentication is through
> for type 1. Else HDCP enable will be failed.
>
> v2:
> cp_content_type is replaced with content_protection_type [daniel]
> check at atomic_set_property is removed [Maarten]
> v3:
> %s/content_protection_type/hdcp_content_type [Pekka]
> v4:
> property is created for the first requested connector and then reused.
> [Danvet]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 53 ++-
> drivers/gpu/drm/i915/intel_hdcp.c | 4 ++-
> include/drm/drm_connector.h | 9 +-
> include/drm/drm_mode_config.h | 6
> include/uapi/drm/drm_mode.h | 4 +++
> 6 files changed, 77 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 002dcede7915..0b0747869963 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -733,6 +733,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == config->hdcp_content_type_property) {
> + state->hdcp_content_type = val;
> } else if (property == connector->colorspace_property) {
> state->colorspace = val;
> } else if (property == config->writeback_fb_id_property) {
> @@ -809,6 +811,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->scaling_mode;
> } else if (property == config->content_protection_property) {
> *val = state->content_protection;
> + } else if (property == config->hdcp_content_type_property) {
> + *val = state->hdcp_content_type;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> *val = 0;
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7c0eda9cca60..03907d13ef66 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -857,6 +857,13 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> };
>
> +static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
> + { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
> + { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
> + drm_hdcp_content_type_enum_list)
> +
> /**
> * DOC: standard connector properties
> *
> @@ -962,6 +969,23 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> * the value transitions from ENABLED to DESIRED. This signifies the link
> * is no longer protected and userspace should take appropriate action
> * (whatever that might be).
> + * HDCP Content Type:
> + * This property is used by the userspace to configure the kernel with
> + * upcoming stream's content type. Content Type of a stream is decided by
"upcoming" sounds a bit like "in a future patch", which is confusing in
documentation. Maybe "to be displayed" instead of "upcoming"?
> + * the owner of the stream, as HDCP Type0 or HDCP Type1.
> + *
> + * The value of the property can be one the below:
> + * - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> + * HDCP Type0 streams can be transmitted on a link which is
> + * encrypted with HDCP 1.4 or HDCP 2.2.
> + * - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> + * HDCP Type1 streams can be transmitted on a link which is
> + * encrypted only with HDCP 2.2.
> + *
> + * Please note this content type is introduced at HDCP 2.2 and used in its
> + * authentication process.
I'd replace this with "Note that the HDCP Content Type property is
optional, and defaults to type 0. It is only exposed by drivers supporting
HDCP 2.x." I think that makes it clearer for userspace people what this
means.
> If content type is changed when
> + * content_protection is not UNDESIRED, then kernel will disable the HDCP
> + * and re-enable with new type in the same atomic commit
> *
> * max bpc:
> * This range property is used by userspace to limit the bit depth. When
Re: [Intel-gfx] [PATCH v5 01/12] drm: move content protection property to mode_config
On Thu, Apr 18, 2019 at 02:27:54PM +0530, Ramalingam C wrote:
> Content protection property is created once and stored in
> drm_mode_config. And attached to all HDCP capable connectors.
>
> Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
> drivers/gpu/drm/drm_connector.c | 13 +++--
> include/drm/drm_connector.h | 6 --
> include/drm/drm_mode_config.h | 6 ++
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index ea797d4c82ee..002dcede7915 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -727,7 +727,7 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->content_type = val;
> } else if (property == connector->scaling_mode_property) {
> state->scaling_mode = val;
> - } else if (property == connector->content_protection_property) {
> + } else if (property == config->content_protection_property) {
> if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> return -EINVAL;
> @@ -807,7 +807,7 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->colorspace;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> - } else if (property == connector->content_protection_property) {
> + } else if (property == config->content_protection_property) {
> *val = state->content_protection;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2355124849db..7c0eda9cca60 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1534,18 +1534,19 @@ int drm_connector_attach_content_protection_property(
> struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> - struct drm_property *prop;
> + struct drm_property *prop =
> + dev->mode_config.content_protection_property;
>
> - prop = drm_property_create_enum(dev, 0, "Content Protection",
> - drm_cp_enum_list,
> - ARRAY_SIZE(drm_cp_enum_list));
> + if (!prop)
> + prop = drm_property_create_enum(dev, 0, "Content Protection",
> + drm_cp_enum_list,
> + ARRAY_SIZE(drm_cp_enum_list));
> if (!prop)
> return -ENOMEM;
>
> drm_object_attach_property(&connector->base, prop,
> DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
> -
> - connector->content_protection_property = prop;
> + dev->mode_config.content_protection_property = prop;
>
> return 0;
> }
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 02a131202add..5e41942e5679 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1061,12 +1061,6 @@ struct drm_connector {
>*/
> struct drm_property *vrr_capable_property;
>
> - /**
> - * @content_protection_property: DRM ENUM property for content
> - * protection. See drm_connector_attach_content_protection_property().
> - */
> - struct drm_property *content_protection_property;
> -
> /**
>* @colorspace_property: Connector property to set the suitable
>* colorspace supported by the sink.
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 7f60e8eb269a..5764ee3c7453 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -836,6 +836,12 @@ struct drm_mode_config {
>*/
> struct drm_property *writeback_out_fence_ptr_property;
>
> + /**
> + * @content_protection_property: DRM ENUM property for content
> + * protection. See drm_connector_attach_content_protection_property().
> + */
> + struct drm_property *content_protection_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
>
> --
> 2.19.1
>
--
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
Re: [Intel-gfx] [patch V2 16/29] drm: Simplify stacktrace handling
On Thu, Apr 18, 2019 at 10:41:35AM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> The original code in all printing functions is really wrong. It allocates a
> storage array on stack which is unused because depot_fetch_stack() does not
> store anything in it. It overwrites the entries pointer in the stack_trace
> struct so it points to the depot storage.
Thanks for cleaning this up for us!
> Signed-off-by: Thomas Gleixner
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Joonas Lahtinen
> Cc: Maarten Lankhorst
> Cc: dri-de...@lists.freedesktop.org
> Cc: David Airlie
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
Acked-by: Daniel Vetter
for merging through whatever tree is convenient for you (or tell me I
should pick it up into drm-next when the prep work landed).
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_mm.c| 22 +++---
> drivers/gpu/drm/i915/i915_vma.c | 11 ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +++--
> 3 files changed, 18 insertions(+), 36 deletions(-)
>
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -106,22 +106,19 @@
> static noinline void save_stack(struct drm_mm_node *node)
> {
> unsigned long entries[STACKDEPTH];
> - struct stack_trace trace = {
> - .entries = entries,
> - .max_entries = STACKDEPTH,
> - .skip = 1
> - };
> + unsigned int n;
>
> - save_stack_trace(&trace);
> + n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
>
> /* May be called under spinlock, so avoid sleeping */
> - node->stack = depot_save_stack(&trace, GFP_NOWAIT);
> + node->stack = stack_depot_save(entries, n, GFP_NOWAIT);
> }
>
> static void show_leaks(struct drm_mm *mm)
> {
> struct drm_mm_node *node;
> - unsigned long entries[STACKDEPTH];
> + unsigned long *entries;
> + unsigned int nr_entries;
> char *buf;
>
> buf = kmalloc(BUFSZ, GFP_KERNEL);
> @@ -129,19 +126,14 @@ static void show_leaks(struct drm_mm *mm
> return;
>
> list_for_each_entry(node, drm_mm_nodes(mm), node_list) {
> - struct stack_trace trace = {
> - .entries = entries,
> - .max_entries = STACKDEPTH
> - };
> -
> if (!node->stack) {
> DRM_ERROR("node [%08llx + %08llx]: unknown owner\n",
> node->start, node->size);
> continue;
> }
>
> - depot_fetch_stack(node->stack, &trace);
> - snprint_stack_trace(buf, BUFSZ, &trace, 0);
> + nr_entries = stack_depot_fetch(node->stack, &entries);
> + stack_trace_snprint(buf, BUFSZ, entries, nr_entries, 0);
> DRM_ERROR("node [%08llx + %08llx]: inserted at\n%s",
> node->start, node->size, buf);
> }
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -36,11 +36,8 @@
>
> static void vma_print_allocator(struct i915_vma *vma, const char *reason)
> {
> - unsigned long entries[12];
> - struct stack_trace trace = {
> - .entries = entries,
> - .max_entries = ARRAY_SIZE(entries),
> - };
> + unsigned long *entries;
> + unsigned int nr_entries;
> char buf[512];
>
> if (!vma->node.stack) {
> @@ -49,8 +46,8 @@ static void vma_print_allocator(struct i
> return;
> }
>
> - depot_fetch_stack(vma->node.stack, &trace);
> - snprint_stack_trace(buf, sizeof(buf), &trace, 0);
> + nr_entries = stack_depot_fetch(vma->node.stack, &entries);
> + stack_trace_snprint(buf, sizeof(buf), entries, nr_entries, 0);
> DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: inserted at %s\n",
>vma->node.start, vma->node.size, reason, buf);
> }
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -60,27 +60,20 @@
> static noinline depot_stack_handle_t __save_depot_stack(void)
> {
> unsigned long entries[STACKDEPTH];
> - struct stack_trace trace = {
> - .entries = entries,
> - .max_entries = ARRAY_SIZE(entries),
> - .skip = 1,
> - };
> + unsigned int n;
>
> - save_stack_trace(&trace);
> - return depot_save_stack(&trace, GFP_NOWAIT | __GFP_NOWARN);
> + n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
> + return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
> }
>
> static void __print_depot_stack(depot_stack_handle_t stack,
> char *buf, int sz, int indent)
> {
> - unsigned long entries[STACKDEPTH];
> - struct stack_trace trace = {
> - .entries = entries,
> - .max_entries = ARRAY_SIZE(entries),
> -
Re: [Intel-gfx] [PATCH] drm: Fire off KMS hotplug events if probe detect says the connector is connected
On Thu, Apr 18, 2019 at 01:15:17PM +, Mun, Gwan-gyeong wrote: > On Thu, 2019-04-18 at 10:28 +0200, Daniel Vetter wrote: > > On Thu, Apr 18, 2019 at 11:09:29AM +0300, Gwan-gyeong Mun wrote: > > > The hotplug detection routine of drm_helper_hpd_irq_event() can > > > detect > > > changing of status of connector, but it can not detect changing of > > > properties of the connector. > > > e.g. changing of edid while suspend/resume, changing of dp lanes in > > > dp aux. > > > > > > Following scenario explains one of them; A detection of changing of > > > edid. > > > > > > 1) plug display device to a connector > > > 2) system suspend > > > 3) unplug 1)'s display device and plug the other display device to > > > a > > > connector > > > 4) system resume > > > > > > To solve explained cases, It fires off KMS hotplug events if > > > drm_helper_probe_detect() says the connector is connected. > > > > > > Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate > > > Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend > > > Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate > > > Testcase: igt/kms_chamelium/dp-edid-change-during-suspend > > > > > > Suggested-by: Daniel Vetter > > > > This isn't at all what I suggested. > > -Daniel > Because the code modification was followed by your comments, so I added > suggested-by line. I will remove this line and will resend it. Apologies for not being clear: I don't think this here is what we want really, and it's not what I suggested. I'm not exactly sure why you think this will work, essentially it just always generates a hotplug uevent for irq, but totally ignores polling. I guess it works, but that's a hack, not something we should merge. -Daniel > Br, > G.G. > > > > > Signed-off-by: Gwan-gyeong Mun > > > Link: > > > https://lists.freedesktop.org/archives/dri-devel/2019-April/214572.html > > > --- > > > drivers/gpu/drm/drm_probe_helper.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c > > > b/drivers/gpu/drm/drm_probe_helper.c > > > index 6fd08e04b323..081a849104f2 100644 > > > --- a/drivers/gpu/drm/drm_probe_helper.c > > > +++ b/drivers/gpu/drm/drm_probe_helper.c > > > @@ -780,7 +780,8 @@ bool drm_helper_hpd_irq_event(struct drm_device > > > *dev) > > > connector->name, > > > drm_get_connector_status_name(old_status) > > > , > > > drm_get_connector_status_name(connector- > > > >status)); > > > - if (old_status != connector->status) > > > + if (old_status != connector->status || > > > + connector->status == connector_status_connected) > > > changed = true; > > > } > > > drm_connector_list_iter_end(&conn_iter); > > > -- > > > 2.21.0 > > > -- 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
