Re: [Intel-gfx] [PATCH] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
Am 27.07.20 um 23:30 schrieb Daniel Vetter:
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to bother, READ_ONCE is
equivalent. And avoids the locking issue.
v2: Also take into account tmz_surface boolean, plus just delete the
old code.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
DC-folks, I think this split out patch from my series here
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200707201229.472834-1-daniel.vetter%40ffwll.ch%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C8a4f5736682a4b5c943e08d832747ab1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637314823145521840&sdata=qd7Nrox62Lr%2FXWbJJFVskg9RYL4%2FoRVCFjR6rUDMA5E%3D&reserved=0
should be ready for review/merging. I fixed it up a bit so that it's not
just a gross hack :-)
Cheers, Daniel
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
1 file changed, 6 insertions(+), 13 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 21ec64fe5527..a20b62b1f2ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6959,20 +6959,13 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
DRM_ERROR("Waiting for fences timed out!");
/*
-* TODO This might fail and hence better not used, wait
-* explicitly on fences instead
-* and in general should be called for
-* blocking commit to as per framework helpers
+* We cannot reserve buffers here, which means the normal flag
+* access functions don't work. Paper over this with READ_ONCE,
+* but maybe the flags are invariant enough that not even that
+* would be needed.
*/
- r = amdgpu_bo_reserve(abo, true);
- if (unlikely(r != 0))
- DRM_ERROR("failed to reserve buffer before flip\n");
-
- amdgpu_bo_get_tiling_flags(abo, &tiling_flags);
-
- tmz_surface = amdgpu_bo_encrypted(abo);
-
- amdgpu_bo_unreserve(abo);
+ tiling_flags = READ_ONCE(abo->tiling_flags);
+ tmz_surface = READ_ONCE(abo->flags) &
AMDGPU_GEM_CREATE_ENCRYPTED;
Yeah, the abo->flags are mostly fixed after creation, especially the
encrypted flag can't change or we corrupt page table tables. So that
should work fine.
Anybody who picks this up feel free to add an Reviewed-by: Christian
König .
Regards,
Christian.
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
Hi Jose,
On Tue, Jul 28, 2020 at 01:47:56AM +, Souza, Jose wrote:
> Hi Nathan
>
> Are you planning to check this regressions and send another version with the
> fix?Or can I do it on top of your patch?
Unfortunately, I have had little time for kernel work (full time retail
worker in the middle of a pandemic plus full time student is a real fun
combination...). I would definitely appreciate a follow up fix if you
can provide one, since I would imagine it would be a pre-existing issue
since all my patch does is make the check in the icl_combo_phy_enabled
if block work as expected (when it does not appear to be working
before).
Cheers,
Nathan
> On Thu, 2020-07-16 at 05:06 +, Patchwork wrote:
> > Patch Details
> > Series: drm/i915/display: Ensure that ret is always initialized in
> > icl_combo_phy_verify_state
> > URL:https://patchwork.freedesktop.org/series/79536/
> > State: failure
> > Details:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/index.html
> > CI Bug Log - changes from CI_DRM_8753 -> Patchwork_18185
> > Summary
> > FAILURE
> >
> > Serious unknown changes coming with Patchwork_18185 absolutely need to be
> > verified manually.
> >
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_18185, 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_18185/index.html
> >
> > Possible new issues
> > Here are the unknown changes that may have been introduced in
> > Patchwork_18185:
> >
> > IGT changes
> > Possible regressions
> > igt@i915_pm_rpm@module-reload:
> > fi-tgl-y: PASS -> DMESG-WARN +4 similar issues
> > Suppressed
> > The following results come from untrusted machines, tests, or statuses.
> > They do not affect the overall result.
> >
> > igt@i915_pm_rpm@basic-pci-d3-state:
> >
> > {fi-tgl-dsi}: DMESG-WARN (i915#1982) -> DMESG-WARN
> > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
> >
> > {fi-tgl-dsi}: PASS -> DMESG-WARN +4 similar issues
> > Known issues
> > Here are the changes found in Patchwork_18185 that come from known issues:
> >
> > IGT changes
> > Issues hit
> > igt@gem_exec_suspend@basic-s0:
> >
> > fi-tgl-u2: PASS -> FAIL (i915#1888)
> > igt@kms_addfb_basic@bo-too-small:
> >
> > fi-tgl-y: PASS -> DMESG-WARN (i915#402) +1 similar issue
> > Possible fixes
> > igt@debugfs_test@read_all_entries:
> >
> > fi-bsw-nick: INCOMPLETE (i915#1250 / i915#1436) -> PASS
> > igt@gem_exec_store@basic:
> >
> > fi-tgl-y: DMESG-WARN (i915#402) -> PASS +2 similar issues
> > igt@i915_module_load@reload:
> >
> > fi-byt-j1900: DMESG-WARN (i915#1982) -> PASS
> >
> > fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92) -> PASS
> >
> > igt@i915_pm_rpm@basic-pci-d3-state:
> >
> > fi-bsw-kefka: DMESG-WARN (i915#1982) -> PASS
> > igt@i915_selftest@live@execlists:
> >
> > fi-kbl-r: INCOMPLETE (i915#794) -> PASS
> > igt@i915_selftest@live@gt_lrc:
> >
> > fi-tgl-u2: DMESG-FAIL (i915#1233) -> PASS
> > igt@kms_flip@basic-flip-vs-modeset@a-dsi1:
> >
> > {fi-tgl-dsi}: DMESG-WARN (i915#1982) -> PASS
> > igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
> >
> > fi-tgl-u2: DMESG-WARN (i915#402) -> PASS
> > Warnings
> > igt@gem_exec_suspend@basic-s0:
> >
> > fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92) -> DMESG-WARN (i915#1982 /
> > i915#62 / i915#92 / i915#95)
> > igt@kms_flip@basic-flip-vs-dpms@a-dp1:
> >
> > fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92 / i915#95) -> DMESG-WARN
> > (i915#62 / i915#92)
> > igt@kms_force_connector_basic@force-edid:
> >
> > fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92) -> DMESG-WARN (i915#62 /
> > i915#92 / i915#95) +4 similar issues
> > {name}: This element is suppressed. This means it is ignored when computing
> > the status of the difference (SUCCESS, WARNING, or FAILURE).
> >
> > Participating hosts (46 -> 40)
> > 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_8753 -> Patchwork_18185
> > CI-20190529: 20190529
> > CI_DRM_8753: 62f01b776240c4586b3cbbdbe6065d4473d45429 @
> > git://anongit.freedesktop.org/gfx-ci/linux
> > IGT_5737: c18a9c1083ce9344ff71ae405b9f2deaa82b6702 @
> > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> > Patchwork_18185: b0efac00fd8cdd3d7a3cc3140ba0df8bda56ebf3 @
> > git://anongit.freedesktop.org/gfx-ci/linux
> >
> > == Linux commits ==
> >
> > b0efac00fd8c drm/i915/display: Ensure that ret is always initialized in
> > icl_combo_phy_verify_state
> >
> > ___
> > 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] linux-next: manual merge of the drm tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_gem.c
between commit:
8490d6a7e0a0 ("drm: hold gem reference until object is no longer accessed")
from the drm-misc-fixes tree and commit:
be6ee102341b ("drm: remove _unlocked suffix in drm_gem_object_put_unlocked")
from the drm 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_gem.c
index ee2058ad482c,a57f5379fc08..
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@@ -901,9 -913,7 +909,9 @@@ drm_gem_open_ioctl(struct drm_device *d
args->handle = handle;
args->size = obj->size;
- return 0;
+err:
- drm_gem_object_put_unlocked(obj);
++ drm_gem_object_put(obj);
+ return ret;
}
/**
pgpfU11_Mj8Be.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next
On 2020.07.27 16:39:58 +, Vivi, Rodrigo wrote: > > > > On Jul 21, 2020, at 5:42 PM, Zhenyu Wang wrote: > > > > On 2020.07.21 14:04:41 +0300, Joonas Lahtinen wrote: > >> Quoting Zhenyu Wang (2020-07-20 11:05:41) > >>> > >>> Hi, > >>> > >>> Sorry that this might be a bit late as last week our QA people were > >>> busy on something else..So this is gvt changes queued for 5.9 which is > >>> to improve guest suspend/resume with proper PCI PM state tracking for > >>> resource handling, e.g ppgtt. Hopefully this could still be in queue > >>> for 5.9. > >> > >> Is this a regression fix to a problem introduced by previous > >> gvt-next PR targeting 5.9? > >> > >> Or is it an incremental improvement over 5.8? > >> > > > > Second case. This is incremental improvement. Guest suspend/resume > > did work somehow before but has bad performance and possible failure > > with some guest versions. > > I'm afraid Jani already sent the last pull request towards 5.9. > So if there are fixes inside this pull request this should move to the > -next-fixes > > and the remaining improvements to another 5.10 pull request > Got it. I'll split out those fixes for another pull. Thanks signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
Hi Nathan
Are you planning to check this regressions and send another version with the
fix?Or can I do it on top of your patch?
On Thu, 2020-07-16 at 05:06 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/display: Ensure that ret is always initialized in
> icl_combo_phy_verify_state
> URL: https://patchwork.freedesktop.org/series/79536/
> State:failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/index.html
> CI Bug Log - changes from CI_DRM_8753 -> Patchwork_18185
> Summary
> FAILURE
>
> Serious unknown changes coming with Patchwork_18185 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_18185, 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_18185/index.html
>
> Possible new issues
> Here are the unknown changes that may have been introduced in Patchwork_18185:
>
> IGT changes
> Possible regressions
> igt@i915_pm_rpm@module-reload:
> fi-tgl-y: PASS -> DMESG-WARN +4 similar issues
> Suppressed
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> igt@i915_pm_rpm@basic-pci-d3-state:
>
> {fi-tgl-dsi}: DMESG-WARN (i915#1982) -> DMESG-WARN
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
>
> {fi-tgl-dsi}: PASS -> DMESG-WARN +4 similar issues
> Known issues
> Here are the changes found in Patchwork_18185 that come from known issues:
>
> IGT changes
> Issues hit
> igt@gem_exec_suspend@basic-s0:
>
> fi-tgl-u2: PASS -> FAIL (i915#1888)
> igt@kms_addfb_basic@bo-too-small:
>
> fi-tgl-y: PASS -> DMESG-WARN (i915#402) +1 similar issue
> Possible fixes
> igt@debugfs_test@read_all_entries:
>
> fi-bsw-nick: INCOMPLETE (i915#1250 / i915#1436) -> PASS
> igt@gem_exec_store@basic:
>
> fi-tgl-y: DMESG-WARN (i915#402) -> PASS +2 similar issues
> igt@i915_module_load@reload:
>
> fi-byt-j1900: DMESG-WARN (i915#1982) -> PASS
>
> fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92) -> PASS
>
> igt@i915_pm_rpm@basic-pci-d3-state:
>
> fi-bsw-kefka: DMESG-WARN (i915#1982) -> PASS
> igt@i915_selftest@live@execlists:
>
> fi-kbl-r: INCOMPLETE (i915#794) -> PASS
> igt@i915_selftest@live@gt_lrc:
>
> fi-tgl-u2: DMESG-FAIL (i915#1233) -> PASS
> igt@kms_flip@basic-flip-vs-modeset@a-dsi1:
>
> {fi-tgl-dsi}: DMESG-WARN (i915#1982) -> PASS
> igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
>
> fi-tgl-u2: DMESG-WARN (i915#402) -> PASS
> Warnings
> igt@gem_exec_suspend@basic-s0:
>
> fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92) -> DMESG-WARN (i915#1982 /
> i915#62 / i915#92 / i915#95)
> igt@kms_flip@basic-flip-vs-dpms@a-dp1:
>
> fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92 / i915#95) -> DMESG-WARN (i915#62
> / i915#92)
> igt@kms_force_connector_basic@force-edid:
>
> fi-kbl-x1275: DMESG-WARN (i915#62 / i915#92) -> DMESG-WARN (i915#62 / i915#92
> / i915#95) +4 similar issues
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> Participating hosts (46 -> 40)
> 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_8753 -> Patchwork_18185
> CI-20190529: 20190529
> CI_DRM_8753: 62f01b776240c4586b3cbbdbe6065d4473d45429 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_5737: c18a9c1083ce9344ff71ae405b9f2deaa82b6702 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_18185: b0efac00fd8cdd3d7a3cc3140ba0df8bda56ebf3 @
> git://anongit.freedesktop.org/gfx-ci/linux
>
> == Linux commits ==
>
> b0efac00fd8c drm/i915/display: Ensure that ret is always initialized in
> icl_combo_phy_verify_state
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
>
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement WA 14011294188 (rev2)
On Mon, 2020-07-27 at 20:51 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Implement WA 14011294188 (rev2)
> URL: https://patchwork.freedesktop.org/series/79825/
> State:success
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/index.html
> CI Bug Log - changes from CI_DRM_8797_full -> Patchwork_18245_full
> Summary
> SUCCESS
>
> No regressions found.
Thanks for the review Matt.Pushed to dinq.
>
> Possible new issues
> Here are the unknown changes that may have been introduced in
> Patchwork_18245_full:
>
> Piglit changes
> Possible regressions
> spec@glsl-4.20@execution@vs_in@vs-input-double_dvec3-position-float_mat4x2_array3
> (NEW):
>
> {pig-icl-1065g7}: NOTRUN -> INCOMPLETE +5 similar issues
> spec@glsl-4.20@execution@vs_in@vs-input-position-int_int-double_dmat3x4_array2
> (NEW):
>
> {pig-icl-1065g7}: NOTRUN -> CRASH +1 similar issue
> New tests
> New tests have been introduced between CI_DRM_8797_full and
> Patchwork_18245_full:
>
> New Piglit tests (8)
> spec@glsl-4.20@execution@vs_in@vs-input-double_dmat3-position-double_dmat2x4_array2:
>
> Statuses : 1 crash(s)
> Exec time: [0.86] s
> spec@glsl-4.20@execution@vs_in@vs-input-double_dmat3x2-position-float_vec4_array3:
>
> Statuses : 1 incomplete(s)
> Exec time: [0.0] s
> spec@glsl-4.20@execution@vs_in@vs-input-double_dvec3-position-float_mat4x2_array3:
>
> Statuses : 1 incomplete(s)
> Exec time: [0.0] s
> spec@glsl-4.20@execution@vs_in@vs-input-float_mat2x3_array3-position-double_dmat4x3_array2:
>
> Statuses : 1 incomplete(s)
> Exec time: [0.0] s
> spec@glsl-4.20@execution@vs_in@vs-input-float_mat2x4_array3-position-double_dvec4_array2:
>
> Statuses : 1 incomplete(s)
> Exec time: [0.0] s
> spec@glsl-4.20@execution@vs_in@vs-input-float_vec2-double_dmat4_array2-position:
>
> Statuses : 1 incomplete(s)
> Exec time: [0.0] s
> spec@glsl-4.20@execution@vs_in@vs-input-position-double_dmat2x4_array5-float_vec3_array3:
>
> Statuses : 1 incomplete(s)
> Exec time: [0.0] s
> spec@glsl-4.20@execution@vs_in@vs-input-position-int_int-double_dmat3x4_array2:
>
> Statuses : 1 crash(s)
> Exec time: [0.87] s
> Known issues
> Here are the changes found in Patchwork_18245_full that come from known
> issues:
>
> IGT changes
> Issues hit
> igt@gem_exec_whisper@basic-queues:
>
> shard-iclb: PASS -> DMESG-WARN (i915#1982)
> igt@kms_busy@basic-flip-pipe-c:
>
> shard-skl: PASS -> DMESG-WARN (i915#1982) +11 similar issues
> igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen:
>
> shard-skl: PASS -> FAIL (i915#54)
> igt@kms_cursor_legacy@pipe-b-torture-bo:
>
> shard-iclb: PASS -> DMESG-WARN (i915#128)
> igt@kms_draw_crc@draw-method-rgb565-blt-untiled:
>
> shard-skl: PASS -> FAIL (i915#52 / i915#54)
> igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
>
> shard-kbl: PASS -> DMESG-WARN (i915#180) +12 similar issues
> igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
>
> shard-skl: PASS -> DMESG-FAIL (i915#1982)
> igt@kms_frontbuffer_tracking@fbc-badstride:
>
> shard-glk: PASS -> DMESG-WARN (i915#1982)
> igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt:
>
> shard-tglb: PASS -> DMESG-WARN (i915#1982) +2 similar issues
> igt@kms_hdr@bpc-switch-suspend:
>
> shard-skl: PASS -> FAIL (i915#1188)
> igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
>
> shard-tglb: PASS -> INCOMPLETE (i915#456)
> igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
>
> shard-skl: PASS -> FAIL (fdo#108145 / i915#265)
> igt@kms_psr@psr2_sprite_mmap_cpu:
>
> shard-iclb: PASS -> SKIP (fdo#109441) +1 similar issue
> igt@kms_setmode@basic:
>
> shard-apl: PASS -> FAIL (i915#1635 / i915#31)
>
> shard-hsw: PASS -> FAIL (i915#31)
>
> Possible fixes
> igt@gem_ctx_isolation@preservation-s3@rcs0:
>
> shard-skl: INCOMPLETE (i915#198) -> PASS
> igt@gem_eio@in-flight-suspend:
>
> shard-skl: DMESG-WARN (i915#1982) -> PASS +5 similar issues
> igt@gem_exec_whisper@basic-forked:
>
> shard-glk: DMESG-WARN (i915#118 / i915#95) -> PASS
> igt@gem_huc_copy@huc-copy:
>
> shard-tglb: SKIP (i915#2190) -> PASS
> igt@gem_linear_blits@normal:
>
> shard-tglb: DMESG-WARN (i915#402) -> PASS
> igt@kms_atomic_interruptible@universal-setplane-primary:
>
> shard-apl: DMESG-WARN (i915#1635 / i915#62) -> PASS +7 similar issues
> igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
>
> shard-glk: FAIL (i915#72) -> PASS
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
>
> shard-tglb: DMESG-WARN (i915#1982) -> PASS
> igt@kms_hdr@bpc-switch:
>
> shard-skl: FAIL (i915#1188) -> PASS
> igt@kms_hdr@bpc-switch-suspend:
>
> shard-kbl: DMESG-WARN (i915#180) -> PASS +6 similar issues
> igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
>
> shard-skl: FAIL (fdo#108145 / i915#265) -> PASS +1 similar issue
> igt@kms_psr@psr2_cursor_plane_move:
>
> shard-iclb: SKIP (fdo#109441) -> PASS +1 similar issue
> igt@kms_vblank@pipe-c-wait-busy-hang:
>
> shard-apl: DMESG-WARN (i915#1635 / i915#1982) -> PASS +1 similar
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] vga-switcheroo: add new "immediate" switch event type
== Series Details == Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch event type URL : https://patchwork.freedesktop.org/series/79940/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8799_full -> Patchwork_18247_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18247_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18247_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_18247_full: ### IGT changes ### Possible regressions * igt@gem_exec_balancer@bonded-early: - shard-tglb: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-tglb1/igt@gem_exec_balan...@bonded-early.html ### Piglit changes ### Possible regressions * spec@glsl-1.50@execution@built-in-functions@gs-op-eq-bvec4-bvec4 (NEW): - pig-snb-2600: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/pig-snb-2600/spec@glsl-1.50@execution@built-in-functi...@gs-op-eq-bvec4-bvec4.html New tests - New tests have been introduced between CI_DRM_8799_full and Patchwork_18247_full: ### New Piglit tests (1) ### * spec@glsl-1.50@execution@built-in-functions@gs-op-eq-bvec4-bvec4: - Statuses : 1 fail(s) - Exec time: [0.09] s Known issues Here are the changes found in Patchwork_18247_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +6 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-kbl4/igt@gem_ctx_isolation@preservation...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-kbl2/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#1528]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-skl6/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_exec_whisper@basic-forked: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-glk7/igt@gem_exec_whis...@basic-forked.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-glk8/igt@gem_exec_whis...@basic-forked.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][9] -> [SKIP][10] ([i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-tglb5/igt@gem_huc_c...@huc-copy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_userptr_blits@invalid-mmap-offset-unsync@wc: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([i915#2119]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-iclb2/igt@gem_userptr_blits@invalid-mmap-offset-uns...@wc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-iclb5/igt@gem_userptr_blits@invalid-mmap-offset-uns...@wc.html * igt@i915_selftest@live@gt_heartbeat: - shard-iclb: [PASS][13] -> [DMESG-FAIL][14] ([i915#541]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-iclb4/igt@i915_selftest@live@gt_heartbeat.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-iclb4/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_big_fb@y-tiled-16bpp-rotate-0: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +13 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl4/igt@kms_big...@y-tiled-16bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-skl8/igt@kms_big...@y-tiled-16bpp-rotate-0.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-render: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-tglb3/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-render.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-s
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
== Series Details == Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail URL : https://patchwork.freedesktop.org/series/79937/ State : success == Summary == CI Bug Log - changes from CI_DRM_8799_full -> Patchwork_18246_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18246_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@vcs0: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html * igt@gem_mmap_gtt@fault-concurrent: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#2165]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl10/igt@gem_mmap_...@fault-concurrent.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-skl4/igt@gem_mmap_...@fault-concurrent.html * igt@kms_big_fb@yf-tiled-32bpp-rotate-270: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-apl1/igt@kms_big...@yf-tiled-32bpp-rotate-270.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-apl1/igt@kms_big...@yf-tiled-32bpp-rotate-270.html * igt@kms_color@pipe-b-ctm-negative: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +10 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl1/igt@kms_co...@pipe-b-ctm-negative.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-skl5/igt@kms_co...@pipe-b-ctm-negative.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#79]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl9/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-skl10/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-kbl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#198]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl7/igt@kms_flip@flip-vs-susp...@a-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-skl9/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip_tiling@flip-yf-tiled: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-kbl1/igt@kms_flip_til...@flip-yf-tiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-kbl7/igt@kms_flip_til...@flip-yf-tiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-msflip-blt: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-msflip-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-msflip-blt.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-skl4/igt@kms_...@bpc-switch-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-skl9/igt@kms_...@bpc-switch-dpms.html * igt@kms_psr@psr2_primary_blt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-iclb2/igt@kms_psr@psr2_primary_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-iclb8/igt@kms_psr@psr2_primary_blt.html * igt@perf_pmu@semaphore-busy@rcs0: - shard-kbl: [PASS][23] -> [FAIL][24] ([i915#1820]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/shard-kbl2/igt@perf_pmu@semaphore-b...@rcs0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/shard-kbl2/igt@perf_pmu@semaphore-b...@rcs0.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-skl: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26] +10 similar issues [
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] vga-switcheroo: add new "immediate" switch event type
== Series Details ==
Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch
event type
URL : https://patchwork.freedesktop.org/series/79940/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8799 -> Patchwork_18247
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/index.html
Known issues
Here are the changes found in Patchwork_18247 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_8799/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-y/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][7] -> [DMESG-FAIL][8] ([i915#1748])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Possible fixes
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-dsi/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][15] ([i915#2203]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][19] ([i915#402]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][21] ([fdo#109271]) -> [DMESG-FAIL][22]
([i915#62] / [i915#95])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18247/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_pipe_crc_basic@read-
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] vga-switcheroo: add new "immediate" switch event type
== Series Details == Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch event type URL : https://patchwork.freedesktop.org/series/79940/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] vga-switcheroo: add new "immediate" switch event type
== Series Details == Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch event type URL : https://patchwork.freedesktop.org/series/79940/ State : warning == Summary == $ dim checkpatch origin/drm-tip c641759bc9fc vga-switcheroo: add new "immediate" switch event type bfff6b1409e8 vga-switcheroo: Add a way to test for the active client ff047b26770b vga-switcheroo: notify clients of pending/completed switch events 11d6a92ef9e8 i915: implement vga-switcheroo reprobe() callback 84cd1d3bc501 i915: fail atomic commit when muxed away -:31: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #31: FILE: drivers/gpu/drm/i915/display/intel_display.c:15736: + drm_dbg_atomic(&dev_priv->drm, + "Atomic commit attempted while muxed away.\n"); total: 0 errors, 0 warnings, 1 checks, 19 lines checked 967055634357 i915: bail out of eDP link training while mux-switched away -:37: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #37: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:400: + drm_dbg_kms(&dp_to_i915(intel_dp)->drm, + "eDP link training not allowed when muxed away."); total: 0 errors, 0 warnings, 1 checks, 21 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/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
== Series Details ==
Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
URL : https://patchwork.freedesktop.org/series/79937/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8799 -> Patchwork_18246
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/index.html
Known issues
Here are the changes found in Patchwork_18246 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +2 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-byt-j1900/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@prime_vgem@basic-write:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-y/igt@prime_v...@basic-write.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-tgl-y/igt@prime_v...@basic-write.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-dsi/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-tgl-dsi/igt@i915_module_l...@reload.html
- fi-bxt-dsi: [DMESG-WARN][13] ([i915#1635] / [i915#1982]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-bxt-dsi/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-bxt-dsi/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@execlists:
- fi-cfl-8700k: [INCOMPLETE][15] ([i915#2089]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][19] ([i915#402]) -> [DMESG-WARN][20]
([i915#1982])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-tgl-u2/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][21] ([fdo#109271]) -> [DMESG-FAIL][22]
([i915#62])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +8 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8799/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18246/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
== Series Details == Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail URL : https://patchwork.freedesktop.org/series/79937/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ 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/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
== Series Details == Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail URL : https://patchwork.freedesktop.org/series/79937/ State : warning == Summary == $ dim checkpatch origin/drm-tip be92e429f9aa drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail -:60: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 26 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] vga-switcheroo: notify clients of pending/completed switch events
Add a new vga-switcheroo client callback to allow clients to register
for receiving notifications when a mux switch is pending, completed,
or failed. This allows individual client drivers to prepare for or
respond to mux switches to and from the registered client device.
Signed-off-by: Daniel Dadap
---
drivers/gpu/vga/vga_switcheroo.c | 29 -
include/linux/vga_switcheroo.h | 18 ++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index a4fc78c4bf4f..6392dc92696b 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -756,14 +756,41 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client,
if (new_client->fb_info)
fbcon_remap_all(new_client->fb_info);
+ if (active->ops->notify)
+ active->ops->notify(active->pdev,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_AWAY,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_PENDING);
+ if (new_client->ops->notify)
+ new_client->ops->notify(new_client->pdev,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_TO,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_PENDING);
+
active->switched = false;
mutex_lock(&vgasr_priv.mux_hw_lock);
ret = vgasr_priv.handler->switchto(new_client->id);
mutex_unlock(&vgasr_priv.mux_hw_lock);
- if (ret)
+ if (ret) {
+ if (active->ops->notify)
+ active->ops->notify(active->pdev,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_AWAY,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_FAILED);
+ if (new_client->ops->notify)
+ new_client->ops->notify(new_client->pdev,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_TO,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_FAILED);
return ret;
+ }
new_client->switched = true;
+ if (active->ops->notify)
+ active->ops->notify(active->pdev,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_AWAY,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_COMPLETE);
+ if (new_client->ops->notify)
+ new_client->ops->notify(new_client->pdev,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_TO,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_COMPLETE);
+
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index 63e6d6e5786e..2dc8ebc84fd4 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -90,6 +90,17 @@ enum vga_switcheroo_client_id {
VGA_SWITCHEROO_MAX_CLIENTS,
};
+enum vga_switcheroo_notify_direction {
+ VGA_SWITCHEROO_NOTIFY_SWITCH_TO,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_AWAY,
+};
+
+enum vga_switcheroo_notify_action {
+ VGA_SWITCHEROO_NOTIFY_SWITCH_PENDING,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_COMPLETE,
+ VGA_SWITCHEROO_NOTIFY_SWITCH_FAILED,
+};
+
/**
* struct vga_switcheroo_handler - handler callbacks
* @init: initialize handler.
@@ -134,6 +145,10 @@ struct vga_switcheroo_handler {
* Mandatory. The client should return false if a user space process
* has one of its device files open
* @gpu_bound: notify the client id to audio client when the GPU is bound.
+ * @notify: notify clients of pending and completed switches
+ * Optional. This gets called for both active and inactive clients,
+ * before a switch begins, and after a switch successfully completes
+ * or fails.
*
* Client callbacks. A client can be either a GPU or an audio device on a GPU.
* The @set_gpu_state and @can_switch methods are mandatory, @reprobe may be
@@ -145,6 +160,9 @@ struct vga_switcheroo_client_ops {
void (*reprobe)(struct pci_dev *dev);
bool (*can_switch)(struct pci_dev *dev);
void (*gpu_bound)(struct pci_dev *dev, enum vga_switcheroo_client_id);
+ void (*notify)(struct pci_dev *dev,
+ enum vga_switcheroo_notify_direction,
+ enum vga_switcheroo_notify_action);
};
#if defined(CONFIG_VGA_SWITCHEROO)
--
2.18.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] vga-switcheroo: add new "immediate" switch event type
vga-switcheroo supports the following types of mux switch events:
* standard: checks the clients' can_switch() callbacks and switches
the mux if the client drivers report that they are prepared for a
switch. Also uses client and handler callbacks to manage power on
the GPUs and reprobe display outputs.
* deferred: registers the intent to perform a mux switch and defers
it until the client drivers no longer have any active modesetting
clients. Performs the equivalent of a standard switch when clients
are ready.
* mux-only: switches the mux immediately without testing can_switch
first and without calling any of the client or handler callbacks
for power management and reprobing.
In order to support additional use cases involving dynamic switching
of display muxes, add a new type of "immediate" switch event which
skips the can_switch test and power management hooks, but still calls
the reprobe hook. This switch event type uses 'I' as a prefix for its
commands, similar to the existing 'D' pefix for the deferred commands
and 'M' for the mux-only commands.
Signed-off-by: Daniel Dadap
---
drivers/gpu/vga/vga_switcheroo.c | 86 +---
1 file changed, 58 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 087304b1a5d7..cf3c7024dafa 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -631,16 +631,23 @@ EXPORT_SYMBOL(vga_switcheroo_unlock_ddc);
* * DDIS: Delayed switch to the discrete graphics device.
* * MIGD: Mux-only switch to the integrated graphics device.
* Does not remap console or change the power state of either gpu.
+ * Does not call into any client-supplied callbacks, e.g. reprobe.
* If the integrated GPU is currently off, the screen will turn black.
* If it is on, the screen will show whatever happens to be in VRAM.
* Either way, the user has to blindly enter the command to switch back.
* * MDIS: Mux-only switch to the discrete graphics device.
+ * * IIGD: Immediate switch to the integrated graphics device.
+ * Does not test for active user space processes utilizing the device
+ * files of the GPU or audio device. Does not change the power state of
+ * either gpu. The console is remapped and client-provided callbacks
+ * such as reprobe are called.
+ * * IDIS: Immediate switch to the discrete graphics device.
*
* For GPUs whose power state is controlled by the driver's runtime pm,
* the ON and OFF commands are a no-op (see next section).
*
- * For muxless machines, the IGD/DIS, DIGD/DDIS and MIGD/MDIS commands
- * should not be used.
+ * For muxless machines, the IGD/DIS, DIGD/DDIS, MIGD/MDIS and IIGD/IDIS
+ * commands should not be used.
*/
static int vga_switcheroo_show(struct seq_file *m, void *v)
@@ -704,7 +711,8 @@ static void set_audio_state(enum vga_switcheroo_client_id
id,
}
/* stage one happens before delay */
-static int vga_switchto_stage1(struct vga_switcheroo_client *new_client)
+static int vga_switchto_stage1(struct vga_switcheroo_client *new_client,
+ bool power_control)
{
struct vga_switcheroo_client *active;
@@ -712,7 +720,8 @@ static int vga_switchto_stage1(struct vga_switcheroo_client
*new_client)
if (!active)
return 0;
- if (vga_switcheroo_pwr_state(new_client) == VGA_SWITCHEROO_OFF)
+ if (power_control &&
+ vga_switcheroo_pwr_state(new_client) == VGA_SWITCHEROO_OFF)
vga_switchon(new_client);
vga_set_default_device(new_client->pdev);
@@ -720,7 +729,8 @@ static int vga_switchto_stage1(struct vga_switcheroo_client
*new_client)
}
/* post delay */
-static int vga_switchto_stage2(struct vga_switcheroo_client *new_client)
+static int vga_switchto_stage2(struct vga_switcheroo_client *new_client,
+ bool power_control)
{
int ret;
struct vga_switcheroo_client *active;
@@ -747,7 +757,8 @@ static int vga_switchto_stage2(struct vga_switcheroo_client
*new_client)
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);
- if (vga_switcheroo_pwr_state(active) == VGA_SWITCHEROO_ON)
+ if (power_control &&
+ vga_switcheroo_pwr_state(active) == VGA_SWITCHEROO_ON)
vga_switchoff(active);
/* let HDA controller autoresume if GPU uses driver power control */
@@ -779,6 +790,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const char
__user *ubuf,
int ret;
bool delay = false, can_switch;
bool just_mux = false;
+ bool immediate_switch = false;
enum vga_switcheroo_client_id client_id = VGA_SWITCHEROO_UNKNOWN_ID;
struct vga_switcheroo_client *client = NULL;
@@ -822,30 +834,48 @@ vga_switcheroo_debugfs_write(struct file *filp, const
char __user *ubuf,
goto out;
}
- /* request a dela
[Intel-gfx] [PATCH 5/6] i915: fail atomic commit when muxed away
Attempting to commit a modeset while mux-switched away can cause
problems due to DisplayPort links being unavailable while they are
physically disconnected. In order to avoid this, bail out of atomic
commit early if attempted while a display mux is switched away.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 346846609f45..4ad799e4b024 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -15736,6 +15737,12 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
+ if (!vga_switcheroo_is_client_active(to_pci_dev(dev->dev))) {
+ drm_dbg_atomic(&dev_priv->drm,
+ "Atomic commit attempted while muxed away.\n");
+ return -EINVAL;
+ }
+
state->wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
drm_atomic_state_get(&state->base);
--
2.18.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] vga-switcheroo: Add a way to test for the active client
vga-switcheroo clients may wish to know whether they are currently
active, i.e., whether the mux is currently switched to the client
in question. Add an in-kernel API to test whether a vga-switcheroo
client, as identified by PCI device, is actively switched.
Signed-off-by: Daniel Dadap
---
drivers/gpu/vga/vga_switcheroo.c | 38 +++-
include/linux/vga_switcheroo.h | 2 ++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index cf3c7024dafa..a4fc78c4bf4f 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -99,7 +99,13 @@
* @id: client identifier. Determining the id requires the handler,
* so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
* and later given their true id in vga_switcheroo_enable()
- * @active: whether the outputs are currently switched to this client
+ * @active: whether the client is currently active: this is unset for the
+ * currently active client before preparing for a mux switch, and set
+ * for the newly active client after completing all post-switch actions.
+ * @switched: whether the outputs are physically switched to the client:
+ * this is unset for the currently switched client immediately before
+ * switching the mux, and set for the newly switched client immediately
+ * after switching the mux.
* @driver_power_control: whether power state is controlled by the driver's
* runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
* interface is a no-op so as not to interfere with runtime pm
@@ -117,6 +123,7 @@ struct vga_switcheroo_client {
const struct vga_switcheroo_client_ops *ops;
enum vga_switcheroo_client_id id;
bool active;
+ bool switched;
bool driver_power_control;
struct list_head list;
struct pci_dev *vga_dev;
@@ -306,6 +313,7 @@ static int register_client(struct pci_dev *pdev,
client->ops = ops;
client->id = id;
client->active = active;
+ client->switched = active;
client->driver_power_control = driver_power_control;
client->vga_dev = vga_dev;
@@ -748,11 +756,13 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client,
if (new_client->fb_info)
fbcon_remap_all(new_client->fb_info);
+ active->switched = false;
mutex_lock(&vgasr_priv.mux_hw_lock);
ret = vgasr_priv.handler->switchto(new_client->id);
mutex_unlock(&vgasr_priv.mux_hw_lock);
if (ret)
return ret;
+ new_client->switched = true;
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);
@@ -,3 +1121,29 @@ void vga_switcheroo_fini_domain_pm_ops(struct device
*dev)
dev_pm_domain_set(dev, NULL);
}
EXPORT_SYMBOL(vga_switcheroo_fini_domain_pm_ops);
+
+/**
+ * vga_switcheroo_is_client_active() - test if a device is the active client
+ * @pdev: vga client device
+ *
+ * Check whether the mux is switched to the switcheroo client associated with
+ * the given PCI device. Assumes that mux is always switched to the device in
+ * question when switcheroo is inactive, and that the mux is switched away if
+ * no matching client is registered.
+ */
+bool vga_switcheroo_is_client_active(struct pci_dev *pdev)
+{
+ if (vgasr_priv.active) {
+ struct vga_switcheroo_client *client;
+
+ client = find_client_from_pci(&vgasr_priv.clients, pdev);
+
+ if (client)
+ return client->switched;
+ else
+ return false;
+ } else {
+ return true;
+ }
+}
+EXPORT_SYMBOL(vga_switcheroo_is_client_active);
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index 7e6ac0114d55..63e6d6e5786e 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -173,6 +173,7 @@ enum vga_switcheroo_state
vga_switcheroo_get_client_state(struct pci_dev *dev);
int vga_switcheroo_init_domain_pm_ops(struct device *dev, struct dev_pm_domain
*domain);
void vga_switcheroo_fini_domain_pm_ops(struct device *dev);
+bool vga_switcheroo_is_client_active(struct pci_dev *pdev);
#else
static inline void vga_switcheroo_unregister_client(struct pci_dev *dev) {}
@@ -194,6 +195,7 @@ static inline enum vga_switcheroo_state
vga_switcheroo_get_client_state(struct p
static inline int vga_switcheroo_init_domain_pm_ops(struct device *dev, struct
dev_pm_domain *domain) { return -EINVAL; }
static inline void vga_switcheroo_fini_domain_pm_ops(struct device *dev) {}
+static inline bool vga_switcheroo_is_client_active(struct pci_dev *pdev) {
return true; }
#endif
#endif /* _LINUX_VGA_SWITCHEROO_H_ */
--
2.18.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.f
[Intel-gfx] [PATCH 6/6] i915: bail out of eDP link training while mux-switched away
It is not possible to train a Displayport link while the lanes are
physically disconnected by a display mux. In order to prevent problems
associated with attempting to train a disconnected link, abort eDP
link training if the i915 GPU is not an active vga-switcheroo client.
This short circuit is eDP-specific, as normal DP (e.g. for external
displays) should be able to detect that the link is not physically
connected, while eDP is usually assumed to be always connected.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index a7defb37ab00..a1c61db8a228 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -24,6 +24,7 @@
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_dp_link_training.h"
+#include "linux/vga_switcheroo.h"
static void
intel_dp_dump_link_status(const u8 link_status[DP_LINK_STATUS_SIZE])
@@ -371,6 +372,14 @@ void
intel_dp_start_link_train(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct device *dev = dp_to_dig_port(intel_dp)->base.base.dev->dev;
+
+ if (intel_dp_is_edp(intel_dp) &&
+ !vga_switcheroo_is_client_active(to_pci_dev(dev))) {
+ drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
+ "eDP link training not allowed when muxed away.");
+ return;
+ }
if (!intel_dp_link_training_clock_recovery(intel_dp))
goto failure_handling;
--
2.18.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] i915: implement vga-switcheroo reprobe() callback
Add a vga-switcheroo callback for reprobing displays. Use this new
callback to retrain the link on all DP encoders after a mux switch.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/i915/i915_switcheroo.c | 27 +-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_switcheroo.c
b/drivers/gpu/drm/i915/i915_switcheroo.c
index ed69b5d4a375..fa388de03cf6 100644
--- a/drivers/gpu/drm/i915/i915_switcheroo.c
+++ b/drivers/gpu/drm/i915/i915_switcheroo.c
@@ -7,6 +7,8 @@
#include "i915_drv.h"
#include "i915_switcheroo.h"
+#include "display/intel_display_types.h"
+#include "display/intel_dp.h"
static void i915_switcheroo_set_state(struct pci_dev *pdev,
enum vga_switcheroo_state state)
@@ -46,9 +48,32 @@ static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
return i915 && atomic_read(&i915->drm.open_count) == 0;
}
+static void i915_switcheroo_reprobe(struct pci_dev *pdev)
+{
+ struct drm_i915_private *i915 = pdev_to_i915(pdev);
+ struct intel_encoder *encoder;
+
+ for_each_intel_dp(&i915->drm, encoder) {
+ int ret = -EDEADLK;
+ struct drm_modeset_acquire_ctx ctx;
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+ while (ret == -EDEADLK) {
+ ret = intel_dp_retrain_link(encoder, &ctx);
+
+ if (ret == -EDEADLK)
+ drm_modeset_backoff(&ctx);
+ }
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+ }
+}
+
static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
.set_gpu_state = i915_switcheroo_set_state,
- .reprobe = NULL,
+ .reprobe = i915_switcheroo_reprobe,
.can_switch = i915_switcheroo_can_switch,
};
--
2.18.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] vga-switcheroo: initial dynamic mux switch support
Changes to allow vga-switcheroo to switch the mux while modesetting clients remain active. There is existing support for switching the mux without checking can_switch; however, this support also does not reprobe after the mux switch is complete. This patch series adds a new type of switch event which switches immediately while still calling client driver callbacks, and updates the i915 DRM-KMS driver to reprobe eDP outputs after switching the mux to an i915-driven GPU, and to avoid using eDP links (which i915 always assumes to be connected) while the mux is switched away. Daniel Dadap (6): vga-switcheroo: add new "immediate" switch event type vga-switcheroo: Add a way to test for the active client vga-switcheroo: notify clients of pending/completed switch events i915: implement vga-switcheroo reprobe() callback i915: fail atomic commit when muxed away i915: bail out of eDP link training while mux-switched away drivers/gpu/drm/i915/display/intel_display.c | 7 + .../drm/i915/display/intel_dp_link_training.c | 9 ++ drivers/gpu/drm/i915/i915_switcheroo.c| 27 +++- drivers/gpu/vga/vga_switcheroo.c | 153 ++ include/linux/vga_switcheroo.h| 20 +++ 5 files changed, 185 insertions(+), 31 deletions(-) -- 2.18.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler
On Mon, Jul 27, 2020 at 2:27 PM Michel Dänzer wrote:
>
> On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
> > Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 1fa67700d8f4..95953b393941 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
> >> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
> >> }
> >>
> >> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
> >> +{
> >> +struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> >> +enum pipe pipe = to_intel_crtc(crtc)->pipe;
> >> +
> >> +return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
> >> +}
> >> +
> >> u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
> >> {
> >> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> >> enum pipe pipe = to_intel_crtc(crtc)->pipe;
> >>
> >> +if (crtc->state->async_flip)
> >> +return g4x_get_flip_counter(crtc);
> >> +
> >> return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
> >
> > I don't understand the intention behind this, can you please clarify?
> > This goes back to my reply of the cover letter. It seems that here
> > we're going to alternate between two different counters in our vblank
> > count. So if user space alternates between sometimes using async flips
> > and sometimes using normal flip it's going to get some very weird
> > deltas, isn't it? At least this is what I remember from when I played
> > with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
> > using async flips.
>
> This definitely looks wrong. The counter value returned by the
> get_vblank_counter hook is supposed to increment when a vertical blank
> period occurs; page flips are not supposed to affect this in any way.
Also you just flat out can't access crtc->state from interrupt
context. Anything you need in there needs to be protected by the right
irq-type spin_lock, updates correctly synchronized against both the
interrupt handler and atomic updates, and data copied over, not
pointers. Otherwise just crash&burn.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to bother, READ_ONCE is
equivalent. And avoids the locking issue.
v2: Also take into account tmz_surface boolean, plus just delete the
old code.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
DC-folks, I think this split out patch from my series here
https://lore.kernel.org/dri-devel/20200707201229.472834-1-daniel.vet...@ffwll.ch/
should be ready for review/merging. I fixed it up a bit so that it's not
just a gross hack :-)
Cheers, Daniel
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
1 file changed, 6 insertions(+), 13 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 21ec64fe5527..a20b62b1f2ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6959,20 +6959,13 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
DRM_ERROR("Waiting for fences timed out!");
/*
-* TODO This might fail and hence better not used, wait
-* explicitly on fences instead
-* and in general should be called for
-* blocking commit to as per framework helpers
+* We cannot reserve buffers here, which means the normal flag
+* access functions don't work. Paper over this with READ_ONCE,
+* but maybe the flags are invariant enough that not even that
+* would be needed.
*/
- r = amdgpu_bo_reserve(abo, true);
- if (unlikely(r != 0))
- DRM_ERROR("failed to reserve buffer before flip\n");
-
- amdgpu_bo_get_tiling_flags(abo, &tiling_flags);
-
- tmz_surface = amdgpu_bo_encrypted(abo);
-
- amdgpu_bo_unreserve(abo);
+ tiling_flags = READ_ONCE(abo->tiling_flags);
+ tmz_surface = READ_ONCE(abo->flags) &
AMDGPU_GEM_CREATE_ENCRYPTED;
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Restore driver.preclose() for all to use
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 4.12+
The bot has tested the following trees: v5.7.10, v5.4.53, v4.19.134, v4.14.189.
v5.7.10: Build OK!
v5.4.53: Build OK!
v4.19.134: Build OK!
v4.14.189: Failed to apply! Possible dependencies:
112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
1572042a4ab2 ("drm: provide management functions for drm_file")
7a2c65dd32b1 ("drm: Release filp before global lock")
7e13ad896484 ("drm: Avoid drm_global_mutex for simple inc/dec of
dev->open_count")
b46a33e271ed ("drm/i915/pmu: Expose a PMU interface for perf queries")
c2400ec3b6d1 ("drm/i915: add Makefile magic for testing headers are
self-contained")
cc662126b413 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET")
e7af3116836f ("drm/i915: Introduce a preempt context")
f0e4a0639752 ("drm/i915: Move GEM domain management to its own file")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.7.10, v5.4.53, v4.19.134, v4.14.189,
v4.9.231, v4.4.231.
v5.7.10: Build OK!
v5.4.53: Failed to apply! Possible dependencies:
061489c65ff5 ("drm/i915/dsb: single register write function for DSB.")
11988e393813 ("drm/i915/execlists: Try rearranging breadcrumb flush")
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
5a90606df7cb ("drm/i915: Replace obj->pin_global with obj->frontbuffer")
67f3b58f3bac ("drm/i915/dsb: DSB context creation.")
8a9a982767b7 ("drm/i915: use a separate context for gpu relocs")
a4e7ccdac38e ("drm/i915: Move context management under GEM")
b27a96ad72fd ("drm/i915/dsb: Indexed register write function for DSB.")
bb120e1171a9 ("drm/i915: Show the logical context ring state on dumping")
c210e85b8f33 ("drm/i915/tgl: Extend MI_SEMAPHORE_WAIT")
d19d71fc2b15 ("drm/i915: Mark i915_request.timeline as a volatile, rcu
pointer")
e8f6b4952ec5 ("drm/i915/execlists: Flush the post-sync breadcrumb write
harder")
v4.19.134: Failed to apply! Possible dependencies:
0258404f9d38 ("drm/i915: start moving runtime device info to a separate
struct")
026844460743 ("drm/i915: Remove intel_context.active_link")
07d805721938 ("drm/i915: Introduce intel_runtime_pm_disable to pair
intel_runtime_pm_enable")
13f1bfd3b332 ("drm/i915: Make object/vma allocation caches global")
1c71bc565cdb ("drm/i915/perf: simplify configure all context function")
2cc8376fd350 ("drm/i915: rename dev_priv info to __info to avoid usage")
2cd9a689e97b ("drm/i915: Refactor intel_display_set_init_power() logic")
37d7c9cc2eb6 ("drm/i915: Check engine->default_state mapping on module
load")
55ac5a1614f9 ("drm/i915: Attach the pci match data to the device upon
creation")
666424abfb86 ("drm/i915/execlists: Use coherent writes into the context
image")
6dfc4a8f134f ("drm/i915: Verify power domains after enabling them")
722f3de39e03 ("i915/oa: Simplify updating contexts")
900ccf30f9e1 ("drm/i915: Only force GGTT coherency w/a on required
chipsets")
c4d52feb2c46 ("drm/i915: Move over to intel_context_lookup()")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
fa9f668141f4 ("drm/i915: Export intel_context_instance()")
v4.14.189: Failed to apply! Possible dependencies:
3bd4073524fa ("drm/i915: Consolidate get_fence with pin_fence")
465c403cb508 ("drm/i915: introduce simple gemfs")
66df1014efba ("drm/i915: Keep a small stash of preallocated WC pages")
67b48040255b ("drm/i915: Assert that the handle->vma lut is empty on object
close")
73ebd503034c ("drm/i915: make mappable struct resource centric")
7789422665f5 ("drm/i915: make dsm struct resource centric")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
969b0950a188 ("drm/i915: Add interface to reserve fence registers for vGPU")
a65adaf8a834 ("drm/i915: Track user GTT faulting per-vma")
b4563f595ed4 ("drm/i915: Pin fence for iomap")
e91ef99b9543 ("drm/i915/selftests: Remember to create the fake preempt
context")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
f773568b6ff8 ("drm/i915: nuke the duplicated stolen discovery")
v4.9.231: Failed to apply! Possible dependencies:
0e70447605f4 ("drm/i915: Move common code out of i915_gpu_error.c")
1b36595ffb35 ("drm/i915: Show RING registers through debugfs")
28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management")
3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the
enabled engines")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
85fd4f58d7ef ("drm/i915: Mark all non-vma being inserted into the address
spaces")
9c870d03674f ("drm/i915: Use RPM as the barrier for controlling user mmap
access")
bb6dc8d96b68 ("drm/i915: Implement pread without struct-mutex")
d636951ec01b ("drm/i915: Cleanup instdone collection")
e007b19d7ba7 ("drm/i915: Use the MRU stack search after evicting")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
f9e613728090 ("drm/i915: Try to print INSTDONE bits for all slice/subslice")
v4.4.231: Failed to apply! Possible dependencies:
1b683729e7ac ("drm/i915: Remove redundant check in i915_gem_obj_to_vma")
1c7f4bca5a6f ("drm/i915: Rename vma->*_list to *_link for consistency")
3272db53136f ("drm/i915: Combine all i915_vma bitfields into a single set
of flags")
596c5923197b ("drm/i915: Reduce the pointer dance of i915_is_ggtt()")
c1a415e261aa ("drm/i915: Disable shrinker for non-swapped backed objects")
d0710abbcd88 ("drm/i915: Set the map-and-fenceable flag for preallocated
objects")
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement WA 14011294188 (rev2)
== Series Details ==
Series: drm/i915: Implement WA 14011294188 (rev2)
URL : https://patchwork.freedesktop.org/series/79825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8797_full -> Patchwork_18245_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18245_full:
### Piglit changes ###
Possible regressions
*
spec@glsl-4.20@execution@vs_in@vs-input-double_dvec3-position-float_mat4x2_array3
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][1] +5 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/pig-icl-1065g7/spec@glsl-4.20@execution@vs_in@vs-input-double_dvec3-position-float_mat4x2_array3.html
*
spec@glsl-4.20@execution@vs_in@vs-input-position-int_int-double_dmat3x4_array2
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][2] +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/pig-icl-1065g7/spec@glsl-4.20@execution@vs_in@vs-input-position-int_int-double_dmat3x4_array2.html
New tests
-
New tests have been introduced between CI_DRM_8797_full and
Patchwork_18245_full:
### New Piglit tests (8) ###
*
spec@glsl-4.20@execution@vs_in@vs-input-double_dmat3-position-double_dmat2x4_array2:
- Statuses : 1 crash(s)
- Exec time: [0.86] s
*
spec@glsl-4.20@execution@vs_in@vs-input-double_dmat3x2-position-float_vec4_array3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-4.20@execution@vs_in@vs-input-double_dvec3-position-float_mat4x2_array3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-4.20@execution@vs_in@vs-input-float_mat2x3_array3-position-double_dmat4x3_array2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-4.20@execution@vs_in@vs-input-float_mat2x4_array3-position-double_dvec4_array2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-4.20@execution@vs_in@vs-input-float_vec2-double_dmat4_array2-position:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-4.20@execution@vs_in@vs-input-position-double_dmat2x4_array5-float_vec3_array3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-4.20@execution@vs_in@vs-input-position-int_int-double_dmat3x4_array2:
- Statuses : 1 crash(s)
- Exec time: [0.87] s
Known issues
Here are the changes found in Patchwork_18245_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_whisper@basic-queues:
- shard-iclb: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/shard-iclb5/igt@gem_exec_whis...@basic-queues.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/shard-iclb2/igt@gem_exec_whis...@basic-queues.html
* igt@kms_busy@basic-flip-pipe-c:
- shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +11
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/shard-skl7/igt@kms_b...@basic-flip-pipe-c.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/shard-skl8/igt@kms_b...@basic-flip-pipe-c.html
* igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#54])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-64x64-offscreen.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-64x64-offscreen.html
* igt@kms_cursor_legacy@pipe-b-torture-bo:
- shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#128])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/shard-iclb5/igt@kms_cursor_leg...@pipe-b-torture-bo.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/shard-iclb2/igt@kms_cursor_leg...@pipe-b-torture-bo.html
* igt@kms_draw_crc@draw-method-rgb565-blt-untiled:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#52] / [i915#54])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/shard-skl2/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/shard-skl9/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +12
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/shard-kbl1/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
- shard-skl: [PASS][15] -> [DMESG-FAIL][16
Re: [Intel-gfx] [PATCH 1/3] drm: Restore driver.preclose() for all to use
> -Original Message-
> From: Daniel Vetter
> Sent: Monday, July 27, 2020 12:33 PM
> To: Chris Wilson ; Dave Airlie
> Cc: intel-gfx ; stable
> ; Gustavo Padovan
> ; Tang, CQ ; dri-
> devel ; Vetter, Daniel
>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
> On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson
> wrote:
> >
> > An unfortunate sequence of events, but it turns out there is a valid
> > usecase for being able to free/decouple the driver objects before they
> > are freed by the DRM core. In particular, if we have a pointer into a
> > drm core object from inside a driver object, that pointer needs to be
> > nerfed *before* it is freed so that concurrent access (e.g. debugfs)
> > does not following the dangling pointer.
> >
> > The legacy marker was adding in the code movement from drp_fops.c to
> > drm_file.c
>
> I might fumble a lot, but not this one:
>
> commit 45c3d213a400c952ab7119f394c5293bb6877e6b
> Author: Daniel Vetter
> Date: Mon May 8 10:26:33 2017 +0200
>
> drm: Nerf the preclose callback for modern drivers
>
> Also looking at the debugfs hook that has some rather adventurous stuff
> going on I think, feels a bit like a kitchensink with batteries included. If
> that's
> really all needed I'd say iterate the contexts by first going over files,
> then the
> ctx (which arent shared anyway) and the problem should also be gone.
Debugfs code can jump in after drm_gem_release() (where file->object_idr is
destroyed), but before postclose(). At this window, everything is fine for
debugfs context accessing except the file->object_idr.
--CQ
> -Daniel
>
> > References: 9acdac68bcdc ("drm: rename drm_fops.c to drm_file.c")
> > Signed-off-by: Chris Wilson
> > Cc: Daniel Vetter
> > Cc: Gustavo Padovan
> > Cc: CQ Tang
> > Cc: # v4.12+
> > ---
> > drivers/gpu/drm/drm_file.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index 0ac4566ae3f4..7b4258d6f7cc 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -258,8 +258,7 @@ void drm_file_free(struct drm_file *file)
> > (long)old_encode_dev(file->minor->kdev->devt),
> > atomic_read(&dev->open_count));
> >
> > - if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> > - dev->driver->preclose)
> > + if (dev->driver->preclose)
> > dev->driver->preclose(dev, file);
> >
> > if (drm_core_check_feature(dev, DRIVER_LEGACY))
> > --
> > 2.20.1
> >
> > ___
> > 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
Re: [Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers
On Fri, Jul 24, 2020 at 09:55:35AM +0100, Chris Wilson wrote: Quoting Umesh Nerlige Ramappa (2020-07-24 01:19:00) From: Piotr Maciejewski It is useful to have markers in the OA reports to identify triggered reports. Whitelist some OA counters that can be used as markers. A triggered report can be found faster if we can sample the HW tail and head registers when the report was triggered. Whitelist OA buffer specific registers. v2: - Bump up the perf revision (Lionel) - Use indexing for counters (Lionel) - Fix selftest for oa ticking register (Umesh) v3: Pardon whitelisted registers for selftest (Umesh) v4: - Document whitelisted registers (Lionel) - Fix live isolated whitelist for OA regs (Umesh) Signed-off-by: Piotr Maciejewski Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Lionel Landwerlin --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 34 +++ .../gpu/drm/i915/gt/selftest_workarounds.c| 30 +++- drivers/gpu/drm/i915/i915_perf.c | 8 - drivers/gpu/drm/i915/i915_reg.h | 10 ++ 4 files changed, 80 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index a72ebfd115e5..c950d07beec3 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1392,6 +1392,23 @@ static void gen9_whitelist_build_performance_counters(struct i915_wa_list *w) /* OA buffer trigger report 2/6 used by performance query */ whitelist_reg(w, OAREPORTTRIG2); whitelist_reg(w, OAREPORTTRIG6); + + /* Performance counters A18-20 used by tbs marker query */ + whitelist_reg_ext(w, OA_PERF_COUNTER_A(18), + RING_FORCE_TO_NONPRIV_ACCESS_RW | + RING_FORCE_TO_NONPRIV_RANGE_4); + + whitelist_reg(w, OA_PERF_COUNTER_A(20)); + whitelist_reg(w, OA_PERF_COUNTER_A_UPPER(20)); + + /* Read access to gpu ticks */ + whitelist_reg_ext(w, GEN8_GPU_TICKS, + RING_FORCE_TO_NONPRIV_ACCESS_RD); + + /* Read access to: oa status, head, tail, buffer settings */ + whitelist_reg_ext(w, GEN8_OASTATUS, + RING_FORCE_TO_NONPRIV_ACCESS_RD | + RING_FORCE_TO_NONPRIV_RANGE_4); Great. This completely fills RING_MAX_NONPRIV_SLOTS, with over half the slots going to OA. That does not seem sustainable. I did not think the extended whitelist settings were available before cml. Looks like we can remove A20, A20_upper and gpu ticks to free up 3 slots. Will post that in the new series. Hoping that will do for now. Thanks, Umesh -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Restore driver.preclose() for all to use
On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson wrote:
>
> An unfortunate sequence of events, but it turns out there is a valid
> usecase for being able to free/decouple the driver objects before they
> are freed by the DRM core. In particular, if we have a pointer into a
> drm core object from inside a driver object, that pointer needs to be
> nerfed *before* it is freed so that concurrent access (e.g. debugfs)
> does not following the dangling pointer.
>
> The legacy marker was adding in the code movement from drp_fops.c to
> drm_file.c
I might fumble a lot, but not this one:
commit 45c3d213a400c952ab7119f394c5293bb6877e6b
Author: Daniel Vetter
Date: Mon May 8 10:26:33 2017 +0200
drm: Nerf the preclose callback for modern drivers
Also looking at the debugfs hook that has some rather adventurous
stuff going on I think, feels a bit like a kitchensink with batteries
included. If that's really all needed I'd say iterate the contexts by
first going over files, then the ctx (which arent shared anyway) and
the problem should also be gone.
-Daniel
> References: 9acdac68bcdc ("drm: rename drm_fops.c to drm_file.c")
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Gustavo Padovan
> Cc: CQ Tang
> Cc: # v4.12+
> ---
> drivers/gpu/drm/drm_file.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 0ac4566ae3f4..7b4258d6f7cc 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -258,8 +258,7 @@ void drm_file_free(struct drm_file *file)
> (long)old_encode_dev(file->minor->kdev->devt),
> atomic_read(&dev->open_count));
>
> - if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> - dev->driver->preclose)
> + if (dev->driver->preclose)
> dev->driver->preclose(dev, file);
>
> if (drm_core_check_feature(dev, DRIVER_LEGACY))
> --
> 2.20.1
>
> ___
> 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
Re: [Intel-gfx] s/obj->mm.lock//
On 7/6/20 8:19 AM, Chris Wilson wrote:
This is the easy part; pulling reservation of multiple objects under an
ww acquire context. With one simple rule that eviction is handled by the
ww acquire context, we can carefully transition the driver over to using
eviction. Instead of feeding the acquire context everywhere, we make the
caller gather up all the objects they need to acquire into the context,
then acquire their backing store. The major boon here is that by
providing a clean set of objects (that we have not yet started to
acquire any auxiliary attachments for) to the acquire context, it can
handle all the EDEADLK processing for us [since it is a pure locking
operation and does not need to release attachments upon revoking the
locks].
As a sketch of what that would look like, to illustrate the major work
remaining:
static int evict(struct drm_i915_gem_object *obj, struct i915_acquire_ctx *ctx)
{
struct intel_memory_region *mem = obj->mm->region;
struct drm_i915_gem_object *swap; // struct i915_mm_bo *swap
struct i915_request *rq;
int err;
/* swap = mem->create_eviction_target(obj); */
swap = i915_gem_object_create_shmem(mem->i915, obj->base.size);
if (IS_ERR(swap))
return PTR_ERR(swap);
err = dma_resv_lock_interruptible(swap, &ctx->ctx);
GEM_BUG_ON(err == -EALREADY);
if (err == -EDEADLK)
goto out;
/* Obviously swap has to be carefully chosen so that this may succeed */
err = __i915_gem_object_get_pages_locked(swap);
if (err)
goto out_unlock;
rq = pinned_evict_copy(ctx, obj, swap);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto out_unlock;
}
err = i915_gem_revoke_mm(obj);
if (err)
goto out_request;
/* Alternatively you could wait synchronously! */
mem->release_blocks(&obj->mm->blocks, rq);
i915_mm_bo_put(xchg(&obj->mm, i915_mm_bo_get(swap)));
dma_resv_add_exclusive_fence(obj->base.resv, &rq->fence);
out_request:
i915_request_put(rq);
out_unlock:
dma_resv_unlock(swap);
out:
i915_gem_object_put(swap);
return err;
}
static int relock_all(struct i915_acquire_ctx *ctx)
{
struct i915_acquire_link *lnk, *lock;
int err;
for (lnk = ctx->locked; lnk; lnk = lnk->next)
dma_resv_unlock(lnk->obj->base.resv);
lock = fetch_and_zero(&ctx->locked);
while ((lnk = lock)) {
struct drm_i915_gem_object *obj;
obj = lnk->obj;
lock = lnk->next;
if (ctx->locked)
err = dma_resv_lock_interruptible(obj->base.resv,
&ctx->ctx);
else
err = dma_resv_lock_slow_interruptible(obj->base.resv,
&ctx->ctx);
GEM_BUG_ON(err == -EALREADY);
if (err == -EDEADLK) {
struct i915_acquire *old;
while ((old = ctx->locked)) {
dma_resv_unlock(old->obj->base.resv);
ctx->locked = old->next;
old->next = lock;
lock = old;
}
lnk->next = lock;
lock = lnk;
continue;
}
if (err) {
lock = lnk;
break;
}
lnk->next = ctx->locked;
ctx->locked = lnk;
}
while ((lnk = lock)) {
lock = lnk->next;
i915_gem_object_put(lnk->obj);
i915_acquire_free(lnk);
}
return err;
}
int i915_acquire_mm(struct i915_acquire_ctx *ctx)
{
struct i915_acquire_link *lnk;
int n, err;
restart:
for (lnk = ctx->locked; lnk; lnk = lnk->next) {
for (n = 0;
!i915_gem_object_has_pages(lnk->obj);
n++) {
struct drm_i915_gem_object *evictee = NULL;
mem = get_preferred_memregion_for_object(lnk->obj, n);
if (!mem)
return -ENXIO;
while (!i915_gem_object_get_pages(lnk->obj)) {
struct i915_acquire_link *this;
evictee = mem->get_eviction_candidate(mem,
evictee);
if (!evictee)
break;
err = dma_resv_lock_interruptible(evictee,
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement WA 14011294188 (rev2)
== Series Details ==
Series: drm/i915: Implement WA 14011294188 (rev2)
URL : https://patchwork.freedesktop.org/series/79825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8797 -> Patchwork_18245
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/index.html
Known issues
Here are the changes found in Patchwork_18245 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
* igt@gem_mmap@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-tgl-y/igt@gem_m...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-tgl-y/igt@gem_m...@basic.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-byt-j1900/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-tgl-y/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-tgl-y/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_tiled_fence_blits@basic:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-tgl-y/igt@gem_tiled_fence_bl...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-tgl-y/igt@gem_tiled_fence_bl...@basic.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-kbl-soraka/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][23] ([i915#402]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@i915_module_load@reload:
- fi-icl-u2: [DMESG-WARN][25] ([i915#289]) -> [DMESG-WARN][26]
([i915#1982] / [i915#289])
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8797/fi-icl-u2/igt@i915_module_l...@reload.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/fi-ic
Re: [Intel-gfx] [PATCH 22/66] drm/i915/gem: Bind the fence async for execbuf
On 7/15/20 1:51 PM, Chris Wilson wrote:
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the async binding pipeline.
Why is it we don't just move the fence binding to a separate loop after
unlocking the vm->mutex in eb_reserve_vm()?
/Thomas
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +--
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 137 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 5 +
3 files changed, 151 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bdcbb82bfc3d..af2b4aeb6df0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1056,15 +1056,6 @@ static int eb_reserve_vma(struct eb_vm_work *work,
struct eb_bind_vma *bind)
return err;
pin:
- if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
- err = __i915_vma_pin_fence(vma); /* XXX no waiting */
- if (unlikely(err))
- return err;
-
- if (vma->fence)
- bind->ev->flags |= __EXEC_OBJECT_HAS_FENCE;
- }
-
bind_flags &= ~atomic_read(&vma->flags);
if (bind_flags) {
err = set_bind_fence(vma, work);
@@ -1095,6 +1086,15 @@ static int eb_reserve_vma(struct eb_vm_work *work,
struct eb_bind_vma *bind)
bind->ev->flags |= __EXEC_OBJECT_HAS_PIN;
GEM_BUG_ON(eb_vma_misplaced(entry, vma, bind->ev->flags));
+ if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
+ err = __i915_vma_pin_fence_async(vma, &work->base);
+ if (unlikely(err))
+ return err;
+
+ if (vma->fence)
+ bind->ev->flags |= __EXEC_OBJECT_HAS_FENCE;
+ }
+
return 0;
}
@@ -1160,6 +1160,9 @@ static void __eb_bind_vma(struct eb_vm_work *work)
struct eb_bind_vma *bind = &work->bind[n];
struct i915_vma *vma = bind->ev->vma;
+ if (bind->ev->flags & __EXEC_OBJECT_HAS_FENCE)
+ __i915_vma_apply_fence_async(vma);
+
if (!bind->bind_flags)
goto put;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 7fb36b12fe7a..734b6aa61809 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -21,10 +21,13 @@
* IN THE SOFTWARE.
*/
+#include "i915_active.h"
#include "i915_drv.h"
#include "i915_scatterlist.h"
+#include "i915_sw_fence_work.h"
#include "i915_pvinfo.h"
#include "i915_vgpu.h"
+#include "i915_vma.h"
/**
* DOC: fence register handling
@@ -340,19 +343,37 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt
*ggtt)
return ERR_PTR(-EDEADLK);
}
+static int fence_wait_bind(struct i915_fence_reg *reg)
+{
+ struct dma_fence *fence;
+ int err = 0;
+
+ fence = i915_active_fence_get(®->active.excl);
+ if (fence) {
+ err = dma_fence_wait(fence, true);
+ dma_fence_put(fence);
+ }
+
+ return err;
+}
+
int __i915_vma_pin_fence(struct i915_vma *vma)
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
- struct i915_fence_reg *fence;
+ struct i915_fence_reg *fence = vma->fence;
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
int err;
lockdep_assert_held(&vma->vm->mutex);
/* Just update our place in the LRU if our fence is getting reused. */
- if (vma->fence) {
- fence = vma->fence;
+ if (fence) {
GEM_BUG_ON(fence->vma != vma);
+
+ err = fence_wait_bind(fence);
+ if (err)
+ return err;
+
atomic_inc(&fence->pin_count);
if (!fence->dirty) {
list_move_tail(&fence->link, &ggtt->fence_list);
@@ -384,6 +405,116 @@ int __i915_vma_pin_fence(struct i915_vma *vma)
return err;
}
+static int set_bind_fence(struct i915_fence_reg *fence,
+ struct dma_fence_work *work)
+{
+ struct dma_fence *prev;
+ int err;
+
+ if (rcu_access_pointer(fence->active.excl.fence) == &work->dma)
+ return 0;
+
+ err = i915_sw_fence_await_active(&work->chain,
+&fence->active,
+I915_ACTIVE_AWAIT_ACTIVE);
+ if (err)
+ return err;
+
+ if (i915_active_acquire(&fence->active))
+ return -ENOENT;
+
+ prev = i915_active_
Re: [Intel-gfx] [PATCH 27/66] drm/i915/gem: Pull execbuf dma resv under a single critical section
On 7/15/20 1:51 PM, Chris Wilson wrote:
Acquire all the objects and their backing storage, and page directories,
as used by execbuf under a single common ww_mutex. Albeit we have to
restart the critical section a few times in order to handle various
restrictions (such as avoiding copy_(from|to)_user and mmap_sem).
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 168 +-
.../i915/gem/selftests/i915_gem_execbuffer.c | 8 +-
2 files changed, 87 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ebabc0746d50..db433f3f18ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -20,6 +20,7 @@
#include "gt/intel_gt_pm.h"
#include "gt/intel_gt_requests.h"
#include "gt/intel_ring.h"
+#include "mm/i915_acquire_ctx.h"
#include "i915_drv.h"
#include "i915_gem_clflush.h"
@@ -244,6 +245,8 @@ struct i915_execbuffer {
struct intel_context *context; /* logical state for the request */
struct i915_gem_context *gem_context; /** caller's context */
+ struct i915_acquire_ctx acquire; /** lock for _all_ DMA reservations */
+
struct i915_request *request; /** our request to build */
struct eb_vma *batch; /** identity of the batch obj/vma */
@@ -389,42 +392,6 @@ static void eb_vma_array_put(struct eb_vma_array *arr)
kref_put(&arr->kref, eb_vma_array_destroy);
}
-static int
-eb_lock_vma(struct i915_execbuffer *eb, struct ww_acquire_ctx *acquire)
-{
- struct eb_vma *ev;
- int err = 0;
-
- list_for_each_entry(ev, &eb->submit_list, submit_link) {
- struct i915_vma *vma = ev->vma;
-
- err = ww_mutex_lock_interruptible(&vma->resv->lock, acquire);
- if (err == -EDEADLK) {
- struct eb_vma *unlock = ev, *en;
-
- list_for_each_entry_safe_continue_reverse(unlock, en,
-
&eb->submit_list,
- submit_link) {
- ww_mutex_unlock(&unlock->vma->resv->lock);
- list_move_tail(&unlock->submit_link,
&eb->submit_list);
- }
-
- GEM_BUG_ON(!list_is_first(&ev->submit_link,
&eb->submit_list));
- err = ww_mutex_lock_slow_interruptible(&vma->resv->lock,
- acquire);
- }
- if (err) {
- list_for_each_entry_continue_reverse(ev,
-&eb->submit_list,
-submit_link)
- ww_mutex_unlock(&ev->vma->resv->lock);
- break;
- }
- }
-
- return err;
-}
-
static int eb_create(struct i915_execbuffer *eb)
{
/* Allocate an extra slot for use by the sentinel */
@@ -668,6 +635,25 @@ eb_add_vma(struct i915_execbuffer *eb,
}
}
+static int eb_lock_mm(struct i915_execbuffer *eb)
+{
+ struct eb_vma *ev;
+ int err;
+
+ list_for_each_entry(ev, &eb->bind_list, bind_link) {
+ err = i915_acquire_ctx_lock(&eb->acquire, ev->vma->obj);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+static int eb_acquire_mm(struct i915_execbuffer *eb)
+{
+ return i915_acquire_mm(&eb->acquire);
+}
+
struct eb_vm_work {
struct dma_fence_work base;
struct eb_vma_array *array;
@@ -1390,7 +1376,15 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
unsigned long count;
struct eb_vma *ev;
unsigned int pass;
- int err = 0;
+ int err;
+
+ err = eb_lock_mm(eb);
+ if (err)
+ return err;
+
+ err = eb_acquire_mm(eb);
+ if (err)
+ return err;
count = 0;
INIT_LIST_HEAD(&unbound);
@@ -1416,10 +1410,15 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
if (count == 0)
return 0;
+ /* We need to reserve page directories, release all, start over */
+ i915_acquire_ctx_fini(&eb->acquire);
+
pass = 0;
do {
struct eb_vm_work *work;
+ i915_acquire_ctx_init(&eb->acquire);
Couldn't we do a i915_acquire_ctx_rollback() here to avoid losing our
ticket? That would mean deferring i915_acquire_ctx_done() until all
potential rollbacks have been performed.
Or even better if we defer _ctx_done(), couldn't we just continue
locking the pts here instead of dropping and re-acquiring everything?
+
/*
* We need to hold one lock as we bind all the vma so that
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Implement WA 14011294188 (rev2)
== Series Details == Series: drm/i915: Implement WA 14011294188 (rev2) URL : https://patchwork.freedesktop.org/series/79825/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI] drm/i915: Implement WA 14011294188
Although the WA description targets the platforms it is a workaround
for the affected PCHs, that is why it is being checked.
v2: excluding DG1 fake PCH from WA
BSpec: 52890
BSpec: 53273
BSpec: 52888
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h| 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0c713e83274d..788bd4516365 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5302,6 +5302,12 @@ static void icl_display_core_init(struct
drm_i915_private *dev_priv,
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+ /* Wa_14011294188:ehl,jsl,tgl,rkl */
+ if (INTEL_PCH_TYPE(dev_priv) >= PCH_JSP &&
+ INTEL_PCH_TYPE(dev_priv) < PCH_DG1)
+ intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D, 0,
+PCH_DPMGUNIT_CLOCK_GATE_DISABLE);
+
/* 1. Enable PCH reset handshake. */
intel_pch_reset_handshake(dev_priv, !HAS_PCH_NOP(dev_priv));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a0d31f3bf634..5eae593ee784 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8730,6 +8730,7 @@ enum {
#define PCH_GMBUSUNIT_CLOCK_GATE_DISABLE (1 << 31)
#define PCH_DPLUNIT_CLOCK_GATE_DISABLE (1 << 30)
#define PCH_DPLSUNIT_CLOCK_GATE_DISABLE (1 << 29)
+#define PCH_DPMGUNIT_CLOCK_GATE_DISABLE (1 << 15)
#define PCH_CPUNIT_CLOCK_GATE_DISABLE (1 << 14)
#define CNP_PWM_CGE_GATING_DISABLE (1 << 13)
#define PCH_LP_PARTITION_LEVEL_DISABLE (1 << 12)
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next
> On Jul 21, 2020, at 5:42 PM, Zhenyu Wang wrote: > > On 2020.07.21 14:04:41 +0300, Joonas Lahtinen wrote: >> Quoting Zhenyu Wang (2020-07-20 11:05:41) >>> >>> Hi, >>> >>> Sorry that this might be a bit late as last week our QA people were >>> busy on something else..So this is gvt changes queued for 5.9 which is >>> to improve guest suspend/resume with proper PCI PM state tracking for >>> resource handling, e.g ppgtt. Hopefully this could still be in queue >>> for 5.9. >> >> Is this a regression fix to a problem introduced by previous >> gvt-next PR targeting 5.9? >> >> Or is it an incremental improvement over 5.8? >> > > Second case. This is incremental improvement. Guest suspend/resume > did work somehow before but has bad performance and possible failure > with some guest versions. I'm afraid Jani already sent the last pull request towards 5.9. So if there are fixes inside this pull request this should move to the -next-fixes and the remaining improvements to another 5.10 pull request Thanks, Rodrigo. > > Thanks > >> >>> >>> Thanks >>> -- >>> The following changes since commit d524b87f77364db096855d7eb714ffacec974ddf: >>> >>> drm/i915: Update DRIVER_DATE to 20200702 (2020-07-02 21:25:28 +0300) >>> >>> are available in the Git repository at: >>> >>> https://github.com/intel/gvt-linux tags/gvt-next-2020-07-20 >>> >>> for you to fetch changes up to 02b5fc1527c0bb26a1012c6a806dc033f3b125a6: >>> >>> drm/i915/gvt: Remove intel_vgpu_reset_gtt() since no one use it. >>> (2020-07-14 16:42:14 +0800) >>> >>> >>> gvt-next-2020-07-20 >>> >>> - Improve guest suspend/resume handling (Colin) >>> >>> >>> Colin Xu (3): >>> drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0. >>> drm/i915/gvt: Do not reset pv_notified when vGPU transit from D3->D0 >>> drm/i915/gvt: Remove intel_vgpu_reset_gtt() since no one use it. >>> >>> drivers/gpu/drm/i915/gvt/cfg_space.c | 24 >>> drivers/gpu/drm/i915/gvt/gtt.c | 20 +--- >>> drivers/gpu/drm/i915/gvt/gtt.h | 3 ++- >>> drivers/gpu/drm/i915/gvt/gvt.h | 3 +++ >>> drivers/gpu/drm/i915/gvt/vgpu.c | 20 +--- >>> 5 files changed, 47 insertions(+), 23 deletions(-) >>> -- > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't force IOSF_MBI
On Fri, 17 Jul 2020 20:32:44 +0100 Chris Wilson wrote: > > > Quoting Jisheng Zhang (2020-07-17 07:11:38) > > The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines > > isof_mbi_* APIs when ISOF_MBI is disabled. > > > > Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC platforms. > > But it is required for Valleyview/Cherryview and we want to support > those by default. Tricky. If linux kernel is built for Valleyview/Cherryview, ISOF_MBI has to be enabled. The dependency is met there. Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea
Am 22.07.20 um 16:07 schrieb Daniel Vetter: On Wed, Jul 22, 2020 at 3:12 PM Thomas Hellström (Intel) wrote: On 2020-07-22 14:41, Daniel Vetter wrote: I'm pretty sure there's more bugs, I just haven't heard from them yet. Also due to the opt-in nature of dma-fence we can limit the scope of what we fix fairly naturally, just don't put them where no one cares :-) Of course that also hides general locking issues in dma_fence signalling code, but well *shrug*. Hmm, yes. Another potential big problem would be drivers that want to use gpu page faults in the dma-fence critical sections with the batch-based programming model. Yeah that's a massive can of worms. But luckily there's no such driver merged in upstream, so hopefully we can think about all the constraints and how to best annotate&enforce this before we land any code and have big regrets. Do you want a bad news? I once made a prototype for that when Vega10 came out. But we abandoned this approach for the the batch based approach because of the horrible performance. KFD is going to see that, but this is only with user queues and no dma_fence involved whatsoever. Christian. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [XDC 2020] Virtual conference + Call for Proposals extended 2 weeks more
On 7/3/20 4:41 PM, Samuel Iglesias Gonsálvez wrote: > Hi, > > In the last meeting, X.Org Foundation board has decided that XDC 2020 > will be a virtual conference, given the uncertain COVID-19 situation in > Europe by September, including the possibility of a second wave, > outbreaks and travel restrictions, either in Poland or in other > countries. > > XDC 2020 organization team agrees on this decision and it volunteered > to organize our first virtual XDC! > > We would like to announce as well that the new CFP deadline is Sunday > July 19th 2020. Don't forget to submit your talk, demo and workshop > proposals! > As approved in last board's meeting [0], CfP is extended until two weeks before the conference, or until we fill all the slots (whichever happens first). Please submit your talk proposals early! Last two years we had lots of talks about new and fresh development and we prioritized those over other kind of talks, as they had more potential for discussions and hallway track. However, this year that doesn't make too much sense, so we encourage our community to submit any talk related to open-source graphics stack, including those that focus on project status updates. Sam [0] https://www.x.org/wiki/BoardOfDirectors/MeetingSummaries/2020/07-16/ > Thanks, > > Sam > > > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability
Em Tue, Jul 21, 2020 at 04:06:34PM +0300, Alexey Budankov escreveu: > > On 13.07.2020 21:51, Arnaldo Carvalho de Melo wrote: > > Em Mon, Jul 13, 2020 at 03:37:51PM +0300, Alexey Budankov escreveu: > >> > >> On 13.07.2020 15:17, Arnaldo Carvalho de Melo wrote: > >>> Em Mon, Jul 13, 2020 at 12:48:25PM +0300, Alexey Budankov escreveu: > >> If it had that patch below then message change would not be required. > > Sure, but the tool should continue to work and provide useful messages > > when running on kernels without that change. Pointing to the document is > > valid and should be done, that is an agreed point. But the tool can do > > some checks, narrow down the possible causes for the error message and > > provide something that in most cases will make the user make progress. > >> However this two sentences in the end of whole message would still add up: > >> "Please read the 'Perf events and tool security' document: > >> https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html"; > > We're in violent agreement here. :-) > Here is the message draft mentioning a) CAP_SYS_PTRACE, for kernels prior > v5.8, and b) Perf security document link. The plan is to send a patch > extending > perf_events with CAP_PERFMON check [1] for ptrace_may_access() and extending > the tool with this message. > "Access to performance monitoring and observability operations is limited. > Enforced MAC policy settings (SELinux) can limit access to performance > monitoring and observability operations. Inspect system audit records for > more perf_event access control information and adjusting the policy. > Consider adjusting /proc/sys/kernel/perf_event_paranoid setting to open > access to performance monitoring and observability operations for processes > without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability. > More information can be found at 'Perf events and tool security' document: > https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > perf_event_paranoid setting is -1: > -1: Allow use of (almost) all events by all users >Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK > >= 0: Disallow raw and ftrace function tracepoint access > >= 1: Disallow CPU event access > >= 2: Disallow kernel profiling > To make the adjusted perf_event_paranoid setting permanent preserve it > in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = )" Looks ok! Lots of knobs to control access as one needs. - Arnaldo > Alexei > > [1] https://lore.kernel.org/lkml/20200713121746.ga7...@kernel.org/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler
On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
> Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 1fa67700d8f4..95953b393941 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
>> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
>> }
>>
>> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> +enum pipe pipe = to_intel_crtc(crtc)->pipe;
>> +
>> +return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
>> +}
>> +
>> u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
>> {
>> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> enum pipe pipe = to_intel_crtc(crtc)->pipe;
>>
>> +if (crtc->state->async_flip)
>> +return g4x_get_flip_counter(crtc);
>> +
>> return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
>
> I don't understand the intention behind this, can you please clarify?
> This goes back to my reply of the cover letter. It seems that here
> we're going to alternate between two different counters in our vblank
> count. So if user space alternates between sometimes using async flips
> and sometimes using normal flip it's going to get some very weird
> deltas, isn't it? At least this is what I remember from when I played
> with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
> using async flips.
This definitely looks wrong. The counter value returned by the
get_vblank_counter hook is supposed to increment when a vertical blank
period occurs; page flips are not supposed to affect this in any way.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
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: Reduce register reads around GT interrupts
== Series Details == Series: drm/i915: Reduce register reads around GT interrupts URL : https://patchwork.freedesktop.org/series/79919/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8793_full -> Patchwork_18244_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18244_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18244_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_18244_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@fence: - shard-tglb: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-tglb2/igt@i915_selftest@m...@fence.html - shard-kbl: NOTRUN -> [INCOMPLETE][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-kbl6/igt@i915_selftest@m...@fence.html - shard-iclb: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-iclb1/igt@i915_selftest@m...@fence.html - shard-hsw: NOTRUN -> [INCOMPLETE][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-hsw2/igt@i915_selftest@m...@fence.html - shard-glk: NOTRUN -> [INCOMPLETE][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-glk9/igt@i915_selftest@m...@fence.html Known issues Here are the changes found in Patchwork_18244_full that come from known issues: ### IGT changes ### Issues hit * 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_8793/shard-tglb3/igt@gem_exec_balan...@bonded-early.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-tglb3/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [PASS][8] -> [DMESG-WARN][9] ([i915#118] / [i915#95]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-glk4/igt@gem_exec_whis...@basic-contexts-forked.html * igt@i915_module_load@reload: - shard-tglb: [PASS][10] -> [DMESG-WARN][11] ([i915#402]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-tglb1/igt@i915_module_l...@reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-tglb8/igt@i915_module_l...@reload.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#454]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-iclb5/igt@i915_pm...@dc6-psr.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-iclb4/igt@i915_pm...@dc6-psr.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][14] -> [DMESG-FAIL][15] ([i915#118] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-glk1/igt@kms_big...@x-tiled-64bpp-rotate-180.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][16] -> [FAIL][17] ([i915#57]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_cursor_legacy@cursora-vs-flipa-toggle: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) +16 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-skl9/igt@kms_cursor_leg...@cursora-vs-flipa-toggle.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-skl4/igt@kms_cursor_leg...@cursora-vs-flipa-toggle.html * igt@kms_cursor_legacy@pipe-b-torture-bo: - shard-iclb: [PASS][20] -> [DMESG-WARN][21] ([i915#128]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-iclb6/igt@kms_cursor_leg...@pipe-b-torture-bo.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/shard-iclb8/igt@kms_cursor_leg...@pipe-b-torture-bo.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][22] -> [DMESG-WARN][23] ([i915#180]) +3 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/shard-kbl2/igt@kms_...@bpc-switch-suspend.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1
Re: [Intel-gfx] [PATCH] drm/i915: Reduce register reads around GT interrupts
Chris Wilson writes:
> The GT subsystem is highly dependent on interrupts for driving the GPU;
> while the interrupt is being processed the GPU may idle leading to lower
> throughput and higher latency. Since the GT interrupts dominate, push
> the incidental display interrupt handling to later.
>
> gem_exec_nop/parallel on ivb [i7-3720QM]:
>
> Before:
> average (individually): 2.278us
> rcs0: 8337674 cycles, 2.399us
> vcs0: 3286990 cycles, 6.085us
> bcs0: 2047917 cycles, 9.766us
>
> After:
> average (individually): 2.118us
> rcs0: 10132462 cycles, 1.974us
> bcs0: 3667130 cycles, 5.454us
> vcs0: 3616618 cycles, 5.530us
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Ville Syrjälä
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 58 +
> 1 file changed, 30 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1fa67700d8f4..e156de88bdc6 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2099,29 +2099,16 @@ static irqreturn_t ilk_irq_handler(int irq, void *arg)
> {
> struct drm_i915_private *i915 = arg;
> void __iomem * const regs = i915->uncore.regs;
> - u32 de_iir, gt_iir, de_ier, sde_ier = 0;
> + u32 de_iir, gt_iir, de_ier;
> irqreturn_t ret = IRQ_NONE;
>
> if (unlikely(!intel_irqs_enabled(i915)))
> return IRQ_NONE;
>
> - /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> - disable_rpm_wakeref_asserts(&i915->runtime_pm);
> -
> /* disable master interrupt before clearing iir */
> de_ier = raw_reg_read(regs, DEIER);
> raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
>
> - /* Disable south interrupts. We'll only write to SDEIIR once, so further
> - * interrupts will will be stored on its back queue, and then we'll be
> - * able to process them after we restore SDEIER (as soon as we restore
> - * it, we'll get an interrupt if SDEIIR still has something to process
> - * due to its back queue). */
> - if (!HAS_PCH_NOP(i915)) {
> - sde_ier = raw_reg_read(regs, SDEIER);
> - raw_reg_write(regs, SDEIER, 0);
> - }
> -
> /* Find, clear, then process each source of interrupt */
>
> gt_iir = raw_reg_read(regs, GTIIR);
> @@ -2134,32 +2121,47 @@ static irqreturn_t ilk_irq_handler(int irq, void *arg)
> ret = IRQ_HANDLED;
> }
>
> + if (INTEL_GEN(i915) >= 6) {
> + u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
> + if (pm_iir) {
> + raw_reg_write(regs, GEN6_PMIIR, pm_iir);
> + gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
> + ret = IRQ_HANDLED;
> + }
> + }
> +
> de_iir = raw_reg_read(regs, DEIIR);
> if (de_iir) {
> + u32 sde_ier = 0;
> +
> + /*
> + * Disable south interrupts. We'll only write to SDEIIR once,
> + * so further interrupts will will be stored on its back queue,
> + * and then we'll be able to process them after we restore
> + * SDEIER (as soon as we restore it, we'll get an interrupt if
> + * SDEIIR still has something to process due to its back queue).
> + */
> + if (!HAS_PCH_NOP(i915)) {
> + sde_ier = raw_reg_read(regs, SDEIER);
> + raw_reg_write(regs, SDEIER, 0);
> + }
> +
> + disable_rpm_wakeref_asserts(&i915->runtime_pm);
> +
> raw_reg_write(regs, DEIIR, de_iir);
> if (INTEL_GEN(i915) >= 7)
> ivb_display_irq_handler(i915, de_iir);
> else
> ilk_display_irq_handler(i915, de_iir);
> +
> + enable_rpm_wakeref_asserts(&i915->runtime_pm);
> ret = IRQ_HANDLED;
> - }
>
> - if (INTEL_GEN(i915) >= 6) {
> - u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
> - if (pm_iir) {
> - raw_reg_write(regs, GEN6_PMIIR, pm_iir);
> - gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
> - ret = IRQ_HANDLED;
> - }
> + if (sde_ier)
> + raw_reg_write(regs, SDEIER, sde_ier);
> }
>
> raw_reg_write(regs, DEIER, de_ier);
> - if (sde_ier)
> - raw_reg_write(regs, SDEIER, sde_ier);
> -
> - /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> - enable_rpm_wakeref_asserts(&i915->runtime_pm);
> -
> return ret;
> }
>
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait
On 23/07/2020 21:32, Dave Airlie wrote: I've got a 66 patch series here, does it have a cover letter I missed? > > Does it have a what is the goal of this series? Does it tell the > reviewer where things are headed and why this is a good idea from a > high level. Chris sent it on one of the previous rounds upon my request - please see https://www.spinics.net/lists/intel-gfx/msg243461.html. First paragraph is the key. This series of 66 is some other unrelated work which is a bit misleading, but that the usual. :) Real amount of patches is more around 20, like that posting which had a cover letter. The problem with these series is they are impossible to review from a WTF does it do, and it forces people to review at a patch level, but the high level concepts and implications go unmissed. I've been reviewing both implementations so in case it helps I'll write a few words... We had internal discussions and meetings on two different approaches. With this in mind, I agree it is hard to get the full picture looking from the outside when only limited amount of information went out (in the for of the cover letter). In short, core idea the series is doing is splitting out object backing store reservation from address space management. This way it is able to collect all possible backing store (and kernel memory allocations) into this first stage, and it also does not have to feed the ww context down the stack. (Because parts lower in the stack can therefore never try to obtain a new buffer objects, or do memory allocation.) To me that sounds a solid approach which is in line with obj dma_resv locking rules. And it definitely is not to be reviewed (just) on the patch-per-patch basis. Applying all of it and looking at the end result is what is needed and what I have done first before proceeded to look at individual patches. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories
Hi, Chris, It appears to me like this series is doing a lot of different things: - Various optimizations - Locking rework - Adding schedulers - Other misc fixes Could you please separate out as much as possible the locking rework prerequisites in one series with cover letter, and most importantly the major part of the locking rework (only) with a more elaborate cover letter discussing, if not trivial, how each patch fits in and on design and future directions, Questions that I have stumbled on so far (being a new-to-the-driver reviewer): - When are memory allocations disallowed? If we need to pre-allocate in execbuf, when? why? - When is the request dma-fence published? - Do we need to keep cpu asynchronous execbuf tasks after this? why? - What about userptr pinning ending up in the dma_fence critical path? And then move anything non-related to separate series? Thanks, Thomas ___ 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: Reduce register reads around GT interrupts
== Series Details ==
Series: drm/i915: Reduce register reads around GT interrupts
URL : https://patchwork.freedesktop.org/series/79919/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8793 -> Patchwork_18244
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/index.html
Known issues
Here are the changes found in Patchwork_18244 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_auth@basic-auth:
- fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-kbl-soraka/igt@core_a...@basic-auth.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-kbl-soraka/igt@core_a...@basic-auth.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_addfb_basic@addfb25-bad-modifier:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_psr@primary_mmap_gtt:
- fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-tgl-y/igt@kms_psr@primary_mmap_gtt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-tgl-y/igt@kms_psr@primary_mmap_gtt.html
Possible fixes
* igt@gem_exec_store@basic:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-tgl-y/igt@gem_exec_st...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-tgl-y/igt@gem_exec_st...@basic.html
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][15] ([i915#1888]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-tgl-y/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-dpms@d-dsi1:
- {fi-tgl-dsi}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-tgl-dsi/igt@kms_flip@basic-flip-vs-d...@d-dsi1.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18244/fi-tgl-dsi/igt@kms_flip@basic-flip-vs-d...@d-dsi1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][25] ([i915#2203]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8793/fi-skl-guc/igt@kms_flip@ba
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reduce register reads around GT interrupts
== Series Details ==
Series: drm/i915: Reduce register reads around GT interrupts
URL : https://patchwork.freedesktop.org/series/79919/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84189faf3bc4 drm/i915: Reduce register reads around GT interrupts
-:73: WARNING:LINE_SPACING: Missing a blank line after declarations
#73: FILE: drivers/gpu/drm/i915/i915_irq.c:2126:
+ u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
+ if (pm_iir) {
total: 0 errors, 1 warnings, 0 checks, 91 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reduce register reads around GT interrupts
The GT subsystem is highly dependent on interrupts for driving the GPU;
while the interrupt is being processed the GPU may idle leading to lower
throughput and higher latency. Since the GT interrupts dominate, push
the incidental display interrupt handling to later.
gem_exec_nop/parallel on ivb [i7-3720QM]:
Before:
average (individually): 2.278us
rcs0: 8337674 cycles, 2.399us
vcs0: 3286990 cycles, 6.085us
bcs0: 2047917 cycles, 9.766us
After:
average (individually): 2.118us
rcs0: 10132462 cycles, 1.974us
bcs0: 3667130 cycles, 5.454us
vcs0: 3616618 cycles, 5.530us
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 58 +
1 file changed, 30 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1fa67700d8f4..e156de88bdc6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2099,29 +2099,16 @@ static irqreturn_t ilk_irq_handler(int irq, void *arg)
{
struct drm_i915_private *i915 = arg;
void __iomem * const regs = i915->uncore.regs;
- u32 de_iir, gt_iir, de_ier, sde_ier = 0;
+ u32 de_iir, gt_iir, de_ier;
irqreturn_t ret = IRQ_NONE;
if (unlikely(!intel_irqs_enabled(i915)))
return IRQ_NONE;
- /* IRQs are synced during runtime_suspend, we don't require a wakeref */
- disable_rpm_wakeref_asserts(&i915->runtime_pm);
-
/* disable master interrupt before clearing iir */
de_ier = raw_reg_read(regs, DEIER);
raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
- /* Disable south interrupts. We'll only write to SDEIIR once, so further
-* interrupts will will be stored on its back queue, and then we'll be
-* able to process them after we restore SDEIER (as soon as we restore
-* it, we'll get an interrupt if SDEIIR still has something to process
-* due to its back queue). */
- if (!HAS_PCH_NOP(i915)) {
- sde_ier = raw_reg_read(regs, SDEIER);
- raw_reg_write(regs, SDEIER, 0);
- }
-
/* Find, clear, then process each source of interrupt */
gt_iir = raw_reg_read(regs, GTIIR);
@@ -2134,32 +2121,47 @@ static irqreturn_t ilk_irq_handler(int irq, void *arg)
ret = IRQ_HANDLED;
}
+ if (INTEL_GEN(i915) >= 6) {
+ u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
+ if (pm_iir) {
+ raw_reg_write(regs, GEN6_PMIIR, pm_iir);
+ gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
+ ret = IRQ_HANDLED;
+ }
+ }
+
de_iir = raw_reg_read(regs, DEIIR);
if (de_iir) {
+ u32 sde_ier = 0;
+
+ /*
+* Disable south interrupts. We'll only write to SDEIIR once,
+* so further interrupts will will be stored on its back queue,
+* and then we'll be able to process them after we restore
+* SDEIER (as soon as we restore it, we'll get an interrupt if
+* SDEIIR still has something to process due to its back queue).
+*/
+ if (!HAS_PCH_NOP(i915)) {
+ sde_ier = raw_reg_read(regs, SDEIER);
+ raw_reg_write(regs, SDEIER, 0);
+ }
+
+ disable_rpm_wakeref_asserts(&i915->runtime_pm);
+
raw_reg_write(regs, DEIIR, de_iir);
if (INTEL_GEN(i915) >= 7)
ivb_display_irq_handler(i915, de_iir);
else
ilk_display_irq_handler(i915, de_iir);
+
+ enable_rpm_wakeref_asserts(&i915->runtime_pm);
ret = IRQ_HANDLED;
- }
- if (INTEL_GEN(i915) >= 6) {
- u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
- if (pm_iir) {
- raw_reg_write(regs, GEN6_PMIIR, pm_iir);
- gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
- ret = IRQ_HANDLED;
- }
+ if (sde_ier)
+ raw_reg_write(regs, SDEIER, sde_ier);
}
raw_reg_write(regs, DEIER, de_ier);
- if (sde_ier)
- raw_reg_write(regs, SDEIER, sde_ier);
-
- /* IRQs are synced during runtime_suspend, we don't require a wakeref */
- enable_rpm_wakeref_asserts(&i915->runtime_pm);
-
return ret;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 00/16] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote: > Hi All, > > Here is v5 of my patch series converting the i915 driver's code for > controlling the panel's backlight with an external PWM controller to > use the atomic PWM API. See below for the changelog. > > This series consists of 4 parts: > > 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness > 2. various fixes to the pwm-lpss driver > 3. convert the pwm-crc driver to support the atomic PWM API and > 4. convert the i915 driver's PWM code to use the atomic PWM API > > The involved acpi_lpss and pwm drivers do not see a whole lot of churn, > so the plan is to merge this all through drm-intel-next-queued (dinq) > once all the patches are reviewed / have acks. > > Specifically patches 5-9, 11 still need an Acked- / Reviewed-by > > Andy, can you please take a look at the unreviewed patches? Specifically > patches 5-6 should address your review remarks from v4 of this set > and I've addressed your review remarks on patches 7-9 in v3 already. > A review of patch 11 would also be welcome > > Uwe, can you please take a look at the unreviewed patches? > > Uwe, may I have your Acked-by for merging this series through the > drm-intel-next-queued branch once all PWM patches have an Acked- or > Reviewed-by ? > > This series has been tested (and re-tested after adding various bug-fixes) > extensively. It has been tested on the following devices: > > -Asus T100TA BYT + CRC-PMIC PWM > -Toshiba WT8-A BYT + CRC-PMIC PWM > -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM > -Asus T100HA CHT + CRC-PMIC PWM > -Terra Pad 1061 BYT + LPSS PWM > -Trekstor Twin 10.1 BYT + LPSS PWM > -Asus T101HA CHT + CRC-PMIC PWM > -GPD Pocket CHT + CRC-PMIC PWM > > Changelog: > Changes in v5: > - Dropped the "pwm: lpss: Correct get_state result for base_unit == 0" > patch. The base_unit == 0 condition should never happen and sofar it is > unclear what the proper behavior / correct values to store in the > pwm_state should be when this does happen. Since this patch was added as > an extra pwm-lpss fix in v4 of this patch-set and otherwise is orthogonal > to the of this patch-set just drop it (again). > - "[PATCH 04/16] pwm: lpss: Add range limit check for the base_unit register > value" > - Use clamp_val(... instead of clam_t(unsigned long long, ... > - "[PATCH 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper" > - This is a new patch in v5 of this patchset > - [PATCH 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume > - Use the new pwm_lpss_prepare_enable() helper > > Changes in v4: > - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0" > - This is a new patch in v4 of this patchset > - "[PATCH v4 12/16] pwm: crc: Implement get_state() method" > - Use DIV_ROUND_UP when calculating the period and duty_cycle values > - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an > external PWM controller" > - Add a note to the commit message about the changes in > pwm_disable_backlight() > - Use the pwm_set/get_relative_duty_cycle() helpers > > Changes in v3: > - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit > register value" > - Use base_unit_range - 1 as maximum value for the clamp() > - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on > resume" > - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" > patch from previous versions of this patch-set, which really was a hack > working around the resume issue which this patch fixes properly. > - PATCH v3 6 - 11 pwm-crc changes: > - Various small changes resulting from the reviews by Andy and Uwe, > including some refactoring of the patches to reduce the amount of churn > in the patch-set > > Changes in v2: > - Fix coverletter subject > - Drop accidentally included debugging patch > - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only > once ( > - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX Hi Hans, I've applied patches 3 through 12 to the PWM tree. I thought it was a bit odd that only a handful of these patches had been reviewed and there were no Tested-bys, but I'm going to trust that you know what you're doing. =) If this breaks things for anyone I'm sure they'll complain. That said I see that Rafael has acked patches 1-2 and Jani did so for patches 13-16. I'm not sure if you expect me to pick those patches up as well. As far as I can tell the ACPI, PWM and DRM parts are all independent, so these patches could be applied to the corresponding subsystem trees. Anyway, if you want me to pick those all up into the PWM tree, I suppose that's something I can do as well. Thierry signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
