[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Also drop vm.ref along error paths for vma construction
== Series Details == Series: drm/i915: Also drop vm.ref along error paths for vma construction URL : https://patchwork.freedesktop.org/series/79063/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8701_full -> Patchwork_18074_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18074_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18074_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_18074_full: ### IGT changes ### Possible regressions * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-tglb6/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-tglb6/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html Known issues Here are the changes found in Patchwork_18074_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-tglb6/igt@drm_import_exp...@prime.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-tglb1/igt@drm_import_exp...@prime.html * igt@gem_exec_whisper@basic-fds: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-glk6/igt@gem_exec_whis...@basic-fds.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-glk3/igt@gem_exec_whis...@basic-fds.html * igt@kms_ccs@pipe-a-bad-pixel-format: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#1635] / [i915#95]) +14 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-apl2/igt@kms_...@pipe-a-bad-pixel-format.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-apl4/igt@kms_...@pipe-a-bad-pixel-format.html * igt@kms_color@pipe-a-ctm-0-75: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-kbl4/igt@kms_co...@pipe-a-ctm-0-75.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-kbl1/igt@kms_co...@pipe-a-ctm-0-75.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +12 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-skl6/igt@kms_co...@pipe-c-ctm-0-25.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-skl9/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_flip@flip-vs-suspend-interruptible@a-edp1: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#198]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-skl8/igt@kms_flip@flip-vs-suspend-interrupti...@a-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-skl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-edp1.html * igt@kms_flip@plain-flip-ts-check-interruptible@b-dp1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#78]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-kbl1/igt@kms_flip@plain-flip-ts-check-interrupti...@b-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-kbl2/igt@kms_flip@plain-flip-ts-check-interrupti...@b-dp1.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-tglb7/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-tglb7/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-wc.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-skl10/igt@kms_...@bpc-switch-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/shard-skl5/igt@kms_...@bpc-switch-dpms.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/shard-kbl6/igt@kms_...@bpc-switch-suspend.html [22]:
Re: [Intel-gfx] [PATCH] drm/i915: Also drop vm.ref along error paths for vma construction
Hi Chris,
On Thu, Jul 02, 2020 at 10:10:15PM +0100, Chris Wilson wrote:
> Not only do we need to release the vm.ref we acquired for the vma on the
> duplicate insert branch, but also for the normal error paths, so roll
> them all into one.
>
> Reported-by: Andi Shyti
> Suggested-by: Andi Shyti
> Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: # v5.5+
I've never been mentioned this much before, not even at school.
But that's not enough and I'll give myself another mention:
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/23] drm/i915/gem: Drop forced struct_mutex from shrinker_taints_mutex
Hi Chris, On Thu, Jul 02, 2020 at 09:32:05AM +0100, Chris Wilson wrote: > Since we no longer always take struct_mutex around everything, and want > the freedom to create GEM objects, actually taking struct_mutex inside > the lock creation ends up pulling the mutex inside other looks. Since we > don't use generally use struct_mutex, we can relax the tainting. > > Signed-off-by: Chris Wilson Looks good! Reviewed-by: Andi Shyti Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the kspp tree with the drm-misc tree
Hi all,
Today's linux-next merge of the kspp tree got a conflict in:
drivers/gpu/drm/drm_edid.c
between commit:
948de84233d3 ("drm : Insert blank lines after declarations.")
from the drm-misc tree and commit:
80b89ab785a4 ("treewide: Remove uninitialized_var() usage")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/drm_edid.c
index 252e89cb54a3,b98fa573e706..
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@@ -3095,8 -3051,7 +3095,8 @@@ static int drm_cvt_modes(struct drm_con
const u8 empty[3] = { 0, 0, 0 };
for (i = 0; i < 4; i++) {
- int uninitialized_var(width), height;
+ int width, height;
+
cvt = &(timing->data.other_data.data.cvt[i]);
if (!memcmp(cvt->code, empty, 3))
pgpQxe2l51qGw.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: do not read swizzle info if unavailable (rev2)
== Series Details == Series: drm/i915: do not read swizzle info if unavailable (rev2) URL : https://patchwork.freedesktop.org/series/79007/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8700_full -> Patchwork_18073_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18073_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18073_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_18073_full: ### IGT changes ### Possible regressions * igt@gem_exec_flush@basic-wb-rw-default: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-hsw7/igt@gem_exec_fl...@basic-wb-rw-default.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-hsw7/igt@gem_exec_fl...@basic-wb-rw-default.html * igt@kms_cursor_edge_walk@pipe-a-256x256-left-edge: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-tglb8/igt@kms_cursor_edge_w...@pipe-a-256x256-left-edge.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-tglb7/igt@kms_cursor_edge_w...@pipe-a-256x256-left-edge.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-iclb: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-iclb3/igt@kms_fbcon_...@fbc-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-iclb2/igt@kms_fbcon_...@fbc-suspend.html Known issues Here are the changes found in Patchwork_18073_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@vecs0: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-kbl2/igt@gem_exec_reloc@basic-many-act...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-kbl2/igt@gem_exec_reloc@basic-many-act...@vecs0.html * igt@gem_softpin@softpin: - shard-snb: [PASS][9] -> [INCOMPLETE][10] ([i915#82]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-snb5/igt@gem_soft...@softpin.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-snb6/igt@gem_soft...@softpin.html * igt@i915_module_load@reload: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-tglb5/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-tglb1/igt@i915_module_l...@reload.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#198] / [i915#2110]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-skl9/igt@i915_selftest@m...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-skl10/igt@i915_selftest@m...@requests.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-kbl7/igt@i915_susp...@forcewake.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-kbl6/igt@i915_susp...@forcewake.html * igt@kms_big_fb@linear-16bpp-rotate-0: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-apl2/igt@kms_big...@linear-16bpp-rotate-0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-apl6/igt@kms_big...@linear-16bpp-rotate-0.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#118] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-glk1/igt@kms_big...@linear-64bpp-rotate-180.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_edge_walk@pipe-b-64x64-top-edge: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#165]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/shard-kbl2/igt@kms_cursor_edge_w...@pipe-b-64x64-top-edge.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/shard-kbl2/igt@kms_cursor_edge_w...@pipe-b-64x64-top-edge.html * igt@kms_cursor_legacy@cursor-vs-flip-varying-size: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +9 similar issues
Re: [Intel-gfx] [PATCH 02/23] drm/i915/gem: Split the context's obj:vma lut into its own mutex
Hi Chris,
> @@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private
> *file_priv,
> if (vm == rcu_access_pointer(ctx->vm))
> goto unlock;
>
> + old = __set_ppgtt(ctx, vm);
> +
> /* Teardown the existing obj:vma cache, it will have to be rebuilt. */
> lut_close(ctx);
>
> - old = __set_ppgtt(ctx, vm);
> -
> /*
>* We need to flush any requests using the current ppgtt before
>* we release it as the requests do not hold a reference themselves,
> @@ -1330,6 +1332,7 @@ static int set_ppgtt(struct drm_i915_file_private
> *file_priv,
> if (err) {
> i915_vm_close(__set_ppgtt(ctx, old));
> i915_vm_close(old);
> + lut_close(ctx); /* rebuild the old obj:vma cache */
I don't really understand this but it doesn't hurt
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> index aa0d06cf1903..51b5a3421b40 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> @@ -23,6 +23,8 @@ mock_context(struct drm_i915_private *i915,
> INIT_LIST_HEAD(>link);
> ctx->i915 = i915;
>
> + mutex_init(>mutex);
> +
> spin_lock_init(>stale.lock);
> INIT_LIST_HEAD(>stale.engines);
>
> @@ -35,7 +37,7 @@ mock_context(struct drm_i915_private *i915,
> RCU_INIT_POINTER(ctx->engines, e);
>
> INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
> - mutex_init(>mutex);
> + mutex_init(>lut_mutex);
...and I don't really understand why moved the first
init(>mutex) above, is it just aesthetic?
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms that support them
== Series Details == Series: series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms that support them URL : https://patchwork.freedesktop.org/series/79060/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8698_full -> Patchwork_18072_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18072_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18072_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_18072_full: ### IGT changes ### Possible regressions * igt@i915_pm_rps@reset: - shard-skl: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-skl7/igt@i915_pm_...@reset.html Known issues Here are the changes found in Patchwork_18072_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-tglb: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-tglb6/igt@drm_import_exp...@prime.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-tglb8/igt@drm_import_exp...@prime.html * igt@gem_ctx_isolation@nonpriv-switch@vecs0: - shard-iclb: [PASS][4] -> [DMESG-WARN][5] ([i915#1226]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-iclb5/igt@gem_ctx_isolation@nonpriv-swi...@vecs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-iclb2/igt@gem_ctx_isolation@nonpriv-swi...@vecs0.html * igt@gem_exec_balancer@bonded-early: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2079]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-tglb5/igt@gem_exec_balan...@bonded-early.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-tglb1/igt@gem_exec_balan...@bonded-early.html * igt@kms_big_fb@y-tiled-32bpp-rotate-180: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) +11 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-skl10/igt@kms_big...@y-tiled-32bpp-rotate-180.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-skl8/igt@kms_big...@y-tiled-32bpp-rotate-180.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-apl4/igt@kms_big...@y-tiled-64bpp-rotate-180.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-apl3/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-a-ctm-0-75: - shard-kbl: [PASS][12] -> [DMESG-WARN][13] ([i915#93] / [i915#95]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-kbl3/igt@kms_co...@pipe-a-ctm-0-75.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-kbl3/igt@kms_co...@pipe-a-ctm-0-75.html * igt@kms_color@pipe-a-gamma: - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#1149]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-tglb8/igt@kms_co...@pipe-a-gamma.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-tglb5/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#72]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-glk3/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#1635] / [i915#95]) +17 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-apl1/igt@kms_draw_...@draw-method-xrgb-mmap-wc-ytiled.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-apl2/igt@kms_draw_...@draw-method-xrgb-mmap-wc-ytiled.html * igt@kms_flip@flip-vs-expired-vblank@c-dp1: - shard-apl: [PASS][20] -> [FAIL][21] ([i915#79]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/shard-apl4/igt@kms_flip@flip-vs-expired-vbl...@c-dp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/shard-apl3/igt@kms_flip@flip-vs-expired-vbl...@c-dp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render: - shard-tglb: [PASS][22] -> [DMESG-WARN][23] ([i915#1982])
Re: [Intel-gfx] [PATCH 01/23] drm/i915: Drop vm.ref for duplicate vma on construction
Hi Chris, > Ta, going to send that as a patch? mine was a suggestion, it was easier to build the diff than explain myself :) If you want I can send it, though. Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
URL : https://patchwork.freedesktop.org/series/79064/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8702 -> Patchwork_18078
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/index.html
Known issues
Here are the changes found in Patchwork_18078 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2] ([i915#1795])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-skl-6600u/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-skl-6600u/igt@i915_selftest@l...@execlists.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][3] ([i915#1888]) -> [PASS][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-byt-n2820: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-byt-n2820/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-byt-n2820/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][13] ([i915#62] / [i915#95]) ->
[SKIP][14] ([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#1982] / [i915#62] /
[i915#92]) -> [DMESG-WARN][20] ([i915#62] / [i915#92])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18078/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1795]: https://gitlab.freedesktop.org/drm/intel/issues/1795
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
== Series Details == Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3) URL : https://patchwork.freedesktop.org/series/79064/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:786:21: error: incompatible types in comparison expression (different address spaces) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
== Series Details == Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3) URL : https://patchwork.freedesktop.org/series/79064/ State : warning == Summary == $ dim checkpatch origin/drm-tip 15fe500e5d57 drm/i915/gem: Split the context's obj:vma lut into its own mutex -:83: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #83: FILE: drivers/gpu/drm/i915/gem/i915_gem_context_types.h:173: + struct mutex lut_mutex; total: 0 errors, 0 warnings, 1 checks, 137 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+" (rev2)
== Series Details == Series: Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+" (rev2) URL : https://patchwork.freedesktop.org/series/79065/ State : success == Summary == CI Bug Log - changes from CI_DRM_8702 -> Patchwork_18077 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/index.html Known issues Here are the changes found in Patchwork_18077 that come from known issues: ### IGT changes ### Issues hit * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Possible fixes * igt@gem_linear_blits@basic: - fi-tgl-u2: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-tgl-u2/igt@gem_linear_bl...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-tgl-u2/igt@gem_linear_bl...@basic.html * igt@i915_module_load@reload: - fi-byt-n2820: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-byt-n2820/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-byt-n2820/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][17] ([i915#62] / [i915#95]) -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_flip@basic-flip-vs-modeset@a-dp1: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18077/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#1982] / [i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) [23]:
[Intel-gfx] [CI] drm/i915/gem: Split the context's obj:vma lut into its own mutex
Rather than reuse the common ctx->mutex for locking the execbuffer LUT,
split it into its own lock to avoid being taken [as part of ctx->mutex]
at inappropriate times. In particular to avoid the inversion from taking
the timeline->mutex for the whole execbuf submission in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_context.c | 4 +++-
5 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6675447a47b9..41784df51e58 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -101,8 +101,7 @@ static void lut_close(struct i915_gem_context *ctx)
struct radix_tree_iter iter;
void __rcu **slot;
- lockdep_assert_held(>mutex);
-
+ mutex_lock(>lut_mutex);
rcu_read_lock();
radix_tree_for_each_slot(slot, >handles_vma, , 0) {
struct i915_vma *vma = rcu_dereference_raw(*slot);
@@ -135,6 +134,7 @@ static void lut_close(struct i915_gem_context *ctx)
i915_gem_object_put(obj);
}
rcu_read_unlock();
+ mutex_unlock(>lut_mutex);
}
static struct intel_context *
@@ -342,6 +342,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
spin_unlock(>i915->gem.contexts.lock);
mutex_destroy(>engines_mutex);
+ mutex_destroy(>lut_mutex);
if (ctx->timeline)
intel_timeline_put(ctx->timeline);
@@ -725,6 +726,7 @@ __create_context(struct drm_i915_private *i915)
RCU_INIT_POINTER(ctx->engines, e);
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
+ mutex_init(>lut_mutex);
/* NB: Mark all slices as needing a remap so that when the context first
* loads it will restore whatever remap state already exists. If there
@@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
if (vm == rcu_access_pointer(ctx->vm))
goto unlock;
+ old = __set_ppgtt(ctx, vm);
+
/* Teardown the existing obj:vma cache, it will have to be rebuilt. */
lut_close(ctx);
- old = __set_ppgtt(ctx, vm);
-
/*
* We need to flush any requests using the current ppgtt before
* we release it as the requests do not hold a reference themselves,
@@ -1330,6 +1332,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
if (err) {
i915_vm_close(__set_ppgtt(ctx, old));
i915_vm_close(old);
+ lut_close(ctx); /* force a rebuild of the old obj:vma cache */
}
unlock:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..ae14ca24a11f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -170,6 +170,7 @@ struct i915_gem_context {
* per vm, which may be one per context or shared with the global GTT)
*/
struct radix_tree_root handles_vma;
+ struct mutex lut_mutex;
/**
* @name: arbitrary name, used for user debug
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b4862afaaf28..e9bb85b679b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -782,10 +782,13 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
/* Check that the context hasn't been closed in the meantime */
err = -EINTR;
- if (!mutex_lock_interruptible(>mutex)) {
- err = -ENOENT;
- if (likely(!i915_gem_context_is_closed(ctx)))
+ if (!mutex_lock_interruptible(>lut_mutex)) {
+ if (unlikely(ctx->vm && vma->vm != ctx->vm))
+ err = -EAGAIN; /* user racing with ctx set-vm */
+ else if (likely(!i915_gem_context_is_closed(ctx)))
err = radix_tree_insert(>handles_vma, handle, vma);
+ else
+ err = -ENOENT;
if (err == 0) { /* And nor has this handle */
struct drm_i915_gem_object *obj = vma->obj;
@@ -798,7 +801,7 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
}
spin_unlock(>lut_lock);
}
- mutex_unlock(>mutex);
+ mutex_unlock(>lut_mutex);
}
if (unlikely(err))
goto err;
@@ -814,6 +817,8 @@ static int __eb_add_lut(struct i915_execbuffer
Re: [Intel-gfx] [PATCH 01/23] drm/i915: Drop vm.ref for duplicate vma on construction
Hi Chris,
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 1f63c4a1f055..7fe1f317cd2b 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -198,6 +198,7 @@ vma_create(struct drm_i915_gem_object *obj,
> cmp = i915_vma_compare(pos, vm, view);
> if (cmp == 0) {
> spin_unlock(>vma.lock);
> + i915_vm_put(vm);
> i915_vma_free(vma);
You are forgettin one return without dereferencing it.
would this be a solution:
@@ -106,6 +106,7 @@ vma_create(struct drm_i915_gem_object *obj,
{
struct i915_vma *vma;
struct rb_node *rb, **p;
+ struct i915_vma *pos = ERR_PTR(-E2BIG);
/* The aliasing_ppgtt should never be used directly! */
GEM_BUG_ON(vm == >gt->ggtt->alias->vm);
@@ -185,7 +186,6 @@ vma_create(struct drm_i915_gem_object *obj,
rb = NULL;
p = >vma.tree.rb_node;
while (*p) {
- struct i915_vma *pos;
long cmp;
rb = *p;
@@ -197,12 +197,8 @@ vma_create(struct drm_i915_gem_object *obj,
* and dispose of ours.
*/
cmp = i915_vma_compare(pos, vm, view);
- if (cmp == 0) {
- spin_unlock(>vma.lock);
- i915_vm_put(vm);
- i915_vma_free(vma);
- return pos;
- }
+ if (!cmp)
+ goto err_unlock;
if (cmp < 0)
p = >rb_right;
@@ -230,8 +226,9 @@ vma_create(struct drm_i915_gem_object *obj,
err_unlock:
spin_unlock(>vma.lock);
err_vma:
+ i915_vm_put(vm);
i915_vma_free(vma);
- return ERR_PTR(-E2BIG);
+ return pos;
}
Andi
___
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/gem: Split the context's obj:vma lut into its own mutex (rev2)
== Series Details == Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2) URL : https://patchwork.freedesktop.org/series/79064/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8702 -> Patchwork_18076 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18076 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18076, 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_18076/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18076: ### IGT changes ### Possible regressions * igt@gem_busy@busy@all: - fi-ilk-650: [PASS][1] -> [INCOMPLETE][2] +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-ilk-650/igt@gem_busy@b...@all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-ilk-650/igt@gem_busy@b...@all.html - fi-snb-2520m: [PASS][3] -> [INCOMPLETE][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-snb-2520m/igt@gem_busy@b...@all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-snb-2520m/igt@gem_busy@b...@all.html * igt@gem_close_race@basic-process: - fi-ivb-3770:[PASS][5] -> [TIMEOUT][6] +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-ivb-3770/igt@gem_close_r...@basic-process.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-ivb-3770/igt@gem_close_r...@basic-process.html - fi-blb-e6850: [PASS][7] -> [TIMEOUT][8] +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-blb-e6850/igt@gem_close_r...@basic-process.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-blb-e6850/igt@gem_close_r...@basic-process.html - fi-hsw-4770:[PASS][9] -> [TIMEOUT][10] +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-hsw-4770/igt@gem_close_r...@basic-process.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-hsw-4770/igt@gem_close_r...@basic-process.html * igt@gem_ctx_create@basic-files: - fi-byt-n2820: [PASS][11] -> [TIMEOUT][12] +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-byt-n2820/igt@gem_ctx_cre...@basic-files.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-byt-n2820/igt@gem_ctx_cre...@basic-files.html - fi-byt-j1900: [PASS][13] -> [TIMEOUT][14] +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html * igt@gem_ctx_exec@basic: - fi-ilk-650: [PASS][15] -> [TIMEOUT][16] +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-ilk-650/igt@gem_ctx_e...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-ilk-650/igt@gem_ctx_e...@basic.html - fi-elk-e7500: [PASS][17] -> [TIMEOUT][18] +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-elk-e7500/igt@gem_ctx_e...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-elk-e7500/igt@gem_ctx_e...@basic.html - fi-snb-2520m: [PASS][19] -> [TIMEOUT][20] +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-snb-2520m/igt@gem_ctx_e...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-snb-2520m/igt@gem_ctx_e...@basic.html * igt@gem_exec_basic@basic@rcs0: - fi-bwr-2160:[PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-bwr-2160/igt@gem_exec_basic@ba...@rcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-bwr-2160/igt@gem_exec_basic@ba...@rcs0.html * igt@gem_exec_create@basic: - fi-gdg-551: [PASS][23] -> [TIMEOUT][24] +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-gdg-551/igt@gem_exec_cre...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-gdg-551/igt@gem_exec_cre...@basic.html - fi-bwr-2160:[PASS][25] -> [TIMEOUT][26] +1 similar issue [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8702/fi-bwr-2160/igt@gem_exec_cre...@basic.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18076/fi-bwr-2160/igt@gem_exec_cre...@basic.html * igt@gem_exec_fence@basic-await@rcs0: - fi-ivb-3770:[PASS][27] -> [INCOMPLETE][28] +5 similar issues
Re: [Intel-gfx] [PATCH v2] Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
On Thu, Jul 02, 2020 at 04:09:57PM -0700, Matt Atwood wrote:
> The initial CI results did not include a TGL system which includes a
> panel that is having issues with patch. Revert while we triage.
>
> This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
>
> Signed-off-by: Matt Atwood
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 +++--
> 1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a5ab405d3a12..d6295eb20b63 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -137,8 +137,6 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> *
> * If a CPU or PCH DP output is attached to an eDP panel, this function
> * will return true, and false otherwise.
> - *
> - * This function is not safe to use prior to encoder type being set.
> */
> bool intel_dp_is_edp(struct intel_dp *intel_dp)
> {
> @@ -8159,6 +8157,8 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
>intel_encoder->base.name))
> return false;
>
> + intel_dp_set_source_rates(intel_dp);
> +
> intel_dp->reset_link_params = true;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
> @@ -8174,22 +8174,28 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
>*/
> drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> type = DRM_MODE_CONNECTOR_eDP;
> - intel_encoder->type = INTEL_OUTPUT_EDP;
> -
> - /* eDP only on port B and/or C on vlv/chv */
> - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> - IS_CHERRYVIEW(dev_priv)) &&
> - port != PORT_B && port != PORT_C))
> - return false;
> } else {
> type = DRM_MODE_CONNECTOR_DisplayPort;
> }
>
> - intel_dp_set_source_rates(intel_dp);
> -
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> intel_dp->active_pipe = vlv_active_pipe(intel_dp);
>
> + /*
> + * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> + * for DP the encoder type can be set by the caller to
> + * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> + */
> + if (type == DRM_MODE_CONNECTOR_eDP)
> + intel_encoder->type = INTEL_OUTPUT_EDP;
> +
> + /* eDP only on port B and/or C on vlv/chv */
> + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> + IS_CHERRYVIEW(dev_priv)) &&
> + intel_dp_is_edp(intel_dp) &&
> + port != PORT_B && port != PORT_C))
> + return false;
> +
> drm_dbg_kms(_priv->drm,
> "Adding %s connector on [ENCODER:%d:%s]\n",
> type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> --
> 2.21.3
>
> ___
> 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] Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
On Thu, Jul 02, 2020 at 03:34:36PM -0700, Souza, Jose wrote:
> On Thu, 2020-07-02 at 15:18 -0700, Matt Atwood wrote:
> > The initial CI results did not include a TGL system which includes a
> > panel that is having issues with patch. Revert while we triage.
> >
> > This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
>
> Missing the Signed-off-by line also the commit references should follow this
> format "2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm-
> >mutex")".
> Please CC me in the updated version.
Arent these references for the Fixes , I see that revert references have always
been a full SHA like
Matt has in his patch?
Can you review his v2?
Regards
Manasi
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 28 +++--
> > 1 file changed, 17 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index a5ab405d3a12..d6295eb20b63 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -137,8 +137,6 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> > *
> > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > * will return true, and false otherwise.
> > - *
> > - * This function is not safe to use prior to encoder type being set.
> > */
> > bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > {
> > @@ -8159,6 +8157,8 @@ intel_dp_init_connector(struct intel_digital_port
> > *dig_port,
> > intel_encoder->base.name))
> > return false;
> >
> > + intel_dp_set_source_rates(intel_dp);
> > +
> > intel_dp->reset_link_params = true;
> > intel_dp->pps_pipe = INVALID_PIPE;
> > intel_dp->active_pipe = INVALID_PIPE;
> > @@ -8174,22 +8174,28 @@ intel_dp_init_connector(struct intel_digital_port
> > *dig_port,
> > */
> > drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> > type = DRM_MODE_CONNECTOR_eDP;
> > - intel_encoder->type = INTEL_OUTPUT_EDP;
> > -
> > - /* eDP only on port B and/or C on vlv/chv */
> > - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > - IS_CHERRYVIEW(dev_priv)) &&
> > - port != PORT_B && port != PORT_C))
> > - return false;
> > } else {
> > type = DRM_MODE_CONNECTOR_DisplayPort;
> > }
> >
> > - intel_dp_set_source_rates(intel_dp);
> > -
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > intel_dp->active_pipe = vlv_active_pipe(intel_dp);
> >
> > + /*
> > +* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> > +* for DP the encoder type can be set by the caller to
> > +* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> > +*/
> > + if (type == DRM_MODE_CONNECTOR_eDP)
> > + intel_encoder->type = INTEL_OUTPUT_EDP;
> > +
> > + /* eDP only on port B and/or C on vlv/chv */
> > + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > + IS_CHERRYVIEW(dev_priv)) &&
> > + intel_dp_is_edp(intel_dp) &&
> > + port != PORT_B && port != PORT_C))
> > + return false;
> > +
> > drm_dbg_kms(_priv->drm,
> > "Adding %s connector on [ENCODER:%d:%s]\n",
> > type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K
On Thu, Jul 02, 2020 at 12:15:26PM +0300, Stanislav Lisovskiy wrote:
> We still need "Bump up CDCLK" workaround otherwise getting
> underruns - however currently it blocks 8K as CDCLK = Pixel rate,
> in 8K case would require CDCLK to be around 1 Ghz which is not
> possible.
>
> v2: - Convert to expression(max(min_cdclk, min(pixel_rate, max_cdclk))
> (Ville Syrjälä)
> - Use type specific min_t, max_t(Ville Syrjälä)
>
> Signed-off-by: Stanislav Lisovskiy
I have tested this and this unblocks 8K
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 45f7f33d1144..8f9320e1e249 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2080,8 +2080,15 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
>* Explicitly stating here that this seems to be currently
>* rather a Hack, than final solution.
>*/
> - if (IS_TIGERLAKE(dev_priv))
> - min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> + if (IS_TIGERLAKE(dev_priv)) {
> + /*
> + * Clamp to max_cdclk_freq in case pixel rate is higher,
> + * in order not to break an 8K, but still leave W/A at place.
> + */
> + min_cdclk = max_t(int, min_cdclk,
> + min_t(int, crtc_state->pixel_rate,
> + dev_priv->max_cdclk_freq));
> + }
>
> if (min_cdclk > dev_priv->max_cdclk_freq) {
> drm_dbg_kms(_priv->drm,
> --
> 2.24.1.485.gad05a3d8e5
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2)
== Series Details == Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2) URL : https://patchwork.freedesktop.org/series/79064/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:786:21: error: incompatible types in comparison expression (different address spaces) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2)
== Series Details == Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2) URL : https://patchwork.freedesktop.org/series/79064/ State : warning == Summary == $ dim checkpatch origin/drm-tip e64718ab4fd9 drm/i915/gem: Split the context's obj:vma lut into its own mutex -:83: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #83: FILE: drivers/gpu/drm/i915/gem/i915_gem_context_types.h:173: + struct mutex lut_mutex; total: 0 errors, 0 warnings, 1 checks, 137 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbc: Use the correct plane stride
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Consult the actual plane stride instead of the fb stride. The two
> will disagree when we remap the gtt. The plane stride is what the
> hw will be fed so that's what we should look at for the FBC
> retrictions/cfb allocation.
>
> Since we no longer require a fence we are going to attempt using
> FBC with remapping, and so we should look at correct stride.
>
> With 90/270 degree rotation the plane stride is stored in units
> of pixels, so we need to conver it to bytes for the purposes
> of calculating the cfb stride. Not entirely sure if this matches
> the hw behaviour though. Need to reverse engineer that at some
> point...
>
> We also need to reorder the pixel format check vs. stride check
> to avoid triggering a spurious WARN(stride & 63) with cpp==1 and
> plane stride==32.
>
> v2: Try to deal with rotated stride and related WARN
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Fixes: 691f7ba58d52 ("drm/i915/display/fbc: Make fences a nice-to-have for
> GEN9+")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 69a0682ddb6a..d30c2a389294 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -695,9 +695,13 @@ static void intel_fbc_update_state_cache(struct
> intel_crtc *crtc,
> cache->plane.pixel_blend_mode = plane_state->hw.pixel_blend_mode;
>
> cache->fb.format = fb->format;
> - cache->fb.stride = fb->pitches[0];
> cache->fb.modifier = fb->modifier;
>
> + /* FIXME is this correct? */
> + cache->fb.stride = plane_state->color_plane[0].stride;
> + if (drm_rotation_90_or_270(plane_state->hw.rotation))
If it was wrong our CI would caught this in BDW or SNB for example.
> + cache->fb.stride *= fb->format->cpp[0];
> +
> /* FBC1 compression interval: arbitrary choice of 1 second */
> cache->interval = drm_mode_vrefresh(_state->hw.adjusted_mode);
>
> @@ -797,6 +801,11 @@ static bool intel_fbc_can_activate(struct intel_crtc
> *crtc)
> return false;
> }
>
> + if (!pixel_format_is_valid(dev_priv, cache->fb.format->format)) {
> + fbc->no_fbc_reason = "pixel format is invalid";
> + return false;
> + }
> +
> if (!rotation_is_valid(dev_priv, cache->fb.format->format,
> cache->plane.rotation)) {
> fbc->no_fbc_reason = "rotation unsupported";
> @@ -813,11 +822,6 @@ static bool intel_fbc_can_activate(struct intel_crtc
> *crtc)
> return false;
> }
>
> - if (!pixel_format_is_valid(dev_priv, cache->fb.format->format)) {
> - fbc->no_fbc_reason = "pixel format is invalid";
> - return false;
> - }
> -
> if (cache->plane.pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE &&
> cache->fb.format->has_alpha) {
> fbc->no_fbc_reason = "per-pixel alpha blending is incompatible
> with FBC";
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
== Series Details ==
Series: Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
URL : https://patchwork.freedesktop.org/series/79065/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8701 -> Patchwork_18075
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/index.html
Known issues
Here are the changes found in Patchwork_18075 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-kbl-soraka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-soraka/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-n2820: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-byt-n2820/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-byt-n2820/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18075/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
[Intel-gfx] [PATCH v2] Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
The initial CI results did not include a TGL system which includes a
panel that is having issues with patch. Revert while we triage.
This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/display/intel_dp.c | 28 +++--
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a5ab405d3a12..d6295eb20b63 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -137,8 +137,6 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
*
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
- *
- * This function is not safe to use prior to encoder type being set.
*/
bool intel_dp_is_edp(struct intel_dp *intel_dp)
{
@@ -8159,6 +8157,8 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
intel_encoder->base.name))
return false;
+ intel_dp_set_source_rates(intel_dp);
+
intel_dp->reset_link_params = true;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
@@ -8174,22 +8174,28 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
*/
drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
type = DRM_MODE_CONNECTOR_eDP;
- intel_encoder->type = INTEL_OUTPUT_EDP;
-
- /* eDP only on port B and/or C on vlv/chv */
- if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
- IS_CHERRYVIEW(dev_priv)) &&
- port != PORT_B && port != PORT_C))
- return false;
} else {
type = DRM_MODE_CONNECTOR_DisplayPort;
}
- intel_dp_set_source_rates(intel_dp);
-
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->active_pipe = vlv_active_pipe(intel_dp);
+ /*
+* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
+* for DP the encoder type can be set by the caller to
+* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
+*/
+ if (type == DRM_MODE_CONNECTOR_eDP)
+ intel_encoder->type = INTEL_OUTPUT_EDP;
+
+ /* eDP only on port B and/or C on vlv/chv */
+ if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
+ IS_CHERRYVIEW(dev_priv)) &&
+ intel_dp_is_edp(intel_dp) &&
+ port != PORT_B && port != PORT_C))
+ return false;
+
drm_dbg_kms(_priv->drm,
"Adding %s connector on [ENCODER:%d:%s]\n",
type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
--
2.21.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/fbc: Fix nuke for pre-snb platforms
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The MSG_FBC_REND_STATE register only exists on snb+. For older
> platforms (would also work for snb+) we can simply rewite DSPSURF
> to trigger a flip nuke.
>
> While generally RMW is considered harmful we'll use it here for
> simplicity. And since FBC doesn't exist in i830 we don't have to
> worry about the DSPSURF double buffering hardware fails present
> on that platform.
Did not found a explicit statement about writing DSPSURF will nuke compressed
buffer but that makes sense, also checked that MSG_FBC_REND_STATE do not
exist this older platforms.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 34 +++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index d30c2a389294..036546ce8db8 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -187,8 +187,30 @@ static bool g4x_fbc_is_active(struct drm_i915_private
> *dev_priv)
> return intel_de_read(dev_priv, DPFC_CONTROL) & DPFC_CTL_EN;
> }
>
> +static void i8xx_fbc_recompress(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbc_reg_params *params = _priv->fbc.params;
> + enum i9xx_plane_id i9xx_plane = params->crtc.i9xx_plane;
> +
> + spin_lock_irq(_priv->uncore.lock);
> + intel_de_write_fw(dev_priv, DSPADDR(i9xx_plane),
> + intel_de_read_fw(dev_priv, DSPADDR(i9xx_plane)));
> + spin_unlock_irq(_priv->uncore.lock);
> +}
> +
> +static void i965_fbc_recompress(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbc_reg_params *params = _priv->fbc.params;
> + enum i9xx_plane_id i9xx_plane = params->crtc.i9xx_plane;
> +
> + spin_lock_irq(_priv->uncore.lock);
> + intel_de_write_fw(dev_priv, DSPSURF(i9xx_plane),
> + intel_de_read_fw(dev_priv, DSPSURF(i9xx_plane)));
> + spin_unlock_irq(_priv->uncore.lock);
> +}
> +
> /* This function forces a CFB recompression through the nuke operation. */
> -static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
> +static void snb_fbc_recompress(struct drm_i915_private *dev_priv)
> {
> struct intel_fbc *fbc = _priv->fbc;
>
> @@ -198,6 +220,16 @@ static void intel_fbc_recompress(struct drm_i915_private
> *dev_priv)
> intel_de_posting_read(dev_priv, MSG_FBC_REND_STATE);
> }
>
> +static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
> +{
> + if (INTEL_GEN(dev_priv) >= 6)
> + snb_fbc_recompress(dev_priv);
> + else if (INTEL_GEN(dev_priv) >= 4)
> + i965_fbc_recompress(dev_priv);
> + else
> + i8xx_fbc_recompress(dev_priv);
> +}
> +
> static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
> {
> struct intel_fbc_reg_params *params = _priv->fbc.params;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
== Series Details == Series: Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+" URL : https://patchwork.freedesktop.org/series/79065/ State : warning == Summary == $ dim checkpatch origin/drm-tip 138679950a74 Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+" -:70: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 0 warnings, 0 checks, 53 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Also drop vm.ref along error paths for vma construction
== Series Details ==
Series: drm/i915: Also drop vm.ref along error paths for vma construction
URL : https://patchwork.freedesktop.org/series/79063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8701 -> Patchwork_18074
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/index.html
Known issues
Here are the changes found in Patchwork_18074 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-glk-dsi/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@i915_module_load@reload:
- fi-kbl-soraka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-soraka/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-n2820: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-byt-n2820/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-byt-n2820/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#1982] / [i915#62] / [i915#92])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-icl-u2: [DMESG-WARN][15] ([i915#289]) -> [DMESG-WARN][16]
([i915#1982] / [i915#289])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-icl-u2/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-icl-u2/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8701/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18074/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
== Series Details == Series: series starting with [CI,1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes URL : https://patchwork.freedesktop.org/series/79053/ State : success == Summary == CI Bug Log - changes from CI_DRM_8697_full -> Patchwork_18071_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18071_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@vecs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#93] / [i915#95]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-kbl6/igt@gem_exec_reloc@basic-many-act...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-kbl6/igt@gem_exec_reloc@basic-many-act...@vecs0.html * igt@gem_exec_whisper@basic-forked-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-glk6/igt@gem_exec_whis...@basic-forked-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-glk5/igt@gem_exec_whis...@basic-forked-all.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-iclb: [PASS][5] -> [FAIL][6] ([i915#1515]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-iclb4/igt@i915_pm_rc6_reside...@rc6-idle.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-iclb8/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_selftest@mock@requests: - shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([i915#2110]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-tglb6/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-tglb5/igt@i915_selftest@m...@requests.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +12 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-skl7/igt@kms_co...@pipe-c-ctm-0-25.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-skl9/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@pipe-a-forked-move: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / [i915#95]) +20 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-apl2/igt@kms_cursor_leg...@pipe-a-forked-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-apl7/igt@kms_cursor_leg...@pipe-a-forked-move.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-tglb3/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-gtt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-gtt.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-skl5/igt@kms_...@bpc-switch.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-skl7/igt@kms_...@bpc-switch.html * igt@kms_plane_cursor@pipe-a-viewport-size-256: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#1559]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-glk7/igt@kms_plane_cur...@pipe-a-viewport-size-256.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-glk4/igt@kms_plane_cur...@pipe-a-viewport-size-256.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#173]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-iclb5/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/shard-iclb4/igt@kms_psr@psr2_cursor_render.html Possible fixes * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-kbl: [DMESG-WARN][25] ([i915#180]) -> [PASS][26] +6
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Enable TPS3/4 on all platforms that support them
On Thu, Jul 02, 2020 at 09:24:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Stop using HBR2/3 support as a proxy for TPS3/4 support.
> The two are no longer 1:1 in the hardware, arguably they
> never were due to HSW ULX which does support TPS3 while
> being limited to HBR1.
>
> In more recent times GLK gained support for TPS4 while
> being limited to HBR2. And on CNL+ some ports support
> HBR3 while others are limited to HBR2, but all ports
> support TPS4.
>
> Signed-off-by: Ville Syrjälä
Makes sense to me
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 +++-
> drivers/gpu/drm/i915/display/intel_dp.h | 4 +--
> .../drm/i915/display/intel_dp_link_training.c | 29 +++
> drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
> 4 files changed, 17 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c9b93c5706af..5ac182357fc9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1799,18 +1799,14 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
> intel_dp->aux.transfer = intel_dp_aux_transfer;
> }
>
> -bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
> +bool intel_dp_source_supports_tps3(struct drm_i915_private *i915)
> {
> - int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
> -
> - return max_rate >= 54;
> + return INTEL_GEN(i915) >= 9 || IS_BROADWELL(i915) || IS_HASWELL(i915);
> }
>
> -bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp)
> +bool intel_dp_source_supports_tps4(struct drm_i915_private *i915)
> {
> - int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
> -
> - return max_rate >= 81;
> + return INTEL_GEN(i915) >= 10 || IS_GEMINILAKE(i915);
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 0a8950f744f6..d597a9848397 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -94,8 +94,8 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp);
> void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> u8 *link_bw, u8 *rate_select);
> -bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> -bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
> +bool intel_dp_source_supports_tps3(struct drm_i915_private *i915);
> +bool intel_dp_source_supports_tps4(struct drm_i915_private *i915);
> bool
> intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 2493142a70e9..57c2089c9f5a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -259,41 +259,32 @@ intel_dp_link_training_clock_recovery(struct intel_dp
> *intel_dp)
> */
> static u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> bool source_tps3, sink_tps3, source_tps4, sink_tps4;
>
> - /*
> - * Intel platforms that support HBR3 also support TPS4. It is mandatory
> - * for all downstream devices that support HBR3. There are no known eDP
> - * panels that support TPS4 as of Feb 2018 as per VESA eDP_v1.4b_E1
> - * specification.
> - */
> - source_tps4 = intel_dp_source_supports_hbr3(intel_dp);
> + source_tps4 = intel_dp_source_supports_tps4(i915);
> sink_tps4 = drm_dp_tps4_supported(intel_dp->dpcd);
> if (source_tps4 && sink_tps4) {
> return DP_TRAINING_PATTERN_4;
> } else if (intel_dp->link_rate == 81) {
> if (!source_tps4)
> - drm_dbg_kms(_to_i915(intel_dp)->drm,
> - "8.1 Gbps link rate without source
> HBR3/TPS4 support\n");
> + drm_dbg_kms(>drm,
> + "8.1 Gbps link rate without source TPS4
> support\n");
> if (!sink_tps4)
> - drm_dbg_kms(_to_i915(intel_dp)->drm,
> + drm_dbg_kms(>drm,
> "8.1 Gbps link rate without sink TPS4
> support\n");
> }
> - /*
> - * Intel platforms that support HBR2 also support TPS3. TPS3 support is
> - * also mandatory for downstream devices that support HBR2. However, not
> - * all sinks follow the spec.
> - */
> - source_tps3 = intel_dp_source_supports_hbr2(intel_dp);
> +
> + source_tps3 = intel_dp_source_supports_tps3(i915);
> sink_tps3 = drm_dp_tps3_supported(intel_dp->dpcd);
> if (source_tps3
Re: [Intel-gfx] [PATCH] Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
On Thu, 2020-07-02 at 15:18 -0700, Matt Atwood wrote:
> The initial CI results did not include a TGL system which includes a
> panel that is having issues with patch. Revert while we triage.
>
> This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
Missing the Signed-off-by line also the commit references should follow this
format "2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm-
>mutex")".
Please CC me in the updated version.
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 +++--
> 1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a5ab405d3a12..d6295eb20b63 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -137,8 +137,6 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> *
> * If a CPU or PCH DP output is attached to an eDP panel, this function
> * will return true, and false otherwise.
> - *
> - * This function is not safe to use prior to encoder type being set.
> */
> bool intel_dp_is_edp(struct intel_dp *intel_dp)
> {
> @@ -8159,6 +8157,8 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
>intel_encoder->base.name))
> return false;
>
> + intel_dp_set_source_rates(intel_dp);
> +
> intel_dp->reset_link_params = true;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
> @@ -8174,22 +8174,28 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
>*/
> drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> type = DRM_MODE_CONNECTOR_eDP;
> - intel_encoder->type = INTEL_OUTPUT_EDP;
> -
> - /* eDP only on port B and/or C on vlv/chv */
> - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> - IS_CHERRYVIEW(dev_priv)) &&
> - port != PORT_B && port != PORT_C))
> - return false;
> } else {
> type = DRM_MODE_CONNECTOR_DisplayPort;
> }
>
> - intel_dp_set_source_rates(intel_dp);
> -
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> intel_dp->active_pipe = vlv_active_pipe(intel_dp);
>
> + /*
> + * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> + * for DP the encoder type can be set by the caller to
> + * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> + */
> + if (type == DRM_MODE_CONNECTOR_eDP)
> + intel_encoder->type = INTEL_OUTPUT_EDP;
> +
> + /* eDP only on port B and/or C on vlv/chv */
> + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> + IS_CHERRYVIEW(dev_priv)) &&
> + intel_dp_is_edp(intel_dp) &&
> + port != PORT_B && port != PORT_C))
> + return false;
> +
> drm_dbg_kms(_priv->drm,
> "Adding %s connector on [ENCODER:%d:%s]\n",
> type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/fbc: Allow FBC to recompress after a 3D workload on i85x/i865
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Normally i85x/i865 3D activity will block FBC until a 2D blit > occurs. I suppose this was meant to avoid recompression while > 3D activity is still going on but the frame hasn't yet been > presented. Unfortunately that also means that a page flipped > 3D workload will permanently block FBC even if it only renders > a single frame and then does nothing. > > Since we are using software render tracking anyway we might as > well flip the chicken bit so that 3D does not block FBC. This > will avoid the permament FBC blockage in the aforemention use > case, but thanks to the software tracking the compressor will > not disturb 3D rendering activity. Register does what is described. Reviewed-by: José Roberto de Souza > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 10 ++ > 2 files changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 9d6536afc94b..03590d2d75f7 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -2827,6 +2827,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > #define VLV_GU_CTL0 _MMIO(VLV_DISPLAY_BASE + 0x2030) > #define VLV_GU_CTL1 _MMIO(VLV_DISPLAY_BASE + 0x2034) > #define SCPD0_MMIO(0x209c) /* 915+ only */ > +#define SCPD_FBC_IGNORE_3D (1 << 6) > #define CSTATE_RENDER_CLOCK_GATE_DISABLE(1 << 5) > #define GEN2_IER _MMIO(0x20a0) > #define GEN2_IIR _MMIO(0x20a4) > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 565a2b9da3b3..2d980b83a1f1 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -7471,6 +7471,16 @@ static void i85x_init_clock_gating(struct > drm_i915_private *dev_priv) > > I915_WRITE(MEM_MODE, > _MASKED_BIT_ENABLE(MEM_DISPLAY_TRICKLE_FEED_DISABLE)); > + > + /* > + * Have FBC ignore 3D activity since we use software > + * render tracking, and otherwise a pure 3D workload > + * (even if it just renders a single frame and then does > + * abosultely nothing) would not allow FBC to recompress > + * until a 2D blit occurs. > + */ > + I915_WRITE(SCPD0, > +_MASKED_BIT_ENABLE(SCPD_FBC_IGNORE_3D)); > } > > static void i830_init_clock_gating(struct drm_i915_private *dev_priv) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gem: Split the context's obj:vma lut into its own mutex
Rather than reuse the common ctx->mutex for locking the execbuffer LUT,
split it into its own lock to avoid being taken [as part of ctx->mutex]
at inappropriate times. In particular to avoid the inversion from taking
the timeline->mutex for the whole execbuf submission in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_context.c | 4 +++-
5 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6675447a47b9..41784df51e58 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -101,8 +101,7 @@ static void lut_close(struct i915_gem_context *ctx)
struct radix_tree_iter iter;
void __rcu **slot;
- lockdep_assert_held(>mutex);
-
+ mutex_lock(>lut_mutex);
rcu_read_lock();
radix_tree_for_each_slot(slot, >handles_vma, , 0) {
struct i915_vma *vma = rcu_dereference_raw(*slot);
@@ -135,6 +134,7 @@ static void lut_close(struct i915_gem_context *ctx)
i915_gem_object_put(obj);
}
rcu_read_unlock();
+ mutex_unlock(>lut_mutex);
}
static struct intel_context *
@@ -342,6 +342,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
spin_unlock(>i915->gem.contexts.lock);
mutex_destroy(>engines_mutex);
+ mutex_destroy(>lut_mutex);
if (ctx->timeline)
intel_timeline_put(ctx->timeline);
@@ -725,6 +726,7 @@ __create_context(struct drm_i915_private *i915)
RCU_INIT_POINTER(ctx->engines, e);
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
+ mutex_init(>lut_mutex);
/* NB: Mark all slices as needing a remap so that when the context first
* loads it will restore whatever remap state already exists. If there
@@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
if (vm == rcu_access_pointer(ctx->vm))
goto unlock;
+ old = __set_ppgtt(ctx, vm);
+
/* Teardown the existing obj:vma cache, it will have to be rebuilt. */
lut_close(ctx);
- old = __set_ppgtt(ctx, vm);
-
/*
* We need to flush any requests using the current ppgtt before
* we release it as the requests do not hold a reference themselves,
@@ -1330,6 +1332,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
if (err) {
i915_vm_close(__set_ppgtt(ctx, old));
i915_vm_close(old);
+ lut_close(ctx); /* force a rebuild of the old obj:vma cache */
}
unlock:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..ae14ca24a11f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -170,6 +170,7 @@ struct i915_gem_context {
* per vm, which may be one per context or shared with the global GTT)
*/
struct radix_tree_root handles_vma;
+ struct mutex lut_mutex;
/**
* @name: arbitrary name, used for user debug
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b4862afaaf28..52391894c994 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -782,10 +782,13 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
/* Check that the context hasn't been closed in the meantime */
err = -EINTR;
- if (!mutex_lock_interruptible(>mutex)) {
- err = -ENOENT;
- if (likely(!i915_gem_context_is_closed(ctx)))
+ if (!mutex_lock_interruptible(>lut_mutex)) {
+ if (unlikely(vma->vm != ctx->vm))
+ err = -EAGAIN; /* user racing with ctx set-vm */
+ else if (likely(!i915_gem_context_is_closed(ctx)))
err = radix_tree_insert(>handles_vma, handle, vma);
+ else
+ err = -ENOENT;
if (err == 0) { /* And nor has this handle */
struct drm_i915_gem_object *obj = vma->obj;
@@ -798,7 +801,7 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
}
spin_unlock(>lut_lock);
}
- mutex_unlock(>mutex);
+ mutex_unlock(>lut_mutex);
}
if (unlikely(err))
goto err;
@@ -814,6 +817,8 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
[Intel-gfx] [PATCH] Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
The initial CI results did not include a TGL system which includes a
panel that is having issues with patch. Revert while we triage.
This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
---
drivers/gpu/drm/i915/display/intel_dp.c | 28 +++--
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a5ab405d3a12..d6295eb20b63 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -137,8 +137,6 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
*
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
- *
- * This function is not safe to use prior to encoder type being set.
*/
bool intel_dp_is_edp(struct intel_dp *intel_dp)
{
@@ -8159,6 +8157,8 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
intel_encoder->base.name))
return false;
+ intel_dp_set_source_rates(intel_dp);
+
intel_dp->reset_link_params = true;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
@@ -8174,22 +8174,28 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
*/
drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
type = DRM_MODE_CONNECTOR_eDP;
- intel_encoder->type = INTEL_OUTPUT_EDP;
-
- /* eDP only on port B and/or C on vlv/chv */
- if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
- IS_CHERRYVIEW(dev_priv)) &&
- port != PORT_B && port != PORT_C))
- return false;
} else {
type = DRM_MODE_CONNECTOR_DisplayPort;
}
- intel_dp_set_source_rates(intel_dp);
-
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->active_pipe = vlv_active_pipe(intel_dp);
+ /*
+* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
+* for DP the encoder type can be set by the caller to
+* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
+*/
+ if (type == DRM_MODE_CONNECTOR_eDP)
+ intel_encoder->type = INTEL_OUTPUT_EDP;
+
+ /* eDP only on port B and/or C on vlv/chv */
+ if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
+ IS_CHERRYVIEW(dev_priv)) &&
+ intel_dp_is_edp(intel_dp) &&
+ port != PORT_B && port != PORT_C))
+ return false;
+
drm_dbg_kms(_priv->drm,
"Adding %s connector on [ENCODER:%d:%s]\n",
type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
--
2.21.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gem: Split the context's obj:vma lut into its own mutex
Rather than reuse the common ctx->mutex for locking the execbuffer LUT,
split it into its own lock to avoid being taken [as part of ctx->mutex]
at inappropriate times. In particular to avoid the inversion from taking
the timeline->mutex for the whole execbuf submission in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 +++
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 11 +++
drivers/gpu/drm/i915/gem/i915_gem_object.c| 4 ++--
drivers/gpu/drm/i915/gem/selftests/mock_context.c | 4 +++-
5 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6675447a47b9..41784df51e58 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -101,8 +101,7 @@ static void lut_close(struct i915_gem_context *ctx)
struct radix_tree_iter iter;
void __rcu **slot;
- lockdep_assert_held(>mutex);
-
+ mutex_lock(>lut_mutex);
rcu_read_lock();
radix_tree_for_each_slot(slot, >handles_vma, , 0) {
struct i915_vma *vma = rcu_dereference_raw(*slot);
@@ -135,6 +134,7 @@ static void lut_close(struct i915_gem_context *ctx)
i915_gem_object_put(obj);
}
rcu_read_unlock();
+ mutex_unlock(>lut_mutex);
}
static struct intel_context *
@@ -342,6 +342,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
spin_unlock(>i915->gem.contexts.lock);
mutex_destroy(>engines_mutex);
+ mutex_destroy(>lut_mutex);
if (ctx->timeline)
intel_timeline_put(ctx->timeline);
@@ -725,6 +726,7 @@ __create_context(struct drm_i915_private *i915)
RCU_INIT_POINTER(ctx->engines, e);
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
+ mutex_init(>lut_mutex);
/* NB: Mark all slices as needing a remap so that when the context first
* loads it will restore whatever remap state already exists. If there
@@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
if (vm == rcu_access_pointer(ctx->vm))
goto unlock;
+ old = __set_ppgtt(ctx, vm);
+
/* Teardown the existing obj:vma cache, it will have to be rebuilt. */
lut_close(ctx);
- old = __set_ppgtt(ctx, vm);
-
/*
* We need to flush any requests using the current ppgtt before
* we release it as the requests do not hold a reference themselves,
@@ -1330,6 +1332,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
if (err) {
i915_vm_close(__set_ppgtt(ctx, old));
i915_vm_close(old);
+ lut_close(ctx); /* force a rebuild of the old obj:vma cache */
}
unlock:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..ae14ca24a11f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -170,6 +170,7 @@ struct i915_gem_context {
* per vm, which may be one per context or shared with the global GTT)
*/
struct radix_tree_root handles_vma;
+ struct mutex lut_mutex;
/**
* @name: arbitrary name, used for user debug
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b4862afaaf28..0253c403d2e3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -782,10 +782,13 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
/* Check that the context hasn't been closed in the meantime */
err = -EINTR;
- if (!mutex_lock_interruptible(>mutex)) {
- err = -ENOENT;
- if (likely(!i915_gem_context_is_closed(ctx)))
+ if (!mutex_lock_interruptible(>lut_mutex)) {
+ if (unlikely(vma->vm != ctx->vm))
+ err = -EAGAIN; /* user racing with ctx set-vm */
+ else if (likely(!i915_gem_context_is_closed(ctx)))
err = radix_tree_insert(>handles_vma, handle, vma);
+ else
+ err = -ENOENT;
if (err == 0) { /* And nor has this handle */
struct drm_i915_gem_object *obj = vma->obj;
@@ -798,7 +801,7 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
}
spin_unlock(>lut_lock);
}
- mutex_unlock(>mutex);
+ mutex_unlock(>lut_mutex);
}
if (unlikely(err))
goto err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
Re: [Intel-gfx] [PATCH 02/23] drm/i915/gem: Split the context's obj:vma lut into its own mutex
Quoting Andi Shyti (2020-07-02 23:09:44)
> Hi Chris,
>
> > @@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private
> > *file_priv,
> > if (vm == rcu_access_pointer(ctx->vm))
> > goto unlock;
> >
> > + old = __set_ppgtt(ctx, vm);
> > +
> > /* Teardown the existing obj:vma cache, it will have to be rebuilt. */
> > lut_close(ctx);
> >
> > - old = __set_ppgtt(ctx, vm);
> > -
> > /*
> >* We need to flush any requests using the current ppgtt before
> >* we release it as the requests do not hold a reference themselves,
> > @@ -1330,6 +1332,7 @@ static int set_ppgtt(struct drm_i915_file_private
> > *file_priv,
> > if (err) {
> > i915_vm_close(__set_ppgtt(ctx, old));
> > i915_vm_close(old);
> > + lut_close(ctx); /* rebuild the old obj:vma cache */
>
> I don't really understand this but it doesn't hurt
Yeah; another testcase required for racing set-vm against execbuf.
Outcome unknown, all that we have to avoid are explosions. Userspace is
allowed to shoot itself in the foot, but is not allowed to shoot anyone
else.
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > index aa0d06cf1903..51b5a3421b40 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > @@ -23,6 +23,8 @@ mock_context(struct drm_i915_private *i915,
> > INIT_LIST_HEAD(>link);
> > ctx->i915 = i915;
> >
> > + mutex_init(>mutex);
> > +
> > spin_lock_init(>stale.lock);
> > INIT_LIST_HEAD(>stale.engines);
> >
> > @@ -35,7 +37,7 @@ mock_context(struct drm_i915_private *i915,
> > RCU_INIT_POINTER(ctx->engines, e);
> >
> > INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
> > - mutex_init(>mutex);
> > + mutex_init(>lut_mutex);
>
> ...and I don't really understand why moved the first
> init(>mutex) above, is it just aesthetic?
Yup. The ctx->mutex is the broader one, so I felt it deserved to be
higher. Whereas here we are setting up the lut [handles_vma] so was the
natural spot to place the ctx->lut_mutex; and I wanted some distance
between the pair to keep the confusion at bay.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/fbc: Enable fbc on i865
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Unlike all the other pre-snb desktop platforms i865 actually
> supports FBC. Let's enable it.
>
> Quote from the spec:
> "DevSDG provides the same Run-Length Encoded Frame Buffer
> Compression (RLEFBC) function as exists in DevMGM."
>
> As i865 only has the one pipe we want to skip massaging the
> plane<->pipe assignment aimed at getting FBC+LVDS working on
> the mobile platforms.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 84e2a17b5ecb..653f6617d59a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16332,7 +16332,8 @@ intel_primary_plane_create(struct drm_i915_private
> *dev_priv, enum pipe pipe)
>* On gen2/3 only plane A can do FBC, but the panel fitter and LVDS
>* port is hooked to pipe B. Hence we want plane A feeding pipe B.
>*/
> - if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4)
> + if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4 &&
> + INTEL_NUM_PIPES(dev_priv) == 2)
> plane->i9xx_plane = (enum i9xx_plane_id) !pipe;
> else
> plane->i9xx_plane = (enum i9xx_plane_id) pipe;
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index e5fdf17cd9cd..0be3b66ce666 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -217,6 +217,7 @@ static const struct intel_device_info i85x_info = {
> static const struct intel_device_info i865g_info = {
> I845_FEATURES,
> PLATFORM(INTEL_I865G),
> + .display.has_fbc = 1,
> };
>
> #define GEN3_FEATURES \
___
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: FBC fixes (rev3)
== Series Details == Series: drm/i915: FBC fixes (rev3) URL : https://patchwork.freedesktop.org/series/76714/ State : success == Summary == CI Bug Log - changes from CI_DRM_8697_full -> Patchwork_18070_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18070_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-kbl6/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-kbl6/igt@gem_...@in-flight-suspend.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#1930]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-snb: [PASS][5] -> [INCOMPLETE][6] ([i915#82]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-snb5/igt@gem_exec_whis...@basic-contexts-forked-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-snb2/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_exec_whisper@basic-forked-all: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-glk6/igt@gem_exec_whis...@basic-forked-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-glk1/igt@gem_exec_whis...@basic-forked-all.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-hsw: [PASS][9] -> [WARN][10] ([i915#1519]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-fence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#1515]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-iclb4/igt@i915_pm_rc6_reside...@rc6-idle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-iclb5/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_selftest@mock@requests: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#2110]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-tglb6/igt@i915_selftest@m...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-tglb3/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][15] -> [DMESG-FAIL][16] ([i915#118] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-glk4/igt@kms_big...@linear-64bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_cursor_legacy@pipe-a-forked-move: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / [i915#95]) +14 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-apl2/igt@kms_cursor_leg...@pipe-a-forked-move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-apl1/igt@kms_cursor_leg...@pipe-a-forked-move.html * igt@kms_flip@flip-vs-wf_vblank-interruptible@a-dp1: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-kbl6/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-kbl6/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-wf_vblank-interruptible@a-edp1: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-tglb8/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-tglb7/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-edp1.html * igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +9 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-pipe-b-planes.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-pipe-b-planes.html * igt@kms_plane_cursor@pipe-a-viewport-size-256: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#1559])
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: do not read swizzle info if unavailable (rev2)
== Series Details ==
Series: drm/i915: do not read swizzle info if unavailable (rev2)
URL : https://patchwork.freedesktop.org/series/79007/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8700 -> Patchwork_18073
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/index.html
Known issues
Here are the changes found in Patchwork_18073 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-tgl-dsi/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62] / [i915#95]) ->
[SKIP][16] ([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8700/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18073/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u
[Intel-gfx] [PATCH] drm/i915: Also drop vm.ref along error paths for vma construction
Not only do we need to release the vm.ref we acquired for the vma on the
duplicate insert branch, but also for the normal error paths, so roll
them all into one.
Reported-by: Andi Shyti
Suggested-by: Andi Shyti
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: # v5.5+
---
drivers/gpu/drm/i915/i915_vma.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7fe1f317cd2b..f4e22e256ac6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -104,6 +104,7 @@ vma_create(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
const struct i915_ggtt_view *view)
{
+ struct i915_vma *pos = ERR_PTR(-E2BIG);
struct i915_vma *vma;
struct rb_node *rb, **p;
@@ -184,7 +185,6 @@ vma_create(struct drm_i915_gem_object *obj,
rb = NULL;
p = >vma.tree.rb_node;
while (*p) {
- struct i915_vma *pos;
long cmp;
rb = *p;
@@ -196,17 +196,12 @@ vma_create(struct drm_i915_gem_object *obj,
* and dispose of ours.
*/
cmp = i915_vma_compare(pos, vm, view);
- if (cmp == 0) {
- spin_unlock(>vma.lock);
- i915_vm_put(vm);
- i915_vma_free(vma);
- return pos;
- }
-
if (cmp < 0)
p = >rb_right;
- else
+ else if (cmp > 0)
p = >rb_left;
+ else
+ goto err_unlock;
}
rb_link_node(>obj_node, rb, p);
rb_insert_color(>obj_node, >vma.tree);
@@ -229,8 +224,9 @@ vma_create(struct drm_i915_gem_object *obj,
err_unlock:
spin_unlock(>vma.lock);
err_vma:
+ i915_vm_put(vm);
i915_vma_free(vma);
- return ERR_PTR(-E2BIG);
+ return pos;
}
static struct i915_vma *
--
2.20.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/edid: Allow looking for ext blocks starting from a specified index
On Thu, 2020-07-02 at 17:40 +0300, Ville Syrjälä wrote:
> On Tue, Jun 30, 2020 at 11:42:36PM +, Souza, Jose wrote:
> > On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> > > for iterating through multiple ext blocks of the same type by
> > > passing the starting ext block index to drm_find_edid_extension(). Well
> > > also have drm_find_edid_extension() update the index to point to the
> > > next ext block on success. Thus we should be able to call
> > > drm_find_edid_extension() in loop.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 30 +-
> > > 1 file changed, 21 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index d8372d63851b..f2531d51dfa2 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3188,7 +3188,8 @@ add_detailed_modes(struct drm_connector *connector,
> > > struct edid *edid,
> > > /*
> > > * Search EDID for CEA extension block.
> > > */
> > > -static u8 *drm_find_edid_extension(const struct edid *edid, int ext_id)
> > > +static u8 *drm_find_edid_extension(const struct edid *edid,
> > > +int ext_id, int *ext_index)
> > > {
> > > u8 *edid_ext = NULL;
> > > int i;
> > > @@ -3198,23 +3199,26 @@ static u8 *drm_find_edid_extension(const struct
> > > edid *edid, int ext_id)
> > > return NULL;
> > >
> > > /* Find CEA extension */
> > > - for (i = 0; i < edid->extensions; i++) {
> > > + for (i = *ext_index; i < edid->extensions; i++) {
> > > edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
> > > if (edid_ext[0] == ext_id)
> > > break;
> > > }
> > >
> > > - if (i == edid->extensions)
> > > + if (i >= edid->extensions)
> > > return NULL;
> > >
> > > + *ext_index = i + 1;
> > > +
> > > return edid_ext;
> > > }
> > >
> >
> > I would add something like drm_find_edid_n_extension() with the
> > implementation above and then implement drm_find_edid_extension() calling
> > drm_find_edid_n_extension() but it is just one caller that is not using
> > ext_index so LGTM.
> >
> > >
> > > static u8 *drm_find_displayid_extension(const struct edid *edid,
> > > - int *length, int *idx)
> > > + int *length, int *idx,
> > > + int *ext_index)
> > > {
> > > - u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT);
> > > + u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
> > > struct displayid_hdr *base;
> > > int ret;
> > >
> > > @@ -3241,14 +3245,18 @@ static u8 *drm_find_cea_extension(const struct
> > > edid *edid)
> > > struct displayid_block *block;
> > > u8 *cea;
> > > u8 *displayid;
> > > + int ext_index;
> > >
> > > /* Look for a top level CEA extension block */
> > > - cea = drm_find_edid_extension(edid, CEA_EXT);
> > > + ext_index = 0;
> >
> > In 2 places ext_index is initialized in the variable declaration and in 2
> > other places is not, all of it could be done in the declaration
>
> No, in this case we need to reset it back to 0 when the start looking
> for the DispID ext block (as opposed to the CEA ext block). So I figured
> it's cleaner if both initialize it to 0 the same way. All the other
> places need just the one initialization.
>
> Eventually I think I'd like some kind of for_each_ext_block() to make
> this stuff less crap...
Okay makes sense.
Reviewed-by: José Roberto de Souza
>
> > or if you
> > really want to leave the context close to the users, initialize it in the
> > "for (;;)" in the next patch.
> >
> > With the change above:
> >
> > Reviewed-by: José Roberto de Souza
> >
> > > + cea = drm_find_edid_extension(edid, CEA_EXT, _index);
> > > if (cea)
> > > return cea;
> > >
> > > /* CEA blocks can also be found embedded in a DisplayID block */
> > > - displayid = drm_find_displayid_extension(edid, , );
> > > + ext_index = 0;
> > > + displayid = drm_find_displayid_extension(edid, , ,
> > > + _index);
> > > if (!displayid)
> > > return NULL;
> > >
> > > @@ -5195,8 +5203,10 @@ static int add_displayid_detailed_modes(struct
> > > drm_connector *connector,
> > > int length, idx;
> > > struct displayid_block *block;
> > > int num_modes = 0;
> > > + int ext_index = 0;
> > >
> > > - displayid = drm_find_displayid_extension(edid, , );
> > > + displayid = drm_find_displayid_extension(edid, , ,
> > > + _index);
> > > if (!displayid)
> > > return 0;
> > >
> > > @@ -5870,11 +5880,13 @@ void drm_update_tile_info(struct drm_connector
> > > *connector,
> > > const struct edid *edid)
> > >
Re: [Intel-gfx] [PATCH 01/23] drm/i915: Drop vm.ref for duplicate vma on construction
Quoting Andi Shyti (2020-07-02 21:25:45)
> Hi Chris,
>
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> > b/drivers/gpu/drm/i915/i915_vma.c
> > index 1f63c4a1f055..7fe1f317cd2b 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -198,6 +198,7 @@ vma_create(struct drm_i915_gem_object *obj,
> > cmp = i915_vma_compare(pos, vm, view);
> > if (cmp == 0) {
> > spin_unlock(>vma.lock);
> > + i915_vm_put(vm);
> > i915_vma_free(vma);
>
> You are forgettin one return without dereferencing it.
>
> would this be a solution:
>
> @@ -106,6 +106,7 @@ vma_create(struct drm_i915_gem_object *obj,
> {
> struct i915_vma *vma;
> struct rb_node *rb, **p;
> + struct i915_vma *pos = ERR_PTR(-E2BIG);
>
> /* The aliasing_ppgtt should never be used directly! */
> GEM_BUG_ON(vm == >gt->ggtt->alias->vm);
> @@ -185,7 +186,6 @@ vma_create(struct drm_i915_gem_object *obj,
> rb = NULL;
> p = >vma.tree.rb_node;
> while (*p) {
> - struct i915_vma *pos;
> long cmp;
>
> rb = *p;
> @@ -197,12 +197,8 @@ vma_create(struct drm_i915_gem_object *obj,
> * and dispose of ours.
> */
> cmp = i915_vma_compare(pos, vm, view);
> - if (cmp == 0) {
> - spin_unlock(>vma.lock);
> - i915_vm_put(vm);
> - i915_vma_free(vma);
> - return pos;
> - }
> + if (!cmp)
> + goto err_unlock;
Yeah, but you might as well do
if (cmp < 0)
p = right;
else if (cmp > 0)
p = left;
else
goto err_unlock;
> if (cmp < 0)
> p = >rb_right;
> @@ -230,8 +226,9 @@ vma_create(struct drm_i915_gem_object *obj,
> err_unlock:
> spin_unlock(>vma.lock);
> err_vma:
> + i915_vm_put(vm);
> i915_vma_free(vma);
> - return ERR_PTR(-E2BIG);
> + return pos;
> }
>
> Andi
Ta, going to send that as a patch?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: do not read swizzle info if unavailable
Quoting Lucas De Marchi (2020-07-02 21:07:14) > Since gen8 we don't use swizzle anymore. Don't dump registers related to > it: registers may or may not be there. > > v2: pull the rest of driver state reporting before the read out (Chris) > > Cc: Matt Roper > Signed-off-by: Lucas De Marchi 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 v2] drm/i915: do not read swizzle info if unavailable
Since gen8 we don't use swizzle anymore. Don't dump registers related to
it: registers may or may not be there.
v2: pull the rest of driver state reporting before the read out (Chris)
Cc: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9ca94a435b75..94ed442910d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1138,13 +1138,20 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
struct intel_uncore *uncore = _priv->uncore;
intel_wakeref_t wakeref;
- wakeref = intel_runtime_pm_get(_priv->runtime_pm);
-
seq_printf(m, "bit6 swizzle for X-tiling = %s\n",
swizzle_string(dev_priv->ggtt.bit_6_swizzle_x));
seq_printf(m, "bit6 swizzle for Y-tiling = %s\n",
swizzle_string(dev_priv->ggtt.bit_6_swizzle_y));
+ if (dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES)
+ seq_puts(m, "L-shaped memory detected\n");
+
+ /* On BDW+, swizzling is not used. See detect_bit_6_swizzle() */
+ if (INTEL_GEN(dev_priv) >= 8 || IS_VALLEYVIEW(dev_priv))
+ return 0;
+
+ wakeref = intel_runtime_pm_get(_priv->runtime_pm);
+
if (IS_GEN_RANGE(dev_priv, 3, 4)) {
seq_printf(m, "DDC = 0x%08x\n",
intel_uncore_read(uncore, DCC));
@@ -1173,9 +1180,6 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
intel_uncore_read(uncore, DISP_ARB_CTL));
}
- if (dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES)
- seq_puts(m, "L-shaped memory detected\n");
-
intel_runtime_pm_put(_priv->runtime_pm, wakeref);
return 0;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms that support them
== Series Details ==
Series: series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms
that support them
URL : https://patchwork.freedesktop.org/series/79060/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8698 -> Patchwork_18072
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/index.html
Known issues
Here are the changes found in Patchwork_18072 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][5] ([i915#95]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][13] ([i915#62]) -> [SKIP][14]
([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_flip@basic-plain-flip@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8698/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18072/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8698 -> Patchwork_18072
CI-20190529: 20190529
CI_DRM_8698: a5bde2bddb64dc774e9fc1444243b8f224a31df6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5720: f35053d4b6d7bbcf6505ef67a8bd56acc7fb2eb2 @
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
== Series Details == Series: series starting with [v2,1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes URL : https://patchwork.freedesktop.org/series/79046/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8696_full -> Patchwork_18068_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18068_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18068_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_18068_full: ### IGT changes ### Possible regressions * igt@kms_fbcon_fbt@fbc-suspend: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-iclb1/igt@kms_fbcon_...@fbc-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-iclb2/igt@kms_fbcon_...@fbc-suspend.html Known issues Here are the changes found in Patchwork_18068_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / [i915#95]) +21 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-apl2/igt@gem_exec_reloc@basic-many-act...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-apl3/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_reloc@basic-many-active@vecs0: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-kbl6/igt@gem_exec_reloc@basic-many-act...@vecs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-kbl6/igt@gem_exec_reloc@basic-many-act...@vecs0.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-tglb2/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-tglb1/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@i2c: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-skl10/igt@i915_pm_...@i2c.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-skl1/igt@i915_pm_...@i2c.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-apl6/igt@kms_big...@y-tiled-64bpp-rotate-180.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-apl2/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-a-gamma: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#1149]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-tglb1/igt@kms_co...@pipe-a-gamma.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-tglb8/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-skl: [PASS][15] -> [FAIL][16] ([IGT#5]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-skl8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-kbl4/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-kbl1/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#46]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +5 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/shard-kbl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [22]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms that support them
== Series Details == Series: series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms that support them URL : https://patchwork.freedesktop.org/series/79060/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix the training pattern debug print
On Thu, Jul 02, 2020 at 09:24:50PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we claim to use TPS7 when using TPS4. That is just
> confusing, so let's fix the debug print.
>
> And while we're touching this let's add the customary
> encoder id/name as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 26 -
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5ac182357fc9..eba97b1f5839 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4353,17 +4353,33 @@ void intel_dp_set_signal_levels(struct intel_dp
> *intel_dp)
> intel_dp->set_signal_levels(intel_dp);
> }
>
> +static char dp_training_pattern_name(u8 train_pat)
> +{
> + switch (train_pat) {
> + case DP_TRAINING_PATTERN_1:
> + case DP_TRAINING_PATTERN_2:
> + case DP_TRAINING_PATTERN_3:
> + return '0' + train_pat;
> + case DP_TRAINING_PATTERN_4:
> + return '4';
> + default:
> + return '?';
Shouldnt this be a WARN? If we just return a ? it might result into failure
without any warn
Other than that I like that now it will say TPS4 instead of misleading TPS7
So with a default WARN,
Reviewed-by: Manasi Navare
Manasi
> + }
> +}
> +
> void
> intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
> u8 dp_train_pat)
> {
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + u8 train_pat = dp_train_pat &
> drm_dp_training_pattern_mask(intel_dp->dpcd);
>
> - if (dp_train_pat & train_pat_mask)
> + if (train_pat)
> drm_dbg_kms(_priv->drm,
> - "Using DP training pattern TPS%d\n",
> - dp_train_pat & train_pat_mask);
> + "[ENCODER:%d:%s] Using DP training pattern TPS%c\n",
> + encoder->base.base.id, encoder->base.name,
> + dp_training_pattern_name(train_pat));
>
> intel_dp->set_link_train(intel_dp, dp_train_pat);
> }
> --
> 2.26.2
>
> ___
> 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] [PULL] drm-intel-next
Hi Dave & Daniel - Here's the first batch of i915 features for v5.9. BR, Jani. drm-intel-next-2020-07-02: drm/i915 features for v5.9 Highlights: - Rocket Lake (RKL) platform enabling (Matt Roper, Lucas, José, Aditya) Gem/GT: - Numerous selftest fixes and improvements (Chris) - TGL, RKL, EHL workaround updates (Matts Atwood and Roper, Clint, Swathi Dhanavanthri, Chris) - Retry faulthandlers on ENOSPC to avoid oomkiller (Chris) - Numerous refactorings and cleanups (Chris) - Several GT fixes around init/suspend/resume/shutdown (Chris) - Whitelist CTX_TIMESTAMP register on non-RCS (Chris) - Track if an engine requires forcewake w/a (Chris) - Locking improvements (Chris) - Timeslicing improvements (Chris) - Add a safety submission flush in the heartbeat (Chris) - Flush gen3 relocs harder (Chris) - Discard a misplaced GGTT vma (Chris) - Reduce relocation paths to async GPU relocations only (Chris) - It's all build up with no pay off (Chris' own words...) Display: - A plethora of DP MST fixes (Imre) - Implement proper dbuf global state (Ville) - Consider dbuf bandwidth when calculating CDCLK (Stan) - FBC fixes and refactoring (Ville) - PSR fixes and improvements (José, Gwan-gyeong) - Cursor size fixes (Ville) - Overlay color and gamma fixes (Ville) - Fix and improve FSB and HRAWCLK read out (Ville) - Pre allocate and late cleanup of DSB cmd buffer (Animesh) - Stop using mode->private_flags (Ville) - Add plane color encoding support for YCBCR_BT2020 (Kishore Kadiyala) - Update TGL Type-C DP and DKL HBR and HBR+ vswing tables (José) - Fix DSI connector init error path (Vivek) - A plethora of DP vswing/preemph fixes and refactoring (Ville) - Fix TGL DKL vswing sequence selection (Vandita) - Fix ICL hotplug interrupt disabling after storm detection (Imre) - Retry HDCP link integrity check on failure (Oliver Barta) - Fix TBT DPLL fractional divider (Imre) - Fix ICL+ HBR3 source rate (Matt Atwood) - Fix gen2 spurious underruns (Ville) - Fix potential NULL dereference, some spelling fixes (Colin Ian King) - Fix NULL dereference on encoder state probe (Chris) Other: - Backmerge to get mmap locking API (Jani) - Distinguish Comet Lake from Coffee Lake (Chris) - Various compiler warning fixes (Arnd Bergmann, Nathan Chancellor) - WARN* conversions to drm_WARN* (Pankaj) - Switch to device specific parameters with debugfs access (Jani) - Fix agp/intel error path leak (Qiushi Wu) - Forcewake power optimization (Chris) - Irq handler optimization (Chris) BR, Jani. The following changes since commit 0a19b068acc47d05212f03e494381926dc0381e2: Merge tag 'drm-misc-next-2020-06-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-06-24 15:45:51 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-07-02 for you to fetch changes up to d524b87f77364db096855d7eb714ffacec974ddf: drm/i915: Update DRIVER_DATE to 20200702 (2020-07-02 21:25:28 +0300) drm/i915 features for v5.9 Highlights: - Rocket Lake (RKL) platform enabling (Matt Roper, Lucas, José, Aditya) Gem/GT: - Numerous selftest fixes and improvements (Chris) - TGL, RKL, EHL workaround updates (Matts Atwood and Roper, Clint, Swathi Dhanavanthri, Chris) - Retry faulthandlers on ENOSPC to avoid oomkiller (Chris) - Numerous refactorings and cleanups (Chris) - Several GT fixes around init/suspend/resume/shutdown (Chris) - Whitelist CTX_TIMESTAMP register on non-RCS (Chris) - Track if an engine requires forcewake w/a (Chris) - Locking improvements (Chris) - Timeslicing improvements (Chris) - Add a safety submission flush in the heartbeat (Chris) - Flush gen3 relocs harder (Chris) - Discard a misplaced GGTT vma (Chris) - Reduce relocation paths to async GPU relocations only (Chris) - It's all build up with no pay off (Chris' own words...) Display: - A plethora of DP MST fixes (Imre) - Implement proper dbuf global state (Ville) - Consider dbuf bandwidth when calculating CDCLK (Stan) - FBC fixes and refactoring (Ville) - PSR fixes and improvements (José, Gwan-gyeong) - Cursor size fixes (Ville) - Overlay color and gamma fixes (Ville) - Fix and improve FSB and HRAWCLK read out (Ville) - Pre allocate and late cleanup of DSB cmd buffer (Animesh) - Stop using mode->private_flags (Ville) - Add plane color encoding support for YCBCR_BT2020 (Kishore Kadiyala) - Update TGL Type-C DP and DKL HBR and HBR+ vswing tables (José) - Fix DSI connector init error path (Vivek) - A plethora of DP vswing/preemph fixes and refactoring (Ville) - Fix TGL DKL vswing sequence selection (Vandita) - Fix ICL hotplug interrupt disabling after storm detection (Imre) - Retry HDCP link integrity check on failure (Oliver Barta) - Fix TBT DPLL fractional divider (Imre) - Fix ICL+ HBR3 source rate (Matt Atwood) - Fix gen2 spurious underruns (Ville) - Fix potential NULL dereference, some spelling fixes (Colin Ian King) - Fix NULL dereference
[Intel-gfx] [PATCH 2/2] drm/i915: Fix the training pattern debug print
From: Ville Syrjälä
Currently we claim to use TPS7 when using TPS4. That is just
confusing, so let's fix the debug print.
And while we're touching this let's add the customary
encoder id/name as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 26 -
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5ac182357fc9..eba97b1f5839 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4353,17 +4353,33 @@ void intel_dp_set_signal_levels(struct intel_dp
*intel_dp)
intel_dp->set_signal_levels(intel_dp);
}
+static char dp_training_pattern_name(u8 train_pat)
+{
+ switch (train_pat) {
+ case DP_TRAINING_PATTERN_1:
+ case DP_TRAINING_PATTERN_2:
+ case DP_TRAINING_PATTERN_3:
+ return '0' + train_pat;
+ case DP_TRAINING_PATTERN_4:
+ return '4';
+ default:
+ return '?';
+ }
+}
+
void
intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
u8 dp_train_pat)
{
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ u8 train_pat = dp_train_pat &
drm_dp_training_pattern_mask(intel_dp->dpcd);
- if (dp_train_pat & train_pat_mask)
+ if (train_pat)
drm_dbg_kms(_priv->drm,
- "Using DP training pattern TPS%d\n",
- dp_train_pat & train_pat_mask);
+ "[ENCODER:%d:%s] Using DP training pattern TPS%c\n",
+ encoder->base.base.id, encoder->base.name,
+ dp_training_pattern_name(train_pat));
intel_dp->set_link_train(intel_dp, dp_train_pat);
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Enable TPS3/4 on all platforms that support them
From: Ville Syrjälä
Stop using HBR2/3 support as a proxy for TPS3/4 support.
The two are no longer 1:1 in the hardware, arguably they
never were due to HSW ULX which does support TPS3 while
being limited to HBR1.
In more recent times GLK gained support for TPS4 while
being limited to HBR2. And on CNL+ some ports support
HBR3 while others are limited to HBR2, but all ports
support TPS4.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 +++-
drivers/gpu/drm/i915/display/intel_dp.h | 4 +--
.../drm/i915/display/intel_dp_link_training.c | 29 +++
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
4 files changed, 17 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c9b93c5706af..5ac182357fc9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1799,18 +1799,14 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
intel_dp->aux.transfer = intel_dp_aux_transfer;
}
-bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
+bool intel_dp_source_supports_tps3(struct drm_i915_private *i915)
{
- int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
-
- return max_rate >= 54;
+ return INTEL_GEN(i915) >= 9 || IS_BROADWELL(i915) || IS_HASWELL(i915);
}
-bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp)
+bool intel_dp_source_supports_tps4(struct drm_i915_private *i915)
{
- int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
-
- return max_rate >= 81;
+ return INTEL_GEN(i915) >= 10 || IS_GEMINILAKE(i915);
}
static void
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 0a8950f744f6..d597a9848397 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -94,8 +94,8 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp);
void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
u8 *link_bw, u8 *rate_select);
-bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
-bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
+bool intel_dp_source_supports_tps3(struct drm_i915_private *i915);
+bool intel_dp_source_supports_tps4(struct drm_i915_private *i915);
bool
intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 2493142a70e9..57c2089c9f5a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -259,41 +259,32 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
*/
static u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
bool source_tps3, sink_tps3, source_tps4, sink_tps4;
- /*
-* Intel platforms that support HBR3 also support TPS4. It is mandatory
-* for all downstream devices that support HBR3. There are no known eDP
-* panels that support TPS4 as of Feb 2018 as per VESA eDP_v1.4b_E1
-* specification.
-*/
- source_tps4 = intel_dp_source_supports_hbr3(intel_dp);
+ source_tps4 = intel_dp_source_supports_tps4(i915);
sink_tps4 = drm_dp_tps4_supported(intel_dp->dpcd);
if (source_tps4 && sink_tps4) {
return DP_TRAINING_PATTERN_4;
} else if (intel_dp->link_rate == 81) {
if (!source_tps4)
- drm_dbg_kms(_to_i915(intel_dp)->drm,
- "8.1 Gbps link rate without source
HBR3/TPS4 support\n");
+ drm_dbg_kms(>drm,
+ "8.1 Gbps link rate without source TPS4
support\n");
if (!sink_tps4)
- drm_dbg_kms(_to_i915(intel_dp)->drm,
+ drm_dbg_kms(>drm,
"8.1 Gbps link rate without sink TPS4
support\n");
}
- /*
-* Intel platforms that support HBR2 also support TPS3. TPS3 support is
-* also mandatory for downstream devices that support HBR2. However, not
-* all sinks follow the spec.
-*/
- source_tps3 = intel_dp_source_supports_hbr2(intel_dp);
+
+ source_tps3 = intel_dp_source_supports_tps3(i915);
sink_tps3 = drm_dp_tps3_supported(intel_dp->dpcd);
if (source_tps3 && sink_tps3) {
return DP_TRAINING_PATTERN_3;
} else if (intel_dp->link_rate >= 54) {
if (!source_tps3)
- drm_dbg_kms(_to_i915(intel_dp)->drm,
- ">=5.4/6.48
Re: [Intel-gfx] [PATCH 2/8] drm/amdgpu: Use __drm_atomic_helper_crtc_reset
On Fri, Jun 12, 2020 at 01:41:17PM -0400, Alex Deucher wrote: > On Fri, Jun 12, 2020 at 1:24 PM Harry Wentland wrote: > > > > On 2020-06-12 12:00 p.m., Daniel Vetter wrote: > > > Now also comes with the added benefit of doing a drm_crtc_vblank_off(), > > > which means vblank state isn't ill-defined and fail-y at driver load > > > before the first modeset on each crtc. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Alex Deucher > > > Cc: Nicholas Kazlauskas > > > Cc: Harry Wentland > > > Cc: Rodrigo Siqueira > > > Cc: Bhawanpreet Lakha > > > Cc: Roman Li > > > Cc: Mikita Lipski > > > Cc: Stylon Wang > > > > Reviewed-by: Harry Wentland > > > > Daniel, do you want to take the whole series, or should I pull this in > through my tree? Either way works for me. Thanks for the patch! Merged the entire series through drm-misc-next now. -Daniel > > Alex > > > Harry > > > > > --- > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > index 68a73065b516..36d605a6eb16 100644 > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > @@ -4594,9 +4594,7 @@ static void dm_crtc_reset_state(struct drm_crtc > > > *crtc) > > > if (WARN_ON(!state)) > > > return; > > > > > > - crtc->state = >base; > > > - crtc->state->crtc = crtc; > > > - > > > + __drm_atomic_helper_crtc_reset(crtc, >base); > > > } > > > > > > static struct drm_crtc_state * > > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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] [PATCH i-g-t] i915/perf: Instantiate a local drm_fd for the unprivileged helper
While the test is blocked, we keep trying the gen12_single_ctx_helper().
As this is using the parent's drm_fd, all of our context allocations are
persistent. Reopen the device in the child so that when we exit, our
allocations are freed along with the process -- avoiding a total memory
leak if the test is stuck.
This does not explain why the test was stuck, it just prevents us from
exacerbating the error condition. Hopefully leaving the system in a more
debuggable state.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2126
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Reviewed-by: Lionel Landwerlin
---
tests/i915/perf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/i915/perf.c b/tests/i915/perf.c
index d4ebae30d..92edc9f1f 100644
--- a/tests/i915/perf.c
+++ b/tests/i915/perf.c
@@ -4120,8 +4120,13 @@
gen12_test_single_ctx_render_target_writes_a_counter(void)
do {
igt_fork_helper() {
+ /* A local device for local resources. */
+ drm_fd = gem_reopen_driver(drm_fd);
+
igt_drop_root();
gen12_single_ctx_helper();
+
+ close(drm_fd);
}
child_ret = igt_wait_helper();
igt_assert(WEXITSTATUS(child_ret) == EAGAIN ||
--
2.27.0
___
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/gem: Only revoke the GGTT mmappings on aperture detiling changes
== Series Details == Series: series starting with [CI,1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes URL : https://patchwork.freedesktop.org/series/79053/ State : success == Summary == CI Bug Log - changes from CI_DRM_8697 -> Patchwork_18071 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/index.html Known issues Here are the changes found in Patchwork_18071 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-glk-dsi/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html Possible fixes * igt@i915_selftest@live@execlists: - fi-kbl-guc: [INCOMPLETE][7] ([i915#794]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-guc/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-kbl-guc/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_pm: - fi-icl-y: [DMESG-FAIL][9] ([i915#2111]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-icl-y/igt@i915_selftest@live@gt_pm.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-icl-y/igt@i915_selftest@live@gt_pm.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-u2: [DMESG-WARN][15] -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-tgl-u2/igt@prime_self_import@basic-with_two_bos.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-tgl-u2/igt@prime_self_import@basic-with_two_bos.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][17] ([i915#62]) -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18071/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2111]: https://gitlab.freedesktop.org/drm/intel/issues/2111 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#794]:
[Intel-gfx] [CI 2/2] drm/i915/gem: Only revoke mmap handlers if active
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdown.
v2: Pull the release_mmap() into its single user in freeing the objects,
where there can not be any race with a concurrent user of the freed
object. Or so one hopes!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin ,
Reviewed-by: Tvrtko Ursulin ,
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 13
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 --
drivers/gpu/drm/i915/gem/i915_gem_object.c | 37 ++
3 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 7c2650cfb070..b23368529a40 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -507,19 +507,6 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_unlock(>mmo.lock);
}
-/**
- * i915_gem_object_release_mmap - remove physical page mappings
- * @obj: obj in question
- *
- * Preserve the reservation of the mmapping with the DRM core code, but
- * relinquish ownership of the pages back to the system.
- */
-void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
-{
- i915_gem_object_release_mmap_gtt(obj);
- i915_gem_object_release_mmap_offset(obj);
-}
-
static struct i915_mmap_offset *
lookup_mmo(struct drm_i915_gem_object *obj,
enum i915_mmap_type mmap_type)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 7c5ccdf59359..efee9e0d2508 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -24,8 +24,6 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
struct drm_device *dev,
u32 handle, u64 *offset);
-void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
-
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6b69191c5543..eb35bdd10c09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -171,14 +171,35 @@ static void __i915_gem_free_object_rcu(struct rcu_head
*head)
atomic_dec(>mm.free_count);
}
+static void __i915_gem_object_free_mmaps(struct drm_i915_gem_object *obj)
+{
+ /* Skip serialisation and waking the device if known to be not used. */
+
+ if (obj->userfault_count)
+ i915_gem_object_release_mmap_gtt(obj);
+
+ if (!RB_EMPTY_ROOT(>mmo.offsets)) {
+ struct i915_mmap_offset *mmo, *mn;
+
+ i915_gem_object_release_mmap_offset(obj);
+
+ rbtree_postorder_for_each_entry_safe(mmo, mn,
+>mmo.offsets,
+offset) {
+ drm_vma_offset_remove(obj->base.dev->vma_offset_manager,
+ >vma_node);
+ kfree(mmo);
+ }
+ obj->mmo.offsets = RB_ROOT;
+ }
+}
+
static void __i915_gem_free_objects(struct drm_i915_private *i915,
struct llist_node *freed)
{
struct drm_i915_gem_object *obj, *on;
llist_for_each_entry_safe(obj, on, freed, freed) {
- struct i915_mmap_offset *mmo, *mn;
-
trace_i915_gem_object_destroy(obj);
if (!list_empty(>vma.list)) {
@@ -204,18 +225,8 @@ static void __i915_gem_free_objects(struct
drm_i915_private *i915,
spin_unlock(>vma.lock);
}
- i915_gem_object_release_mmap(obj);
-
- rbtree_postorder_for_each_entry_safe(mmo, mn,
->mmo.offsets,
-offset) {
- drm_vma_offset_remove(obj->base.dev->vma_offset_manager,
- >vma_node);
- kfree(mmo);
- }
- obj->mmo.offsets = RB_ROOT;
+ __i915_gem_object_free_mmaps(obj);
- GEM_BUG_ON(obj->userfault_count);
GEM_BUG_ON(!list_empty(>lut_list));
atomic_set(>mm.pages_pin_count, 0);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
Only a GGTT mmapping will use the aperture detiling registers, so on a
tiling change for an object, we only need to revoke those mmappings and
not the CPU mmappings (which are always linear irrespective of the tiling).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fe27c5b344e3..7c2650cfb070 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -448,7 +448,7 @@ void __i915_gem_object_release_mmap_gtt(struct
drm_i915_gem_object *obj)
* mapping will then trigger a page fault on the next user access, allowing
* fixup by vm_fault_gtt().
*/
-static void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
+void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
intel_wakeref_t wakeref;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 862e01b7cb69..7c5ccdf59359 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -24,8 +24,11 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
struct drm_device *dev,
u32 handle, u64 *offset);
-void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
+
+void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
#endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index 0158e49bf9bb..ff72ee2fd9cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -299,7 +299,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
i915_gem_object_unlock(obj);
/* Force the fence to be reacquired for GTT access */
- i915_gem_object_release_mmap(obj);
+ i915_gem_object_release_mmap_gtt(obj);
/* Try to preallocate memory required to save swizzling on put-pages */
if (i915_gem_object_needs_bit17_swizzle(obj)) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: FBC fixes (rev3)
== Series Details ==
Series: drm/i915: FBC fixes (rev3)
URL : https://patchwork.freedesktop.org/series/76714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8697 -> Patchwork_18070
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/index.html
Known issues
Here are the changes found in Patchwork_18070 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-bsw-kefka/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-bsw-kefka/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][3] ([i915#95]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-kbl-guc: [INCOMPLETE][7] ([i915#794]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-guc/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-kbl-guc/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-icl-y: [DMESG-FAIL][9] ([i915#2111]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-icl-y/igt@i915_selftest@live@gt_pm.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-icl-y/igt@i915_selftest@live@gt_pm.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-u2: [DMESG-WARN][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-tgl-u2/igt@prime_self_import@basic-with_two_bos.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-tgl-u2/igt@prime_self_import@basic-with_two_bos.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62]) -> [SKIP][16]
([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8697/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18070/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2111]: https://gitlab.freedesktop.org/drm/intel/issues/2111
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#794]: https://gitlab.freedesktop.org/drm/intel/issues/794
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 37)
--
Missing
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/79042/ State : success == Summary == CI Bug Log - changes from CI_DRM_8693_full -> Patchwork_18067_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18067_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@engines@fds: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-glk7/igt@gem_exec_parallel@engi...@fds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-glk7/igt@gem_exec_parallel@engi...@fds.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#1930]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_reloc@basic-many-active@vecs0: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-kbl4/igt@gem_exec_reloc@basic-many-act...@vecs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-kbl7/igt@gem_exec_reloc@basic-many-act...@vecs0.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#1515]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-iclb5/igt@i915_pm_rc6_reside...@rc6-idle.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-iclb7/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-apl7/igt@kms_big...@y-tiled-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-apl7/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_ccs@pipe-a-bad-pixel-format: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +24 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-apl7/igt@kms_...@pipe-a-bad-pixel-format.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-apl7/igt@kms_...@pipe-a-bad-pixel-format.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +10 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl10/igt@kms_co...@pipe-c-ctm-0-25.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-skl3/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-128x128-offscreen.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-128x128-offscreen.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#300]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][21] -> [FAIL][22] ([IGT#5]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-wf_vblank-interruptible@a-dp1: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-kbl4/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-dp1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/shard-kbl7/igt@kms_flip@flip-vs-wf_vblank-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-wf_vblank-interruptible@a-edp1:
Re: [Intel-gfx] [PATCH 04/33] drm/i915/gt: Check for a completed last request once
Quoting Mika Kuoppala (2020-07-02 16:46:22)
> Chris Wilson writes:
>
> > Pull the repeated check for the last active request being completed to a
> > single spot, when deciding whether or not execlist preemption is
> > required.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
> > 1 file changed, 4 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 4eb397b0e14d..7bdbfac26d7b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -2137,12 +2137,11 @@ static void execlists_dequeue(struct
> > intel_engine_cs *engine)
> >*/
> >
> > if ((last = *active)) {
> > - if (need_preempt(engine, last, rb)) {
> > - if (i915_request_completed(last)) {
> > - tasklet_hi_schedule(>tasklet);
> > - return;
> > - }
> > + if (i915_request_completed(last) &&
> > + !list_is_last(>sched.link,
> > >active.requests))
>
> You return if it is not last? Also the hi schedule is gone.
The kick was just causing us to busyspin ahead of the HW CS event. On
tracing, it did not seem worth it.
If this is the last request, the GPU is now idling and we know that we
will not try and lite restore into that request/context. So instead of
waiting for the CS event, we go ahead and prepare the next pair of
contexts.
If it was not the last request, we know there is a context the GPU will
switch into, so the urgency is not an issue. However, we have to be
careful that we don't issue an ELSP into that second context in case we
catch it as it idles (thus hanging the HW).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: Only revoke mmap handlers if active
On 02/07/2020 14:06, Chris Wilson wrote:
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdown.
v2: Pull the release_mmap() into its single user in freeing the objects,
where there can not be any race with a concurrent user of the freed
object. Or so one hopes!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin ,
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 13 -
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 --
drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +++
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 7c2650cfb070..b23368529a40 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -507,19 +507,6 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_unlock(>mmo.lock);
}
-/**
- * i915_gem_object_release_mmap - remove physical page mappings
- * @obj: obj in question
- *
- * Preserve the reservation of the mmapping with the DRM core code, but
- * relinquish ownership of the pages back to the system.
- */
-void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
-{
- i915_gem_object_release_mmap_gtt(obj);
- i915_gem_object_release_mmap_offset(obj);
-}
-
static struct i915_mmap_offset *
lookup_mmo(struct drm_i915_gem_object *obj,
enum i915_mmap_type mmap_type)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 7c5ccdf59359..efee9e0d2508 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -24,8 +24,6 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
struct drm_device *dev,
u32 handle, u64 *offset);
-void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
-
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6b69191c5543..d377c0ef8603 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -171,6 +171,17 @@ static void __i915_gem_free_object_rcu(struct rcu_head
*head)
atomic_dec(>mm.free_count);
}
+static void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
Yes you can give it a more internal name for a good measure.
+{
+ /* Skip serialisation and waking the device if known to be not used. */
+
+ if (obj->userfault_count)
+ i915_gem_object_release_mmap_gtt(obj);
+
+ if (!RB_EMPTY_ROOT(>mmo.offsets))
+ i915_gem_object_release_mmap_offset(obj);
+}
+
static void __i915_gem_free_objects(struct drm_i915_private *i915,
struct llist_node *freed)
{
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
On 02/07/2020 14:06, Chris Wilson wrote:
Only a GGTT mmaping will use the aperture detiling registers, so only a
tiling change for an object, we only need to revoke those mmapings and
not the CPU mmapings (which are always linear irrespective of the tiling).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fe27c5b344e3..7c2650cfb070 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -448,7 +448,7 @@ void __i915_gem_object_release_mmap_gtt(struct
drm_i915_gem_object *obj)
* mapping will then trigger a page fault on the next user access, allowing
* fixup by vm_fault_gtt().
*/
-static void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
+void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
intel_wakeref_t wakeref;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 862e01b7cb69..7c5ccdf59359 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -24,8 +24,11 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
struct drm_device *dev,
u32 handle, u64 *offset);
-void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
+
+void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
#endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index 0158e49bf9bb..ff72ee2fd9cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -299,7 +299,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
i915_gem_object_unlock(obj);
/* Force the fence to be reacquired for GTT access */
- i915_gem_object_release_mmap(obj);
+ i915_gem_object_release_mmap_gtt(obj);
/* Try to preallocate memory required to save swizzling on put-pages */
if (i915_gem_object_needs_bit17_swizzle(obj)) {
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/33] drm/i915/gt: Check for a completed last request once
Chris Wilson writes:
> Pull the repeated check for the last active request being completed to a
> single spot, when deciding whether or not execlist preemption is
> required.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 4eb397b0e14d..7bdbfac26d7b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2137,12 +2137,11 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
>*/
>
> if ((last = *active)) {
> - if (need_preempt(engine, last, rb)) {
> - if (i915_request_completed(last)) {
> - tasklet_hi_schedule(>tasklet);
> - return;
> - }
> + if (i915_request_completed(last) &&
> + !list_is_last(>sched.link, >active.requests))
You return if it is not last? Also the hi schedule is gone.
-Mika
> + return;
>
> + if (need_preempt(engine, last, rb)) {
> ENGINE_TRACE(engine,
>"preempting last=%llx:%lld, prio=%d,
> hint=%d\n",
>last->fence.context,
> @@ -2170,11 +2169,6 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> last = NULL;
> } else if (need_timeslice(engine, last, rb) &&
> timeslice_expired(execlists, last)) {
> - if (i915_request_completed(last)) {
> - tasklet_hi_schedule(>tasklet);
> - return;
> - }
> -
> ENGINE_TRACE(engine,
>"expired last=%llx:%lld, prio=%d, hint=%d,
> yield?=%s\n",
>last->fence.context,
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/fbc: Enable fbc on i865
From: Ville Syrjälä
Unlike all the other pre-snb desktop platforms i865 actually
supports FBC. Let's enable it.
Quote from the spec:
"DevSDG provides the same Run-Length Encoded Frame Buffer
Compression (RLEFBC) function as exists in DevMGM."
As i865 only has the one pipe we want to skip massaging the
plane<->pipe assignment aimed at getting FBC+LVDS working on
the mobile platforms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
drivers/gpu/drm/i915/i915_pci.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 84e2a17b5ecb..653f6617d59a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16332,7 +16332,8 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
* On gen2/3 only plane A can do FBC, but the panel fitter and LVDS
* port is hooked to pipe B. Hence we want plane A feeding pipe B.
*/
- if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4)
+ if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4 &&
+ INTEL_NUM_PIPES(dev_priv) == 2)
plane->i9xx_plane = (enum i9xx_plane_id) !pipe;
else
plane->i9xx_plane = (enum i9xx_plane_id) pipe;
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index e5fdf17cd9cd..0be3b66ce666 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -217,6 +217,7 @@ static const struct intel_device_info i85x_info = {
static const struct intel_device_info i865g_info = {
I845_FEATURES,
PLATFORM(INTEL_I865G),
+ .display.has_fbc = 1,
};
#define GEN3_FEATURES \
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/fbc: Allow FBC to recompress after a 3D workload on i85x/i865
From: Ville Syrjälä Normally i85x/i865 3D activity will block FBC until a 2D blit occurs. I suppose this was meant to avoid recompression while 3D activity is still going on but the frame hasn't yet been presented. Unfortunately that also means that a page flipped 3D workload will permanently block FBC even if it only renders a single frame and then does nothing. Since we are using software render tracking anyway we might as well flip the chicken bit so that 3D does not block FBC. This will avoid the permament FBC blockage in the aforemention use case, but thanks to the software tracking the compressor will not disturb 3D rendering activity. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 10 ++ 2 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9d6536afc94b..03590d2d75f7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2827,6 +2827,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define VLV_GU_CTL0_MMIO(VLV_DISPLAY_BASE + 0x2030) #define VLV_GU_CTL1_MMIO(VLV_DISPLAY_BASE + 0x2034) #define SCPD0 _MMIO(0x209c) /* 915+ only */ +#define SCPD_FBC_IGNORE_3D(1 << 6) #define CSTATE_RENDER_CLOCK_GATE_DISABLE (1 << 5) #define GEN2_IER _MMIO(0x20a0) #define GEN2_IIR _MMIO(0x20a4) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 565a2b9da3b3..2d980b83a1f1 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7471,6 +7471,16 @@ static void i85x_init_clock_gating(struct drm_i915_private *dev_priv) I915_WRITE(MEM_MODE, _MASKED_BIT_ENABLE(MEM_DISPLAY_TRICKLE_FEED_DISABLE)); + + /* +* Have FBC ignore 3D activity since we use software +* render tracking, and otherwise a pure 3D workload +* (even if it just renders a single frame and then does +* abosultely nothing) would not allow FBC to recompress +* until a 2D blit occurs. +*/ + I915_WRITE(SCPD0, + _MASKED_BIT_ENABLE(SCPD_FBC_IGNORE_3D)); } static void i830_init_clock_gating(struct drm_i915_private *dev_priv) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm/i915: FBC fixes
From: Ville Syrjälä Leftovers from the earlier FBC series. Ville Syrjälä (4): drm/i915/fbc: Use the correct plane stride drm/i915/fbc: Fix nuke for pre-snb platforms drm/i915/fbc: Enable fbc on i865 drm/i915/fbc: Allow FBC to recompress after a 3D workload on i85x/i865 drivers/gpu/drm/i915/display/intel_display.c | 3 +- drivers/gpu/drm/i915/display/intel_fbc.c | 50 +--- drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 10 5 files changed, 57 insertions(+), 8 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/fbc: Use the correct plane stride
From: Ville Syrjälä
Consult the actual plane stride instead of the fb stride. The two
will disagree when we remap the gtt. The plane stride is what the
hw will be fed so that's what we should look at for the FBC
retrictions/cfb allocation.
Since we no longer require a fence we are going to attempt using
FBC with remapping, and so we should look at correct stride.
With 90/270 degree rotation the plane stride is stored in units
of pixels, so we need to conver it to bytes for the purposes
of calculating the cfb stride. Not entirely sure if this matches
the hw behaviour though. Need to reverse engineer that at some
point...
We also need to reorder the pixel format check vs. stride check
to avoid triggering a spurious WARN(stride & 63) with cpp==1 and
plane stride==32.
v2: Try to deal with rotated stride and related WARN
Cc: José Roberto de Souza
Fixes: 691f7ba58d52 ("drm/i915/display/fbc: Make fences a nice-to-have for
GEN9+")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 69a0682ddb6a..d30c2a389294 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -695,9 +695,13 @@ static void intel_fbc_update_state_cache(struct intel_crtc
*crtc,
cache->plane.pixel_blend_mode = plane_state->hw.pixel_blend_mode;
cache->fb.format = fb->format;
- cache->fb.stride = fb->pitches[0];
cache->fb.modifier = fb->modifier;
+ /* FIXME is this correct? */
+ cache->fb.stride = plane_state->color_plane[0].stride;
+ if (drm_rotation_90_or_270(plane_state->hw.rotation))
+ cache->fb.stride *= fb->format->cpp[0];
+
/* FBC1 compression interval: arbitrary choice of 1 second */
cache->interval = drm_mode_vrefresh(_state->hw.adjusted_mode);
@@ -797,6 +801,11 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
+ if (!pixel_format_is_valid(dev_priv, cache->fb.format->format)) {
+ fbc->no_fbc_reason = "pixel format is invalid";
+ return false;
+ }
+
if (!rotation_is_valid(dev_priv, cache->fb.format->format,
cache->plane.rotation)) {
fbc->no_fbc_reason = "rotation unsupported";
@@ -813,11 +822,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
- if (!pixel_format_is_valid(dev_priv, cache->fb.format->format)) {
- fbc->no_fbc_reason = "pixel format is invalid";
- return false;
- }
-
if (cache->plane.pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE &&
cache->fb.format->has_alpha) {
fbc->no_fbc_reason = "per-pixel alpha blending is incompatible
with FBC";
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/fbc: Fix nuke for pre-snb platforms
From: Ville Syrjälä
The MSG_FBC_REND_STATE register only exists on snb+. For older
platforms (would also work for snb+) we can simply rewite DSPSURF
to trigger a flip nuke.
While generally RMW is considered harmful we'll use it here for
simplicity. And since FBC doesn't exist in i830 we don't have to
worry about the DSPSURF double buffering hardware fails present
on that platform.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 34 +++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index d30c2a389294..036546ce8db8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -187,8 +187,30 @@ static bool g4x_fbc_is_active(struct drm_i915_private
*dev_priv)
return intel_de_read(dev_priv, DPFC_CONTROL) & DPFC_CTL_EN;
}
+static void i8xx_fbc_recompress(struct drm_i915_private *dev_priv)
+{
+ struct intel_fbc_reg_params *params = _priv->fbc.params;
+ enum i9xx_plane_id i9xx_plane = params->crtc.i9xx_plane;
+
+ spin_lock_irq(_priv->uncore.lock);
+ intel_de_write_fw(dev_priv, DSPADDR(i9xx_plane),
+ intel_de_read_fw(dev_priv, DSPADDR(i9xx_plane)));
+ spin_unlock_irq(_priv->uncore.lock);
+}
+
+static void i965_fbc_recompress(struct drm_i915_private *dev_priv)
+{
+ struct intel_fbc_reg_params *params = _priv->fbc.params;
+ enum i9xx_plane_id i9xx_plane = params->crtc.i9xx_plane;
+
+ spin_lock_irq(_priv->uncore.lock);
+ intel_de_write_fw(dev_priv, DSPSURF(i9xx_plane),
+ intel_de_read_fw(dev_priv, DSPSURF(i9xx_plane)));
+ spin_unlock_irq(_priv->uncore.lock);
+}
+
/* This function forces a CFB recompression through the nuke operation. */
-static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
+static void snb_fbc_recompress(struct drm_i915_private *dev_priv)
{
struct intel_fbc *fbc = _priv->fbc;
@@ -198,6 +220,16 @@ static void intel_fbc_recompress(struct drm_i915_private
*dev_priv)
intel_de_posting_read(dev_priv, MSG_FBC_REND_STATE);
}
+static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
+{
+ if (INTEL_GEN(dev_priv) >= 6)
+ snb_fbc_recompress(dev_priv);
+ else if (INTEL_GEN(dev_priv) >= 4)
+ i965_fbc_recompress(dev_priv);
+ else
+ i8xx_fbc_recompress(dev_priv);
+}
+
static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
{
struct intel_fbc_reg_params *params = _priv->fbc.params;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K (rev2)
== Series Details == Series: drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K (rev2) URL : https://patchwork.freedesktop.org/series/78940/ State : success == Summary == CI Bug Log - changes from CI_DRM_8693_full -> Patchwork_18066_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18066_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-tglb5/igt@drm_import_exp...@prime.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-tglb8/igt@drm_import_exp...@prime.html * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#198]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl4/igt@gem_ctx_isolation@preservation...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-skl1/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#1930]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_reloc@basic-many-active@vecs0: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-kbl4/igt@gem_exec_reloc@basic-many-act...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-kbl7/igt@gem_exec_reloc@basic-many-act...@vecs0.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-hsw: [PASS][9] -> [WARN][10] ([i915#1519]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-fence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#1515]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-iclb5/igt@i915_pm_rc6_reside...@rc6-idle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-iclb7/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_pm_rpm@i2c: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl6/igt@i915_pm_...@i2c.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-skl2/igt@i915_pm_...@i2c.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198] / [i915#2110]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl1/igt@i915_selftest@m...@requests.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-skl9/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-apl7/igt@kms_big...@y-tiled-64bpp-rotate-180.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-apl3/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-a-ctm-0-75: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#1635] / [i915#95]) +29 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-apl3/igt@kms_co...@pipe-a-ctm-0-75.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-apl6/igt@kms_co...@pipe-a-ctm-0-75.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1: - shard-hsw: [PASS][23] -> [INCOMPLETE][24] ([i915#2055]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/shard-hsw1/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/shard-hsw1/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-kbl: [PASS][25] -> [DMESG-WARN][26] ([i915#1982]) +1 similar issue [25]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev3)
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev3)
URL : https://patchwork.freedesktop.org/series/78012/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8696 -> Patchwork_18069
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18069 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18069, 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_18069/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18069:
### IGT changes ###
Possible regressions
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-u2: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
Known issues
Here are the changes found in Patchwork_18069 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-byt-j1900/igt@i915_pm_...@module-reload.html
- fi-glk-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][17] ([fdo#109271]) -> [DMESG-FAIL][18]
([i915#62])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18069/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +3 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[22]:
Re: [Intel-gfx] [PATCH] drm/i915: Kill context before taking ctx->mutex
On 02/07/2020 14:26, Maarten Lankhorst wrote:
> Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin:
>>
>> On 24/06/2020 12:05, Maarten Lankhorst wrote:
>>> Killing context before taking ctx->mutex fixes a hang in
>>> gem_ctx_persistence.close-replace-race, where lut_close
>>> takes obj->resv.lock which is already held by execbuf,
>>> causing a stalling indefinitely.
>>
>> If this is the consequence of inverting the locking order I think you need
>> to move the fix earlier in the series, to precede the patch which creates
>> the inversion. Otherwise AFAICT the re-order of kill_context vs lut_close
>> seems fine.
>
> Yeah, it was just a bugfix I found when looking at the code, if you review it
> I can push it now so I don't have to resend. :)
You are saying it's a bug in drm-tip today?
From the commit:
[ 1904.342847] 2 locks held by gem_ctx_persist/11520:
[ 1904.342849] #0: 8882188e4968 (>mutex){+.+.}-{3:3}, at:
context_close+0xe6/0x850 [i915]
[ 1904.342941] #1: 88821c58a5a8 (reservation_ww_class_mutex){+.+.}-{3:3},
at: lut_close+0x2c2/0xba0 [i915]
[ 1904.343033] 3 locks held by gem_ctx_persist/11521:
[ 1904.343035] #0: c98ff938
(reservation_ww_class_acquire){+.+.}-{0:0}, at:
i915_gem_do_execbuffer+0x103d/0x54c0 [i915]
[ 1904.343157] #1: 88821c58a5a8 (reservation_ww_class_mutex){+.+.}-{3:3},
at: eb_validate_vmas+0x602/0x2010 [i915]
[ 1904.343267] #2: 88820afd9200 (>mutex/1){+.+.}-{3:3}, at:
i915_vma_pin_ww+0x335/0x2300 [i915]
I don't see two inverted locks in two threads - what is happening causing
"stalling" - deadlock? Livelock?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> wrote:
> >
> > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote:
> > Hi Sean,
> > I am new to DP MST stuff, I am looking to DP MST spec DP v1.2a.
> > I have looked the entire series, i will take up this opportunity to review
> > the series from HDCP over DP MST POV.
> > I think theoretically this series should work or Gen12 as well, as DP MST
> > streams
> > are getting encrypted by QUERY_STREAM_ENCRYPTION_STATUS reply tranaction msg
> > (generating Stream State Signature L’).
> > I will test this on Gen12 H/W with DP MST support and will provide my
> > inputs.
> >
> > Meanwhile while going through DP MST v1.2a specs(Page 262) came to know
> > about
> > a DP irq vector LINK_SERVICE_IRQ_VECTOR_ESI0 (02005h),
> > Bit 2 : STREAM_STATUS_CHANGED.
> > When this bit set to ‘1’ indicates the source must re-check the Stream
> > Status
> > with the QUERY_STREAM_ENCRYPTION_STATUS message.
> > Currently i feel this irq support is missing, do we require to support
> > above IRQ vector for DP MST stream encryption.
> >
>
> Hi Anshuman,
> Thank you for your comments.
>
> QUERY_STREAM_ENCRYPTION_STATUS is not necessary for HDCP 1.x, I added
> this as a safety check to ensure that the streams were being
> encrypted. As such, the existing integrity checks in place for DP are
> sufficient to satisfy spec. When HDCP 2.2 support is added for MST,
> handling QSES will need to be addressed to meet spec. Note also that
> we're not validating the QSES signature for the same reason.
Thanks sean for the explanation,
overall patch looks good to me but i have couple of doubt see below.
>
> Sean
>
>
> > Thanks,
> > Anshuman Gupta.
> >
> > > From: Sean Paul
> > >
> > > Used to query whether an MST stream is encrypted or not.
> > >
> > > Signed-off-by: Sean Paul
> > >
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> > > #v4
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
> > > #v5
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
> > > #v6
> > >
> > > Changes in v4:
> > > -Added to the set
> > > Changes in v5:
> > > -None
> > > Changes in v6:
> > > -Use FIELD_PREP to generate request buffer bitfields (Lyude)
> > > -Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
> > > Changes in v7:
> > > -None
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 142 ++
> > > .../drm/selftests/test-drm_dp_mst_helper.c| 17 +++
> > > include/drm/drm_dp_helper.h | 3 +
> > > include/drm/drm_dp_mst_helper.h | 44 ++
> > > 4 files changed, 206 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index b2f5a84b4cfb..fc68478eaeb4 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -20,11 +20,13 @@
> > > * OF THIS SOFTWARE.
> > > */
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -419,6 +421,22 @@ drm_dp_encode_sideband_req(const struct
> > > drm_dp_sideband_msg_req_body *req,
> > > memcpy([idx], req->u.i2c_write.bytes,
> > > req->u.i2c_write.num_bytes);
> > > idx += req->u.i2c_write.num_bytes;
> > > break;
> > > + case DP_QUERY_STREAM_ENC_STATUS: {
> > > + const struct drm_dp_query_stream_enc_status *msg;
> > > +
> > > + msg = >u.enc_status;
> > > + buf[idx] = msg->stream_id;
> > > + idx++;
> > > + memcpy([idx], msg->client_id, sizeof(msg->client_id));
> > > + idx += sizeof(msg->client_id);
> > > + buf[idx] = 0;
> > > + buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
> > > + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> > > + buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
> > > + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> > > + idx++;
> > > + }
> > > + break;
> > > }
> > > raw->cur_len = idx;
> > > }
> > > @@ -547,6 +565,20 @@ drm_dp_decode_sideband_req(const struct
> > > drm_dp_sideband_msg_tx *raw,
> > > return -ENOMEM;
> > > }
> > > break;
> > > + case DP_QUERY_STREAM_ENC_STATUS:
> > > + req->u.enc_status.stream_id = buf[idx++];
> > > + for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
> > > + req->u.enc_status.client_id[i] = buf[idx++];
> > > +
> > > + req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
> > > +
Re: [Intel-gfx] [PATCH 1/3] drm/edid: Allow looking for ext blocks starting from a specified index
On Tue, Jun 30, 2020 at 11:42:36PM +, Souza, Jose wrote:
> On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> > for iterating through multiple ext blocks of the same type by
> > passing the starting ext block index to drm_find_edid_extension(). Well
> > also have drm_find_edid_extension() update the index to point to the
> > next ext block on success. Thus we should be able to call
> > drm_find_edid_extension() in loop.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_edid.c | 30 +-
> > 1 file changed, 21 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index d8372d63851b..f2531d51dfa2 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3188,7 +3188,8 @@ add_detailed_modes(struct drm_connector *connector,
> > struct edid *edid,
> > /*
> > * Search EDID for CEA extension block.
> > */
> > -static u8 *drm_find_edid_extension(const struct edid *edid, int ext_id)
> > +static u8 *drm_find_edid_extension(const struct edid *edid,
> > + int ext_id, int *ext_index)
> > {
> > u8 *edid_ext = NULL;
> > int i;
> > @@ -3198,23 +3199,26 @@ static u8 *drm_find_edid_extension(const struct
> > edid *edid, int ext_id)
> > return NULL;
> >
> > /* Find CEA extension */
> > - for (i = 0; i < edid->extensions; i++) {
> > + for (i = *ext_index; i < edid->extensions; i++) {
> > edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
> > if (edid_ext[0] == ext_id)
> > break;
> > }
> >
> > - if (i == edid->extensions)
> > + if (i >= edid->extensions)
> > return NULL;
> >
> > + *ext_index = i + 1;
> > +
> > return edid_ext;
> > }
> >
>
> I would add something like drm_find_edid_n_extension() with the
> implementation above and then implement drm_find_edid_extension() calling
> drm_find_edid_n_extension() but it is just one caller that is not using
> ext_index so LGTM.
>
> >
> > static u8 *drm_find_displayid_extension(const struct edid *edid,
> > - int *length, int *idx)
> > + int *length, int *idx,
> > + int *ext_index)
> > {
> > - u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT);
> > + u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
> > struct displayid_hdr *base;
> > int ret;
> >
> > @@ -3241,14 +3245,18 @@ static u8 *drm_find_cea_extension(const struct edid
> > *edid)
> > struct displayid_block *block;
> > u8 *cea;
> > u8 *displayid;
> > + int ext_index;
> >
> > /* Look for a top level CEA extension block */
> > - cea = drm_find_edid_extension(edid, CEA_EXT);
> > + ext_index = 0;
>
> In 2 places ext_index is initialized in the variable declaration and in 2
> other places is not, all of it could be done in the declaration
No, in this case we need to reset it back to 0 when the start looking
for the DispID ext block (as opposed to the CEA ext block). So I figured
it's cleaner if both initialize it to 0 the same way. All the other
places need just the one initialization.
Eventually I think I'd like some kind of for_each_ext_block() to make
this stuff less crap...
> or if you
> really want to leave the context close to the users, initialize it in the
> "for (;;)" in the next patch.
>
> With the change above:
>
> Reviewed-by: José Roberto de Souza
>
> > + cea = drm_find_edid_extension(edid, CEA_EXT, _index);
> > if (cea)
> > return cea;
> >
> > /* CEA blocks can also be found embedded in a DisplayID block */
> > - displayid = drm_find_displayid_extension(edid, , );
> > + ext_index = 0;
> > + displayid = drm_find_displayid_extension(edid, , ,
> > +_index);
> > if (!displayid)
> > return NULL;
> >
> > @@ -5195,8 +5203,10 @@ static int add_displayid_detailed_modes(struct
> > drm_connector *connector,
> > int length, idx;
> > struct displayid_block *block;
> > int num_modes = 0;
> > + int ext_index = 0;
> >
> > - displayid = drm_find_displayid_extension(edid, , );
> > + displayid = drm_find_displayid_extension(edid, , ,
> > +_index);
> > if (!displayid)
> > return 0;
> >
> > @@ -5870,11 +5880,13 @@ void drm_update_tile_info(struct drm_connector
> > *connector,
> > const struct edid *edid)
> > {
> > const void *displayid = NULL;
> > + int ext_index = 0;
> > int length, idx;
> > int ret;
> >
> > connector->has_tile = false;
> > - displayid = drm_find_displayid_extension(edid, , );
> > + displayid = drm_find_displayid_extension(edid,
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gem: Only revoke the GGTT
mmappings on aperture detiling changes
URL : https://patchwork.freedesktop.org/series/79046/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8696 -> Patchwork_18068
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/index.html
Known issues
Here are the changes found in Patchwork_18068 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#1982] / [i915#62] / [i915#92])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8696/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18068/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 37)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8696 -> Patchwork_18068
CI-20190529: 20190529
CI_DRM_8696: ba8b1c9012ed325ee42f673654da123bd1a9e2df @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5720: f35053d4b6d7bbcf6505ef67a8bd56acc7fb2eb2 @
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/display: add phy, vbt and ddi indexes
On Wed, Jul 01, 2020 at 10:24:07AM -0700, Lucas De Marchi wrote:
> On Wed, Jul 01, 2020 at 08:04:30PM +0300, Ville Syrjälä wrote:
> >On Wed, Jun 24, 2020 at 05:11:18PM -0700, Lucas De Marchi wrote:
> >> Identify 3 possible cases in which the index numbers can be different
> >> from the "port" and add them to the description-based ddi initialization
> >> table. This can be used in place of additional functions mapping from
> >> one to the other. Right now we already cover part of this by creating
> >> kind of
> >> virtual phy numbering, but that comes with downsides:
> >>
> >> a) there's not really a "phy numbering" in the spec, this is purely a
> >> software thing; hardware uses whatever they want thinking mapping from
> >> one to the other arbitrarily is easy in software.
> >>
> >> b) currently the mapping occurs on "leaf" functions, making the decision
> >> based on the platform for each of those functions
> >>
> >> With this new table the approach will be: the port, as defined by the
> >> enum port, is merely a driver convention and won't be used anymore to
> >> define the register offset or register bits. For that we have the other
> >> 3 indexes, identified as being possibly different from the current usage
> >> of register bits: ddi, vbt and phy. The phy type is also added here,
> >> meant to replace the checks for combo vs tc.
> >>
> >> v2: Rebase and add RKL
> >>
> >> Signed-off-by: Lucas De Marchi
> >> ---
> >> drivers/gpu/drm/i915/display/intel_display.c | 64 ++-
> >> drivers/gpu/drm/i915/display/intel_display.h | 8 +++
> >> .../drm/i915/display/intel_display_types.h| 4 ++
> >> 3 files changed, 45 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> index c234b50212b0..d591063502c5 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -16806,57 +16806,59 @@ static void intel_pps_init(struct
> >> drm_i915_private *dev_priv)
> >> }
> >>
> >> static const struct intel_ddi_port_info rkl_ports[] = {
> >> - { .name = "DDI A", .port = PORT_A },
> >> - { .name = "DDI B", .port = PORT_B },
> >> - { .name = "DDI TC1", .port = PORT_D },
> >> - { .name = "DDI TC2", .port = PORT_E },
> >> + { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> >> = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
> >
> >I'm thinking we won't need ddi_idx and instead 'port' should suffice.
> >We can add the aliases with the TC names for tgl+ to unconfuse the
> >current mess. In fact I already tried that in a local branch (while
> >doing the hpd_pin cleanup) and it looks mostly fine to me. There are
> >a few annoying parts, like power domains, where we still end up with
> >port G-I names that don't exist anywhere in bspec (excetp in VBT).
>
> I think we should stop trying that because it leads to the current mess
> we put ourselves into. Hence my idea of "port should be just a software
> thing, don't try to make it match the hardware". HW indexes (for register
> address, bitfields and whatnot) are provided by the correspondent _idx.
> Which index you use depends on what part of the hw you are talking to.
>
> See the TODO below of one case this would be true. Once the conversions
> are finished we change them and then for every ddi+ platform, port is
> just a number we can use to identify the entry in the table.
Seems contrary to pretty much everything else in the driver so
not great IMO.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/1] drm/i915/gt: Initialize reserved and unspecified MOCS indices
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified entries should not be used as they may be
changed to less performant variants with better coherency in the future
if more entries are needed.
V2: As suggested by Lucas "De Marchi" to utilise __init_mocs_table for
programming default value, setting I915_MOCS_PTE index of tgl_mocs_table
with desired value.
Cc: Chris Wilson
Cc: Lucas De Marchi
Cc: Tomasz Lis
Cc: Matt Roper
Cc: Joonas Lahtinen
Cc: Francisco Jerez
Cc: Mathew Alwin
Cc: Mcguire Russell W
Cc: Spruit Neil R
Cc: Zhou Cheng
Cc: Benemelis Mike G
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 632e08a4592b2..c32f90bd56693 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -234,11 +234,17 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
L3_1_UC)
static const struct drm_i915_mocs_entry tgl_mocs_table[] = {
- /* Base - Error (Reserved for Non-Use) */
- MOCS_ENTRY(0, 0x0, 0x0),
- /* Base - Reserved */
- MOCS_ENTRY(1, 0x0, 0x0),
+ /* NOTE:
+* Reserved and unspecified MOCS indices have been set to (L3 + LCC).
+* These reserved entry should never be used, they may be chanaged
+* to low performant variants with better coherency in the future if
+* more entries are needed. We are programming index I915_MOCS_PTE(1)
+* only, __init_mocs_table() take care to prgramm unseud index with
+* this entry.
+*/
+ MOCS_ENTRY(1, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
GEN11_MOCS_ENTRIES,
/* Implicitly enable L1 - HDC:L1 + L3 + LLC */
@@ -265,6 +271,7 @@ static const struct drm_i915_mocs_entry tgl_mocs_table[] = {
MOCS_ENTRY(61,
LE_1_UC | LE_TC_1_LLC,
L3_3_WB),
+
};
static const struct drm_i915_mocs_entry icl_mocs_table[] = {
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/1] drm/i915/gt: Initialize reserved and unspecified MOCS indices
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified entries should not be used as they may be
changed to less performant variants with better coherency in the future
if more entries are needed.
V2: As suggested by Lucas "De Marchi" to utilise __init_mocs_table for
programming default value, setting I915_MOCS_PTE index of tgl_mocs_table
with desired value.
Ayaz A Siddiqui (1):
drm/i915/gt: Initialize reserved and unspecified MOCS indices
drivers/gpu/drm/i915/gt/intel_mocs.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Kill context before taking ctx->mutex
Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin: > > On 24/06/2020 12:05, Maarten Lankhorst wrote: >> Killing context before taking ctx->mutex fixes a hang in >> gem_ctx_persistence.close-replace-race, where lut_close >> takes obj->resv.lock which is already held by execbuf, >> causing a stalling indefinitely. > > If this is the consequence of inverting the locking order I think you need to > move the fix earlier in the series, to precede the patch which creates the > inversion. Otherwise AFAICT the re-order of kill_context vs lut_close seems > fine. Yeah, it was just a bugfix I found when looking at the code, if you review it I can push it now so I don't have to resend. :) ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: Only revoke mmap handlers if active
Quoting Chris Wilson (2020-07-02 14:06:05)
> Avoid waking up the device and taking stale locks if we know that the
> object is not currently mmapped. This is particularly useful as not many
> object are actually mmapped and so we can destroy them without waking
> the device up, and gives us a little more freedom of workqueue ordering
> during shutdown.
>
> v2: Pull the release_mmap() into its single user in freeing the objects,
> where there can not be any race with a concurrent user of the freed
> object. Or so one hopes!
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin ,
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 13 -
> drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 --
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +++
> 3 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 7c2650cfb070..b23368529a40 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -507,19 +507,6 @@ void i915_gem_object_release_mmap_offset(struct
> drm_i915_gem_object *obj)
> spin_unlock(>mmo.lock);
> }
>
> -/**
> - * i915_gem_object_release_mmap - remove physical page mappings
> - * @obj: obj in question
> - *
> - * Preserve the reservation of the mmapping with the DRM core code, but
> - * relinquish ownership of the pages back to the system.
> - */
> -void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> -{
> - i915_gem_object_release_mmap_gtt(obj);
> - i915_gem_object_release_mmap_offset(obj);
> -}
> -
> static struct i915_mmap_offset *
> lookup_mmo(struct drm_i915_gem_object *obj,
>enum i915_mmap_type mmap_type)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> index 7c5ccdf59359..efee9e0d2508 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> @@ -24,8 +24,6 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
> struct drm_device *dev,
> u32 handle, u64 *offset);
>
> -void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
> -
> void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
> void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 6b69191c5543..d377c0ef8603 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -171,6 +171,17 @@ static void __i915_gem_free_object_rcu(struct rcu_head
> *head)
> atomic_dec(>mm.free_count);
> }
>
> +static void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
Maybe free_mmaps to try and discourage re-use?
> +{
> + /* Skip serialisation and waking the device if known to be not used.
> */
> +
> + if (obj->userfault_count)
> + i915_gem_object_release_mmap_gtt(obj);
> +
> + if (!RB_EMPTY_ROOT(>mmo.offsets))
> + i915_gem_object_release_mmap_offset(obj);
> +}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on construction
== Series Details == Series: series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on construction URL : https://patchwork.freedesktop.org/series/79037/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8692_full -> Patchwork_18065_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18065_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18065_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_18065_full: ### IGT changes ### Possible regressions * igt@gem_bad_reloc@negative-reloc-bltcopy: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-iclb5/igt@gem_bad_re...@negative-reloc-bltcopy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-iclb5/igt@gem_bad_re...@negative-reloc-bltcopy.html - shard-kbl: [PASS][3] -> [FAIL][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-kbl1/igt@gem_bad_re...@negative-reloc-bltcopy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-kbl3/igt@gem_bad_re...@negative-reloc-bltcopy.html - shard-skl: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-skl5/igt@gem_bad_re...@negative-reloc-bltcopy.html * igt@gem_close@many-handles-one-vma: - shard-glk: [PASS][6] -> [FAIL][7] +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-glk2/igt@gem_cl...@many-handles-one-vma.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-glk1/igt@gem_cl...@many-handles-one-vma.html - shard-apl: [PASS][8] -> [FAIL][9] +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-apl3/igt@gem_cl...@many-handles-one-vma.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-apl8/igt@gem_cl...@many-handles-one-vma.html - shard-skl: [PASS][10] -> [FAIL][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-skl9/igt@gem_cl...@many-handles-one-vma.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-skl8/igt@gem_cl...@many-handles-one-vma.html - shard-tglb: [PASS][12] -> [FAIL][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-tglb5/igt@gem_cl...@many-handles-one-vma.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-tglb8/igt@gem_cl...@many-handles-one-vma.html - shard-hsw: [PASS][14] -> [FAIL][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-hsw4/igt@gem_cl...@many-handles-one-vma.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-hsw7/igt@gem_cl...@many-handles-one-vma.html - shard-snb: [PASS][16] -> [FAIL][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-snb2/igt@gem_cl...@many-handles-one-vma.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-snb6/igt@gem_cl...@many-handles-one-vma.html - shard-iclb: NOTRUN -> [FAIL][18] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-iclb6/igt@gem_cl...@many-handles-one-vma.html * igt@gem_sync@basic-many-each: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-iclb6/igt@gem_s...@basic-many-each.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-iclb3/igt@gem_s...@basic-many-each.html * igt@kms_vblank@pipe-d-ts-continuation-dpms-rpm: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/shard-tglb8/igt@kms_vbl...@pipe-d-ts-continuation-dpms-rpm.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/shard-tglb8/igt@kms_vbl...@pipe-d-ts-continuation-dpms-rpm.html ### Piglit changes ### Possible regressions * spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-bitand-not-uint-uvec3 (NEW): - pig-glk-j5005: NOTRUN -> [FAIL][23] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/pig-glk-j5005/spec@arb_tessellation_shader@execution@built-in-functi...@tcs-op-bitand-not-uint-uvec3.html New tests - New tests have been introduced between CI_DRM_8692_full and Patchwork_18065_full: ### New Piglit tests (1) ### * spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-bitand-not-uint-uvec3: - Statuses : 1 fail(s) - Exec time: [0.12] s Known issues
[Intel-gfx] [PATCH v2 2/2] drm/i915/gem: Only revoke mmap handlers if active
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdown.
v2: Pull the release_mmap() into its single user in freeing the objects,
where there can not be any race with a concurrent user of the freed
object. Or so one hopes!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin ,
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 13 -
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 --
drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +++
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 7c2650cfb070..b23368529a40 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -507,19 +507,6 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_unlock(>mmo.lock);
}
-/**
- * i915_gem_object_release_mmap - remove physical page mappings
- * @obj: obj in question
- *
- * Preserve the reservation of the mmapping with the DRM core code, but
- * relinquish ownership of the pages back to the system.
- */
-void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
-{
- i915_gem_object_release_mmap_gtt(obj);
- i915_gem_object_release_mmap_offset(obj);
-}
-
static struct i915_mmap_offset *
lookup_mmo(struct drm_i915_gem_object *obj,
enum i915_mmap_type mmap_type)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 7c5ccdf59359..efee9e0d2508 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -24,8 +24,6 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
struct drm_device *dev,
u32 handle, u64 *offset);
-void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
-
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6b69191c5543..d377c0ef8603 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -171,6 +171,17 @@ static void __i915_gem_free_object_rcu(struct rcu_head
*head)
atomic_dec(>mm.free_count);
}
+static void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
+{
+ /* Skip serialisation and waking the device if known to be not used. */
+
+ if (obj->userfault_count)
+ i915_gem_object_release_mmap_gtt(obj);
+
+ if (!RB_EMPTY_ROOT(>mmo.offsets))
+ i915_gem_object_release_mmap_offset(obj);
+}
+
static void __i915_gem_free_objects(struct drm_i915_private *i915,
struct llist_node *freed)
{
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
Only a GGTT mmaping will use the aperture detiling registers, so only a
tiling change for an object, we only need to revoke those mmapings and
not the CPU mmapings (which are always linear irrespective of the tiling).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fe27c5b344e3..7c2650cfb070 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -448,7 +448,7 @@ void __i915_gem_object_release_mmap_gtt(struct
drm_i915_gem_object *obj)
* mapping will then trigger a page fault on the next user access, allowing
* fixup by vm_fault_gtt().
*/
-static void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
+void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
intel_wakeref_t wakeref;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 862e01b7cb69..7c5ccdf59359 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -24,8 +24,11 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
struct drm_device *dev,
u32 handle, u64 *offset);
-void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
+
+void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
#endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index 0158e49bf9bb..ff72ee2fd9cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -299,7 +299,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
i915_gem_object_unlock(obj);
/* Force the fence to be reacquired for GTT access */
- i915_gem_object_release_mmap(obj);
+ i915_gem_object_release_mmap_gtt(obj);
/* Try to preallocate memory required to save swizzling on put-pages */
if (i915_gem_object_needs_bit17_swizzle(obj)) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/perf: Instantiate a local drm_fd for the unprivileged helper
Could be a particularly slow PIPE_CONTROL instruction on TGL. We assumed that in a sequence of instructions : PC0, MI_RPC0, PC1, MI_RPC1 The delta of time PC1 - PC0 would be with 500ns of MI_RPC1 - MI_RPC0. That does sound a bit broken tbf... Patch looks good : Reviewed-by: Lionel Landwerlin Thanks, -Lionel On 02/07/2020 15:39, Chris Wilson wrote: While the test is blocked, we keep trying the gen12_single_ctx_helper(). As this is using the parent's drm_fd, all of our context allocations are persistent. Reopen the device in the child so that when we exit, our allocations are freed along with the process -- avoiding a total memory leak if the test is stuck. This does not explain why the test was stuck, it just prevents us from exacerbating the error condition. Hopefully leaving the system in a more debuggable state. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2126 Signed-off-by: Chris Wilson Cc: Lionel Landwerlin --- tests/i915/perf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/i915/perf.c b/tests/i915/perf.c index d4ebae30d..dbf7e3497 100644 --- a/tests/i915/perf.c +++ b/tests/i915/perf.c @@ -3845,6 +3845,7 @@ static void gen12_single_ctx_helper(void) .format = test_set->perf_oa_format }; + drm_fd = gem_reopen_driver(drm_fd); bufmgr = drm_intel_bufmgr_gem_init(drm_fd, 4096); drm_intel_bufmgr_gem_enable_reuse(bufmgr); @@ -4107,6 +4108,7 @@ static void gen12_single_ctx_helper(void) drm_intel_gem_context_destroy(context1); drm_intel_bufmgr_destroy(bufmgr); __perf_close(stream_fd); + close(drm_fd); } static void ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
Am 25.06.20 um 15:59 schrieb Daniel Vetter: On Thu, Jun 25, 2020 at 3:23 PM Lionel Landwerlin wrote: On 25/06/2020 16:18, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-06-25 13:34:43) There was probably a misunderstand on how the dma-fence-chain is supposed to work or what dma_fence_chain_find_seqno() is supposed to return. dma_fence_chain_find_seqno() is here to give us the fence to wait upon for a particular point in the timeline. The timeline progresses only when all the points prior to a given number have completed. Hmm, the question was what point is it supposed to wait for. For the simple chain of [1, 3], does 1 being signaled imply that all points up to 3 are signaled, or does 3 not being signaled imply that all points after 1 are not. If that's mentioned already somewhere, my bad. If not, could you put the answer somewhere. -Chris In [1, 3], if 1 is signaled, the timeline value is 1. And find_seqno(2) should return NULL. In the out_of_order selftest the chain was [1, 2, 3], 2 was signaled and the test was expecting no fence to be returned by find_seqno(2). But we still have to wait on 1 to complete before find_seqno(2) can return NULL (as in you don't have to wait on anything). Hope that answer the question. I asked Christian to document why timeline works like this, but I can't find it in the kerneldoc right now. If it's missing I think we should fix that and add the explanation, iirc it was around gpu reset creating too much havoc otherwise. I do remember that I wrote a patch to improve the kerneldoc for timeline semaphores, but then somebody else came along with an even better description. Unfortunately it looks like neither was ever merged. Need to dig through my mails, Christian. -Daniel -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fintel-gfxdata=02%7C01%7Cchristian.koenig%40amd.com%7Cfd87640cd9bd422971bf08d8191004d2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637286903879074805sdata=M3WGWbuyQKZeGC0J3wEKtgQ1oKYo6GOAMvKU2mU3r%2FM%3Dreserved=0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/23] drm/i915/gem: Only revoke mmap handlers if active
Quoting Chris Wilson (2020-07-02 13:47:00)
> Quoting Tvrtko Ursulin (2020-07-02 13:35:41)
> >
> > On 02/07/2020 09:32, Chris Wilson wrote:
> > > Avoid waking up the device and taking stale locks if we know that the
> > > object is not currently mmapped. This is particularly useful as not many
> > > object are actually mmapped and so we can destroy them without waking
> > > the device up, and gives us a little more freedom of workqueue ordering
> > > during shutdown.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > index fe27c5b344e3..522ca4f51b53 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > @@ -516,8 +516,11 @@ void i915_gem_object_release_mmap_offset(struct
> > > drm_i915_gem_object *obj)
> > >*/
> > > void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> > > {
> > > - i915_gem_object_release_mmap_gtt(obj);
> > > - i915_gem_object_release_mmap_offset(obj);
> > > + if (obj->userfault_count)
> > > + i915_gem_object_release_mmap_gtt(obj);
> > > +
> > > + if (!RB_EMPTY_ROOT(>mmo.offsets))
> > > + i915_gem_object_release_mmap_offset(obj);
> > > }
> > >
> > > static struct i915_mmap_offset *
> > >
> >
> > Both conditions will need explaining why they are not racy.
>
> It's an identical race even if you do take the mutex.
>
> Thread AThread B
> release_mmapcreate_mmap_offset
> mutex_lock/unlock ...
> mutex_lock/unlock
>
> Thread A will only operate on a snapshot of the current state with or
> without the mutex; if Thread B is concurrently adding new mmaps, that
> may occur before after Thread A makes decision the object is clean.
> Thread A can only assess the state at that moment in time, and only
> cares enough to ensure that from its pov, it has cleared the old
> mmaps.
>
> During free, we know there can be no concurrency (refcnt==0) and so the
> snapshot is true.
Beyond the free usecase, the serialisation of the individual releases is
coordinated by owning the backing storage operation i.e. we release
when revoking the vma under the vma->vm->mutex, and the pages under
currently the obj->mm.lock; to create a new fault mapping, the handlers
will have taken a reference to either the vma or backing store and thus
have serialised with the release. i915_gem_object_release_mmap() should
be only used on the free path, since it's usual for us to have to do
both. Now what are we doing in set-tiling? The tiling only affects ggtt
mmapings...
-Chris
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/23] drm/i915/gem: Only revoke mmap handlers if active
Quoting Tvrtko Ursulin (2020-07-02 13:35:41)
>
> On 02/07/2020 09:32, Chris Wilson wrote:
> > Avoid waking up the device and taking stale locks if we know that the
> > object is not currently mmapped. This is particularly useful as not many
> > object are actually mmapped and so we can destroy them without waking
> > the device up, and gives us a little more freedom of workqueue ordering
> > during shutdown.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index fe27c5b344e3..522ca4f51b53 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -516,8 +516,11 @@ void i915_gem_object_release_mmap_offset(struct
> > drm_i915_gem_object *obj)
> >*/
> > void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> > {
> > - i915_gem_object_release_mmap_gtt(obj);
> > - i915_gem_object_release_mmap_offset(obj);
> > + if (obj->userfault_count)
> > + i915_gem_object_release_mmap_gtt(obj);
> > +
> > + if (!RB_EMPTY_ROOT(>mmo.offsets))
> > + i915_gem_object_release_mmap_offset(obj);
> > }
> >
> > static struct i915_mmap_offset *
> >
>
> Both conditions will need explaining why they are not racy.
It's an identical race even if you do take the mutex.
Thread AThread B
release_mmapcreate_mmap_offset
mutex_lock/unlock ...
mutex_lock/unlock
Thread A will only operate on a snapshot of the current state with or
without the mutex; if Thread B is concurrently adding new mmaps, that
may occur before after Thread A makes decision the object is clean.
Thread A can only assess the state at that moment in time, and only
cares enough to ensure that from its pov, it has cleared the old
mmaps.
During free, we know there can be no concurrency (refcnt==0) and so the
snapshot is true.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/perf: Instantiate a local drm_fd for the unprivileged helper
While the test is blocked, we keep trying the gen12_single_ctx_helper(). As this is using the parent's drm_fd, all of our context allocations are persistent. Reopen the device in the child so that when we exit, our allocations are freed along with the process -- avoiding a total memory leak if the test is stuck. This does not explain why the test was stuck, it just prevents us from exacerbating the error condition. Hopefully leaving the system in a more debuggable state. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2126 Signed-off-by: Chris Wilson Cc: Lionel Landwerlin --- tests/i915/perf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/i915/perf.c b/tests/i915/perf.c index d4ebae30d..dbf7e3497 100644 --- a/tests/i915/perf.c +++ b/tests/i915/perf.c @@ -3845,6 +3845,7 @@ static void gen12_single_ctx_helper(void) .format = test_set->perf_oa_format }; + drm_fd = gem_reopen_driver(drm_fd); bufmgr = drm_intel_bufmgr_gem_init(drm_fd, 4096); drm_intel_bufmgr_gem_enable_reuse(bufmgr); @@ -4107,6 +4108,7 @@ static void gen12_single_ctx_helper(void) drm_intel_gem_context_destroy(context1); drm_intel_bufmgr_destroy(bufmgr); __perf_close(stream_fd); + close(drm_fd); } static void -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 03/28] drm/i915/dg1: Add DG1 PCI IDs
Hi Lucas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20200702]
[cannot apply to v5.8-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Lucas-De-Marchi/Introduce-DG1/20200702-075819
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-r025-20200702 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
003a086ffc0d1affbb8300b36225fb8150a2d40a)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_pci.c:903:39: warning: unused variable 'dg1_info'
>> [-Wunused-const-variable]
static const struct intel_device_info dg1_info = {
^
1 warning generated.
vim +/dg1_info +903 drivers/gpu/drm/i915/i915_pci.c
896
897 #define GEN12_DGFX_FEATURES \
898 GEN12_FEATURES, \
899 .memory_regions = REGION_SMEM | REGION_LMEM, \
900 .has_master_unit_irq = 1, \
901 .is_dgfx = 1
902
> 903 static const struct intel_device_info dg1_info = {
904 GEN12_DGFX_FEATURES,
905 PLATFORM(INTEL_DG1),
906 .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) |
BIT(PIPE_D),
907 .require_force_probe = 1,
908 .engine_mask =
909 BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
910 BIT(VCS0) | BIT(VCS2),
911 };
912
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/23] drm/i915/gem: Only revoke mmap handlers if active
On 02/07/2020 09:32, Chris Wilson wrote:
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdown.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fe27c5b344e3..522ca4f51b53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -516,8 +516,11 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
*/
void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
{
- i915_gem_object_release_mmap_gtt(obj);
- i915_gem_object_release_mmap_offset(obj);
+ if (obj->userfault_count)
+ i915_gem_object_release_mmap_gtt(obj);
+
+ if (!RB_EMPTY_ROOT(>mmo.offsets))
+ i915_gem_object_release_mmap_offset(obj);
}
static struct i915_mmap_offset *
Both conditions will need explaining why they are not racy.
First should normally be done under the ggtt->mutex, second under
obj->mmo.lock.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/23] drm/i915: Drop vm.ref for duplicate vma on construction
On 02/07/2020 09:32, Chris Wilson wrote:
As we allow for parallel threads to create vma instances in parallel,
and we only filter out the duplicates upon reacquiring the spinlock for
the rbtree, we have to free the loser of the constructors' race. When
freeing, we should also drop any resource references acquired for the
redundant vma.
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
---
drivers/gpu/drm/i915/i915_vma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 1f63c4a1f055..7fe1f317cd2b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -198,6 +198,7 @@ vma_create(struct drm_i915_gem_object *obj,
cmp = i915_vma_compare(pos, vm, view);
if (cmp == 0) {
spin_unlock(>vma.lock);
+ i915_vm_put(vm);
i915_vma_free(vma);
return pos;
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
On Thu, Jul 2, 2020 at 1:27 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> > Only when vblanks are supported ofc.
> >
> > Some drivers do this already, but most unfortunately missed it. This
> > opens up bugs after driver load, before the crtc is enabled for the
> > first time. syzbot spotted this when loading vkms as a secondary
> > output. Given how many drivers are buggy it's best to solve this once
> > and for all in shared helper code.
> >
> > Aside from moving the few existing calls to drm_crtc_vblank_reset into
> > helpers (i915 doesn't use helpers, so keeps its own) I think the
> > regression risk is minimal: atomic helpers already rely on drivers
> > calling drm_crtc_vblank_on/off correctly in their hooks when they
> > support vblanks. And driver that's failing to handle vblanks after
> > this is missing those calls already, and vblanks could only work by
> > accident when enabling a CRTC for the first time right after boot.
> >
> > Big thanks to Tetsuo for helping track down what's going wrong here.
> >
> > There's only a few drivers which already had the necessary call and
> > needed some updating:
> > - komeda, atmel and tidss also needed to be changed to call
> > __drm_atomic_helper_crtc_reset() intead of open coding it
> > - tegra and msm even had it in the same place already, just code
> > motion, and malidp already uses __drm_atomic_helper_crtc_reset().
>
> Should you mention rcar-du and omapdrm here ?
Uh yes need to mention them too here, and how exactly they're a bit
different. Will shuffle that from the v4: block below when applying.
> > Only call left is in i915, which doesn't use drm_mode_config_reset,
> > but has its own fastboot infrastructure. So that's the only case where
> > we actually want this in the driver still.
> >
> > I've also reviewed all other drivers which set up vblank support with
> > drm_vblank_init. After the previous patch fixing mxsfb all atomic
> > drivers do call drm_crtc_vblank_on/off as they should, the remaining
> > drivers are either legacy kms or legacy dri1 drivers, so not affected
> > by this change to atomic helpers.
> >
> > v2: Use the drm_dev_has_vblank() helper.
> >
> > v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> > instead of drm_crtc_vblank_reset. Adjust them too.
> >
> > v4: Laurent noticed that rcar-du and omap open-code their crtc reset
> > and hence would actually be broken by this patch now. So fix them up
> > by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
> >
> > Cc: Laurent Pinchart
> > Reviewed-by: Boris Brezillon
> > Acked-by: Liviu Dudau
> > Acked-by: Thierry Reding
> > Link:
> > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> > Reported-by: Tetsuo Handa
> > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> > Cc: Tetsuo Handa
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > Cc: Mihail Atanassov
> > Cc: Brian Starkey
> > Cc: Sam Ravnborg
> > Cc: Boris Brezillon
> > Cc: Nicolas Ferre
> > Cc: Alexandre Belloni
> > Cc: Ludovic Desroches
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Thierry Reding
> > Cc: Jonathan Hunter
> > Cc: Jyri Sarha
> > Cc: Tomi Valkeinen
> > Cc: Rob Clark
> > Cc: Sean Paul
> > Cc: Brian Masney
> > Cc: Emil Velikov
> > Cc: zhengbin
> > Cc: Thomas Gleixner
> > Cc: linux-te...@vger.kernel.org
> > Cc: Kieran Bingham
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> > drivers/gpu/drm/arm/malidp_drv.c | 1 -
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> > drivers/gpu/drm/drm_atomic_state_helper.c| 4
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> > drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +---
> > drivers/gpu/drm/omapdrm/omap_drv.c | 4
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +-
> > drivers/gpu/drm/tegra/dc.c | 1 -
> > drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> > drivers/gpu/drm/tidss/tidss_kms.c| 4
> > 11 files changed, 15 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 56bd938961ee..f33418d6e1a0 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> > crtc->state = NULL;
> >
> > state = kzalloc(sizeof(*state), GFP_KERNEL);
> > - if (state) {
> > - crtc->state = >base;
> > -
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/79042/ State : success == Summary == CI Bug Log - changes from CI_DRM_8693 -> Patchwork_18067 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/index.html Known issues Here are the changes found in Patchwork_18067 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-glk-dsi: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-glk-dsi/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/fi-glk-dsi/igt@i915_pm_...@module-reload.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][7] ([i915#1982] / [i915#62] / [i915#92]) -> [DMESG-WARN][8] ([i915#62] / [i915#92] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_flip@basic-flip-vs-modeset@a-dp1: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][10] ([i915#62] / [i915#92]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) -> [DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (43 -> 37) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8693 -> Patchwork_18067 CI-20190529: 20190529 CI_DRM_8693: 878d924ea8a8c4c8812215d881f3bd70b3d4f2ee @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5720: f35053d4b6d7bbcf6505ef67a8bd56acc7fb2eb2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18067: 003acb5bb17450dfe3253238bba2290603a24346 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 003acb5bb174 drm/i915/gt: Move the heartbeat into the high priority system wq 905d2359cfb2 drm/i915/gt: Harden the heartbeat against a stuck driver == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18067/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
Hi Daniel,
Thank you for the patch.
On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
Should you mention rcar-du and omapdrm here ?
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
>
> v4: Laurent noticed that rcar-du and omap open-code their crtc reset
> and hence would actually be broken by this patch now. So fix them up
> by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
>
> Cc: Laurent Pinchart
> Reviewed-by: Boris Brezillon
> Acked-by: Liviu Dudau
> Acked-by: Thierry Reding
> Link:
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Brian Masney
> Cc: Emil Velikov
> Cc: zhengbin
> Cc: Thomas Gleixner
> Cc: linux-te...@vger.kernel.org
> Cc: Kieran Bingham
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c| 4
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +---
> drivers/gpu/drm/omapdrm/omap_drv.c | 4
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +-
> drivers/gpu/drm/tegra/dc.c | 1 -
> drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> drivers/gpu/drm/tidss/tidss_kms.c| 4
> 11 files changed, 15 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> crtc->state = NULL;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> return err;
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>
> crtc->port = kcrtc->master->of_output_port;
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/79042/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2267:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2268:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2269:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2270:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/79042/ State : warning == Summary == $ dim checkpatch origin/drm-tip 905d2359cfb2 drm/i915/gt: Harden the heartbeat against a stuck driver -:44: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using 'heartbeat', this function's name, in a string #44: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:135: + "no heartbeat on %s", total: 0 errors, 1 warnings, 0 checks, 35 lines checked 003acb5bb174 drm/i915/gt: Move the heartbeat into the high priority system wq ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce DG1 (rev4)
== Series Details == Series: Introduce DG1 (rev4) URL : https://patchwork.freedesktop.org/series/77496/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8691_full -> Patchwork_18064_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18064_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18064_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_18064_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@engines-mixed@vecs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-skl7/igt@gem_ctx_persistence@engines-mi...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-skl3/igt@gem_ctx_persistence@engines-mi...@vecs0.html * igt@kms_cursor_edge_walk@pipe-b-128x128-bottom-edge: - shard-hsw: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-hsw8/igt@kms_cursor_edge_w...@pipe-b-128x128-bottom-edge.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-hsw8/igt@kms_cursor_edge_w...@pipe-b-128x128-bottom-edge.html Known issues Here are the changes found in Patchwork_18064_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd2: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#1528]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-tglb1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-tglb1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd2.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-snb: [PASS][7] -> [TIMEOUT][8] ([i915#1958] / [i915#2119]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-snb5/igt@gem_mmap_...@cpuset-basic-small-copy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-snb2/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_addfb_basic@addfb25-modifier-no-flag: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +18 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-apl8/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-apl4/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html * igt@kms_big_fb@y-tiled-32bpp-rotate-0: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-kbl2/igt@kms_big...@y-tiled-32bpp-rotate-0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-kbl6/igt@kms_big...@y-tiled-32bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180] / [i915#93] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@cursor-vs-flip-varying-size: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +12 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-skl10/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-skl2/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html * igt@kms_flip@2x-modeset-vs-vblank-race@ab-vga1-hdmi-a1: - shard-hsw: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8691/shard-hsw7/igt@kms_flip@2x-modeset-vs-vblank-r...@ab-vga1-hdmi-a1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18064/shard-hsw6/igt@kms_flip@2x-modeset-vs-vblank-r...@ab-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-vga1: - shard-hsw: [PASS][21] -> [FAIL][22] ([i915#79]) [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K (rev2)
== Series Details == Series: drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K (rev2) URL : https://patchwork.freedesktop.org/series/78940/ State : success == Summary == CI Bug Log - changes from CI_DRM_8693 -> Patchwork_18066 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/index.html Known issues Here are the changes found in Patchwork_18066 that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Possible fixes * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][3] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/fi-kbl-x1275/igt@kms_busy@ba...@flip.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][5] ([i915#1982] / [i915#62] / [i915#92]) -> [DMESG-WARN][6] ([i915#62] / [i915#92] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_flip@basic-flip-vs-modeset@a-dp1: - fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][8] ([i915#62] / [i915#92]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) -> [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#1982] / [i915#62] / [i915#92]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8693/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (43 -> 37) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8693 -> Patchwork_18066 CI-20190529: 20190529 CI_DRM_8693: 878d924ea8a8c4c8812215d881f3bd70b3d4f2ee @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5720: f35053d4b6d7bbcf6505ef67a8bd56acc7fb2eb2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18066: e766a332c302f3ade90296b8b094acd9ebaeb520 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e766a332c302 drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18066/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/59] Add support for Keem Bay DRM driver
Hi, On 30/06/2020 23:27, Anitha Chrisanthus wrote: > This is a new DRM driver for Intel's KeemBay SOC. > The SoC couples an ARM Cortex A53 CPU with an Intel > Movidius VPU. > > This driver is tested with the KMB EVM board which is the refernce baord > for Keem Bay SOC. The SOC's display pipeline is as follows > > +--++-++---+ > |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | > +--++-++---+ > > LCD controller and Mipi DSI transmitter are part of the SOC and > mipi to HDMI converter is ADV7535 for KMB EVM board. > > The DRM driver is a basic KMS atomic modesetting display driver and > has no 2D or 3D graphics.It calls into the ADV bridge driver at > the connector level. > > Only 1080p resolution and single plane is supported at this time. > The usecase is for debugging video and camera outputs. > > Since we are just starting the upstream process, the KMB EVM board is not in > mainline and so Device tree changes are missing. A proper Yaml bindings file is then necessary even if the platform is not mainline. Neil > > Anitha Chrisanthus (52): > drm/kmb: Add support for KeemBay Display > drm/kmb: Added id to kmb_plane > drm/kmb: Set correct values in the LAYERn_CFG register > drm/kmb: Use biwise operators for register definitions > drm/kmb: Updated kmb_plane_atomic_check > drm/kmb: Initial check-in for Mipi DSI > drm/kmb: Set OUT_FORMAT_CFG register > drm/kmb: Added mipi_dsi_host initialization > drm/kmb: Part 1 of Mipi Tx Initialization > drm/kmb: Part 2 of Mipi Tx Initialization > drm/kmb: Use correct mmio offset from data book > drm/kmb: Part3 of Mipi Tx initialization > drm/kmb: Part4 of Mipi Tx Initialization > drm/kmb: Correct address offsets for mipi registers > drm/kmb: Part5 of Mipi Tx Intitialization > drm/kmb: Part6 of Mipi Tx Initialization > drm/kmb: Part7 of Mipi Tx Initialization > drm/kmb: Part8 of Mipi Tx Initialization > drm/kmb: Added ioremap/iounmap for register access > drm/kmb: Register IRQ for LCD > drm/kmb: IRQ handlers for LCD and mipi dsi > drm/kmb: Set hardcoded values to LCD_VSYNC_START > drm/kmb: Additional register programming to update_plane > drm/kmb: Add ADV7535 bridge > drm/kmb: Display clock enable/disable > drm/kmb: rebase to newer kernel version > drm/kmb: minor name change to match device tree > drm/kmb: Changed MMIO size > drm/kmb: Defer Probe > drm/kmb: call bridge init in the very beginning > drm/kmb: Enable MSS_CAM_CLK_CTRL for LCD and MIPI > drm/kmb: Set MSS_CAM_RSTN_CTRL along with enable > drm/kmb: Mipi DPHY initialization changes > drm/kmb: Fixed driver unload > drm/kmb: Added LCD_TEST config > drm/kmb: Changes for LCD to Mipi > drm/kmb: Update LCD programming to match MIPI > drm/kmb: Changed name of driver to kmb-drm > drm/kmb: Mipi settings from input timings > drm/kmb: Enable LCD interrupts > drm/kmb: Enable LCD interrupts during modeset > drm/kmb: Don’t inadvertantly disable LCD controller > drm/kmb: SWAP R and B LCD Layer order > drm/kmb: Disable ping pong mode > drm/kmb: Do the layer initializations only once > drm/kmb: disable the LCD layer in EOF irq handler > drm/kmb: Initialize uninitialized variables > drm/kmb: Added useful messages in LCD ISR > kmb/drm: Prune unsupported modes > drm/kmb: workaround for dma undeflow issue > drm/kmb: Get System Clock from SCMI > drm/kmb: work around for planar formats > > Edmund Dea (7): > drm/kmb: Cleanup probe functions > drm/kmb: Revert dsi_host back to a static variable > drm/kmb: Initialize clocks for clk_msscam, clk_mipi_ecfg, & > clk_mipi_cfg. > drm/kmb: Remove declaration of irq_lcd/irq_mipi > drm/kmb: Enable MIPI TX HS Test Pattern Generation > drm/kmb: Write to LCD_LAYERn_CFG only once > drm/kmb: Cleaned up code > > drivers/gpu/drm/Kconfig |2 + > drivers/gpu/drm/Makefile|1 + > drivers/gpu/drm/kmb/Kconfig | 12 + > drivers/gpu/drm/kmb/Makefile|2 + > drivers/gpu/drm/kmb/kmb_crtc.c | 243 + > drivers/gpu/drm/kmb/kmb_crtc.h | 61 ++ > drivers/gpu/drm/kmb/kmb_drv.c | 828 + > drivers/gpu/drm/kmb/kmb_drv.h | 196 > drivers/gpu/drm/kmb/kmb_dsi.c | 1950 > +++ > drivers/gpu/drm/kmb/kmb_dsi.h | 390 > drivers/gpu/drm/kmb/kmb_plane.c | 538 +++ > drivers/gpu/drm/kmb/kmb_plane.h | 142 +++ > drivers/gpu/drm/kmb/kmb_regs.h | 758 +++ > 13 files changed, 5123 insertions(+) > create mode 100644 drivers/gpu/drm/kmb/Kconfig > create mode 100644 drivers/gpu/drm/kmb/Makefile > create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c > create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.h > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h > create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c >
Re: [Intel-gfx] [PATCH 3/8] drm/imx: Use __drm_atomic_helper_crtc_reset
On Thu, 2020-07-02 at 11:41 +0200, Daniel Vetter wrote: > On Wed, Jun 24, 2020 at 9:25 AM Daniel Vetter wrote: > > On Fri, Jun 12, 2020 at 06:00:51PM +0200, Daniel Vetter wrote: > > > Now also comes with the added benefit of doing a drm_crtc_vblank_off(), > > > which means vblank state isn't ill-defined and fail-y at driver load > > > before the first modeset on each crtc. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Philipp Zabel > > > Cc: Shawn Guo > > > Cc: Sascha Hauer > > > Cc: Pengutronix Kernel Team > > > Cc: Fabio Estevam > > > Cc: NXP Linux Team > > > Cc: linux-arm-ker...@lists.infradead.org > > > > Ping for some ack/review on this pls. > > Still looking for an ack here so I can land this entire pile. > -Daniel Acked-by: Philipp Zabel regards Philipp ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/gt: Move the heartbeat into the high priority system wq
As we ensure that the heartbeat is reasonably fast (and should not block), move the heartbeat work into the system_highpri_wq to avoid having this essential task be blocked behind other slow work, such as our own retire_work_handler. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2119 Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c index 1c6c6692dd17..8ffdf676c0a0 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c @@ -32,7 +32,7 @@ static bool next_heartbeat(struct intel_engine_cs *engine) delay = msecs_to_jiffies_timeout(delay); if (delay >= HZ) delay = round_jiffies_up_relative(delay); - mod_delayed_work(system_wq, >heartbeat.work, delay); + mod_delayed_work(system_highpri_wq, >heartbeat.work, delay); return true; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
If the driver gets stuck holding the kernel timeline, we cannot issue a
heartbeat and so fail to discover that the driver is indeed stuck and do
not issue a GPU reset (which would hopefully unstick the driver!).
Switch to using a trylock so that we can query if the heartbeat's
timeline mutex is locked elsewhere, and then use the timer to probe if it
remains stuck at the same spot for consecutive heartbeats, indicating
that the mutex has not been released and the engine has not progressed.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 --
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 8db7e93abde5..1c6c6692dd17 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -65,6 +65,7 @@ static void heartbeat(struct work_struct *wrk)
container_of(wrk, typeof(*engine), heartbeat.work.work);
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
+ unsigned long serial;
/* Just in case everything has gone horribly wrong, give it a kick */
intel_engine_flush_submission(engine);
@@ -122,10 +123,19 @@ static void heartbeat(struct work_struct *wrk)
goto out;
}
- if (engine->wakeref_serial == engine->serial)
+ serial = READ_ONCE(engine->serial);
+ if (engine->wakeref_serial == serial)
goto out;
- mutex_lock(>timeline->mutex);
+ if (!mutex_trylock(>timeline->mutex)) {
+ /* Unable to lock the kernel timeline, is the engine stuck? */
+ if (xchg(>heartbeat.blocked, serial) == serial)
+ intel_gt_handle_error(engine->gt, engine->mask,
+ I915_ERROR_CAPTURE,
+ "no heartbeat on %s",
+ engine->name);
+ goto out;
+ }
intel_context_enter(ce);
rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 073c3769e8cc..490af81bd6f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -348,6 +348,7 @@ struct intel_engine_cs {
struct {
struct delayed_work work;
struct i915_request *systole;
+ unsigned long blocked;
} heartbeat;
unsigned long serial;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/imx: Use __drm_atomic_helper_crtc_reset
On Wed, Jun 24, 2020 at 9:25 AM Daniel Vetter wrote:
>
> On Fri, Jun 12, 2020 at 06:00:51PM +0200, Daniel Vetter wrote:
> > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > which means vblank state isn't ill-defined and fail-y at driver load
> > before the first modeset on each crtc.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Philipp Zabel
> > Cc: Shawn Guo
> > Cc: Sascha Hauer
> > Cc: Pengutronix Kernel Team
> > Cc: Fabio Estevam
> > Cc: NXP Linux Team
> > Cc: linux-arm-ker...@lists.infradead.org
>
> Ping for some ack/review on this pls.
Still looking for an ack here so I can land this entire pile.
-Daniel
>
> Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/imx/ipuv3-crtc.c | 21 -
> > 1 file changed, 8 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > index 63c0284f8b3c..02c2f848f2d1 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > @@ -109,20 +109,15 @@ static void imx_drm_crtc_reset(struct drm_crtc *crtc)
> > {
> > struct imx_crtc_state *state;
> >
> > - if (crtc->state) {
> > - if (crtc->state->mode_blob)
> > - drm_property_blob_put(crtc->state->mode_blob);
> > -
> > - state = to_imx_crtc_state(crtc->state);
> > - memset(state, 0, sizeof(*state));
> > - } else {
> > - state = kzalloc(sizeof(*state), GFP_KERNEL);
> > - if (!state)
> > - return;
> > - crtc->state = >base;
> > - }
> > + if (crtc->state)
> > + __drm_atomic_helper_crtc_destroy_state(crtc->state);
> >
> > - state->base.crtc = crtc;
> > + kfree(to_imx_crtc_state(crtc->state));
> > + crtc->state = NULL;
> > +
> > + state = kzalloc(sizeof(*state), GFP_KERNEL);
> > + if (state)
> > + __drm_atomic_helper_crtc_reset(crtc, >base);
> > }
> >
> > static struct drm_crtc_state *imx_drm_crtc_duplicate_state(struct drm_crtc
> > *crtc)
> > --
> > 2.26.2
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
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: success for series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on construction
== Series Details ==
Series: series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on
construction
URL : https://patchwork.freedesktop.org/series/79037/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8692 -> Patchwork_18065
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/index.html
Known issues
Here are the changes found in Patchwork_18065 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_linear_blits@basic:
- fi-tgl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-tgl-u2/igt@gem_linear_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-tgl-u2/igt@gem_linear_bl...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][5] -> [DMESG-WARN][6] ([i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][13] ([fdo#109271]) -> [DMESG-FAIL][14]
([i915#62])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8692/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18065/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8692 -> Patchwork_18065
CI-20190529: 20190529
CI_DRM_8692: e30abe29fd5407631a61d48f93bad5fdeba8080d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5720: f35053d4b6d7bbcf6505ef67a8bd56acc7fb2eb2 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18065: 6f377648e7f5e352bf1600ef1f8954ec04781765 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6f377648e7f5 drm/i915/gem: Pull execbuf dma resv under a single critical section
1375d1da0182 drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
db49ec7ea2ce drm/i915/gem:
