Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual
On 26/05/2020 10:07, Chris Wilson wrote: When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon the virtual engine, but along the physical engine in use, will then see that it is due to be submitted to the same engine and take a shortcut (and be queued without waiting for the completion fence). However, the virtual request may be preempted (either by higher priority users, or by timeslicing) and removed from the physical engine to be migrated over to one of its siblings. The dependent normal request however is oblivious to the removal of the virtual request and remains queued to execute on HW, believing that once it reaches the head of its queue all of its predecessors will have completed executing! v2: Beware restriction of signal->execution_mask prior to submission. Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Testcase: igt/gem_exec_balancer/sliced Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: # v5.3+ --- drivers/gpu/drm/i915/i915_request.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 33bbad623e02..0b07ccc7e9bc 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq, return 0; } +static int +await_request_submit(struct i915_request *to, struct i915_request *from) +{ + /* +* If we are waiting on a virtual engine, then it may be +* constrained to execute on a single engine *prior* to submission. +* When it is submitted, it will be first submitted to the virtual +* engine and then passed to the physical engine. We cannot allow +* the waiter to be submitted immediately to the physical engine +* as it may then bypass the virtual request. +*/ + if (to->engine == READ_ONCE(from->engine)) + return i915_sw_fence_await_sw_fence_gfp(&to->submit, + &from->submit, + I915_FENCE_GFP); + else + return __i915_request_await_execution(to, from, NULL); If I am following correctly this branch will be the virtual <-> physical or virtual <-> virtual dependency on the same physical engine. Why is await_execution sufficient in this case? Is there something preventing timeslicing between the two (not wanted right!) once from start execution (not finishes). Regards, Tvrtko +} + static int i915_request_await_request(struct i915_request *to, struct i915_request *from) { @@ -1258,10 +1277,8 @@ i915_request_await_request(struct i915_request *to, struct i915_request *from) return ret; } - if (to->engine == READ_ONCE(from->engine)) - ret = i915_sw_fence_await_sw_fence_gfp(&to->submit, - &from->submit, - I915_FENCE_GFP); + if (is_power_of_2(to->execution_mask | READ_ONCE(from->execution_mask))) + ret = await_request_submit(to, from); else ret = emit_semaphore_wait(to, from, I915_FENCE_GFP); if (ret < 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915/rkl: Disable PSR2
== Series Details == Series: series starting with [1/6] drm/i915/rkl: Disable PSR2 URL : https://patchwork.freedesktop.org/series/77676/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8540_full -> Patchwork_17781_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17781_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17781_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_17781_full: ### IGT changes ### Possible regressions * igt@gem_workarounds@suspend-resume-fd: - shard-apl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-apl4/igt@gem_workarou...@suspend-resume-fd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-apl1/igt@gem_workarou...@suspend-resume-fd.html * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-hsw1/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17781_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@render: - shard-skl: [PASS][4] -> [FAIL][5] ([i915#1528]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-skl9/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-apl1/igt@i915_susp...@sysfs-reader.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#1119] / [i915#118] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-glk5/igt@kms_big...@linear-64bpp-rotate-180.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#54] / [i915#93] / [i915#95]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#72]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle: - shard-glk: [PASS][16] -> [DMESG-WARN][17] ([i915#1926] / [i915#1927]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-glk7/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-glk9/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][18] -> [FAIL][19] ([fdo#108145] / [i915#265]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_prop_blob@blob-prop-lifetime: - shard-hsw: [PASS][20] -> [DMESG-WARN][21] ([i915#1927]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-hsw7/igt@kms_prop_b...@blob-prop-lifetime.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-hsw1/igt@kms_prop_b...@blob-prop-lifetime.html * igt@kms_psr@no_drrs: - shard-i
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/rkl: Disable PSR2
== Series Details == Series: series starting with [1/6] drm/i915/rkl: Disable PSR2 URL : https://patchwork.freedesktop.org/series/77676/ State : success == Summary == CI Bug Log - changes from CI_DRM_8540 -> Patchwork_17781 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/index.html Known issues Here are the changes found in Patchwork_17781 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [FAIL][1] ([i915#262]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 Participating hosts (51 -> 45) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8540 -> Patchwork_17781 CI-20190529: 20190529 CI_DRM_8540: b02ab97d6794973472bfdf91b62448d9354fd698 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5679: 93639b4e52140826c24da21865e912a280f9aefb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17781: d80c35b307494430f7e33f71733ea99e5dc42673 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d80c35b30749 drm/i915: Implement PSR2 selective fetch WAs 8dcb0cb37119 drm/i915: Implement PSR2 selective fetch 837cb19aab8f drm/i915: Add PSR2 software tracking registers af8c4264fa17 drm/i915: Reorder intel_psr2_config_valid() 54e02163a7f7 drm/i915: Add plane damage clips property 3b5607178b4a drm/i915/rkl: Disable PSR2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915/rkl: Disable PSR2
== Series Details == Series: series starting with [1/6] drm/i915/rkl: Disable PSR2 URL : https://patchwork.freedesktop.org/series/77676/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3b5607178b4a drm/i915/rkl: Disable PSR2 54e02163a7f7 drm/i915: Add plane damage clips property af8c4264fa17 drm/i915: Reorder intel_psr2_config_valid() 837cb19aab8f drm/i915: Add PSR2 software tracking registers -:29: WARNING:LONG_LINE: line over 100 characters #29: FILE: drivers/gpu/drm/i915/i915_reg.h:4574: +#define PSR2_MAN_TRK_CTL_REGION_START_ADDR(val) REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK, val) -:31: WARNING:LONG_LINE: line over 100 characters #31: FILE: drivers/gpu/drm/i915/i915_reg.h:4576: +#define PSR2_MAN_TRK_CTL_REGION_END_ADDR(val) REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK, val) -:63: WARNING:LONG_LINE: line over 100 characters #63: FILE: drivers/gpu/drm/i915/i915_reg.h:7163: +#define _PLANE_SEL_FETCH_BASE_1(pipe) _PIPE(pipe, _PLANE_SEL_FETCH_BASE_1_A, _PLANE_SEL_FETCH_BASE_1_A) total: 0 errors, 3 warnings, 0 checks, 87 lines checked 8dcb0cb37119 drm/i915: Implement PSR2 selective fetch -:565: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #565: FILE: drivers/gpu/drm/i915/i915_params.c:92: +i915_param_named_unsafe(enable_psr2_sel_fetch, int, 0400, + "Enable PSR2 selective fetch " total: 0 errors, 0 warnings, 1 checks, 488 lines checked d80c35b30749 drm/i915: Implement PSR2 selective fetch WAs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915/rkl: Disable PSR2
RKL doesn't have PSR2 HW tracking, it was replaced by software/manual tracking. The driver is required to track the areas that needs update and program hardware to send selective updates. So until the software tracking is implemented, PSR2 needs to be disabled for platforms without PSR2 HW tracking. This is part of RKL enabling patches, just cherry-picking here as it is needed. BSpec: 50422 BSpec: 50424 Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi Signed-off-by: José Roberto de Souza Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/display/intel_psr.c | 15 +++ drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_pci.c | 2 ++ drivers/gpu/drm/i915/intel_device_info.h | 1 + 4 files changed, 20 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index b7a2c102648a..714c590b39f5 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -646,6 +646,21 @@ static bool intel_psr2_config_valid(struct intel_dp *intel_dp, return false; } + /* +* Some platforms lack PSR2 HW tracking and instead require manual +* tracking by software. In this case, the driver is required to track +* the areas that need updates and program hardware to send selective +* updates. +* +* So until the software tracking is implemented, PSR2 needs to be +* disabled for platforms without PSR2 HW tracking. +*/ + if (!HAS_PSR_HW_TRACKING(dev_priv)) { + drm_dbg_kms(&dev_priv->drm, + "No PSR2 HW tracking in the platform\n"); + return false; + } + /* * DSC and PSR2 cannot be enabled simultaneously. If a requested * resolution requires DSC to be enabled, priority is given to DSC diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 98f2c448cd92..146bfd276ce7 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1632,6 +1632,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi) #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg) #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr) +#define HAS_PSR_HW_TRACKING(dev_priv) \ + (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking) #define HAS_TRANSCODER(dev_priv, trans) ((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0) #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)->has_rc6) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 7e3252fbad8e..709e857a3983 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -536,6 +536,7 @@ static const struct intel_device_info vlv_info = { .display.has_ddi = 1, \ .has_fpga_dbg = 1, \ .display.has_psr = 1, \ + .display.has_psr_hw_tracking = 1, \ .display.has_dp_mst = 1, \ .has_rc6p = 0 /* RC6p removed-by HSW */, \ HSW_PIPE_OFFSETS, \ @@ -690,6 +691,7 @@ static const struct intel_device_info skl_gt4_info = { .display.has_fbc = 1, \ .display.has_hdcp = 1, \ .display.has_psr = 1, \ + .display.has_psr_hw_tracking = 1, \ .has_runtime_pm = 1, \ .display.has_csr = 1, \ .has_rc6 = 1, \ diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index c912acd06109..1ada48ef517c 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -147,6 +147,7 @@ enum intel_ppgtt_type { func(has_modular_fia); \ func(has_overlay); \ func(has_psr); \ + func(has_psr_hw_tracking); \ func(overlay_needs_physical); \ func(supports_tv); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: Reorder intel_psr2_config_valid()
Future patches will bring PSR2 selective fetch configuration validation but most of the configuration checks will be used for HW tracking and selective fetch so the reoder was necessary. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 50 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 714c590b39f5..0c86e9e341a2 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -646,21 +646,6 @@ static bool intel_psr2_config_valid(struct intel_dp *intel_dp, return false; } - /* -* Some platforms lack PSR2 HW tracking and instead require manual -* tracking by software. In this case, the driver is required to track -* the areas that need updates and program hardware to send selective -* updates. -* -* So until the software tracking is implemented, PSR2 needs to be -* disabled for platforms without PSR2 HW tracking. -*/ - if (!HAS_PSR_HW_TRACKING(dev_priv)) { - drm_dbg_kms(&dev_priv->drm, - "No PSR2 HW tracking in the platform\n"); - return false; - } - /* * DSC and PSR2 cannot be enabled simultaneously. If a requested * resolution requires DSC to be enabled, priority is given to DSC @@ -672,6 +657,12 @@ static bool intel_psr2_config_valid(struct intel_dp *intel_dp, return false; } + if (crtc_state->crc_enabled) { + drm_dbg_kms(&dev_priv->drm, + "PSR2 not enabled because it would inhibit pipe CRC calculation\n"); + return false; + } + if (INTEL_GEN(dev_priv) >= 12) { psr_max_h = 5120; psr_max_v = 3200; @@ -686,14 +677,6 @@ static bool intel_psr2_config_valid(struct intel_dp *intel_dp, max_bpp = 24; } - if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) { - drm_dbg_kms(&dev_priv->drm, - "PSR2 not enabled, resolution %dx%d > max supported %dx%d\n", - crtc_hdisplay, crtc_vdisplay, - psr_max_h, psr_max_v); - return false; - } - if (crtc_state->pipe_bpp > max_bpp) { drm_dbg_kms(&dev_priv->drm, "PSR2 not enabled, pipe bpp %d > max supported %d\n", @@ -714,9 +697,26 @@ static bool intel_psr2_config_valid(struct intel_dp *intel_dp, return false; } - if (crtc_state->crc_enabled) { + /* +* Some platforms lack PSR2 HW tracking and instead require manual +* tracking by software. In this case, the driver is required to track +* the areas that need updates and program hardware to send selective +* updates. +* +* So until the software tracking is implemented, PSR2 needs to be +* disabled for platforms without PSR2 HW tracking. +*/ + if (!HAS_PSR_HW_TRACKING(dev_priv)) { drm_dbg_kms(&dev_priv->drm, - "PSR2 not enabled because it would inhibit pipe CRC calculation\n"); + "No PSR2 HW tracking in the platform\n"); + return false; + } + + if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) { + drm_dbg_kms(&dev_priv->drm, + "PSR2 not enabled, resolution %dx%d > max supported %dx%d\n", + crtc_hdisplay, crtc_vdisplay, + psr_max_h, psr_max_v); return false; } -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Implement PSR2 selective fetch WAs
This feature have 3 WAs and as commented WA 14010103792 and WA 14010254185 conflicts, so leaving the feature disabled in the affected steppings. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 30 ++-- drivers/gpu/drm/i915/i915_reg.h | 1 + 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index bc2a2e64fe2a..c138ab69fa93 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -518,13 +518,21 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp) else val |= EDP_PSR2_TP2_TIME_2500us; - if (dev_priv->psr.psr2_sel_fetch_enabled) + if (dev_priv->psr.psr2_sel_fetch_enabled) { + /* WA 1408330847 */ + if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) || + IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)) + intel_de_rmw(dev_priv, CHICKEN_PAR1_1, +DIS_RAM_BYPASS_PSR2_MAN_TRACK, +DIS_RAM_BYPASS_PSR2_MAN_TRACK); + intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(dev_priv->psr.transcoder), PSR2_MAN_TRK_CTL_ENABLE); - else if (HAS_PSR2_SEL_FETCH(dev_priv)) + } else if (HAS_PSR2_SEL_FETCH(dev_priv)) { intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(dev_priv->psr.transcoder), 0); + } /* * PSR2 HW is incorrectly using EDP_PSR_TP1_TP3_SEL and BSpec is @@ -651,6 +659,17 @@ static bool intel_psr2_sel_fetch_config_valid(struct intel_dp *intel_dp, return false; } + /* +* As WA 14010103792 conflicts with WA 14010254185 so disabling PSR2 SW +* tracking in TGL and RKL A0 +*/ + if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) || + IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)) { + drm_dbg_kms(&dev_priv->drm, + "PSR2 sel fetch not enabled, feature not working in current stepping\n"); + return false; + } + if (crtc_state->uapi.async_flip) { drm_dbg_kms(&dev_priv->drm, "PSR2 sel fetch not enabled, async flip enabled\n"); @@ -1063,6 +1082,13 @@ static void intel_psr_disable_locked(struct intel_dp *intel_dp) psr_status_mask, 2000)) drm_err(&dev_priv->drm, "Timed out waiting PSR idle state\n"); + /* WA 1408330847 */ + if (dev_priv->psr.psr2_sel_fetch_enabled && + (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) || +IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))) + intel_de_rmw(dev_priv, CHICKEN_PAR1_1, +DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0); + /* Disable PSR on Sink */ drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0); diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 6f547e459d30..2e374e166b2e 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -7833,6 +7833,7 @@ enum { # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2) #define CHICKEN_PAR1_1 _MMIO(0x42080) +#define DIS_RAM_BYPASS_PSR2_MAN_TRACK (1 << 16) #define SKL_DE_COMPRESSED_HASH_MODE (1 << 15) #define DPA_MASK_VBLANK_SRD (1 << 15) #define FORCE_ARB_IDLE_PLANES (1 << 14) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Add PSR2 software tracking registers
This registers will be used to implement PSR2 software tracking. BSpec: 55229 BSpec: 50424 BSpec: 50420 Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_reg.h | 68 ++--- 1 file changed, 63 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e9d50fe0f375..6f547e459d30 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4566,6 +4566,18 @@ enum { #define PSR2_SU_STATUS_MASK(frame) (0x3ff << PSR2_SU_STATUS_SHIFT(frame)) #define PSR2_SU_STATUS_FRAMES 8 +#define _PSR2_MAN_TRK_CTL_A0x60910 +#define _PSR2_MAN_TRK_CTL_EDP 0x6f910 +#define PSR2_MAN_TRK_CTL(tran) _MMIO_TRANS2(tran, _PSR2_MAN_TRK_CTL_A) +#define PSR2_MAN_TRK_CTL_ENABLE REG_BIT(31) +#define PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK REG_GENMASK(30, 21) +#define PSR2_MAN_TRK_CTL_REGION_START_ADDR(val) REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK, val) +#define PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK REG_GENMASK(20, 11) +#define PSR2_MAN_TRK_CTL_REGION_END_ADDR(val) REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK, val) +#define PSR2_MAN_TRK_CTL_SINGLE_FULL_FRAMEREG_BIT(3) +#define PSR2_MAN_TRK_CTL_CONTINUOS_FULL_FRAME REG_BIT(2) +#define PSR2_MAN_TRK_CTL_PARTIAL_FRAME_UPDATE REG_BIT(1) + /* VGA port control */ #define ADPA _MMIO(0x61100) #define PCH_ADPA_MMIO(0xe1100) @@ -7129,7 +7141,52 @@ enum { #define PLANE_COLOR_CTL(pipe, plane) \ _MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe), _PLANE_COLOR_CTL_2(pipe)) -#/* SKL new cursor registers */ +#define _PLANE_SEL_FETCH_BASE_1_A 0x70890 +#define _PLANE_SEL_FETCH_BASE_2_A 0x708B0 +#define _PLANE_SEL_FETCH_BASE_3_A 0x708D0 +#define _PLANE_SEL_FETCH_BASE_4_A 0x708F0 +#define _PLANE_SEL_FETCH_BASE_5_A 0x70920 +#define _PLANE_SEL_FETCH_BASE_6_A 0x70940 +#define _PLANE_SEL_FETCH_BASE_7_A 0x70960 +#define _PLANE_SEL_FETCH_BASE_CUR_A0x70880 +#define _PLANE_SEL_FETCH_BASE_1_B 0x70990 + +#define _PLANE_SEL_FETCH_BASE_A(plane) _PICK(plane, \ +_PLANE_SEL_FETCH_BASE_1_A, \ +_PLANE_SEL_FETCH_BASE_2_A, \ +_PLANE_SEL_FETCH_BASE_3_A, \ +_PLANE_SEL_FETCH_BASE_4_A, \ +_PLANE_SEL_FETCH_BASE_5_A, \ +_PLANE_SEL_FETCH_BASE_6_A, \ +_PLANE_SEL_FETCH_BASE_7_A, \ +_PLANE_SEL_FETCH_BASE_CUR_A) +#define _PLANE_SEL_FETCH_BASE_1(pipe) _PIPE(pipe, _PLANE_SEL_FETCH_BASE_1_A, _PLANE_SEL_FETCH_BASE_1_A) +#define PLANE_SEL_FETCH_BASE(pipe, plane) (_PLANE_SEL_FETCH_BASE_1(pipe) - \ + _PLANE_SEL_FETCH_BASE_1_A + \ + _PLANE_SEL_FETCH_BASE_A(plane)) + +#define _PLANE_SEL_FETCH_CTL_1_A 0x70890 +#define PLANE_SEL_FETCH_CTL(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, plane) + \ + _PLANE_SEL_FETCH_CTL_1_A - \ + _PLANE_SEL_FETCH_BASE_1_A) +#define PLANE_SET_FETCH_CTL_ENABLE REG_BIT(31) + +#define _PLANE_SEL_FETCH_POS_1_A 0x70894 +#define PLANE_SEL_FETCH_POS(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, plane) + \ + _PLANE_SEL_FETCH_POS_1_A - \ + _PLANE_SEL_FETCH_BASE_1_A) + +#define _PLANE_SEL_FETCH_SIZE_1_A 0x70898 +#define PLANE_SEL_FETCH_SIZE(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, plane) + \ + _PLANE_SEL_FETCH_SIZE_1_A - \ + _PLANE_SEL_FETCH_BASE_1_A) + +#define _PLANE_SEL_FETCH_OFFSET_1_A0x7089C +#define PLANE_SEL_FETCH_OFFSET(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, plane) + \ + _PLANE_SEL_FETCH_OFFSET_1_A - \ + _PLANE_SEL_FETCH_BASE_1_A) + +/* SKL new cursor registers */ #define _CUR_BUF_CFG_A 0x7017c #define _CUR_BUF_CFG_B 0x7117c #define CUR_BUF_CFG(pipe) _MMIO_PIPE(pipe, _CUR_BUF_CFG_A, _CUR_BUF_CFG_B) @@ -7775,11 +7832,12 @@ enum { # define CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE (1 << 5) # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2) -#define CHICKEN_PAR1_1 _MMIO(0x42080) +#define CHICKEN_PAR1_1
[Intel-gfx] [PATCH 5/6] drm/i915: Implement PSR2 selective fetch
All GEN12 platforms supports PSR2 selective fetch but not all GEN12 platforms supports PSR2 hardware tracking(aka RKL). This feature consists in software program registers with the damaged area of each plane this way hardware will only fetch from memory those areas and sent the PSR2 selective update blocks to panel, saving even more power but to it actually happen userspace needs to send the damaged areas otherwise it will still fetch the whole plane as fallback. As today Gnome3 do not send damaged areas and the only compositor that I'm aware that sets the damaged areas is Weston. https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/17 So here implementing page flip part, it is still completely missing frontbuffer modifications, that is why the enable_psr2_sel_fetch parameter was added. The plan is to switch all GEN12 platforms to selective fetch when ready, it will also depend in add some tests sending damaged areas. I have a hacked version of kms_psr2_su with 3 planes that I can cleanup and send in a few days(99% of PSR2 selective fetch changes was done during my free time while bored during quarantine rainy days). BSpec: 55229 Cc: Ville Syrjälä Cc: Imre Deak Cc: Gwan-gyeong Mun Cc: Rodrigo Vivi Cc: Dhinakaran Pandiyan Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display.c | 5 + .../drm/i915/display/intel_display_debugfs.c | 3 + .../drm/i915/display/intel_display_types.h| 10 + drivers/gpu/drm/i915/display/intel_psr.c | 329 +- drivers/gpu/drm/i915/display/intel_psr.h | 10 + drivers/gpu/drm/i915/display/intel_sprite.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_params.c| 5 + drivers/gpu/drm/i915/i915_params.h| 1 + 9 files changed, 352 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index b69878334040..984809208c29 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -11729,6 +11729,8 @@ static void i9xx_update_cursor(struct intel_plane *plane, if (INTEL_GEN(dev_priv) >= 9) skl_write_cursor_wm(plane, crtc_state); + intel_psr2_program_plane_sel_fetch(plane, crtc_state, plane_state); + if (plane->cursor.base != base || plane->cursor.size != fbc_ctl || plane->cursor.cntl != cntl) { @@ -15115,6 +15117,8 @@ static void commit_pipe_config(struct intel_atomic_state *state, if (new_crtc_state->update_pipe) intel_pipe_fastset(old_crtc_state, new_crtc_state); + + intel_psr2_program_trans_man_trk_ctl(new_crtc_state); } if (dev_priv->display.atomic_update_watermarks) @@ -15156,6 +15160,7 @@ static void intel_update_crtc(struct intel_atomic_state *state, intel_color_load_luts(new_crtc_state); intel_pre_plane_update(state, crtc); + intel_psr2_sel_fetch_update(state, crtc); if (new_crtc_state->update_pipe) intel_encoders_update_pipe(state, crtc); diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index 70525623bcdf..0f600974462b 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -417,6 +417,9 @@ static int i915_edp_psr_status(struct seq_file *m, void *data) su_blocks = su_blocks >> PSR2_SU_STATUS_SHIFT(frame); seq_printf(m, "%d\t%d\n", frame, su_blocks); } + + seq_printf(m, "PSR2 selective fetch: %s\n", + enableddisabled(psr->psr2_sel_fetch_enabled)); } unlock: diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index 30b2767578dc..b77a512e5362 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -586,6 +586,13 @@ struct intel_plane_state { u32 planar_slave; struct drm_intel_sprite_colorkey ckey; + + struct { + u32 ctl; + u32 pos; + u32 offset; + u32 size; + } psr2_sel_fetch; }; struct intel_initial_plane_config { @@ -931,6 +938,7 @@ struct intel_crtc_state { bool has_psr; bool has_psr2; + bool enable_psr2_sel_fetch; u32 dc3co_exitline; /* @@ -1070,6 +1078,8 @@ struct intel_crtc_state { /* For DSB related info */ struct intel_dsb *dsb; + + u32 psr2_sw_man_track_ctl; }; enum intel_pipe_crc_source { diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 0c86e9e341a2..bc2a2e64f
[Intel-gfx] [PATCH 2/6] drm/i915: Add plane damage clips property
This property will be used by PSR2 software tracking, adding it to GEN12+. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display.c | 4 drivers/gpu/drm/i915/display/intel_sprite.c | 4 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index f40b909952cc..b69878334040 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -16476,6 +16477,9 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv, zpos = RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1; drm_plane_create_zpos_immutable_property(&cursor->base, zpos); + if (INTEL_GEN(dev_priv) >= 12) + drm_plane_enable_fb_damage_clips(&cursor->base); + drm_plane_helper_add(&cursor->base, &intel_plane_helper_funcs); return cursor; diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index 571c36f929bd..8be06cb25999 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include @@ -3151,6 +3152,9 @@ skl_universal_plane_create(struct drm_i915_private *dev_priv, drm_plane_create_zpos_immutable_property(&plane->base, plane_id); + if (INTEL_GEN(dev_priv) >= 12) + drm_plane_enable_fb_damage_clips(&plane->base); + drm_plane_helper_add(&plane->base, &intel_plane_helper_funcs); return plane; -- 2.26.2 ___ 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/gt: Clear LOCAL_BIND from shared GGTT on resume
== Series Details == Series: drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume URL : https://patchwork.freedesktop.org/series/77666/ State : success == Summary == CI Bug Log - changes from CI_DRM_8539_full -> Patchwork_17779_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17779_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-apl6/igt@gem_soft...@noreloc-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-apl6/igt@gem_soft...@noreloc-s3.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-snb: [PASS][3] -> [INCOMPLETE][4] ([i915#82]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-128x42-offscreen: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#54]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#300]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([i915#61]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-hsw6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-hsw1/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: - shard-hsw: [PASS][11] -> [SKIP][12] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-hsw4/igt@kms_cursor_leg...@cursorb-vs-flipb-toggle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-hsw6/igt@kms_cursor_leg...@cursorb-vs-flipb-toggle.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][13] -> [FAIL][14] ([IGT#5]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_no_drrs: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-iclb2/igt@kms_psr@psr2_no_drrs.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-iclb6/igt@kms_psr@psr2_no_drrs.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-kbl2/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-kbl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html Possible fixes * {igt@gem_ctx_isolation@preservation-s3@rcs0}: - shard-skl: [INCOMPLETE][21] ([i915#198]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl2/igt@gem_ctx_isolation@preservation...@rcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl10/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-skl: [INCOMPLETE][23] ([i915#69]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl3/igt@i915_susp...@fence-restore-tiled2untiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl10/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-glk: [FAIL][25]
[Intel-gfx] [PATCH 0/2] drm/probe_helper, i915: Validate MST modes against PBN limits
Something we've been missing for a while with drivers that support MST is being able to prune modes that can't be set due to bandwidth limitations. So, let's go ahead and add that. This also adds a new hook that was needed, mode_valid_ctx, so that we can grab additional locks as needed when validating modes. Lee Shawn C (1): drm/i915/mst: filter out the display mode exceed sink's capability Lyude Paul (1): drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx drivers/gpu/drm/drm_crtc_helper_internal.h | 6 +- drivers/gpu/drm/drm_probe_helper.c | 65 ++--- drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 +++-- include/drm/drm_modeset_helper_vtables.h| 41 + 4 files changed, 123 insertions(+), 28 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/mst: filter out the display mode exceed sink's capability
From: Lee Shawn C So far, max dot clock rate for MST mode rely on physcial bandwidth limitation. It would caused compatibility issue if source display resolution exceed MST hub output ability. For example, source DUT had DP 1.2 output capability. And MST docking just support HDMI 1.4 spec. When a HDMI 2.0 monitor connected. Source would retrieve EDID from external and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps because it did not surpass DP physical bandwidth limitation. Do modeset to 4k@60fps, source output display data but MST docking can't output HDMI properly due to this resolution already over HDMI 1.4 spec. Refer to commit ("drm/dp_mst: Use full_pbn instead of available_pbn for bandwidth checks"). Source driver should refer to full_pbn to evaluate sink output capability. And filter out the resolution surpass sink output limitation. v2: Using mgr->base.lock to protect full_pbn. v3: Add ctx lock. v4: * s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/ intel_dp_mst_mode_clock_exceeds_pbn_bw/ * Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe down the drm_modeset_acquire_ctx that the probe helpers are using, so we can safely grab &mgr->base.lock without deadlocking Cc: Manasi Navare Cc: Jani Nikula Cc: Ville Syrjala Cc: Cooper Chiou Co-developed-by: Lyude Paul Signed-off-by: Lee Shawn C Tested-by: Lee Shawn C Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 ++--- 1 file changed, 35 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c index d18b406f2a7d2..cf052095ad785 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -610,15 +610,42 @@ static int intel_dp_mst_get_modes(struct drm_connector *connector) return intel_dp_mst_get_ddc_modes(connector); } +static int +intel_dp_mst_mode_clock_exceeds_pbn_bw(struct drm_connector *connector, + struct drm_modeset_acquire_ctx *ctx, + int clock, int bpp) +{ + struct intel_connector *intel_connector = to_intel_connector(connector); + struct intel_dp *intel_dp = intel_connector->mst_port; + struct drm_dp_mst_topology_mgr *mgr = &intel_dp->mst_mgr; + struct drm_dp_mst_port *port = (to_intel_connector(connector))->port; + int ret = MODE_OK; + + if (!mgr) + return ret; + + ret = drm_modeset_lock(&mgr->base.lock, ctx); + if (ret == -EDEADLK) + return ret; + + if (port->full_pbn && + drm_dp_calc_pbn_mode(clock, bpp, false) > port->full_pbn) + ret = MODE_CLOCK_HIGH; + + return ret; +} + static enum drm_mode_status -intel_dp_mst_mode_valid(struct drm_connector *connector, - struct drm_display_mode *mode) +intel_dp_mst_mode_valid_ctx(struct drm_connector *connector, + struct drm_display_mode *mode, + struct drm_modeset_acquire_ctx *ctx) { struct drm_i915_private *dev_priv = to_i915(connector->dev); struct intel_connector *intel_connector = to_intel_connector(connector); struct intel_dp *intel_dp = intel_connector->mst_port; int max_dotclk = to_i915(connector->dev)->max_dotclk_freq; int max_rate, mode_rate, max_lanes, max_link_clock; + int ret; if (drm_connector_is_unregistered(connector)) return MODE_ERROR; @@ -632,7 +659,11 @@ intel_dp_mst_mode_valid(struct drm_connector *connector, max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes); mode_rate = intel_dp_link_required(mode->clock, 18); - /* TODO - validate mode against available PBN for link */ + ret = intel_dp_mst_mode_clock_exceeds_pbn_bw(connector, ctx, +mode->clock, 24); + if (ret != MODE_OK) + return ret; + if (mode->clock < 1) return MODE_CLOCK_LOW; @@ -671,7 +702,7 @@ intel_dp_mst_detect(struct drm_connector *connector, static const struct drm_connector_helper_funcs intel_dp_mst_connector_helper_funcs = { .get_modes = intel_dp_mst_get_modes, - .mode_valid = intel_dp_mst_mode_valid, + .mode_valid_ctx = intel_dp_mst_mode_valid_ctx, .atomic_best_encoder = intel_mst_atomic_best_encoder, .atomic_check = intel_dp_mst_atomic_check, .detect_ctx = intel_dp_mst_detect, -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/37] drm/i915: Add has_master_unit_irq flag
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: > From: Stuart Summers > > Add flag to differentiate platforms with and without the master > IRQ control bit. Reviewed-by: José Roberto de Souza > > Signed-off-by: Stuart Summers > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_device_info.h | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index bed12799495b..162b1ead88d3 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1580,6 +1580,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \ > (INTEL_INFO(dev_priv)->has_logical_ring_preemption) > > +#define HAS_MASTER_UNIT_IRQ(dev_priv) > (INTEL_INFO(dev_priv)->has_master_unit_irq) > + > #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv) > > #define INTEL_PPGTT(dev_priv) (INTEL_INFO(dev_priv)->ppgtt_type) > diff --git a/drivers/gpu/drm/i915/intel_device_info.h > b/drivers/gpu/drm/i915/intel_device_info.h > index c912acd06109..ced979c9b366 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.h > +++ b/drivers/gpu/drm/i915/intel_device_info.h > @@ -121,6 +121,7 @@ enum intel_ppgtt_type { > func(has_logical_ring_contexts); \ > func(has_logical_ring_elsq); \ > func(has_logical_ring_preemption); \ > + func(has_master_unit_irq); \ > func(has_pooled_eu); \ > func(has_rc6); \ > func(has_rc6p); \ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions
On Tue, 2020-05-26 at 10:51 -0700, Lucas De Marchi wrote: > On Tue, May 26, 2020 at 10:34:47AM -0700, Jose Souza wrote: > > On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: > > > From: Abdiel Janulgue > > > > > > Bspec: 33617, 33617 > > > > > > Cc: José Roberto de Souza > > > Cc: Daniele Ceraolo Spurio > > > Cc: Stuart Summers > > > Cc: Vanshidhar Konda > > > Cc: Lucas De Marchi > > > Cc: Aravind Iddamsetty > > > Cc: Matt Roper > > > Signed-off-by: Abdiel Janulgue > > > Signed-off-by: Lucas De Marchi > > > --- > > > drivers/gpu/drm/i915/i915_drv.h | 7 +++ > > > drivers/gpu/drm/i915/i915_pci.c | 12 > > > drivers/gpu/drm/i915/intel_device_info.c | 1 + > > > drivers/gpu/drm/i915/intel_device_info.h | 1 + > > > 4 files changed, 21 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > > b/drivers/gpu/drm/i915/i915_drv.h > > > index a9846205a5e2..382703a6c17d 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.h > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > @@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > > > #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE) > > > #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) > > > #define IS_ROCKETLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE) > > > +#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1) > > > #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \ > > > (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00) > > > #define IS_BDW_ULT(dev_priv) \ > > > @@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > > > #define IS_RKL_REVID(p, since, until) \ > > > (IS_ROCKETLAKE(p) && IS_REVID(p, since, until)) > > > > > > +#define DG1_REVID_A0 0x0 > > > +#define DG1_REVID_B0 0x1 > > > + > > > +#define IS_DG1_REVID(p, since, until) \ > > > + (IS_DG1(p) && IS_REVID(p, since, until)) > > > + > > > #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp) > > > #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv)) > > > #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && > > > !IS_LP(dev_priv)) > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c > > > b/drivers/gpu/drm/i915/i915_pci.c > > > index be52d1b76b2e..e5a851a2dfe7 100644 > > > --- a/drivers/gpu/drm/i915/i915_pci.c > > > +++ b/drivers/gpu/drm/i915/i915_pci.c > > > @@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = { > > > > > > #define GEN12_DGFX_FEATURES \ > > > GEN12_FEATURES, \ > > > + .memory_regions = REGION_SMEM | REGION_LMEM, \ > > > > REGION_LMEM should be left here for all GEN12 platforms? > > no, this define is GEN12_DGFX_FEATURES. For dgfx, yes... we should leave > lmem region there. Ops. Also ignore my has_master_unit_irq comment. Reviewed-by: José Roberto de Souza > > Lucas De Marchi > > > I guess it will be detected in runtime that TGL and RKL don't have it but > > would be better to not have it in all GEN12 but will let memory experts to > > shine in, other than LGTM. > > > > > > > .is_dgfx = 1, \ > > > + .has_master_unit_irq = 1, \ > > > .has_snoop_pcie = 1 > > > > > > +static const struct intel_device_info intel_dg1_info = { > > > + GEN12_DGFX_FEATURES, > > > + PLATFORM(INTEL_DG1), > > > + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), > > > + .require_force_probe = 1, > > > + .engine_mask = > > > + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | > > > + BIT(VCS0) | BIT(VCS2), > > > +}; > > > + > > > #undef GEN > > > #undef PLATFORM > > > > > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c > > > b/drivers/gpu/drm/i915/intel_device_info.c > > > index c245c10c9bee..207244b9a852 100644 > > > --- a/drivers/gpu/drm/i915/intel_device_info.c > > > +++ b/drivers/gpu/drm/i915/intel_device_info.c > > > @@ -62,6 +62,7 @@ static const char * const platform_names[] = { > > > PLATFORM_NAME(ELKHARTLAKE), > > > PLATFORM_NAME(TIGERLAKE), > > > PLATFORM_NAME(ROCKETLAKE), > > > + PLATFORM_NAME(DG1), > > > }; > > > #undef PLATFORM_NAME > > > > > > diff --git a/drivers/gpu/drm/i915/intel_device_info.h > > > b/drivers/gpu/drm/i915/intel_device_info.h > > > index 4bcaa0d6a9e6..64260faac006 100644 > > > --- a/drivers/gpu/drm/i915/intel_device_info.h > > > +++ b/drivers/gpu/drm/i915/intel_device_info.h > > > @@ -81,6 +81,7 @@ enum intel_platform { > > > /* gen12 */ > > > INTEL_TIGERLAKE, > > > INTEL_ROCKETLAKE, > > > + INTEL_DG1, > > > INTEL_MAX_PLATFORMS > > > }; > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/37] drm/i915/dg1: add support for the master unit interrupt
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: > DG1 has master unit interrupt register which is used to indicate the > correct source of interrupt. > Reviewed-by: José Roberto de Souza > Cc: Radhakrishna Sripada > Cc: Daniele Spurio Ceraolo > Cc: Matt Roper > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +++ > drivers/gpu/drm/i915/i915_irq.c | 56 +++-- > drivers/gpu/drm/i915/i915_reg.h | 4 +++ > 3 files changed, 61 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index bca036ac6621..4e13f7d7dc5d 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -492,6 +492,10 @@ static int i915_interrupt_info(struct seq_file *m, void > *data) > seq_printf(m, "PCU interrupt enable:\t%08x\n", > I915_READ(GEN8_PCU_IER)); > } else if (INTEL_GEN(dev_priv) >= 11) { > + if (HAS_MASTER_UNIT_IRQ(dev_priv)) > + seq_printf(m, "Master Unit Interrupt Control: %08x\n", > +I915_READ(DG1_MSTR_UNIT_INTR)); > + > seq_printf(m, "Master Interrupt Control: %08x\n", > I915_READ(GEN11_GFX_MSTR_IRQ)); > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 95996db46939..2e950387c179 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -2583,6 +2583,46 @@ static irqreturn_t gen11_irq_handler(int irq, void > *arg) > gen11_master_intr_enable); > } > > +static u32 dg1_master_intr_disable_and_ack(void __iomem * const regs) > +{ > + u32 val; > + > + /* First disable interrupts */ > + raw_reg_write(regs, DG1_MSTR_UNIT_INTR, 0); > + > + /* Get the indication levels and ack the master unit */ > + val = raw_reg_read(regs, DG1_MSTR_UNIT_INTR); > + if (unlikely(!val)) > + return 0; > + > + raw_reg_write(regs, DG1_MSTR_UNIT_INTR, val); > + > + /* > + * Now with master disabled, get a sample of level indications > + * for this interrupt and ack them right away - we keep GEN11_MASTER_IRQ > + * out as this bit doesn't exist anymore for DG1 > + */ > + val = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ) & ~GEN11_MASTER_IRQ; > + if (unlikely(!val)) > + return 0; > + > + raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, val); > + > + return val; > +} > + > +static inline void dg1_master_intr_enable(void __iomem * const regs) > +{ > + raw_reg_write(regs, DG1_MSTR_UNIT_INTR, DG1_MSTR_IRQ); > +} > + > +static irqreturn_t dg1_irq_handler(int irq, void *arg) > +{ > + return __gen11_irq_handler(arg, > +dg1_master_intr_disable_and_ack, > +dg1_master_intr_enable); > +} > + > /* Called from drm generic code, passed 'crtc' which > * we use as a pipe index > */ > @@ -2917,7 +2957,10 @@ static void gen11_irq_reset(struct drm_i915_private > *dev_priv) > { > struct intel_uncore *uncore = &dev_priv->uncore; > > - gen11_master_intr_disable(dev_priv->uncore.regs); > + if (HAS_MASTER_UNIT_IRQ(dev_priv)) > + dg1_master_intr_disable_and_ack(dev_priv->uncore.regs); > + else > + gen11_master_intr_disable(dev_priv->uncore.regs); > > gen11_gt_irq_reset(&dev_priv->gt); > gen11_display_irq_reset(dev_priv); > @@ -3511,8 +3554,13 @@ static void gen11_irq_postinstall(struct > drm_i915_private *dev_priv) > > I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE); > > - gen11_master_intr_enable(uncore->regs); > - POSTING_READ(GEN11_GFX_MSTR_IRQ); > + if (HAS_MASTER_UNIT_IRQ(dev_priv)) { > + dg1_master_intr_enable(uncore->regs); > + POSTING_READ(DG1_MSTR_UNIT_INTR); > + } else { > + gen11_master_intr_enable(uncore->regs); > + POSTING_READ(GEN11_GFX_MSTR_IRQ); > + } > } > > static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv) > @@ -4037,6 +4085,8 @@ static irq_handler_t intel_irq_handler(struct > drm_i915_private *dev_priv) > else > return i8xx_irq_handler; > } else { > + if (HAS_MASTER_UNIT_IRQ(dev_priv)) > + return dg1_irq_handler; > if (INTEL_GEN(dev_priv) >= 11) > return gen11_irq_handler; > else if (INTEL_GEN(dev_priv) >= 8) > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 95e903c01b2b..c1fde43867dc 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -7651,6 +7651,10 @@ enum { > #define GEN11_GT_DW1_IRQ(1 << 1) > #define GEN11_GT_DW0_IRQ(1 << 0) > > +#define DG1_MSTR_UNIT_IN
Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions
On Tue, May 26, 2020 at 10:34:47AM -0700, Jose Souza wrote: On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: From: Abdiel Janulgue Bspec: 33617, 33617 Cc: José Roberto de Souza Cc: Daniele Ceraolo Spurio Cc: Stuart Summers Cc: Vanshidhar Konda Cc: Lucas De Marchi Cc: Aravind Iddamsetty Cc: Matt Roper Signed-off-by: Abdiel Janulgue Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_drv.h | 7 +++ drivers/gpu/drm/i915/i915_pci.c | 12 drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 1 + 4 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a9846205a5e2..382703a6c17d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE) #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) #define IS_ROCKETLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE) +#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1) #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \ (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00) #define IS_BDW_ULT(dev_priv) \ @@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define IS_RKL_REVID(p, since, until) \ (IS_ROCKETLAKE(p) && IS_REVID(p, since, until)) +#define DG1_REVID_A0 0x0 +#define DG1_REVID_B0 0x1 + +#define IS_DG1_REVID(p, since, until) \ + (IS_DG1(p) && IS_REVID(p, since, until)) + #define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv)) #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv)) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index be52d1b76b2e..e5a851a2dfe7 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = { #define GEN12_DGFX_FEATURES \ GEN12_FEATURES, \ + .memory_regions = REGION_SMEM | REGION_LMEM, \ REGION_LMEM should be left here for all GEN12 platforms? no, this define is GEN12_DGFX_FEATURES. For dgfx, yes... we should leave lmem region there. Lucas De Marchi I guess it will be detected in runtime that TGL and RKL don't have it but would be better to not have it in all GEN12 but will let memory experts to shine in, other than LGTM. .is_dgfx = 1, \ + .has_master_unit_irq = 1, \ .has_snoop_pcie = 1 +static const struct intel_device_info intel_dg1_info = { + GEN12_DGFX_FEATURES, + PLATFORM(INTEL_DG1), + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), + .require_force_probe = 1, + .engine_mask = + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | + BIT(VCS0) | BIT(VCS2), +}; + #undef GEN #undef PLATFORM diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index c245c10c9bee..207244b9a852 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -62,6 +62,7 @@ static const char * const platform_names[] = { PLATFORM_NAME(ELKHARTLAKE), PLATFORM_NAME(TIGERLAKE), PLATFORM_NAME(ROCKETLAKE), + PLATFORM_NAME(DG1), }; #undef PLATFORM_NAME diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 4bcaa0d6a9e6..64260faac006 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -81,6 +81,7 @@ enum intel_platform { /* gen12 */ INTEL_TIGERLAKE, INTEL_ROCKETLAKE, + INTEL_DG1, INTEL_MAX_PLATFORMS }; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: > From: Abdiel Janulgue > > Bspec: 33617, 33617 > > Cc: José Roberto de Souza > Cc: Daniele Ceraolo Spurio > Cc: Stuart Summers > Cc: Vanshidhar Konda > Cc: Lucas De Marchi > Cc: Aravind Iddamsetty > Cc: Matt Roper > Signed-off-by: Abdiel Janulgue > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_drv.h | 7 +++ > drivers/gpu/drm/i915/i915_pci.c | 12 > drivers/gpu/drm/i915/intel_device_info.c | 1 + > drivers/gpu/drm/i915/intel_device_info.h | 1 + > 4 files changed, 21 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index a9846205a5e2..382703a6c17d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE) > #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) > #define IS_ROCKETLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE) > +#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1) > #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \ > (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00) > #define IS_BDW_ULT(dev_priv) \ > @@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define IS_RKL_REVID(p, since, until) \ > (IS_ROCKETLAKE(p) && IS_REVID(p, since, until)) > > +#define DG1_REVID_A0 0x0 > +#define DG1_REVID_B0 0x1 > + > +#define IS_DG1_REVID(p, since, until) \ > + (IS_DG1(p) && IS_REVID(p, since, until)) > + > #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp) > #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv)) > #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv)) > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > index be52d1b76b2e..e5a851a2dfe7 100644 > --- a/drivers/gpu/drm/i915/i915_pci.c > +++ b/drivers/gpu/drm/i915/i915_pci.c > @@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = { > > #define GEN12_DGFX_FEATURES \ > GEN12_FEATURES, \ > + .memory_regions = REGION_SMEM | REGION_LMEM, \ > .is_dgfx = 1, \ > + .has_master_unit_irq = 1, \ Also has_master_unit_irq is wrong, it should be added only to intel_dg1_info, TGL don't have DG1_MSTR_UNIT_INTR according to the "drm/i915/dg1: add support for the master unit interrupt" and BSpec: 50862 > .has_snoop_pcie = 1 > > +static const struct intel_device_info intel_dg1_info = { > + GEN12_DGFX_FEATURES, > + PLATFORM(INTEL_DG1), > + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), > + .require_force_probe = 1, > + .engine_mask = > + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | > + BIT(VCS0) | BIT(VCS2), > +}; > + > #undef GEN > #undef PLATFORM > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c > b/drivers/gpu/drm/i915/intel_device_info.c > index c245c10c9bee..207244b9a852 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.c > +++ b/drivers/gpu/drm/i915/intel_device_info.c > @@ -62,6 +62,7 @@ static const char * const platform_names[] = { > PLATFORM_NAME(ELKHARTLAKE), > PLATFORM_NAME(TIGERLAKE), > PLATFORM_NAME(ROCKETLAKE), > + PLATFORM_NAME(DG1), > }; > #undef PLATFORM_NAME > > diff --git a/drivers/gpu/drm/i915/intel_device_info.h > b/drivers/gpu/drm/i915/intel_device_info.h > index 4bcaa0d6a9e6..64260faac006 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.h > +++ b/drivers/gpu/drm/i915/intel_device_info.h > @@ -81,6 +81,7 @@ enum intel_platform { > /* gen12 */ > INTEL_TIGERLAKE, > INTEL_ROCKETLAKE, > + INTEL_DG1, > INTEL_MAX_PLATFORMS > }; > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 35/37] drm/i915/dg1: Load DMC
On Tue, May 26, 2020 at 10:42:30AM -0700, Jose Souza wrote: On Wed, 2020-05-20 at 17:38 -0700, Lucas De Marchi wrote: From: Matt Atwood Add support to load DMC v2.0.2 on DG1 While we're at it, tweak the TGL and RKL firmware size definition to follow the convention used in previous platforms. Remove obsolete commenting. Bpec: 49230 Cc: Matt Roper Signed-off-by: Matt Atwood Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_csr.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_csr.c b/drivers/gpu/drm/i915/display/intel_csr.c index 319932b03e88..1f05876620fe 100644 --- a/drivers/gpu/drm/i915/display/intel_csr.c +++ b/drivers/gpu/drm/i915/display/intel_csr.c @@ -38,15 +38,19 @@ * low-power state and comes back to normal. */ -#define GEN12_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE Why GEN12_CSR_MAX_FW_SIZE was replaced by platform size if the size is still the same for all? Previous platforms used it per platform rather than gen, so I guess this is what Matt Atwood intended to do and wrote in the last paragraph in the commit message. I think we could go either way... no strong opinion on one vs the other. Lucas De Marchi +#define DG1_CSR_PATH "i915/dg1_dmc_ver2_02.bin" +#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) +#define DG1_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE +MODULE_FIRMWARE(DG1_CSR_PATH); #define RKL_CSR_PATH "i915/rkl_dmc_ver2_01.bin" #define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 1) +#define RKL_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE MODULE_FIRMWARE(RKL_CSR_PATH); #define TGL_CSR_PATH "i915/tgl_dmc_ver2_06.bin" #define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 6) -#define TGL_CSR_MAX_FW_SIZE0x6000 +#define TGL_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE MODULE_FIRMWARE(TGL_CSR_PATH); #define ICL_CSR_PATH "i915/icl_dmc_ver1_09.bin" @@ -686,15 +690,18 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv) */ intel_csr_runtime_pm_get(dev_priv); - if (IS_ROCKETLAKE(dev_priv)) { + if (IS_DG1(dev_priv)) { + csr->fw_path = DG1_CSR_PATH; + csr->required_version = DG1_CSR_VERSION_REQUIRED; + csr->max_fw_size = DG1_CSR_MAX_FW_SIZE; + } else if (IS_ROCKETLAKE(dev_priv)) { csr->fw_path = RKL_CSR_PATH; csr->required_version = RKL_CSR_VERSION_REQUIRED; - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE; + csr->max_fw_size = RKL_CSR_MAX_FW_SIZE; } else if (INTEL_GEN(dev_priv) >= 12) { csr->fw_path = TGL_CSR_PATH; csr->required_version = TGL_CSR_VERSION_REQUIRED; - /* Allow to load fw via parameter using the last known size */ - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE; + csr->max_fw_size = TGL_CSR_MAX_FW_SIZE; } else if (IS_GEN(dev_priv, 11)) { csr->fw_path = ICL_CSR_PATH; csr->required_version = ICL_CSR_VERSION_REQUIRED; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/37] drm/i915/dg1: Remove SHPD_FILTER_CNT register programming
On Wed, 2020-05-20 at 17:38 -0700, Lucas De Marchi wrote: > From: Anusha Srivatsa > > Bspec asks us to remove the special programming of the > SHPD_FILTER_CNT register which we have been doing since CNP+. > > Bspec: 49305 > Reviewed-by: José Roberto de Souza > Cc: Matt Roper > Signed-off-by: Anusha Srivatsa > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_irq.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index ca35edef492d..d4061d5b4d67 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -3274,7 +3274,8 @@ static void icp_hpd_irq_setup(struct drm_i915_private > *dev_priv, > hotplug_irqs = sde_ddi_mask | sde_tc_mask; > enabled_irqs = intel_hpd_enabled_irqs(dev_priv, > dev_priv->hotplug.pch_hpd); > > - I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ); > + if (INTEL_PCH_TYPE(dev_priv) <= PCH_TGP) > + I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ); > > ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs); > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 35/37] drm/i915/dg1: Load DMC
On Wed, 2020-05-20 at 17:38 -0700, Lucas De Marchi wrote: > From: Matt Atwood > > Add support to load DMC v2.0.2 on DG1 > > While we're at it, tweak the TGL and RKL firmware size definition to > follow the convention used in previous platforms. Remove obsolete > commenting. > > Bpec: 49230 > > Cc: Matt Roper > Signed-off-by: Matt Atwood > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/display/intel_csr.c | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_csr.c > b/drivers/gpu/drm/i915/display/intel_csr.c > index 319932b03e88..1f05876620fe 100644 > --- a/drivers/gpu/drm/i915/display/intel_csr.c > +++ b/drivers/gpu/drm/i915/display/intel_csr.c > @@ -38,15 +38,19 @@ > * low-power state and comes back to normal. > */ > > -#define GEN12_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE Why GEN12_CSR_MAX_FW_SIZE was replaced by platform size if the size is still the same for all? > +#define DG1_CSR_PATH "i915/dg1_dmc_ver2_02.bin" > +#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) > +#define DG1_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE > +MODULE_FIRMWARE(DG1_CSR_PATH); > > #define RKL_CSR_PATH "i915/rkl_dmc_ver2_01.bin" > #define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 1) > +#define RKL_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE > MODULE_FIRMWARE(RKL_CSR_PATH); > > #define TGL_CSR_PATH "i915/tgl_dmc_ver2_06.bin" > #define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 6) > -#define TGL_CSR_MAX_FW_SIZE 0x6000 > +#define TGL_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE > MODULE_FIRMWARE(TGL_CSR_PATH); > > #define ICL_CSR_PATH "i915/icl_dmc_ver1_09.bin" > @@ -686,15 +690,18 @@ void intel_csr_ucode_init(struct drm_i915_private > *dev_priv) >*/ > intel_csr_runtime_pm_get(dev_priv); > > - if (IS_ROCKETLAKE(dev_priv)) { > + if (IS_DG1(dev_priv)) { > + csr->fw_path = DG1_CSR_PATH; > + csr->required_version = DG1_CSR_VERSION_REQUIRED; > + csr->max_fw_size = DG1_CSR_MAX_FW_SIZE; > + } else if (IS_ROCKETLAKE(dev_priv)) { > csr->fw_path = RKL_CSR_PATH; > csr->required_version = RKL_CSR_VERSION_REQUIRED; > - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE; > + csr->max_fw_size = RKL_CSR_MAX_FW_SIZE; > } else if (INTEL_GEN(dev_priv) >= 12) { > csr->fw_path = TGL_CSR_PATH; > csr->required_version = TGL_CSR_VERSION_REQUIRED; > - /* Allow to load fw via parameter using the last known size */ > - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE; > + csr->max_fw_size = TGL_CSR_MAX_FW_SIZE; > } else if (IS_GEN(dev_priv, 11)) { > csr->fw_path = ICL_CSR_PATH; > csr->required_version = ICL_CSR_VERSION_REQUIRED; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/37] drm/i915/dg1: Add DG1 PCI IDs
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: > From: Abdiel Janulgue > > Bspec: 44463 Reviewed-by: José Roberto de Souza > > Cc: Matthew Auld > Cc: James Ausmus > Cc: Joonas Lahtinen > Cc: Matt Roper > Signed-off-by: Abdiel Janulgue > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_pci.c | 3 ++- > include/drm/i915_pciids.h | 4 > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > index e5a851a2dfe7..f1a3a59093c9 100644 > --- a/drivers/gpu/drm/i915/i915_pci.c > +++ b/drivers/gpu/drm/i915/i915_pci.c > @@ -879,7 +879,7 @@ static const struct intel_device_info rkl_info = { > .has_master_unit_irq = 1, \ > .has_snoop_pcie = 1 > > -static const struct intel_device_info intel_dg1_info = { > +static const struct intel_device_info dg1_info = { > GEN12_DGFX_FEATURES, > PLATFORM(INTEL_DG1), > .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), > @@ -964,6 +964,7 @@ static const struct pci_device_id pciidlist[] = { > INTEL_EHL_IDS(&ehl_info), > INTEL_TGL_12_IDS(&tgl_info), > INTEL_RKL_IDS(&rkl_info), > + INTEL_DG1_IDS(&dg1_info), > {0, 0, 0} > }; > MODULE_DEVICE_TABLE(pci, pciidlist); > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index bc989de2aac2..f44fe822880d 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -614,4 +614,8 @@ > INTEL_VGA_DEVICE(0x4C90, info), \ > INTEL_VGA_DEVICE(0x4C9A, info) > > +/* DG1 */ > +#define INTEL_DG1_IDS(info) \ > + INTEL_VGA_DEVICE(0x4905, info) > + > #endif /* _I915_PCIIDS_H */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: > From: Abdiel Janulgue > > Bspec: 33617, 33617 > > Cc: José Roberto de Souza > Cc: Daniele Ceraolo Spurio > Cc: Stuart Summers > Cc: Vanshidhar Konda > Cc: Lucas De Marchi > Cc: Aravind Iddamsetty > Cc: Matt Roper > Signed-off-by: Abdiel Janulgue > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_drv.h | 7 +++ > drivers/gpu/drm/i915/i915_pci.c | 12 > drivers/gpu/drm/i915/intel_device_info.c | 1 + > drivers/gpu/drm/i915/intel_device_info.h | 1 + > 4 files changed, 21 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index a9846205a5e2..382703a6c17d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE) > #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) > #define IS_ROCKETLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE) > +#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1) > #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \ > (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00) > #define IS_BDW_ULT(dev_priv) \ > @@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define IS_RKL_REVID(p, since, until) \ > (IS_ROCKETLAKE(p) && IS_REVID(p, since, until)) > > +#define DG1_REVID_A0 0x0 > +#define DG1_REVID_B0 0x1 > + > +#define IS_DG1_REVID(p, since, until) \ > + (IS_DG1(p) && IS_REVID(p, since, until)) > + > #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp) > #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv)) > #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv)) > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > index be52d1b76b2e..e5a851a2dfe7 100644 > --- a/drivers/gpu/drm/i915/i915_pci.c > +++ b/drivers/gpu/drm/i915/i915_pci.c > @@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = { > > #define GEN12_DGFX_FEATURES \ > GEN12_FEATURES, \ > + .memory_regions = REGION_SMEM | REGION_LMEM, \ REGION_LMEM should be left here for all GEN12 platforms? I guess it will be detected in runtime that TGL and RKL don't have it but would be better to not have it in all GEN12 but will let memory experts to shine in, other than LGTM. > .is_dgfx = 1, \ > + .has_master_unit_irq = 1, \ > .has_snoop_pcie = 1 > > +static const struct intel_device_info intel_dg1_info = { > + GEN12_DGFX_FEATURES, > + PLATFORM(INTEL_DG1), > + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), > + .require_force_probe = 1, > + .engine_mask = > + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | > + BIT(VCS0) | BIT(VCS2), > +}; > + > #undef GEN > #undef PLATFORM > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c > b/drivers/gpu/drm/i915/intel_device_info.c > index c245c10c9bee..207244b9a852 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.c > +++ b/drivers/gpu/drm/i915/intel_device_info.c > @@ -62,6 +62,7 @@ static const char * const platform_names[] = { > PLATFORM_NAME(ELKHARTLAKE), > PLATFORM_NAME(TIGERLAKE), > PLATFORM_NAME(ROCKETLAKE), > + PLATFORM_NAME(DG1), > }; > #undef PLATFORM_NAME > > diff --git a/drivers/gpu/drm/i915/intel_device_info.h > b/drivers/gpu/drm/i915/intel_device_info.h > index 4bcaa0d6a9e6..64260faac006 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.h > +++ b/drivers/gpu/drm/i915/intel_device_info.h > @@ -81,6 +81,7 @@ enum intel_platform { > /* gen12 */ > INTEL_TIGERLAKE, > INTEL_ROCKETLAKE, > + INTEL_DG1, > INTEL_MAX_PLATFORMS > }; > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/selftests: Fix runtime PM imbalance on error
== Series Details == Series: drm/i915/selftests: Fix runtime PM imbalance on error URL : https://patchwork.freedesktop.org/series/77667/ State : failure == Summary == Applying: drm/i915/selftests: Fix runtime PM imbalance on error Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/selftests/mock_gem_device.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/selftests/mock_gem_device.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/selftests/mock_gem_device.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/selftests: Fix runtime PM imbalance on error When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Fix runtime PM imbalance on error
When drm_dev_init() returns an error code, a pairing runtime PM usage counter decrement is needed to keep the counter balanced. For error paths after this call, things are the same. Signed-off-by: Dinghao Liu --- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c index 754d0eb6beaa..fdf01461acc6 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c @@ -200,6 +200,7 @@ struct drm_i915_private *mock_gem_device(void) drm_mode_config_cleanup(&i915->drm); drm_dev_fini(&i915->drm); put_device: + pm_runtime_put_noidle(&pdev->dev); put_device(&pdev->dev); err: return NULL; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
On 2020-05-23 02:41, Chris Wilson wrote: Quoting John Hubbard (2020-05-22 06:19:27) The purpose of posting this series is to launch a test in the intel-gfx-ci tree. (The patches have already been merged into Andrew's linux-mm tree.) This applies to today's linux.git (note the base-commit tag at the bottom). Changes since V1: * Fixed a bug in the refactoring patch: added FOLL_FAST_ONLY to the list of gup_flags *not* to WARN() on. This lead to a failure in the first intel-gfx-ci test run [1]. [1] https://lore.kernel.org/r/159008745422.32320.5724805750977048...@build.alporthouse.com Ran this through our CI, warn and subsequent lockup were gone. That DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1590273216; bh=oK85oUq4LCrgTs8kxvJryKE7a7GUQfAveFtGpNOU2dQ=; h=X-PGP-Universal:Subject:To:CC:References:From:X-Nvconfidentiality: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=QoI4eJbYYVxcoARKgFJdRrxzB/GBPqy5yKIF46/pjR75LEiZvvAX947VBwywSMYhx It8aQpMm6kMaF/rxiv0IPBf3tNGxNziWBAAhDXCyNqmvAS5s1HfdQh5ZoYbyDynKbJ uF+u9JjBOYo5uTnn3IUaGPRgl/p9k6OhwRhbJ9nYreDwIF1/1pPeo97jwP2jW7AtDf xDO5iJhGmwLYHPzRLilgiDdLbNhIGAP1XJ/4t/DByshidOUalduU7HxVQ9IOnysnCw QcqSlpyPgx5LkJOvs63gO8n28hHJnoJ4FggNXC3D311lBWRuD7iekdP5WuvmrxUb8N rZKwTpl0vJl9w== Yea! Thanks again for these test runs. I really don't like posting patches that I can't run-time test, but this CI system mitigates that pretty well. lockup is worrying me now, but that doesn't seem to be an issue from this series. I do think it's worth following up on. And it seems like it would be very easy to repro: just hack in a forced failure at the call site of pin_user_pages_fast_only(), and follow the breadcrumbs. The i915 changes were simple enough, I would have computed the pin flags just once (since the readonly bit is static, that would be interesting if that was allowed to change mid gup :) Reviewed-by: Chris Wilson -Chris Thanks for the review! And if lifting that check up higher in the call stack is desired, I'm all in favor of that being done...in a separate patch. :) I'm trying to keep a very light touch when converting these call sites. thanks, -- John Hubbard NVIDIA ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual
Quoting Tvrtko Ursulin (2020-05-26 17:00:06) > > On 26/05/2020 10:07, Chris Wilson wrote: > > When we push a virtual request onto the HW, we update the rq->engine to > > point to the physical engine. A request that is then submitted by the > > user that waits upon the virtual engine, but along the physical engine > > in use, will then see that it is due to be submitted to the same engine > > and take a shortcut (and be queued without waiting for the completion > > fence). However, the virtual request may be preempted (either by higher > > priority users, or by timeslicing) and removed from the physical engine > > to be migrated over to one of its siblings. The dependent normal request > > however is oblivious to the removal of the virtual request and remains > > queued to execute on HW, believing that once it reaches the head of its > > queue all of its predecessors will have completed executing! > > > > v2: Beware restriction of signal->execution_mask prior to submission. > > > > Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") > > Testcase: igt/gem_exec_balancer/sliced > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: # v5.3+ > > --- > > drivers/gpu/drm/i915/i915_request.c | 25 + > > 1 file changed, 21 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index 33bbad623e02..0b07ccc7e9bc 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq, > > return 0; > > } > > > > +static int > > +await_request_submit(struct i915_request *to, struct i915_request *from) > > +{ > > + /* > > + * If we are waiting on a virtual engine, then it may be > > + * constrained to execute on a single engine *prior* to submission. > > + * When it is submitted, it will be first submitted to the virtual > > + * engine and then passed to the physical engine. We cannot allow > > + * the waiter to be submitted immediately to the physical engine > > + * as it may then bypass the virtual request. > > + */ > > + if (to->engine == READ_ONCE(from->engine)) > > + return i915_sw_fence_await_sw_fence_gfp(&to->submit, > > + &from->submit, > > + I915_FENCE_GFP); > > + else > > When can engines be different and the mask test below brought us here? We change the mask during evaluation of the bond, which is from the signaler's signaler's execute_cb before the signaler is submitted. So there will be a period where the from->execution_mask is constrained to a single engine, but it is still waiting to be queued. Once it is executed on HW, it will remain on that engine. -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] i915/perf_pmu: Update inter-engine semaphore detection
Quoting Tvrtko Ursulin (2020-05-26 16:58:05) > > On 26/05/2020 15:17, Chris Wilson wrote: > > The kernel no longer uses semaphores between engines, unless it can do > > so by preempting them with timeslices. Update the semaphore-busy to only > > run when we expect semaphore usage, i.e. not on bdw/bsw. > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1939 > > Signed-off-by: Chris Wilson > > --- > > tests/perf_pmu.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c > > index e54a0d47e..e80f730cf 100644 > > --- a/tests/perf_pmu.c > > +++ b/tests/perf_pmu.c > > @@ -822,6 +822,7 @@ sema_busy(int gem_fd, > > int fd; > > > > igt_require(gem_scheduler_has_semaphores(gem_fd)); > > + igt_require(gem_scheduler_has_preemption(gem_fd)); > > > > fd = open_group(gem_fd, > > I915_PMU_ENGINE_SEMA(e->class, e->instance), -1); > > > > Test with perhaps too intimate knowledge of i915.. iirc, part of the intent of the test was to understand how the kernel's choice of inter-engine sync would show up in the pmu. The challenge we have is in declaring the expected outcomes, that requires intimate knowledge of what the kernel might decide to do. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual
On 26/05/2020 10:07, Chris Wilson wrote: When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon the virtual engine, but along the physical engine in use, will then see that it is due to be submitted to the same engine and take a shortcut (and be queued without waiting for the completion fence). However, the virtual request may be preempted (either by higher priority users, or by timeslicing) and removed from the physical engine to be migrated over to one of its siblings. The dependent normal request however is oblivious to the removal of the virtual request and remains queued to execute on HW, believing that once it reaches the head of its queue all of its predecessors will have completed executing! v2: Beware restriction of signal->execution_mask prior to submission. Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Testcase: igt/gem_exec_balancer/sliced Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: # v5.3+ --- drivers/gpu/drm/i915/i915_request.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 33bbad623e02..0b07ccc7e9bc 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq, return 0; } +static int +await_request_submit(struct i915_request *to, struct i915_request *from) +{ + /* +* If we are waiting on a virtual engine, then it may be +* constrained to execute on a single engine *prior* to submission. +* When it is submitted, it will be first submitted to the virtual +* engine and then passed to the physical engine. We cannot allow +* the waiter to be submitted immediately to the physical engine +* as it may then bypass the virtual request. +*/ + if (to->engine == READ_ONCE(from->engine)) + return i915_sw_fence_await_sw_fence_gfp(&to->submit, + &from->submit, + I915_FENCE_GFP); + else When can engines be different and the mask test below brought us here? Regards, Tvrtko + return __i915_request_await_execution(to, from, NULL); +} + static int i915_request_await_request(struct i915_request *to, struct i915_request *from) { @@ -1258,10 +1277,8 @@ i915_request_await_request(struct i915_request *to, struct i915_request *from) return ret; } - if (to->engine == READ_ONCE(from->engine)) - ret = i915_sw_fence_await_sw_fence_gfp(&to->submit, - &from->submit, - I915_FENCE_GFP); + if (is_power_of_2(to->execution_mask | READ_ONCE(from->execution_mask))) + ret = await_request_submit(to, from); else ret = emit_semaphore_wait(to, from, I915_FENCE_GFP); if (ret < 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Update inter-engine semaphore detection
On 26/05/2020 15:17, Chris Wilson wrote: The kernel no longer uses semaphores between engines, unless it can do so by preempting them with timeslices. Update the semaphore-busy to only run when we expect semaphore usage, i.e. not on bdw/bsw. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1939 Signed-off-by: Chris Wilson --- tests/perf_pmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c index e54a0d47e..e80f730cf 100644 --- a/tests/perf_pmu.c +++ b/tests/perf_pmu.c @@ -822,6 +822,7 @@ sema_busy(int gem_fd, int fd; igt_require(gem_scheduler_has_semaphores(gem_fd)); + igt_require(gem_scheduler_has_preemption(gem_fd)); fd = open_group(gem_fd, I915_PMU_ENGINE_SEMA(e->class, e->instance), -1); Test with perhaps too intimate knowledge of i915.. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume
== Series Details == Series: drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume URL : https://patchwork.freedesktop.org/series/77666/ State : success == Summary == CI Bug Log - changes from CI_DRM_8539 -> Patchwork_17779 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/index.html Changes --- No changes found Participating hosts (50 -> 44) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8539 -> Patchwork_17779 CI-20190529: 20190529 CI_DRM_8539: 6590da76d8c6a2952b3cde70859bad41c59ed444 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17779: f2bb7a370b1aa4fee6d41385fab9a42099942db3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f2bb7a370b1a drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume
We only restore GLOBAL binds upon resume as we expect these to be pinned for use by HW, whereas the LOCAL binds can be recreated on demand once userspace is resumed. For the LOCAL bind to be recreated in the global GTT, we need to clear its presence flag on deciding not to restore the mapping upon resume. Fixes: bf0840cdb304 ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with PIN_USER with no-ppgtt") Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 8c275f8588c3..317172ad5ef3 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -1161,6 +1161,11 @@ void i915_ggtt_disable_guc(struct i915_ggtt *ggtt) ggtt->invalidate(ggtt); } +static unsigned int clear_bind(struct i915_vma *vma) +{ + return atomic_fetch_and(~I915_VMA_BIND_MASK, &vma->flags); +} + void i915_ggtt_resume(struct i915_ggtt *ggtt) { struct i915_vma *vma; @@ -1179,10 +1184,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt) list_for_each_entry(vma, &ggtt->vm.bound_list, vm_link) { struct drm_i915_gem_object *obj = vma->obj; - if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) + if (!(clear_bind(vma) & I915_VMA_GLOBAL_BIND)) continue; - clear_bit(I915_VMA_GLOBAL_BIND_BIT, __i915_vma_flags(vma)); WARN_ON(i915_vma_bind(vma, obj ? obj->cache_level : 0, PIN_GLOBAL, NULL)); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915/params: don't expose inject_probe_failure in debugfs
== Series Details == Series: series starting with [CI,1/4] drm/i915/params: don't expose inject_probe_failure in debugfs URL : https://patchwork.freedesktop.org/series/77661/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8539 -> Patchwork_17778 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17778 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17778, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17778: ### CI changes ### Possible regressions * boot: - fi-kbl-8809g: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-kbl-8809g/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-kbl-8809g/boot.html - fi-icl-y: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-y/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-y/boot.html - fi-icl-u2: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-u2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-u2/boot.html - fi-cfl-8109u: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cfl-8109u/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cfl-8109u/boot.html - fi-skl-6600u: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-skl-6600u/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-skl-6600u/boot.html - fi-cfl-8700k: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cfl-8700k/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cfl-8700k/boot.html - fi-icl-dsi: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-dsi/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-dsi/boot.html - fi-whl-u: [PASS][15] -> [FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-whl-u/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-whl-u/boot.html - fi-cml-u2: [PASS][17] -> [FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cml-u2/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cml-u2/boot.html - fi-skl-6700k2: [PASS][19] -> [FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-skl-6700k2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-skl-6700k2/boot.html - fi-cfl-guc: [PASS][21] -> [FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cfl-guc/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cfl-guc/boot.html - fi-kbl-soraka: [PASS][23] -> [FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-kbl-soraka/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-kbl-soraka/boot.html - fi-icl-guc: [PASS][25] -> [FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-guc/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-guc/boot.html - fi-cml-s: [PASS][27] -> [FAIL][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cml-s/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cml-s/boot.html - fi-skl-lmem:[PASS][29] -> [FAIL][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-skl-lmem/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-skl-lmem/boot.html - fi-glk-dsi: [PASS][31] -> [FAIL][32] [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-glk-dsi/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-glk-dsi/boot.html - fi-tgl-y: [PASS][33] -> [FAIL][34] [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-tgl-y/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-tgl-y/boot.html - fi-kbl-guc: [PASS][35] -> [FAIL][36] [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-kbl-guc/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-kbl-guc/boot.html - fi-kbl-x1275: [PASS][37] -> [FAIL][
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Update inter-engine semaphore detection
The kernel no longer uses semaphores between engines, unless it can do so by preempting them with timeslices. Update the semaphore-busy to only run when we expect semaphore usage, i.e. not on bdw/bsw. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1939 Signed-off-by: Chris Wilson --- tests/perf_pmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c index e54a0d47e..e80f730cf 100644 --- a/tests/perf_pmu.c +++ b/tests/perf_pmu.c @@ -822,6 +822,7 @@ sema_busy(int gem_fd, int fd; igt_require(gem_scheduler_has_semaphores(gem_fd)); + igt_require(gem_scheduler_has_preemption(gem_fd)); fd = open_group(gem_fd, I915_PMU_ENGINE_SEMA(e->class, e->instance), -1); -- 2.27.0.rc0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915/params: don't expose inject_probe_failure in debugfs
== Series Details == Series: series starting with [CI,1/4] drm/i915/params: don't expose inject_probe_failure in debugfs URL : https://patchwork.freedesktop.org/series/77661/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8685c3c6d218 drm/i915/params: don't expose inject_probe_failure in debugfs 4d8a197e487c drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions -:27: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #27: FILE: drivers/gpu/drm/i915/i915_params.c:177: +i915_param_named_unsafe(fake_lmem_start, ulong, 0400, "Fake LMEM start offset (default: 0)"); total: 0 errors, 0 warnings, 1 checks, 8 lines checked af9a802b3b26 drm/i915/params: prevent changing module params runtime -:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #48: FILE: drivers/gpu/drm/i915/i915_params.c:62: +i915_param_named_unsafe(enable_fbc, int, 0400, "Enable frame buffer compression for power savings " -:57: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #57: FILE: drivers/gpu/drm/i915/i915_params.c:70: +i915_param_named_unsafe(panel_use_ssc, int, 0400, "Use Spread Spectrum Clock with panels [LVDS/eDP] " -:66: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #66: FILE: drivers/gpu/drm/i915/i915_params.c:78: +i915_param_named_unsafe(reset, int, 0400, "Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default])"); -:74: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #74: FILE: drivers/gpu/drm/i915/i915_params.c:85: +i915_param_named(error_capture, bool, 0400, "Record the GPU state following a hang. " -:81: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #81: FILE: drivers/gpu/drm/i915/i915_params.c:91: +i915_param_named_unsafe(enable_hangcheck, bool, 0400, "Periodically check GPU activity for detecting hangs. " -:87: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #87: FILE: drivers/gpu/drm/i915/i915_params.c:96: +i915_param_named_unsafe(enable_psr, int, 0400, "Enable PSR " -:99: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #99: FILE: drivers/gpu/drm/i915/i915_params.c:111: +i915_param_named(fastboot, int, 0400, "Try to skip unnecessary mode sets at boot time " -:105: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #105: FILE: drivers/gpu/drm/i915/i915_params.c:116: +i915_param_named_unsafe(load_detect_test, bool, 0400, "Force-enable the VGA load detect code for testing (default:false). " -:110: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #110: FILE: drivers/gpu/drm/i915/i915_params.c:120: +i915_param_named_unsafe(force_reset_modeset_test, bool, 0400, "Force a modeset during gpu reset for testing (default:false). " -:115: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #115: FILE: drivers/gpu/drm/i915/i915_params.c:124: +i915_param_named_unsafe(invert_brightness, int, 0400, "Invert backlight brightness " -:124: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #124: FILE: drivers/gpu/drm/i915/i915_params.c:134: +i915_param_named(mmio_debug, int, 0400, "Enable the MMIO debug code for the first N failures (default: off). " -:137: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #137: FILE: drivers/gpu/drm/i915/i915_params.c:169: +i915_param_named_unsafe(enable_dp_mst, bool, 0400, "Enable multi-stream transport (MST) for new DisplayPort sinks. (default: true)"); -:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #146: FILE: drivers/gpu/drm/i915/i915_params.c:177: +i915_param_named(enable_dpcd_backlight, int, 0400, "Enable support for DPCD backlight control" total: 0 errors, 0 warnings, 13 checks, 115 lines checked 92adebe0d92e drm/i915/params: switch to device specific parameters ___ 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: Fix wrong CDCLK adjustment changes
== Series Details == Series: drm/i915: Fix wrong CDCLK adjustment changes URL : https://patchwork.freedesktop.org/series/77654/ State : success == Summary == CI Bug Log - changes from CI_DRM_8537_full -> Patchwork_17776_full Summary --- **SUCCESS** No regressions found. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17776_full: ### Piglit changes ### Possible regressions * spec@glsl-4.30@execution@built-in-functions@cs-op-bitand-not-uvec4-uint (NEW): - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][1] +7 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/pig-icl-1065g7/spec@glsl-4.30@execution@built-in-functi...@cs-op-bitand-not-uvec4-uint.html * spec@glsl-4.30@execution@built-in-functions@cs-op-ne-ivec2-ivec2-using-if (NEW): - {pig-icl-1065g7}: NOTRUN -> [CRASH][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/pig-icl-1065g7/spec@glsl-4.30@execution@built-in-functi...@cs-op-ne-ivec2-ivec2-using-if.html New tests - New tests have been introduced between CI_DRM_8537_full and Patchwork_17776_full: ### New Piglit tests (9) ### * spec@glsl-4.30@execution@built-in-functions@cs-greaterthanequal-uvec3-uvec3: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@glsl-4.30@execution@built-in-functions@cs-op-add-mat2x4-mat2x4: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@glsl-4.30@execution@built-in-functions@cs-op-bitand-not-uvec4-uint: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@glsl-4.30@execution@built-in-functions@cs-op-mult-int-ivec2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@glsl-4.30@execution@built-in-functions@cs-op-ne-ivec2-ivec2-using-if: - Statuses : 1 crash(s) - Exec time: [0.39] s * spec@glsl-4.30@execution@built-in-functions@cs-op-ne-vec3-vec3-using-if: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@glsl-4.30@execution@built-in-functions@cs-op-rshift-ivec2-uvec2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@glsl-4.30@execution@built-in-functions@cs-op-selection-bool-uvec2-uvec2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@glsl-4.30@execution@built-in-functions@cs-op-sub-float-mat2x4: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_17776_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-kbl6/igt@gem_soft...@noreloc-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-kbl3/igt@gem_soft...@noreloc-s3.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk7/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-glk4/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#1119] / [i915#118] / [i915#95]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk4/igt@kms_big...@y-tiled-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-apl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#54]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl8/igt@kms_...@bpc-switch-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-skl4/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-
[Intel-gfx] [PATCH i-g-t] lib/i915: Restore hangcheck modparams between tests
The hangcheck/reset modparam has far reaching effects and disables functionality if switch off. This can surprise a few tests causing them to skip. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1929 Signed-off-by: Chris Wilson --- lib/i915/gem.c | 8 1 file changed, 8 insertions(+) diff --git a/lib/i915/gem.c b/lib/i915/gem.c index 3ef31ed33..45db8a0fd 100644 --- a/lib/i915/gem.c +++ b/lib/i915/gem.c @@ -130,6 +130,13 @@ static void reset_device(int i915) close(dir); } +static void restore_params(int i915) +{ + /* Re-enable modparams if left clobbered */ + igt_params_set(i915, "reset", "%u", -1); + igt_params_set(i915, "enable_hangcheck", "%u", 1); +} + void igt_require_gem(int i915) { int err; @@ -150,6 +157,7 @@ void igt_require_gem(int i915) * sequences of batches. */ reset_device(i915); + restore_params(i915); restore_defaults(i915); err = 0; -- 2.27.0.rc0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Randomise spinner location to reduce relocation risk
Randomise the position of the spinner to reduce the number of relocations we might require. Signed-off-by: Chris Wilson --- lib/igt_dummyload.c | 33 ++--- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c index a733bd674..776e97baa 100644 --- a/lib/igt_dummyload.c +++ b/lib/igt_dummyload.c @@ -82,8 +82,21 @@ emit_recursive_batch(igt_spin_t *spin, unsigned int nengine; int fence_fd = -1; uint32_t *cs, *batch; + uint32_t addr; int i; + /* +* Pick a random location for our spinner et al. +* +* If available, the kernel will place our objects in our hinted +* locations and we will avoid having to perform any relocations. +* +* It must be a valid location (or else the kernel will be forced +* to select one for us) and so must be within the GTT and suitably +* aligned. For simplicity, stick to the low 32bit addresses. +*/ + addr = (random() % 1024 + 1024) << 12; + nengine = 0; if (opts->engine == ALL_ENGINES) { struct intel_execution_engine2 *engine; @@ -114,6 +127,9 @@ emit_recursive_batch(igt_spin_t *spin, execbuf->buffer_count++; cs = batch; + obj[BATCH].offset = addr; + addr += BATCH_SIZE; + if (opts->dependency) { igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN)); @@ -152,11 +168,13 @@ emit_recursive_batch(igt_spin_t *spin, spin->poll_handle, 0, 4096, PROT_READ | PROT_WRITE); + addr += 4096; /* guard page */ + obj[SCRATCH].offset = addr; + addr += 4096; igt_assert_eq(spin->poll[SPIN_POLL_START_IDX], 0); - /* batch is first */ - r->presumed_offset = 4096; + r->presumed_offset = obj[SCRATCH].offset; r->target_handle = obj[SCRATCH].handle; r->offset = sizeof(uint32_t) * 1; r->delta = sizeof(uint32_t) * SPIN_POLL_START_IDX; @@ -231,7 +249,7 @@ emit_recursive_batch(igt_spin_t *spin, spin->condition[0] = 0x; spin->condition[1] = 0x; - r->presumed_offset = 0; + r->presumed_offset = obj[BATCH].offset; r->target_handle = obj[BATCH].handle; r->offset = (cs + 2 - batch) * sizeof(*cs); r->read_domains = I915_GEM_DOMAIN_COMMAND; @@ -239,28 +257,29 @@ emit_recursive_batch(igt_spin_t *spin, *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | 2; *cs++ = MI_BATCH_BUFFER_END; - *cs++ = r->delta; + *cs++ = r->presumed_offset + r->delta; *cs++ = 0; } /* recurse */ r = &relocs[obj[BATCH].relocation_count++]; r->target_handle = obj[BATCH].handle; + r->presumed_offset = obj[BATCH].offset; r->offset = (cs + 1 - batch) * sizeof(*cs); r->read_domains = I915_GEM_DOMAIN_COMMAND; r->delta = LOOP_START_OFFSET; if (gen >= 8) { *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | 1; - *cs++ = r->delta; + *cs++ = r->presumed_offset + r->delta; *cs++ = 0; } else if (gen >= 6) { *cs++ = MI_BATCH_BUFFER_START | 1 << 8; - *cs++ = r->delta; + *cs++ = r->presumed_offset + r->delta; } else { *cs++ = MI_BATCH_BUFFER_START | 2 << 6; if (gen < 4) r->delta |= 1; - *cs = r->delta; + *cs = r->presumed_offset + r->delta; cs++; } obj[BATCH].relocs_ptr = to_user_pointer(relocs); -- 2.27.0.rc0 ___ 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/2] drm/i915: Reorder await_execution before await_request
== Series Details == Series: series starting with [1/2] drm/i915: Reorder await_execution before await_request URL : https://patchwork.freedesktop.org/series/77653/ State : success == Summary == CI Bug Log - changes from CI_DRM_8537_full -> Patchwork_17775_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17775_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#1436] / [i915#716]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk7/igt@gen9_exec_pa...@allowed-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-glk6/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#1119] / [i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk9/igt@kms_big...@linear-64bpp-rotate-0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-c-cursor-128x42-offscreen: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#54]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#1188]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl8/igt@kms_...@bpc-switch-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl8/igt@kms_...@bpc-switch-suspend.html * igt@kms_psr@psr2_suspend: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109441]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-iclb2/igt@kms_psr@psr2_suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-iclb4/igt@kms_psr@psr2_suspend.html * igt@kms_psr@suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl7/igt@kms_...@suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl3/igt@kms_...@suspend.html * igt@kms_setmode@basic: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#31]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-apl3/igt@kms_setm...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-apl6/igt@kms_setm...@basic.html Possible fixes * igt@i915_suspend@forcewake: - shard-apl: [DMESG-WARN][15] ([i915#180]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-apl6/igt@i915_susp...@forcewake.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-apl1/igt@i915_susp...@forcewake.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [FAIL][17] ([i915#1119] / [i915#118] / [i915#95]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html * {igt@kms_flip@flip-vs-suspend@c-dp1}: - shard-kbl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-kbl1/igt@kms_flip@flip-vs-susp...@c-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-kbl6/igt@kms_flip@flip-vs-susp...@c-dp1.html * {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-dp1}: - shard-kbl: [FAIL][21] ([i915#1928]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-kbl3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-dp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-kbl3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-dp1.html * {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1}: - shard-skl: [FAIL][23] ([i915#1928]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl2/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [FAIL][25] ([fdo#108145] / [i915#265]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl10/igt@km
[Intel-gfx] [CI 4/4] drm/i915/params: switch to device specific parameters
Start using device specific parameters instead of module parameters for most things. The module parameters become the immutable initial values for i915 parameters. The device specific parameters in i915->params start life as a copy of i915_modparams. Any later changes are only reflected in the debugfs. The stragglers are: * i915.force_probe and i915.modeset. Needed before dev_priv is available. This is fine because the parameters are read-only and never modified. * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and I915_STATE_WARN_ON would result in massive and ugly churn. This is handled by not exposing the parameter via debugfs, and leaving the parameter writable in sysfs. This may be fixed up in follow-up work. * i915.inject_probe_failure. Only makes sense in terms of the module, not the device. This is handled by not exposing the parameter via debugfs. Cc: Juha-Pekka Heikkilä Cc: Venkata Sandeep Dhanalakota Reviewed-by: Rodrigo Vivi Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_bios.c | 6 ++--- drivers/gpu/drm/i915/display/intel_crt.c | 4 ++-- drivers/gpu/drm/i915/display/intel_csr.c | 6 ++--- drivers/gpu/drm/i915/display/intel_display.c | 12 +- .../drm/i915/display/intel_display_debugfs.c | 2 +- .../drm/i915/display/intel_display_power.c| 14 ++-- drivers/gpu/drm/i915/display/intel_dp.c | 8 --- .../drm/i915/display/intel_dp_aux_backlight.c | 4 ++-- drivers/gpu/drm/i915/display/intel_fbc.c | 12 +- drivers/gpu/drm/i915/display/intel_lvds.c | 4 ++-- drivers/gpu/drm/i915/display/intel_opregion.c | 2 +- drivers/gpu/drm/i915/display/intel_panel.c| 4 ++-- drivers/gpu/drm/i915/display/intel_psr.c | 6 ++--- drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++-- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3 ++- drivers/gpu/drm/i915/gt/intel_reset.c | 6 ++--- .../drm/i915/gt/selftest_engine_heartbeat.c | 6 ++--- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 15 - .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +++- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20 - drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 22 ++- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_debugfs_params.c| 7 +- drivers/gpu/drm/i915/i915_drv.c | 9 ++-- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/i915_getparam.c | 2 +- drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- drivers/gpu/drm/i915/intel_gvt.c | 8 +++ drivers/gpu/drm/i915/intel_region_lmem.c | 6 ++--- drivers/gpu/drm/i915/intel_uncore.c | 8 +++ 30 files changed, 114 insertions(+), 101 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index 839124647202..ec8af2b7bf01 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -479,7 +479,7 @@ parse_sdvo_panel_data(struct drm_i915_private *dev_priv, struct drm_display_mode *panel_fixed_mode; int index; - index = i915_modparams.vbt_sdvo_panel_type; + index = dev_priv->params.vbt_sdvo_panel_type; if (index == -2) { drm_dbg_kms(&dev_priv->drm, "Ignore SDVO panel mode from BIOS VBT tables.\n"); @@ -829,9 +829,9 @@ parse_edp(struct drm_i915_private *dev_priv, const struct bdb_header *bdb) u8 vswing; /* Don't read from VBT if module parameter has valid value*/ - if (i915_modparams.edp_vswing) { + if (dev_priv->params.edp_vswing) { dev_priv->vbt.edp.low_vswing = - i915_modparams.edp_vswing == 1; + dev_priv->params.edp_vswing == 1; } else { vswing = (edp->edp_vswing_preemph >> (panel_type * 4)) & 0xF; dev_priv->vbt.edp.low_vswing = vswing == 0; diff --git a/drivers/gpu/drm/i915/display/intel_crt.c b/drivers/gpu/drm/i915/display/intel_crt.c index 2f5b9a4baafd..5b4510ce5693 100644 --- a/drivers/gpu/drm/i915/display/intel_crt.c +++ b/drivers/gpu/drm/i915/display/intel_crt.c @@ -833,7 +833,7 @@ intel_crt_detect(struct drm_connector *connector, connector->base.id, connector->name, force); - if (i915_modparams.load_detect_test) { + if (dev_priv->params.load_detect_test) { wakeref = intel_display_power_get(dev_priv, intel_encoder->power_domain); goto load_detect; @@ -889,7 +889,7 @@ intel_crt_detect(struct drm_connector *connector, else if (INTEL_GEN(dev_priv) < 4) status = intel_crt_load_detect(
[Intel-gfx] [CI 3/4] drm/i915/params: prevent changing module params runtime
Only support runtime changes through the debugfs. i915.verbose_state_checks remains an exception, and is not exposed via debugfs. This depends on IGT having been updated to use the debugfs for modifying the parameters. Cc: Juha-Pekka Heikkilä Cc: Venkata Sandeep Dhanalakota Reviewed-by: Juha-Pekka Heikkila Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_params.c | 38 +++--- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index a3dde770226d..ace44ad7e6df 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -40,6 +40,15 @@ struct i915_params i915_modparams __read_mostly = { #undef MEMBER }; +/* + * Note: As a rule, keep module parameter sysfs permissions read-only + * 0400. Runtime changes are only supported through i915 debugfs. + * + * For any exceptions requiring write access and runtime changes through module + * parameter sysfs, prevent debugfs file creation by setting the parameter's + * debugfs mode to 0. + */ + i915_param_named(modeset, int, 0400, "Use kernel modesetting [KMS] (0=disable, " "1=on, -1=force vga console preference [default])"); @@ -49,7 +58,7 @@ i915_param_named_unsafe(enable_dc, int, 0400, "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; " "3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)"); -i915_param_named_unsafe(enable_fbc, int, 0600, +i915_param_named_unsafe(enable_fbc, int, 0400, "Enable frame buffer compression for power savings " "(default: -1 (use per-chip default))"); @@ -57,7 +66,7 @@ i915_param_named_unsafe(lvds_channel_mode, int, 0400, "Specify LVDS channel mode " "(0=probe BIOS [default], 1=single-channel, 2=dual-channel)"); -i915_param_named_unsafe(panel_use_ssc, int, 0600, +i915_param_named_unsafe(panel_use_ssc, int, 0400, "Use Spread Spectrum Clock with panels [LVDS/eDP] " "(default: auto from VBT)"); @@ -65,25 +74,25 @@ i915_param_named_unsafe(vbt_sdvo_panel_type, int, 0400, "Override/Ignore selection of SDVO panel mode in the VBT " "(-2=ignore, -1=auto [default], index in VBT BIOS table)"); -i915_param_named_unsafe(reset, int, 0600, +i915_param_named_unsafe(reset, int, 0400, "Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default])"); i915_param_named_unsafe(vbt_firmware, charp, 0400, "Load VBT from specified file under /lib/firmware"); #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR) -i915_param_named(error_capture, bool, 0600, +i915_param_named(error_capture, bool, 0400, "Record the GPU state following a hang. " "This information in /sys/class/drm/card/error is vital for " "triaging and debugging hangs."); #endif -i915_param_named_unsafe(enable_hangcheck, bool, 0600, +i915_param_named_unsafe(enable_hangcheck, bool, 0400, "Periodically check GPU activity for detecting hangs. " "WARNING: Disabling this can cause system wide hangs. " "(default: true)"); -i915_param_named_unsafe(enable_psr, int, 0600, +i915_param_named_unsafe(enable_psr, int, 0400, "Enable PSR " "(0=disabled, 1=enabled) " "Default: -1 (use per-chip default)"); @@ -96,22 +105,22 @@ i915_param_named_unsafe(disable_power_well, int, 0400, "Disable display power wells when possible " "(-1=auto [default], 0=power wells always on, 1=power wells disabled when possible)"); -i915_param_named_unsafe(enable_ips, int, 0600, "Enable IPS (default: true)"); +i915_param_named_unsafe(enable_ips, int, 0400, "Enable IPS (default: true)"); -i915_param_named(fastboot, int, 0600, +i915_param_named(fastboot, int, 0400, "Try to skip unnecessary mode sets at boot time " "(0=disabled, 1=enabled) " "Default: -1 (use per-chip default)"); -i915_param_named_unsafe(load_detect_test, bool, 0600, +i915_param_named_unsafe(load_detect_test, bool, 0400, "Force-enable the VGA load detect code for testing (default:false). " "For developers only."); -i915_param_named_unsafe(force_reset_modeset_test, bool, 0600, +i915_param_named_unsafe(force_reset_modeset_test, bool, 0400, "Force a modeset during gpu reset for testing (default:false). " "For developers only."); -i915_param_named_unsafe(invert_brightness, int, 0600, +i915_param_named_unsafe(invert_brightness, int, 0400, "Invert backlight brightness " "(-1 force normal, 0 machine defaults, 1 force inversion), please " "report PCI device ID, subsystem vendor and subsystem device ID " @@ -121,10 +130,11 @@ i915_param_named_unsafe(invert_brightness, int, 0600, i915_param_named(disable_display, bool, 0400, "Disable display (default: false)"); -i915_param_named(mmio_debug, int, 0600, +i915_param_named(mmio_debug, int, 0400, "Enable the MMIO debug code for the first N failure
[Intel-gfx] [CI 2/4] drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions
fake_lmem_start does not need to be mutable via module param sysfs. It's only used during driver probe. Fixes: 1629224324b6 ("drm/i915/lmem: add the fake lmem region") Cc: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Rodrigo Vivi Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_params.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index add00ec1f787..a3dde770226d 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -173,7 +173,7 @@ i915_param_named(enable_gvt, bool, 0400, #endif #if IS_ENABLED(CONFIG_DRM_I915_UNSTABLE_FAKE_LMEM) -i915_param_named_unsafe(fake_lmem_start, ulong, 0600, +i915_param_named_unsafe(fake_lmem_start, ulong, 0400, "Fake LMEM start offset (default: 0)"); #endif -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915/params: don't expose inject_probe_failure in debugfs
The parameter only makes sense as a module parameter only. Fixes: c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs") Cc: Juha-Pekka Heikkilä Cc: Venkata Sandeep Dhanalakota Reviewed-by: Juha-Pekka Heikkila Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 45323732f099..4f21bfffbf0e 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -64,7 +64,7 @@ struct drm_printer; param(int, mmio_debug, -IS_ENABLED(CONFIG_DRM_I915_DEBUG_MMIO), 0600) \ param(int, edp_vswing, 0, 0400) \ param(unsigned int, reset, 3, 0600) \ - param(unsigned int, inject_probe_failure, 0, 0600) \ + param(unsigned int, inject_probe_failure, 0, 0) \ param(int, fastboot, -1, 0600) \ param(int, enable_dpcd_backlight, -1, 0600) \ param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \ -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve execute_cb struct packing (rev2)
== Series Details == Series: drm/i915: Improve execute_cb struct packing (rev2) URL : https://patchwork.freedesktop.org/series/77281/ State : success == Summary == CI Bug Log - changes from CI_DRM_8537 -> Patchwork_1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1/index.html Changes --- No changes found Participating hosts (50 -> 45) -- Additional (1): fi-kbl-7560u Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8537 -> Patchwork_1 CI-20190529: 20190529 CI_DRM_8537: 05a47cd761c49c3fa87648c30df0fd4d64b0b8c5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_1: c668d9c787ca7c6450cd4c7bb82a68f4c31ac439 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c668d9c787ca drm/i915: Improve execute_cb struct packing == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Improve execute_cb struct packing
Reduce the irq_work llist for attaching the callbacks to the signal for both smaller structs (two fewer pointers!) and simpler [debug] code: Function old new delta irq_execute_cb35 34 -1 __igt_breadcrumbs_smoketest 16841682 -2 i915_request_retire 20031996 -7 __i915_request_create 10471040 -7 __notify_execute_cb 135 126 -9 __i915_request_ctor 188 178 -10 __await_execution.part.constprop 451 440 -11 igt_wait_request 924 714-210 One minor artifact is that the order of cb exection is reversed. No current use cases are affected by that change. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_request.c | 23 ++- drivers/gpu/drm/i915/i915_request.h | 2 +- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index c282719ad3ac..877eaaccba81 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -42,7 +42,6 @@ #include "intel_pm.h" struct execute_cb { - struct list_head link; struct irq_work work; struct i915_sw_fence *fence; void (*hook)(struct i915_request *rq, struct dma_fence *signal); @@ -189,14 +188,14 @@ static void irq_execute_cb_hook(struct irq_work *wrk) static void __notify_execute_cb(struct i915_request *rq) { - struct execute_cb *cb; + struct execute_cb *cb, *cn; lockdep_assert_held(&rq->lock); - if (list_empty(&rq->execute_cb)) + if (llist_empty(&rq->execute_cb)) return; - list_for_each_entry(cb, &rq->execute_cb, link) + llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode) irq_work_queue(&cb->work); /* @@ -209,7 +208,7 @@ static void __notify_execute_cb(struct i915_request *rq) * preempt-to-idle cycle on the target engine, all the while the * master execute_cb may refire. */ - INIT_LIST_HEAD(&rq->execute_cb); + init_llist_head(&rq->execute_cb); } static inline void @@ -327,7 +326,7 @@ bool i915_request_retire(struct i915_request *rq) set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags); __notify_execute_cb(rq); } - GEM_BUG_ON(!list_empty(&rq->execute_cb)); + GEM_BUG_ON(!llist_empty(&rq->execute_cb)); spin_unlock_irq(&rq->lock); remove_from_client(rq); @@ -357,6 +356,12 @@ void i915_request_retire_upto(struct i915_request *rq) } while (i915_request_retire(tmp) && tmp != rq); } +static void __llist_add(struct llist_node *node, struct llist_head *head) +{ + node->next = head->first; + head->first = node; +} + static int __await_execution(struct i915_request *rq, struct i915_request *signal, @@ -395,7 +400,7 @@ __await_execution(struct i915_request *rq, i915_sw_fence_complete(cb->fence); kmem_cache_free(global.slab_execute_cbs, cb); } else { - list_add_tail(&cb->link, &signal->execute_cb); + __llist_add(&cb->work.llnode, &signal->execute_cb); } spin_unlock_irq(&signal->lock); @@ -704,7 +709,7 @@ static void __i915_request_ctor(void *arg) rq->file_priv = NULL; rq->capture_list = NULL; - INIT_LIST_HEAD(&rq->execute_cb); + init_llist_head(&rq->execute_cb); } struct i915_request * @@ -794,7 +799,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) rq->batch = NULL; GEM_BUG_ON(rq->file_priv); GEM_BUG_ON(rq->capture_list); - GEM_BUG_ON(!list_empty(&rq->execute_cb)); + GEM_BUG_ON(!llist_empty(&rq->execute_cb)); /* * Reserve space in the ring buffer for all the commands required to diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index 8ec7ee4dbadc..5d4709a3dace 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -214,7 +214,7 @@ struct i915_request { ktime_t emitted; } duration; }; - struct list_head execute_cb; + struct llist_head execute_cb; struct i915_sw_fence semaphore; /* -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Improve execute_cb struct packing
Chris Wilson writes: > Reduce the irq_work llist for attaching the callbacks to the signal for > both smaller structs (two fewer pointers!) and simpler [debug] code: > > Function old new delta > irq_execute_cb35 34 -1 > __igt_breadcrumbs_smoketest 16841682 -2 > i915_request_retire 20031996 -7 > __i915_request_create 10471040 -7 > __notify_execute_cb 135 126 -9 > __i915_request_ctor 188 178 -10 > __await_execution.part.constprop 451 440 -11 > igt_wait_request 924 714-210 > > One minor artifact is that the order of cb exection is reversed. No > current use cases are affected by that change. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_request.c | 18 +- > drivers/gpu/drm/i915/i915_request.h | 2 +- > 2 files changed, 10 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index c282719ad3ac..22df5b229aed 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -42,7 +42,6 @@ > #include "intel_pm.h" > > struct execute_cb { > - struct list_head link; > struct irq_work work; > struct i915_sw_fence *fence; > void (*hook)(struct i915_request *rq, struct dma_fence *signal); > @@ -189,14 +188,14 @@ static void irq_execute_cb_hook(struct irq_work *wrk) > > static void __notify_execute_cb(struct i915_request *rq) > { > - struct execute_cb *cb; > + struct execute_cb *cb, *cn; > > lockdep_assert_held(&rq->lock); > > - if (list_empty(&rq->execute_cb)) > + if (llist_empty(&rq->execute_cb)) > return; > > - list_for_each_entry(cb, &rq->execute_cb, link) > + llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode) > irq_work_queue(&cb->work); > > /* > @@ -209,7 +208,7 @@ static void __notify_execute_cb(struct i915_request *rq) >* preempt-to-idle cycle on the target engine, all the while the >* master execute_cb may refire. >*/ > - INIT_LIST_HEAD(&rq->execute_cb); > + rq->execute_cb.first = NULL; > } > > static inline void > @@ -327,7 +326,7 @@ bool i915_request_retire(struct i915_request *rq) > set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags); > __notify_execute_cb(rq); > } > - GEM_BUG_ON(!list_empty(&rq->execute_cb)); > + GEM_BUG_ON(!llist_empty(&rq->execute_cb)); > spin_unlock_irq(&rq->lock); > > remove_from_client(rq); > @@ -395,7 +394,8 @@ __await_execution(struct i915_request *rq, > i915_sw_fence_complete(cb->fence); > kmem_cache_free(global.slab_execute_cbs, cb); > } else { > - list_add_tail(&cb->link, &signal->execute_cb); > + cb->work.llnode.next = signal->execute_cb.first; > + signal->execute_cb.first = &cb->work.llnode; With this part giving more glues as of why can we do this, Reviewed-by: Mika Kuoppala > } > spin_unlock_irq(&signal->lock); > > @@ -704,7 +704,7 @@ static void __i915_request_ctor(void *arg) > rq->file_priv = NULL; > rq->capture_list = NULL; > > - INIT_LIST_HEAD(&rq->execute_cb); > + init_llist_head(&rq->execute_cb); > } > > struct i915_request * > @@ -794,7 +794,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) > rq->batch = NULL; > GEM_BUG_ON(rq->file_priv); > GEM_BUG_ON(rq->capture_list); > - GEM_BUG_ON(!list_empty(&rq->execute_cb)); > + GEM_BUG_ON(!llist_empty(&rq->execute_cb)); > > /* >* Reserve space in the ring buffer for all the commands required to > diff --git a/drivers/gpu/drm/i915/i915_request.h > b/drivers/gpu/drm/i915/i915_request.h > index 8ec7ee4dbadc..5d4709a3dace 100644 > --- a/drivers/gpu/drm/i915/i915_request.h > +++ b/drivers/gpu/drm/i915/i915_request.h > @@ -214,7 +214,7 @@ struct i915_request { > ktime_t emitted; > } duration; > }; > - struct list_head execute_cb; > + struct llist_head execute_cb; > struct i915_sw_fence semaphore; > > /* > -- > 2.20.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels
Chris Wilson writes: > If there are no internal levels and the user priority-shift is zero, we > can help the compiler eliminate some dead code: > > Function old new delta > start_timeslice 169 154 -15 > __execlists_submission_tasklet 46964659 -37 > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c > b/drivers/gpu/drm/i915/gt/intel_lrc.c > index de5be57ed6d2..3214a4ecc31a 100644 > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > @@ -446,6 +446,9 @@ static int queue_prio(const struct intel_engine_execlists > *execlists) >* we have to flip the index value to become priority. >*/ > p = to_priolist(rb); > + if (!I915_USER_PRIORITY_SHIFT) > + return p->priority; > + > return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used); > } > > -- > 2.20.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix wrong CDCLK adjustment changes
== Series Details == Series: drm/i915: Fix wrong CDCLK adjustment changes URL : https://patchwork.freedesktop.org/series/77654/ State : success == Summary == CI Bug Log - changes from CI_DRM_8537 -> Patchwork_17776 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/index.html Known issues Here are the changes found in Patchwork_17776 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [PASS][1] -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/fi-kbl-guc/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/fi-kbl-guc/igt@i915_pm_...@module-reload.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [TIMEOUT][3] ([i915#1288]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/fi-glk-dsi/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/fi-glk-dsi/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1288]: https://gitlab.freedesktop.org/drm/intel/issues/1288 Participating hosts (50 -> 44) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8537 -> Patchwork_17776 CI-20190529: 20190529 CI_DRM_8537: 05a47cd761c49c3fa87648c30df0fd4d64b0b8c5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17776: ac70e0df58bb143436d9fc1229484d87661b4638 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ac70e0df58bb drm/i915: Fix wrong CDCLK adjustment changes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors
On 2020-05-20 at 09:11:38 -0400, Sean Paul wrote: > On Mon, May 18, 2020 at 12:41 PM Ramalingam C wrote: > > > > On 2020-05-18 at 10:32:09 -0400, Sean Paul wrote: > > > On Fri, May 15, 2020 at 10:48 AM Ramalingam C > > > wrote: > > > > > > > > On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote: > > > > > From: Sean Paul > > > > > > > > > > Changes in v6: > > > > > -Rebased on -tip > > > > > -Disabled HDCP over MST on GEN12 > > > > > -Addressed Lyude's review comments in the > > > > > QUERY_STREAM_ENCRYPTION_STATUS patch > > > > > > > > Sean, > > > > > > > > What is the test setup you have used? > > > > > > > > > > Hi Ram, > > > Thanks for the feedback. To be completely honest it's really > > > frustrating that I'm just now getting questions and review feedback > > > (which I've been begging for on IRC) on this review that could have > > > been addressed ~5 months ago. It's super disruptive to have to keep > > > switching back to this after a long hiatus and many i915 refactors > > > complicating my rebases. > > Hi Sean, > > > > As a developer I really feel bad for the delay happened in review. > > I couldn't spend required time for understanding MST part hence I > > couldn't review. > > > > Just for this series now I have started preparing myself on these topics, > > hence started reviewing the series. > > > > If you are still interested to work on this, I can commit for regular > > reviews. > > > > Thanks Ram. I'm still incentivized to get this in. Once you have had a > chance to look over the whole series, I'll revise again. Sean I have already gone through the whole series when I commented before. Most of the prepation patches are looking good. I am having questions on MST HDCP enabling sequence and what is the decision on streams to be encrypted on the MST HDCP link (all/selective) etc. Which were posted on https://patchwork.freedesktop.org/patch/363798/?series=70393&rev=6 And also, could you please explain the level of testing this series has gone through? -Ram > > Sean > > > > > Thanks, > > Ram. > > > > > > If no one wants this patchset, that's fine, please just let me know so > > > I don't waste any more time. If Intel is interested, could we please > > > stop the review trickle and lay out exactly what needs to be done to > > > get this landed? > > > > > > Sean > > > > > > > > > > I am afraid our CI dont have the coverage for MST capability yet to > > > > provide > > > > the functional status of the code. > > > > > > > > -Ram. > > > > > > > > > > Sean Paul (16): > > > > > drm/i915: Fix sha_text population code > > > > > drm/i915: Clear the repeater bit on HDCP disable > > > > > drm/i915: WARN if HDCP signalling is enabled upon disable > > > > > drm/i915: Intercept Aksv writes in the aux hooks > > > > > drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP > > > > > signalling > > > > > drm/i915: Factor out hdcp->value assignments > > > > > drm/i915: Protect workers against disappearing connectors > > > > > drm/i915: Don't fully disable HDCP on a port if multiple pipes are > > > > > using it > > > > > drm/i915: Support DP MST in enc_to_dig_port() function > > > > > drm/i915: Use ddi_update_pipe in intel_dp_mst > > > > > drm/i915: Factor out HDCP shim functions from dp for use by dp_mst > > > > > drm/i915: Plumb port through hdcp init > > > > > drm/i915: Add connector to hdcp_shim->check_link() > > > > > drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband > > > > > message > > > > > drm/i915: Print HDCP version info for all connectors > > > > > drm/i915: Add HDCP 1.4 support for MST connectors > > > > > > > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 142 > > > > > drivers/gpu/drm/i915/Makefile | 1 + > > > > > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > > > > > drivers/gpu/drm/i915/display/intel_ddi.h | 2 + > > > > > .../drm/i915/display/intel_display_debugfs.c | 21 +- > > > > > .../drm/i915/display/intel_display_types.h| 30 +- > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 654 +-- > > > > > drivers/gpu/drm/i915/display/intel_dp.h | 9 + > > > > > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 743 > > > > > ++ > > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + > > > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 217 +++-- > > > > > drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- > > > > > drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +- > > > > > .../drm/selftests/test-drm_dp_mst_helper.c| 17 + > > > > > include/drm/drm_dp_helper.h | 3 + > > > > > include/drm/drm_dp_mst_helper.h | 44 ++ > > > > > include/drm/drm_hdcp.h| 3 + > > > > > 17 files changed, 1235 insertions(+), 726 deletions(-) > > > > > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c > > > > > > > > > > -- > > > > > Sean P
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Reorder await_execution before await_request
== Series Details == Series: series starting with [1/2] drm/i915: Reorder await_execution before await_request URL : https://patchwork.freedesktop.org/series/77653/ State : success == Summary == CI Bug Log - changes from CI_DRM_8537 -> Patchwork_17775 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/index.html Known issues Here are the changes found in Patchwork_17775 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-7500u: [PASS][1] -> [DMESG-FAIL][2] ([i915#165]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 Participating hosts (50 -> 45) -- Additional (1): fi-kbl-7560u Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8537 -> Patchwork_17775 CI-20190529: 20190529 CI_DRM_8537: 05a47cd761c49c3fa87648c30df0fd4d64b0b8c5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17775: 95d84329d1e9e74b00a4372c6b5b24a4d5a58d0c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 95d84329d1e9 drm/i915/gt: Do not schedule normal requests immediately along virtual acc962187d69 drm/i915: Reorder await_execution before await_request == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 02/17] dma-fence: basic lockdep annotations
Op 12-05-2020 om 10:59 schreef Daniel Vetter: > Design is similar to the lockdep annotations for workers, but with > some twists: > > - We use a read-lock for the execution/worker/completion side, so that > this explicit annotation can be more liberally sprinkled around. > With read locks lockdep isn't going to complain if the read-side > isn't nested the same way under all circumstances, so ABBA deadlocks > are ok. Which they are, since this is an annotation only. > > - We're using non-recursive lockdep read lock mode, since in recursive > read lock mode lockdep does not catch read side hazards. And we > _very_ much want read side hazards to be caught. For full details of > this limitation see > > commit e91498589746065e3ae95d9a00b068e525eec34f > Author: Peter Zijlstra > Date: Wed Aug 23 13:13:11 2017 +0200 > > locking/lockdep/selftests: Add mixed read-write ABBA tests > > - To allow nesting of the read-side explicit annotations we explicitly > keep track of the nesting. lock_is_held() allows us to do that. > > - The wait-side annotation is a write lock, and entirely done within > dma_fence_wait() for everyone by default. > > - To be able to freely annotate helper functions I want to make it ok > to call dma_fence_begin/end_signalling from soft/hardirq context. > First attempt was using the hardirq locking context for the write > side in lockdep, but this forces all normal spinlocks nested within > dma_fence_begin/end_signalling to be spinlocks. That bollocks. > > The approach now is to simple check in_atomic(), and for these cases > entirely rely on the might_sleep() check in dma_fence_wait(). That > will catch any wrong nesting against spinlocks from soft/hardirq > contexts. > > The idea here is that every code path that's critical for eventually > signalling a dma_fence should be annotated with > dma_fence_begin/end_signalling. The annotation ideally starts right > after a dma_fence is published (added to a dma_resv, exposed as a > sync_file fd, attached to a drm_syncobj fd, or anything else that > makes the dma_fence visible to other kernel threads), up to and > including the dma_fence_wait(). Examples are irq handlers, the > scheduler rt threads, the tail of execbuf (after the corresponding > fences are visible), any workers that end up signalling dma_fences and > really anything else. Not annotated should be code paths that only > complete fences opportunistically as the gpu progresses, like e.g. > shrinker/eviction code. > > The main class of deadlocks this is supposed to catch are: > > Thread A: > > mutex_lock(A); > mutex_unlock(A); > > dma_fence_signal(); > > Thread B: > > mutex_lock(A); > dma_fence_wait(); > mutex_unlock(A); > > Thread B is blocked on A signalling the fence, but A never gets around > to that because it cannot acquire the lock A. > > Note that dma_fence_wait() is allowed to be nested within > dma_fence_begin/end_signalling sections. To allow this to happen the > read lock needs to be upgraded to a write lock, which means that any > other lock is acquired between the dma_fence_begin_signalling() call and > the call to dma_fence_wait(), and still held, this will result in an > immediate lockdep complaint. The only other option would be to not > annotate such calls, defeating the point. Therefore these annotations > cannot be sprinkled over the code entirely mindless to avoid false > positives. > > v2: handle soft/hardirq ctx better against write side and dont forget > EXPORT_SYMBOL, drivers can't use this otherwise. > > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian König > Signed-off-by: Daniel Vetter > --- This is something we definitely need, all drivers need to follow the same rules, in order to put some light in the darkness. :) Reviewed-by: Maarten Lankhorst > drivers/dma-buf/dma-fence.c | 53 + > include/linux/dma-fence.h | 12 + > 2 files changed, 65 insertions(+) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 6802125349fb..d5c0fd2efc70 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num) > } > EXPORT_SYMBOL(dma_fence_context_alloc); > > +#ifdef CONFIG_LOCKDEP > +struct lockdep_map dma_fence_lockdep_map = { > + .name = "dma_fence_map" > +}; > + > +bool dma_fence_begin_signalling(void) > +{ > + /* explicitly nesting ... */ > + if (lock_is_held_type(&dma_fence_lockdep_map, 1)) > + return true; > + > + /* rely on might_sleep check for soft/hardirq locks */ > + if (in_atomic()) > + return true; > + > + /* ... and non-recursive readlock */ > + lock_acquire(&dma_fence_lockdep
[Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes
Previous patch didn't take into account all pipes but only those in state, which could cause wrong CDCLK conclcusions and calculations. Also there was a severe issue with min_cdclk being assigned to 0 every compare cycle. Too bad this was found by me only after merge. This could be also causing the issues in test, however not clear - anyway marking this as fixing the "Adjust CDCLK accordingly to our DBuf bw needs". Signed-off-by: Stanislav Lisovskiy Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs") --- drivers/gpu/drm/i915/display/intel_bw.c | 51 drivers/gpu/drm/i915/display/intel_cdclk.c | 19 +--- drivers/gpu/drm/i915/display/intel_display.c | 26 +- 3 files changed, 53 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c index a79bd7aeb03b..8096138abecc 100644 --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state) struct intel_crtc *crtc; int max_bw = 0; int slice_id; + enum pipe pipe; int i; for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) { @@ -447,7 +448,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state) if (IS_ERR(new_bw_state)) return PTR_ERR(new_bw_state); - crtc_bw = &new_bw_state->dbuf_bw[crtc->pipe]; + old_bw_state = intel_atomic_get_old_bw_state(state); + + crtc_bw = &new_bw_state->dbuf_bw[pipe]; memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw)); @@ -478,6 +481,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state) for_each_dbuf_slice_in_mask(slice_id, dbuf_mask) crtc_bw->used_bw[slice_id] += data_rate; } + } + + if (!old_bw_state) + return 0; + + for_each_pipe(dev_priv, pipe) { + struct intel_dbuf_bw *crtc_bw; + + crtc_bw = &new_bw_state->dbuf_bw[pipe]; for_each_dbuf_slice(slice_id) { /* @@ -490,14 +502,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state) */ max_bw += crtc_bw->used_bw[slice_id]; } - - new_bw_state->min_cdclk = max_bw / 64; - - old_bw_state = intel_atomic_get_old_bw_state(state); } - if (!old_bw_state) - return 0; + new_bw_state->min_cdclk = max_bw / 64; if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) { int ret = intel_atomic_lock_global_state(&new_bw_state->base); @@ -511,34 +518,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state) int intel_bw_calc_min_cdclk(struct intel_atomic_state *state) { - int i; + struct drm_i915_private *dev_priv = to_i915(state->base.dev); + struct intel_bw_state *new_bw_state = NULL; + struct intel_bw_state *old_bw_state = NULL; const struct intel_crtc_state *crtc_state; struct intel_crtc *crtc; int min_cdclk = 0; - struct intel_bw_state *new_bw_state = NULL; - struct intel_bw_state *old_bw_state = NULL; + enum pipe pipe; + int i; for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) { - struct intel_cdclk_state *cdclk_state; - new_bw_state = intel_atomic_get_bw_state(state); if (IS_ERR(new_bw_state)) return PTR_ERR(new_bw_state); - cdclk_state = intel_atomic_get_cdclk_state(state); - if (IS_ERR(cdclk_state)) - return PTR_ERR(cdclk_state); - - min_cdclk = max(cdclk_state->min_cdclk[crtc->pipe], min_cdclk); - - new_bw_state->min_cdclk = min_cdclk; - old_bw_state = intel_atomic_get_old_bw_state(state); } if (!old_bw_state) return 0; + for_each_pipe(dev_priv, pipe) { + struct intel_cdclk_state *cdclk_state; + + cdclk_state = intel_atomic_get_new_cdclk_state(state); + if (!cdclk_state) + return 0; + + min_cdclk = max(cdclk_state->min_cdclk[pipe], min_cdclk); + } + + new_bw_state->min_cdclk = min_cdclk; + if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) { int ret = intel_atomic_lock_global_state(&new_bw_state->base); diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index f9b0fc7317de..08468b121d02 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -2084,9 +2084,12 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *
Re: [Intel-gfx] [PATCH] drm/i915/gt: Force the GT reset on shutdown
Chris Wilson writes: > Before we return control to the system, and letting it reuse all the > pages being accessed by HW, we must disable the HW. At the moment, we > dare not reset the GPU if it will clobber the display, but once we know > the display has been disabled, we can proceed with the reset as we > shutdown the module. We know the next user must reinitialise the HW for > their purpose. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/489 > Signed-off-by: Chris Wilson > Cc: sta...@kernel.org Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_gt.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > index f069551e412f..ebc29b6ee86c 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > @@ -616,6 +616,11 @@ void intel_gt_driver_unregister(struct intel_gt *gt) > void intel_gt_driver_release(struct intel_gt *gt) > { > struct i915_address_space *vm; > + intel_wakeref_t wakeref; > + > + /* Scrub all HW state upon release */ > + with_intel_runtime_pm(gt->uncore->rpm, wakeref) > + __intel_gt_reset(gt, ALL_ENGINES); > > vm = fetch_and_zero(>->vm); > if (vm) /* FIXME being called twice on error paths :( */ > -- > 2.20.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual
When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon the virtual engine, but along the physical engine in use, will then see that it is due to be submitted to the same engine and take a shortcut (and be queued without waiting for the completion fence). However, the virtual request may be preempted (either by higher priority users, or by timeslicing) and removed from the physical engine to be migrated over to one of its siblings. The dependent normal request however is oblivious to the removal of the virtual request and remains queued to execute on HW, believing that once it reaches the head of its queue all of its predecessors will have completed executing! v2: Beware restriction of signal->execution_mask prior to submission. Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Testcase: igt/gem_exec_balancer/sliced Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: # v5.3+ --- drivers/gpu/drm/i915/i915_request.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 33bbad623e02..0b07ccc7e9bc 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq, return 0; } +static int +await_request_submit(struct i915_request *to, struct i915_request *from) +{ + /* +* If we are waiting on a virtual engine, then it may be +* constrained to execute on a single engine *prior* to submission. +* When it is submitted, it will be first submitted to the virtual +* engine and then passed to the physical engine. We cannot allow +* the waiter to be submitted immediately to the physical engine +* as it may then bypass the virtual request. +*/ + if (to->engine == READ_ONCE(from->engine)) + return i915_sw_fence_await_sw_fence_gfp(&to->submit, + &from->submit, + I915_FENCE_GFP); + else + return __i915_request_await_execution(to, from, NULL); +} + static int i915_request_await_request(struct i915_request *to, struct i915_request *from) { @@ -1258,10 +1277,8 @@ i915_request_await_request(struct i915_request *to, struct i915_request *from) return ret; } - if (to->engine == READ_ONCE(from->engine)) - ret = i915_sw_fence_await_sw_fence_gfp(&to->submit, - &from->submit, - I915_FENCE_GFP); + if (is_power_of_2(to->execution_mask | READ_ONCE(from->execution_mask))) + ret = await_request_submit(to, from); else ret = emit_semaphore_wait(to, from, I915_FENCE_GFP); if (ret < 0) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Reorder await_execution before await_request
Reorder the code so that we can reuse the await_execution from a special case in await_request in the next patch. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 264 ++-- 1 file changed, 132 insertions(+), 132 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index c282719ad3ac..33bbad623e02 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1053,37 +1053,91 @@ emit_semaphore_wait(struct i915_request *to, I915_FENCE_GFP); } +static bool intel_timeline_sync_has_start(struct intel_timeline *tl, + struct dma_fence *fence) +{ + return __intel_timeline_sync_is_later(tl, + fence->context, + fence->seqno - 1); +} + +static int intel_timeline_sync_set_start(struct intel_timeline *tl, +const struct dma_fence *fence) +{ + return __intel_timeline_sync_set(tl, fence->context, fence->seqno - 1); +} + static int -i915_request_await_request(struct i915_request *to, struct i915_request *from) +__i915_request_await_execution(struct i915_request *to, + struct i915_request *from, + void (*hook)(struct i915_request *rq, + struct dma_fence *signal)) { - int ret; + int err; - GEM_BUG_ON(to == from); - GEM_BUG_ON(to->timeline == from->timeline); + GEM_BUG_ON(intel_context_is_barrier(from->context)); - if (i915_request_completed(from)) { - i915_sw_fence_set_error_once(&to->submit, from->fence.error); + /* Submit both requests at the same time */ + err = __await_execution(to, from, hook, I915_FENCE_GFP); + if (err) + return err; + + /* Squash repeated depenendices to the same timelines */ + if (intel_timeline_sync_has_start(i915_request_timeline(to), + &from->fence)) return 0; + + /* +* Wait until the start of this request. +* +* The execution cb fires when we submit the request to HW. But in +* many cases this may be long before the request itself is ready to +* run (consider that we submit 2 requests for the same context, where +* the request of interest is behind an indefinite spinner). So we hook +* up to both to reduce our queues and keep the execution lag minimised +* in the worst case, though we hope that the await_start is elided. +*/ + err = i915_request_await_start(to, from); + if (err < 0) + return err; + + /* +* Ensure both start together [after all semaphores in signal] +* +* Now that we are queued to the HW at roughly the same time (thanks +* to the execute cb) and are ready to run at roughly the same time +* (thanks to the await start), our signaler may still be indefinitely +* delayed by waiting on a semaphore from a remote engine. If our +* signaler depends on a semaphore, so indirectly do we, and we do not +* want to start our payload until our signaler also starts theirs. +* So we wait. +* +* However, there is also a second condition for which we need to wait +* for the precise start of the signaler. Consider that the signaler +* was submitted in a chain of requests following another context +* (with just an ordinary intra-engine fence dependency between the +* two). In this case the signaler is queued to HW, but not for +* immediate execution, and so we must wait until it reaches the +* active slot. +*/ + if (intel_engine_has_semaphores(to->engine) && + !i915_request_has_initial_breadcrumb(to)) { + err = __emit_semaphore_wait(to, from, from->fence.seqno - 1); + if (err < 0) + return err; } + /* Couple the dependency tree for PI on this exposed to->fence */ if (to->engine->schedule) { - ret = i915_sched_node_add_dependency(&to->sched, + err = i915_sched_node_add_dependency(&to->sched, &from->sched, -I915_DEPENDENCY_EXTERNAL); - if (ret < 0) - return ret; +I915_DEPENDENCY_WEAK); + if (err < 0) + return err; } - if (to->engine == from->engine) - ret = i915_sw_fence_await_sw_fence_gfp(&to->submit, - &from->submit, -
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Do not schedule normal requests immediately along virtual
On 25/05/2020 21:28, Chris Wilson wrote: When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon the virtual engine, but along the physical engine in use, will then see that it is due to be submitted to the same engine and take a shortcut (and be queued without waiting for the completion fence). However, the virtual request may be preempted (either by higher priority users, or by timeslicing) and removed from the physical engine to be migrated over to one of its siblings. The dependent normal request however is oblivious to the removal of the virtual request and remains queued to execute on HW, believing that once it reaches the head of its queue all of its predecessors will have completed executing! Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Testcase: igt/gem_exec_balancer/sliced Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: # v5.3+ --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index c282719ad3ac..51588209bddd 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1074,7 +1074,7 @@ i915_request_await_request(struct i915_request *to, struct i915_request *from) return ret; } - if (to->engine == from->engine) + if (is_power_of_2(to->execution_mask | READ_ONCE(from->execution_mask))) ret = i915_sw_fence_await_sw_fence_gfp(&to->submit, &from->submit, I915_FENCE_GFP); Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx