[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details == Series: series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission URL : https://patchwork.freedesktop.org/series/74363/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v3,1/3] drm/i915/display: Deactive FBC in fastsets when disabled by parameter (rev2)
== Series Details == Series: series starting with [v3,1/3] drm/i915/display: Deactive FBC in fastsets when disabled by parameter (rev2) URL : https://patchwork.freedesktop.org/series/73618/ State : failure == Summary == Applying: drm/i915/display: Deactive FBC in fastsets when disabled by parameter Applying: drm/i915/display: Do not write in removed FBC fence registers Applying: drm/i915/display/fbc: Make fences a nice-to-have for GEN9+ error: git diff header lacks filename information when removing 1 leading pathname component (line 2) error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0003 drm/i915/display/fbc: Make fences a nice-to-have for GEN9+ 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] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details == Series: series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission URL : https://patchwork.freedesktop.org/series/74363/ State : success == Summary == CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16853 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16853/index.html New tests - New tests have been introduced between CI_DRM_8074 and Patchwork_16853: ### New IGT tests (1) ### * igt@i915_selftest@live@ring_submission: - Statuses : 39 pass(s) - Exec time: [0.45, 2.49] s Known issues Here are the changes found in Patchwork_16853 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#1250]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8074/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16853/fi-bsw-nick/igt@debugfs_test@read_all_entries.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8074/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16853/fi-tgl-y/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][5] ([CI#94]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8074/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16853/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@prime_vgem@basic-gtt: - fi-tgl-y: [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8074/fi-tgl-y/igt@prime_v...@basic-gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16853/fi-tgl-y/igt@prime_v...@basic-gtt.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (50 -> 41) -- Additional (1): fi-kbl-7560u Missing(10): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-ivb-3770 fi-cfl-8109u fi-skl-lmem fi-byt-clapper fi-bdw-samus fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8074 -> Patchwork_16853 CI-20190529: 20190529 CI_DRM_8074: 0dd63259839ca847514d749219635f311015 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5495: 22df72de8affcec22d9f354bb6148d77f60cc580 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16853: 1283df1a17508efda4992459f2977e293884dfc7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1283df1a1750 drm/i915/gen7: Clear all EU/L3 residual contexts c0358b495597 drm/i915: Add mechanism to submit a context WA on ring submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16853/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [v4,1/2] drm/edid: Name the detailed monitor range flags
== Series Details == Series: series starting with [v4,1/2] drm/edid: Name the detailed monitor range flags URL : https://patchwork.freedesktop.org/series/74364/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Polish CHV CGM CSC loading
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Only load the CGM CSC based on the cgm_mode bit like we
do with the gamma/degamma LUTs. And make the function
naming and arguments consistent as well.
TODO: the code to convert the coefficients look totally
bogus. IIRC CHV uses two's complement format but the code
certainly doesn't generate that, so probably negative
coefficients are totally busted.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 69 +++---
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 98aefeebda28..444980fdeda6 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -348,48 +348,43 @@ static void icl_load_csc_matrix(const struct
intel_crtc_state *crtc_state)
crtc_state->csc_mode);
}
-/*
- * Set up the pipe CSC unit on CherryView.
- */
-static void cherryview_load_csc_matrix(const struct intel_crtc_state
*crtc_state)
+static void chv_load_cgm_csc(struct intel_crtc *crtc,
+const struct drm_property_blob *blob)
Nitpick: Spacing?
{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_color_ctm *ctm = blob->data;
enum pipe pipe = crtc->pipe;
+ u16 coeffs[9];
+ int i;
- if (crtc_state->hw.ctm) {
- const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
- u16 coeffs[9] = {};
- int i;
+ for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
+ u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
- for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
- u64 abs_coeff =
- ((1ULL << 63) - 1) & ctm->matrix[i];
+ /* Round coefficient. */
+ abs_coeff += 1 << (32 - 13);
+ /* Clamp to hardware limits. */
+ abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
- /* Round coefficient. */
- abs_coeff += 1 << (32 - 13);
- /* Clamp to hardware limits. */
- abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
+ coeffs[i] = 0;
- /* Write coefficients in S3.12 format. */
- if (ctm->matrix[i] & (1ULL << 63))
- coeffs[i] = 1 << 15;
- coeffs[i] |= ((abs_coeff >> 32) & 7) << 12;
- coeffs[i] |= (abs_coeff >> 20) & 0xfff;
- }
+ /* Write coefficients in S3.12 format. */
+ if (ctm->matrix[i] & (1ULL << 63))
+ coeffs[i] |= 1 << 15;
- intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF01(pipe),
- coeffs[1] << 16 | coeffs[0]);
- intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF23(pipe),
- coeffs[3] << 16 | coeffs[2]);
- intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF45(pipe),
- coeffs[5] << 16 | coeffs[4]);
- intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF67(pipe),
- coeffs[7] << 16 | coeffs[6]);
- intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF8(pipe), coeffs[8]);
+ coeffs[i] |= ((abs_coeff >> 32) & 7) << 12;
+ coeffs[i] |= (abs_coeff >> 20) & 0xfff;
}
- intel_de_write(dev_priv, CGM_PIPE_MODE(pipe), crtc_state->cgm_mode);
+ intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF01(pipe),
+ coeffs[1] << 16 | coeffs[0]);
+ intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF23(pipe),
+ coeffs[3] << 16 | coeffs[2]);
+ intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF45(pipe),
+ coeffs[5] << 16 | coeffs[4]);
+ intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF67(pipe),
+ coeffs[7] << 16 | coeffs[6]);
+ intel_de_write(dev_priv, CGM_PIPE_CSC_COEFF8(pipe),
+ coeffs[8]);
}
static u32 i9xx_lut_8(const struct drm_color_lut *color)
@@ -1020,10 +1015,13 @@ static void chv_load_cgm_gamma(struct intel_crtc *crtc,
static void chv_load_luts(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_property_blob *degamma_lut =
crtc_state->hw.degamma_lut;
+ const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+ const struct drm_property_blob *ctm = crtc_state->hw.ctm;
- cherryview_load_csc_matrix(crtc_state);
+ if (crtc_state->cgm_mode & CGM_PI
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/edid: Name the detailed monitor range flags
== Series Details == Series: series starting with [v4,1/2] drm/edid: Name the detailed monitor range flags URL : https://patchwork.freedesktop.org/series/74364/ State : success == Summary == CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16855 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16855/index.html Known issues Here are the changes found in Patchwork_16855 that come from known issues: ### IGT changes ### Issues hit * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8074/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16855/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@prime_vgem@basic-gtt: - fi-tgl-y: [DMESG-WARN][3] ([CI#94] / [i915#402]) -> [PASS][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8074/fi-tgl-y/igt@prime_v...@basic-gtt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16855/fi-tgl-y/igt@prime_v...@basic-gtt.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][5] ([fdo#111096] / [i915#323]) -> [FAIL][6] ([fdo#111407]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8074/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16855/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (50 -> 44) -- Additional (1): fi-kbl-7560u Missing(7): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8074 -> Patchwork_16855 CI-20190529: 20190529 CI_DRM_8074: 0dd63259839ca847514d749219635f311015 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5495: 22df72de8affcec22d9f354bb6148d77f60cc580 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16855: 1a34fea554d6ab46b313d6cef1670a292b72e616 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1a34fea554d6 drm/dp: Add function to parse EDID descriptors for adaptive sync limits 50c133bbb0b6 drm/edid: Name the detailed monitor range flags == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16855/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: properly sanity check batch_start_offset (rev2)
Quoting Patchwork (2020-03-06 04:28:26) > == Series Details == > > Series: drm/i915: properly sanity check batch_start_offset (rev2) > URL : https://patchwork.freedesktop.org/series/74287/ > State : success Apologies, SPF vs intel.com again. So, I think the _end variant should be for the inclusive endpoint which is the less common form (there's only 3 where we use U32_MAX and the other 24 all use size or total, i.e. exclusive). So I would convert those 3 to use _end or _excl, and convert the main overflow check to use >= -Chris ___ 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 [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details == Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev URL : https://patchwork.freedesktop.org/series/74298/ State : success == Summary == CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16831_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16831_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl4/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +23 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk9/igt@gem_exec_whis...@basic-queues-priority.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-glk2/igt@gem_exec_whis...@basic-queues-priority.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#644]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-kbl2/igt@gem_pp...@flink-and-close-vma-leak.html - shard-skl: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl5/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-skl7/igt@gem_pp...@flink-and-close-vma-leak.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#49]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - sh
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Assert requests within a context are submitted in order
Chris Wilson writes:
> Check the flow of requests into the hardware to verify that are
> submitted in order along their timeline.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4
> drivers/gpu/drm/i915/i915_request.c | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 16a023ac4604..13941d1c0a4a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1622,6 +1622,7 @@ static bool can_merge_rq(const struct i915_request
> *prev,
> if (!can_merge_ctx(prev->context, next->context))
> return false;
>
> + GEM_BUG_ON(i915_seqno_passed(prev->fence.seqno, next->fence.seqno));
> return true;
> }
>
> @@ -2142,6 +2143,9 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> GEM_BUG_ON(last &&
> !can_merge_ctx(last->context,
> rq->context));
> + GEM_BUG_ON(last &&
> +i915_seqno_passed(last->fence.seqno,
> + rq->fence.seqno));
>
> submit = true;
> last = rq;
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index ca5361eb1f0b..35147df79655 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -737,6 +737,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
> RCU_INIT_POINTER(rq->timeline, tl);
> RCU_INIT_POINTER(rq->hwsp_cacheline, tl->hwsp_cacheline);
> rq->hwsp_seqno = tl->hwsp_seqno;
> + GEM_BUG_ON(i915_request_completed(rq));
>
> rq->rcustate = get_state_synchronize_rcu(); /* acts as smp_mb() */
>
> @@ -1284,6 +1285,9 @@ __i915_request_add_to_timeline(struct i915_request *rq)
> prev = to_request(__i915_active_fence_set(&timeline->last_request,
> &rq->fence));
> if (prev && !i915_request_completed(prev)) {
> + GEM_BUG_ON(i915_seqno_passed(prev->fence.seqno,
> + rq->fence.seqno));
> +
> if (is_power_of_2(prev->engine->mask | rq->engine->mask))
> i915_sw_fence_await_sw_fence(&rq->submit,
>&prev->submit,
> --
> 2.25.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 v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors
On Thu, 05 Mar 2020, Rajat Jain wrote: > On Thu, Mar 5, 2020 at 1:41 AM Jani Nikula > wrote: >> >> On Wed, 04 Mar 2020, Rajat Jain wrote: >> 1) See if we can postpone creating and attaching properties to connector >> ->late_register hook. (I didn't have the time to look into it yet, at >> all.) > > Apparently not. The drm core doesn't like to add properties in > late_register() callback. I just tried it and get this warning: I kind of had a feeling this would be the case, thanks for checking. >> 2) Provide a way to populate connector->acpi_device_id and >> connector->acpi_handle on a per-connector basis. At least the device id >> remains constant for the lifetime of the drm_device > > Are you confirming that the connector->acpi_device_id remains constant > for the lifetime of the drm_device, as calculated in > intel_acpi_device_id_update()? Even in the face of external displays > (monitors) being connected and disconnected during the lifetime of the > system? If so, then I think we can have a solution. First I thought so. Alas it does not hold for DP MST, where you can have connectors added and removed dynamically. I think we could ensure they stay the same for all other connectors though. I'm pretty sure this is already the case; they get added/removed after all others. Another thought, from the ACPI perspective, I'm not sure the dynamically added/removed DP MST connectors should even have acpi handles. But again, tying all this together with ACPI stuff is not something I am an expert on. >> (why do we keep >> updating it at every resume?!) but can we be sure ->acpi_handle does >> too? (I don't really know my way around ACPI.) > > I don't understand why this was being updated on every resume in that > case (this existed even before my patchset). I believe we do not need > it. Yes, the ->acpi_handle will not change if the ->acpi_device_id > does not change. I believe the way forward should then be to populate > connector->acpi_device_id and connector->acpi_handle ONE TIME at the > time of connector init (and not update it on every resume). Does this > sound ok? If a DP MST connector gets removed, should the other ACPI display indexes after that shift, or remain the same? I really don't know. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gem: Limit struct_mutex to eb_reserve
Chris Wilson writes:
> We only need to serialise the multiple pinning during the eb_reserve
> phase. Ideally this would be using the vm->mutex as an outer lock, or
> using a composite global mutex (ww_mutex), but at the moment we are
> using struct_mutex for the group.
>
> Fixes: 003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during
> execbuf ioctl")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
from other thread,
Reviewed-by: Mika Kuoppala
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 51 ---
> drivers/gpu/drm/i915/i915_drv.h | 6 ---
> 2 files changed, 20 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 7bb27f382af7..faa5b5c99a9a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -610,7 +610,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
> struct list_head last;
> struct eb_vma *ev;
> unsigned int i, pass;
> - int err;
> + int err = 0;
>
> /*
>* Attempt to pin all of the buffers into the GTT.
> @@ -626,8 +626,10 @@ static int eb_reserve(struct i915_execbuffer *eb)
>* room for the earlier objects *unless* we need to defragment.
>*/
>
> + if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
> + return -EINTR;
> +
> pass = 0;
> - err = 0;
> do {
> list_for_each_entry(ev, &eb->unbound, bind_link) {
> err = eb_reserve_vma(eb, ev, pin_flags);
> @@ -635,7 +637,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
> break;
> }
> if (!(err == -ENOSPC || err == -EAGAIN))
> - return err;
> + break;
>
> /* Resort *all* the objects into priority order */
> INIT_LIST_HEAD(&eb->unbound);
> @@ -666,7 +668,9 @@ static int eb_reserve(struct i915_execbuffer *eb)
> list_splice_tail(&last, &eb->unbound);
>
> if (err == -EAGAIN) {
> + mutex_unlock(&eb->i915->drm.struct_mutex);
> flush_workqueue(eb->i915->mm.userptr_wq);
> + mutex_lock(&eb->i915->drm.struct_mutex);
> continue;
> }
>
> @@ -680,15 +684,20 @@ static int eb_reserve(struct i915_execbuffer *eb)
> err = i915_gem_evict_vm(eb->context->vm);
> mutex_unlock(&eb->context->vm->mutex);
> if (err)
> - return err;
> + goto unlock;
> break;
>
> default:
> - return -ENOSPC;
> + err = -ENOSPC;
> + goto unlock;
> }
>
> pin_flags = PIN_USER;
> } while (1);
> +
> +unlock:
> + mutex_unlock(&eb->i915->drm.struct_mutex);
> + return err;
> }
>
> static unsigned int eb_batch_index(const struct i915_execbuffer *eb)
> @@ -1631,7 +1640,6 @@ static int eb_prefault_relocations(const struct
> i915_execbuffer *eb)
>
> static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
> {
> - struct drm_device *dev = &eb->i915->drm;
> bool have_copy = false;
> struct eb_vma *ev;
> int err = 0;
> @@ -1642,8 +1650,6 @@ static noinline int eb_relocate_slow(struct
> i915_execbuffer *eb)
> goto out;
> }
>
> - mutex_unlock(&dev->struct_mutex);
> -
> /*
>* We take 3 passes through the slowpatch.
>*
> @@ -1666,21 +1672,8 @@ static noinline int eb_relocate_slow(struct
> i915_execbuffer *eb)
> cond_resched();
> err = 0;
> }
> - if (err) {
> - mutex_lock(&dev->struct_mutex);
> - goto out;
> - }
> -
> - /* A frequent cause for EAGAIN are currently unavailable client pages */
> - flush_workqueue(eb->i915->mm.userptr_wq);
> -
> - err = i915_mutex_lock_interruptible(dev);
> - if (err) {
> - mutex_lock(&dev->struct_mutex);
> + if (err)
> goto out;
> - }
> -
> - GEM_BUG_ON(!eb->batch);
>
> list_for_each_entry(ev, &eb->relocs, reloc_link) {
> if (!have_copy) {
> @@ -1738,9 +1731,11 @@ static int eb_relocate(struct i915_execbuffer *eb)
> if (err)
> return err;
>
> - err = eb_reserve(eb);
> - if (err)
> - return err;
> + if (!list_empty(&eb->unbound)) {
> + err = eb_reserve(eb);
> + if (err)
> + return err;
> + }
>
> /* The objects are in their final locations, apply the relocations. */
> if (eb->args->flags & __EXEC_HAS_RELOC) {
> @@ -2690,10 +2685,6 @@ i915_gem_do_execbuffer(struct drm_device *dev,
>
[Intel-gfx] [PATCH v3] drm/i915: properly sanity check batch_start_offset
Check the edge case where batch_start_offset sits exactly on the batch
size.
v2: add new range_overflows variant to capture the special case where
the size is permitted to be zero, like with batch_len.
v3: other way around. the common case is the exclusive one which should
just be >=, with that we then just need to convert the three odd ball
cases that don't apply to use the new inclusive _end version.
Testcase: igt/gem_exec_params/invalid-batch-start-offset
Fixes: 0b5372727be3 ("drm/i915/cmdparser: Use cached vmappings")
Signed-off-by: Matthew Auld
Cc: Mika Kuoppala
Cc: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_fbc.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_rc6.c | 8
drivers/gpu/drm/i915/i915_utils.h| 14 +-
3 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 6cfe14393885..2d982c322be9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -509,12 +509,12 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private
*dev_priv,
fbc->compressed_llb = compressed_llb;
- GEM_BUG_ON(range_overflows_t(u64, dev_priv->dsm.start,
-fbc->compressed_fb.start,
-U32_MAX));
- GEM_BUG_ON(range_overflows_t(u64, dev_priv->dsm.start,
-fbc->compressed_llb->start,
-U32_MAX));
+ GEM_BUG_ON(range_overflows_end_t(u64, dev_priv->dsm.start,
+fbc->compressed_fb.start,
+U32_MAX));
+ GEM_BUG_ON(range_overflows_end_t(u64, dev_priv->dsm.start,
+fbc->compressed_llb->start,
+U32_MAX));
intel_de_write(dev_priv, FBC_CFB_BASE,
dev_priv->dsm.start + fbc->compressed_fb.start);
intel_de_write(dev_priv, FBC_LL_BASE,
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 0392d2c79de9..66c07c32745c 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -320,10 +320,10 @@ static int vlv_rc6_init(struct intel_rc6 *rc6)
return PTR_ERR(pctx);
}
- GEM_BUG_ON(range_overflows_t(u64,
-i915->dsm.start,
-pctx->stolen->start,
-U32_MAX));
+ GEM_BUG_ON(range_overflows_end_t(u64,
+i915->dsm.start,
+pctx->stolen->start,
+U32_MAX));
pctx_paddr = i915->dsm.start + pctx->stolen->start;
intel_uncore_write(uncore, VLV_PCBR, pctx_paddr);
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index cae0ae520398..ec31ef6be52f 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -102,12 +102,24 @@ bool i915_error_injected(void);
typeof(max) max__ = (max); \
(void)(&start__ == &size__); \
(void)(&start__ == &max__); \
- start__ > max__ || size__ > max__ - start__; \
+ start__ >= max__ || size__ > max__ - start__; \
})
#define range_overflows_t(type, start, size, max) \
range_overflows((type)(start), (type)(size), (type)(max))
+#define range_overflows_end(start, size, max) ({ \
+ typeof(start) start__ = (start); \
+ typeof(size) size__ = (size); \
+ typeof(max) max__ = (max); \
+ (void)(&start__ == &size__); \
+ (void)(&start__ == &max__); \
+ start__ > max__ || size__ > max__ - start__; \
+})
+
+#define range_overflows_end_t(type, start, size, max) \
+ range_overflows_end((type)(start), (type)(size), (type)(max))
+
/* Note we don't consider signbits :| */
#define overflows_type(x, T) \
(sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/phys: unconditionally call release_memory_region
Quoting Patchwork (2020-03-06 06:09:52) > == Series Details == > > Series: drm/i915/phys: unconditionally call release_memory_region > URL : https://patchwork.freedesktop.org/series/74354/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16849 > > > Summary > --- > > **SUCCESS** > > No regressions found. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16849/index.html Ok. This migration still looks ugly, but the patch looks correct. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/3] drm/i915/perf: remove generated code
A little bit of history :
Back when i915-perf was introduced (4.13), there was no way to
dynamically add new OA configurations to i915. Only the generated
configs baked in at build time were allowed.
It quickly became obvious that we would need to allow applications
to upload their own configurations, for instance to be able to test
new ones, and so by the next stable version (4.14) we added uAPIs
to allow uploading new configurations.
When adding that capability, we took the opportunity to remove most
HW configurations except the TestOa one which is a configuration
IGT would rely on to verify that the HW is outputting correct
values. At the time it made sense to have that confiuration in at
the same time a given HW platform added to the i915-perf driver.
Now that IGT has become the reference point for HW configurations (see
commit 53f8f541ca ("lib: Add i915_perf library"), previously this was
located in the GPUTop repository), the need for having those
configurations in i915-perf is gone.
On the Mesa side, we haven't relied on this test configuration for a
while. The MDAPI library always required 4.14 feature level and always
loaded its configuration into i915.
I'm sure nobody will miss this generated stuff in i915 :)
v2: Fix selftests by creating an empty config
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/Makefile | 17 ---
drivers/gpu/drm/i915/i915_perf.c | 81 +-
drivers/gpu/drm/i915/i915_perf_types.h | 2 -
drivers/gpu/drm/i915/oa/i915_oa_bdw.c | 90 ---
drivers/gpu/drm/i915/oa/i915_oa_bdw.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_bxt.c | 88 ---
drivers/gpu/drm/i915/oa/i915_oa_bxt.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt2.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt2.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt3.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt3.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_chv.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_chv.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_cnl.c | 101 -
drivers/gpu/drm/i915/oa/i915_oa_cnl.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_glk.c | 88 ---
drivers/gpu/drm/i915/oa/i915_oa_glk.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_hsw.c | 118
drivers/gpu/drm/i915/oa/i915_oa_hsw.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_icl.c | 98 -
drivers/gpu/drm/i915/oa/i915_oa_icl.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt2.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt2.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt3.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt3.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt2.c | 88 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt2.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt3.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt3.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt4.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt4.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_tgl.c | 121 -
drivers/gpu/drm/i915/oa/i915_oa_tgl.h | 16 ---
drivers/gpu/drm/i915/selftests/i915_perf.c | 99 -
34 files changed, 97 insertions(+), 1757 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bdw.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bdw.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bxt.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bxt.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt2.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt2.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt3.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt3.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_chv.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_chv.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cnl.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cnl.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_glk.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_glk.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_hsw.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_hsw.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_icl.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_icl.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt2.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt2.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt3.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt3.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_sklgt2.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_sklgt2.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_sklgt3.c
delete mode 100644 drivers/gpu/drm/i915
[Intel-gfx] [PATCH v4 3/3] drm/i915/perf: introduce global sseu pinning
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As a result using OA (and NOA feeding into it) so far has required us
to use a power configuration that can work for all contexts. The only
power configuration fullfilling this is powergating half the execution
units.
This makes performance analysis for 3D workloads somewhat pointless.
Failing to find a solution that would work for everybody, this change
introduces a new i915-perf stream open parameter that punts the
decision off to userspace. If this parameter is omitted, the existing
Gen11 behavior remains (half EU array powergating).
This change takes the initiative to move all perf related sseu
configuration into i915_perf.c
v2: Make parameter priviliged if different from default
v3: Fix context modifying its sseu config while i915-perf is enabled
v4: Always consider global sseu a privileged operation (Tvrtko)
Override req_sseu point in intel_sseu_make_rpcs() (Tvrtko)
Remove unrelated changes (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 +--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 4 +
drivers/gpu/drm/i915/gt/intel_sseu.c| 33 ++--
drivers/gpu/drm/i915/i915_perf.c| 84 -
drivers/gpu/drm/i915/i915_perf_types.h | 7 ++
include/uapi/drm/i915_drm.h | 11 +++
6 files changed, 116 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index cb6b6be48978..edcbc7eef716 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1358,10 +1358,10 @@ static int get_ringsize(struct i915_gem_context *ctx,
return 0;
}
-static int
-user_to_context_sseu(struct drm_i915_private *i915,
-const struct drm_i915_gem_context_param_sseu *user,
-struct intel_sseu *context)
+int
+i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context)
{
const struct sseu_dev_info *device = &RUNTIME_INFO(i915)->sseu;
@@ -1496,7 +1496,7 @@ static int set_sseu(struct i915_gem_context *ctx,
goto out_ce;
}
- ret = user_to_context_sseu(i915, &user_sseu, &sseu);
+ ret = i915_gem_user_to_context_sseu(i915, &user_sseu, &sseu);
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 57b7ae2893e1..f37c36719b04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -221,4 +221,8 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
*it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
+int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context);
+
#endif /* !__I915_GEM_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 74f793423231..d173271c7397 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -65,7 +65,6 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
{
const struct sseu_dev_info *sseu = &RUNTIME_INFO(i915)->sseu;
bool subslice_pg = sseu->has_subslice_pg;
- struct intel_sseu ctx_sseu;
u8 slices, subslices;
u32 rpcs = 0;
@@ -78,31 +77,13 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system.
-*
-* We could choose full enablement, but on ICL we know there are use
-* cases which disable slices for functional, apart for performance
-* reasons. So in this case we select a known stable subset.
+* on the system. Use the configuration pinned by i915/perf.
*/
- if (!i915->perf.exclusive_stream) {
- ctx_sseu = *req_sseu;
- } else {
- ctx_sseu = intel_sseu_from_device_info(sseu);
-
- if (IS_GEN(i915, 11)) {
- /*
-* We only need subslice count so it doesn't matter
-* which ones we select - just turn off low bits in the
-* amount of half of all available subslices per slice.
-*/
-
[Intel-gfx] [PATCH v4 2/3] drm/i915/perf: remove redundant power configuration register override
The caller of i915_oa_init_reg_state() already sets this.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0069f09b988c..86c6abaa3e0e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2098,9 +2098,6 @@ gen8_update_reg_state_unlocked(const struct intel_context
*ce,
for (i = 0; i < ARRAY_SIZE(flex_regs); i++)
reg_state[ctx_flexeu0 + i * 2 + 1] =
oa_config_flex_reg(stream->oa_config, flex_regs[i]);
-
- reg_state[CTX_R_PWR_CLK_STATE] =
- intel_sseu_make_rpcs(ce->engine->i915, &ce->sseu);
}
struct flex {
@@ -2906,10 +2903,6 @@ void i915_oa_init_reg_state(const struct intel_context
*ce,
/* perf.exclusive_stream serialised by lrc_configure_all_contexts() */
stream = READ_ONCE(engine->i915->perf.exclusive_stream);
- /*
-* For gen12, only CTX_R_PWR_CLK_STATE needs update, but the caller
-* is already doing that, so nothing to be done for gen12 here.
-*/
if (stream && INTEL_GEN(stream->perf->i915) < 12)
gen8_update_reg_state_unlocked(ce, stream);
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: be more solid in checking the alignment
Quoting Patchwork (2020-03-06 05:40:31) > == Series Details == > > Series: drm/i915: be more solid in checking the alignment > URL : https://patchwork.freedesktop.org/series/74353/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8074 -> Patchwork_16848 > > > Summary > --- > > **SUCCESS** Feels like we should convert is_power_of_2() to a type agnostic macro ala round_up(). That said, this patch is correct and fixes a bug, so Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Always propagate the invocation to i915_schedule
Chris Wilson writes:
> We only call i915_schedule() when we know we have changed the priority
> on a request and so require to propagate any change in priority to its
> signalers (for PI). By unconditionally checking all of our signalers, we
> avoid skipping changes made prior to construction of the request (as the
> request may be waited upon before submission when used in parallel).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_scheduler.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index be770f2419b1..52f71e83e088 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -227,10 +227,10 @@ static void kick_submission(struct intel_engine_cs
> *engine,
> static void __i915_schedule(struct i915_sched_node *node,
> const struct i915_sched_attr *attr)
> {
> + const int prio = max(attr->priority, node->attr.priority);
> struct intel_engine_cs *engine;
> struct i915_dependency *dep, *p;
> struct i915_dependency stack;
> - const int prio = attr->priority;
> struct sched_cache cache;
> LIST_HEAD(dfs);
>
> @@ -238,9 +238,6 @@ static void __i915_schedule(struct i915_sched_node *node,
> lockdep_assert_held(&schedule_lock);
> GEM_BUG_ON(prio == I915_PRIORITY_INVALID);
>
> - if (prio <= READ_ONCE(node->attr.priority))
> - return;
> -
> if (node_signaled(node))
> return;
>
> --
> 2.25.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.IGT: success for series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details == Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev URL : https://patchwork.freedesktop.org/series/74299/ State : success == Summary == CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16832_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16832_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-iclb7/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-write-read-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb7/igt@gem_exec_sched...@implicit-write-read-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-iclb4/igt@gem_exec_sched...@implicit-write-read-bsd.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +12 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-iclb7/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_whisper@basic-queues-forked: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk6/igt@gem_exec_whis...@basic-queues-forked.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-glk2/igt@gem_exec_whis...@basic-queues-forked.html * igt@i915_pm_rps@min-max-config-loaded: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#370]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@i915_pm_...@min-max-config-loaded.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-iclb2/igt@i915_pm_...@min-max-config-loaded.html * igt@kms_flip_tiling@flip-yf-tiled: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl8/igt@kms_flip_til...@flip-yf-tiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-skl10/igt@kms_flip_til...@flip-yf-tiled.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#49]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#899]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-glk6/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr2_su@page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-iclb8/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/shard-iclb1/igt@kms_psr@psr2_cursor_plane_move.html * igt@kms_setmode@basic: - shard-apl: [PASS][25] -> [FAIL][26] ([i915#31]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Add support for integrated privacy screens
On Thu, 05 Mar 2020, Rajat Jain wrote:
> OK, will do. In order to do that I may need to introduce driver level
> hooks that i915 driver can populate and drm core can call (or may be
> some functions to add privacy screen property that drm core exports
> and i915 driver will call).
The latter. Look at drm_connector_attach_*() functions in
drm_connector.c. i915 (or any other driver) can create and attach the
property as needed. drm_atomic_connector_{get,set}_property in
drm_atomic_uapi.c need to handle the properties, but *only* to get/set
the value in drm_connector_state, nothing more. How that value is
actually used is up to the drivers, but the userspace interface will be
the same instead of being driver specific.
>> > @@ -93,15 +97,18 @@ int intel_digital_connector_atomic_set_property(struct
>> > drm_connector *connector,
>> > struct drm_i915_private *dev_priv = to_i915(dev);
>> > struct intel_digital_connector_state *intel_conn_state =
>> > to_intel_digital_connector_state(state);
>> > + struct intel_connector *intel_connector =
>> > to_intel_connector(connector);
>> >
>> > if (property == dev_priv->force_audio_property) {
>> > intel_conn_state->force_audio = val;
>> > return 0;
>> > - }
>> > -
>> > - if (property == dev_priv->broadcast_rgb_property) {
>> > + } else if (property == dev_priv->broadcast_rgb_property) {
>> > intel_conn_state->broadcast_rgb = val;
>> > return 0;
>> > + } else if (property == intel_connector->privacy_screen_property) {
>> > + intel_privacy_screen_set_val(intel_connector, val);
>>
>> I think this part should only change the connector state. The driver
>> would then do the magic at commit stage according to the property value.
Also, this would be the part that's done in drm core level.
> Can you please point me to some code reference as to where in code
> does the "commit stage" apply the changes?
Look at, say, drm_connector_attach_scaling_mode_property(). In the
getter/setter code it'll just read/change state->scaling_mode. You can
use the value in encoder ->enable, ->disable, and ->update_pipe
hooks. Enable should enable the privacy screen if desired, disable
should probably unconditionally disable the privacy screen while
disabling the display, and update should just change the state according
to the value. Update is called if there isn't a full modeset. (Scaling
mode is a bit more indirect than that, affecting other things in the
encoder ->compute_config hook, leading to similar effects.)
Ville, anything I missed?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/edid: Name the detailed monitor range flags
On Thu, 05 Mar 2020, Manasi Navare wrote:
> This patch adds defines for the detailed monitor
> range flags as per the EDID specification.
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Kazlauskas Nicholas
> Signed-off-by: Manasi Navare
> ---
> include/drm/drm_edid.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index f0b03d401c27..f89c97623845 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -91,6 +91,11 @@ struct detailed_data_string {
> u8 str[13];
> } __attribute__((packed));
>
> +#define EDID_DEFAULT_GTF_SUPPORT_FLAG 0x00
> +#define EDID_RANGE_LIMITS_ONLY_FLAG 0x01
> +#define EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02
> +#define EDID_CVT_SUPPORT_FLAG 0x04
Bikeshed for consideration:
drm_edid.h has some macros with DRM_EDID_ prefix, some with EDID_
prefix, and then some with no prefix at all really. Should we start
consolidating on something when we add more?
BR,
Jani.
> +
> struct detailed_data_monitor_range {
> u8 min_vfreq;
> u8 max_vfreq;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/3] drm/i915: Assert requests within a context are submitted in order
== Series Details == Series: series starting with [1/3] drm/i915: Assert requests within a context are submitted in order URL : https://patchwork.freedesktop.org/series/74369/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] MAINTAINERS: adjust to reservation.h renaming
On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > renamed include/linux/reservation.h to include/linux/dma-resv.h, but
> > missed the reference in the MAINTAINERS entry.
> >
> > Since then, ./scripts/get_maintainer.pl --self-test complains:
> >
> >warning: no file matches F: include/linux/reservation.h
> >
> > Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS.
> >
> > Co-developed-by: Sebastian Duda
> > Signed-off-by: Sebastian Duda
> > Signed-off-by: Lukas Bulwahn
>
> Reviewed-by: Christian König
You'll push this too?
-Daniel
>
> > ---
> > Christian, please pick this patch.
> > applies cleanly on current master and next-20200303
> >
> > MAINTAINERS | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6158a143a13e..3d6cb2789c9e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5022,7 +5022,7 @@ L:dri-de...@lists.freedesktop.org
> > L:linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
> > F:drivers/dma-buf/
> > F:include/linux/dma-buf*
> > -F: include/linux/reservation.h
> > +F: include/linux/dma-resv.h
> > F:include/linux/*fence.h
> > F:Documentation/driver-api/dma-buf.rst
> > K:dma_(buf|fence|resv)
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Assert requests within a context are submitted in order
== Series Details ==
Series: series starting with [1/3] drm/i915: Assert requests within a context
are submitted in order
URL : https://patchwork.freedesktop.org/series/74369/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8076 -> Patchwork_16856
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16856 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16856, 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_16856/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16856:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-cfl-8109u: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-cfl-8109u/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live@ring_submission}:
- fi-byt-j1900: [PASS][2] -> [DMESG-FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-byt-j1900/igt@i915_selftest@live@ring_submission.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-byt-j1900/igt@i915_selftest@live@ring_submission.html
* igt@runner@aborted:
- {fi-kbl-7560u}: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-kbl-7560u/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_16856 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([CI#94] / [i915#402])
+1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8109u: [PASS][7] -> [INCOMPLETE][8] ([i915#424])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][9] ([CI#94]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live@gt_mocs:
- fi-snb-2520m: [DMESG-WARN][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-snb-2520m/igt@i915_selftest@live@gt_mocs.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-snb-2520m/igt@i915_selftest@live@gt_mocs.html
* {igt@i915_selftest@live@ring_submission}:
- fi-hsw-peppy: [DMESG-FAIL][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-hsw-peppy/igt@i915_selftest@live@ring_submission.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-hsw-peppy/igt@i915_selftest@live@ring_submission.html
- fi-snb-2520m: [INCOMPLETE][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-snb-2520m/igt@i915_selftest@live@ring_submission.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-snb-2520m/igt@i915_selftest@live@ring_submission.html
* igt@kms_addfb_basic@bad-pitch-63:
- fi-tgl-y: [DMESG-WARN][17] ([CI#94] / [i915#402]) -> [PASS][18]
+1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8076/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-63.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16856/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-63.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#504]: https://gitlab.freedesktop.org/drm/intel/issues/504
Participating hosts (45 -> 45)
--
Additional (4): fi-hsw-4770r fi-skl-lmem fi-blb-e6850 fi-kbl-r
Missing(4): fi-byt-clapper fi-byt-squawks fi-bsw-cyan fi-bdw-samus
Build changes
-
* CI:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
== Series Details == Series: drm/i915/execlists: Enable timeslice on partial virtual engine dequeue URL : https://patchwork.freedesktop.org/series/74304/ State : success == Summary == CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16833_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16833_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-shared-gtt-default: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#616]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-tglb7/igt@gem_ctx_sha...@exec-shared-gtt-default.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-tglb1/igt@gem_ctx_sha...@exec-shared-gtt-default.html * igt@gem_exec_capture@capture-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@gem_exec_capt...@capture-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-iclb5/igt@gem_exec_capt...@capture-bsd2.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-iclb7/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-iclb1/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb8/igt@gem_exec_sched...@wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-iclb4/igt@gem_exec_sched...@wide-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#644]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_pp...@flink-and-close-vma-leak.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-iclb2/igt@gem_pp...@flink-and-close-vma-leak.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#49]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-skl2/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-kbl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#899]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-glk7/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr2_su@page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-iclb5/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16833/shard-iclb1/igt@kms_psr@psr2_cursor_plane_move.html * igt@kms_setmode@basic: - shard-kbl: [PASS][25] -> [FAIL][26] ([i915#31]) [25]: https://intel-gfx-ci.
Re: [Intel-gfx] [PATCH] drm/i915/gt: allow setting generic data pointer
Hi Daniele,
> > > > diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > index 75255aaacaed..9112a8585caf 100644
> > > > --- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > +++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
> > > > @@ -26,15 +26,14 @@ void debugfs_gt_register(struct intel_gt *gt)
> > > > debugfs_gt_pm_register(gt, root);
> > > >}
> > > > -void debugfs_gt_register_files(struct intel_gt *gt,
> > > > - struct dentry *root,
> > > > - const struct debugfs_gt_file *files,
> > > > - unsigned long count)
> > > > +void __intel_gt_debugfs_register_files(struct intel_gt *gt, struct
> > > > dentry *root,
> > > > + const struct debugfs_gt_file
> > > > *files,
> > > > + unsigned long count, void *data)
> > > >{
> > > > while (count--) {
> > > > if (!files->eval || files->eval(gt))
> > >
> > > IMO the files->eval() function should also use the provided data instead
> > > of
> > > intel_gt. This will also allow us to drop the intel_gt parameter in this
> > > function, which in turn means we can use this function directly from all
> > > the
> > > levels.
> >
> > do you mean something like this:
> >
> > - bool (*eval)(const struct intel_gt *gt);
> > + bool (*eval)(void *data);
> >
> > ?
>
> yes
>
> >
> > I am missing the use case, though, what is it that cannot be
> > reached by the gt so that it needs to be more generic?
>
> It's not a problem of reaching it from gt but the other way around, I don't
> want the caller to have to retrieve a gt variable it don't needs just to
> pass it to this function and then go back to the actual required data from
> gt inside of the eval function. Anything you need for your evaluation should
> be reachable from the struct used as data for the debugfs.
> To make a concrete example, I want to avoid an unneeded guc_to_gt inside
> intel_guc_debugfs_register that would also require a matched guc =
> >->uc.guc inside the eval function, passing guc (i.e. the data) straight
> in the eval is cleaner IMO.
Thanks for the feedback, makes sense.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] MAINTAINERS: adjust to reservation.h renaming
On Fri, 2020-03-06 at 11:39 +0100, Daniel Vetter wrote:
> On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> > Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > > renamed include/linux/reservation.h to include/linux/dma-resv.h, but
> > > missed the reference in the MAINTAINERS entry.
> > >
> > > Since then, ./scripts/get_maintainer.pl --self-test complains:
> > >
> > >warning: no file matches F: include/linux/reservation.h
> > >
> > > Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS.
> > >
> > > Co-developed-by: Sebastian Duda
> > > Signed-off-by: Sebastian Duda
> > > Signed-off-by: Lukas Bulwahn
> >
> > Reviewed-by: Christian König
>
> You'll push this too?
> -Daniel
>
> > > ---
> > > Christian, please pick this patch.
> > > applies cleanly on current master and next-20200303
> > >
> > > MAINTAINERS | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 6158a143a13e..3d6cb2789c9e 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -5022,7 +5022,7 @@ L: dri-de...@lists.freedesktop.org
> > > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
> > > F: drivers/dma-buf/
> > > F: include/linux/dma-buf*
> > > -F: include/linux/reservation.h
> > > +F: include/linux/dma-resv.h
> > > F: include/linux/*fence.h
> > > F: Documentation/driver-api/dma-buf.rst
> > > K: dma_(buf|fence|resv)
Slightly unrelated:
The K: entry matches a lot of other things
and may have a lot of false positive matches
like any variable named dma_buffer
This should also use (?:...) to avoid a perl
capture group.
Perhaps:
K: '\bdma_(?:buf|fence|resv)\b'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Improve the start alignment of bonded pairs
Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting on the semaphore used to synchronise the start of the
bonded payload.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 41 +
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 66efd16c4850..db11006b4ac9 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1128,14 +1128,45 @@ __i915_request_await_execution(struct i915_request *to,
&from->fence))
return 0;
- /* Ensure both start together [after all semaphores in signal] */
- if (intel_engine_has_semaphores(to->engine))
- err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
- else
- err = i915_request_await_start(to, from);
+ /*
+* 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)) {
+ 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) {
err = i915_sched_node_add_dependency(&to->sched, &from->sched);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Tweak scheduler's kick_submission()
Skip useless priority bumping on adding a new dependency, but otherwise prevent tasklet scheduling until we have completed all the potential rescheduling. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_scheduler.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c index 52f71e83e088..603cba36d6a4 100644 --- a/drivers/gpu/drm/i915/i915_scheduler.c +++ b/drivers/gpu/drm/i915/i915_scheduler.c @@ -209,6 +209,8 @@ static void kick_submission(struct intel_engine_cs *engine, if (!inflight) goto unlock; + engine->execlists.queue_priority_hint = prio; + /* * If we are already the currently executing context, don't * bother evaluating if we should preempt ourselves. @@ -216,7 +218,6 @@ static void kick_submission(struct intel_engine_cs *engine, if (inflight->context == rq->context) goto unlock; - engine->execlists.queue_priority_hint = prio; if (need_preempt(prio, rq_prio(inflight))) tasklet_hi_schedule(&engine->execlists.tasklet); @@ -463,11 +464,15 @@ int i915_sched_node_add_dependency(struct i915_sched_node *node, if (!dep) return -ENOMEM; + local_bh_disable(); + if (!__i915_sched_node_add_dependency(node, signal, dep, I915_DEPENDENCY_EXTERNAL | I915_DEPENDENCY_ALLOC)) i915_dependency_free(dep); + local_bh_enable(); /* kick submission tasklet */ + return 0; } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
If we stop filling the ELSP due to an incompatible virtual engine
request, check if we should enable the timeslice on behalf of the queue.
This fixes the case where we are inspecting the last->next element when
we know that the last element is the last request in the execution queue,
and so decided we did not need to enable timeslicing despite the intent
to do so!
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: # v5.4+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 13941d1c0a4a..a1d268880cfe 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1757,11 +1757,9 @@ need_timeslice(struct intel_engine_cs *engine, const
struct i915_request *rq)
if (!intel_engine_has_timeslices(engine))
return false;
- if (list_is_last(&rq->sched.link, &engine->active.requests))
- return false;
-
- hint = max(rq_prio(list_next_entry(rq, sched.link)),
- engine->execlists.queue_priority_hint);
+ hint = engine->execlists.queue_priority_hint;
+ if (!list_is_last(&rq->sched.link, &engine->active.requests))
+ hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
return hint >= effective_prio(rq);
}
@@ -1803,6 +1801,18 @@ static void set_timeslice(struct intel_engine_cs *engine)
set_timer_ms(&engine->execlists.timer, active_timeslice(engine));
}
+static void start_timeslice(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ execlists->switch_priority_hint = execlists->queue_priority_hint;
+
+ if (timer_pending(&execlists->timer))
+ return;
+
+ set_timer_ms(&execlists->timer, timeslice(engine));
+}
+
static void record_preemption(struct intel_engine_execlists *execlists)
{
(void)I915_SELFTEST_ONLY(execlists->preempt_hang.count++);
@@ -1966,11 +1976,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* Even if ELSP[1] is occupied and not worthy
* of timeslices, our queue might be.
*/
- if (!execlists->timer.expires &&
- need_timeslice(engine, last))
- set_timer_ms(&execlists->timer,
-timeslice(engine));
-
+ start_timeslice(engine);
return;
}
}
@@ -2005,7 +2011,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (last && !can_merge_rq(last, rq)) {
spin_unlock(&ve->base.active.lock);
- return; /* leave this for another */
+ start_timeslice(engine);
+ return; /* leave this for another sibling */
}
ENGINE_TRACE(engine,
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Improve the start alignment of bonded pairs
== Series Details ==
Series: drm/i915: Improve the start alignment of bonded pairs
URL : https://patchwork.freedesktop.org/series/74315/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16835_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_16835_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_balancer@bonded-early}:
- shard-iclb: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_balan...@bonded-early.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-iclb2/igt@gem_exec_balan...@bonded-early.html
- shard-kbl: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl1/igt@gem_exec_balan...@bonded-early.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-kbl4/igt@gem_exec_balan...@bonded-early.html
- shard-tglb: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-tglb3/igt@gem_exec_balan...@bonded-early.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-tglb8/igt@gem_exec_balan...@bonded-early.html
Known issues
Here are the changes found in Patchwork_16835_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@gem_exec_balan...@smoke.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-iclb7/igt@gem_exec_balan...@smoke.html
* igt@gem_exec_schedule@deep-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +6 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb7/igt@gem_exec_sched...@deep-bsd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-iclb4/igt@gem_exec_sched...@deep-bsd.html
* igt@gem_exec_schedule@implicit-read-write-bsd1:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-iclb5/igt@gem_exec_sched...@implicit-read-write-bsd1.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276]) +22 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-iclb7/igt@gem_exec_sched...@independent-bsd2.html
* igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [PASS][15] -> [SKIP][16] ([i915#677]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html
* igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118] /
[i915#95]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk6/igt@gem_exec_whis...@basic-queues-forked-all.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-glk8/igt@gem_exec_whis...@basic-queues-forked-all.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl1/igt@gem_soft...@noreloc-s3.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-apl6/igt@gem_soft...@noreloc-s3.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#716])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@gen9_exec_pa...@allowed-single.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-skl2/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [PASS][23] -> [FAIL][24] ([i915#79])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16835/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
* igt@kms_flip_tiling@flip-yf-tiled:
- shard-skl:
[Intel-gfx] [RFC 0/7] Asynchronous flip implementation for i915
Without async flip support in the kernel, fullscreen apps where game resolution is equal to the screen resolution, must perform an extra blit per frame prior to flipping. Asynchronous page flips will also boost the FPS of Mesa benchmarks. Karthik B S (7): drm/i915: Define flip done functions and enable IER drm/i915: Add support for async flips in I915 drm/i915: Make commit call blocking in case of async flips drm/i915: Add checks specific to async flips drm/i915: Add flip_done_handler definition drm/i915: Enable and handle flip done interrupt drm/i915: Do not call drm_crtc_arm_vblank_event in async flips drivers/gpu/drm/i915/display/intel_display.c | 55 +-- drivers/gpu/drm/i915/display/intel_sprite.c | 12 ++-- drivers/gpu/drm/i915/i915_irq.c | 58 +++- drivers/gpu/drm/i915/i915_irq.h | 2 + drivers/gpu/drm/i915/i915_reg.h | 1 + 5 files changed, 117 insertions(+), 11 deletions(-) -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/7] drm/i915: Add checks specific to async flips
Support added only for async flips on primary plane.
If flip is requested on any other plane, reject it.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 25fad5d01e67..a8de08c3773e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14732,6 +14732,31 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
return false;
}
+static int intel_atomic_check_async(struct intel_atomic_state *state)
+{
+ struct drm_plane *plane;
+ struct drm_plane_state *plane_state;
+ struct intel_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+ int i, j;
+
+ /*FIXME: Async flip is only supported for primary plane currently
+* Support for overlays to be added.
+*/
+ for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
+ if (crtc_state->uapi.async_flip) {
+ for_each_new_plane_in_state(&state->base,
+ plane, plane_state, j) {
+ if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
+ DRM_ERROR("Async flips is NOT supported
for non-primary plane\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ return 0;
+}
+
/**
* intel_atomic_check - validate state object
* @dev: drm device
@@ -14760,6 +14785,10 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
+ ret = intel_atomic_check_async(state);
+ if (ret)
+ goto fail;
+
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!needs_modeset(new_crtc_state)) {
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 6/7] drm/i915: Enable and handle flip done interrupt
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt.
If the flip done event is requested then send it in the flip done handler,
and then disable the interrupt.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/i915_irq.c | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a8de08c3773e..757380af1f93 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15604,6 +15604,13 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
if (state->modeset)
icl_dbuf_slice_pre_update(state);
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip) {
+ icl_enable_flip_done(&crtc->base);
+ break;
+ }
+ }
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1feda9aecf4a..c9b1bb0e2c30 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2363,6 +2363,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
if (iir & GEN8_PIPE_VBLANK)
intel_handle_vblank(dev_priv, pipe);
+ if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
+ flip_done_handler(dev_priv, pipe);
+
if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
hsw_pipe_crc_irq_handler(dev_priv, pipe);
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/7] drm/i915: Define flip done functions and enable IER
Add enable/disable flip done functions and enable
the flip done interrupt in IER.
Flip done interrupt is used to send the page flip event as soon as the
surface address is written as per the requirement of async flips.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/i915_irq.c | 37 -
drivers/gpu/drm/i915/i915_irq.h | 2 ++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ecf07b0faad2..5955e737a45d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2626,6 +2626,27 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
return 0;
}
+void icl_enable_flip_done(struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ struct drm_vblank_crtc *vblank = &dev_priv->drm.vblank[pipe];
+ unsigned long irqflags;
+
+ /* Make sure that vblank is not enabled, as we are already sending
+* the page flip event in the flip_done_handler.
+*/
+ if (atomic_read(&vblank->refcount) != 0)
+ drm_crtc_vblank_put(crtc);
+
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+
+ bdw_enable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
+
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+
+}
+
/* Called from drm generic code, passed 'crtc' which
* we use as a pipe index
*/
@@ -2686,6 +2707,20 @@ void bdw_disable_vblank(struct drm_crtc *crtc)
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
}
+
+void icl_disable_flip_done(struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+
+ bdw_disable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
+
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+}
+
static void ibx_irq_reset(struct drm_i915_private *dev_priv)
{
struct intel_uncore *uncore = &dev_priv->uncore;
@@ -3375,7 +3410,7 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
de_port_masked |= CNL_AUX_CHANNEL_F;
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
- GEN8_PIPE_FIFO_UNDERRUN;
+ GEN8_PIPE_FIFO_UNDERRUN | GEN9_PIPE_PLANE1_FLIP_DONE;
de_port_enables = de_port_masked;
if (IS_GEN9_LP(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
index 812c47a9c2d6..6fc319980dd3 100644
--- a/drivers/gpu/drm/i915/i915_irq.h
+++ b/drivers/gpu/drm/i915/i915_irq.h
@@ -114,11 +114,13 @@ int i915gm_enable_vblank(struct drm_crtc *crtc);
int i965_enable_vblank(struct drm_crtc *crtc);
int ilk_enable_vblank(struct drm_crtc *crtc);
int bdw_enable_vblank(struct drm_crtc *crtc);
+void icl_enable_flip_done(struct drm_crtc *crtc);
void i8xx_disable_vblank(struct drm_crtc *crtc);
void i915gm_disable_vblank(struct drm_crtc *crtc);
void i965_disable_vblank(struct drm_crtc *crtc);
void ilk_disable_vblank(struct drm_crtc *crtc);
void bdw_disable_vblank(struct drm_crtc *crtc);
+void icl_disable_flip_done(struct drm_crtc *crtc);
void gen2_irq_reset(struct intel_uncore *uncore);
void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/7] drm/i915: Add support for async flips in I915
Enable support for async flips in I915.
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 4
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dd47eb65b563..4ce9897f5c58 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4756,6 +4756,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state
*crtc_state,
plane_ctl |= PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE;
}
+ if (crtc_state->uapi.async_flip)
+ plane_ctl |= PLANE_CTL_ASYNC_FLIP;
+
plane_ctl |= skl_plane_ctl_format(fb->format->format);
plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
plane_ctl |= skl_plane_ctl_rotate(rotation & DRM_MODE_ROTATE_MASK);
@@ -17738,6 +17741,7 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
mode_config->funcs = &intel_mode_funcs;
+ mode_config->async_page_flip = true;
/*
* Maximum framebuffer dimensions, chosen to match
* the maximum render engine surface size on gen4+.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 80cf02a6eec1..42037aee9b78 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6794,6 +6794,7 @@ enum {
#define PLANE_CTL_TILED_X(1 << 10)
#define PLANE_CTL_TILED_Y(4 << 10)
#define PLANE_CTL_TILED_YF (5 << 10)
+#define PLANE_CTL_ASYNC_FLIP (1 << 9)
#define PLANE_CTL_FLIP_HORIZONTAL(1 << 8)
#define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
#define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/7] drm/i915: Make commit call blocking in case of async flips
Make the commit call blocking in case of async flips
so that there is no delay in completing the flip.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 4ce9897f5c58..25fad5d01e67 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15737,7 +15737,9 @@ static int intel_atomic_commit(struct drm_device *dev,
{
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
- int ret = 0;
+ struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc *crtc;
+ int ret = 0, i;
state->wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
@@ -15763,10 +15765,6 @@ static int intel_atomic_commit(struct drm_device *dev,
* (assuming we had any) would solve these problems.
*/
if (INTEL_GEN(dev_priv) < 9 && state->base.legacy_cursor_update) {
- struct intel_crtc_state *new_crtc_state;
- struct intel_crtc *crtc;
- int i;
-
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
if (new_crtc_state->wm.need_postvbl_update ||
new_crtc_state->update_wm_post)
@@ -15808,6 +15806,13 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_state_get(&state->base);
INIT_WORK(&state->base.commit_work, intel_atomic_commit_work);
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip) {
+ nonblock = false;
+ break;
+ }
+ }
+
i915_sw_fence_commit(&state->commit_ready);
if (nonblock && state->modeset) {
queue_work(dev_priv->modeset_wq, &state->base.commit_work);
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 7/7] drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_sprite.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index deda351719db..95193a521aa9 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -209,12 +209,14 @@ void intel_pipe_update_end(struct intel_crtc_state
*new_crtc_state)
drm_WARN_ON(&dev_priv->drm,
drm_crtc_vblank_get(&crtc->base) != 0);
- spin_lock(&crtc->base.dev->event_lock);
- drm_crtc_arm_vblank_event(&crtc->base,
- new_crtc_state->uapi.event);
- spin_unlock(&crtc->base.dev->event_lock);
+ if (!new_crtc_state->uapi.async_flip) {
+ spin_lock(&crtc->base.dev->event_lock);
+ drm_crtc_arm_vblank_event(&crtc->base,
+ new_crtc_state->uapi.event);
+ spin_unlock(&crtc->base.dev->event_lock);
- new_crtc_state->uapi.event = NULL;
+ new_crtc_state->uapi.event = NULL;
+ }
}
local_irq_enable();
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 5/7] drm/i915: Add flip_done_handler definition
Send the flip done event in the handler and disable the interrupt.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5955e737a45d..1feda9aecf4a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1243,6 +1243,24 @@ display_pipe_crc_irq_handler(struct drm_i915_private
*dev_priv,
u32 crc4) {}
#endif
+static void flip_done_handler(struct drm_i915_private *dev_priv,
+ unsigned int pipe)
+{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ struct drm_crtc_state *crtc_state = crtc->base.state;
+ struct drm_device *dev = &dev_priv->drm;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&dev->event_lock, irqflags);
+
+ if (crtc_state->event->base.event->type == DRM_EVENT_FLIP_COMPLETE) {
+ drm_crtc_send_vblank_event(&crtc->base, crtc_state->event);
+ crtc_state->event = NULL;
+ }
+
+ spin_unlock_irqrestore(&dev->event_lock, irqflags);
+ icl_disable_flip_done(&crtc->base);
+}
static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
enum pipe pipe)
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Polish CHV CGM CSC loading
On Fri, Mar 06, 2020 at 02:14:15PM +0530, Sharma, Swati2 wrote: > > > On 03-Mar-20 11:03 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Only load the CGM CSC based on the cgm_mode bit like we > > do with the gamma/degamma LUTs. And make the function > > naming and arguments consistent as well. > > > > TODO: the code to convert the coefficients look totally > > bogus. IIRC CHV uses two's complement format but the code > > certainly doesn't generate that, so probably negative > > coefficients are totally busted. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/display/intel_color.c | 69 +++--- > > 1 file changed, 35 insertions(+), 34 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c > > b/drivers/gpu/drm/i915/display/intel_color.c > > index 98aefeebda28..444980fdeda6 100644 > > --- a/drivers/gpu/drm/i915/display/intel_color.c > > +++ b/drivers/gpu/drm/i915/display/intel_color.c > > @@ -348,48 +348,43 @@ static void icl_load_csc_matrix(const struct > > intel_crtc_state *crtc_state) > >crtc_state->csc_mode); > > } > > > > -/* > > - * Set up the pipe CSC unit on CherryView. > > - */ > > -static void cherryview_load_csc_matrix(const struct intel_crtc_state > > *crtc_state) > > +static void chv_load_cgm_csc(struct intel_crtc *crtc, > > +const struct drm_property_blob *blob) > Nitpick: Spacing? I think it's just the use of tabs and the diff's '+' making it look off. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Actually emit the await_start
== Series Details == Series: drm/i915: Actually emit the await_start URL : https://patchwork.freedesktop.org/series/74319/ State : success == Summary == CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16836_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16836_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_capture@capture-bsd2: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@gem_exec_capt...@capture-bsd2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-iclb3/igt@gem_exec_capt...@capture-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112146]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk6/igt@gem_exec_whis...@basic-queues-forked-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-glk9/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#716]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@gen9_exec_pa...@allowed-single.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-skl10/igt@gen9_exec_pa...@allowed-single.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#49]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#899]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-glk5/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr2_su@page_flip.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-iclb3/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-iclb4/igt@kms_psr@psr2_cursor_plane_move.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([i915#31]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl7/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-apl1/igt@kms_setm...@basic.html - shard-kbl: [PASS][23] -> [FAIL][24] ([i915#31]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl7/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16836/shard-kbl6/igt@kms_setm...@basic.html * igt@perf_pmu@busy-vcs1: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#112080]) +5 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@perf_...@busy-vcs1.html [26]: https://intel-gfx-ci.0
[Intel-gfx] [PATCH 16/17] drm/i915: Use ww pinning for intel_context_create_request()
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index b048e4efb82c..b921a8d02032 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -445,15 +445,25 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce)
{
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
int err;
- err = intel_context_pin(ce);
- if (unlikely(err))
- return ERR_PTR(err);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = intel_context_pin_ww(ce, &ww);
+ if (!err) {
+ rq = i915_request_create(ce);
+ intel_context_unpin(ce);
+ } else if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ } else {
+ rq = ERR_PTR(err);
+ }
- rq = i915_request_create(ce);
- intel_context_unpin(ce);
+ i915_gem_ww_ctx_fini(&ww);
if (IS_ERR(rq))
return rq;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/17] drm/i915: Parse command buffer earlier in eb_relocate(slow)
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get called from execbuf
relocation fast and slowpath.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 61 ++-
1 file changed, 32 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index a1a2f6e8b7bc..c70026b05c26 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -285,6 +285,8 @@ struct i915_execbuffer {
struct hlist_head *buckets; /** ht for relocation handles */
};
+static int eb_parse(struct i915_execbuffer *eb);
+
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -731,6 +733,7 @@ static int eb_select_context(struct i915_execbuffer *eb)
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
struct radix_tree_root *handles_vma = &eb->gem_context->handles_vma;
+ struct drm_i915_private *i915 = eb->i915;
struct drm_i915_gem_object *obj;
unsigned int i, batch;
int err;
@@ -794,6 +797,22 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
eb_add_vma(eb, i, batch, vma);
}
+ if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
+ drm_dbg(&i915->drm,
+ "Attempting to use self-modifying batch buffer\n");
+ return -EINVAL;
+ }
+
+ if (range_overflows_t(u64,
+ eb->batch_start_offset, eb->batch_len,
+ eb->batch->vma->size)) {
+ drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
+ return -EINVAL;
+ }
+
+ if (eb->batch_len == 0)
+ eb->batch_len = eb->batch->vma->size - eb->batch_start_offset;
+
return 0;
err_obj:
@@ -1648,7 +1667,7 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1699,6 +1718,11 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
}
}
+ /* as last step, parse the command buffer */
+ err = eb_parse(eb);
+ if (err)
+ goto err;
+
/*
* Leave the user relocations as are, this is the painfully slow path,
* and we want to avoid the complication of dropping the lock whilst
@@ -1731,7 +1755,7 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
return err;
}
-static int eb_relocate(struct i915_execbuffer *eb)
+static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
@@ -1753,11 +1777,11 @@ static int eb_relocate(struct i915_execbuffer *eb)
list_for_each_entry(ev, &eb->relocs, reloc_link) {
if (eb_relocate_vma(eb, ev))
- return eb_relocate_slow(eb);
+ return eb_relocate_parse_slow(eb);
}
}
- return 0;
+ return eb_parse(eb);
}
static int eb_move_to_gpu(struct i915_execbuffer *eb)
@@ -2695,7 +2719,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_context;
- err = eb_relocate(&eb);
+ err = eb_relocate_parse(&eb);
if (err) {
/*
* If the user expects the execobject.offset and
@@ -2708,33 +2732,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
- if (unlikely(eb.batch->flags & EXEC_OBJECT_WRITE)) {
- drm_dbg(&i915->drm,
- "Attempting to use self-modifying batch buffer\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (range_overflows_t(u64,
- eb.batch_start_offset, eb.batch_len,
- eb.batch->vma->size)) {
- drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (eb.batch_len == 0)
- eb.batch_len = eb.batch->vma->size - eb.batch_start_offset;
-
- err = eb_parse(&eb);
- if (err)
- goto err_vma;
-
/*
* snb/ivb/vlv conflate the "batch in ppgtt" bit with the "non-secure
* batch" bit. Hence we need to pin secure batches into the global gtt.
* hsw should have this fi
[Intel-gfx] [PATCH 10/17] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass ww at a point where we could still handle -EDEADLK safely.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 125 ++
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 4 +-
drivers/gpu/drm/i915/gt/intel_context.c | 65 +
drivers/gpu/drm/i915/gt/intel_context.h | 13 ++
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ring.h | 3 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 15 +--
drivers/gpu/drm/i915/gt/intel_timeline.c | 12 +-
drivers/gpu/drm/i915/gt/intel_timeline.h | 3 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_timeline.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 13 +-
drivers/gpu/drm/i915/i915_gem.c | 11 +-
drivers/gpu/drm/i915/i915_vma.c | 13 +-
drivers/gpu/drm/i915/i915_vma.h | 13 +-
24 files changed, 207 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 13b6ffcd318c..cf9687cab30f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3441,7 +3441,7 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(vma))
goto err_obj;
- if (i915_ggtt_pin(vma, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
+ if (i915_ggtt_pin(vma, NULL, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
goto err_obj;
if (i915_gem_object_is_tiled(obj) &&
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 3d6bba91d073..f9fef6aab6aa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1102,7 +1102,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
i915_gem_ww_ctx_init(&ww, true);
retry:
- err = intel_context_pin(ce);
+ err = intel_context_pin_ww(ce, &ww);
if (err)
goto err;
@@ -1195,7 +1195,7 @@ static int pin_ppgtt_update(struct intel_context *ce,
struct i915_gem_ww_ctx *ww
if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
/* ppGTT is not part of the legacy context image */
- return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm), ww);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f913e3cfdb5b..574a1ac141d1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -394,7 +394,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
- if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
+ if (unlikely(i915_vma_pin_ww(vma, &eb->ww, 0, 0, pin_flags)))
return false;
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
@@ -535,7 +535,7 @@ static inline int use_cpu_reloc(const struct reloc_cache
*cache,
obj->cache_level != I915_CACHE_NONE);
}
-static int eb_reserve_vma(const struct i915_execbuffer *eb,
+static int eb_reserve_vma(struct i915_execbuffer *eb,
struct eb_vma *ev,
u64 pin_flags)
{
@@ -569,7 +569,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
return err;
}
- err = i915_vma_pin(vma,
+ err = i915_vma_pin_ww(vma, &eb->ww,
entry->pad_to_size, entry->alignment,
pin_flags);
if (err)
@@ -1033,9 +1033,10 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
}
static void *reloc_iomap(struct drm_i915_gem_object *obj,
-struct reloc_cache *cache,
+struct i915_execbuffer *eb,
unsigned long page)
{
+ struct reloc_cache *cache = &eb-
[Intel-gfx] [PATCH 17/17] drm/i915: Move i915_vma_lock in the live selftest to avoid lock inversion
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/selftests/i915_request.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..2a6052d609d9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -848,6 +848,8 @@ static int live_all_engines(void *arg)
goto out_free;
}
+ i915_vma_lock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
request[idx] = intel_engine_create_kernel_request(engine);
@@ -865,11 +867,9 @@ static int live_all_engines(void *arg)
GEM_BUG_ON(err);
request[idx]->batch = batch;
- i915_vma_lock(batch);
err = i915_request_await_object(request[idx], batch->obj, 0);
if (err == 0)
err = i915_vma_move_to_active(batch, request[idx], 0);
- i915_vma_unlock(batch);
GEM_BUG_ON(err);
i915_request_get(request[idx]);
@@ -877,6 +877,8 @@ static int live_all_engines(void *arg)
idx++;
}
+ i915_vma_unlock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
if (i915_request_completed(request[idx])) {
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/17] drm/i915: Kill last user of intel_context_create_request outside of selftests
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 7be71a1a5719..bb9f6e586530 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1707,6 +1707,7 @@ static int engine_wa_list_verify(struct intel_context *ce,
const struct i915_wa *wa;
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
unsigned int i;
u32 *results;
int err;
@@ -1719,29 +1720,34 @@ static int engine_wa_list_verify(struct intel_context
*ce,
return PTR_ERR(vma);
intel_engine_pm_get(ce->engine);
- rq = intel_context_create_request(ce);
- intel_engine_pm_put(ce->engine);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err == 0)
+ err = intel_context_pin_ww(ce, &ww);
+ if (err)
+ goto err_pm;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto err_vma;
+ goto err_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- if (err) {
- i915_request_add(rq);
- goto err_vma;
- }
-
- err = wa_list_srm(rq, wal, vma);
- if (err)
- goto err_vma;
+ if (err == 0)
+ err = wa_list_srm(rq, wal, vma);
i915_request_get(rq);
+ if (err)
+ i915_request_set_error_once(rq, err);
i915_request_add(rq);
+
+ if (err)
+ goto err_rq;
+
if (i915_request_wait(rq, 0, HZ / 5) < 0) {
err = -ETIME;
goto err_rq;
@@ -1766,7 +1772,16 @@ static int engine_wa_list_verify(struct intel_context
*ce,
err_rq:
i915_request_put(rq);
-err_vma:
+err_unpin:
+ intel_context_unpin(ce);
+err_pm:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+ intel_engine_pm_put(ce->engine);
i915_vma_unpin(vma);
i915_vma_put(vma);
return err;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/17] drm/i915: Use per object locking in execbuf, v5.
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This finally allows us to do parallel submission, but because not
all of the pinning code uses the ww ctx yet, we cannot completely
drop struct_mutex yet.
Changes since v1:
- Keep struct_mutex for now. :(
Changes since v2:
- Make sure we always lock the ww context in slowpath.
Changes since v3:
- Don't call __eb_unreserve_vma in eb_move_to_gpu now; this can be
done on normal unlock path.
- Unconditionally release vmas and context.
Changes since v4:
- Rebased on top of struct_mutex reduction.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 234 ++
1 file changed, 133 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c70026b05c26..df05abfbb81a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -249,6 +249,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
+ struct i915_gem_ww_ctx ww;
+
/**
* Track the most recently used object for relocations, as we
* frequently have to perform multiple relocations within the same
@@ -404,24 +406,18 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
-static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
-{
- GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
-
- if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- __i915_vma_unpin(vma);
-}
-
static inline void
eb_unreserve_vma(struct eb_vma *ev)
{
if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
return;
- __eb_unreserve_vma(ev->vma, ev->flags);
ev->flags &= ~__EXEC_OBJECT_RESERVED;
+
+ if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(ev->vma);
+
+ __i915_vma_unpin(ev->vma);
}
static int
@@ -515,16 +511,6 @@ eb_add_vma(struct i915_execbuffer *eb,
eb->batch = ev;
}
-
- if (eb_pin_vma(eb, entry, ev)) {
- if (entry->offset != vma->node.start) {
- entry->offset = vma->node.start | UPDATE;
- eb->args->flags |= __EXEC_HAS_RELOC;
- }
- } else {
- eb_unreserve_vma(ev);
- list_add_tail(&ev->bind_link, &eb->unbound);
- }
}
static inline int use_cpu_reloc(const struct reloc_cache *cache,
@@ -742,7 +728,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
return -ENOENT;
INIT_LIST_HEAD(&eb->relocs);
- INIT_LIST_HEAD(&eb->unbound);
batch = eb_batch_index(eb);
@@ -822,6 +807,48 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
return err;
}
+static int eb_validate_vmas(struct i915_execbuffer *eb)
+{
+ unsigned int i;
+ int err;
+
+ INIT_LIST_HEAD(&eb->unbound);
+
+ for (i = 0; i < eb->buffer_count; i++) {
+ struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
+ struct eb_vma *ev = &eb->vma[i];
+ struct i915_vma *vma = ev->vma;
+
+ err = i915_gem_object_lock(vma->obj, &eb->ww);
+ if (err)
+ return err;
+
+ if (eb_pin_vma(eb, entry, ev)) {
+ if (entry->offset != vma->node.start) {
+ entry->offset = vma->node.start | UPDATE;
+ eb->args->flags |= __EXEC_HAS_RELOC;
+ }
+ } else {
+ eb_unreserve_vma(ev);
+
+ list_add_tail(&ev->bind_link, &eb->unbound);
+ if (drm_mm_node_allocated(&vma->node)) {
+ err = i915_vma_unbind(vma);
+ if (err)
+ return err;
+ }
+ }
+
+ GEM_BUG_ON(drm_mm_node_allocated(&vma->node) &&
+ eb_vma_misplaced(&eb->exec[i], vma, ev->flags));
+ }
+
+ if (!list_empty(&eb->unbound))
+ return eb_reserve(eb);
+
+ return 0;
+}
+
static struct eb_vma *
eb_get_vma(const struct i915_execbuffer *eb, unsigned long handle)
{
@@ -842,7 +869,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long
handle)
}
}
-static void eb_release_vmas(const struct i915_execbuffer *eb)
+static void eb_release_vmas(const struct i915_execbuffer *eb, bool final)
{
const uns
[Intel-gfx] [PATCH 14/17] drm/i915: Dirty hack to fix selftests locking inversion
Some i915 selftests still use i915_vma_lock() as inner lock, and intel_context_create_request() intel_timeline->mutex as outer lock. Fortunately for selftests this is not an issue, they should be fixed but we can move ahead and cleanify lockdep now. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 9baf967c16bd..b048e4efb82c 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -455,6 +455,18 @@ struct i915_request *intel_context_create_request(struct intel_context *ce) rq = i915_request_create(ce); intel_context_unpin(ce); + if (IS_ERR(rq)) + return rq; + + /* +* timeline->mutex should be the inner lock, but is used as outer lock. +* Hack around this to shut up lockdep in selftests.. +*/ + lockdep_unpin_lock(&ce->timeline->mutex, rq->cookie); + mutex_release(&ce->timeline->mutex.dep_map, _RET_IP_); + mutex_acquire(&ce->timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, _RET_IP_); + rq->cookie = lockdep_pin_lock(&ce->timeline->mutex); + return rq; } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/17] drm/i915: Nuke arguments to eb_pin_engine
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index df05abfbb81a..848bba932e27 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2387,11 +2387,10 @@ static void eb_unpin_engine(struct i915_execbuffer *eb)
}
static unsigned int
-eb_select_legacy_ring(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_select_legacy_ring(struct i915_execbuffer *eb)
{
struct drm_i915_private *i915 = eb->i915;
+ struct drm_i915_gem_execbuffer2 *args = eb->args;
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
if (user_ring_id != I915_EXEC_BSD &&
@@ -2406,7 +2405,7 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
- bsd_idx = gen8_dispatch_bsd_engine(i915, file);
+ bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
@@ -2431,18 +2430,16 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
}
static int
-eb_pin_engine(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_pin_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce;
unsigned int idx;
int err;
if (i915_gem_context_user_engines(eb->gem_context))
- idx = args->flags & I915_EXEC_RING_MASK;
+ idx = eb->args->flags & I915_EXEC_RING_MASK;
else
- idx = eb_select_legacy_ring(eb, file, args);
+ idx = eb_select_legacy_ring(eb);
ce = i915_gem_context_get_engine(eb->gem_context, idx);
if (IS_ERR(ce))
@@ -2742,7 +2739,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_destroy;
- err = eb_pin_engine(&eb, file, args);
+ err = eb_pin_engine(&eb);
if (unlikely(err))
goto err_context;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/17] drm/i915: Convert i915_perf to ww locking as well
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_perf.c | 57 +++-
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1b074bb4a7fe..42727cf8a9f7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1242,24 +1242,39 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
struct i915_gem_engines_iter it;
struct i915_gem_context *ctx = stream->ctx;
struct intel_context *ce;
- int err;
+ struct i915_gem_ww_ctx ww;
+ int err = -ENODEV;
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
if (ce->engine != stream->engine) /* first match! */
continue;
- /*
-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*/
- err = intel_context_pin(ce);
- if (err == 0) {
- stream->pinned_ctx = ce;
- break;
- }
+ err = 0;
+ break;
}
i915_gem_context_unlock_engines(ctx);
+ if (err)
+ return ERR_PTR(err);
+
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*/
+ err = intel_context_pin_ww(ce, &ww);
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
+ if (err)
+ return ERR_PTR(err);
+
+ stream->pinned_ctx = ce;
return stream->pinned_ctx;
}
@@ -1979,15 +1994,22 @@ emit_oa_config(struct i915_perf_stream *stream,
{
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = get_oa_vma(stream, oa_config);
if (IS_ERR(vma))
return ERR_CAST(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
if (err)
- goto err_vma_put;
+ goto err;
+
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (err)
+ goto err;
intel_engine_pm_get(ce->engine);
rq = i915_request_create(ce);
@@ -1997,11 +2019,9 @@ emit_oa_config(struct i915_perf_stream *stream,
goto err_vma_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, 0);
if (!err)
err = i915_vma_move_to_active(vma, rq, 0);
- i915_vma_unlock(vma);
if (err)
goto err_add_request;
@@ -2016,7 +2036,14 @@ emit_oa_config(struct i915_perf_stream *stream,
i915_request_add(rq);
err_vma_unpin:
i915_vma_unpin(vma);
-err_vma_put:
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+
+ i915_gem_ww_ctx_fini(&ww);
i915_vma_put(vma);
return err ? ERR_PTR(err) : rq;
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/17] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_ctx and obj order in locking functions (Jonas Lahtinen)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 10 ++--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +++---
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../i915/gem/selftests/i915_gem_coherency.c | 10 ++--
.../drm/i915/gem/selftests/i915_gem_context.c | 4 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 +-
.../drm/i915/gem/selftests/i915_gem_phys.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 52 +--
drivers/gpu/drm/i915/i915_gem.h | 11
drivers/gpu/drm/i915/selftests/i915_gem.c | 41 +++
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 2 +-
26 files changed, 175 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f23c4d51c33..13b6ffcd318c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2305,7 +2305,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
{
- i915_gem_object_lock(vma->obj);
+ i915_gem_object_lock(vma->obj, NULL);
if (flags & PLANE_HAS_FENCE)
i915_vma_unpin_fence(vma);
i915_gem_object_unpin_from_display_plane(vma);
@@ -17138,7 +17138,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
if (!intel_fb->frontbuffer)
return -ENOMEM;
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
tiling = i915_gem_object_get_tiling(obj);
stride = i915_gem_object_get_stride(obj);
i915_gem_object_unlock(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 0598e5382a1d..5d94a77f9bdd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -287,7 +287,7 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
err = i915_sw_fence_await_reservation(&work->wait,
obj->base.resv, NULL,
true, I915_FENCE_TIMEOUT,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index cb6b6be48978..becccb62820e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -113,7 +113,7 @@ static void lut_close(struct i915_gem_context *ctx)
continue;
rcu_read_unlock();
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
list_for_each_entry(lut, &obj->lut_list, obj_link) {
if (lut->ctx != ctx)
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a793739d..cfadccfc2990 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -128,7 +128,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
if (err)
return err;
- err = i915_gem_object_lock_interruptible(obj);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
goto out;
@@ -149,7 +149,7 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direct
if (err)
[Intel-gfx] [PATCH 08/17] drm/i915: Pin engine before pinning all objects, v3.
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take the fastpath, if not we will take the slowpath and wait for
the throttle request while unlocked.
The engine has to be pinned as first step, otherwise gpu relocations
won't work.
Changes since v1:
- Only need to get a throttled request in the fastpath, no need for
a global flag any more.
- Always free the waited request correctly.
Changes since v2:
- Use intel_engine_pm_get()/put() to keeep engine pool alive during
EDEADLK handling.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 170 --
1 file changed, 116 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 848bba932e27..f913e3cfdb5b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -16,6 +16,7 @@
#include "gem/i915_gem_ioctls.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_pool.h"
+#include "gt/intel_engine_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_ring.h"
@@ -55,7 +56,8 @@ enum {
#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
-#define __EXEC_INTERNAL_FLAGS (~0u << 31)
+#define __EXEC_ENGINE_PINNED BIT(30)
+#define __EXEC_INTERNAL_FLAGS (~0u << 30)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -288,6 +290,9 @@ struct i915_execbuffer {
};
static int eb_parse(struct i915_execbuffer *eb);
+static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
+ bool throttle);
+static void eb_unpin_engine(struct i915_execbuffer *eb);
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
@@ -869,7 +874,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long
handle)
}
}
-static void eb_release_vmas(const struct i915_execbuffer *eb, bool final)
+static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
{
const unsigned int count = eb->buffer_count;
unsigned int i;
@@ -886,6 +891,8 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb, bool final)
if (final)
i915_vma_put(vma);
}
+
+ eb_unpin_engine(eb);
}
static void eb_destroy(const struct i915_execbuffer *eb)
@@ -1686,7 +1693,8 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb,
+ struct i915_request *rq)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1702,6 +1710,21 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
eb_release_vmas(eb, false);
i915_gem_ww_ctx_fini(&eb->ww);
+ if (rq) {
+ /* nonblocking is always false */
+ if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
+ MAX_SCHEDULE_TIMEOUT) < 0) {
+ i915_request_put(rq);
+ rq = NULL;
+
+ err = -EINTR;
+ goto err_relock;
+ }
+
+ i915_request_put(rq);
+ rq = NULL;
+ }
+
/*
* We take 3 passes through the slowpatch.
*
@@ -1725,12 +1748,22 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
err = 0;
}
+err_relock:
i915_gem_ww_ctx_init(&eb->ww, true);
if (err)
goto out;
/* reacquire the objects */
repeat_validate:
+ rq = eb_pin_engine(eb, false);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err;
+ }
+
+ /* We didn't throttle, should be NULL */
+ GEM_WARN_ON(rq);
+
err = eb_validate_vmas(eb);
if (err)
goto err;
@@ -1794,12 +1827,17 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
}
}
+ if (rq)
+ i915_request_put(rq);
+
return err;
}
static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
+ struct i915_request *rq = NULL;
+ bool throttle = true;
mutex_lock(&eb->gem_context->mutex);
err = eb_lookup_vmas(eb);
@@ -1808,6 +1846,34 @@ static int eb_relocate_parse(struct i915_execbuffer *eb)
return err;
retry:
+ rq = eb_pin_engine(eb, throttle);
+
[Intel-gfx] [PATCH 15/17] drm/i915/selftests: Fix locking inversion in lrc selftest.
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index e9e71c52b34d..43ee52a857e8 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -4283,6 +4283,7 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
{
struct intel_context *ce;
struct i915_request *rq;
+ struct i915_gem_ww_ctx ww;
enum {
RING_START_IDX = 0,
RING_TAIL_IDX,
@@ -4297,7 +4298,11 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
if (IS_ERR(ce))
return PTR_ERR(ce);
- err = intel_context_pin(ce);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(scratch->obj, &ww);
+ if (!err)
+ err = intel_context_pin_ww(ce, &ww);
if (err)
goto err_put;
@@ -4326,11 +4331,9 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
*cs++ = i915_ggtt_offset(scratch) + RING_TAIL_IDX * sizeof(u32);
*cs++ = 0;
- i915_vma_lock(scratch);
err = i915_request_await_object(rq, scratch->obj, true);
if (!err)
err = i915_vma_move_to_active(scratch, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(scratch);
i915_request_get(rq);
i915_request_add(rq);
@@ -4367,6 +4370,12 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
err_unpin:
intel_context_unpin(ce);
err_put:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
intel_context_put(ce);
return err;
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/17] drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/put() calls to fix use-after-free when using
intel_engine_get_pool().
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 80 +++--
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 156 +++---
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 3 +
3 files changed, 165 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 5d94a77f9bdd..10df576e785f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -157,6 +157,7 @@ static void clear_pages_worker(struct work_struct *work)
struct clear_pages_work *w = container_of(work, typeof(*w), work);
struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
struct i915_vma *batch;
int err = w->dma.error;
@@ -172,17 +173,20 @@ static void clear_pages_worker(struct work_struct *work)
obj->read_domains = I915_GEM_GPU_DOMAINS;
obj->write_domain = 0;
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
- if (unlikely(err))
+ i915_gem_ww_ctx_init(&ww, false);
+ intel_engine_pm_get(w->ce->engine);
+retry:
+ err = intel_context_pin_ww(w->ce, &ww);
+ if (err)
goto out_signal;
- batch = intel_emit_vma_fill_blt(w->ce, vma, w->value);
+ batch = intel_emit_vma_fill_blt(w->ce, vma, &ww, w->value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
- goto out_unpin;
+ goto out_ctx;
}
- rq = intel_context_create_request(w->ce);
+ rq = i915_request_create(w->ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto out_batch;
@@ -224,9 +228,19 @@ static void clear_pages_worker(struct work_struct *work)
i915_request_add(rq);
out_batch:
intel_emit_vma_release(w->ce, batch);
-out_unpin:
- i915_vma_unpin(vma);
+out_ctx:
+ intel_context_unpin(w->ce);
out_signal:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
+ i915_vma_unpin(w->sleeve->vma);
+ intel_engine_pm_put(w->ce->engine);
+
if (unlikely(err)) {
dma_fence_set_error(&w->dma, err);
dma_fence_signal(&w->dma);
@@ -234,6 +248,45 @@ static void clear_pages_worker(struct work_struct *work)
}
}
+static int pin_wait_clear_pages_work(struct clear_pages_work *w,
+struct intel_context *ce)
+{
+ struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err)
+ goto out;
+
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
+ if (unlikely(err))
+ goto out;
+
+ err = i915_sw_fence_await_reservation(&w->wait,
+ vma->obj->base.resv, NULL,
+ true, I915_FENCE_TIMEOUT,
+ I915_FENCE_GFP);
+ if (err)
+ goto err_unpin_vma;
+
+ dma_resv_add_excl_fence(vma->obj->base.resv, &w->dma);
+
+err_unpin_vma:
+ if (err)
+ i915_vma_unpin(vma);
+out:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+ return err;
+}
+
static int __i915_sw_fence_call
clear_pages_work_notify(struct i915_sw_fence *fence,
enum i915_sw_fence_notify state)
@@ -287,18 +340,9 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
- i915_gem_object_lock(obj, NULL);
- err = i915_sw_fence_await_reservation(&work->wait,
- obj->base.resv, NULL,
- true, I915_FENCE_TIMEOUT,
- I915_FENCE_GFP);
- if (err < 0) {
+ err = pin_wait_clear_pages_work(work, ce);
+ if (err < 0)
dma_fence_set_error(&work->dma, err);
- } else {
- dma_resv_add_e
[Intel-gfx] [PATCH 06/17] drm/i915: Add ww context handling to context_barrier_task
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index becccb62820e..3d6bba91d073 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1061,12 +1061,14 @@ I915_SELFTEST_DECLARE(static intel_engine_mask_t
context_barrier_inject_fault);
static int context_barrier_task(struct i915_gem_context *ctx,
intel_engine_mask_t engines,
bool (*skip)(struct intel_context *ce, void
*data),
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
int (*emit)(struct i915_request *rq, void
*data),
void (*task)(void *data),
void *data)
{
struct context_barrier_task *cb;
struct i915_gem_engines_iter it;
+ struct i915_gem_ww_ctx ww;
struct intel_context *ce;
int err = 0;
@@ -1098,10 +1100,21 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
if (skip && skip(ce, data))
continue;
- rq = intel_context_create_request(ce);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ if (pin)
+ err = pin(ce, &ww, data);
+ if (err)
+ goto err_unpin;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- break;
+ goto err_unpin;
}
err = 0;
@@ -,6 +1124,16 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
err = i915_active_add_request(&cb->base, rq);
i915_request_add(rq);
+err_unpin:
+ intel_context_unpin(ce);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
if (err)
break;
}
@@ -1166,6 +1189,17 @@ static void set_ppgtt_barrier(void *data)
i915_vm_close(old);
}
+static int pin_ppgtt_update(struct intel_context *ce, struct i915_gem_ww_ctx
*ww, void *data)
+{
+ struct i915_address_space *vm = ce->vm;
+
+ if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
+ /* ppGTT is not part of the legacy context image */
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+
+ return 0;
+}
+
static int emit_ppgtt_update(struct i915_request *rq, void *data)
{
struct i915_address_space *vm = rq->context->vm;
@@ -1222,20 +1256,10 @@ static int emit_ppgtt_update(struct i915_request *rq,
void *data)
static bool skip_ppgtt_update(struct intel_context *ce, void *data)
{
- if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
- return true;
-
if (HAS_LOGICAL_RING_CONTEXTS(ce->engine->i915))
- return false;
-
- if (!atomic_read(&ce->pin_count))
- return true;
-
- /* ppGTT is not part of the legacy context image */
- if (gen6_ppgtt_pin(i915_vm_to_ppgtt(ce->vm)))
- return true;
-
- return false;
+ return !ce->state;
+ else
+ return !atomic_read(&ce->pin_count);
}
static int set_ppgtt(struct drm_i915_file_private *file_priv,
@@ -1286,6 +1310,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
*/
err = context_barrier_task(ctx, ALL_ENGINES,
skip_ppgtt_update,
+ pin_ppgtt_update,
emit_ppgtt_update,
set_ppgtt_barrier,
old);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 406f26470457..b710ad7344d7 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1904,8 +1904,8 @@ static int mock_context_barrier(void *arg)
return -ENOMEM;
counter = 0;
- err = context_barrier_task(ctx, 0,
- NULL, NULL, mock_barrier_task, &counter);
+ err = context_barrier_task(ctx, 0, NULL, NULL, NULL,
+
[Intel-gfx] [PATCH 09/17] drm/i915: Rework intel_context pinning to do everything outside of pin_mutex
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us to take pin refcounts correctly
all the time.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 223 +++---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 ++-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 1 -
.../gpu/drm/i915/gt/intel_ring_submission.c | 13 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 13 +-
6 files changed, 186 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 01474d3a558b..f304fab1b619 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -93,74 +93,6 @@ static void intel_context_active_release(struct
intel_context *ce)
i915_active_release(&ce->active);
}
-int __intel_context_do_pin(struct intel_context *ce)
-{
- int err;
-
- if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
- err = intel_context_alloc_state(ce);
- if (err)
- return err;
- }
-
- err = i915_active_acquire(&ce->active);
- if (err)
- return err;
-
- if (mutex_lock_interruptible(&ce->pin_mutex)) {
- err = -EINTR;
- goto out_release;
- }
-
- if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
- err = intel_context_active_acquire(ce);
- if (unlikely(err))
- goto out_unlock;
-
- err = ce->ops->pin(ce);
- if (unlikely(err))
- goto err_active;
-
- CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
-ce->ring->head, ce->ring->tail);
-
- smp_mb__before_atomic(); /* flush pin before it is visible */
- atomic_inc(&ce->pin_count);
- }
-
- GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
- GEM_BUG_ON(i915_active_is_idle(&ce->active));
- goto out_unlock;
-
-err_active:
- intel_context_active_release(ce);
-out_unlock:
- mutex_unlock(&ce->pin_mutex);
-out_release:
- i915_active_release(&ce->active);
- return err;
-}
-
-void intel_context_unpin(struct intel_context *ce)
-{
- if (!atomic_dec_and_test(&ce->pin_count))
- return;
-
- CE_TRACE(ce, "unpin\n");
- ce->ops->unpin(ce);
-
- /*
-* Once released, we may asynchronously drop the active reference.
-* As that may be the only reference keeping the context alive,
-* take an extra now so that it is not freed before we finish
-* dereferencing it.
-*/
- intel_context_get(ce);
- intel_context_active_release(ce);
- intel_context_put(ce);
-}
-
static int __context_pin_state(struct i915_vma *vma)
{
unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
@@ -220,6 +152,133 @@ static void __ring_retire(struct intel_ring *ring)
i915_active_release(&ring->vma->active);
}
+static int intel_context_pre_pin(struct intel_context *ce)
+{
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ err = __ring_active(ce->ring);
+ if (err)
+ return err;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+ return err;
+}
+
+static void intel_context_post_unpin(struct intel_context *ce)
+{
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+}
+
+int __intel_context_do_pin(struct intel_context *ce)
+{
+ bool handoff = false;
+ void *vaddr;
+ int err = 0;
+
+ if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
+ err = intel_context_alloc_state(ce);
+ if (err)
+ return err;
+ }
+
+ /*
+* We always pin the context/ring/timeline here, to ensure a pin
+* refcount for __intel_context_active(), which prevent a lock
+* inversion of ce->pin_mutex vs dma_resv_lock().
+*/
+ err = intel_context_pre_pin(ce);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(&ce->active);
+ if (err)
+
[Intel-gfx] [PATCH 02/17] drm/i915: Remove locking from i915_gem_object_prepare_read/write
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 20 ++-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 -
.../gpu/drm/i915/gem/selftests/huge_pages.c | 5 -
.../i915/gem/selftests/i915_gem_coherency.c | 14 +
.../drm/i915/gem/selftests/i915_gem_context.c | 12 ---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 5 -
drivers/gpu/drm/i915/gvt/cmd_parser.c | 9 -
drivers/gpu/drm/i915/i915_gem.c | 20 +--
9 files changed, 70 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index f4602faa8db9..e9d3b587f562 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -581,19 +581,17 @@ int i915_gem_object_prepare_read(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -621,8 +619,6 @@ int i915_gem_object_prepare_read(struct drm_i915_gem_object
*obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
@@ -635,20 +631,18 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_ALL,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -685,7 +679,5 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 80598f929717..a1a2f6e8b7bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -920,11 +920,14 @@ static void reloc_cache_reset(struct reloc_cache *cache)
vaddr = unmask_page(cache->vaddr);
if (cache->vaddr & KMAP) {
+ struct drm_i915_gem_object *obj =
+ (struct drm_i915_gem_object *)cache->node.mm;
if (cache->vaddr & CLFLUSH_AFTER)
mb();
kunmap_atomic(vaddr);
- i915_gem_object_finish_access((struct drm_i915_gem_object
*)cache->node.mm);
+ i915_gem_object_finish_access(obj);
+ i915_gem_object_unlock(obj);
} else {
struct i915_ggtt *ggtt = cache_to_ggtt(cache);
@@ -959,10 +962,16 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
unsigned int flushes;
int err;
- err = i915_gem_object_prepare_write(obj, &flushes);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
return ERR_PTR(err);
+ err = i915_gem_object_prepare_write(obj, &flushes);
+ if (err) {
+ i915_gem_object_unlock(obj);
+ return ERR_PTR(err);
+ }
+
BUILD_BUG_ON(KMAP & CLFLUSH_FLAGS);
BUILD_BUG_ON((KMAP | CLFLUSH_FLAGS) & PAGE_MASK);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 5103067269b0..11b8e273507
[Intel-gfx] [PATCH 05/17] drm/i915: Use ww locking in intel_renderstate.
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_gt.c | 21 +++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 71 ++---
drivers/gpu/drm/i915/gt/intel_renderstate.h | 9 ++-
3 files changed, 65 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index d3e36a3b1d93..57dfa18da26a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -406,21 +406,20 @@ static int __engines_record_defaults(struct intel_gt *gt)
/* We must be able to switch to something! */
GEM_BUG_ON(!engine->kernel_context);
- err = intel_renderstate_init(&so, engine);
- if (err)
- goto out;
-
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
err = PTR_ERR(ce);
goto out;
}
- rq = intel_context_create_request(ce);
+ err = intel_renderstate_init(&so, ce);
+ if (err)
+ goto err;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- intel_context_put(ce);
- goto out;
+ goto err_fini;
}
err = intel_engine_emit_ctx_wa(rq);
@@ -434,9 +433,13 @@ static int __engines_record_defaults(struct intel_gt *gt)
err_rq:
requests[id] = i915_request_get(rq);
i915_request_add(rq);
- intel_renderstate_fini(&so);
- if (err)
+err_fini:
+ intel_renderstate_fini(&so, ce);
+err:
+ if (err) {
+ intel_context_put(ce);
goto out;
+ }
}
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index fff61e86cfbf..09ea4d0a14f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -27,6 +27,7 @@
#include "i915_drv.h"
#include "intel_renderstate.h"
+#include "gt/intel_context.h"
#include "intel_ring.h"
static const struct intel_renderstate_rodata *
@@ -74,10 +75,9 @@ static int render_state_setup(struct intel_renderstate *so,
u32 *d;
int ret;
- i915_gem_object_lock(so->vma->obj, NULL);
ret = i915_gem_object_prepare_write(so->vma->obj, &needs_clflush);
if (ret)
- goto out_unlock;
+ return ret;
d = kmap_atomic(i915_gem_object_get_dirty_page(so->vma->obj, 0));
@@ -158,8 +158,6 @@ static int render_state_setup(struct intel_renderstate *so,
ret = 0;
out:
i915_gem_object_finish_access(so->vma->obj);
-out_unlock:
- i915_gem_object_unlock(so->vma->obj);
return ret;
err:
@@ -171,33 +169,47 @@ static int render_state_setup(struct intel_renderstate
*so,
#undef OUT_BATCH
int intel_renderstate_init(struct intel_renderstate *so,
- struct intel_engine_cs *engine)
+ struct intel_context *ce)
{
- struct drm_i915_gem_object *obj;
+ struct intel_engine_cs *engine = ce->engine;
+ struct drm_i915_gem_object *obj = NULL;
int err;
memset(so, 0, sizeof(*so));
so->rodata = render_state_get_rodata(engine);
- if (!so->rodata)
- return 0;
+ if (so->rodata) {
+ if (so->rodata->batch_items * 4 > PAGE_SIZE)
+ return -EINVAL;
+
+ obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
+ if (IS_ERR(so->vma)) {
+ err = PTR_ERR(so->vma);
+ goto err_obj;
+ }
+ }
- if (so->rodata->batch_items * 4 > PAGE_SIZE)
- return -EINVAL;
+ i915_gem_ww_ctx_init(&so->ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err_fini;
- obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ /* return early if there's nothing to setup */
+ if (!err && !so->rodata)
+ return 0;
- so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
- if (
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: properly sanity check batch_start_offset (rev3)
== Series Details == Series: drm/i915: properly sanity check batch_start_offset (rev3) URL : https://patchwork.freedesktop.org/series/74287/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: properly sanity check batch_start_offset (rev3)
== Series Details ==
Series: drm/i915: properly sanity check batch_start_offset (rev3)
URL : https://patchwork.freedesktop.org/series/74287/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8080 -> Patchwork_16857
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16857 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16857, 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_16857/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16857:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-hsw-peppy: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16857/fi-hsw-peppy/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live@ring_submission}:
- fi-hsw-peppy: [PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8080/fi-hsw-peppy/igt@i915_selftest@live@ring_submission.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16857/fi-hsw-peppy/igt@i915_selftest@live@ring_submission.html
Known issues
Here are the changes found in Patchwork_16857 that come from known issues:
### IGT changes ###
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][4] ([fdo#111096] / [i915#323]) -> [FAIL][5]
([fdo#111407])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8080/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16857/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
Participating hosts (47 -> 38)
--
Additional (3): fi-kbl-7560u fi-ivb-3770 fi-snb-2520m
Missing(12): fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan
fi-bwr-2160 fi-ctg-p8600 fi-kbl-x1275 fi-bsw-kefka fi-tgl-y fi-byt-clapper
fi-bsw-nick fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8080 -> Patchwork_16857
CI-20190529: 20190529
CI_DRM_8080: d122b6eaf8f3999f69ddd9cfde05cc0775e0e68e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5495: 22df72de8affcec22d9f354bb6148d77f60cc580 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16857: 6cf293eddb7782075741dead5b40957d991d2400 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6cf293eddb77 drm/i915: properly sanity check batch_start_offset
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16857/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/17] drm/i915/gt: Declare when we enabled timeslicing
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine.h | 3 ++-
drivers/gpu/drm/i915/gt/intel_engine_user.c | 5 +
include/uapi/drm/i915_drm.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 29c8c03c5caa..a32dc82a90d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -326,7 +326,8 @@ intel_engine_has_timeslices(const struct intel_engine_cs
*engine)
if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
return false;
- return intel_engine_has_semaphores(engine);
+ return (intel_engine_has_semaphores(engine) &&
+ intel_engine_has_preemption(engine));
}
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 848decee9066..b84fdd722781 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -121,6 +121,11 @@ static void set_scheduler_caps(struct drm_i915_private
*i915)
else
disabled |= BIT(map[i].sched);
}
+
+ if (intel_engine_has_timeslices(engine))
+ enabled |= I915_SCHEDULER_CAP_TIMESLICING;
+ else
+ disabled |= I915_SCHEDULER_CAP_TIMESLICING;
}
i915->caps.scheduler = enabled & ~disabled;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3a24817ca25b..ff7be293ec31 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -523,6 +523,7 @@ typedef struct drm_i915_irq_wait {
#define I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
#define I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
#define I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
+#define I915_SCHEDULER_CAP_TIMESLICING (1ul << 5)
#define I915_PARAM_HUC_STATUS 42
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/17] drm/i915/gem: Teach execbuf how to wait on future syncobj
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 0893ce781a84..3c427bdfbb2d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -2491,8 +2492,24 @@ await_fence_array(struct i915_execbuffer *eb,
continue;
fence = drm_syncobj_fence_get(syncobj);
- if (!fence)
- return -EINVAL;
+ if (!fence) {
+ struct dma_fence *old;
+
+ fence = dma_fence_create_proxy();
+ if (!fence)
+ return -ENOMEM;
+
+ spin_lock(&syncobj->lock);
+ old = rcu_dereference_protected(syncobj->fence, true);
+ if (unlikely(old)) {
+ dma_fence_put(fence);
+ fence = dma_fence_get(old);
+ } else {
+ rcu_assign_pointer(syncobj->fence,
+ dma_fence_get(fence));
+ }
+ spin_unlock(&syncobj->lock);
+ }
err = i915_request_await_dma_fence(eb->request, fence);
dma_fence_put(fence);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/17] dma-buf: Proxy fence, an unsignaled fence placeholder
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real fence completes, and any future listeners will instead be
attach directly to the real fence avoiding any indirection overhead.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/dma-buf/Makefile | 13 +-
drivers/dma-buf/dma-fence-private.h | 20 +
drivers/dma-buf/dma-fence-proxy.c| 189 +
drivers/dma-buf/dma-fence.c | 4 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-proxy.c | 581 +++
include/linux/dma-fence-proxy.h | 20 +
7 files changed, 824 insertions(+), 4 deletions(-)
create mode 100644 drivers/dma-buf/dma-fence-private.h
create mode 100644 drivers/dma-buf/dma-fence-proxy.c
create mode 100644 drivers/dma-buf/st-dma-fence-proxy.c
create mode 100644 include/linux/dma-fence-proxy.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 995e05f609ff..afaf6dadd9a3 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,6 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
-dma-resv.o seqno-fence.o
+obj-y := \
+ dma-buf.o \
+ dma-fence.o \
+ dma-fence-array.o \
+ dma-fence-chain.o \
+ dma-fence-proxy.o \
+ dma-resv.o \
+ seqno-fence.o
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
@@ -10,6 +16,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
dmabuf_selftests-y := \
selftest.o \
st-dma-fence.o \
- st-dma-fence-chain.o
+ st-dma-fence-chain.o \
+ st-dma-fence-proxy.o
obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/dma-fence-private.h
b/drivers/dma-buf/dma-fence-private.h
new file mode 100644
index ..6924d28af0fa
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-private.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Fence mechanism for dma-buf and to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Canonical Ltd
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Authors:
+ * Rob Clark
+ * Maarten Lankhorst
+ */
+
+#ifndef DMA_FENCE_PRIVATE_H
+#define DMA_FENCE_PRIAVTE_H
+
+struct dma_fence;
+
+bool __dma_fence_enable_signaling(struct dma_fence *fence);
+
+#endif /* DMA_FENCE_PRIAVTE_H */
diff --git a/drivers/dma-buf/dma-fence-proxy.c
b/drivers/dma-buf/dma-fence-proxy.c
new file mode 100644
index ..6dce543d0757
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-proxy.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * dma-fence-proxy: placeholder unsignaled fence
+ *
+ * Copyright (C) 2017-2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "dma-fence-private.h"
+
+struct dma_fence_proxy {
+ struct dma_fence base;
+ spinlock_t lock;
+
+ struct dma_fence *real;
+ struct dma_fence_cb cb;
+ struct irq_work work;
+};
+
+static const char *proxy_get_driver_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_driver_name(real) : "proxy";
+}
+
+static const char *proxy_get_timeline_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_timeline_name(real) : "unset";
+}
+
+static void proxy_irq_work(struct irq_work *work)
+{
+ struct dma_fence_proxy *p = container_of(work, typeof(*p), work);
+
+ dma_fence_signal(&p->base);
+ dma_fence_put(&p->base);
+}
+
+static void proxy_callback(struct dma_fence *real, struct dma_fence_cb *cb)
+{
+ struct dma_fence_proxy *p = container_of(cb, typeof(*p), cb);
+
+ if (real->error)
+ dma_fence_set_error(&p->base, real->error);
+
+ /* Lower the height of the proxy chain -> single stack frame */
+ irq_work_queue(&p->work);
+}
+
+static bool proxy_enable_signaling(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+ bool ret = true;
+
+ if (real) {
+ spin_lock_nested(real->lock, SINGLE_DEPTH_NESTING);
+ ret = __dma_fence_enable_signaling(real);
+ spin_unlock(real->lock);
+ }
+
+ return ret;
+}
+
+static void proxy_release(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof
[Intel-gfx] [PATCH 01/17] drm/i915/selftests: Apply a heavy handed flush to i915_active
Due to the ordering of cmpxchg()/dma_fence_signal() inside node_retire(),
we must also use the xchg() as our primary memory barrier to flush the
outstanding callbacks after expected completion of the i915_active.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_active.c | 29 ++--
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 3a37c67ab6c4..68bbb1580162 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -311,20 +311,33 @@ static void spin_unlock_wait(spinlock_t *lock)
spin_unlock_irq(lock);
}
+static void active_flush(struct i915_active *ref,
+struct i915_active_fence *active)
+{
+ struct dma_fence *fence;
+
+ fence = xchg(__active_fence_slot(active), NULL);
+ if (!fence)
+ return;
+
+ spin_lock_irq(fence->lock);
+ __list_del_entry(&active->cb.node);
+ spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
+ atomic_dec(&ref->count);
+
+ GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
+}
+
void i915_active_unlock_wait(struct i915_active *ref)
{
if (i915_active_acquire_if_busy(ref)) {
struct active_node *it, *n;
+ /* Wait for all active callbacks */
rcu_read_lock();
- rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
- struct dma_fence *f;
-
- /* Wait for all active callbacks */
- f = rcu_dereference(it->base.fence);
- if (f)
- spin_unlock_wait(f->lock);
- }
+ active_flush(ref, &ref->excl);
+ rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node)
+ active_flush(ref, &it->base);
rcu_read_unlock();
i915_active_release(ref);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/17] drm/i915: Extend i915_request_await_active to use all timelines
Extend i915_request_await_active() to be able to asynchronously wait on
all the tracked timelines simultaneously.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 51 +++---
drivers/gpu/drm/i915/i915_active.h | 5 ++-
drivers/gpu/drm/i915/i915_vma.c| 2 +-
3 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 1826de14d2da..e659688db043 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -518,23 +518,52 @@ int i915_active_wait(struct i915_active *ref)
return 0;
}
-int i915_request_await_active(struct i915_request *rq, struct i915_active *ref)
+static int await_active(struct i915_request *rq,
+ struct i915_active_fence *active)
+{
+ struct dma_fence *fence;
+
+ if (is_barrier(active))
+ return 0;
+
+ fence = i915_active_fence_get(active);
+ if (fence) {
+ int err;
+
+ err = i915_request_await_dma_fence(rq, fence);
+ dma_fence_put(fence);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
+}
+
+int i915_request_await_active(struct i915_request *rq,
+ struct i915_active *ref,
+ unsigned int flags)
{
int err = 0;
+ /* We must always wait for the exclusive fence! */
if (rcu_access_pointer(ref->excl.fence)) {
- struct dma_fence *fence;
-
- rcu_read_lock();
- fence = dma_fence_get_rcu_safe(&ref->excl.fence);
- rcu_read_unlock();
- if (fence) {
- err = i915_request_await_dma_fence(rq, fence);
- dma_fence_put(fence);
- }
+ err = await_active(rq, &ref->excl);
+ if (err)
+ return err;
}
- /* In the future we may choose to await on all fences */
+ if (flags & I915_ACTIVE_AWAIT_ALL && i915_active_acquire_if_busy(ref)) {
+ struct active_node *it, *n;
+
+ rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
+ err = await_active(rq, &it->base);
+ if (err)
+ break;
+ }
+ i915_active_release(ref);
+ if (err)
+ return err;
+ }
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 7e438501333e..e3c13060c4c7 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -183,7 +183,10 @@ static inline bool i915_active_has_exclusive(struct
i915_active *ref)
int i915_active_wait(struct i915_active *ref);
-int i915_request_await_active(struct i915_request *rq, struct i915_active
*ref);
+int i915_request_await_active(struct i915_request *rq,
+ struct i915_active *ref,
+ unsigned int flags);
+#define I915_ACTIVE_AWAIT_ALL BIT(0)
int i915_active_acquire(struct i915_active *ref);
bool i915_active_acquire_if_busy(struct i915_active *ref);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 3dde671145f7..5b3efb43a8ef 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1173,7 +1173,7 @@ int __i915_vma_move_to_active(struct i915_vma *vma,
struct i915_request *rq)
GEM_BUG_ON(!i915_vma_is_pinned(vma));
/* Wait for the vma to be bound before we start! */
- err = i915_request_await_active(rq, &vma->active);
+ err = i915_request_await_active(rq, &vma->active, 0);
if (err)
return err;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/17] dma-buf: Report signaled links inside dma-fence-chain
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element in a dma-fence-chain.
Report a NULL fence and success if the seqno has already been signaled.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence-chain.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index 3d123502ff12..c435bbba851c 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -99,6 +99,12 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence,
uint64_t seqno)
return -EINVAL;
dma_fence_chain_for_each(*pfence, &chain->base) {
+ if ((*pfence)->seqno < seqno) { /* already signaled */
+ dma_fence_put(*pfence);
+ *pfence = NULL;
+ break;
+ }
+
if ((*pfence)->context != chain->base.context ||
to_dma_fence_chain(*pfence)->prev_seqno < seqno)
break;
@@ -222,6 +228,7 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
* @chain: the chain node to initialize
* @prev: the previous fence
* @fence: the current fence
+ * @seqno: the sequence number (syncpt) of the fence within the chain
*
* Initialize a new chain node and either start a new chain or add the node to
* the existing chain of the previous fence.
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/17] dma-buf: Prettify typecasts for dma-fence-chain
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To avoid the sparse warning for using the RCU pointer directly, we have to cast away the __rcu annotation. However, we don't need to use void* everywhere and can stick to the dma_fence*. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/dma-buf/dma-fence-chain.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index 44a741677d25..3d123502ff12 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -62,7 +62,8 @@ struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence) replacement = NULL; } - tmp = cmpxchg((void **)&chain->prev, (void *)prev, (void *)replacement); + tmp = cmpxchg((struct dma_fence __force **)&chain->prev, + prev, replacement); if (tmp == prev) dma_fence_put(tmp); else -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/17] drm/i915/gem: Allow combining submit-fences with syncobj
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3c427bdfbb2d..96a1f36f161c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2456,7 +2456,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
- fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+ fences[n] = ptr_pack_bits(syncobj, fence.flags, 3);
}
return fences;
@@ -2487,7 +2487,7 @@ await_fence_array(struct i915_execbuffer *eb,
struct dma_fence *fence;
unsigned int flags;
- syncobj = ptr_unpack_bits(fences[n], &flags, 2);
+ syncobj = ptr_unpack_bits(fences[n], &flags, 3);
if (!(flags & I915_EXEC_FENCE_WAIT))
continue;
@@ -2511,7 +2511,11 @@ await_fence_array(struct i915_execbuffer *eb,
spin_unlock(&syncobj->lock);
}
- err = i915_request_await_dma_fence(eb->request, fence);
+ if (flags & I915_EXEC_FENCE_WAIT_SUBMIT)
+ err = i915_request_await_execution(eb->request, fence,
+
eb->engine->bond_execute);
+ else
+ err = i915_request_await_dma_fence(eb->request, fence);
dma_fence_put(fence);
if (err < 0)
return err;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 2813e579b480..3a24817ca25b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1040,9 +1040,10 @@ struct drm_i915_gem_exec_fence {
*/
__u32 handle;
-#define I915_EXEC_FENCE_WAIT(1<<0)
-#define I915_EXEC_FENCE_SIGNAL (1<<1)
-#define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SIGNAL << 1))
+#define I915_EXEC_FENCE_WAIT(1u << 0)
+#define I915_EXEC_FENCE_SIGNAL (1u << 1)
+#define I915_EXEC_FENCE_WAIT_SUBMIT (1u << 2)
+#define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_WAIT_SUBMIT << 1))
__u32 flags;
};
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/17] drm/i915/perf: Schedule oa_config after modifying the contexts
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct context to the state modifications, we need that command packet
to be always last in the queue.
We borrow the i915_active for its ability to track multiple timelines
and the last dma_fence on each; a flexible dma_resv. Keeping track of
each dma_fence is important for us so that we can efficiently schedule
the requests and reprioritise as required.
Reported-by: Lionel Landwerlin
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/display/intel_overlay.c | 8 +-
drivers/gpu/drm/i915/gt/intel_context_param.c | 2 +-
drivers/gpu/drm/i915/i915_active.c| 6 +-
drivers/gpu/drm/i915/i915_active.h| 2 +-
drivers/gpu/drm/i915/i915_perf.c | 154 +++---
drivers/gpu/drm/i915/i915_perf_types.h| 5 +-
drivers/gpu/drm/i915/i915_vma.h | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 4 +-
8 files changed, 115 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 3b0cb3534e2a..733dcfc28a05 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -272,7 +272,7 @@ static int intel_overlay_on(struct intel_overlay *overlay)
i915_request_add(rq);
- return i915_active_wait(&overlay->last_flip);
+ return i915_active_wait(&overlay->last_flip, TASK_INTERRUPTIBLE);
}
static void intel_overlay_flip_prepare(struct intel_overlay *overlay,
@@ -429,14 +429,14 @@ static int intel_overlay_off(struct intel_overlay
*overlay)
intel_overlay_flip_prepare(overlay, NULL);
i915_request_add(rq);
- return i915_active_wait(&overlay->last_flip);
+ return i915_active_wait(&overlay->last_flip, TASK_INTERRUPTIBLE);
}
/* recover from an interruption due to a signal
* We have to be careful not to repeat work forever an make forward progess. */
static int intel_overlay_recover_from_interrupt(struct intel_overlay *overlay)
{
- return i915_active_wait(&overlay->last_flip);
+ return i915_active_wait(&overlay->last_flip, TASK_INTERRUPTIBLE);
}
/* Wait for pending overlay flip and release old frame.
@@ -477,7 +477,7 @@ static int intel_overlay_release_old_vid(struct
intel_overlay *overlay)
i915_request_add(rq);
- return i915_active_wait(&overlay->last_flip);
+ return i915_active_wait(&overlay->last_flip, TASK_INTERRUPTIBLE);
}
void intel_overlay_reset(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_param.c
b/drivers/gpu/drm/i915/gt/intel_context_param.c
index 65dcd090245d..903cce8c23c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_param.c
+++ b/drivers/gpu/drm/i915/gt/intel_context_param.c
@@ -15,7 +15,7 @@ int intel_context_set_ring_size(struct intel_context *ce,
long sz)
if (intel_context_lock_pinned(ce))
return -EINTR;
- err = i915_active_wait(&ce->active);
+ err = i915_active_wait(&ce->active, TASK_INTERRUPTIBLE);
if (err < 0)
goto unlock;
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index e659688db043..12943301df3d 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -496,7 +496,7 @@ static int flush_lazy_signals(struct i915_active *ref)
return err;
}
-int i915_active_wait(struct i915_active *ref)
+int i915_active_wait(struct i915_active *ref, int state)
{
int err;
@@ -511,7 +511,9 @@ int i915_active_wait(struct i915_active *ref)
if (err)
return err;
- if (wait_var_event_interruptible(ref, i915_active_is_idle(ref)))
+ if (!i915_active_is_idle(ref) &&
+ ___wait_var_event(ref, i915_active_is_idle(ref),
+ state, 0, 0, schedule()))
return -EINTR;
flush_work(&ref->work);
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index e3c13060c4c7..69b5f7a76488 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -181,7 +181,7 @@ static inline bool i915_active_has_exclusive(struct
i915_active *ref)
return rcu_access_pointer(ref->excl.fence);
}
-int i915_active_wait(struct i915_active *ref);
+int i915_active_wait(struct i915_active *ref, int state);
int i915_request_await_active(struct i915_request *rq,
struct i915_active *ref,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1b074bb4a7fe..214e72670738 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
++
[Intel-gfx] [PATCH 17/17] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.
v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 +++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 40 +---
drivers/gpu/drm/i915/i915_reg.h | 1 +
5 files changed, 61 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 53ac3f00909a..c93a805eddfb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1290,6 +1290,12 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
if (engine->id == RENDER_CLASS && IS_GEN_RANGE(dev_priv, 4, 7))
drm_printf(m, "\tCCID: 0x%08x\n", ENGINE_READ(engine, CCID));
+ if (HAS_EXECLISTS(dev_priv)) {
+ drm_printf(m, "\tEL_STAT_HI: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_HI));
+ drm_printf(m, "\tEL_STAT_LO: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_LO));
+ }
drm_printf(m, "\tRING_START: 0x%08x\n",
ENGINE_READ(engine, RING_START));
drm_printf(m, "\tRING_HEAD: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 80cdde712842..ac283ab5d89c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -156,6 +156,15 @@ struct intel_engine_execlists {
*/
struct i915_priolist default_priolist;
+ /**
+* @yield: CCID at the time of the last semaphore-wait interrupt.
+*
+* Instead of leaving a semaphore busy-spinning on an engine, we would
+* like to switch to another ready context, i.e. yielding the semaphore
+* timeslice.
+*/
+ u32 yield;
+
/**
* @error_interrupt: CS Master EIR
*
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f0e7fd95165a..875bd0392ffc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -39,6 +39,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
}
}
+ if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
+ WRITE_ONCE(engine->execlists.yield,
+ ENGINE_READ_FW(engine, RING_EXECLIST_STATUS_HI));
+ if (del_timer(&engine->execlists.timer))
+ tasklet = true;
+ }
+
if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
tasklet = true;
@@ -228,7 +235,8 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
const u32 dmask = irqs << 16 | irqs;
const u32 smask = irqs << 16;
@@ -366,7 +374,8 @@ void gen8_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
const u32 gt_interrupts[] = {
irqs << GEN8_RCS_IRQ_SHIFT | irqs << GEN8_BCS_IRQ_SHIFT,
irqs << GEN8_VCS0_IRQ_SHIFT | irqs << GEN8_VCS1_IRQ_SHIFT,
diff --git a/drivers/gpu/drm/i915/gt/inte
[Intel-gfx] [PATCH 13/17] drm/syncobj: Allow use of dma-fence-proxy
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 42d46414f767..e141db0e1eb6 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -184,6 +184,7 @@
*/
#include
+#include
#include
#include
#include
@@ -324,14 +325,9 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *old_fence;
struct syncobj_wait_entry *cur, *tmp;
- if (fence)
- dma_fence_get(fence);
-
spin_lock(&syncobj->lock);
- old_fence = rcu_dereference_protected(syncobj->fence,
- lockdep_is_held(&syncobj->lock));
- rcu_assign_pointer(syncobj->fence, fence);
+ old_fence = dma_fence_replace_proxy(&syncobj->fence, fence);
if (fence != old_fence) {
list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/17] drm/i915: Wrap i915_active in a simple kreffed struct
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 53 ++
drivers/gpu/drm/i915/i915_active.h | 4 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 7b3d6c12ad61..1826de14d2da 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -881,6 +881,59 @@ void i915_active_noop(struct dma_fence *fence, struct
dma_fence_cb *cb)
active_fence_cb(fence, cb);
}
+struct auto_active {
+ struct i915_active base;
+ struct kref ref;
+};
+
+struct i915_active *i915_active_get(struct i915_active *ref)
+{
+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
+
+ kref_get(&aa->ref);
+ return &aa->base;
+}
+
+static void auto_release(struct kref *ref)
+{
+ struct auto_active *aa = container_of(ref, typeof(*aa), ref);
+
+ i915_active_fini(&aa->base);
+ kfree(aa);
+}
+
+void i915_active_put(struct i915_active *ref)
+{
+ struct auto_active *aa = container_of(ref, typeof(*aa), base);
+
+ kref_put(&aa->ref, auto_release);
+}
+
+static int auto_active(struct i915_active *ref)
+{
+ i915_active_get(ref);
+ return 0;
+}
+
+static void auto_retire(struct i915_active *ref)
+{
+ i915_active_put(ref);
+}
+
+struct i915_active *i915_active_create(void)
+{
+ struct auto_active *aa;
+
+ aa = kmalloc(sizeof(*aa), GFP_KERNEL);
+ if (!aa)
+ return NULL;
+
+ kref_init(&aa->ref);
+ i915_active_init(&aa->base, auto_active, auto_retire);
+
+ return &aa->base;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/i915_active.c"
#endif
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 973ff0447c6c..7e438501333e 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -215,4 +215,8 @@ void i915_request_add_active_barriers(struct i915_request
*rq);
void i915_active_print(struct i915_active *ref, struct drm_printer *m);
void i915_active_unlock_wait(struct i915_active *ref);
+struct i915_active *i915_active_create(void);
+struct i915_active *i915_active_get(struct i915_active *ref);
+void i915_active_put(struct i915_active *ref);
+
#endif /* _I915_ACTIVE_H_ */
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/17] drm/i915: Improve the start alignment of bonded pairs
Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting on the semaphore used to synchronise the start of the
bonded payload.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 41 +
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 66efd16c4850..db11006b4ac9 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1128,14 +1128,45 @@ __i915_request_await_execution(struct i915_request *to,
&from->fence))
return 0;
- /* Ensure both start together [after all semaphores in signal] */
- if (intel_engine_has_semaphores(to->engine))
- err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
- else
- err = i915_request_await_start(to, from);
+ /*
+* 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)) {
+ 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) {
err = i915_sched_node_add_dependency(&to->sched, &from->sched);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/17] dma-buf: Exercise dma-fence-chain under selftests
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/st-dma-fence-chain.c
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 9c190026bfab..995e05f609ff 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
dmabuf_selftests-y := \
selftest.o \
- st-dma-fence.o
+ st-dma-fence.o \
+ st-dma-fence-chain.o
obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h
index 5320386f02e5..55918ef9adab 100644
--- a/drivers/dma-buf/selftests.h
+++ b/drivers/dma-buf/selftests.h
@@ -11,3 +11,4 @@
*/
selftest(sanitycheck, __sanitycheck__) /* keep first (igt selfcheck) */
selftest(dma_fence, dma_fence)
+selftest(dma_fence_chain, dma_fence_chain)
diff --git a/drivers/dma-buf/st-dma-fence-chain.c
b/drivers/dma-buf/st-dma-fence-chain.c
new file mode 100644
index ..bd08ba67b03b
--- /dev/null
+++ b/drivers/dma-buf/st-dma-fence-chain.c
@@ -0,0 +1,713 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "selftest.h"
+
+static struct kmem_cache *slab_fences;
+
+static inline struct mock_fence {
+ struct dma_fence base;
+ spinlock_t lock;
+} *to_mock_fence(struct dma_fence *f) {
+ return container_of(f, struct mock_fence, base);
+}
+
+static const char *mock_name(struct dma_fence *f)
+{
+ return "mock";
+}
+
+static void mock_fence_release(struct dma_fence *f)
+{
+ kmem_cache_free(slab_fences, to_mock_fence(f));
+}
+
+static const struct dma_fence_ops mock_ops = {
+ .get_driver_name = mock_name,
+ .get_timeline_name = mock_name,
+ .release = mock_fence_release,
+};
+
+static struct dma_fence *mock_fence(void)
+{
+ struct mock_fence *f;
+
+ f = kmem_cache_alloc(slab_fences, GFP_KERNEL);
+ if (!f)
+ return NULL;
+
+ spin_lock_init(&f->lock);
+ dma_fence_init(&f->base, &mock_ops, &f->lock, 0, 0);
+
+ return &f->base;
+}
+
+static inline struct mock_chain {
+ struct dma_fence_chain base;
+} *to_mock_chain(struct dma_fence *f) {
+ return container_of(f, struct mock_chain, base.base);
+}
+
+static struct dma_fence *mock_chain(struct dma_fence *prev,
+ struct dma_fence *fence,
+ u64 seqno)
+{
+ struct mock_chain *f;
+
+ f = kmalloc(sizeof(*f), GFP_KERNEL);
+ if (!f)
+ return NULL;
+
+ dma_fence_chain_init(&f->base,
+dma_fence_get(prev),
+dma_fence_get(fence),
+seqno);
+
+ return &f->base.base;
+}
+
+static int sanitycheck(void *arg)
+{
+ struct dma_fence *f, *chain;
+ int err = 0;
+
+ f = mock_fence();
+ if (!f)
+ return -ENOMEM;
+
+ chain = mock_chain(NULL, f, 1);
+ if (!chain)
+ err = -ENOMEM;
+
+ dma_fence_signal(f);
+ dma_fence_put(f);
+
+ dma_fence_put(chain);
+
+ return err;
+}
+
+struct fence_chains {
+ unsigned int chain_length;
+ struct dma_fence **fences;
+ struct dma_fence **chains;
+
+ struct dma_fence *tail;
+};
+
+static uint64_t seqno_inc(unsigned int i)
+{
+ return i + 1;
+}
+
+static int fence_chains_init(struct fence_chains *fc, unsigned int count,
+uint64_t (*seqno_fn)(unsigned int))
+{
+ unsigned int i;
+ int err = 0;
+
+ fc->chains = kvmalloc_array(count, sizeof(*fc->chains),
+ GFP_KERNEL | __GFP_ZERO);
+ if (!fc->chains)
+ return -ENOMEM;
+
+ fc->fences = kvmalloc_array(count, sizeof(*fc->fences),
+ GFP_KERNEL | __GFP_ZERO);
+ if (!fc->fences) {
+ err = -ENOMEM;
+ goto err_chains;
+ }
+
+ fc->tail = NULL;
+ for (i = 0; i < count; i++) {
+ fc->fences[i] = mock_fence();
+ if (!fc->fences[i]) {
+ err = -ENOMEM;
+ goto unwind;
+ }
+
+ fc->chains[i] = mock_chain(fc->tail,
+ fc->fences[i],
+ seqno_fn(i));
+ if (!fc->chains[i]) {
+ err = -ENOMEM;
+ goto unwind;
+ }
+
+ fc->tail = fc->chains[i];
+ }
[Intel-gfx] [PATCH 04/17] drm/i915: Tweak scheduler's kick_submission()
Skip useless priority bumping on adding a new dependency, but otherwise prevent tasklet scheduling until we have completed all the potential rescheduling. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_scheduler.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c index 52f71e83e088..603cba36d6a4 100644 --- a/drivers/gpu/drm/i915/i915_scheduler.c +++ b/drivers/gpu/drm/i915/i915_scheduler.c @@ -209,6 +209,8 @@ static void kick_submission(struct intel_engine_cs *engine, if (!inflight) goto unlock; + engine->execlists.queue_priority_hint = prio; + /* * If we are already the currently executing context, don't * bother evaluating if we should preempt ourselves. @@ -216,7 +218,6 @@ static void kick_submission(struct intel_engine_cs *engine, if (inflight->context == rq->context) goto unlock; - engine->execlists.queue_priority_hint = prio; if (need_preempt(prio, rq_prio(inflight))) tasklet_hi_schedule(&engine->execlists.tasklet); @@ -463,11 +464,15 @@ int i915_sched_node_add_dependency(struct i915_sched_node *node, if (!dep) return -ENOMEM; + local_bh_disable(); + if (!__i915_sched_node_add_dependency(node, signal, dep, I915_DEPENDENCY_EXTERNAL | I915_DEPENDENCY_ALLOC)) i915_dependency_free(dep); + local_bh_enable(); /* kick submission tasklet */ + return 0; } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/17] drm/i915/selftests: Add request throughput measurement to perf
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/i915_request.c | 285 +-
2 files changed, 285 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
index 3bf7f53e9924..d8da142985eb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
@@ -16,5 +16,6 @@
* Tests are executed in order by igt/i915_selftest
*/
selftest(engine_cs, intel_engine_cs_perf_selftests)
+selftest(request, i915_request_perf_selftests)
selftest(blt, i915_gem_object_blt_perf_selftests)
selftest(region, intel_memory_region_perf_selftests)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..d4c088cfe4e1 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include "gem/i915_gem_pm.h"
#include "gem/selftests/mock_context.h"
@@ -1233,7 +1234,7 @@ static int live_parallel_engines(void *arg)
struct igt_live_test t;
unsigned int idx;
- snprintf(name, sizeof(name), "%pS", fn);
+ snprintf(name, sizeof(name), "%ps", *fn);
err = igt_live_test_begin(&t, i915, __func__, name);
if (err)
break;
@@ -1470,3 +1471,285 @@ int i915_request_live_selftests(struct drm_i915_private
*i915)
return i915_subtests(tests, i915);
}
+
+struct perf_parallel {
+ struct intel_engine_cs *engine;
+ unsigned long count;
+ ktime_t time;
+ ktime_t busy;
+ u64 runtime;
+};
+
+static int switch_to_kernel_sync(struct intel_context *ce, int err)
+{
+ struct i915_request *rq;
+ struct dma_fence *fence;
+
+ rq = intel_engine_create_kernel_request(ce->engine);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ fence = i915_active_fence_get(&ce->timeline->last_request);
+ if (fence) {
+ i915_request_await_dma_fence(rq, fence);
+ dma_fence_put(fence);
+ }
+
+ rq = i915_request_get(rq);
+ i915_request_add(rq);
+ if (i915_request_wait(rq, 0, HZ / 2) < 0 && !err)
+ err = -ETIME;
+ i915_request_put(rq);
+
+ while (!err && !intel_engine_is_idle(ce->engine))
+ intel_engine_flush_submission(ce->engine);
+
+ return err;
+}
+
+static int perf_sync(void *arg)
+{
+ struct perf_parallel *p = arg;
+ struct intel_engine_cs *engine = p->engine;
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+ bool busy;
+ int err = 0;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_pin(ce);
+ if (err) {
+ intel_context_put(ce);
+ return err;
+ }
+
+ busy = false;
+ if (intel_engine_supports_stats(engine) &&
+ !intel_enable_engine_stats(engine)) {
+ p->busy = intel_engine_get_busy_time(engine);
+ busy = true;
+ }
+
+ p->time = ktime_get();
+ count = 0;
+ do {
+ struct i915_request *rq;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ break;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ break;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+ p->time = ktime_sub(ktime_get(), p->time);
+
+ if (busy) {
+ p->busy = ktime_sub(intel_engine_get_busy_time(engine),
+ p->busy);
+ intel_disable_engine_stats(engine);
+ }
+
+ err = switch_to_kernel_sync(ce, err);
+ p->runtime = intel_context_get_total_runtime_ns(ce);
+ p->count = count;
+
+ intel_context_unpin(ce);
+ intel_context_put(ce);
+ return err;
+}
+
+static int perf_many(void *arg)
+{
+ struct perf_parallel *p = arg;
+ struct intel_engine_cs *engine = p->engine;
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+ int err = 0;
+ bool busy;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce))
+
[Intel-gfx] [PATCH 02/17] drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
If we stop filling the ELSP due to an incompatible virtual engine
request, check if we should enable the timeslice on behalf of the queue.
This fixes the case where we are inspecting the last->next element when
we know that the last element is the last request in the execution queue,
and so decided we did not need to enable timeslicing despite the intent
to do so!
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: # v5.4+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 13941d1c0a4a..a1d268880cfe 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1757,11 +1757,9 @@ need_timeslice(struct intel_engine_cs *engine, const
struct i915_request *rq)
if (!intel_engine_has_timeslices(engine))
return false;
- if (list_is_last(&rq->sched.link, &engine->active.requests))
- return false;
-
- hint = max(rq_prio(list_next_entry(rq, sched.link)),
- engine->execlists.queue_priority_hint);
+ hint = engine->execlists.queue_priority_hint;
+ if (!list_is_last(&rq->sched.link, &engine->active.requests))
+ hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
return hint >= effective_prio(rq);
}
@@ -1803,6 +1801,18 @@ static void set_timeslice(struct intel_engine_cs *engine)
set_timer_ms(&engine->execlists.timer, active_timeslice(engine));
}
+static void start_timeslice(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ execlists->switch_priority_hint = execlists->queue_priority_hint;
+
+ if (timer_pending(&execlists->timer))
+ return;
+
+ set_timer_ms(&execlists->timer, timeslice(engine));
+}
+
static void record_preemption(struct intel_engine_execlists *execlists)
{
(void)I915_SELFTEST_ONLY(execlists->preempt_hang.count++);
@@ -1966,11 +1976,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* Even if ELSP[1] is occupied and not worthy
* of timeslices, our queue might be.
*/
- if (!execlists->timer.expires &&
- need_timeslice(engine, last))
- set_timer_ms(&execlists->timer,
-timeslice(engine));
-
+ start_timeslice(engine);
return;
}
}
@@ -2005,7 +2011,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (last && !can_merge_rq(last, rq)) {
spin_unlock(&ve->base.active.lock);
- return; /* leave this for another */
+ start_timeslice(engine);
+ return; /* leave this for another sibling */
}
ENGINE_TRACE(engine,
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH v2 0/7] drm: drm_fb_helper cleanup.
On Thu, Mar 05, 2020 at 05:34:27PM +0530, Pankaj Bharadiya wrote:
> This series addresses below drm_fb_helper tasks from
> Documentation/gpu/todo.rst.
>
> - The max connector argument for drm_fb_helper_init() isn't used
> anymore and can be removed.
>
> - The helper doesn't keep an array of connectors anymore so these can
> be removed: drm_fb_helper_single_add_all_connectors(),
> drm_fb_helper_add_one_connector() and
> drm_fb_helper_remove_one_connector().
Entire series applied, thanks for doing this cleanup.
-Daniel
>
> Changes since v1:
>- Accumulated all review tags into individual commits (Emil, Daniel)
>- Squashed warning fixes into the patch that introduced the
> warnings (into 5/7) (Laurent, Emil, Lyude)
>- Remove entire drm_fb_helper tasks from todo list. Daniel's
> "64914da24ea9 drm/fbdev-helper: don't force restores" fixes first
> one (Daniel)
>
> Pankaj Bharadiya (7):
> drm: Remove unused arg from drm_fb_helper_init
> drm/radeon: remove radeon_fb_{add,remove}_connector functions
> drm/amdgpu: Remove drm_fb_helper_{add,remove}_one_connector calls
> drm/i915/display: Remove drm_fb_helper_{add,remove}_one_connector calls
> drm: Remove drm_fb_helper add, add all and remove connector calls
> drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector
> functions
> drm/todo: Update drm_fb_helper tasks
>
> Documentation/gpu/todo.rst| 17
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 5 +---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 13 -
> drivers/gpu/drm/armada/armada_fbdev.c | 8 +-
> drivers/gpu/drm/bridge/tc358764.c | 3 ---
> drivers/gpu/drm/drm_fb_helper.c | 6 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 -
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 10 +--
> drivers/gpu/drm/gma500/framebuffer.c | 6 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 12 -
> drivers/gpu/drm/i915/display/intel_fbdev.c| 4 +--
> drivers/gpu/drm/msm/msm_fbdev.c | 6 +
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 -
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 +
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 6 +
> drivers/gpu/drm/radeon/radeon_dp_mst.c| 10 ---
> drivers/gpu/drm/radeon/radeon_fb.c| 19 +
> drivers/gpu/drm/radeon/radeon_mode.h | 3 ---
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 9 +--
> drivers/gpu/drm/tegra/fb.c| 8 +-
> include/drm/drm_fb_helper.h | 27 ++-
> 21 files changed, 15 insertions(+), 171 deletions(-)
>
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: drm_fb_helper cleanup. (rev3)
== Series Details == Series: drm: drm_fb_helper cleanup. (rev3) URL : https://patchwork.freedesktop.org/series/74140/ State : success == Summary == CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16838_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16838_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +18 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb8/igt@gem_exec_sched...@wide-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk9/igt@gem_exec_whis...@basic-queues-priority.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-glk4/igt@gem_exec_whis...@basic-queues-priority.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#644]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_pp...@flink-and-close-vma-leak.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-iclb6/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl4/igt@gem_soft...@noreloc-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-kbl7/igt@gem_soft...@noreloc-s3.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip_tiling@flip-yf-tiled: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl8/igt@kms_flip_til...@flip-yf-tiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-skl1/igt@kms_flip_til...@flip-yf-tiled.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#49]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-skl2/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl8/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-apl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#899]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16838/shard-glk2/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109642] / [fdo#111068]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_D
[Intel-gfx] [PATCH] drm/i915: Do not poison i915_request.link on removal
Do not poison the timeline link on the i915_request to allow both forward/backward list traversal under RCU. [ 9759.139229] RIP: 0010:active_request+0x2a/0x90 [i915] [ 9759.139240] Code: 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 c5 60 e8 49 de dc e0 48 8b 83 e8 01 00 00 48 39 c5 74 12 48 8d 90 20 fe ff ff <48> 8b 80 50 fe ff ff a8 01 74 11 e8 66 20 dd e0 48 89 d8 5b 5d 41 [ 9759.139251] RSP: 0018:c914ce80 EFLAGS: 00010012 [ 9759.139260] RAX: dead0122 RBX: 17cac040 RCX: 00022000 [ 9759.139267] RDX: deacff42 RSI: 17cac040 RDI: 51fee900 [ 9759.139275] RBP: 51fee960 R08: 001a R09: a04702e0 [ 9759.139282] R10: 82187ea0 R11: 0002 R12: 0004 [ 9759.139289] R13: a04d5179 R14: 8887f994ae40 R15: 57b9a068 [ 9759.139296] FS: () GS:5ed8() knlGS: [ 9759.139304] CS: 0010 DS: ES: CR0: 80050033 [ 9759.139311] CR2: 7fff5bdec000 CR3: 0008534fe001 CR4: 001606e0 [ 9759.139318] Call Trace: [ 9759.139325] [ 9759.139389] execlists_reset+0x14d/0x310 [i915] [ 9759.139400] ? _raw_spin_unlock_irqrestore+0xf/0x30 [ 9759.139445] ? fwtable_read32+0x90/0x230 [i915] [ 9759.139499] execlists_submission_tasklet+0xf6/0x150 [i915] [ 9759.139508] tasklet_action_common.isra.17+0x32/0xa0 [ 9759.139516] __do_softirq+0x114/0x3dc [ 9759.139525] ? handle_irq_event_percpu+0x59/0x70 [ 9759.139533] irq_exit+0xa1/0xc0 [ 9759.139540] do_IRQ+0x76/0x150 [ 9759.139547] common_interrupt+0xf/0xf [ 9759.139554] Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- 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 66efd16c4850..5de3989b6c4f 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -290,7 +290,7 @@ bool i915_request_retire(struct i915_request *rq) spin_unlock_irq(&rq->lock); remove_from_client(rq); - list_del_rcu(&rq->link); + __list_del_entry(&rq->link); /* poison neither prev/next (RCU walks) */ intel_context_exit(rq->context); intel_context_unpin(rq->context); -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
Chris Wilson writes:
> If we stop filling the ELSP due to an incompatible virtual engine
> request, check if we should enable the timeslice on behalf of the queue.
>
> This fixes the case where we are inspecting the last->next element when
> we know that the last element is the last request in the execution queue,
> and so decided we did not need to enable timeslicing despite the intent
> to do so!
>
> Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Cc: # v5.4+
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 29 ++---
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 13941d1c0a4a..a1d268880cfe 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1757,11 +1757,9 @@ need_timeslice(struct intel_engine_cs *engine, const
> struct i915_request *rq)
> if (!intel_engine_has_timeslices(engine))
> return false;
>
> - if (list_is_last(&rq->sched.link, &engine->active.requests))
> - return false;
> -
> - hint = max(rq_prio(list_next_entry(rq, sched.link)),
> -engine->execlists.queue_priority_hint);
> + hint = engine->execlists.queue_priority_hint;
> + if (!list_is_last(&rq->sched.link, &engine->active.requests))
> + hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
>
> return hint >= effective_prio(rq);
> }
> @@ -1803,6 +1801,18 @@ static void set_timeslice(struct intel_engine_cs
> *engine)
> set_timer_ms(&engine->execlists.timer, active_timeslice(engine));
> }
>
> +static void start_timeslice(struct intel_engine_cs *engine)
> +{
> + struct intel_engine_execlists *execlists = &engine->execlists;
> +
> + execlists->switch_priority_hint = execlists->queue_priority_hint;
> +
> + if (timer_pending(&execlists->timer))
> + return;
> +
> + set_timer_ms(&execlists->timer, timeslice(engine));
> +}
> +
> static void record_preemption(struct intel_engine_execlists *execlists)
> {
> (void)I915_SELFTEST_ONLY(execlists->preempt_hang.count++);
> @@ -1966,11 +1976,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
>* Even if ELSP[1] is occupied and not worthy
>* of timeslices, our queue might be.
>*/
> - if (!execlists->timer.expires &&
> - need_timeslice(engine, last))
> - set_timer_ms(&execlists->timer,
> - timeslice(engine));
> -
> + start_timeslice(engine);
> return;
> }
> }
> @@ -2005,7 +2011,8 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
>
> if (last && !can_merge_rq(last, rq)) {
> spin_unlock(&ve->base.active.lock);
> - return; /* leave this for another */
> + start_timeslice(engine);
> + return; /* leave this for another sibling */
> }
>
> ENGINE_TRACE(engine,
> --
> 2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/17] drm/i915/perf: Schedule oa_config after modifying the contexts
On 06/03/2020 15:38, Chris Wilson wrote:
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct context to the state modifications, we need that command packet
to be always last in the queue.
We borrow the i915_active for its ability to track multiple timelines
and the last dma_fence on each; a flexible dma_resv. Keeping track of
each dma_fence is important for us so that we can efficiently schedule
the requests and reprioritise as required.
Reported-by: Lionel Landwerlin
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/display/intel_overlay.c | 8 +-
drivers/gpu/drm/i915/gt/intel_context_param.c | 2 +-
drivers/gpu/drm/i915/i915_active.c| 6 +-
drivers/gpu/drm/i915/i915_active.h| 2 +-
drivers/gpu/drm/i915/i915_perf.c | 154 +++---
drivers/gpu/drm/i915/i915_perf_types.h| 5 +-
drivers/gpu/drm/i915/i915_vma.h | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 4 +-
8 files changed, 115 insertions(+), 68 deletions(-)
...
@@ -2729,16 +2772,19 @@ static const struct i915_perf_stream_ops
i915_oa_stream_ops = {
static int i915_perf_stream_enable_sync(struct i915_perf_stream *stream)
{
- struct i915_request *rq;
+ struct i915_active *active;
+ int err;
- rq = stream->perf->ops.enable_metric_set(stream);
- if (IS_ERR(rq))
- return PTR_ERR(rq);
+ active = i915_active_create();
+ if (!active)
+ return -ENOMEM;
- i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
- i915_request_put(rq);
+ err = stream->perf->ops.enable_metric_set(stream, active);
+ if (err == 0)
+ i915_active_wait(active, TASK_UNINTERRUPTIBLE);
Why not? :
err = i915_active_wait(active, TASK_INTERRUPTIBLE);
-Lionel
- return 0;
+ i915_active_put(active);
+ return err;
}
/**
@@ -3192,7 +3238,7 @@ static long i915_perf_config_locked(struct
i915_perf_stream *stream,
return -EINVAL;
if (config != stream->oa_config) {
- struct i915_request *rq;
+ int err;
/*
* If OA is bound to a specific context, emit the
@@ -3203,13 +3249,11 @@ static long i915_perf_config_locked(struct
i915_perf_stream *stream,
* When set globally, we use a low priority kernel context,
* so it will effectively take effect when idle.
*/
- rq = emit_oa_config(stream, config, oa_context(stream));
- if (!IS_ERR(rq)) {
+ err = emit_oa_config(stream, config, oa_context(stream), NULL);
+ if (!err)
config = xchg(&stream->oa_config, config);
- i915_request_put(rq);
- } else {
- ret = PTR_ERR(rq);
- }
+ else
+ ret = err;
}
i915_oa_config_put(config);
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h
b/drivers/gpu/drm/i915/i915_perf_types.h
index a0e22f00f6cf..5eaf874a0d25 100644
--- a/drivers/gpu/drm/i915/i915_perf_types.h
+++ b/drivers/gpu/drm/i915/i915_perf_types.h
@@ -21,6 +21,7 @@
struct drm_i915_private;
struct file;
+struct i915_active;
struct i915_gem_context;
struct i915_perf;
struct i915_vma;
@@ -339,8 +340,8 @@ struct i915_oa_ops {
* counter reports being sampled. May apply system constraints such as
* disabling EU clock gating as required.
*/
- struct i915_request *
- (*enable_metric_set)(struct i915_perf_stream *stream);
+ int (*enable_metric_set)(struct i915_perf_stream *stream,
+struct i915_active *active);
/**
* @disable_metric_set: Remove system constraints associated with using
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index e1ced1df13e1..3baa98fa5009 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -380,7 +380,7 @@ int i915_vma_wait_for_bind(struct i915_vma *vma);
static inline int i915_vma_sync(struct i915_vma *vma)
{
/* Wait for the asynchronous bindings and pending GPU reads */
- return i915_active_wait(&vma->active);
+ return i915_active_wait(&vma->active, TASK_INTERRUPTIBLE);
}
#endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 68bbb1580162..7357d2130024 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -153,7 +153,7 @@ static int live_active_wait(void *arg)
if (IS_ERR(active))
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Deactive FBC in fastsets when disabled by parameter
On Fri, Mar 06, 2020 at 12:22:09AM +, Souza, Jose wrote: > On Wed, 2020-02-19 at 20:52 +0200, Ville Syrjälä wrote: > > On Wed, Feb 19, 2020 at 06:37:27PM +, Souza, Jose wrote: > > > On Wed, 2020-02-19 at 15:37 +0200, Ville Syrjälä wrote: > > > > On Tue, Feb 18, 2020 at 05:42:28PM -0800, José Roberto de Souza > > > > wrote: > > > > > Most of the kms_frontbuffer_tracking tests disables the feature > > > > > being > > > > > tested, draw, get the CRC then enable the feature, draw again, > > > > > get > > > > > the > > > > > CRC and check if it matches. > > > > > Some times it is able to do that with a fastset, so > > > > > intel_pre_plane_update() is executed but > > > > > intel_fbc_can_flip_nuke() > > > > > was > > > > > not checking if FBC is now enabled in this CRTC leaving FBC > > > > > active > > > > > and > > > > > causing the warning bellow in __intel_fbc_disable() > > > > > > > > > > [IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri- > > > > > indfb- > > > > > multidraw > > > > > Setting dangerous option enable_fbc - tainting kernel > > > > > i915 :00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting > > > > > PSR > > > > > debug to f > > > > > i915 :00:02.0: [drm:intel_psr_debug_set [i915]] Invalid > > > > > debug > > > > > mask f > > > > > i915 :00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting > > > > > PSR > > > > > debug to 1 > > > > > i915 :00:02.0: [drm:intel_atomic_check [i915]] > > > > > [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of > > > > > EDID > > > > > bpp 24, requested bpp 36, max platform bpp 36 > > > > > [drm:intel_dp_compute_config [i915]] DP link computation with > > > > > max > > > > > lane count 2 max rate 27 max bpp 24 pixel clock 138120KHz > > > > > [drm:intel_dp_compute_config [i915]] Force DSC en = 0 > > > > > [drm:intel_dp_compute_config [i915]] DP lane count 2 clock > > > > > 27 > > > > > bpp 24 > > > > > [drm:intel_dp_compute_config [i915]] DP link rate required > > > > > 414360 > > > > > available 54 > > > > > i915 :00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: > > > > > 24, > > > > > pipe bpp: 24, dithering: 0 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > > > [CRTC:91:pipe A] enable: yes [fastset] > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] active: > > > > > yes, > > > > > output_types: EDP (0x100), output format: RGB > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > > > cpu_transcoder: EDP, pipe bpp: 24, dithering: 0 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: > > > > > lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, > > > > > link_n: > > > > > 524288, tu: 64 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] audio: > > > > > 0, > > > > > infoframes: 0, infoframes enabled: 0x0 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > > > requested > > > > > mode: > > > > > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 > > > > > 138120 > > > > > 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted > > > > > mode: > > > > > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 > > > > > 138120 > > > > > 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa > > > > > [drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 > > > > > 1968 > > > > > 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] port > > > > > clock: > > > > > 27, pipe src size: 1920x1080, pixel rate 138120 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > > > linetime: > > > > > 119, ips linetime: 0 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > > > num_scalers: > > > > > 2, scaler_users: 0x0, scaler_id: -1 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] pch > > > > > pfit: > > > > > pos: 0x, size: 0x, disabled, force thru: no > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, > > > > > double wide: 0 > > > > > [drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: > > > > > 0x1c001a5, > > > > > cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: > > > > > 0x0, > > > > > mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, > > > > > mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, > > > > > mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > > > csc_mode: > > > > > 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0 > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] MST > > > > > master > > > > > transcoder: > > > > > i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] > > > > > [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 > > > > > little- > > > > > endian (0x34325258), visible: yes > > > > > i915 :00:02.0: [drm:intel_dump_p
Re: [Intel-gfx] [PATCH 01/17] drm/i915/selftests: Apply a heavy handed flush to i915_active
Chris Wilson writes:
> Due to the ordering of cmpxchg()/dma_fence_signal() inside node_retire(),
> we must also use the xchg() as our primary memory barrier to flush the
> outstanding callbacks after expected completion of the i915_active.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests/i915_active.c | 29 ++--
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
> b/drivers/gpu/drm/i915/selftests/i915_active.c
> index 3a37c67ab6c4..68bbb1580162 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> @@ -311,20 +311,33 @@ static void spin_unlock_wait(spinlock_t *lock)
> spin_unlock_irq(lock);
> }
>
> +static void active_flush(struct i915_active *ref,
> + struct i915_active_fence *active)
> +{
> + struct dma_fence *fence;
> +
> + fence = xchg(__active_fence_slot(active), NULL);
> + if (!fence)
> + return;
> +
> + spin_lock_irq(fence->lock);
> + __list_del_entry(&active->cb.node);
> + spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
> + atomic_dec(&ref->count);
> +
> + GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> +}
> +
> void i915_active_unlock_wait(struct i915_active *ref)
> {
> if (i915_active_acquire_if_busy(ref)) {
> struct active_node *it, *n;
>
> + /* Wait for all active callbacks */
> rcu_read_lock();
> - rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
> - struct dma_fence *f;
> -
> - /* Wait for all active callbacks */
> - f = rcu_dereference(it->base.fence);
> - if (f)
> - spin_unlock_wait(f->lock);
> - }
> + active_flush(ref, &ref->excl);
> + rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node)
> + active_flush(ref, &it->base);
> rcu_read_unlock();
>
> i915_active_release(ref);
> --
> 2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] gem_wsim: Fix calibration for special VCS engine name
From: Tvrtko Ursulin
VCS is a special (non-physical) engine id/name which means load-balancing
in legacy workloads. As such when i915 balancing is not enabled it needs
to have a calibration as well.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index a1bbcef031bb..c196b25317ce 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -3353,6 +3353,8 @@ int main(int argc, char **argv)
engine_calib_map[eng] =
calib_val;
if (eng == RCS)
engine_calib_map[DEFAULT] = calib_val;
+ else if (eng == VCS1 || eng ==
VCS2)
+ engine_calib_map[VCS] =
calib_val;
has_nop_calibration = true;
}
} else {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] gem_wsim: Mark contexts as non-persistent
From: Tvrtko Ursulin
We want to mark workload contexts as non-persistent if possible so that we
do not have to worry about leaving long (or infinite!) batches running
post exit.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 50 ---
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index c196b25317ce..7cb8ea5b18ba 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -1431,16 +1431,48 @@ alloc_step_batch(struct workload *wrk, struct w_step
*w, unsigned int flags)
#endif
}
-static void __ctx_set_prio(uint32_t ctx_id, unsigned int prio)
+static bool has_persistence(int i915)
{
- struct drm_i915_gem_context_param param = {
- .ctx_id = ctx_id,
- .param = I915_CONTEXT_PARAM_PRIORITY,
- .value = prio,
+ struct drm_i915_gem_context_param p = {
+ .param = I915_CONTEXT_PARAM_PERSISTENCE,
};
+ uint64_t saved;
+
+ if (__gem_context_get_param(i915, &p))
+ return false;
+
+ saved = p.value;
+ p.value = 0;
+ if (__gem_context_set_param(i915, &p))
+ return false;
+
+ p.value = saved;
+ return __gem_context_set_param(i915, &p) == 0;
+}
+
+static bool __has_persistence;
+
+static void __configure_context(uint32_t ctx_id, unsigned int prio)
+{
+ if (prio) {
+ struct drm_i915_gem_context_param param = {
+ .ctx_id = ctx_id,
+ .param = I915_CONTEXT_PARAM_PRIORITY,
+ .value = prio,
+ };
- if (prio)
gem_context_set_param(fd, ¶m);
+ }
+
+ /* Mark as non-persistent if supported. */
+ if (__has_persistence) {
+ struct drm_i915_gem_context_param param = {
+ .ctx_id = ctx_id,
+ .param = I915_CONTEXT_PARAM_PERSISTENCE,
+ };
+
+ gem_context_set_param(fd, ¶m);
+ }
}
static int __vm_destroy(int i915, uint32_t vm_id)
@@ -1743,7 +1775,7 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
ctx_vcs ^= 1;
}
- __ctx_set_prio(ctx_id, wrk->prio);
+ __configure_context(ctx_id, wrk->prio);
/*
* Do we need a separate context to satisfy this workloads which
@@ -1772,7 +1804,7 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
ctx_id = args.ctx_id;
wrk->ctx_list[i + 1].id = args.ctx_id;
- __ctx_set_prio(ctx_id, wrk->prio);
+ __configure_context(ctx_id, wrk->prio);
}
if (ctx->engine_map) {
@@ -3280,6 +3312,8 @@ int main(int argc, char **argv)
fd = __drm_open_driver(DRIVER_INTEL);
igt_require(fd);
+ __has_persistence = has_persistence(fd);
+
intel_register_access_init(&mmio_data, intel_get_pci_device(), false,
fd);
init_clocks();
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Clean up i9xx_load_luts_internal()
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
+static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+
+ assert_pll_enabled(dev_priv, crtc->pipe);
Just a query:
Why won't we have following condition here?
if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
assert_dsi_pll_enabled(dev_priv);
or is it applicable only for i965_load_luts() and not for i9xx_load_luts()?
+
+ i9xx_load_lut_8(crtc, gamma_lut);
+}
+
The patch looks good to me.
Reviewed-by: Swati Sharma
--
~Swati Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/17] drm/i915: Wrap i915_active in a simple kreffed struct
Chris Wilson writes:
> For conveniences of callers that just want to use an i915_active to
> track a wide array of concurrent timelines, wrap the base i915_active
> struct inside a kref. This i915_active will self-destruct after use.
>
Found the user,
Reviewed-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_active.c | 53 ++
> drivers/gpu/drm/i915/i915_active.h | 4 +++
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_active.c
> b/drivers/gpu/drm/i915/i915_active.c
> index 7b3d6c12ad61..1826de14d2da 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -881,6 +881,59 @@ void i915_active_noop(struct dma_fence *fence, struct
> dma_fence_cb *cb)
> active_fence_cb(fence, cb);
> }
>
> +struct auto_active {
> + struct i915_active base;
> + struct kref ref;
> +};
> +
> +struct i915_active *i915_active_get(struct i915_active *ref)
> +{
> + struct auto_active *aa = container_of(ref, typeof(*aa), base);
> +
> + kref_get(&aa->ref);
> + return &aa->base;
> +}
> +
> +static void auto_release(struct kref *ref)
> +{
> + struct auto_active *aa = container_of(ref, typeof(*aa), ref);
> +
> + i915_active_fini(&aa->base);
> + kfree(aa);
> +}
> +
> +void i915_active_put(struct i915_active *ref)
> +{
> + struct auto_active *aa = container_of(ref, typeof(*aa), base);
> +
> + kref_put(&aa->ref, auto_release);
> +}
> +
> +static int auto_active(struct i915_active *ref)
> +{
> + i915_active_get(ref);
> + return 0;
> +}
> +
> +static void auto_retire(struct i915_active *ref)
> +{
> + i915_active_put(ref);
> +}
> +
> +struct i915_active *i915_active_create(void)
> +{
> + struct auto_active *aa;
> +
> + aa = kmalloc(sizeof(*aa), GFP_KERNEL);
> + if (!aa)
> + return NULL;
> +
> + kref_init(&aa->ref);
> + i915_active_init(&aa->base, auto_active, auto_retire);
> +
> + return &aa->base;
> +}
> +
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/i915_active.c"
> #endif
> diff --git a/drivers/gpu/drm/i915/i915_active.h
> b/drivers/gpu/drm/i915/i915_active.h
> index 973ff0447c6c..7e438501333e 100644
> --- a/drivers/gpu/drm/i915/i915_active.h
> +++ b/drivers/gpu/drm/i915/i915_active.h
> @@ -215,4 +215,8 @@ void i915_request_add_active_barriers(struct i915_request
> *rq);
> void i915_active_print(struct i915_active *ref, struct drm_printer *m);
> void i915_active_unlock_wait(struct i915_active *ref);
>
> +struct i915_active *i915_active_create(void);
> +struct i915_active *i915_active_get(struct i915_active *ref);
> +void i915_active_put(struct i915_active *ref);
> +
> #endif /* _I915_ACTIVE_H_ */
> --
> 2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Clean up i9xx_load_luts_internal()
On Fri, Mar 06, 2020 at 08:12:22PM +0530, Sharma, Swati2 wrote:
>
>
> On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
> > +static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
> > +
> > + assert_pll_enabled(dev_priv, crtc->pipe);
> Just a query:
> Why won't we have following condition here?
> if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
> assert_dsi_pll_enabled(dev_priv);
> or is it applicable only for i965_load_luts() and not for i9xx_load_luts()?
No DSI on these platforms. Only VLV/CHV can have it, and they use
i965_load_luts().
>
> > +
> > + i9xx_load_lut_8(crtc, gamma_lut);
> > +}
> > +
> The patch looks good to me.
>
> Reviewed-by: Swati Sharma
>
> --
> ~Swati Sharma
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Return early for await_start on same timeline
== Series Details == Series: drm/i915: Return early for await_start on same timeline URL : https://patchwork.freedesktop.org/series/74338/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16839_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16839_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16839_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_16839_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@gem-mmap-type@wb: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@i915_pm_rpm@gem-mmap-t...@wb.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-iclb2/igt@i915_pm_rpm@gem-mmap-t...@wb.html Known issues Here are the changes found in Patchwork_16839_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-iclb7/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +16 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-iclb8/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb8/igt@gem_exec_sched...@wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-iclb1/igt@gem_exec_sched...@wide-bsd.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk6/igt@gem_exec_whis...@basic-queues-forked-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-glk3/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][15] -> [FAIL][16] ([i915#644]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-apl3/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_rps@min-max-config-loaded: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#370]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb1/igt@i915_pm_...@min-max-config-loaded.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-iclb6/igt@i915_pm_...@min-max-config-loaded.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@i915_suspend@sysfs-reader: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl6/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16839/shard-kbl7/igt@i915_susp...@sysfs-reader.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk:
Re: [Intel-gfx] [PATCH v2 3/9] drm/i915: Split i9xx_read_lut_8() to gmch vs. ilk variants
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
To mirror the load_luts path let's clone an ilk+ version
from i9xx_read_lut_8(). I guess the extra branch isn't a huge
issue but feels better to make a clean split.
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 41 ++
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index cf8ed4e2ae13..e3abaa1908a9 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1706,10 +1706,7 @@ i9xx_read_lut_8(const struct intel_crtc_state
*crtc_state)
blob_data = blob->data;
for (i = 0; i < LEGACY_LUT_LENGTH; i++) {
- if (HAS_GMCH(dev_priv))
- val = intel_de_read(dev_priv, PALETTE(pipe, i));
- else
- val = intel_de_read(dev_priv, LGC_PALETTE(pipe, i));
+ val = intel_de_read(dev_priv, PALETTE(pipe, i));
blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
LGC_PALETTE_RED_MASK,
val), 8);
@@ -1824,6 +1821,38 @@ static void chv_read_luts(struct intel_crtc_state
*crtc_state)
i965_read_luts(crtc_state);
}
+static struct drm_property_blob *
+ilk_read_lut_8(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+ u32 i, val;
+
+ blob = drm_property_create_blob(&dev_priv->drm,
+ sizeof(struct drm_color_lut) *
LEGACY_LUT_LENGTH,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < LEGACY_LUT_LENGTH; i++) {
+ val = intel_de_read(dev_priv, LGC_PALETTE(pipe, i));
+
+ blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
+ LGC_PALETTE_RED_MASK,
val), 8);
+ blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
+
LGC_PALETTE_GREEN_MASK, val), 8);
+ blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(
+LGC_PALETTE_BLUE_MASK,
val), 8);
+ }
+
+ return blob;
+}
+
static struct drm_property_blob *
ilk_read_lut_10(const struct intel_crtc_state *crtc_state)
{
@@ -1866,7 +1895,7 @@ static void ilk_read_luts(struct intel_crtc_state
*crtc_state)
return;
if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
- crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
+ crtc_state->hw.gamma_lut = ilk_read_lut_8(crtc_state);
else
crtc_state->hw.gamma_lut = ilk_read_lut_10(crtc_state);
}
@@ -1915,7 +1944,7 @@ static void glk_read_luts(struct intel_crtc_state
*crtc_state)
return;
if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
- crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
+ crtc_state->hw.gamma_lut = ilk_read_lut_8(crtc_state);
else
crtc_state->hw.gamma_lut = glk_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
}
--
~Swati Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
On 2020-03-05 8:42 p.m., Manasi Navare wrote:
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_freesync_caps() to make it generic and be used
across all DRM drivers
v4:
* Use is_display_descriptor() (Ville)
* Name the monitor range flags (Ville)
v3:
* Remove the edid parsing restriction for just DP (Nicholas)
* Use drm_for_each_detailed_block (Ville)
* Make the drm_get_adaptive_sync_range function static (Harry, Jani)
v2:
* Change vmin and vmax to use u8 (Ville)
* Dont store pixel clock since that is just a max dotclock
and not related to VRR mode (Manasi)
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Clinton A Taylor
Cc: Kazlauskas Nicholas
Signed-off-by: Manasi Navare
Looks good to me now. I'm fine with whether we want to rename the flags
or not, I don't have much of a preference either way.
Series is:
Reviewed-by: Nicholas Kazlauskas
Regards,
Nicholas Kazlauskas
---
drivers/gpu/drm/drm_edid.c | 44 +
include/drm/drm_connector.h | 22 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ad41764a4ebe..61ed544d9535 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
}
}
+static
+void get_adaptive_sync_range(struct detailed_timing *timing,
+void *info_adaptive_sync)
+{
+ struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
+ const struct detailed_non_pixel *data = &timing->data.other_data;
+ const struct detailed_data_monitor_range *range = &data->data.range;
+
+ if (!is_display_descriptor((const u8 *)timing,
EDID_DETAIL_MONITOR_RANGE))
+ return;
+
+ /*
+* Check for flag range limits only. If flag == 1 then
+* no additional timing information provided.
+* Default GTF, GTF Secondary curve and CVT are not
+* supported
+*/
+ if (range->flags != EDID_RANGE_LIMITS_ONLY_FLAG)
+ return;
+
+ adaptive_sync->min_vfreq = range->min_vfreq;
+ adaptive_sync->max_vfreq = range->max_vfreq;
+}
+
+static
+void drm_get_adaptive_sync_range(struct drm_connector *connector,
+const struct edid *edid)
+{
+ struct drm_display_info *info = &connector->display_info;
+
+ if (!version_greater(edid, 1, 1))
+ return;
+
+ drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
+ &info->adaptive_sync);
+
+ DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
+ info->adaptive_sync.min_vfreq,
+ info->adaptive_sync.max_vfreq);
+}
+
/* A connector has no EDID information, so we've got no EDID to compute
quirks from. Reset
* all of the values which would have been set from EDID
*/
@@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
memset(&info->hdmi, 0, sizeof(info->hdmi));
info->non_desktop = 0;
+ memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
}
u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)
@@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector *connector,
const struct edid *edi
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
+ drm_get_adaptive_sync_range(connector, edid);
+
DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
if (edid->revision < 3)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 0df7a95ca5d9..2b22c0fa42c4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -254,6 +254,23 @@ enum drm_panel_orientation {
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+/**
+ * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
+ * &drm_display_info
+ *
+ * This struct is used to store a Panel's Adaptive Sync capabilities
+ * as parsed from EDID's detailed monitor range descriptor block.
+ *
+ * @min_vfreq: This is the min supported refresh rate in Hz from
+ * EDID's detailed monitor range.
+ * @max_vfreq: This is the max supported refresh rate in Hz from
+ * EDID's detailed monitor range
+ */
+struct drm_adaptive_sync_info {
+ u8 min_vfreq;
+ u8 max_vfreq;
+};
+
/*
* This is a consolidated colorimetry list supported by HDMI and
* DP protocol standard. The respective connectors will register
@@ -473,6 +490,11 @@ struct drm_display_info {
* @non_desktop: Non desktop display (HMD).
*/
bool non_desktop;
+
+ /
Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: s/blob_data/lut/
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We're talking about LUT contents here so let's call the thing
'lut' rather than 'blob_data'. This is the name the load_lut()
code used before already.
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 66 +++---
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index e3abaa1908a9..f90f113355bc 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1694,7 +1694,7 @@ i9xx_read_lut_8(const struct intel_crtc_state *crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
- struct drm_color_lut *blob_data;
+ struct drm_color_lut *lut;
u32 i, val;
blob = drm_property_create_blob(&dev_priv->drm,
@@ -1703,16 +1703,16 @@ i9xx_read_lut_8(const struct intel_crtc_state
*crtc_state)
if (IS_ERR(blob))
return NULL;
- blob_data = blob->data;
+ lut = blob->data;
for (i = 0; i < LEGACY_LUT_LENGTH; i++) {
val = intel_de_read(dev_priv, PALETTE(pipe, i));
- blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
+ lut[i].red = intel_color_lut_pack(REG_FIELD_GET(
LGC_PALETTE_RED_MASK,
val), 8);
- blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
+ lut[i].green = intel_color_lut_pack(REG_FIELD_GET(
LGC_PALETTE_GREEN_MASK, val), 8);
- blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(
+ lut[i].blue = intel_color_lut_pack(REG_FIELD_GET(
LGC_PALETTE_BLUE_MASK,
val), 8);
}
@@ -1735,7 +1735,7 @@ i965_read_lut_10p6(const struct intel_crtc_state *crtc_state)
u32 lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
- struct drm_color_lut *blob_data;
+ struct drm_color_lut *lut;
u32 i, val1, val2;
blob = drm_property_create_blob(&dev_priv->drm,
@@ -1744,25 +1744,25 @@ i965_read_lut_10p6(const struct intel_crtc_state
*crtc_state)
if (IS_ERR(blob))
return NULL;
- blob_data = blob->data;
+ lut = blob->data;
for (i = 0; i < lut_size - 1; i++) {
val1 = intel_de_read(dev_priv, PALETTE(pipe, 2 * i + 0));
val2 = intel_de_read(dev_priv, PALETTE(pipe, 2 * i + 1));
- blob_data[i].red = REG_FIELD_GET(PALETTE_RED_MASK, val2) << 8 |
+ lut[i].red = REG_FIELD_GET(PALETTE_RED_MASK, val2) << 8 |
REG_FIELD_GET(PALETTE_RED_MASK, val1);
- blob_data[i].green = REG_FIELD_GET(PALETTE_GREEN_MASK, val2) <<
8 |
+ lut[i].green = REG_FIELD_GET(PALETTE_GREEN_MASK, val2) << 8 |
REG_FIELD_GET(PALETTE_GREEN_MASK, val1);
- blob_data[i].blue = REG_FIELD_GET(PALETTE_BLUE_MASK, val2) << 8
|
+ lut[i].blue = REG_FIELD_GET(PALETTE_BLUE_MASK, val2) << 8 |
REG_FIELD_GET(PALETTE_BLUE_MASK, val1);
}
- blob_data[i].red = REG_FIELD_GET(PIPEGCMAX_RGB_MASK,
+ lut[i].red = REG_FIELD_GET(PIPEGCMAX_RGB_MASK,
intel_de_read(dev_priv,
PIPEGCMAX(pipe, 0)));
- blob_data[i].green = REG_FIELD_GET(PIPEGCMAX_RGB_MASK,
+ lut[i].green = REG_FIELD_GET(PIPEGCMAX_RGB_MASK,
intel_de_read(dev_priv,
PIPEGCMAX(pipe, 1)));
- blob_data[i].blue = REG_FIELD_GET(PIPEGCMAX_RGB_MASK,
+ lut[i].blue = REG_FIELD_GET(PIPEGCMAX_RGB_MASK,
intel_de_read(dev_priv,
PIPEGCMAX(pipe, 2)));
return blob;
@@ -1787,7 +1787,7 @@ chv_read_cgm_lut(const struct intel_crtc_state
*crtc_state)
u32 lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
- struct drm_color_lut *blob_data;
+ struct drm_color_lut *lut;
u32 i, val;
blob = drm_property_create_blob(&dev_priv->drm,
@@ -1796,17 +1796,17 @@ chv_read_cgm_lut(const struct intel_crtc_state
*crtc_state)
if (IS_ERR(blob))
return NULL;
- blob_data = blob->data;
+ lut = blob->data;
for (i = 0; i < lut_size; i++) {
val = intel_de_read(dev_priv, CGM_PIPE_GAMMA(pipe, i, 0));
- blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
+ lut[i].green = intel_colo
Re: [Intel-gfx] [PATCH] drm/i915: Do not poison i915_request.link on removal
Chris Wilson writes: > Do not poison the timeline link on the i915_request to allow both > forward/backward list traversal under RCU. > > [ 9759.139229] RIP: 0010:active_request+0x2a/0x90 [i915] > [ 9759.139240] Code: 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 c5 60 e8 > 49 de dc e0 48 8b 83 e8 01 00 00 48 39 c5 74 12 48 8d 90 20 fe ff ff <48> 8b > 80 50 fe ff ff a8 01 74 11 e8 66 20 dd e0 48 89 d8 5b 5d 41 > [ 9759.139251] RSP: 0018:c914ce80 EFLAGS: 00010012 > [ 9759.139260] RAX: dead0122 RBX: 17cac040 RCX: > 00022000 > [ 9759.139267] RDX: deacff42 RSI: 17cac040 RDI: > 51fee900 > [ 9759.139275] RBP: 51fee960 R08: 001a R09: > a04702e0 > [ 9759.139282] R10: 82187ea0 R11: 0002 R12: > 0004 > [ 9759.139289] R13: a04d5179 R14: 8887f994ae40 R15: > 57b9a068 > [ 9759.139296] FS: () GS:5ed8() > knlGS: > [ 9759.139304] CS: 0010 DS: ES: CR0: 80050033 > [ 9759.139311] CR2: 7fff5bdec000 CR3: 0008534fe001 CR4: > 001606e0 > [ 9759.139318] Call Trace: > [ 9759.139325] > [ 9759.139389] execlists_reset+0x14d/0x310 [i915] > [ 9759.139400] ? _raw_spin_unlock_irqrestore+0xf/0x30 > [ 9759.139445] ? fwtable_read32+0x90/0x230 [i915] > [ 9759.139499] execlists_submission_tasklet+0xf6/0x150 [i915] > [ 9759.139508] tasklet_action_common.isra.17+0x32/0xa0 > [ 9759.139516] __do_softirq+0x114/0x3dc > [ 9759.139525] ? handle_irq_event_percpu+0x59/0x70 > [ 9759.139533] irq_exit+0xa1/0xc0 > [ 9759.139540] do_IRQ+0x76/0x150 > [ 9759.139547] common_interrupt+0xf/0xf > [ 9759.139554] > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala > --- > 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 66efd16c4850..5de3989b6c4f 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -290,7 +290,7 @@ bool i915_request_retire(struct i915_request *rq) > spin_unlock_irq(&rq->lock); > > remove_from_client(rq); > - list_del_rcu(&rq->link); > + __list_del_entry(&rq->link); /* poison neither prev/next (RCU walks) */ > > intel_context_exit(rq->context); > intel_context_unpin(rq->context); > -- > 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/9] drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().
At present, since all the readouts are only gamma luts so should we
rename all the readouts like chv_read_gamma_lut()?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index f90f113355bc..ab23b24e7be3 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1780,7 +1780,7 @@ static void i965_read_luts(struct intel_crtc_state
*crtc_state)
}
static struct drm_property_blob *
-chv_read_cgm_lut(const struct intel_crtc_state *crtc_state)
+chv_read_cgm_gamma(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1816,7 +1816,7 @@ chv_read_cgm_lut(const struct intel_crtc_state
*crtc_state)
static void chv_read_luts(struct intel_crtc_state *crtc_state)
{
if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
- crtc_state->hw.gamma_lut = chv_read_cgm_lut(crtc_state);
+ crtc_state->hw.gamma_lut = chv_read_cgm_gamma(crtc_state);
else
i965_read_luts(crtc_state);
}
--
~Swati Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Clean up integer types in color code
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which generally provide the loop end codition
for 'i'.
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 43 ++
1 file changed, 19 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index ab23b24e7be3..934f00817c5c 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -740,9 +740,8 @@ static void glk_load_degamma_lut(const struct
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- const u32 lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
+ int i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
const struct drm_color_lut *lut = crtc_state->hw.degamma_lut->data;
- u32 i;
/*
* When setting the auto-increment bit, the hardware seems to
@@ -781,8 +780,7 @@ static void glk_load_degamma_lut_linear(const struct
intel_crtc_state *crtc_stat
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- const u32 lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
- u32 i;
+ int i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
/*
* When setting the auto-increment bit, the hardware seems to
@@ -867,7 +865,7 @@ icl_program_gamma_superfine_segment(const struct
intel_crtc_state *crtc_state)
const struct drm_color_lut *lut = blob->data;
struct intel_dsb *dsb = intel_dsb_get(crtc);
enum pipe pipe = crtc->pipe;
- u32 i;
+ int i;
/*
* Program Super Fine segment (let's call it seg1)...
@@ -900,7 +898,7 @@ icl_program_gamma_multi_segment(const struct
intel_crtc_state *crtc_state)
const struct drm_color_lut *entry;
struct intel_dsb *dsb = intel_dsb_get(crtc);
enum pipe pipe = crtc->pipe;
- u32 i;
+ int i;
/*
* Program Fine segment (let's call it seg2)...
@@ -1675,7 +1673,7 @@ bool intel_color_lut_equal(struct drm_property_blob
*blob1,
}
/* convert hw value with given bit_precision to lut property val */
-static u32 intel_color_lut_pack(u32 val, u32 bit_precision)
+static u32 intel_color_lut_pack(u32 val, int bit_precision)
{
u32 max = 0x >> (16 - bit_precision);
@@ -1695,7 +1693,7 @@ i9xx_read_lut_8(const struct intel_crtc_state *crtc_state)
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
struct drm_color_lut *lut;
- u32 i, val;
+ int i;
blob = drm_property_create_blob(&dev_priv->drm,
sizeof(struct drm_color_lut) *
LEGACY_LUT_LENGTH,
@@ -1706,7 +1704,7 @@ i9xx_read_lut_8(const struct intel_crtc_state *crtc_state)
lut = blob->data;
for (i = 0; i < LEGACY_LUT_LENGTH; i++) {
- val = intel_de_read(dev_priv, PALETTE(pipe, i));
+ u32 val = intel_de_read(dev_priv, PALETTE(pipe, i));
lut[i].red = intel_color_lut_pack(REG_FIELD_GET(
LGC_PALETTE_RED_MASK,
val), 8);
@@ -1732,11 +1730,10 @@ i965_read_lut_10p6(const struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- u32 lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ int i, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
struct drm_color_lut *lut;
- u32 i, val1, val2;
blob = drm_property_create_blob(&dev_priv->drm,
sizeof(struct drm_color_lut) * lut_size,
@@ -1747,8 +1744,8 @@ i965_read_lut_10p6(const struct intel_crtc_state
*crtc_state)
lut = blob->data;
for (i = 0; i < lut_size - 1; i++) {
- val1 = intel_de_read(dev_priv, PALETTE(pipe, 2 * i + 0));
- val2 = intel_de_read(dev_priv, PALETTE(pipe, 2 * i + 1));
+ u32 val1 = intel_de_read(dev_priv, PALETTE(pipe, 2 * i + 0));
+ u32 val2 = intel_de_read(dev_priv, PALETTE(pipe, 2 * i + 1));
lut[i].red = REG_FIELD_GET(PALETTE_RED_MASK, val2) << 8 |
REG_FIELD_GET(PALETTE_RED_MASK, val1);
@@ -1784,11 +1781,10 @@ chv_
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: HDCP: fix Ri prime and R0 checks during auth (rev2)
== Series Details == Series: drm/i915: HDCP: fix Ri prime and R0 checks during auth (rev2) URL : https://patchwork.freedesktop.org/series/74271/ State : success == Summary == CI Bug Log - changes from CI_DRM_8070_full -> Patchwork_16840_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16840_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#69]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl9/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-skl8/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_schedule@implicit-read-write-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb7/igt@gem_exec_sched...@implicit-read-write-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd.html * igt@gem_exec_schedule@pi-common-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +13 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd1.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb8/igt@gem_exec_sched...@wide-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-iclb1/igt@gem_exec_sched...@wide-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#644]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-apl4/igt@gem_pp...@flink-and-close-vma-leak.html - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#644]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-kbl3/igt@i915_susp...@fence-restore-tiled2untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-kbl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-apl2/igt@kms_fbcon_...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#49]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#899]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-glk9/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr2_su@page_flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16840/shard-iclb5/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +2 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
Re: [Intel-gfx] [PATCH v2 7/9] drm/i915: Refactor LUT read functions
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.
Wow!
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 122 +++--
1 file changed, 62 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 934f00817c5c..8796f04e23a8 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -387,6 +387,19 @@ static void chv_load_cgm_csc(struct intel_crtc *crtc,
coeffs[8]);
}
+/* convert hw value with given bit_precision to lut property val */
+static u32 intel_color_lut_pack(u32 val, int bit_precision)
+{
+ u32 max = 0x >> (16 - bit_precision);
+
+ val = clamp_val(val, 0, max);
+
+ if (bit_precision < 16)
+ val <<= 16 - bit_precision;
+
+ return val;
+}
+
static u32 i9xx_lut_8(const struct drm_color_lut *color)
{
return drm_color_lut_extract(color->red, 8) << 16 |
@@ -394,6 +407,13 @@ static u32 i9xx_lut_8(const struct drm_color_lut *color)
drm_color_lut_extract(color->blue, 8);
}
+static void i9xx_lut_8_pack(struct drm_color_lut *entry, u32 val)
+{
+ entry->red = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK,
val), 8);
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
+ entry->blue = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK,
val), 8);
+}
+
/* i965+ "10.6" bit interpolated format "even DW" (low 8 bits) */
static u32 i965_lut_10p6_ldw(const struct drm_color_lut *color)
{
@@ -410,6 +430,21 @@ static u32 i965_lut_10p6_udw(const struct drm_color_lut
*color)
(color->blue >> 8);
}
+static void i965_lut_10p6_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
+{
+ entry->red = REG_FIELD_GET(PALETTE_RED_MASK, udw) << 8 |
+ REG_FIELD_GET(PALETTE_RED_MASK, ldw);
+ entry->green = REG_FIELD_GET(PALETTE_GREEN_MASK, udw) << 8 |
+ REG_FIELD_GET(PALETTE_GREEN_MASK, ldw);
+ entry->blue = REG_FIELD_GET(PALETTE_BLUE_MASK, udw) << 8 |
+ REG_FIELD_GET(PALETTE_BLUE_MASK, ldw);
+}
+
+static u16 i965_lut_11p6_max_pack(u32 val)
+{
+ return REG_FIELD_GET(PIPEGCMAX_RGB_MASK, val);
+}
+
static u32 ilk_lut_10(const struct drm_color_lut *color)
{
return drm_color_lut_extract(color->red, 10) << 20 |
@@ -417,6 +452,13 @@ static u32 ilk_lut_10(const struct drm_color_lut *color)
drm_color_lut_extract(color->blue, 10);
}
+static void ilk_lut_10_pack(struct drm_color_lut *entry, u32 val)
+{
+ entry->red = intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_RED_MASK,
val), 10);
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_GREEN_MASK, val), 10);
+ entry->blue =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_BLUE_MASK, val), 10);
+}
+
static void i9xx_color_commit(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -983,6 +1025,13 @@ static u32 chv_cgm_degamma_udw(const struct drm_color_lut
*color)
return drm_color_lut_extract(color->red, 14);
}
+static void chv_cgm_gamma_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
+{
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, ldw), 10);
+ entry->blue =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, ldw), 10);
+ entry->red =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, udw), 10);
+}
+
static void chv_load_cgm_degamma(struct intel_crtc *crtc,
const struct drm_property_blob *blob)
{
@@ -1672,19 +1721,6 @@ bool intel_color_lut_equal(struct drm_property_blob
*blob1,
return true;
}
-/* convert hw value with given bit_precision to lut property val */
-static u32 intel_color_lut_pack(u32 val, int bit_precision)
-{
- u32 max = 0x >> (16 - bit_precision);
-
- val = clamp_val(val, 0, max);
-
- if (bit_precision < 16)
- val <<= 16 - bit_precision;
-
- return val;
-}
-
static struct drm_property_blob *
i9xx_read_lut_8(const struct intel_crtc_state *crtc_state)
{
@@ -1706,12 +1742,7 @@ i9xx_read_lut_8(const struct intel_crtc_state
*crtc_state)
for (i = 0; i < LEGACY_LUT_LENGTH; i++) {
u32 val = intel_de_read(dev_priv, PALETTE(pipe, i));
- lut[i].red = intel_color_lut_pack(REG_FIELD_GET(
- LGC_PALETTE_RED_MASK,
val), 8);
- lut[i].green = intel_color_lut_pack(REG_FIELD_GET(
-
LGC_
Re: [Intel-gfx] [PATCH v2 5/9] drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/
On Fri, Mar 06, 2020 at 08:48:42PM +0530, Sharma, Swati2 wrote:
>
>
> On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
> > let's rename it to reflect that fact. This also mirrors
> > the other direction's chv_load_cgm_gamma().
>
> At present, since all the readouts are only gamma luts so should we
> rename all the readouts like chv_read_gamma_lut()?
No, the names are chosen based on the HW LUT we read not the SW LUT.
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index f90f113355bc..ab23b24e7be3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -1780,7 +1780,7 @@ static void i965_read_luts(struct intel_crtc_state
> > *crtc_state)
> > }
> >
> > static struct drm_property_blob *
> > -chv_read_cgm_lut(const struct intel_crtc_state *crtc_state)
> > +chv_read_cgm_gamma(const struct intel_crtc_state *crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > @@ -1816,7 +1816,7 @@ chv_read_cgm_lut(const struct intel_crtc_state
> > *crtc_state)
> > static void chv_read_luts(struct intel_crtc_state *crtc_state)
> > {
> > if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
> > - crtc_state->hw.gamma_lut = chv_read_cgm_lut(crtc_state);
> > + crtc_state->hw.gamma_lut = chv_read_cgm_gamma(crtc_state);
> > else
> > i965_read_luts(crtc_state);
> > }
> >
>
> --
> ~Swati Sharma
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Pass the crtc to the low level read_lut() funcs
On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
From: Ville Syrjälä
The low level read_lut() functions don't need the entire crtc state
as they know exactly what they're reading. Just need to pass in the
crtc to get at the pipe. This now neatly mirrors the load_lut()
direction.
Signed-off-by: Ville Syrjälä
Reviewed-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 51 +++---
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index ed9996aacafd..c1cce93a1c25 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1722,10 +1722,8 @@ bool intel_color_lut_equal(struct drm_property_blob
*blob1,
return true;
}
-static struct drm_property_blob *
-i9xx_read_lut_8(const struct intel_crtc_state *crtc_state)
+static struct drm_property_blob *i9xx_read_lut_8(struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
@@ -1751,16 +1749,16 @@ i9xx_read_lut_8(const struct intel_crtc_state
*crtc_state)
static void i9xx_read_luts(struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
if (!crtc_state->gamma_enable)
return;
- crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
+ crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc);
}
-static struct drm_property_blob *
-i965_read_lut_10p6(const struct intel_crtc_state *crtc_state)
+static struct drm_property_blob *i965_read_lut_10p6(struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
int i, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
enum pipe pipe = crtc->pipe;
@@ -1791,19 +1789,19 @@ i965_read_lut_10p6(const struct intel_crtc_state
*crtc_state)
static void i965_read_luts(struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
if (!crtc_state->gamma_enable)
return;
if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
- crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
+ crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc);
else
- crtc_state->hw.gamma_lut = i965_read_lut_10p6(crtc_state);
+ crtc_state->hw.gamma_lut = i965_read_lut_10p6(crtc);
}
-static struct drm_property_blob *
-chv_read_cgm_gamma(const struct intel_crtc_state *crtc_state)
+static struct drm_property_blob *chv_read_cgm_gamma(struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
int i, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
enum pipe pipe = crtc->pipe;
@@ -1830,16 +1828,16 @@ chv_read_cgm_gamma(const struct intel_crtc_state
*crtc_state)
static void chv_read_luts(struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
- crtc_state->hw.gamma_lut = chv_read_cgm_gamma(crtc_state);
+ crtc_state->hw.gamma_lut = chv_read_cgm_gamma(crtc);
else
i965_read_luts(crtc_state);
}
-static struct drm_property_blob *
-ilk_read_lut_8(const struct intel_crtc_state *crtc_state)
+static struct drm_property_blob *ilk_read_lut_8(struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
@@ -1863,10 +1861,8 @@ ilk_read_lut_8(const struct intel_crtc_state *crtc_state)
return blob;
}
-static struct drm_property_blob *
-ilk_read_lut_10(const struct intel_crtc_state *crtc_state)
+static struct drm_property_blob *ilk_read_lut_10(struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
int i, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
enum pipe pipe = crtc->pipe;
@@ -1892,6 +1888,8 @@ ilk_read_lut_10(const struct intel_crtc_state *crtc_state)
static void ilk_read_luts(struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
if (!crtc_state->gamma_enable)
return;
@@ -1899,15 +1897,14 @@ static void ilk_read_luts(struct intel_crtc_state *crtc_state)
return;
if (crtc_s
