Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: remove unneeded clflush calls
On Wed, Sep 15, 2021 at 12:29:12PM -0700, John Harrison wrote: On 9/15/2021 12:24, Belgaumkar, Vinay wrote: On 9/14/2021 12:51 PM, Lucas De Marchi wrote: The clflush calls here aren't doing anything since we are not writting something and flushing the cache lines to be visible to GuC. Here the intention seems to be to make sure whatever GuC has written is visible to the CPU before we read them. However a clflush from the CPU side is the wrong instruction to use. Is there a right instruction to use? Either we need to verify that no how can there be a right instruction? If the GuC needs to flush, then the GuC needs to do it, nothing to be done by the CPU. Flushing the CPU cache line here is doing nothing to guarantee that what was written by GuC hit the memory and we are reading it. Not sure why it was actually added, but since it was added by Vinay and he reviewed this patch, I'm assuming he also agrees Lucas De Marchi
Re: [Intel-gfx] [PATCH 3/3] drm/i915: remove some debug-only registers from MCHBAR
On Tue, Sep 07, 2021 at 02:56:21PM -0700, Lucas De Marchi wrote:
On Tue, Jul 06, 2021 at 04:44:30PM -0700, Lucas De Marchi wrote:
On Thu, Nov 05, 2020 at 10:02:27AM +0200, Joonas Lahtinen wrote:
Quoting Lucas De Marchi (2020-11-05 03:04:22)
On Wed, Nov 04, 2020 at 11:55:15AM +0200, Joonas Lahtinen wrote:
Quoting Lucas De Marchi (2020-10-27 06:46:18)
GT_PERF_STATUS and RP_STATE_LIMITS were added a long time ago in
commit 3b8d8d91d51c ("drm/i915: dynamic render p-state support for Sandy
Bridge"). Other than printing their values in debugfs we don't do
anything with them. There's not much useful information in them. These
registers may change location in future platforms, but instead of adding
new locations, it's simpler to just remove them.
This code seems to have been updated for Gen9LP, so that would indicate
the debugging information is useful, right? The value is even decoded, not
simply dumped as most registers. So I would be hesitant to drop it for
not being useful.
but just updating the register in itself for a new gen doesn't mean it's
actually useful... the commit message where this happened is pretty
vague: 350405623ff3 ("drm/i915: Update rps frequencies for BXT")
My first reaction would be to do the same if the register had moved or
if it ceased to exist in a new platform. Talking with Matt Roper some
time ago we arrived to the conclusion that just printing these values is
not giving us much benefit and it could very well be accomplished by
intel_reg.
So answering the question: is it really useful as is? IMO, no.
A quick discussion on #intel-gfx seems to indicate it was used for
bug triaging in the past year. So that would indicate it is still
useful to include.
getting back to this as we are trying to upstream XeHP-SDV that doesn't
have access to the MCHBAR. So do you think we should just make it
conditional instead of removing?
I'm still on the side that this additional code doesn't bring much value
and could be replaced by intel-reg.
ping?
So let's not remove it.
The second question is why we have a huge block of 1-to-1 duplicated
code in there. Has there been an incorrect merge or some transition has
been left mid-way?
the deduplication has now being merged together with fixing of the file
names: https://patchwork.freedesktop.org/series/94827/
Back to the previous question... Does the silence here mean
there is no interest to block this anymore?
As noted by me and Matt Roper there is very little value in keeping
this. Even if it was used once in a year for bug triaging, it could very
well had used intel_reg - this is just adding to the maintenance
burden for new platforms. Who used it so I can talk to the person to
understand the gap? Adding some more people in Cc who could possibly
know.
thanks
Lucas De Marchi
not a bad merge, no. It seems to be to preserve the previous file
location since now it moved to be inside a gt dir. Long term I think
this is bad both because of the code duplication and because it's easy
to update one and forget the other.
I started a discussion in the thread of the original patch which called
to move code but left the old code in place too, effectively copying it.
When this path was written and such code duplication noticed, would have
been good to highlight or address the code duplication.
yes, but it doesn't mean there will be an action regarding that, as can
be noticed since that duplication is still there today and this patch
applies cleanly :-/... and they had slightly different changes according
to
git log -L:frequency_show:drivers/gpu/drm/i915/gt/debugfs_gt_pm.c \
-L:i915_frequency_info:drivers/gpu/drm/i915/i915_debugfs.c
Just took a look for a potential deduplication fix there:
https://patchwork.freedesktop.org/series/94455/
Lucas De Marchi
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Fix the dsc check while selecting min_cdclk (rev3)
== Series Details == Series: drm/i915/display: Fix the dsc check while selecting min_cdclk (rev3) URL : https://patchwork.freedesktop.org/series/94683/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10615_full -> Patchwork_21104_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21104_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21104_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_21104_full: ### IGT changes ### Possible regressions * igt@kms_big_fb@x-tiled-16bpp-rotate-180: - shard-apl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-apl7/igt@kms_big...@x-tiled-16bpp-rotate-180.html - shard-kbl: NOTRUN -> [INCOMPLETE][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-kbl4/igt@kms_big...@x-tiled-16bpp-rotate-180.html * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-tglb3/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-tglb5/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-iclb: NOTRUN -> [INCOMPLETE][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-iclb1/igt@kms_plane_multi...@atomic-pipe-b-tiling-yf.html Warnings * igt@i915_module_load@reload: - shard-iclb: [INCOMPLETE][6] ([i915#4130]) -> [INCOMPLETE][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-iclb8/igt@i915_module_l...@reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-iclb1/igt@i915_module_l...@reload.html Known issues Here are the changes found in Patchwork_21104_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#456]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-tglb3/igt@gem_ctx_isolation@preservation...@bcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-tglb7/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +4 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-kbl3/igt@gem_ctx_isolation@preservation...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-kbl6/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][14] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-tglb3/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_schedule@semaphore-codependency: - shard-snb: NOTRUN -> [SKIP][19] ([fdo#109271]) +79 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-snb2/igt@gem_exec_sched...@semaphore-codependency.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/shard-kbl2/igt@gem_huc_c...@huc-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRU
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Check SFC fusing on Xe_HP (rev4)
On Tue, Sep 21, 2021 at 02:13:42AM +, Patchwork wrote:
> == Series Details ==
>
> Series: Check SFC fusing on Xe_HP (rev4)
> URL : https://patchwork.freedesktop.org/series/94808/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10613_full -> Patchwork_21099_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_21099_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21099_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_21099_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_module_load@reload:
> - shard-kbl: NOTRUN -> [INCOMPLETE][1]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-kbl7/igt@i915_module_l...@reload.html
snd_hda_intel "spurious response" errors, followed by "NMI watchdog:
Watchdog detected hard LOCKUP on cpu 1", originating from snd_hda_core.
We've been seeing this on several series since the 5.15rc1 merge. Not
quite the same signature as fdo#4179 (which are pagefaults rather than
CPU lockups), but likely somehow related to the same underlying root
cause.
>
> * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:
> - shard-tglb: [PASS][2] -> [INCOMPLETE][3]
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-tglb2/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-tglb5/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html
Another sound-related failure, this time coming from snd_hda_intel
(rather than snd_hda_core). Again not quite a match for any of the fdo
issues we have open, but likely related to the same underlying issue.
>
> * igt@kms_plane_cursor@pipe-b-primary-size-64:
> - shard-glk: [PASS][4] -> [FAIL][5]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-glk2/igt@kms_plane_cur...@pipe-b-primary-size-64.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-glk4/igt@kms_plane_cur...@pipe-b-primary-size-64.html
Similar to https://gitlab.freedesktop.org/drm/intel/-/issues/4153,
although on the -64 subtest instead of -128, and on GLK instead of ICL.
But a display-related CRC mismatch like this can't be related to
checking the media fuse bits on Xe_HP platforms.
None of the issues reported here are related to this series. Applied to
drm-intel-gt-next. Thanks Jose for the review.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_module_load@reload:
> - {shard-rkl}:NOTRUN -> [INCOMPLETE][6]
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-rkl-1/igt@i915_module_l...@reload.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_21099_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@core_hotunplug@unbind-rebind:
> - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([i915#4130])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-glk7/igt@core_hotunp...@unbind-rebind.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-glk3/igt@core_hotunp...@unbind-rebind.html
>
> * igt@gem_create@create-massive:
> - shard-tglb: NOTRUN -> [DMESG-WARN][9] ([i915#3002])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-tglb6/igt@gem_cre...@create-massive.html
> - shard-apl: NOTRUN -> [DMESG-WARN][10] ([i915#3002])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-apl7/igt@gem_cre...@create-massive.html
>
> * igt@gem_ctx_persistence@legacy-engines-queued:
> - shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1099])
> +3 similar issues
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html
>
> * igt@gem_eio@in-flight-contexts-10ms:
> - shard-tglb: [PASS][12] -> [TIMEOUT][13] ([i915#3063])
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-tglb8/igt@gem_...@in-flight-contexts-10ms.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-tglb6/igt@gem_...@in-flight-contexts-10ms.html
>
> * igt@gem_eio@unwedge-stress:
> - shard-tglb: [PASS][14] -> [TIMEOUT][15] ([i915#2369] /
> [i915#3063] / [i915#3648])
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix the dsc check while selecting min_cdclk (rev3)
== Series Details ==
Series: drm/i915/display: Fix the dsc check while selecting min_cdclk (rev3)
URL : https://patchwork.freedesktop.org/series/94683/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10615 -> Patchwork_21104
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_21104 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21104, 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_21104/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21104:
### IGT changes ###
Warnings
* igt@i915_module_load@reload:
- fi-skl-6600u: [INCOMPLETE][1] ([i915#4130]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-skl-6600u/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-skl-6600u/igt@i915_module_l...@reload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-ehl-2}: [INCOMPLETE][3] ([i915#4136]) -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-ehl-2/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-ehl-2/igt@i915_module_l...@reload.html
- {fi-jsl-1}: [TIMEOUT][5] ([i915#4136]) -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-jsl-1/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-jsl-1/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_21104 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-sdma:
- fi-cfl-8109u: NOTRUN -> [SKIP][7] ([fdo#109271]) +17 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-cfl-8109u/igt@amdgpu/amd_ba...@cs-sdma.html
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][8] ([fdo#109271]) +27 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_basic@userptr:
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271]) +17 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-bxt-dsi/igt@amdgpu/amd_ba...@userptr.html
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-kbl-7567u: NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-kbl-7567u/igt@amdgpu/amd_cs_...@sync-gfx0.html
* igt@amdgpu/amd_prime@i915-to-amd:
- fi-snb-2520m: NOTRUN -> [SKIP][11] ([fdo#109271]) +18 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][12] ([i915#3718])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@i915_module_load@reload:
- fi-ivb-3770:[PASS][13] -> [INCOMPLETE][14] ([i915#4179])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-ivb-3770/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-ivb-3770/igt@i915_module_l...@reload.html
- fi-cfl-8109u: NOTRUN -> [DMESG-WARN][15] ([i915#4136])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-cfl-8109u/igt@i915_module_l...@reload.html
- fi-icl-y: [PASS][16] -> [INCOMPLETE][17] ([i915#4130])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-icl-y/igt@i915_module_l...@reload.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-icl-y/igt@i915_module_l...@reload.html
- fi-bsw-nick:[PASS][18] -> [INCOMPLETE][19] ([i915#4179])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-bsw-nick/igt@i915_module_l...@reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-bsw-nick/igt@i915_module_l...@reload.html
- fi-kbl-7500u: NOTRUN -> [INCOMPLETE][20] ([i915#4136])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-kbl-7500u/igt@i915_module_l...@reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +8
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21104/fi-bdw-5557u/igt@kms_chamel...@dp-cr
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tc: Fix TypeC connect/disconnect sequences
== Series Details == Series: drm/i915/tc: Fix TypeC connect/disconnect sequences URL : https://patchwork.freedesktop.org/series/94878/ State : success == Summary == CI Bug Log - changes from CI_DRM_10615_full -> Patchwork_21102_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_21102_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21102_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_21102_full: ### IGT changes ### Warnings * igt@device_reset@unbind-reset-rebind: - shard-glk: [INCOMPLETE][1] ([i915#4130]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-glk6/igt@device_re...@unbind-reset-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-glk4/igt@device_re...@unbind-reset-rebind.html * igt@i915_module_load@reload: - shard-iclb: [INCOMPLETE][3] ([i915#4130]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-iclb8/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-iclb1/igt@i915_module_l...@reload.html Known issues Here are the changes found in Patchwork_21102_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][5] ([i915#3002]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-snb7/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([i915#456]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-tglb3/igt@gem_ctx_isolation@preservation...@bcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-tglb7/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-snb7/igt@gem_ctx_persiste...@engines-hostile-preempt.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#3063] / [i915#3648]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-tglb1/igt@gem_...@unwedge-stress.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-glk8/igt@gem_exec_f...@basic-deadline.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-glk5/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_flush@basic-uc-ro-default: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/shard-skl1/igt@gem_exec_fl...@basic-uc-ro-default.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-skl4/igt@gem_exec_fl...@basic-uc-ro-default.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/shard-kbl6/igt@gem_huc_c...@huc-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][22] ([i915#2658]) [22]: https://intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Check SFC fusing on Xe_HP (rev4)
== Series Details ==
Series: Check SFC fusing on Xe_HP (rev4)
URL : https://patchwork.freedesktop.org/series/94808/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10613_full -> Patchwork_21099_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_21099_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21099_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_21099_full:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- shard-kbl: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-kbl7/igt@i915_module_l...@reload.html
* igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:
- shard-tglb: [PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-tglb2/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-tglb5/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html
* igt@kms_plane_cursor@pipe-b-primary-size-64:
- shard-glk: [PASS][4] -> [FAIL][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-glk2/igt@kms_plane_cur...@pipe-b-primary-size-64.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-glk4/igt@kms_plane_cur...@pipe-b-primary-size-64.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-rkl-1/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_21099_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- shard-glk: [PASS][7] -> [INCOMPLETE][8] ([i915#4130])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-glk7/igt@core_hotunp...@unbind-rebind.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-glk3/igt@core_hotunp...@unbind-rebind.html
* igt@gem_create@create-massive:
- shard-tglb: NOTRUN -> [DMESG-WARN][9] ([i915#3002])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-tglb6/igt@gem_cre...@create-massive.html
- shard-apl: NOTRUN -> [DMESG-WARN][10] ([i915#3002])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-apl7/igt@gem_cre...@create-massive.html
* igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1099]) +3
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html
* igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][12] -> [TIMEOUT][13] ([i915#3063])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-tglb8/igt@gem_...@in-flight-contexts-10ms.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-tglb6/igt@gem_...@in-flight-contexts-10ms.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][14] -> [TIMEOUT][15] ([i915#2369] /
[i915#3063] / [i915#3648])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-tglb5/igt@gem_...@unwedge-stress.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-tglb7/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: NOTRUN -> [FAIL][16] ([i915#2842])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][17] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][18] ([i915#2842])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#2842]) +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/shard-glk1/igt@gem_exec_fair@bas
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915/display: Disable frontbuffer rendering when PSR2 selective fetch is enabled
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Disable frontbuffer
rendering when PSR2 selective fetch is enabled
URL : https://patchwork.freedesktop.org/series/94879/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10615 -> Patchwork_21103
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_21103 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21103, 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_21103/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21103:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- fi-icl-y: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-icl-y/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-icl-y/igt@i915_module_l...@reload.html
Warnings
* igt@core_hotunplug@unbind-rebind:
- fi-bxt-dsi: [INCOMPLETE][3] ([i915#4130]) -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-ehl-2}: [INCOMPLETE][5] ([i915#4136]) -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-ehl-2/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-ehl-2/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_21103 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-cfl-guc: NOTRUN -> [SKIP][7] ([fdo#109271]) +17 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-cfl-guc/igt@amdgpu/amd_ba...@cs-compute.html
* igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][8] ([fdo#109315]) +17 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][9] ([fdo#109271]) +27 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][10] ([fdo#109315]) +17 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][11] ([fdo#109271]) +17 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][12] ([i915#3718])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@i915_module_load@reload:
- fi-ivb-3770:[PASS][13] -> [INCOMPLETE][14] ([i915#4179])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-ivb-3770/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-ivb-3770/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [PASS][15] -> [INCOMPLETE][16] ([i915#4179])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-bsw-kefka/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-bsw-kefka/igt@i915_module_l...@reload.html
- fi-glk-dsi: [PASS][17] -> [INCOMPLETE][18] ([i915#4130])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-glk-dsi/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-glk-dsi/igt@i915_module_l...@reload.html
- fi-snb-2600:[PASS][19] -> [INCOMPLETE][20] ([i915#4179])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-snb-2600/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21103/fi-snb-2600/igt@i915_module_l...@reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +8
similar issues
[21]:
https://intel-gfx-ci.01.o
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/3] drm/i915/display: Disable frontbuffer rendering when PSR2 selective fetch is enabled
== Series Details == Series: series starting with [v3,1/3] drm/i915/display: Disable frontbuffer rendering when PSR2 selective fetch is enabled URL : https://patchwork.freedesktop.org/series/94879/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlo
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/3] drm/i915/display: Disable frontbuffer rendering when PSR2 selective fetch is enabled
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Disable frontbuffer
rendering when PSR2 selective fetch is enabled
URL : https://patchwork.freedesktop.org/series/94879/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
32149725ef4a drm/i915/display: Disable frontbuffer rendering when PSR2
selective fetch is enabled
3db7b8dedb4c drm/i915/display: Only keep PSR enabled if there is active planes
-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#16:
commit 84030adb9e27 ("drm/i915/display: Disable audio, DRRS and PSR before
planes").
total: 0 errors, 1 warnings, 0 checks, 321 lines checked
15e05b6c4287 drm/i915/display/psr: Do full fetch when handling biplanar formats
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: Fix TypeC connect/disconnect sequences
== Series Details == Series: drm/i915/tc: Fix TypeC connect/disconnect sequences URL : https://patchwork.freedesktop.org/series/94878/ State : success == Summary == CI Bug Log - changes from CI_DRM_10615 -> Patchwork_21102 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/index.html Known issues Here are the changes found in Patchwork_21102 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-cfl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-cfl-guc/igt@amdgpu/amd_ba...@cs-compute.html * igt@amdgpu/amd_basic@cs-sdma: - fi-kbl-7500u: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-kbl-7567u: NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-kbl-7567u/igt@amdgpu/amd_cs_...@sync-gfx0.html * igt@amdgpu/amd_prime@i915-to-amd: - fi-snb-2520m: NOTRUN -> [SKIP][6] ([fdo#109271]) +18 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html * igt@core_hotunplug@unbind-rebind: - fi-rkl-11600: [PASS][7] -> [INCOMPLETE][8] ([i915#4130]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-rkl-11600/igt@core_hotunp...@unbind-rebind.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-rkl-11600/igt@core_hotunp...@unbind-rebind.html - fi-bdw-5557u: NOTRUN -> [WARN][9] ([i915#3718]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_module_load@reload: - fi-icl-u2: NOTRUN -> [INCOMPLETE][10] ([i915#4130] / [i915#4179]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-icl-u2/igt@i915_module_l...@reload.html - fi-glk-dsi: [PASS][11] -> [INCOMPLETE][12] ([i915#4130]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-glk-dsi/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-glk-dsi/igt@i915_module_l...@reload.html - fi-cfl-8109u: NOTRUN -> [INCOMPLETE][13] ([i915#4130] / [i915#4179]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-cfl-8109u/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-rkl-guc: [PASS][14] -> [SKIP][15] ([fdo#109308]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-rkl-guc/igt@i915_pm_...@basic-pci-d3-state.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-rkl-guc/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@gtt: - fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][16] ([i915#3674]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@runner@aborted: - fi-cfl-8109u: NOTRUN -> [FAIL][18] ([i915#2426] / [i915#3363]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-cfl-8109u/igt@run...@aborted.html - fi-icl-u2: NOTRUN -> [FAIL][19] ([i915#2426] / [i915#3363] / [i915#3690] / [i915#4136]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-icl-u2/igt@run...@aborted.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-cfl-guc: [INCOMPLETE][20] ([i915#4130]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-cfl-guc/igt@core_hotunp...@unbind-rebind.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21102/fi-cfl-guc/igt@core_hotunp...@unbind-rebind.html - fi-icl-u2: [INCOMPLETE][22] ([i915#4130]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10615/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html [23]: https://intel-gfx-ci.01.org
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Check SFC fusing on Xe_HP (rev4)
Created a new issue for the regression failures and re-reported.
https://gitlab.freedesktop.org/drm/intel/-/issues/4179
Lakshmi.
-Original Message-
From: Roper, Matthew D
Sent: Monday, September 20, 2021 1:25 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.BAT: failure for Check SFC fusing on Xe_HP (rev4)
On Mon, Sep 20, 2021 at 06:55:52PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Check SFC fusing on Xe_HP (rev4)
> URL : https://patchwork.freedesktop.org/series/94808/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10613 -> Patchwork_21099
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_21099 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21099, 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_21099/index.html
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_21099:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_module_load@reload:
> - fi-snb-2520m: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-snb-2520m/igt@i915_module_l...@reload.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-snb-2520m/igt@i915_module_l...@reload.html
> - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-kefka/igt@i915_module_l...@reload.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-kefka/igt@i915_module_l...@reload.html
> - fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-nick/igt@i915_module_l...@reload.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-nick/i
> gt@i915_module_l...@reload.html
All three of these are page faults originating from the snd_hda_core code.
There seem to be a lot of problems originating from the sound code that came in
with the 5.15-rc1 merge; these aren't caused by the SFC fusing checks in this
series.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_module_load@reload:
> - {fi-jsl-1}: [INCOMPLETE][7] ([i915#4130]) -> [INCOMPLETE][8]
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-jsl-1/igt@i915_module_l...@reload.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-jsl-1/igt@
> i915_module_l...@reload.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_21099 that come from known issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@amdgpu/amd_basic@semaphore:
> - fi-bdw-5557u: NOTRUN -> [SKIP][9] ([fdo#109271]) +27 similar
> issues
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/
> igt@amdgpu/amd_ba...@semaphore.html
>
> * igt@amdgpu/amd_basic@userptr:
> - fi-bxt-dsi: NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar
> issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bxt-dsi/ig
> t@amdgpu/amd_ba...@userptr.html
>
> * igt@amdgpu/amd_cs_nop@fork-gfx0:
> - fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#109315]) +17 similar
> issues
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-icl-u2/igt
> @amdgpu/amd_cs_...@fork-gfx0.html
>
> * igt@amdgpu/amd_cs_nop@sync-gfx0:
> - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109315]) +17 similar
> issues
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-11600/
> igt@amdgpu/amd_cs_...@sync-gfx0.html
>
> * igt@core_hotunplug@unbind-rebind:
> - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][13] ([i915#4130])
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
> - fi-kbl-7567u: [PASS][14] -> [INCOMPLETE][15] ([i915#4130])
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
> - fi-bdw-5557u: NOTRUN -> [WARN][16] ([i915#3718])
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/
> igt@core_hotunp...@unbind-rebind.html
>
> * igt@gem_exec_suspend@basic-s3:
> - fi-tgl-1115g4: NOTRUN -> [FAI
[Intel-gfx] ✓ Fi.CI.BAT: success for Check SFC fusing on Xe_HP (rev4)
== Series Details ==
Series: Check SFC fusing on Xe_HP (rev4)
URL : https://patchwork.freedesktop.org/series/94808/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10613 -> Patchwork_21099
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21099:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-jsl-1}: [INCOMPLETE][1] ([i915#4130]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-jsl-1/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-jsl-1/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_21099 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_basic@userptr:
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bxt-dsi/igt@amdgpu/amd_ba...@userptr.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][5] ([fdo#109315]) +17 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([fdo#109315]) +17 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-11600/igt@amdgpu/amd_cs_...@sync-gfx0.html
* igt@core_hotunplug@unbind-rebind:
- fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][7] ([i915#4130])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
- fi-kbl-7567u: [PASS][8] -> [INCOMPLETE][9] ([i915#4130])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
- fi-bdw-5557u: NOTRUN -> [WARN][10] ([i915#3718])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4: NOTRUN -> [FAIL][11] ([i915#1888])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#2190])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- fi-snb-2520m: [PASS][13] -> [INCOMPLETE][14] ([i915#4179])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-snb-2520m/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-snb-2520m/igt@i915_module_l...@reload.html
- fi-rkl-guc: [PASS][15] -> [DMESG-WARN][16] ([i915#4136])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-rkl-guc/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-guc/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [PASS][17] -> [INCOMPLETE][18] ([i915#4179])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-kefka/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-kefka/igt@i915_module_l...@reload.html
- fi-cfl-8109u: NOTRUN -> [INCOMPLETE][19] ([i915#4136])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-cfl-8109u/igt@i915_module_l...@reload.html
- fi-icl-y: [PASS][20] -> [INCOMPLETE][21] ([i915#4130])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-icl-y/igt@i915_module_l...@reload.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-icl-y/igt@i915_module_l...@reload.html
- fi-bsw-nick:[PASS][22] -> [INCOMPLETE][23] ([i915#4179])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-nick/igt@i915_module_l...@reload.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-nick/igt@i915_module_l...@reload.html
- fi-kbl-7500u: NOTRUN -> [INCOMPLETE][24] ([i915#4130])
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwor
[Intel-gfx] ✗ Fi.CI.BAT: failure for Check SFC fusing on Xe_HP (rev4)
== Series Details ==
Series: Check SFC fusing on Xe_HP (rev4)
URL : https://patchwork.freedesktop.org/series/94808/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10613 -> Patchwork_21099
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_21099 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21099, 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_21099/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21099:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- fi-bsw-kefka: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-kefka/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-kefka/igt@i915_module_l...@reload.html
- fi-bsw-nick:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-nick/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-nick/igt@i915_module_l...@reload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-jsl-1}: [INCOMPLETE][5] ([i915#4130]) -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-jsl-1/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-jsl-1/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_21099 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][7] ([fdo#109271]) +27 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_basic@userptr:
- fi-bxt-dsi: NOTRUN -> [SKIP][8] ([fdo#109271]) +17 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bxt-dsi/igt@amdgpu/amd_ba...@userptr.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([fdo#109315]) +17 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([fdo#109315]) +17 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-11600/igt@amdgpu/amd_cs_...@sync-gfx0.html
* igt@core_hotunplug@unbind-rebind:
- fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][11] ([i915#4130])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
- fi-kbl-7567u: [PASS][12] -> [INCOMPLETE][13] ([i915#4130])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
- fi-bdw-5557u: NOTRUN -> [WARN][14] ([i915#3718])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4: NOTRUN -> [FAIL][15] ([i915#1888])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4: NOTRUN -> [SKIP][16] ([i915#2190])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- fi-snb-2520m: [PASS][17] -> [INCOMPLETE][18] ([i915#4179])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-snb-2520m/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-snb-2520m/igt@i915_module_l...@reload.html
- fi-rkl-guc: [PASS][19] -> [DMESG-WARN][20] ([i915#4136])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-rkl-guc/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-guc/igt@i915_module_l...@reload.html
- fi-cfl-8109u: NOTRUN -> [INCOMPLETE][21] ([i915#4136])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-cfl-8109u/igt@i915_module_l...@reload.html
- fi-icl-y: [PASS][22] -> [INCOMPLETE][23] ([i915#4130])
[Intel-gfx] [PATCH v3 2/3] drm/i915/display: Only keep PSR enabled if there is active planes
PSR always had a requirement to only be enabled if there is active
planes but not following that never caused any issues.
But that changes in Alderlake-P, leaving PSR enabled without
active planes causes transcoder/port underruns.
Similar behavior was fixed during the pipe disable sequence by
commit 84030adb9e27 ("drm/i915/display: Disable audio, DRRS and PSR before
planes").
intel_dp_compute_psr_vsc_sdp() had to move from
intel_psr_enable_locked() to intel_psr_compute_config() because we
need to be able to disable/enable PSR from atomic states without
connector and encoder state.
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 -
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
.../drm/i915/display/intel_display_types.h| 3 +-
drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 140 ++
drivers/gpu/drm/i915/display/intel_psr.h | 11 +-
7 files changed, 98 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bba0ab99836b1..a4667741d3548 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3034,7 +3034,6 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
intel_dp_stop_link_train(intel_dp, crtc_state);
intel_edp_backlight_on(crtc_state, conn_state);
- intel_psr_enable(intel_dp, crtc_state, conn_state);
if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
@@ -3255,7 +3254,6 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_ddi_set_dp_msa(crtc_state, conn_state);
- intel_psr_update(intel_dp, crtc_state, conn_state);
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_drrs_update(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f6c0c595f6313..ddcd8d6efc788 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8093,10 +8093,12 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
if (bp_gamma)
PIPE_CONF_CHECK_COLOR_LUT(gamma_mode, hw.gamma_lut,
bp_gamma);
- PIPE_CONF_CHECK_BOOL(has_psr);
- PIPE_CONF_CHECK_BOOL(has_psr2);
- PIPE_CONF_CHECK_BOOL(enable_psr2_sel_fetch);
- PIPE_CONF_CHECK_I(dc3co_exitline);
+ if (current_config->active_planes) {
+ PIPE_CONF_CHECK_BOOL(has_psr);
+ PIPE_CONF_CHECK_BOOL(has_psr2);
+ PIPE_CONF_CHECK_BOOL(enable_psr2_sel_fetch);
+ PIPE_CONF_CHECK_I(dc3co_exitline);
+ }
}
PIPE_CONF_CHECK_BOOL(double_wide);
@@ -8153,7 +8155,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_I(min_voltage_level);
}
- if (fastset && (current_config->has_psr || pipe_config->has_psr))
+ if (current_config->has_psr || pipe_config->has_psr)
PIPE_CONF_CHECK_X_WITH_MASK(infoframes.enable,
~intel_hdmi_infoframe_enable(DP_SDP_VSC));
else
@@ -10207,6 +10209,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_encoders_update_prepare(state);
intel_dbuf_pre_plane_update(state);
+ intel_psr_pre_plane_update(state);
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->uapi.async_flip)
@@ -10270,6 +10273,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
}
intel_dbuf_post_plane_update(state);
+ intel_psr_post_plane_update(state);
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
intel_post_plane_update(state, crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e9e806d90eec4..c900bfbb7cc52 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1056,12 +1056,14 @@ struct intel_crtc_state {
struct intel_link_m_n dp_m2_n2;
bool has_drrs;
+ /* PSR is supported but might not be enabled due the lack of enabled
planes */
bool has_psr;
bool has_psr2;
bool enable_psr2_sel_fetch;
bool req_psr2_sdp_prior_scanline;
u32 dc3co_exitline;
u16 su_y_granularity;
[Intel-gfx] [PATCH v3 3/3] drm/i915/display/psr: Do full fetch when handling biplanar formats
From: Gwan-gyeong Mun
We are still missing the PSR2 selective fetch handling of biplanar
formats but until proper handle is added we can workaround it by
doing full frames fetch when state has biplanar formats.
We need the second check because an update in a regular format could
intersect with a biplanar plane that was not initialy part of the
atomic commit.
Signed-off-by: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 8ceb22c5a1a6b..e6a4c27975d8c 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1601,9 +1601,13 @@ int intel_psr2_sel_fetch_update(struct
intel_atomic_state *state,
* TODO: Not clear how to handle planes with negative position,
* also planes are not updated if they have a negative X
* position so for now doing a full update in this cases
+*
+* TODO: We are missing biplanar formats handling, until it is
+* implemented it will send full frame updates.
*/
if (new_plane_state->uapi.dst.y1 < 0 ||
- new_plane_state->uapi.dst.x1 < 0) {
+ new_plane_state->uapi.dst.x1 < 0 ||
+ new_plane_state->hw.fb->format->is_yuv) {
full_update = true;
break;
}
@@ -1682,6 +1686,11 @@ int intel_psr2_sel_fetch_update(struct
intel_atomic_state *state,
if (!drm_rect_intersect(&inter, &new_plane_state->uapi.dst))
continue;
+ if (new_plane_state->hw.fb->format->is_yuv) {
+ full_update = true;
+ break;
+ }
+
sel_fetch_area = &new_plane_state->psr2_sel_fetch_area;
sel_fetch_area->y1 = inter.y1 - new_plane_state->uapi.dst.y1;
sel_fetch_area->y2 = inter.y2 - new_plane_state->uapi.dst.y1;
--
2.33.0
[Intel-gfx] [PATCH v3 1/3] drm/i915/display: Disable frontbuffer rendering when PSR2 selective fetch is enabled
By now all the userspace applications should have migrated to atomic
or at least be calling DRM_IOCTL_MODE_DIRTYFB.
But we still can't kill frontbuffer rendering support for good as
we have some performance issues to be solved in desktop environments
that do not use compositors.
But PSR2 selective fetch is not compatible with frontbuffer rendering
so here dropping frontbuffer rendering support when
enable_psr2_sel_fetch is set.
This way we leave for OEM and users the decision of enable this
feature or not.
Here converting legacy APIs into atomic commits so it can be properly
handled by driver i915.
v2:
- return earlier to not set fb_tracking.busy/flip_bits
- added a warn on to make sure we are not setting the busy/flip_bits
v3:
- only dropping frontbuffer rendering support when
enable_psr2_sel_fetch is set
Reviewed-by: Gwan-gyeong Mun # v2
Cc: Daniel Vetter
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_cursor.c| 3 ++-
drivers/gpu/drm/i915/display/intel_fb.c| 8 +++-
.../gpu/drm/i915/display/intel_frontbuffer.c | 18 ++
drivers/gpu/drm/i915/i915_drv.h| 2 ++
4 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index c7618fef01439..7686446c29c13 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -617,6 +617,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
u32 src_w, u32 src_h,
struct drm_modeset_acquire_ctx *ctx)
{
+ struct drm_i915_private *i915 = to_i915(_crtc->dev);
struct intel_plane *plane = to_intel_plane(_plane);
struct intel_crtc *crtc = to_intel_crtc(_crtc);
struct intel_plane_state *old_plane_state =
@@ -638,7 +639,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
*/
if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
crtc_state->update_pipe || crtc_state->bigjoiner ||
- crtc_state->enable_psr2_sel_fetch)
+ !HAS_FRONTBUFFER_RENDERING(i915))
goto slow;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index e4b8602ec0cd2..3eb60785c9f29 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -3,6 +3,7 @@
* Copyright © 2021 Intel Corporation
*/
+#include
#include
#include
@@ -1235,10 +1236,15 @@ static int intel_user_framebuffer_dirty(struct
drm_framebuffer *fb,
unsigned int num_clips)
{
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
i915_gem_object_flush_if_display(obj);
- intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
+ if (!HAS_FRONTBUFFER_RENDERING(i915))
+ return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
+num_clips);
+
+ intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 0492446cd04ad..3860f87dac31c 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -112,6 +112,9 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
unsigned frontbuffer_bits)
{
+ if (!HAS_FRONTBUFFER_RENDERING(i915))
+ return;
+
spin_lock(&i915->fb_tracking.lock);
i915->fb_tracking.flip_bits |= frontbuffer_bits;
/* Remove stale busy bits due to the old buffer. */
@@ -132,6 +135,12 @@ void intel_frontbuffer_flip_prepare(struct
drm_i915_private *i915,
void intel_frontbuffer_flip_complete(struct drm_i915_private *i915,
unsigned frontbuffer_bits)
{
+ if (!HAS_FRONTBUFFER_RENDERING(i915)) {
+ drm_WARN_ON_ONCE(&i915->drm, i915->fb_tracking.flip_bits |
+i915->fb_tracking.busy_bits);
+ return;
+ }
+
spin_lock(&i915->fb_tracking.lock);
/* Mask any cancelled flips. */
frontbuffer_bits &= i915->fb_tracking.flip_bits;
@@ -156,6 +165,9 @@ void intel_frontbuffer_flip_complete(struct
drm_i915_private *i915,
void intel_frontbuffer_flip(struct drm_i915_private *i915,
unsigned frontbuffer_bits)
{
+ if (!HAS_FRONTBUFFER_RENDERING(i915))
+ return;
+
spin_lock(&i915->fb_tracking.lock);
/* Remove sta
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tc: Fix TypeC connect/disconnect sequences
== Series Details == Series: drm/i915/tc: Fix TypeC connect/disconnect sequences URL : https://patchwork.freedesktop.org/series/94878/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen8_write32' - diff
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tc: Fix TypeC connect/disconnect sequences
== Series Details ==
Series: drm/i915/tc: Fix TypeC connect/disconnect sequences
URL : https://patchwork.freedesktop.org/series/94878/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9d2a21b4286f drm/i915/tc: Fix TypeC port init/resume time sanitization
8cf6d77baac7 drm/i915/adlp/tc: Fix PHY connected check for Thunderbolt mode
3a96d2e03bbf drm/i915/tc: Remove waiting for PHY complete during releasing
ownership
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#13:
commit ddec362724f9 ("drm/i915: Wait for TypeC PHY complete flag to clear in
safe mode")
total: 0 errors, 1 warnings, 0 checks, 11 lines checked
4e8751ecf807 drm/i915/tc: Check for DP-alt, legacy sinks before taking PHY
ownership
cc76a5af71d5 drm/i915/tc: Add/use helpers to retrieve TypeC port properties
344a4da141dd drm/i915/tc: Don't keep legacy TypeC ports in connected state w/o
a sink
dc6bbabc3efa drm/i915/tc: Add a mode for the TypeC PHY's disconnected state
-:111: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#111: FILE: drivers/gpu/drm/i915/display/intel_tc.c:714:
+ drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_TBT_ALT &&
+ !tc_phy_is_owned(dig_port));
total: 0 errors, 0 warnings, 1 checks, 91 lines checked
1a6d3f2220ba drm/i915/tc: Refactor TC-cold block/unblock helpers
d163824eae60 drm/i915/tc: Avoid using legacy AUX PW in TBT mode
24944d022b80 drm/i915/icl/tc: Remove the ICL special casing during TC-cold
blocking
d9687de8553d drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P
14a2cb6aae07 drm/i915/tc: Drop extra TC cold blocking from
intel_tc_port_connected()
1890abf291df drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect
[Intel-gfx] [PATCH 12/13] drm/i915/tc: Drop extra TC cold blocking from intel_tc_port_connected()
After the previous patch the driver holds a power domain blocking
TC-cold whenever the port is locked, so we can remove the extra blocking
around the lock/unlock sequence.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 3fefd00e04685..99b66c2852e53 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -719,16 +719,12 @@ bool intel_tc_port_connected(struct intel_encoder
*encoder)
{
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_connected;
- enum intel_display_power_domain domain;
- intel_wakeref_t tc_cold_wref;
intel_tc_port_lock(dig_port);
- tc_cold_wref = tc_cold_block(dig_port, &domain);
is_connected = tc_port_live_status_mask(dig_port) &
BIT(dig_port->tc_mode);
- tc_cold_unblock(dig_port, domain, tc_cold_wref);
intel_tc_port_unlock(dig_port);
return is_connected;
--
2.27.0
[Intel-gfx] [PATCH 11/13] drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P
So far TC-cold was blocked only for the duration of TypeC mode resets.
The DP-alt and legacy modes require TC-cold to be blocked also whenever
the port is in use (AUX transfers, enable modeset), and this was ensured
by the held PHY ownership flag. On ADL-P this doesn't work, since the
PHY ownership flag is in a register backed by the PW#2 power well.
Whenever this power well is disabled the ownership flag is cleared by
the HW under the driver.
The only way to cleanly release and re-acquire the PHY ownership flag
and also allow for power saving (by disabling the display power wells
and reaching DC5/6 states) is to hold the TC-cold blocking power domains
while the PHY is connected and disconnect/reconnect the PHY on-demand
around AUX transfers and modeset enable/disables. Let's do that,
disconnecting a PHY with a 1 sec delay after it becomes idle. For
consistency do this on all platforms and TypeC modes.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +-
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_tc.c | 87 +++
drivers/gpu/drm/i915/display/intel_tc.h | 2 +-
4 files changed, 60 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b9194d6a4dfe7..b509d5f2d5f0e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4019,8 +4019,11 @@ static void intel_ddi_encoder_destroy(struct drm_encoder
*encoder)
{
struct drm_i915_private *i915 = to_i915(encoder->dev);
struct intel_digital_port *dig_port =
enc_to_dig_port(to_intel_encoder(encoder));
+ enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
intel_dp_encoder_flush_work(encoder);
+ if (intel_phy_is_tc(i915, phy))
+ intel_tc_port_flush_work(dig_port);
intel_display_power_flush_work(i915);
drm_encoder_cleanup(encoder);
@@ -4445,7 +4448,7 @@ static void intel_ddi_encoder_suspend(struct
intel_encoder *encoder)
if (!intel_phy_is_tc(i915, phy))
return;
- intel_tc_port_disconnect_phy(dig_port);
+ intel_tc_port_flush_work(dig_port);
}
static void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
@@ -4460,7 +4463,7 @@ static void intel_ddi_encoder_shutdown(struct
intel_encoder *encoder)
if (!intel_phy_is_tc(i915, phy))
return;
- intel_tc_port_disconnect_phy(dig_port);
+ intel_tc_port_flush_work(dig_port);
}
#define port_tc_name(port) ((port) - PORT_TC1 + '1')
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 08a73ffded957..53509f6ae3d10 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1667,6 +1667,7 @@ struct intel_digital_port {
struct mutex tc_lock; /* protects the TypeC port mode */
intel_wakeref_t tc_lock_wakeref;
enum intel_display_power_domain tc_lock_power_domain;
+ struct delayed_work tc_disconnect_phy_work;
int tc_link_refcount;
bool tc_legacy_port:1;
char tc_port_name[8];
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 8d799cf7ccefd..3fefd00e04685 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -645,6 +645,13 @@ static void intel_tc_port_update_mode(struct
intel_digital_port *dig_port,
intel_tc_port_reset_mode(dig_port, required_lanes, force_disconnect);
+ /* Get power domain matching the new mode after reset. */
+ tc_cold_unblock(dig_port, dig_port->tc_lock_power_domain,
+ fetch_and_zero(&dig_port->tc_lock_wakeref));
+ if (dig_port->tc_mode != TC_PORT_DISCONNECTED)
+ dig_port->tc_lock_wakeref = tc_cold_block(dig_port,
+
&dig_port->tc_lock_power_domain);
+
tc_cold_unblock(dig_port, domain, wref);
}
@@ -672,6 +679,7 @@ void intel_tc_port_sanitize(struct intel_digital_port
*dig_port)
active_links = to_intel_crtc(encoder->base.crtc)->active;
drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_DISCONNECTED);
+ drm_WARN_ON(&i915->drm, dig_port->tc_lock_wakeref);
if (active_links) {
enum intel_display_power_domain domain;
intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port, &domain);
@@ -684,6 +692,9 @@ void intel_tc_port_sanitize(struct intel_digital_port
*dig_port)
dig_port->tc_port_name, active_links);
intel_tc_port_link_init_refcount(dig_port, active_links);
+ dig_port->tc_lock_wakeref = tc_cold_block(dig_port,
+
[Intel-gfx] [PATCH 06/13] drm/i915/tc: Don't keep legacy TypeC ports in connected state w/o a sink
A follow-up patch will disconnect/reconnect PHYs around AUX transfers
and modeset enable/disables. To prepare for that and make things
consistent for all TypeC modes stop connecting the PHY in legacy mode
without a sink being connected. This was done before since in legacy
mode the PHY is dedicated to display usage, so there was no point in
disconnecting it. However after the follow-up changes the TC-cold
blocking power domains will be held as long as the PHY is in the
connected state, so we'll need to disconnect/re-connect the PHY in all
TypeC modes to allow for power saving.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 511c46e36e237..aa4c1e5e0c002 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -511,8 +511,6 @@ static void icl_tc_phy_disconnect(struct intel_digital_port
*dig_port)
{
switch (dig_port->tc_mode) {
case TC_PORT_LEGACY:
- /* Nothing to do, we never disconnect from legacy mode */
- break;
case TC_PORT_DP_ALT:
tc_phy_take_ownership(dig_port, false);
dig_port->tc_mode = TC_PORT_TBT_ALT;
@@ -580,9 +578,7 @@ intel_tc_port_get_target_mode(struct intel_digital_port
*dig_port)
if (live_status_mask)
return fls(live_status_mask) - 1;
- return tc_phy_status_complete(dig_port) &&
- dig_port->tc_legacy_port ? TC_PORT_LEGACY :
- TC_PORT_TBT_ALT;
+ return TC_PORT_TBT_ALT;
}
static void intel_tc_port_reset_mode(struct intel_digital_port *dig_port,
@@ -643,14 +639,8 @@ void intel_tc_port_sanitize(struct intel_digital_port
*dig_port)
"Port %s: PHY disconnected with %d active
link(s)\n",
dig_port->tc_port_name, active_links);
intel_tc_port_link_init_refcount(dig_port, active_links);
-
- goto out;
}
- if (dig_port->tc_legacy_port)
- icl_tc_phy_connect(dig_port, 1);
-
-out:
drm_dbg_kms(&i915->drm, "Port %s: sanitize mode (%s)\n",
dig_port->tc_port_name,
tc_port_mode_name(dig_port->tc_mode));
--
2.27.0
[Intel-gfx] [PATCH 13/13] drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect
The PHY ownership release->AUX PW disable steps during a modeset disable->PHY disconnect sequence can hang the system if the PHY disconnect happens after disabling the PHY's PLL. The spec doesn't require a specific order for these two steps, so this issue is still being root caused by HW/FW teams. Until that is found, let's make sure the disconnect happens before the PLL is disabled, and do this on all platforms for consistency. Cc: José Roberto de Souza Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_tc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c index 99b66c2852e53..dc52b76bd57e2 100644 --- a/drivers/gpu/drm/i915/display/intel_tc.c +++ b/drivers/gpu/drm/i915/display/intel_tc.c @@ -813,6 +813,12 @@ void intel_tc_port_put_link(struct intel_digital_port *dig_port) intel_tc_port_lock(dig_port); --dig_port->tc_link_refcount; intel_tc_port_unlock(dig_port); + + /* +* Disconnecting the PHY after the PHY's PLL gets disabled may +* hang the system on ADL-P, so disconnect the PHY here synchronously. +*/ + intel_tc_port_flush_work(dig_port); } static bool -- 2.27.0
[Intel-gfx] [PATCH 09/13] drm/i915/tc: Avoid using legacy AUX PW in TBT mode
For the ADL-P TBT mode the spec doesn't require blocking TC-cold by
using the legacy AUX power domain. To avoid the timeouts that this would
cause during PHY disconnect/reconnect sequences (which will be more
frequent after a follow-up change) use the TC_COLD_OFF power domain in
TBT mode on all platforms. On TGL this power domain blocks TC-cold via a
PUNIT command, while on other platforms the domain just takes a runtime
PM reference.
If the HPD live status indicates that the port mode needs to be reset
- for instance after switching from TBT to a DP-alt sink - still take
the AUX domain, since the IOM firmware handshake requires this.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 55 -
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 24d2dc2e19a7d..b2a3d297bfc19 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -59,10 +59,10 @@ bool intel_tc_cold_requires_aux_pw(struct
intel_digital_port *dig_port)
static enum intel_display_power_domain
tc_cold_get_power_domain(struct intel_digital_port *dig_port, enum
tc_port_mode mode)
{
- if (intel_tc_cold_requires_aux_pw(dig_port))
- return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
- else
+ if (mode == TC_PORT_TBT_ALT || !intel_tc_cold_requires_aux_pw(dig_port))
return POWER_DOMAIN_TC_COLD_OFF;
+
+ return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
}
static intel_wakeref_t
@@ -624,6 +624,36 @@ static void intel_tc_port_reset_mode(struct
intel_digital_port *dig_port,
tc_port_mode_name(dig_port->tc_mode));
}
+static bool intel_tc_port_needs_reset(struct intel_digital_port *dig_port)
+{
+ return intel_tc_port_get_target_mode(dig_port) != dig_port->tc_mode;
+}
+
+static void intel_tc_port_update_mode(struct intel_digital_port *dig_port,
+ int required_lanes, bool force_disconnect)
+{
+ enum intel_display_power_domain domain;
+ intel_wakeref_t wref;
+ bool needs_reset = force_disconnect;
+
+ if (!needs_reset) {
+ /* Get power domain required to check the hotplug live status.
*/
+ wref = tc_cold_block(dig_port, &domain);
+ needs_reset = intel_tc_port_needs_reset(dig_port);
+ tc_cold_unblock(dig_port, domain, wref);
+ }
+
+ if (!needs_reset)
+ return;
+
+ /* Get power domain required for resetting the mode. */
+ wref = tc_cold_block_in_mode(dig_port, TC_PORT_DISCONNECTED, &domain);
+
+ intel_tc_port_reset_mode(dig_port, required_lanes, force_disconnect);
+
+ tc_cold_unblock(dig_port, domain, wref);
+}
+
static void
intel_tc_port_link_init_refcount(struct intel_digital_port *dig_port,
int refcount)
@@ -670,11 +700,6 @@ void intel_tc_port_sanitize(struct intel_digital_port
*dig_port)
mutex_unlock(&dig_port->tc_lock);
}
-static bool intel_tc_port_needs_reset(struct intel_digital_port *dig_port)
-{
- return intel_tc_port_get_target_mode(dig_port) != dig_port->tc_mode;
-}
-
/*
* The type-C ports are different because even when they are connected, they
may
* not be available/usable by the graphics driver: see the comment on
@@ -714,18 +739,10 @@ static void __intel_tc_port_lock(struct
intel_digital_port *dig_port,
mutex_lock(&dig_port->tc_lock);
- if (!dig_port->tc_link_refcount) {
- enum intel_display_power_domain domain;
- intel_wakeref_t tc_cold_wref;
- tc_cold_wref = tc_cold_block(dig_port, &domain);
-
- if (force_disconnect || intel_tc_port_needs_reset(dig_port))
- intel_tc_port_reset_mode(dig_port, required_lanes,
-force_disconnect);
-
- tc_cold_unblock(dig_port, domain, tc_cold_wref);
- }
+ if (!dig_port->tc_link_refcount)
+ intel_tc_port_update_mode(dig_port, required_lanes,
+ force_disconnect);
drm_WARN_ON(&i915->drm, dig_port->tc_mode == TC_PORT_DISCONNECTED);
drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_TBT_ALT &&
--
2.27.0
[Intel-gfx] [PATCH 10/13] drm/i915/icl/tc: Remove the ICL special casing during TC-cold blocking
While a TypeC port mode is locked a DISPLAY_CORE power domain reference
is held, which implies a runtime PM ref. By removing the ICL !legacy
port special casing, a TC_COLD_OFF power domain reference will be taken
for such ports, which also translates to a runtime PM ref on that
platform. A follow-up change will stop holding the DISPLAY_CORE power
domain while the port is locked.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index b2a3d297bfc19..8d799cf7ccefd 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -71,9 +71,6 @@ tc_cold_block_in_mode(struct intel_digital_port *dig_port,
enum tc_port_mode mod
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- if (DISPLAY_VER(i915) == 11 && !dig_port->tc_legacy_port)
- return 0;
-
*domain = tc_cold_get_power_domain(dig_port, mode);
return intel_display_power_get(i915, *domain);
@@ -108,9 +105,6 @@ assert_tc_cold_blocked(struct intel_digital_port *dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
bool enabled;
- if (DISPLAY_VER(i915) == 11 && !dig_port->tc_legacy_port)
- return;
-
enabled = intel_display_power_is_enabled(i915,
tc_cold_get_power_domain(dig_port,
dig_port->tc_mode));
--
2.27.0
[Intel-gfx] [PATCH 03/13] drm/i915/tc: Remove waiting for PHY complete during releasing ownership
Waiting for the PHY complete flag to clear when releasing the PHY
ownership was add in
commit ddec362724f9 ("drm/i915: Wait for TypeC PHY complete flag to clear in
safe mode")
This isn't required by the spec, the vague idea was to make the
handshake with the firmware more robust, without actual evidence for
when it would be needed. Checking this again, the flag doesn't clear on
ICL until after the PHY's PLL is disabled and the flag is permanently
set on ADL-P. To avoid the spurious timeout messages in dmesg, just
remove this wait.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 7dc3696085c71..0d3555437b0b1 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -339,11 +339,6 @@ static bool icl_tc_phy_take_ownership(struct
intel_digital_port *dig_port,
intel_uncore_write(uncore,
PORT_TX_DFLEXDPCSSS(dig_port->tc_phy_fia), val);
- if (!take && wait_for(!tc_phy_status_complete(dig_port), 10))
- drm_dbg_kms(&i915->drm,
- "Port %s: PHY complete clear timed out\n",
- dig_port->tc_port_name);
-
return true;
}
--
2.27.0
[Intel-gfx] [PATCH 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state
A follow-up change will start to disconnect/re-connect PHYs around AUX
transfers and modeset enable/disables. To prepare for that add a new
TypeC PHY disconnected mode, to help tracking the TC-cold blocking power
domain status (no power domain in disconnected state, mode dependent
power domain in connected state).
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.h | 1 +
drivers/gpu/drm/i915/display/intel_tc.c | 26 ++--
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index d425ee77aad71..87b96fed5e0ba 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -270,6 +270,7 @@ enum tc_port {
};
enum tc_port_mode {
+ TC_PORT_DISCONNECTED,
TC_PORT_TBT_ALT,
TC_PORT_DP_ALT,
TC_PORT_LEGACY,
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index aa4c1e5e0c002..77b16a7c43466 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -12,13 +12,14 @@
static const char *tc_port_mode_name(enum tc_port_mode mode)
{
static const char * const names[] = {
+ [TC_PORT_DISCONNECTED] = "disconnected",
[TC_PORT_TBT_ALT] = "tbt-alt",
[TC_PORT_DP_ALT] = "dp-alt",
[TC_PORT_LEGACY] = "legacy",
};
if (WARN_ON(mode >= ARRAY_SIZE(names)))
- mode = TC_PORT_TBT_ALT;
+ mode = TC_PORT_DISCONNECTED;
return names[mode];
}
@@ -513,10 +514,11 @@ static void icl_tc_phy_disconnect(struct
intel_digital_port *dig_port)
case TC_PORT_LEGACY:
case TC_PORT_DP_ALT:
tc_phy_take_ownership(dig_port, false);
- dig_port->tc_mode = TC_PORT_TBT_ALT;
- break;
+ fallthrough;
case TC_PORT_TBT_ALT:
- /* Nothing to do, we stay in TBT-alt mode */
+ dig_port->tc_mode = TC_PORT_DISCONNECTED;
+ fallthrough;
+ case TC_PORT_DISCONNECTED:
break;
default:
MISSING_CASE(dig_port->tc_mode);
@@ -621,31 +623,34 @@ void intel_tc_port_sanitize(struct intel_digital_port
*dig_port)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_encoder *encoder = &dig_port->base;
- intel_wakeref_t tc_cold_wref;
int active_links = 0;
mutex_lock(&dig_port->tc_lock);
- tc_cold_wref = tc_cold_block(dig_port);
- dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
if (dig_port->dp.is_mst)
active_links = intel_dp_mst_encoder_active_links(dig_port);
else if (encoder->base.crtc)
active_links = to_intel_crtc(encoder->base.crtc)->active;
+ drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_DISCONNECTED);
if (active_links) {
+ intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port);
+
+ dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
+
if (!icl_tc_phy_is_connected(dig_port))
drm_dbg_kms(&i915->drm,
"Port %s: PHY disconnected with %d active
link(s)\n",
dig_port->tc_port_name, active_links);
intel_tc_port_link_init_refcount(dig_port, active_links);
+
+ tc_cold_unblock(dig_port, tc_cold_wref);
}
drm_dbg_kms(&i915->drm, "Port %s: sanitize mode (%s)\n",
dig_port->tc_port_name,
tc_port_mode_name(dig_port->tc_mode));
- tc_cold_unblock(dig_port, tc_cold_wref);
mutex_unlock(&dig_port->tc_lock);
}
@@ -704,6 +709,10 @@ static void __intel_tc_port_lock(struct intel_digital_port
*dig_port,
tc_cold_unblock(dig_port, tc_cold_wref);
}
+ drm_WARN_ON(&i915->drm, dig_port->tc_mode == TC_PORT_DISCONNECTED);
+ drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_TBT_ALT &&
+ !tc_phy_is_owned(dig_port));
+
drm_WARN_ON(&i915->drm, dig_port->tc_lock_wakeref);
dig_port->tc_lock_wakeref = wakeref;
}
@@ -816,6 +825,7 @@ void intel_tc_port_init(struct intel_digital_port
*dig_port, bool is_legacy)
mutex_init(&dig_port->tc_lock);
dig_port->tc_legacy_port = is_legacy;
+ dig_port->tc_mode = TC_PORT_DISCONNECTED;
dig_port->tc_link_refcount = 0;
tc_port_load_fia_params(i915, dig_port);
}
--
2.27.0
[Intel-gfx] [PATCH 08/13] drm/i915/tc: Refactor TC-cold block/unblock helpers
A follow-up change will select the TC-cold blocking power domain based
on the TypeC mode, prepare for that here.
Also bring intel_tc_cold_requires_aux_pw() earlier to its logical place
for readability.
No functional change.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/display/intel_tc.c | 63 +++
2 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e9e806d90eec4..08a73ffded957 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1663,8 +1663,10 @@ struct intel_digital_port {
enum intel_display_power_domain ddi_io_power_domain;
intel_wakeref_t ddi_io_wakeref;
intel_wakeref_t aux_wakeref;
+
struct mutex tc_lock; /* protects the TypeC port mode */
intel_wakeref_t tc_lock_wakeref;
+ enum intel_display_power_domain tc_lock_power_domain;
int tc_link_refcount;
bool tc_legacy_port:1;
char tc_port_name[8];
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 77b16a7c43466..24d2dc2e19a7d 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -48,8 +48,16 @@ bool intel_tc_port_in_legacy_mode(struct intel_digital_port
*dig_port)
return intel_tc_port_in_mode(dig_port, TC_PORT_LEGACY);
}
+bool intel_tc_cold_requires_aux_pw(struct intel_digital_port *dig_port)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+
+ return (DISPLAY_VER(i915) == 11 && dig_port->tc_legacy_port) ||
+ IS_ALDERLAKE_P(i915);
+}
+
static enum intel_display_power_domain
-tc_cold_get_power_domain(struct intel_digital_port *dig_port)
+tc_cold_get_power_domain(struct intel_digital_port *dig_port, enum
tc_port_mode mode)
{
if (intel_tc_cold_requires_aux_pw(dig_port))
return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
@@ -58,23 +66,30 @@ tc_cold_get_power_domain(struct intel_digital_port
*dig_port)
}
static intel_wakeref_t
-tc_cold_block(struct intel_digital_port *dig_port)
+tc_cold_block_in_mode(struct intel_digital_port *dig_port, enum tc_port_mode
mode,
+ enum intel_display_power_domain *domain)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- enum intel_display_power_domain domain;
if (DISPLAY_VER(i915) == 11 && !dig_port->tc_legacy_port)
return 0;
- domain = tc_cold_get_power_domain(dig_port);
- return intel_display_power_get(i915, domain);
+ *domain = tc_cold_get_power_domain(dig_port, mode);
+
+ return intel_display_power_get(i915, *domain);
+}
+
+static intel_wakeref_t
+tc_cold_block(struct intel_digital_port *dig_port, enum
intel_display_power_domain *domain)
+{
+ return tc_cold_block_in_mode(dig_port, dig_port->tc_mode, domain);
}
static void
-tc_cold_unblock(struct intel_digital_port *dig_port, intel_wakeref_t wakeref)
+tc_cold_unblock(struct intel_digital_port *dig_port, enum
intel_display_power_domain domain,
+ intel_wakeref_t wakeref)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- enum intel_display_power_domain domain;
/*
* wakeref == -1, means some error happened saving save_depot_stack but
@@ -84,8 +99,7 @@ tc_cold_unblock(struct intel_digital_port *dig_port,
intel_wakeref_t wakeref)
if (wakeref == 0)
return;
- domain = tc_cold_get_power_domain(dig_port);
- intel_display_power_put_async(i915, domain, wakeref);
+ intel_display_power_put(i915, domain, wakeref);
}
static void
@@ -98,7 +112,8 @@ assert_tc_cold_blocked(struct intel_digital_port *dig_port)
return;
enabled = intel_display_power_is_enabled(i915,
-
tc_cold_get_power_domain(dig_port));
+
tc_cold_get_power_domain(dig_port,
+
dig_port->tc_mode));
drm_WARN_ON(&i915->drm, !enabled);
}
@@ -634,7 +649,8 @@ void intel_tc_port_sanitize(struct intel_digital_port
*dig_port)
drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_DISCONNECTED);
if (active_links) {
- intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port);
+ enum intel_display_power_domain domain;
+ intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port, &domain);
dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
@@ -644,7 +660,7 @@ void intel_tc_port_sanitize(struct intel_digital_port
*dig_port)
dig
[Intel-gfx] [PATCH 05/13] drm/i915/tc: Add/use helpers to retrieve TypeC port properties
Instead of directly accessing the TypeC port internal struct members,
add/use helpers to retrieve the corresponding properties.
No functional change.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 31 +++
drivers/gpu/drm/i915/display/intel_display.c | 6 +---
.../drm/i915/display/intel_display_power.c| 4 +--
drivers/gpu/drm/i915/display/intel_dp_aux.c | 6 +---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 5 +--
drivers/gpu/drm/i915/display/intel_tc.c | 24 ++
drivers/gpu/drm/i915/display/intel_tc.h | 4 +++
7 files changed, 46 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c4ed4675f5791..b9194d6a4dfe7 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -288,7 +288,7 @@ static void intel_ddi_init_dp_buf_reg(struct intel_encoder
*encoder,
if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy)) {
intel_dp->DP |= ddi_buf_phy_link_rate(crtc_state->port_clock);
- if (dig_port->tc_mode != TC_PORT_TBT_ALT)
+ if (!intel_tc_port_in_tbt_alt_mode(dig_port))
intel_dp->DP |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
}
}
@@ -885,8 +885,7 @@ static void intel_ddi_get_power_domains(struct
intel_encoder *encoder,
dig_port = enc_to_dig_port(encoder);
- if (!intel_phy_is_tc(dev_priv, phy) ||
- dig_port->tc_mode != TC_PORT_TBT_ALT) {
+ if (!intel_tc_port_in_tbt_alt_mode(dig_port)) {
drm_WARN_ON(&dev_priv->drm, dig_port->ddi_io_wakeref);
dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
dig_port->ddi_io_power_domain);
@@ -1180,7 +1179,7 @@ static void icl_mg_phy_ddi_vswing_sequence(struct
intel_encoder *encoder,
int n_entries, ln;
u32 val;
- if (enc_to_dig_port(encoder)->tc_mode == TC_PORT_TBT_ALT)
+ if (intel_tc_port_in_tbt_alt_mode(enc_to_dig_port(encoder)))
return;
ddi_translations = encoder->get_buf_trans(encoder, crtc_state,
&n_entries);
@@ -1317,7 +1316,7 @@ tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder
*encoder,
u32 val, dpcnt_mask, dpcnt_val;
int n_entries, ln;
- if (enc_to_dig_port(encoder)->tc_mode == TC_PORT_TBT_ALT)
+ if (intel_tc_port_in_tbt_alt_mode(enc_to_dig_port(encoder)))
return;
ddi_translations = encoder->get_buf_trans(encoder, crtc_state,
&n_entries);
@@ -2084,7 +2083,7 @@ icl_program_mg_dp_mode(struct intel_digital_port
*dig_port,
u8 width;
if (!intel_phy_is_tc(dev_priv, phy) ||
- dig_port->tc_mode == TC_PORT_TBT_ALT)
+ intel_tc_port_in_tbt_alt_mode(dig_port))
return;
if (DISPLAY_VER(dev_priv) >= 12) {
@@ -2109,7 +2108,7 @@ icl_program_mg_dp_mode(struct intel_digital_port
*dig_port,
switch (pin_assignment) {
case 0x0:
drm_WARN_ON(&dev_priv->drm,
- dig_port->tc_mode != TC_PORT_LEGACY);
+ !intel_tc_port_in_legacy_mode(dig_port));
if (width == 1) {
ln1 |= MG_DP_MODE_CFG_DP_X1_MODE;
} else {
@@ -2354,7 +2353,6 @@ static void dg2_ddi_pre_enable_dp(struct
intel_atomic_state *state,
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
int level = intel_ddi_dp_level(intel_dp, crtc_state);
@@ -2378,8 +2376,7 @@ static void dg2_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_ddi_enable_clock(encoder, crtc_state);
/* 4. Enable IO power */
- if (!intel_phy_is_tc(dev_priv, phy) ||
- dig_port->tc_mode != TC_PORT_TBT_ALT)
+ if (!intel_tc_port_in_tbt_alt_mode(dig_port))
dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
dig_port->ddi_io_power_domain);
@@ -2468,7 +2465,6 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
int level = intel_ddi_dp_level(intel_dp, crtc_state);
@@ -2505,8 +2501,7 @@ static void t
[Intel-gfx] [PATCH 04/13] drm/i915/tc: Check for DP-alt, legacy sinks before taking PHY ownership
On ADL-P the PHY ready/complete flag is always set even in TBT-alt mode.
To avoid taking the PHY ownership and the following spurious "PHY sudden
disconnect" messages on this platform when connecting the PHY in TBT
mode, check if there is any DP-alt or legacy sink connected before
taking the ownership.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 0d3555437b0b1..1f76c11d70834 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -432,6 +432,13 @@ static void icl_tc_phy_connect(struct intel_digital_port
*dig_port,
goto out_set_tbt_alt_mode;
}
+ if (!(tc_port_live_status_mask(dig_port) &
+ (BIT(TC_PORT_DP_ALT) | BIT(TC_PORT_LEGACY {
+ drm_dbg_kms(&i915->drm, "Port %s: nothing is connected\n",
+ dig_port->tc_port_name);
+ goto out_set_tbt_alt_mode;
+ }
+
if (!tc_phy_take_ownership(dig_port, true) &&
!drm_WARN_ON(&i915->drm, dig_port->tc_legacy_port))
goto out_set_tbt_alt_mode;
--
2.27.0
[Intel-gfx] [PATCH 01/13] drm/i915/tc: Fix TypeC port init/resume time sanitization
Atm during driver loading and system resume TypeC ports are accessed
before their HW/SW state is synced. Move the TypeC port sanitization to
the encoder's sync_state hook to fix this.
Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook to sanitize its state
during init/resume")
Cc: José Roberto de Souza
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8 +++-
drivers/gpu/drm/i915/display/intel_display.c | 20 +---
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bba0ab99836b1..c4ed4675f5791 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3840,7 +3840,13 @@ void hsw_ddi_get_config(struct intel_encoder *encoder,
static void intel_ddi_sync_state(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
- if (intel_crtc_has_dp_encoder(crtc_state))
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+ if (intel_phy_is_tc(i915, phy))
+ intel_tc_port_sanitize(enc_to_dig_port(encoder));
+
+ if (crtc_state && intel_crtc_has_dp_encoder(crtc_state))
intel_dp_sync_state(encoder, crtc_state);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f6c0c595f6313..8547842935389 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12194,18 +12194,16 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
readout_plane_state(dev_priv);
for_each_intel_encoder(dev, encoder) {
+ struct intel_crtc_state *crtc_state = NULL;
+
pipe = 0;
if (encoder->get_hw_state(encoder, &pipe)) {
- struct intel_crtc_state *crtc_state;
-
crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
crtc_state = to_intel_crtc_state(crtc->base.state);
encoder->base.crtc = &crtc->base;
intel_encoder_get_config(encoder, crtc_state);
- if (encoder->sync_state)
- encoder->sync_state(encoder, crtc_state);
/* read out to slave crtc as well for bigjoiner */
if (crtc_state->bigjoiner) {
@@ -12220,6 +12218,9 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
encoder->base.crtc = NULL;
}
+ if (encoder->sync_state)
+ encoder->sync_state(encoder, crtc_state);
+
drm_dbg_kms(&dev_priv->drm,
"[ENCODER:%d:%s] hw state readout: %s, pipe %c\n",
encoder->base.base.id, encoder->base.name,
@@ -12502,17 +12503,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
intel_modeset_readout_hw_state(dev);
/* HW state is read out, now we need to sanitize this mess. */
-
- /* Sanitize the TypeC port mode upfront, encoders depend on this */
- for_each_intel_encoder(dev, encoder) {
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
-
- /* We need to sanitize only the MST primary port. */
- if (encoder->type != INTEL_OUTPUT_DP_MST &&
- intel_phy_is_tc(dev_priv, phy))
- intel_tc_port_sanitize(enc_to_dig_port(encoder));
- }
-
get_encoder_power_domains(dev_priv);
if (HAS_PCH_IBX(dev_priv))
--
2.27.0
[Intel-gfx] [PATCH 02/13] drm/i915/adlp/tc: Fix PHY connected check for Thunderbolt mode
On ADL-P the PHY ready (aka status complete on other platforms) flag is
always set, besides when a DP-alt, legacy sink is connected also when a
TBT sink is connected or nothing is connected. So assume the PHY to be
connected when both the TBT live status and PHY ready flags are set.
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 3ffece568ed98..7dc3696085c71 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -509,6 +509,10 @@ static bool icl_tc_phy_is_connected(struct
intel_digital_port *dig_port)
return dig_port->tc_mode == TC_PORT_TBT_ALT;
}
+ /* On ADL-P the PHY complete flag is set in TBT mode as well. */
+ if (IS_ALDERLAKE_P(i915) && dig_port->tc_mode == TC_PORT_TBT_ALT)
+ return true;
+
if (!tc_phy_is_owned(dig_port)) {
drm_dbg_kms(&i915->drm, "Port %s: PHY not owned\n",
dig_port->tc_port_name);
--
2.27.0
[Intel-gfx] [PATCH 00/13] drm/i915/tc: Fix TypeC connect/disconnect sequences
This patchset fixes two issues on ADL-P related to the TypeC PHY connect/disconnect sequences in patch 11 and 13 and a few other minor TypeC issues I noticed on the way. The fix in patch 11 requires some refactoring and it affects all TypeC platforms; this was the way that made sense to me to keep things consistent across all platforms and TypeC modes and also bring the connect/disconnect sequences closer to the specification. Tested on ICL, TGL, ADL-P, on all the 3 TypeC port types where available. Cc: José Roberto de Souza Imre Deak (13): drm/i915/tc: Fix TypeC port init/resume time sanitization drm/i915/adlp/tc: Fix PHY connected check for Thunderbolt mode drm/i915/tc: Remove waiting for PHY complete during releasing ownership drm/i915/tc: Check for DP-alt,legacy sinks before taking PHY ownership drm/i915/tc: Add/use helpers to retrieve TypeC port properties drm/i915/tc: Don't keep legacy TypeC ports in connected state w/o a sink drm/i915/tc: Add a mode for the TypeC PHY's disconnected state drm/i915/tc: Refactor TC-cold block/unblock helpers drm/i915/tc: Avoid using legacy AUX PW in TBT mode drm/i915/icl/tc: Remove the ICL special casing during TC-cold blocking drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P drm/i915/tc: Drop extra TC cold blocking from intel_tc_port_connected() drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect drivers/gpu/drm/i915/display/intel_ddi.c | 46 +-- drivers/gpu/drm/i915/display/intel_display.c | 26 +- drivers/gpu/drm/i915/display/intel_display.h | 1 + .../drm/i915/display/intel_display_power.c| 4 +- .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_dp_aux.c | 6 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 5 +- drivers/gpu/drm/i915/display/intel_tc.c | 275 +++--- drivers/gpu/drm/i915/display/intel_tc.h | 6 +- 9 files changed, 218 insertions(+), 154 deletions(-) -- 2.27.0
Re: [Intel-gfx] [PATCH 21/27] drm/i915/doc: Update parallel submit doc to point to i915_drm.h
On 8/20/2021 15:44, Matthew Brost wrote:
Update parallel submit doc to point to i915_drm.h
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 --
Documentation/gpu/rfc/i915_scheduler.rst | 4 +-
2 files changed, 2 insertions(+), 124 deletions(-)
delete mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
deleted file mode 100644
index 8cbe2c4e0172..
--- a/Documentation/gpu/rfc/i915_parallel_execbuf.h
+++ /dev/null
@@ -1,122 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Copyright © 2021 Intel Corporation
- */
-
-#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
i915_context_engines_parallel_submit */
-
-/**
- * struct drm_i915_context_engines_parallel_submit - Configure engine for
- * parallel submission.
- *
- * Setup a slot in the context engine map to allow multiple BBs to be submitted
- * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the
GPU
- * in parallel. Multiple hardware contexts are created internally in the i915
- * run these BBs. Once a slot is configured for N BBs only N BBs can be
- * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user
- * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how
- * many BBs there are based on the slot's configuration. The N BBs are the last
- * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set.
- *
- * The default placement behavior is to create implicit bonds between each
- * context if each context maps to more than 1 physical engine (e.g. context is
- * a virtual engine). Also we only allow contexts of same engine class and
these
- * contexts must be in logically contiguous order. Examples of the placement
- * behavior described below. Lastly, the default is to not allow BBs to
- * preempted mid BB rather insert coordinated preemption on all hardware
- * contexts between each set of BBs. Flags may be added in the future to change
- * both of these default behaviors.
- *
- * Returns -EINVAL if hardware context placement configuration is invalid or if
- * the placement configuration isn't supported on the platform / submission
- * interface.
- * Returns -ENODEV if extension isn't supported on the platform / submission
- * interface.
- *
- * .. code-block:: none
- *
- * Example 1 pseudo code:
- * CS[X] = generic engine of same class, logical instance X
- * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
- * set_engines(INVALID)
- * set_parallel(engine_index=0, width=2, num_siblings=1,
- * engines=CS[0],CS[1])
- *
- * Results in the following valid placement:
- * CS[0], CS[1]
- *
- * Example 2 pseudo code:
- * CS[X] = generic engine of same class, logical instance X
- * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
- * set_engines(INVALID)
- * set_parallel(engine_index=0, width=2, num_siblings=2,
- * engines=CS[0],CS[2],CS[1],CS[3])
- *
- * Results in the following valid placements:
- * CS[0], CS[1]
- * CS[2], CS[3]
- *
- * This can also be thought of as 2 virtual engines described by 2-D array
- * in the engines the field with bonds placed between each index of the
- * virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to
- * CS[3].
- * VE[0] = CS[0], CS[2]
- * VE[1] = CS[1], CS[3]
- *
- * Example 3 pseudo code:
- * CS[X] = generic engine of same class, logical instance X
- * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
- * set_engines(INVALID)
- * set_parallel(engine_index=0, width=2, num_siblings=2,
- * engines=CS[0],CS[1],CS[1],CS[3])
- *
- * Results in the following valid and invalid placements:
- * CS[0], CS[1]
- * CS[1], CS[3] - Not logical contiguous, return -EINVAL
- */
-struct drm_i915_context_engines_parallel_submit {
- /**
-* @base: base user extension.
-*/
- struct i915_user_extension base;
-
- /**
-* @engine_index: slot for parallel engine
-*/
- __u16 engine_index;
-
- /**
-* @width: number of contexts per parallel engine
-*/
- __u16 width;
-
- /**
-* @num_siblings: number of siblings per context
-*/
- __u16 num_siblings;
-
- /**
-* @mbz16: reserved for future use; must be zero
-*/
- __u16 mbz16;
-
- /**
-* @flags: all undefined flags must be zero, currently not defined flags
-*/
- __u64 flags;
-
- /**
-* @mbz64: reserved for future use; must be zero
-*/
- __u64 mbz64[3];
-
- /**
-* @engines: 2-d array of engine instances to configure parallel engine
-*
-* length = width
Re: [Intel-gfx] [PATCH 20/27] drm/i915/guc: Connect UAPI to GuC multi-lrc interface
On 8/20/2021 15:44, Matthew Brost wrote:
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071&rev=1
media UMD: link to come
Is this link still not available?
Also, see 'kernel test robot' emails saying that sparse is complaining
about something I don't understand but presumably needs to be fixed.
v2:
(Daniel Vetter)
- Add IGT link and placeholder for media UMD link
Cc: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 220 +-
.../gpu/drm/i915/gem/i915_gem_context_types.h | 6 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +-
drivers/gpu/drm/i915/gt/intel_engine.h| 12 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +-
.../drm/i915/gt/intel_execlists_submission.c | 6 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 -
include/uapi/drm/i915_drm.h | 128 ++
9 files changed, 485 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index bcaaf514876b..de0fd145fb47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -522,9 +522,149 @@ set_proto_ctx_engines_bond(struct i915_user_extension
__user *base, void *data)
return 0;
}
+static int
+set_proto_ctx_engines_parallel_submit(struct i915_user_extension __user *base,
+ void *data)
+{
+ struct i915_context_engines_parallel_submit __user *ext =
+ container_of_user(base, typeof(*ext), base);
+ const struct set_proto_ctx_engines *set = data;
+ struct drm_i915_private *i915 = set->i915;
+ u64 flags;
+ int err = 0, n, i, j;
+ u16 slot, width, num_siblings;
+ struct intel_engine_cs **siblings = NULL;
+ intel_engine_mask_t prev_mask;
+
+ /* Disabling for now */
+ return -ENODEV;
+
+ if (!(intel_uc_uses_guc_submission(&i915->gt.uc)))
+ return -ENODEV;
This needs a FIXME comment to say that exec list will be added later.
+
+ if (get_user(slot, &ext->engine_index))
+ return -EFAULT;
+
+ if (get_user(width, &ext->width))
+ return -EFAULT;
+
+ if (get_user(num_siblings, &ext->num_siblings))
+ return -EFAULT;
+
+ if (slot >= set->num_engines) {
+ drm_dbg(&i915->drm, "Invalid placement value, %d >= %d\n",
+ slot, set->num_engines);
+ return -EINVAL;
+ }
+
+ if (set->engines[slot].type != I915_GEM_ENGINE_TYPE_INVALID) {
+ drm_dbg(&i915->drm,
+ "Invalid placement[%d], already occupied\n", slot);
+ return -EINVAL;
+ }
+
+ if (get_user(flags, &ext->flags))
+ return -EFAULT;
+
+ if (flags) {
+ drm_dbg(&i915->drm, "Unknown flags 0x%02llx", flags);
+ return -EINVAL;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ext->mbz64); n++) {
+ err = check_user_mbz(&ext->mbz64[n]);
+ if (err)
+ return err;
+ }
+
+ if (width < 2) {
+ drm_dbg(&i915->drm, "Width (%d) < 2\n", width);
+ return -EINVAL;
+ }
+
+ if (num_siblings < 1) {
+ drm_dbg(&i915->drm, "Number siblings (%d) < 1\n",
+ num_siblings);
+ return -EINVAL;
+ }
+
+ siblings = kmalloc_array(num_siblings * width,
+sizeof(*siblings),
+GFP_KERNEL);
+ if (!siblings)
+ return -ENOMEM;
+
+ /* Create contexts / engines */
+ for (i = 0; i < width; ++i) {
+ intel_engine_mask_t current_mask = 0;
+ struct i915_engine_class_instance prev_engine;
+
+ for (j = 0; j < num_siblings; ++j) {
+ struct i915_engine_class_instance ci;
+
+ n = i * num_siblings + j;
+ if (copy_from_user(&ci, &ext->engines[n], sizeof(ci))) {
+ err = -EFAULT;
+ goto out_err;
+ }
+
+ siblings[n] =
+ intel_engine_lookup_user(i915, ci.engine_class,
+ci.engine_instance);
+ if (!siblings[n]) {
+ drm_dbg(&i915->drm,
+ "Invalid sibling[%d]: { class:%d, inst:%d
}\n",
+ n, ci.engine_class, ci.engine_instance);
+ er
[Intel-gfx] [PATCH 2/2] Add drm buddy manager support to amdgpu driver
Replace drm_mm with drm buddy manager for
VRAM memory management
Signed-off-by: Arunpravin
---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 78 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 216 ++
3 files changed, 189 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index acfa207cf970..ba24052e9062 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -30,12 +30,25 @@
#include
#include
+struct amdgpu_vram_mgr_node {
+ struct ttm_range_mgr_node tnode;
+ struct list_head blocks;
+};
+
+static inline struct amdgpu_vram_mgr_node *
+to_amdgpu_vram_mgr_node(struct ttm_resource *res)
+{
+ return container_of(container_of(res, struct ttm_range_mgr_node, base),
+ struct amdgpu_vram_mgr_node, tnode);
+}
+
/* state back for walking over vram_mgr and gtt_mgr allocations */
struct amdgpu_res_cursor {
uint64_tstart;
uint64_tsize;
uint64_tremaining;
- struct drm_mm_node *node;
+ void*node;
+ uint32_tmem_type;
};
/**
@@ -52,8 +65,6 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
uint64_t start, uint64_t size,
struct amdgpu_res_cursor *cur)
{
- struct drm_mm_node *node;
-
if (!res || res->mem_type == TTM_PL_SYSTEM) {
cur->start = start;
cur->size = size;
@@ -65,14 +76,39 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
- node = to_ttm_range_mgr_node(res)->mm_nodes;
- while (start >= node->size << PAGE_SHIFT)
- start -= node++->size << PAGE_SHIFT;
+ cur->mem_type = res->mem_type;
+
+ if (cur->mem_type == TTM_PL_VRAM) {
+ struct drm_buddy_block *block;
+ struct list_head *head, *next;
+
+ head = &to_amdgpu_vram_mgr_node(res)->blocks;
+
+ block = list_first_entry_or_null(head, struct drm_buddy_block,
link);
+ while (start >= block->size << PAGE_SHIFT) {
+ start -= block->size << PAGE_SHIFT;
+
+ next = block->link.next;
+ if (next != head)
+ block = list_entry(next, struct
drm_buddy_block, link);
+ }
- cur->start = (node->start << PAGE_SHIFT) + start;
- cur->size = min((node->size << PAGE_SHIFT) - start, size);
- cur->remaining = size;
- cur->node = node;
+ cur->start = (block->start << PAGE_SHIFT) + start;
+ cur->size = min((block->size << PAGE_SHIFT) - start, size);
+ cur->remaining = size;
+ cur->node = block;
+ } else if (cur->mem_type == TTM_PL_TT) {
+ struct drm_mm_node *node;
+
+ node = to_ttm_range_mgr_node(res)->mm_nodes;
+ while (start >= node->size << PAGE_SHIFT)
+ start -= node++->size << PAGE_SHIFT;
+
+ cur->start = (node->start << PAGE_SHIFT) + start;
+ cur->size = min((node->size << PAGE_SHIFT) - start, size);
+ cur->remaining = size;
+ cur->node = node;
+ }
}
/**
@@ -85,8 +121,6 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
*/
static inline void amdgpu_res_next(struct amdgpu_res_cursor *cur, uint64_t
size)
{
- struct drm_mm_node *node = cur->node;
-
BUG_ON(size > cur->remaining);
cur->remaining -= size;
@@ -99,9 +133,23 @@ static inline void amdgpu_res_next(struct amdgpu_res_cursor
*cur, uint64_t size)
return;
}
- cur->node = ++node;
- cur->start = node->start << PAGE_SHIFT;
- cur->size = min(node->size << PAGE_SHIFT, cur->remaining);
+ if (cur->mem_type == TTM_PL_VRAM) {
+ struct drm_buddy_block *block = cur->node;
+ struct list_head *next;
+
+ next = block->link.next;
+ block = list_entry(next, struct drm_buddy_block, link);
+
+ cur->node = block;
+ cur->start = block->start << PAGE_SHIFT;
+ cur->size = min(block->size << PAGE_SHIFT, cur->remaining);
+ } else if (cur->mem_type == TTM_PL_TT) {
+ struct drm_mm_node *node = cur->node;
+
+ cur->node = ++node;
+ cur->start = node->start << PAGE_SHIFT;
+ cur->size = min(node->size << PAGE_SHIFT, cur->remaining);
+ }
}
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index e69f3e8e06e5
[Intel-gfx] [PATCH 1/2] Enable buddy memory manager support
Port Intel buddy system manager to drm root folder
Add CPU mappable/non-mappable region support to the drm buddy manager
Signed-off-by: Arunpravin
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_buddy.c | 465
include/drm/drm_buddy.h | 154
3 files changed, 620 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_buddy.c
create mode 100644 include/drm/drm_buddy.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a118692a6df7..fe1a2fc09675 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y :=drm_aperture.o drm_auth.o drm_cache.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
- drm_managed.o drm_vblank_work.o
+ drm_managed.o drm_vblank_work.o drm_buddy.o
drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o
drm_dma.o \
drm_legacy_misc.o drm_lock.o drm_memory.o
drm_scatter.o \
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
new file mode 100644
index ..f07919a004b6
--- /dev/null
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -0,0 +1,465 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright � 2021 Intel Corporation
+ */
+
+#include
+#include
+
+static struct drm_buddy_block *drm_block_alloc(struct drm_buddy_mm *mm,
+ struct drm_buddy_block *parent, unsigned int order,
+ u64 offset)
+{
+ struct drm_buddy_block *block;
+
+ BUG_ON(order > DRM_BUDDY_MAX_ORDER);
+
+ block = kmem_cache_zalloc(mm->slab_blocks, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ block->header = offset;
+ block->header |= order;
+ block->parent = parent;
+ block->start = offset >> PAGE_SHIFT;
+ block->size = (mm->chunk_size << order) >> PAGE_SHIFT;
+
+ BUG_ON(block->header & DRM_BUDDY_HEADER_UNUSED);
+ return block;
+}
+
+static void drm_block_free(struct drm_buddy_mm *mm, struct drm_buddy_block
*block)
+{
+ kmem_cache_free(mm->slab_blocks, block);
+}
+
+static void add_ordered(struct drm_buddy_mm *mm, struct drm_buddy_block *block)
+{
+ struct drm_buddy_block *node;
+
+ if (list_empty(&mm->free_list[drm_buddy_block_order(block)])) {
+ list_add(&block->link,
+ &mm->free_list[drm_buddy_block_order(block)]);
+ return;
+ }
+
+ list_for_each_entry(node, &mm->free_list[drm_buddy_block_order(block)],
link)
+ if (block->start > node->start)
+ break;
+
+ __list_add(&block->link, node->link.prev, &node->link);
+}
+
+static void mark_allocated(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_STATE;
+ block->header |= DRM_BUDDY_ALLOCATED;
+
+ list_del(&block->link);
+}
+
+static void mark_free(struct drm_buddy_mm *mm,
+ struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_STATE;
+ block->header |= DRM_BUDDY_FREE;
+
+ add_ordered(mm, block);
+}
+
+static void mark_split(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_STATE;
+ block->header |= DRM_BUDDY_SPLIT;
+
+ list_del(&block->link);
+}
+
+int drm_buddy_init(struct drm_buddy_mm *mm, u64 size, u64 chunk_size)
+{
+ unsigned int i;
+ u64 offset;
+
+ if (size < chunk_size)
+ return -EINVAL;
+
+ if (chunk_size < PAGE_SIZE)
+ return -EINVAL;
+
+ if (!is_power_of_2(chunk_size))
+ return -EINVAL;
+
+ size = round_down(size, chunk_size);
+
+ mm->size = size;
+ mm->chunk_size = chunk_size;
+ mm->max_order = ilog2(size) - ilog2(chunk_size);
+
+ BUG_ON(mm->max_order > DRM_BUDDY_MAX_ORDER);
+
+ mm->slab_blocks = KMEM_CACHE(drm_buddy_block, SLAB_HWCACHE_ALIGN);
+
+ if (!mm->slab_blocks)
+ return -ENOMEM;
+
+ mm->free_list = kmalloc_array(mm->max_order + 1,
+ sizeof(struct list_head),
+ GFP_KERNEL);
+ if (!mm->free_list)
+ goto out_destroy_slab;
+
+ for (i = 0; i <= mm->max_order; ++i)
+ INIT_LIST_HEAD(&mm->free_list[i]);
+
+ mm->n_roots = hweight64(size);
+
+ mm->roots = kmalloc_array(mm->n_roots,
+ sizeof(struct drm_buddy_block *),
+ GFP_KERNEL);
+ if (!mm->roots)
+ goto out_free_list;
+
+ offset = 0;
+ i = 0;
+
+ /*
+* Split into power-of-two blocks, in case we are given a size that is
+* not itself a power-of-two.
+*/
+
Re: [Intel-gfx] [PATCH 19/27] drm/i915: Fix bug in user proto-context creation that leaked contexts
On 8/20/2021 15:44, Matthew Brost wrote:
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly.
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create
parameters (v5)")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dbaeb924a437..bcaaf514876b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -944,6 +944,7 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
unsigned int n;
e = alloc_engines(num_engines);
This can return null when out of memory. There needs to be an early exit
check before dereferencing a null pointer. Not sure if that is a worse
bug or not than leaking memory! Either way, it would be good to fix that
too.
John.
+ e->num_engines = num_engines;
for (n = 0; n < num_engines; n++) {
struct intel_context *ce;
int ret;
@@ -977,7 +978,6 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
goto free_engines;
}
}
- e->num_engines = num_engines;
return e;
Re: [Intel-gfx] [PATCH 18/27] drm/i915/guc: Update debugfs for GuC multi-lrc
On 8/20/2021 15:44, Matthew Brost wrote:
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 51 ++-
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e34e0ea9136a..07eee9a399c8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3673,6 +3673,26 @@ static void guc_log_context_priority(struct drm_printer
*p,
drm_printf(p, "\n");
}
+
+static inline void guc_log_context(struct drm_printer *p,
+ struct intel_context *ce)
+{
+ drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id.id);
+ drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
+ drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
+ ce->ring->head,
+ ce->lrc_reg_state[CTX_RING_HEAD]);
+ drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
+ ce->ring->tail,
+ ce->lrc_reg_state[CTX_RING_TAIL]);
+ drm_printf(p, "\t\tContext Pin Count: %u\n",
+ atomic_read(&ce->pin_count));
+ drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
+ atomic_read(&ce->guc_id.ref));
+ drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
+ ce->guc_state.sched_state);
+}
+
void intel_guc_submission_print_context_info(struct intel_guc *guc,
struct drm_printer *p)
{
@@ -3682,22 +3702,25 @@ void intel_guc_submission_print_context_info(struct
intel_guc *guc,
xa_lock_irqsave(&guc->context_lookup, flags);
xa_for_each(&guc->context_lookup, index, ce) {
- drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id.id);
- drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
- drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
- ce->ring->head,
- ce->lrc_reg_state[CTX_RING_HEAD]);
- drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
- ce->ring->tail,
- ce->lrc_reg_state[CTX_RING_TAIL]);
- drm_printf(p, "\t\tContext Pin Count: %u\n",
- atomic_read(&ce->pin_count));
- drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
- atomic_read(&ce->guc_id.ref));
- drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
- ce->guc_state.sched_state);
+ GEM_BUG_ON(intel_context_is_child(ce));
+ guc_log_context(p, ce);
guc_log_context_priority(p, ce);
+
+ if (intel_context_is_parent(ce)) {
+ struct guc_process_desc *desc = __get_process_desc(ce);
+ struct intel_context *child;
+
+ drm_printf(p, "\t\tWQI Head: %u\n",
+ READ_ONCE(desc->head));
+ drm_printf(p, "\t\tWQI Tail: %u\n",
+ READ_ONCE(desc->tail));
+ drm_printf(p, "\t\tWQI Status: %u\n\n",
+ READ_ONCE(desc->wq_status));
+
+ for_each_child(ce, child)
+ guc_log_context(p, child);
There should be some indication that this is a child context and/or how
many children there are. Otherwise how does the reader differentiation
between the list of child contexts and the next parent/single context?
John.
+ }
}
xa_unlock_irqrestore(&guc->context_lookup, flags);
}
Re: [Intel-gfx] [PATCH 17/27] drm/i915/guc: Implement multi-lrc reset
On 8/20/2021 15:44, Matthew Brost wrote:
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its' children. The parent context owns the reset replaying / canceling
its' -> its
requests as needed.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 11 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 63 +--
2 files changed, 51 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 00d1aee6d199..5615be32879c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -528,20 +528,21 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
struct i915_request *intel_context_find_active_request(struct intel_context *ce)
{
+ struct intel_context *parent = intel_context_to_parent(ce);
struct i915_request *rq, *active = NULL;
unsigned long flags;
GEM_BUG_ON(!intel_engine_uses_guc(ce->engine));
Should this not check the parent as well/instead?
And to be clear, this can be called on regular contexts (where ce ==
parent) and on both the parent or child contexts of multi-LRC contexts
(where ce may or may not match parent)?
- spin_lock_irqsave(&ce->guc_state.lock, flags);
- list_for_each_entry_reverse(rq, &ce->guc_state.requests,
+ spin_lock_irqsave(&parent->guc_state.lock, flags);
+ list_for_each_entry_reverse(rq, &parent->guc_state.requests,
sched.link) {
- if (i915_request_completed(rq))
+ if (i915_request_completed(rq) && rq->context == ce)
'rq->context == ce' means:
1. single-LRC context, rq is owned by ce
2. multi-LRC context, ce is child, rq really belongs to ce but is being
tracked by parent
3. multi-LRC context, ce is parent, rq really is owned by ce
So when 'rq->ce != ce', it means that the request is owned by a
different child to 'ce' but within the same multi-LRC group. So we want
to ignore that request and keep searching until we find one that is
really owned by the target ce?
break;
- active = rq;
+ active = (rq->context == ce) ? rq : active;
Would be clearer to say 'if(rq->ce != ce) continue;' and leave 'active =
rq;' alone?
And again, the intention is to ignore requests that are owned by other
members of the same multi-LRC group?
Would be good to add some documentation to this function to explain the
above (assuming my description is correct?).
}
- spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ spin_unlock_irqrestore(&parent->guc_state.lock, flags);
return active;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index f0b60fecf253..e34e0ea9136a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -670,6 +670,11 @@ static int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static inline bool is_multi_lrc(struct intel_context *ce)
+{
+ return intel_context_is_parallel(ce);
+}
+
static bool is_multi_lrc_rq(struct i915_request *rq)
{
return intel_context_is_parallel(rq->context);
@@ -1179,10 +1184,13 @@ __unwind_incomplete_requests(struct intel_context *ce)
static void __guc_reset_context(struct intel_context *ce, bool stalled)
{
+ bool local_stalled;
struct i915_request *rq;
unsigned long flags;
u32 head;
+ int i, number_children = ce->guc_number_children;
If this is a child context, does it not need to pull the child count
from the parent? Likewise the list/link pointers below? Or does each
child context have a full list of its siblings + parent?
bool skip = false;
+ struct intel_context *parent = ce;
intel_context_get(ce);
@@ -1209,25 +1217,34 @@ static void __guc_reset_context(struct intel_context *ce, bool stalled)
if (unlikely(skip))
goto out_put;
- rq = intel_context_find_active_request(ce);
- if (!rq) {
- head = ce->ring->tail;
- stalled = false;
- goto out_replay;
- }
+ for (i = 0; i < number_children + 1; ++i) {
+ if (!intel_context_is_pinned(ce))
+ goto next_context;
+
+ local_stalled = false;
+ rq = intel_context_find_active_request(ce);
+ if (!rq) {
+ head = ce->ring->tail;
+ goto out_replay;
+ }
- if (!i915_request_started(rq))
- stalled = false;
+ GEM_BUG_ON(i915_active_is_idle(&ce->active));
+ head = intel_ring_wrap(ce->ring, rq->head);
- GEM_BUG
Re: [Intel-gfx] [PULL] drm-misc-next
On Thu, Sep 16, 2021 at 2:31 AM Maxime Ripard wrote: > > Hi Dave, Daniel, > > Here's the first drm-misc-next PR for 5.16 > > Thanks! > Maxime > > drm-misc-next-2021-09-16: > drm-misc-next for $kernel-version: > > UAPI Changes: > > Cross-subsystem Changes: > - dma-buf: Avoid a warning with some allocations, Remove > DMA_FENCE_TRACE macros > > Core Changes: > - bridge: New helper to git rid of panels in drivers > - fence: Improve dma_fence_add_callback documentation, Improve > dma_fence_ops->wait documentation > - ioctl: Unexport drm_ioctl_permit > - lease: Documentation improvements > - fourcc: Add new macro to determine the modifier vendor > - quirks: Add the Steam Deck, Chuwi HiBook, Chuwi Hi10 Pro, Samsung > Galaxy Book 10.6, KD Kurio Smart C15200 2-in-1, Lenovo Ideapad D330 > - resv: Improve the documentation > - shmem-helpers: Allocate WC pages on x86, Switch to vmf_insert_pfn > - sched: Fix for a timer being canceled too soon, Avoid null pointer > derefence if the fence is null in drm_sched_fence_free, Convert > drivers to rely on its dependency tracking > - ttm: Switch to kerneldoc, new helper to clear all DMA mappings, pool > shrinker optitimization, Remove ttm_tt_destroy_common, Fix for > unbinding on multiple drivers > > Driver Changes: > - bochs: New PCI IDs > - msm: Fence ordering impromevemnts > - stm: Add layer alpha support, zpos > - v3d: Fix for a Vulkan CTS failure > - vc4: Conversion to the new bridge helpers > - vgem: Use shmem helpers > - virtio: Support mapping exported vram > - zte: Remove obsolete driver > > - bridge: Probe improvements for it66121, enable DSI EOTP for anx7625, > errors propagation improvements for anx7625 > > - panels: 60fps mode for otm8009a, New driver for Samsung S6D27A1 > The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f: > > Linux 5.15-rc1 (2021-09-12 16:28:37 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-09-16 > > for you to fetch changes up to e4f868191138975f2fdf2f37c11318b47db4acc9: > > drm/v3d: fix wait for TMU write combiner flush (2021-09-15 18:43:37 +0100) > > > drm-misc-next for $kernel-version: > > UAPI Changes: > > Cross-subsystem Changes: > - dma-buf: Avoid a warning with some allocations, Remove > DMA_FENCE_TRACE macros > > Core Changes: > - bridge: New helper to git rid of panels in drivers > - fence: Improve dma_fence_add_callback documentation, Improve > dma_fence_ops->wait documentation > - ioctl: Unexport drm_ioctl_permit > - lease: Documentation improvements > - fourcc: Add new macro to determine the modifier vendor > - quirks: Add the Steam Deck, Chuwi HiBook, Chuwi Hi10 Pro, Samsung > Galaxy Book 10.6, KD Kurio Smart C15200 2-in-1, Lenovo Ideapad D330 > - resv: Improve the documentation > - shmem-helpers: Allocate WC pages on x86, Switch to vmf_insert_pfn > - sched: Fix for a timer being canceled too soon, Avoid null pointer > derefence if the fence is null in drm_sched_fence_free, Convert > drivers to rely on its dependency tracking > - ttm: Switch to kerneldoc, new helper to clear all DMA mappings, pool > shrinker optitimization, Remove ttm_tt_destroy_common, Fix for > unbinding on multiple drivers > > Driver Changes: > - bochs: New PCI IDs > - msm: Fence ordering impromevemnts > - stm: Add layer alpha support, zpos > - v3d: Fix for a Vulkan CTS failure > - vc4: Conversion to the new bridge helpers > - vgem: Use shmem helpers > - virtio: Support mapping exported vram > - zte: Remove obsolete driver > > - bridge: Probe improvements for it66121, enable DSI EOTP for anx7625, > errors propagation improvements for anx7625 > > - panels: 60fps mode for otm8009a, New driver for Samsung S6D27A1 > > > Alyssa Rosenzweig (2): > drm/panfrost: Use upper/lower_32_bits helpers > drm/plane: Fix comment typo > > Andrey Grodzovsky (2): > drm/ttm: Create pinned list > drm/ttm: Clear all DMA mappings on demand > > Boris Brezillon (2): > panfrost: Don't cleanup the job if it was successfully queued > drm/sched: Fix drm_sched_fence_free() so it can be passed an > uninitialized fence > > Cai Huoqing (7): > drm/bridge: cdns: Make use of the helper function > devm_platform_ioremap_resource() > drm: adv7511: Convert to SPDX identifier > drm/vc4: Make use of the helper function > devm_platform_ioremap_resource() > drm/sun4i: Make use of the helper function > devm_platform_ioremap_resource() > drm/panfrost: Make use of the helper function > devm_platform_ioremap_resource() > drm/mcde: Make use of the helper function > devm_platform_ioremap_resource() > drm/meson: Make use of the helper function > devm_pla
Re: [Intel-gfx] [PATCH 16/27] drm/i915/guc: Insert submit fences between requests in parent-child relationship
On 8/20/2021 15:44, Matthew Brost wrote:
The GuC must receive requests in the order submitted for contexts in a
parent-child relationship to function correctly. To ensure this, insert
a submit fence between the current request and last request submitted
for requests / contexts in a parent child relationship. This is
conceptually similar to a single timeline.
Signed-off-by: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.h | 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +-
drivers/gpu/drm/i915/i915_request.c | 120 ++
4 files changed, 109 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index c2985822ab74..9dcc1b14697b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -75,6 +75,11 @@ intel_context_to_parent(struct intel_context *ce)
}
}
+static inline bool intel_context_is_parallel(struct intel_context *ce)
+{
+ return intel_context_is_child(ce) || intel_context_is_parent(ce);
+}
+
void intel_context_bind_parent_child(struct intel_context *parent,
struct intel_context *child);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 6f567ebeb039..a63329520c35 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -246,6 +246,13 @@ struct intel_context {
* work queue descriptor
*/
u8 parent_page;
+
+ /**
+* @last_rq: last request submitted on a parallel context, used
+* to insert submit fences between request in the parallel
request -> requests
With that fixed:
Reviewed-by: John Harrison
+* context.
+*/
+ struct i915_request *last_rq;
};
#ifdef CONFIG_DRM_I915_SELFTEST
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b107ad095248..f0b60fecf253 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -672,8 +672,7 @@ static int rq_prio(const struct i915_request *rq)
static bool is_multi_lrc_rq(struct i915_request *rq)
{
- return intel_context_is_child(rq->context) ||
- intel_context_is_parent(rq->context);
+ return intel_context_is_parallel(rq->context);
}
static bool can_merge_rq(struct i915_request *rq,
@@ -2843,6 +2842,8 @@ static void guc_parent_context_unpin(struct intel_context
*ce)
GEM_BUG_ON(!intel_context_is_parent(ce));
GEM_BUG_ON(!intel_engine_is_virtual(ce->engine));
+ if (ce->last_rq)
+ i915_request_put(ce->last_rq);
unpin_guc_id(guc, ce);
lrc_unpin(ce);
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ce446716d092..2e51c8999088 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1546,36 +1546,62 @@ i915_request_await_object(struct i915_request *to,
return ret;
}
+static inline bool is_parallel_rq(struct i915_request *rq)
+{
+ return intel_context_is_parallel(rq->context);
+}
+
+static inline struct intel_context *request_to_parent(struct i915_request *rq)
+{
+ return intel_context_to_parent(rq->context);
+}
+
static struct i915_request *
-__i915_request_add_to_timeline(struct i915_request *rq)
+__i915_request_ensure_parallel_ordering(struct i915_request *rq,
+ struct intel_timeline *timeline)
{
- struct intel_timeline *timeline = i915_request_timeline(rq);
struct i915_request *prev;
- /*
-* Dependency tracking and request ordering along the timeline
-* is special cased so that we can eliminate redundant ordering
-* operations while building the request (we know that the timeline
-* itself is ordered, and here we guarantee it).
-*
-* As we know we will need to emit tracking along the timeline,
-* we embed the hooks into our request struct -- at the cost of
-* having to have specialised no-allocation interfaces (which will
-* be beneficial elsewhere).
-*
-* A second benefit to open-coding i915_request_await_request is
-* that we can apply a slight variant of the rules specialised
-* for timelines that jump between engines (such as virtual engines).
-* If we consider the case of virtual engine, we must emit a dma-fence
-* to prevent scheduling of the second request until the first is
-* complete (to maximise our greedy late load balancing) and this
-* precludes opt
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bdb: Fix version check
== Series Details ==
Series: drm/i915/bdb: Fix version check
URL : https://patchwork.freedesktop.org/series/94871/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10614 -> Patchwork_21101
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_21101 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21101, 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_21101/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21101:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- fi-ilk-650: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-ilk-650/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-ilk-650/igt@i915_module_l...@reload.html
- fi-ivb-3770:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-ivb-3770/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-ivb-3770/igt@i915_module_l...@reload.html
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-bsw-nick/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-bsw-nick/igt@i915_module_l...@reload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-jsl-1}: [INCOMPLETE][7] ([i915#4136]) -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-jsl-1/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-jsl-1/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_21101 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-sdma:
- fi-cfl-8109u: NOTRUN -> [SKIP][9] ([fdo#109271]) +17 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-cfl-8109u/igt@amdgpu/amd_ba...@cs-sdma.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-cfl-8700k: NOTRUN -> [SKIP][11] ([fdo#109271]) +17 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@amdgpu/amd_prime@i915-to-amd:
- fi-snb-2520m: NOTRUN -> [SKIP][12] ([fdo#109271]) +18 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html
* igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [PASS][13] -> [INCOMPLETE][14] ([i915#4130])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
- fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][15] ([i915#4130])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
- fi-icl-u2: [PASS][16] -> [INCOMPLETE][17] ([i915#4130])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u: [PASS][18] -> [INCOMPLETE][19] ([i915#146] /
[i915#198])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4: NOTRUN -> [SKIP][20] ([i915#2190])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- fi-bxt-dsi: [PASS][21] -> [INCOMPLETE][22] ([i915#4130])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10614/fi-bxt-dsi/igt@i915_module_l...@reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21101/fi-bxt-dsi/igt@i915_module_l..
[Intel-gfx] i915 Updates - ADLP DMC v2.12
Hi josh, Ben, Kyle Kindly add the below i915 changes to linux-firmware: linux-firmware: add frimware for mediatek bluetooth chip (MT7922) (2021-09-13 11:35:49 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware adlp_dmc_2_12 for you to fetch changes up to 09ab718bfa2b32a2186dd8f9e39e0cc9a9df7170: i915: Update ADLP DMC v2.12 (2021-09-14 14:42:47 -0700) Anusha Srivatsa (1): i915: Update ADLP DMC v2.12 WHENCE| 3 +++ i915/adlp_dmc_ver2_12.bin | Bin 0 -> 72104 bytes 2 files changed, 3 insertions(+) create mode 100644 i915/adlp_dmc_ver2_12.bin Thanks, Anusha
Re: [Intel-gfx] [PATCH 15/27] drm/i915/guc: Implement multi-lrc submission
On 8/20/2021 15:44, Matthew Brost wrote:
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet and bypass path have
been updated to coalesce requests into a single submission.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 21 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 6 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 312 +++---
drivers/gpu/drm/i915/i915_request.h | 8 +
6 files changed, 317 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index fbfcae727d7f..879aef662b2e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -748,3 +748,24 @@ void intel_guc_load_status(struct intel_guc *guc, struct
drm_printer *p)
}
}
}
+
+void intel_guc_write_barrier(struct intel_guc *guc)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+
+ if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
+ GEM_BUG_ON(guc->send_regs.fw_domains);
Granted, this patch is just moving code from one file to another not
changing it. However, I think it would be worth adding a blank line in
here. Otherwise the 'this register' comment below can be confusingly
read as referring to the send_regs.fw_domain entry above.
And maybe add a comment why it is a bug for the send_regs value to be
set? I'm not seeing any obvious connection between it and the reset of
this code.
+ /*
+* This register is used by the i915 and GuC for MMIO based
+* communication. Once we are in this code CTBs are the only
+* method the i915 uses to communicate with the GuC so it is
+* safe to write to this register (a value of 0 is NOP for MMIO
+* communication). If we ever start mixing CTBs and MMIOs a new
+* register will have to be chosen.
+*/
+ intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
+ } else {
+ /* wmb() sufficient for a barrier if in smem */
+ wmb();
+ }
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 3f95b1b4f15c..0ead2406d03c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -37,6 +37,12 @@ struct intel_guc {
/* Global engine used to submit requests to GuC */
struct i915_sched_engine *sched_engine;
struct i915_request *stalled_request;
+ enum {
+ STALL_NONE,
+ STALL_REGISTER_CONTEXT,
+ STALL_MOVE_LRC_TAIL,
+ STALL_ADD_REQUEST,
+ } submission_stall_reason;
/* intel_guc_recv interrupt related state */
spinlock_t irq_lock;
@@ -332,4 +338,6 @@ void intel_guc_submission_cancel_requests(struct intel_guc
*guc);
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p);
+void intel_guc_write_barrier(struct intel_guc *guc);
+
#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 20c710a74498..10d1878d2826 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -377,28 +377,6 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
return ++ct->requests.last_fence;
}
-static void write_barrier(struct intel_guc_ct *ct)
-{
- struct intel_guc *guc = ct_to_guc(ct);
- struct intel_gt *gt = guc_to_gt(guc);
-
- if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
- GEM_BUG_ON(guc->send_regs.fw_domains);
- /*
-* This register is used by the i915 and GuC for MMIO based
-* communication. Once we are in this code CTBs are the only
-* method the i915 uses to communicate with the GuC so it is
-* safe to write to this register (a value of 0 is NOP for MMIO
-* communication). If we ever start mixing CTBs and MMIOs a new
-* register will have to be chosen.
-*/
- intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
- } else {
- /* wmb() sufficient for a barrier if in smem */
- wmb();
- }
-}
-
static int ct_write(struct intel_guc_ct *ct,
const u32 *action,
u32 len /* in dwords */,
@@ -468,7 +446,7 @@ static int ct_write(struct intel_guc_ct *ct,
* make sure H2G buffer update and LRC tail update (if this triggering a
Re: [Intel-gfx] [PATCH 03/15] dmr/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
On 21/09/20 09:54AM, kernel test robot wrote: > > [auto build test ERROR on drm-exynos/exynos-drm-next] > [also build test ERROR on tegra-drm/drm/tegra/for-next linus/master v5.15-rc2 > next-20210917] I forgot to #include for those platforms and didn't notice because I only tried to build for X86. I'll fix it. > [cannot apply to drm-intel/for-linux-next tegra/for-next drm-tip/drm-tip > airlied/drm-next] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base'. I built this patch against drm-next, which currently points to v5.15-rc1. Should I be targeting a different branch? In any case, as suggested, I'll remember to use "--base" in the future to make it easier to apply. Thanks for the hint. > All errors (new ones prefixed by >>): > >In file included from include/drm/drm_crtc.h:36, > from include/drm/drm_atomic_helper.h:31, > from drivers/gpu/drm/msm/disp/msm_disp_snapshot.h:9, > from drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c:8: >drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c: In function > 'msm_disp_capture_atomic_state': > >> include/drm/drm_modeset_lock.h:167:14: error: implicit declaration of > >> function 'drm_drv_uses_atomic_modeset' > >> [-Werror=implicit-function-declaration] > 167 | if (!drm_drv_uses_atomic_modeset(dev)) > \ > | ^~~ >drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c:108:9: note: in > expansion of macro 'DRM_MODESET_LOCK_ALL_BEGIN' > 108 | DRM_MODESET_LOCK_ALL_BEGIN(ddev, ctx, 0, ret); > | ^~ >cc1: some warnings being treated as errors Out of curiosity: The top comment says there were two build errors (one on exynos and another one on tegra), but there is only one reported bug (on msm). Is this because the bot only reports the first error found? Is there a link to a report with each of the build errors on each of the platforms? Thanks.
Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
On Thu, 2021-09-16 at 12:32 +0200, Hans de Goede wrote: > > I'm fine with refactoring this a bit and adding > an intel_modeset_probe_defer() helper for this, I assume I should also > move the vga_switcheroo_client_probe_defer(pdev) check there? > > As you suggested yourself in your reply to the coverletter I will > push out the rest of the series to drm-misc-next while we figure this > out. Assuming Lyude is happy with the answers which I gave to her > remarks about some of the other patches. I am, btw! > > Regards, > > Hans > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH v1] drm/i915/bdb: Fix version check
On Mon, 2021-09-20 at 16:11 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch fixes it by comparing a total size of all fileds from
> the structure (present before the change) with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
>
> Cc: # 5.4+
> Tested-by: Lukasz Majczak
> Signed-off-by: Lukasz Majczak
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..052a19b455d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -452,7 +452,9 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>
> i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> + get_blocksize(backlight_data) >=
> (sizeof(backlight_data->entry_size) +
> + sizeof(backlight_data->data) +
> + sizeof(backlight_data->level))) {
Missing sizeof(backlight_data->backlight_control) but this is getting very
verbose.
Would be better have a expected size variable set each version set in the
beginning of this function.
something like:
switch (bdb->version) {
case 191:
expected_size = x;
break;
case 234:
expected_size = x;
break;
case 236:
default:
expected_size = x;
}
> const struct lfp_backlight_control_method *method;
>
> method = &backlight_data->backlight_control[panel_type];
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..fff456bf8783 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +/*
> + * Changing struct bdb_lfp_backlight_data might affect its
> + * size comparation to the value hold in BDB.
> + * (e.g. in parse_lfp_backlight())
> + */
This is true for all the blocks so I don't think we need this comment.
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
Re: [Intel-gfx] [PATCH] drm/i915: fix blank screen booting crashes
On Mon, Sep 20, 2021 at 08:42:42AM +0100, Tvrtko Ursulin wrote:
>
> On 20/09/2021 08:38, Jani Nikula wrote:
> > On Mon, 20 Sep 2021, Tvrtko Ursulin wrote:
> > > On 18/09/2021 00:38, Matthew Brost wrote:
> > > > From: Hugh Dickins
> > > >
> > > > 5.15-rc1 crashes with blank screen when booting up on two ThinkPads
> > > > using i915. Bisections converge convincingly, but arrive at different
> > > > and surprising "culprits", none of them the actual culprit.
> > >
> > > It is certainly surprising this patch crashed SNB and KBL.
> > >
> > > How feasible would it be to make this code just not run when GuC is not
> > > used? Given the field it adds is called ce->guc_blocked it sounds like a
> > > natural and preferable thing to do... if possible.
> > >
> > > > netconsole (with init_netconsole() hacked to call i915_init() when
> > > > logging has started, instead of by module_init()) tells the story:
> > > >
> > > > kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245!
> > > > with RSI: 814d408b pointing to sw_fence_dummy_notify().
> > > > I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that
> > > > function needs to be 4-byte aligned.
> > > >
> > > > v2:
> > > >(Jani Nikula)
> > > > - Change BUG_ON to WARN_ON
> > >
> > > However in this case the code would then go on and call into a wrong
> > > function offset which may be worse than a BUG_ON, no?
> >
> > So how about just
> >
> > if (WARN_ON(...))
> > return;
I don't think it is quite that simple as if we short circuit this
function fence->flags will be NULL which would be bad too. I'll have
make a few more changes to make this safe.
Matt
> >
> > or whatever is needed to give both the user and the CI a better
> > opportunity to see the error.
>
> Sounds good to me.
>
> Regards,
>
> Tvrtko
>
>
> >
> > BR,
> > Jani
> >
> >
> > >
> > > >
> > > > Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
> > > > Signed-off-by: Hugh Dickins
> > > > Signed-off-by: Matthew Brost
> > > > Reviewed-by: Matthew Brost
> > > > ---
> > > >drivers/gpu/drm/i915/gt/intel_context.c | 1 +
> > > >drivers/gpu/drm/i915/i915_sw_fence.c| 4 +++-
> > > >2 files changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index ff637147b1a9..f02c2202da9d 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -362,6 +362,7 @@ static int __intel_context_active(struct
> > > > i915_active *active)
> > > > return 0;
> > > >}
> > > > +__aligned(4) /* Respect the I915_SW_FENCE_MASK */
> > >
> > > Hugh suggested __i915_sw_fence_call which I think would be the right
> > > thing to do.
> > >
> > > Regards,
> > >
> > > Tvrtko
> > >
> > > >static int sw_fence_dummy_notify(struct i915_sw_fence *sf,
> > > > enum i915_sw_fence_notify state)
> > > >{
> > > > diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
> > > > b/drivers/gpu/drm/i915/i915_sw_fence.c
> > > > index c589a681da77..1217b124c1d0 100644
> > > > --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> > > > +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> > > > @@ -14,8 +14,10 @@
> > > >#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
> > > >#define I915_SW_FENCE_BUG_ON(expr) BUG_ON(expr)
> > > > +#define I915_SW_FENCE_WARN_ON(expr) WARN_ON(expr)
> > > >#else
> > > >#define I915_SW_FENCE_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
> > > > +#define I915_SW_FENCE_WARN_ON(expr) BUILD_BUG_ON_INVALID(expr)
> > > >#endif
> > > >static DEFINE_SPINLOCK(i915_sw_fence_lock);
> > > > @@ -242,7 +244,7 @@ void __i915_sw_fence_init(struct i915_sw_fence
> > > > *fence,
> > > > const char *name,
> > > > struct lock_class_key *key)
> > > >{
> > > > - BUG_ON(!fn || (unsigned long)fn & ~I915_SW_FENCE_MASK);
> > > > + I915_SW_FENCE_WARN_ON(!fn || (unsigned long)fn &
> > > > ~I915_SW_FENCE_MASK);
> > > > __init_waitqueue_head(&fence->wait, name, key);
> > > > fence->flags = (unsigned long)fn;
> > > >
> >
Re: [Intel-gfx] [PATCH] drm/i915: fix blank screen booting crashes
On Mon, Sep 20, 2021 at 08:28:13AM +0100, Tvrtko Ursulin wrote:
>
> On 18/09/2021 00:38, Matthew Brost wrote:
> > From: Hugh Dickins
> >
> > 5.15-rc1 crashes with blank screen when booting up on two ThinkPads
> > using i915. Bisections converge convincingly, but arrive at different
> > and surprising "culprits", none of them the actual culprit.
>
> It is certainly surprising this patch crashed SNB and KBL.
>
> How feasible would it be to make this code just not run when GuC is not
> used? Given the field it adds is called ce->guc_blocked it sounds like a
> natural and preferable thing to do... if possible.
>
I can likely do this in a follow up patch.
> > netconsole (with init_netconsole() hacked to call i915_init() when
> > logging has started, instead of by module_init()) tells the story:
> >
> > kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245!
> > with RSI: 814d408b pointing to sw_fence_dummy_notify().
> > I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that
> > function needs to be 4-byte aligned.
> >
> > v2:
> > (Jani Nikula)
> >- Change BUG_ON to WARN_ON
>
> However in this case the code would then go on and call into a wrong
> function offset which may be worse than a BUG_ON, no?
>
Yea, I guess that would be bad too.
> >
> > Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
> > Signed-off-by: Hugh Dickins
> > Signed-off-by: Matthew Brost
> > Reviewed-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 1 +
> > drivers/gpu/drm/i915/i915_sw_fence.c| 4 +++-
> > 2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index ff637147b1a9..f02c2202da9d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -362,6 +362,7 @@ static int __intel_context_active(struct i915_active
> > *active)
> > return 0;
> > }
> > +__aligned(4) /* Respect the I915_SW_FENCE_MASK */
>
> Hugh suggested __i915_sw_fence_call which I think would be the right thing
> to do.
>
Yep. Will do.
Matt
> Regards,
>
> Tvrtko
>
> > static int sw_fence_dummy_notify(struct i915_sw_fence *sf,
> > enum i915_sw_fence_notify state)
> > {
> > diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
> > b/drivers/gpu/drm/i915/i915_sw_fence.c
> > index c589a681da77..1217b124c1d0 100644
> > --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> > +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> > @@ -14,8 +14,10 @@
> > #if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
> > #define I915_SW_FENCE_BUG_ON(expr) BUG_ON(expr)
> > +#define I915_SW_FENCE_WARN_ON(expr) WARN_ON(expr)
> > #else
> > #define I915_SW_FENCE_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
> > +#define I915_SW_FENCE_WARN_ON(expr) BUILD_BUG_ON_INVALID(expr)
> > #endif
> > static DEFINE_SPINLOCK(i915_sw_fence_lock);
> > @@ -242,7 +244,7 @@ void __i915_sw_fence_init(struct i915_sw_fence *fence,
> > const char *name,
> > struct lock_class_key *key)
> > {
> > - BUG_ON(!fn || (unsigned long)fn & ~I915_SW_FENCE_MASK);
> > + I915_SW_FENCE_WARN_ON(!fn || (unsigned long)fn & ~I915_SW_FENCE_MASK);
> > __init_waitqueue_head(&fence->wait, name, key);
> > fence->flags = (unsigned long)fn;
> >
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Check SFC fusing on Xe_HP (rev4)
On Mon, Sep 20, 2021 at 06:55:52PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Check SFC fusing on Xe_HP (rev4)
> URL : https://patchwork.freedesktop.org/series/94808/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10613 -> Patchwork_21099
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_21099 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21099, 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_21099/index.html
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_21099:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_module_load@reload:
> - fi-snb-2520m: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-snb-2520m/igt@i915_module_l...@reload.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-snb-2520m/igt@i915_module_l...@reload.html
> - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-kefka/igt@i915_module_l...@reload.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-kefka/igt@i915_module_l...@reload.html
> - fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-nick/igt@i915_module_l...@reload.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-nick/igt@i915_module_l...@reload.html
All three of these are page faults originating from the snd_hda_core
code. There seem to be a lot of problems originating from the sound
code that came in with the 5.15-rc1 merge; these aren't caused by the
SFC fusing checks in this series.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_module_load@reload:
> - {fi-jsl-1}: [INCOMPLETE][7] ([i915#4130]) -> [INCOMPLETE][8]
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-jsl-1/igt@i915_module_l...@reload.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-jsl-1/igt@i915_module_l...@reload.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_21099 that come from known issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@amdgpu/amd_basic@semaphore:
> - fi-bdw-5557u: NOTRUN -> [SKIP][9] ([fdo#109271]) +27 similar
> issues
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
>
> * igt@amdgpu/amd_basic@userptr:
> - fi-bxt-dsi: NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar
> issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bxt-dsi/igt@amdgpu/amd_ba...@userptr.html
>
> * igt@amdgpu/amd_cs_nop@fork-gfx0:
> - fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#109315]) +17 similar
> issues
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
>
> * igt@amdgpu/amd_cs_nop@sync-gfx0:
> - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109315]) +17 similar
> issues
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-11600/igt@amdgpu/amd_cs_...@sync-gfx0.html
>
> * igt@core_hotunplug@unbind-rebind:
> - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][13] ([i915#4130])
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
> - fi-kbl-7567u: [PASS][14] -> [INCOMPLETE][15] ([i915#4130])
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
> - fi-bdw-5557u: NOTRUN -> [WARN][16] ([i915#3718])
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
>
> * igt@gem_exec_suspend@basic-s3:
> - fi-tgl-1115g4: NOTRUN -> [FAIL][17] ([i915#1888])
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
>
> * igt@gem_huc_copy@huc-copy:
> - fi-tgl-1115g4: NOTRUN -> [SKIP][18] ([i915#2190])
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
>
> * igt@i915_module_load
[Intel-gfx] [PATCH v1] drm/i915/bdb: Fix version check
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
the size of bdb_lfp_backlight_data structure has been increased,
causing if-statement in the parse_lfp_backlight function
that comapres this structure size to the one retrieved from BDB,
always to fail for older revisions.
This patch fixes it by comparing a total size of all fileds from
the structure (present before the change) with the value gathered from BDB.
Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Cc: # 5.4+
Tested-by: Lukasz Majczak
Signed-off-by: Lukasz Majczak
---
drivers/gpu/drm/i915/display/intel_bios.c | 4 +++-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 3c25926092de..052a19b455d1 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -452,7 +452,9 @@ parse_lfp_backlight(struct drm_i915_private *i915,
i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
if (bdb->version >= 191 &&
- get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
+ get_blocksize(backlight_data) >=
(sizeof(backlight_data->entry_size) +
+ sizeof(backlight_data->data) +
+ sizeof(backlight_data->level))) {
const struct lfp_backlight_control_method *method;
method = &backlight_data->backlight_control[panel_type];
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 330077c2e588..fff456bf8783 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -814,6 +814,11 @@ struct lfp_brightness_level {
u16 reserved;
} __packed;
+/*
+ * Changing struct bdb_lfp_backlight_data might affect its
+ * size comparation to the value hold in BDB.
+ * (e.g. in parse_lfp_backlight())
+ */
struct bdb_lfp_backlight_data {
u8 entry_size;
struct lfp_backlight_data_entry data[16];
--
2.33.0.464.g1972c5931b-goog
Re: [Intel-gfx] [PATCH 2/2] Add drm buddy manager support to amdgpu driver
On Mon, Sep 20, 2021 at 3:21 PM Arunpravin
wrote:
>
> Replace drm_mm with drm buddy manager for
> VRAM memory management
Would be good to document why we are doing this and what advantages it
brings over the old drm_mm code.
Alex
>
> Signed-off-by: Arunpravin
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 78 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 216 ++
> 3 files changed, 189 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
> index acfa207cf970..ba24052e9062 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
> @@ -30,12 +30,25 @@
> #include
> #include
>
> +struct amdgpu_vram_mgr_node {
> + struct ttm_range_mgr_node tnode;
> + struct list_head blocks;
> +};
> +
> +static inline struct amdgpu_vram_mgr_node *
> +to_amdgpu_vram_mgr_node(struct ttm_resource *res)
> +{
> + return container_of(container_of(res, struct ttm_range_mgr_node,
> base),
> + struct amdgpu_vram_mgr_node, tnode);
> +}
> +
> /* state back for walking over vram_mgr and gtt_mgr allocations */
> struct amdgpu_res_cursor {
> uint64_tstart;
> uint64_tsize;
> uint64_tremaining;
> - struct drm_mm_node *node;
> + void*node;
> + uint32_tmem_type;
> };
>
> /**
> @@ -52,8 +65,6 @@ static inline void amdgpu_res_first(struct ttm_resource
> *res,
> uint64_t start, uint64_t size,
> struct amdgpu_res_cursor *cur)
> {
> - struct drm_mm_node *node;
> -
> if (!res || res->mem_type == TTM_PL_SYSTEM) {
> cur->start = start;
> cur->size = size;
> @@ -65,14 +76,39 @@ static inline void amdgpu_res_first(struct ttm_resource
> *res,
>
> BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
>
> - node = to_ttm_range_mgr_node(res)->mm_nodes;
> - while (start >= node->size << PAGE_SHIFT)
> - start -= node++->size << PAGE_SHIFT;
> + cur->mem_type = res->mem_type;
> +
> + if (cur->mem_type == TTM_PL_VRAM) {
> + struct drm_buddy_block *block;
> + struct list_head *head, *next;
> +
> + head = &to_amdgpu_vram_mgr_node(res)->blocks;
> +
> + block = list_first_entry_or_null(head, struct
> drm_buddy_block, link);
> + while (start >= block->size << PAGE_SHIFT) {
> + start -= block->size << PAGE_SHIFT;
> +
> + next = block->link.next;
> + if (next != head)
> + block = list_entry(next, struct
> drm_buddy_block, link);
> + }
>
> - cur->start = (node->start << PAGE_SHIFT) + start;
> - cur->size = min((node->size << PAGE_SHIFT) - start, size);
> - cur->remaining = size;
> - cur->node = node;
> + cur->start = (block->start << PAGE_SHIFT) + start;
> + cur->size = min((block->size << PAGE_SHIFT) - start, size);
> + cur->remaining = size;
> + cur->node = block;
> + } else if (cur->mem_type == TTM_PL_TT) {
> + struct drm_mm_node *node;
> +
> + node = to_ttm_range_mgr_node(res)->mm_nodes;
> + while (start >= node->size << PAGE_SHIFT)
> + start -= node++->size << PAGE_SHIFT;
> +
> + cur->start = (node->start << PAGE_SHIFT) + start;
> + cur->size = min((node->size << PAGE_SHIFT) - start, size);
> + cur->remaining = size;
> + cur->node = node;
> + }
> }
>
> /**
> @@ -85,8 +121,6 @@ static inline void amdgpu_res_first(struct ttm_resource
> *res,
> */
> static inline void amdgpu_res_next(struct amdgpu_res_cursor *cur, uint64_t
> size)
> {
> - struct drm_mm_node *node = cur->node;
> -
> BUG_ON(size > cur->remaining);
>
> cur->remaining -= size;
> @@ -99,9 +133,23 @@ static inline void amdgpu_res_next(struct
> amdgpu_res_cursor *cur, uint64_t size)
> return;
> }
>
> - cur->node = ++node;
> - cur->start = node->start << PAGE_SHIFT;
> - cur->size = min(node->size << PAGE_SHIFT, cur->remaining);
> + if (cur->mem_type == TTM_PL_VRAM) {
> + struct drm_buddy_block *block = cur->node;
> + struct list_head *next;
> +
> + next = block->link.next;
> + block = list_entry(next, struct drm_buddy_block, link);
> +
> + cur->node = block;
> + cur->start = block->start << PAGE_SHIFT;
> + cur->size = min(block->size << PAGE_SHIFT, cur->remain
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Suspend / resume backup- and restore of LMEM. (rev6)
== Series Details == Series: drm/i915: Suspend / resume backup- and restore of LMEM. (rev6) URL : https://patchwork.freedesktop.org/series/94278/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10613 -> Patchwork_21100 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21100 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21100, 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_21100/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21100: ### IGT changes ### Possible regressions * igt@i915_module_load@reload: - fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-skl-6600u/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-skl-6600u/igt@i915_module_l...@reload.html - fi-ivb-3770:[PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-ivb-3770/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-ivb-3770/igt@i915_module_l...@reload.html - fi-bsw-kefka: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-kefka/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-bsw-kefka/igt@i915_module_l...@reload.html - fi-bsw-nick:[PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-nick/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-bsw-nick/igt@i915_module_l...@reload.html Known issues Here are the changes found in Patchwork_21100 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-sdma: - fi-kbl-7500u: NOTRUN -> [SKIP][9] ([fdo#109271]) +17 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271]) +27 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@nop-compute0: - fi-ilk-650: NOTRUN -> [SKIP][11] ([fdo#109271]) +18 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109315]) +17 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-rkl-11600/igt@amdgpu/amd_cs_...@sync-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-cfl-guc: [PASS][13] -> [INCOMPLETE][14] ([i915#4130]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-cfl-guc/igt@core_hotunp...@unbind-rebind.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-cfl-guc/igt@core_hotunp...@unbind-rebind.html - fi-kbl-7567u: [PASS][15] -> [INCOMPLETE][16] ([i915#4130]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html - fi-bdw-5557u: NOTRUN -> [WARN][17] ([i915#3718]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_module_load@reload: - fi-cfl-8109u: NOTRUN -> [INCOMPLETE][18] ([i915#4130]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-cfl-8109u/igt@i915_module_l...@reload.html - fi-icl-y: [PASS][19] -> [INCOMPLETE][20] ([i915#4130]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-icl-y/igt@i915_module_l...@reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-icl-y/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-snb-2600:NOTRUN -> [SKIP][21] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-snb-2600/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:NOTRUN -> [INCOMPLETE][22] ([i915#3921]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21100/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - fi-pnv-d510:[PASS][23] -> [DMESG-FAIL][24] ([i915#4140]
Re: [Intel-gfx] [PATCH 1/2] Enable buddy memory manager support
On Mon, Sep 20, 2021 at 3:21 PM Arunpravin
wrote:
Please prefix the patch subject with drm. E.g.,
drm: Enable buddy memory manager support
Same for the second patch, but make it drm/amdgpu instead.
Alex
>
> Port Intel buddy system manager to drm root folder
> Add CPU mappable/non-mappable region support to the drm buddy manager
>
> Signed-off-by: Arunpravin
> ---
> drivers/gpu/drm/Makefile| 2 +-
> drivers/gpu/drm/drm_buddy.c | 465
> include/drm/drm_buddy.h | 154
> 3 files changed, 620 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_buddy.c
> create mode 100644 include/drm/drm_buddy.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a118692a6df7..fe1a2fc09675 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -18,7 +18,7 @@ drm-y :=drm_aperture.o drm_auth.o drm_cache.o
> \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
> - drm_managed.o drm_vblank_work.o
> + drm_managed.o drm_vblank_work.o drm_buddy.o
>
> drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o
> drm_dma.o \
> drm_legacy_misc.o drm_lock.o drm_memory.o
> drm_scatter.o \
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> new file mode 100644
> index ..f07919a004b6
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -0,0 +1,465 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright � 2021 Intel Corporation
> + */
> +
> +#include
> +#include
> +
> +static struct drm_buddy_block *drm_block_alloc(struct drm_buddy_mm *mm,
> + struct drm_buddy_block *parent, unsigned int order,
> + u64 offset)
> +{
> + struct drm_buddy_block *block;
> +
> + BUG_ON(order > DRM_BUDDY_MAX_ORDER);
> +
> + block = kmem_cache_zalloc(mm->slab_blocks, GFP_KERNEL);
> + if (!block)
> + return NULL;
> +
> + block->header = offset;
> + block->header |= order;
> + block->parent = parent;
> + block->start = offset >> PAGE_SHIFT;
> + block->size = (mm->chunk_size << order) >> PAGE_SHIFT;
> +
> + BUG_ON(block->header & DRM_BUDDY_HEADER_UNUSED);
> + return block;
> +}
> +
> +static void drm_block_free(struct drm_buddy_mm *mm, struct drm_buddy_block
> *block)
> +{
> + kmem_cache_free(mm->slab_blocks, block);
> +}
> +
> +static void add_ordered(struct drm_buddy_mm *mm, struct drm_buddy_block
> *block)
> +{
> + struct drm_buddy_block *node;
> +
> + if (list_empty(&mm->free_list[drm_buddy_block_order(block)])) {
> + list_add(&block->link,
> + &mm->free_list[drm_buddy_block_order(block)]);
> + return;
> + }
> +
> + list_for_each_entry(node,
> &mm->free_list[drm_buddy_block_order(block)], link)
> + if (block->start > node->start)
> + break;
> +
> + __list_add(&block->link, node->link.prev, &node->link);
> +}
> +
> +static void mark_allocated(struct drm_buddy_block *block)
> +{
> + block->header &= ~DRM_BUDDY_HEADER_STATE;
> + block->header |= DRM_BUDDY_ALLOCATED;
> +
> + list_del(&block->link);
> +}
> +
> +static void mark_free(struct drm_buddy_mm *mm,
> + struct drm_buddy_block *block)
> +{
> + block->header &= ~DRM_BUDDY_HEADER_STATE;
> + block->header |= DRM_BUDDY_FREE;
> +
> + add_ordered(mm, block);
> +}
> +
> +static void mark_split(struct drm_buddy_block *block)
> +{
> + block->header &= ~DRM_BUDDY_HEADER_STATE;
> + block->header |= DRM_BUDDY_SPLIT;
> +
> + list_del(&block->link);
> +}
> +
> +int drm_buddy_init(struct drm_buddy_mm *mm, u64 size, u64 chunk_size)
> +{
> + unsigned int i;
> + u64 offset;
> +
> + if (size < chunk_size)
> + return -EINVAL;
> +
> + if (chunk_size < PAGE_SIZE)
> + return -EINVAL;
> +
> + if (!is_power_of_2(chunk_size))
> + return -EINVAL;
> +
> + size = round_down(size, chunk_size);
> +
> + mm->size = size;
> + mm->chunk_size = chunk_size;
> + mm->max_order = ilog2(size) - ilog2(chunk_size);
> +
> + BUG_ON(mm->max_order > DRM_BUDDY_MAX_ORDER);
> +
> + mm->slab_blocks = KMEM_CACHE(drm_buddy_block, SLAB_HWCACHE_ALIGN);
> +
> + if (!mm->slab_blocks)
> + return -ENOMEM;
> +
> + mm->free_list = kmalloc_array(mm->max_order + 1,
> + sizeof(struct list_head),
> + GFP_KERNEL);
> + if (!mm->free_list)
> + goto out_destroy_slab;
> +
> + for (i = 0; i <= mm->max_order;
Re: [Intel-gfx] [PATCH] drm/i915: Make wa list per-gt
On Fri, 2021-09-17 at 10:08 -0700, Matt Roper wrote:
> From: Venkata Sandeep Dhanalakota
>
> Support for multiple GT's within a single i915 device will be
> arriving
> soon. Since each GT may have its own fusing and require different
> workarounds, we need to make the GT workaround functions and
> multicast
> steering setup per-gt.
>
> Cc: Tvrtko Ursulin
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Venkata Sandeep Dhanalakota <
> venkata.s.dhanalak...@intel.com>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 143 +---
> --
> drivers/gpu/drm/i915/gt/intel_workarounds.h | 2 +-
> .../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 2 -
> drivers/gpu/drm/i915/i915_drv.h | 2 -
> drivers/gpu/drm/i915/i915_gem.c | 2 -
> 8 files changed, 81 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 55e87aff51d2..449ff6e83543 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -660,6 +660,8 @@ int intel_gt_init(struct intel_gt *gt)
> if (err)
> return err;
>
> + intel_gt_init_workarounds(gt);
> +
> /*
>* This is just a security blanket to placate dragons.
>* On some systems, we very sporadically observe that the first
> TLBs
> @@ -767,6 +769,7 @@ void intel_gt_driver_release(struct intel_gt *gt)
> if (vm) /* FIXME being called twice on error paths :( */
> i915_vm_put(vm);
>
> + intel_wa_list_free(>->wa_list);
> intel_gt_pm_fini(gt);
> intel_gt_fini_scratch(gt);
> intel_gt_fini_buffer_pool(gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index 6fdcde64c180..ce127cae9e49 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -72,6 +72,8 @@ struct intel_gt {
>
> struct intel_uc uc;
>
> + struct i915_wa_list wa_list;
> +
> struct intel_gt_timelines {
> spinlock_t lock; /* protects active_list */
> struct list_head active_list;
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index c314d4917b6b..1f0a54b383d9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -804,7 +804,7 @@ int intel_engine_emit_ctx_wa(struct i915_request
> *rq)
> }
>
> static void
> -gen4_gt_workarounds_init(struct drm_i915_private *i915,
> +gen4_gt_workarounds_init(struct intel_gt *gt,
>struct i915_wa_list *wal)
> {
> /* WaDisable_RenderCache_OperationalFlush:gen4,ilk */
> @@ -812,29 +812,29 @@ gen4_gt_workarounds_init(struct
> drm_i915_private *i915,
> }
>
> static void
> -g4x_gt_workarounds_init(struct drm_i915_private *i915, struct
> i915_wa_list *wal)
> +g4x_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list
> *wal)
> {
> - gen4_gt_workarounds_init(i915, wal);
> + gen4_gt_workarounds_init(gt, wal);
>
> /* WaDisableRenderCachePipelinedFlush:g4x,ilk */
> wa_masked_en(wal, CACHE_MODE_0,
> CM0_PIPELINED_RENDER_FLUSH_DISABLE);
> }
>
> static void
> -ilk_gt_workarounds_init(struct drm_i915_private *i915, struct
> i915_wa_list *wal)
> +ilk_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list
> *wal)
> {
> - g4x_gt_workarounds_init(i915, wal);
> + g4x_gt_workarounds_init(gt, wal);
>
> wa_masked_en(wal, _3D_CHICKEN2,
> _3D_CHICKEN2_WM_READ_PIPELINED);
> }
>
> static void
> -snb_gt_workarounds_init(struct drm_i915_private *i915, struct
> i915_wa_list *wal)
> +snb_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list
> *wal)
> {
> }
>
> static void
> -ivb_gt_workarounds_init(struct drm_i915_private *i915, struct
> i915_wa_list *wal)
> +ivb_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list
> *wal)
> {
> /* Apply the WaDisableRHWOOptimizationForRenderHang:ivb
> workaround. */
> wa_masked_dis(wal,
> @@ -850,7 +850,7 @@ ivb_gt_workarounds_init(struct drm_i915_private
> *i915, struct i915_wa_list *wal)
> }
>
> static void
> -vlv_gt_workarounds_init(struct drm_i915_private *i915, struct
> i915_wa_list *wal)
> +vlv_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list
> *wal)
> {
> /* WaForceL3Serialization:vlv */
> wa_write_clr(wal, GEN7_L3SQCREG4,
> L3SQ_URB_READ_CAM_MATCH_DISABLE);
> @@ -863,7 +863,7 @@ vlv_gt_workarounds_init(struct drm_i915_private
> *i915, struct i915_wa_list *wal)
> }
>
> static void
> -hsw_gt_workarounds_init(struct drm_i915_private *i915, struct
> i915_wa_list *wal)
> +hsw_gt_workarounds_init(struct intel_gt *gt, struct i91
Re: [Intel-gfx] [PATCH 1/3] drm/i915/display/dmc: Set DC_STATE_DEBUG_MASK_CORES after firmware load
On Sat, Sep 18, 2021 at 12:06:01AM +0300, Imre Deak wrote:
> On Fri, Sep 17, 2021 at 01:52:39PM -0700, José Roberto de Souza wrote:
> > Specification asks for DC_STATE_DEBUG_MASK_CORES to be set for all
> > platforms that supports DMC, not only for geminilake and broxton.
>
> According to the spec it's only required for BXT and GLK, see
> Bspec 4234, 49193, 49194.
>
> The register description is a bit vague, would need to be clarified
> probably.
The spec got updated now for TGL+, thanks. Provided that you can
get the spec up-to-date for GEN9 platforms as well:
Reviewed-by: Imre Deak
>
> > While at is also taking the oportunity to simply the code.
> >
> > BSpec: 7402
> > BSpec: 49436
> > Cc: Imre Deak
> > Cc: Gwan-gyeong Mun
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 16 +++-
> > 1 file changed, 3 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> > b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index b0268552b2863..2dc9d632969db 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -255,20 +255,10 @@ intel_get_stepping_info(struct drm_i915_private *i915,
> >
> > static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
> > {
> > - u32 val, mask;
> > -
> > - mask = DC_STATE_DEBUG_MASK_MEMORY_UP;
> > -
> > - if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
> > - mask |= DC_STATE_DEBUG_MASK_CORES;
> > -
> > /* The below bit doesn't need to be cleared ever afterwards */
> > - val = intel_de_read(dev_priv, DC_STATE_DEBUG);
> > - if ((val & mask) != mask) {
> > - val |= mask;
> > - intel_de_write(dev_priv, DC_STATE_DEBUG, val);
> > - intel_de_posting_read(dev_priv, DC_STATE_DEBUG);
> > - }
> > + intel_de_rmw(dev_priv, DC_STATE_DEBUG, 0,
> > +DC_STATE_DEBUG_MASK_CORES | DC_STATE_DEBUG_MASK_MEMORY_UP);
> > + intel_de_posting_read(dev_priv, DC_STATE_DEBUG);
> > }
> >
> > /**
> > --
> > 2.33.0
> >
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Suspend / resume backup- and restore of LMEM. (rev6)
== Series Details == Series: drm/i915: Suspend / resume backup- and restore of LMEM. (rev6) URL : https://patchwork.freedesktop.org/series/94278/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5fe8cae9d0ac drm/i915/ttm: Implement a function to copy the contents of two TTM-based objects c446f298a66d drm/i915/gem: Implement a function to process all gem objects of a region 1a68e6875e24 drm/i915 Implement LMEM backup and restore for suspend / resume -:287: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #287: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 459 lines checked aa022e1a6969 drm/i915/gt: Register the migrate contexts with their engines cc2f68116763 drm/i915: Don't back up pinned LMEM context images and rings during suspend c222b6056f94 drm/i915: Reduce the number of objects subject to memcpy recover
[Intel-gfx] ✗ Fi.CI.BAT: failure for Check SFC fusing on Xe_HP (rev4)
== Series Details ==
Series: Check SFC fusing on Xe_HP (rev4)
URL : https://patchwork.freedesktop.org/series/94808/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10613 -> Patchwork_21099
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_21099 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21099, 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_21099/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21099:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- fi-snb-2520m: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-snb-2520m/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-snb-2520m/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-kefka/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-kefka/igt@i915_module_l...@reload.html
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-bsw-nick/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bsw-nick/igt@i915_module_l...@reload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-jsl-1}: [INCOMPLETE][7] ([i915#4130]) -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-jsl-1/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-jsl-1/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_21099 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][9] ([fdo#109271]) +27 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_basic@userptr:
- fi-bxt-dsi: NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bxt-dsi/igt@amdgpu/amd_ba...@userptr.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#109315]) +17 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109315]) +17 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-11600/igt@amdgpu/amd_cs_...@sync-gfx0.html
* igt@core_hotunplug@unbind-rebind:
- fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][13] ([i915#4130])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
- fi-kbl-7567u: [PASS][14] -> [INCOMPLETE][15] ([i915#4130])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
- fi-bdw-5557u: NOTRUN -> [WARN][16] ([i915#3718])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4: NOTRUN -> [FAIL][17] ([i915#1888])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4: NOTRUN -> [SKIP][18] ([i915#2190])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- fi-rkl-guc: [PASS][19] -> [DMESG-WARN][20] ([i915#4136])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10613/fi-rkl-guc/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-rkl-guc/igt@i915_module_l...@reload.html
- fi-cfl-8109u: NOTRUN -> [INCOMPLETE][21] ([i915#4136])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21099/fi-cfl-8109u/igt@i915_module_l...@reload.html
- fi-icl-y: [PASS][22] -> [INCOMPLETE][23] ([i915#4130])
[22]:
htt
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Check SFC fusing on Xe_HP (rev4)
== Series Details == Series: Check SFC fusing on Xe_HP (rev4) URL : https://patchwork.freedesktop.org/series/94808/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen8_write32' - different lock contexts
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: Match PSR2 selective fetch sequences with specification
Looks good to me.
Tested-by: Gwan-gyeong Mun
Reviewed-by: Gwan-gyeong Mun
On 9/17/21 11:52 PM, José Roberto de Souza wrote:
We were not completely following the selective fetch programming
sequence, here some things we were doing wrong:
- not programming plane selective fetch a PSR2_MAN_TRK_CTL registers
when doing a modeset
- programming PSR2_MAN_TRK_CTL out of vblank
With this changes the last remainig underrun found in Alderlake-P is
fixed.
Bspec: 55229
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_cursor.c | 4 ++-
drivers/gpu/drm/i915/display/intel_display.c | 12 +++
drivers/gpu/drm/i915/display/intel_psr.c | 33 ++-
drivers/gpu/drm/i915/display/intel_psr.h | 2 ++
.../drm/i915/display/skl_universal_plane.c| 4 +--
5 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index c7618fef01439..901ad3a4c8c3b 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -536,8 +536,10 @@ static void i9xx_update_cursor(struct intel_plane *plane,
if (DISPLAY_VER(dev_priv) >= 9)
skl_write_cursor_wm(plane, crtc_state);
- if (!intel_crtc_needs_modeset(crtc_state))
+ if (plane_state)
intel_psr2_program_plane_sel_fetch(plane, crtc_state,
plane_state, 0);
+ else
+ intel_psr2_disable_plane_sel_fetch(plane, crtc_state);
if (plane->cursor.base != base ||
plane->cursor.size != fbc_ctl ||
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f6c0c595f6313..224bf622a1c1a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6812,11 +6812,9 @@ static int intel_crtc_atomic_check(struct
intel_atomic_state *state,
}
- if (!mode_changed) {
- ret = intel_psr2_sel_fetch_update(state, crtc);
- if (ret)
- return ret;
- }
+ ret = intel_psr2_sel_fetch_update(state, crtc);
+ if (ret)
+ return ret;
return 0;
}
@@ -9709,10 +9707,10 @@ static void commit_pipe_pre_planes(struct
intel_atomic_state *state,
if (new_crtc_state->update_pipe)
intel_pipe_fastset(old_crtc_state, new_crtc_state);
-
- intel_psr2_program_trans_man_trk_ctl(new_crtc_state);
}
+ intel_psr2_program_trans_man_trk_ctl(new_crtc_state);
+
if (dev_priv->display.atomic_update_watermarks)
dev_priv->display.atomic_update_watermarks(state, crtc);
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index bd13325782f11..101a23bdd7b5b 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -561,15 +561,16 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
val |= EDP_PSR2_SU_SDP_SCANLINE;
if (intel_dp->psr.psr2_sel_fetch_enabled) {
+ u32 tmp;
+
/* Wa_1408330847 */
if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK,
DIS_RAM_BYPASS_PSR2_MAN_TRACK);
- intel_de_write(dev_priv,
- PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
- PSR2_MAN_TRK_CTL_ENABLE);
+ tmp = intel_de_read(dev_priv,
PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder));
+ drm_WARN_ON(&dev_priv->drm, !(tmp & PSR2_MAN_TRK_CTL_ENABLE));
} else if (HAS_PSR2_SEL_FETCH(dev_priv)) {
intel_de_write(dev_priv,
PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder), 0);
@@ -1450,6 +1451,18 @@ static void psr_force_hw_tracking_exit(struct intel_dp
*intel_dp)
intel_de_write(dev_priv, CURSURFLIVE(intel_dp->psr.pipe), 0);
}
+void intel_psr2_disable_plane_sel_fetch(struct intel_plane *plane,
+ const struct intel_crtc_state
*crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+
+ if (!crtc_state->enable_psr2_sel_fetch)
+ return;
+
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), 0);
+}
+
void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
const struct intel_crtc_state
*crtc_state,
const struct intel_plane_state
*plane_state,
@@ -1464,11 +1477,11 @@ void intel_psr2_program_plane_sel_fetch(struct
intel_plane *plane,
if (!crtc_state->enable_psr2_sel_fetch)
Re: [Intel-gfx] [PATCH v2 6/9] vfio/mdev: Add mdev available instance checking to the core
On Thu, Sep 09 2021, Jason Gunthorpe wrote: > Many of the mdev drivers use a simple counter for keeping track of the > available instances. Move this code to the core code and store the counter > in the mdev_type. Implement it using correct locking, fixing mdpy. > > Drivers provide a get_available() callback to set the number of available > instances for their mtypes which is fixed at registration time. The core > provides a standard sysfs attribute to return the available_instances. So, according to the documentation, available_instances is mandatory. This means that drivers either need to provide get_available or implement their own version of the attribute. I think we want to update vfio-mediated-device.rst as well? > > Signed-off-by: Jason Gunthorpe > --- > drivers/s390/cio/vfio_ccw_drv.c | 1 - > drivers/s390/cio/vfio_ccw_ops.c | 26 ++- > drivers/s390/cio/vfio_ccw_private.h | 2 -- > drivers/s390/crypto/vfio_ap_ops.c | 32 ++- > drivers/s390/crypto/vfio_ap_private.h | 2 -- > drivers/vfio/mdev/mdev_core.c | 11 +++- > drivers/vfio/mdev/mdev_private.h | 2 ++ > drivers/vfio/mdev/mdev_sysfs.c| 37 +++ > include/linux/mdev.h | 2 ++ > samples/vfio-mdev/mdpy.c | 22 +--- > 10 files changed, 73 insertions(+), 64 deletions(-) Otherwise, looks good.
Re: [Intel-gfx] [PATCH v10 09/17] drm/i915/pxp: Implement PXP irq handler
On Mon, Sep 20, 2021 at 04:18:10PM +, Teres Alexis, Alan Previn wrote:
>
> On Mon, 2021-09-20 at 12:04 -0400, Rodrigo Vivi wrote:
> > On Fri, Sep 17, 2021 at 09:20:00PM -0700, Alan Previn wrote:
> > > From: "Huang, Sean Z"
> > >
> > > The HW will generate a teardown interrupt when session termination is
> > > required, which requires i915 to submit a terminating batch. Once the HW
> > > is done with the termination it will generate another interrupt, at
> > > which point it is safe to re-create the session.
> > >
> > > Since the termination and re-creation flow is something we want to
> > > trigger from the driver as well, use a common work function that can be
> > > called both from the irq handler and from the driver set-up flows, which
> > > has the addded benefit of allowing us to skip any extra locks because
> > > the work itself serializes the operations.
> > >
> > > v2: use struct completion instead of bool (Chris)
> > > v3: drop locks, clean up functions and improve comments (Chris),
> > > move to common work function.
> > > v4: improve comments, simplify wait logic (Rodrigo)
> > > v5: unconditionally set interrupts, rename state_attacked var (Rodrigo)
> > >
> > > Signed-off-by: Alan Previn
> > > Signed-off-by: Huang, Sean Z
> > > Signed-off-by: Daniele Ceraolo Spurio
> > > Cc: Chris Wilson
> > > Cc: Rodrigo Vivi
> > > Reviewed-by: Rodrigo Vivi
> > > ---
> > > +#include
> > > +#include "intel_pxp.h"
> > > +#include "intel_pxp_irq.h"
> > > +#include "intel_pxp_session.h"
> > > +#include "gt/intel_gt_irq.h"
> > > +#include "gt/intel_gt_types.h"
> > > +#include "i915_irq.h"
> > > +#include "i915_reg.h"
> > > +
> > > +/**
> > > + * intel_pxp_irq_handler - Handles PXP interrupts.
> > > + * @pxp: pointer to pxp struct
> > > + * @iir: interrupt vector
> > > + */
> > > +void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
> > > +{
> > > + struct intel_gt *gt = pxp_to_gt(pxp);
> >
> > this compiles, but I don't see how this can work.
> >
> > shouldn't we use the container_of here directly instead of trying
> > to use something that is not properly defined?
> >
> Its now a function that's abstracted in .c file and prototype defined in the
> intel_pxp.h. Unless i
> misunderstood something, i thought this was one of the options discussed in
> last rev - i can change it
> again to use the container_of directly in all the instances if you like. side
> note: inline was still
> defined but only for the CONFIG_PXP==off case that doesn't require the
> additional header inclusions.
Oh, indeed Sorry
If this was not working we would get an "Undefined referrence" in the face.
Reviewed-by: Rodrigo Vivi
for this v as well.
>
> > > +
Re: [Intel-gfx] [PATCH v1] drm/i915/bdb: Fix version check
On Mon, 20 Sep 2021, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch fixes it by comparing a total size of all fileds from
> the structure (present before the change) with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
>
> Cc: # 5.4+
Not a review of the patch, I'll leave that to José, but 5.4 is not
right.
The commit is d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT
234+") which was merged in v5.11 and AFAICT has not been backported to
any stable kernel.
So this would be:
Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+")
Cc: # v5.11+
BR,
Jani.
> Tested-by: Lukasz Majczak
> Signed-off-by: Lukasz Majczak
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..052a19b455d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -452,7 +452,9 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>
> i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> + get_blocksize(backlight_data) >=
> (sizeof(backlight_data->entry_size) +
> + sizeof(backlight_data->data) +
> + sizeof(backlight_data->level))) {
> const struct lfp_backlight_control_method *method;
>
> method = &backlight_data->backlight_control[panel_type];
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..fff456bf8783 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +/*
> + * Changing struct bdb_lfp_backlight_data might affect its
> + * size comparation to the value hold in BDB.
> + * (e.g. in parse_lfp_backlight())
> + */
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 4/9] vfio/ccw: Make the FSM complete and synchronize it to the mdev
On Mon, Sep 20, 2021 at 02:19:18PM +0200, Cornelia Huck wrote: > On Thu, Sep 09 2021, Jason Gunthorpe wrote: > > > The subchannel should be left in a quiescent state unless the VFIO device > > FD is opened. When the FD is opened bring the chanel to active and allow > > the VFIO device to operate. When the device FD is closed then quiesce the > > channel. > > > > To make this work the FSM needs to handle the transitions to/from open and > > closed so everything is sequenced. Rename state NOT_OPER to BROKEN and use > > it wheneven the driver has malfunctioned. STANDBY becomes CLOSED. The > > normal case FSM looks like: > > CLOSED -> IDLE -> PROCESS/PENDING* -> IDLE -> CLOSED > > > > With a possible branch off to BROKEN from any state. Once the device is in > > BROKEN it cannot be recovered other than be reloading the driver. > > Hm, not sure whether it is a good idea to conflate "something went > wrong" and "device is not operational". Yes, but that is exactly what this FSM is currently doing, NO_OPER is a dumping ground for all kinds of wonky stuff, and what exactly it is supposed to mean or do is unclear. > while the former case could mean all kind of > things, but the subchannel will likely stay around. I think NOT_OPER > was always meant to be a transitional state. Then these sorts of failures should recover the device and FSM back to an appropriate operational state and keep going - but I'm not going to attempt to guess when each of the conditions are recoverable or not. > > Delete the triply redundant calls to > > vfio_ccw_sch_quiesce(). vfio_ccw_mdev_close_device() always leaves the > > subchannel quiescent. vfio_ccw_mdev_remove() cannot return until > > vfio_ccw_mdev_close_device() completes and vfio_ccw_sch_remove() cannot > > return until vfio_ccw_mdev_remove() completes. Have the FSM code take care > > of calling cp_free() when appropriate. > > I remember some serialization issues wrt cp_free() etc. coming up every > now and than; that might need extra care (I'm taking a look.) I'm not too surprised, things like NOT_OPER just exiting the usual FSM logic mean stuff couldn't be properly sequenced. The new logic puts a cp_free in each of arcs entering the terminal states broken/closed and all the flows that would get us to vfio_ccw_mdev_remove() will enter one of those states. It is quite possible this patch needs someone who actually understand this HW to polish it up - the point was to show how ccw should be cleanly structured. I'd like to go ahead with the other patches and leave this for the ccw maintainers if it is needs significant work. The other patches are what are blocking the core code cleanups. Jason
Re: [Intel-gfx] [PATCH v10 09/17] drm/i915/pxp: Implement PXP irq handler
On Mon, 2021-09-20 at 12:04 -0400, Rodrigo Vivi wrote:
> On Fri, Sep 17, 2021 at 09:20:00PM -0700, Alan Previn wrote:
> > From: "Huang, Sean Z"
> >
> > The HW will generate a teardown interrupt when session termination is
> > required, which requires i915 to submit a terminating batch. Once the HW
> > is done with the termination it will generate another interrupt, at
> > which point it is safe to re-create the session.
> >
> > Since the termination and re-creation flow is something we want to
> > trigger from the driver as well, use a common work function that can be
> > called both from the irq handler and from the driver set-up flows, which
> > has the addded benefit of allowing us to skip any extra locks because
> > the work itself serializes the operations.
> >
> > v2: use struct completion instead of bool (Chris)
> > v3: drop locks, clean up functions and improve comments (Chris),
> > move to common work function.
> > v4: improve comments, simplify wait logic (Rodrigo)
> > v5: unconditionally set interrupts, rename state_attacked var (Rodrigo)
> >
> > Signed-off-by: Alan Previn
> > Signed-off-by: Huang, Sean Z
> > Signed-off-by: Daniele Ceraolo Spurio
> > Cc: Chris Wilson
> > Cc: Rodrigo Vivi
> > Reviewed-by: Rodrigo Vivi
> > ---
> > +#include
> > +#include "intel_pxp.h"
> > +#include "intel_pxp_irq.h"
> > +#include "intel_pxp_session.h"
> > +#include "gt/intel_gt_irq.h"
> > +#include "gt/intel_gt_types.h"
> > +#include "i915_irq.h"
> > +#include "i915_reg.h"
> > +
> > +/**
> > + * intel_pxp_irq_handler - Handles PXP interrupts.
> > + * @pxp: pointer to pxp struct
> > + * @iir: interrupt vector
> > + */
> > +void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
> > +{
> > + struct intel_gt *gt = pxp_to_gt(pxp);
>
> this compiles, but I don't see how this can work.
>
> shouldn't we use the container_of here directly instead of trying
> to use something that is not properly defined?
>
Its now a function that's abstracted in .c file and prototype defined in the
intel_pxp.h. Unless i
misunderstood something, i thought this was one of the options discussed in
last rev - i can change it
again to use the container_of directly in all the instances if you like. side
note: inline was still
defined but only for the CONFIG_PXP==off case that doesn't require the
additional header inclusions.
> > +
Re: [Intel-gfx] [PATCH v10 10/17] drm/i915/pxp: interfaces for using protected objects
On Mon, 2021-09-20 at 12:09 -0400, Rodrigo Vivi wrote:
> On Fri, Sep 17, 2021 at 09:20:01PM -0700, Alan Previn wrote:
> > From: Daniele Ceraolo Spurio
> >
> > This api allow user mode to create protected buffers and to mark
> > contexts as making use of such objects. Only when using contexts
> > marked in such a way is the execution guaranteed to work as expected.
> >
> > Contexts can only be marked as using protected content at creation time
> > (i.e. the parameter is immutable) and they must be both bannable and not
> > recoverable. Given that the protected session gets invalidated on
> > suspend, contexts created this way hold a runtime pm wakeref until
> > they're either destroyed or invalidated.
> >
> > All protected objects and contexts will be considered invalid when the
> > PXP session is destroyed and all new submissions using them will be
> > rejected. All intel contexts within the invalidated gem contexts will be
> > marked banned. Userspace can detect that an invalidation has occurred via
> > the RESET_STATS ioctl, where we report it the same way as a ban due to a
> > hang.
> >
> > v5: squash patches, rebase on proto_ctx, update kerneldoc
> >
> > v6: rebase on obj create_ext changes
> >
> > v7: Use session counter to check if an object it valid, hold wakeref in
> > context, don't add a new flag to RESET_STATS (Daniel)
> >
> > v8: don't increase guilty count for contexts banned during pxp
> > invalidation (Rodrigo)
> >
> > v9: better comments, avoid wakeref put race between pxp_inval and
> > context_close, add usage examples (Rodrigo)
>
> can you please add the v10 change explanation here instead of only
> in the cover letter? (apply this comment to all the modified patches)
Okay - will respin.
>
> > Signed-off-by: Alan Previn
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-by: Bommu Krishnaiah
> > Cc: Rodrigo Vivi
> > Cc: Chris Wilson
> > Cc: Lionel Landwerlin
> > Cc: Jason Ekstrand
> > Cc: Daniel Vetter
> > Reviewed-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 95 +++---
> > drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 ++
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++
> > drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 ++
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18
> > drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
> > drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 ++
> > .../gpu/drm/i915/gem/i915_gem_object_types.h | 8 ++
> > .../gpu/drm/i915/gem/selftests/mock_context.c | 4 +-
> > drivers/gpu/drm/i915/pxp/intel_pxp.c | 78 +++
> > drivers/gpu/drm/i915/pxp/intel_pxp.h | 12 +++
> > drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 ++
> > drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 9 ++
> > include/uapi/drm/i915_drm.h | 96 ++-
> > 14 files changed, 404 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index c2ab0e22db0a..4ef643e20849 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -77,6 +77,8 @@
> > #include "gt/intel_gpu_commands.h"
> > #include "gt/intel_ring.h"
> >
> > +#include "pxp/intel_pxp.h"
> > +
> > #include "i915_gem_context.h"
> > #include "i915_trace.h"
> > #include "i915_user_extensions.h"
> > @@ -186,10 +188,13 @@ static int validate_priority(struct drm_i915_private
> > *i915,
> > return 0;
> > }
> >
> > -static void proto_context_close(struct i915_gem_proto_context *pc)
> > +static void proto_context_close(struct drm_i915_private *i915,
> > + struct i915_gem_proto_context *pc)
> > {
> > int i;
> >
> > + if (pc->pxp_wakeref)
> > + intel_runtime_pm_put(&i915->runtime_pm, pc->pxp_wakeref);
> > if (pc->vm)
> > i915_vm_put(pc->vm);
> > if (pc->user_engines) {
> > @@ -241,6 +246,33 @@ static int proto_context_set_persistence(struct
> > drm_i915_private *i915,
> > return 0;
> > }
> >
> > +static int proto_context_set_protected(struct drm_i915_private *i915,
> > + struct i915_gem_proto_context *pc,
> > + bool protected)
> > +{
> > + int ret = 0;
> > +
> > + if (!protected) {
> > + pc->uses_protected_content = false;
>
> v10:
>
> Reviewed-by: Rodrigo Vivi
>
> > + } else if (!intel_pxp_is_enabled(&i915->gt.pxp)) {
> > + ret = -ENODEV;
> > + } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
> > + !(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
> > + ret = -EPERM;
> > + } else {
> > + pc->uses_protected_content = true;
> > +
> > + /*
> > +* protected context usage requires the PXP session to be up,
> > +* which in turn requires
Re: [Intel-gfx] [PATCH v10 10/17] drm/i915/pxp: interfaces for using protected objects
On Fri, Sep 17, 2021 at 09:20:01PM -0700, Alan Previn wrote:
> From: Daniele Ceraolo Spurio
>
> This api allow user mode to create protected buffers and to mark
> contexts as making use of such objects. Only when using contexts
> marked in such a way is the execution guaranteed to work as expected.
>
> Contexts can only be marked as using protected content at creation time
> (i.e. the parameter is immutable) and they must be both bannable and not
> recoverable. Given that the protected session gets invalidated on
> suspend, contexts created this way hold a runtime pm wakeref until
> they're either destroyed or invalidated.
>
> All protected objects and contexts will be considered invalid when the
> PXP session is destroyed and all new submissions using them will be
> rejected. All intel contexts within the invalidated gem contexts will be
> marked banned. Userspace can detect that an invalidation has occurred via
> the RESET_STATS ioctl, where we report it the same way as a ban due to a
> hang.
>
> v5: squash patches, rebase on proto_ctx, update kerneldoc
>
> v6: rebase on obj create_ext changes
>
> v7: Use session counter to check if an object it valid, hold wakeref in
> context, don't add a new flag to RESET_STATS (Daniel)
>
> v8: don't increase guilty count for contexts banned during pxp
> invalidation (Rodrigo)
>
> v9: better comments, avoid wakeref put race between pxp_inval and
> context_close, add usage examples (Rodrigo)
can you please add the v10 change explanation here instead of only
in the cover letter? (apply this comment to all the modified patches)
>
> Signed-off-by: Alan Previn
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Bommu Krishnaiah
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Cc: Lionel Landwerlin
> Cc: Jason Ekstrand
> Cc: Daniel Vetter
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 95 +++---
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 ++
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 28 ++
> drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 ++
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 ++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 8 ++
> .../gpu/drm/i915/gem/selftests/mock_context.c | 4 +-
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 78 +++
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 12 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 9 ++
> include/uapi/drm/i915_drm.h | 96 ++-
> 14 files changed, 404 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index c2ab0e22db0a..4ef643e20849 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -77,6 +77,8 @@
> #include "gt/intel_gpu_commands.h"
> #include "gt/intel_ring.h"
>
> +#include "pxp/intel_pxp.h"
> +
> #include "i915_gem_context.h"
> #include "i915_trace.h"
> #include "i915_user_extensions.h"
> @@ -186,10 +188,13 @@ static int validate_priority(struct drm_i915_private
> *i915,
> return 0;
> }
>
> -static void proto_context_close(struct i915_gem_proto_context *pc)
> +static void proto_context_close(struct drm_i915_private *i915,
> + struct i915_gem_proto_context *pc)
> {
> int i;
>
> + if (pc->pxp_wakeref)
> + intel_runtime_pm_put(&i915->runtime_pm, pc->pxp_wakeref);
> if (pc->vm)
> i915_vm_put(pc->vm);
> if (pc->user_engines) {
> @@ -241,6 +246,33 @@ static int proto_context_set_persistence(struct
> drm_i915_private *i915,
> return 0;
> }
>
> +static int proto_context_set_protected(struct drm_i915_private *i915,
> +struct i915_gem_proto_context *pc,
> +bool protected)
> +{
> + int ret = 0;
> +
> + if (!protected) {
> + pc->uses_protected_content = false;
v10:
Reviewed-by: Rodrigo Vivi
> + } else if (!intel_pxp_is_enabled(&i915->gt.pxp)) {
> + ret = -ENODEV;
> + } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
> +!(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
> + ret = -EPERM;
> + } else {
> + pc->uses_protected_content = true;
> +
> + /*
> + * protected context usage requires the PXP session to be up,
> + * which in turn requires the device to be active.
> + */
> + pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> + ret = intel_pxp_wait_for_arb_start(&i915->gt.pxp);
> + }
> +
> + return ret;
> +}
> +
> static struct i915_gem_proto_context
Re: [Intel-gfx] [PATCH v10 09/17] drm/i915/pxp: Implement PXP irq handler
On Fri, Sep 17, 2021 at 09:20:00PM -0700, Alan Previn wrote:
> From: "Huang, Sean Z"
>
> The HW will generate a teardown interrupt when session termination is
> required, which requires i915 to submit a terminating batch. Once the HW
> is done with the termination it will generate another interrupt, at
> which point it is safe to re-create the session.
>
> Since the termination and re-creation flow is something we want to
> trigger from the driver as well, use a common work function that can be
> called both from the irq handler and from the driver set-up flows, which
> has the addded benefit of allowing us to skip any extra locks because
> the work itself serializes the operations.
>
> v2: use struct completion instead of bool (Chris)
> v3: drop locks, clean up functions and improve comments (Chris),
> move to common work function.
> v4: improve comments, simplify wait logic (Rodrigo)
> v5: unconditionally set interrupts, rename state_attacked var (Rodrigo)
>
> Signed-off-by: Alan Previn
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/gt/intel_gt_irq.c | 7 ++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 66 ++--
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 8 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 100 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 32 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 54 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 8 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 18
> 11 files changed, 284 insertions(+), 16 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 86ea9c98e815..892e17549314 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -284,6 +284,7 @@ i915-y += i915_perf.o
> i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_cmd.o \
> + pxp/intel_pxp_irq.o \
> pxp/intel_pxp_session.o \
> pxp/intel_pxp_tee.o
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index b2de83be4d97..699a74582d32 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -13,6 +13,7 @@
> #include "intel_lrc_reg.h"
> #include "intel_uncore.h"
> #include "intel_rps.h"
> +#include "pxp/intel_pxp_irq.h"
>
> static void guc_irq_handler(struct intel_guc *guc, u16 iir)
> {
> @@ -64,6 +65,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
> instance,
> if (instance == OTHER_GTPM_INSTANCE)
> return gen11_rps_irq_handler(>->rps, iir);
>
> + if (instance == OTHER_KCR_INSTANCE)
> + return intel_pxp_irq_handler(>->pxp, iir);
> +
> WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
> instance, iir);
> }
> @@ -196,6 +200,9 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK, ~0);
> +
> + intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_ENABLE, 0);
> + intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_MASK, ~0);
> }
>
> void gen11_gt_irq_postinstall(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c2853cc005ee..84bc884bd474 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8117,6 +8117,7 @@ enum {
> /* irq instances for OTHER_CLASS */
> #define OTHER_GUC_INSTANCE 0
> #define OTHER_GTPM_INSTANCE 1
> +#define OTHER_KCR_INSTANCE 4
>
> #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 8a4755b235ad..584c998f79be 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -2,7 +2,9 @@
> /*
> * Copyright(c) 2020 Intel Corporation.
> */
> +#include
> #include "intel_pxp.h"
> +#include "intel_pxp_irq.h"
> #include "intel_pxp_session.h"
> #include "intel_pxp_tee.h"
> #include "gt/intel_context.h"
> @@ -78,6 +80,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
>
> mutex_init(&pxp->tee_mutex);
>
> + /*
> + * we'll use the completion to check if there is a termination pending,
> + * so we start it as completed and we reinit it when a termination
> + * is triggered.
> +
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Add "intel_" as prefix in set_mocs_index() (rev3)
Re-reported. -Original Message- From: Roper, Matthew D Sent: Monday, September 20, 2021 8:26 AM To: intel-gfx@lists.freedesktop.org Cc: Siddiqui, Ayaz A ; Vudum, Lakshminarayana ; Kijanczuk, Damian Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Add "intel_" as prefix in set_mocs_index() (rev3) On Fri, Sep 17, 2021 at 11:42:09PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gt: Add "intel_" as prefix in set_mocs_index() (rev3) > URL : https://patchwork.freedesktop.org/series/94721/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10605_full -> Patchwork_21088_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_21088_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_21088_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_21088_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs: > - shard-iclb: NOTRUN -> [INCOMPLETE][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-iclb7/i > gt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs.html As seen on other CI series, a bunch of snd_hda_intel "spurious response" errors, followed by <0>[ 228.961637] NMI watchdog: Watchdog detected hard LOCKUP on cpu 4 with CPU cores stuck in azx_interrupt. > > * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile: > - shard-iclb: [PASS][2] -> [SKIP][3] >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-iclb7/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-iclb2/i > gt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html https://gitlab.freedesktop.org/drm/intel/-/issues/3701 except it's on a "ytileccs" subtest instead of just "ytile" > > * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt: > - shard-tglb: [PASS][4] -> [INCOMPLETE][5] >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-blt.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb8/i > gt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-blt.html > No clear error seen here. But renaming a function causes no functional change, so definitely not caused by this patch. Applied to drm-intel-gt-next. Thanks for the patch. Matt > > Known issues > > > Here are the changes found in Patchwork_21088_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_sseu@engines: > - shard-skl: NOTRUN -> [SKIP][6] ([fdo#109271]) +8 similar issues >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-skl9/ig > t@gem_ctx_s...@engines.html > > * igt@gem_exec_fair@basic-flow@rcs0: > - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar > issue >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb6/i > gt@gem_exec_fair@basic-f...@rcs0.html > > * igt@gem_exec_fair@basic-pace@rcs0: > - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-kbl6/ig > t@gem_exec_fair@basic-p...@rcs0.html > > * igt@gem_exec_fair@basic-pace@vcs0: > - shard-kbl: [PASS][11] -> [SKIP][12] ([fdo#109271]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-kbl6/ig > t@gem_exec_fair@basic-p...@vcs0.html > > * igt@gem_exec_fair@basic-pace@vcs1: > - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-iclb4/i > gt@gem_exec_fair@basic-p...@vcs1.html > > * igt@gem_exec_params@rsvd2-dirt: > - shard-tglb: NOTRUN -> [SKIP][14] ([fdo#109283]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb5/i > gt@gem_exec_par...@rsvd2-dirt.html > > * igt@gem_exec_suspend@basic-s0: > - shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#456]
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Make wa list per-gt (rev2)
Reported. -Original Message- From: Roper, Matthew D Sent: Monday, September 20, 2021 7:53 AM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana ; Kijanczuk, Damian Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Make wa list per-gt (rev2) On Sat, Sep 18, 2021 at 01:46:39AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Make wa list per-gt (rev2) > URL : https://patchwork.freedesktop.org/series/94811/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10605_full -> Patchwork_21091_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_21091_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_21091_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_21091_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_atomic@plane-invalid-params: > - shard-iclb: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-iclb6/igt@kms_ato...@plane-invalid-params.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-iclb2/i > gt@kms_ato...@plane-invalid-params.html https://gitlab.freedesktop.org/drm/intel/-/issues/3728 > > * igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs: > - shard-kbl: NOTRUN -> [INCOMPLETE][3] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-kbl2/ig > t@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs.html <0>[ 148.225355] NMI watchdog: Watchdog detected hard LOCKUP on cpu 2 with some CPU(s) stuck in snd_hda_codec's azx_interrupt(). We've seen this signature on other CI failures recently too; it seems to be something introduced by the 5.15-rc1 backmerge, although I'm not sure if there's a gitlab issue open for it yet. > > * igt@kms_sequence@queue-idle: > - shard-skl: [PASS][4] -> [FAIL][5] >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-skl8/igt@kms_seque...@queue-idle.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl3/ig > t@kms_seque...@queue-idle.html Looks like https://gitlab.freedesktop.org/drm/intel/-/issues/2441 was just closed because it couldn't be reproduced, but it seems to still be happening. Matt > > > Known issues > > > Here are the changes found in Patchwork_21091_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@drm_import_export@flink: > - shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([i915#750]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb7/igt@drm_import_exp...@flink.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb2/i > gt@drm_import_exp...@flink.html > > * igt@gem_ctx_isolation@preservation-s3@vcs0: > - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([i915#146] / > [i915#198]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-skl6/igt@gem_ctx_isolation@preservation...@vcs0.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl4/ig > t@gem_ctx_isolation@preservation...@vcs0.html > > * igt@gem_ctx_sseu@engines: > - shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271]) +9 similar > issues >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl10/i > gt@gem_ctx_s...@engines.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb5/i > gt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_params@rsvd2-dirt: > - shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109283]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/i > gt@gem_exec_par...@rsvd2-dirt.html > > * igt@gem_media_vme: > - shard-tglb: NOTRUN -> [SKIP][14] ([i915#284]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/i > gt@gem_media_vme.html > > * igt@gem_pread@exhaustion: > - shard-skl: NOTRUN -> [WARN][15] ([i915#2658]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl8/ig > t@gem_pr...@exhaustion.html > > * igt@gen9_exec_parse@valid-registers: > - shard-tglb: NOTRUN -> [SKIP][16] ([i915#2856]) >[16]: > htt
[Intel-gfx] [PATCH v4 6/6] drm/i915: Reduce the number of objects subject to memcpy recover
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.
Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.
Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.
Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.
v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless, since
they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 5 +++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +++-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +++--
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 4 ++--
17 files changed, 49 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
if (args->flags)
return -EINVAL;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
#define I915_BO_ALLOC_USERBIT(3)
/* Object is allowed to lose its contents on suspend / resume, even if pinned
*/
#define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
I915_BO_ALLOC_CPU_CLEAR | \
I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
/**
* @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 12b37b4c1192..726b40e1fbb0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -97,8 +97,12 @@ int i915_gem_backup_suspend(struct drm_i915_private *i915)
* More objects may have become unpinned as requests were
* retired. Now try to evict again. The gt may be wedged here
* in which ca
[Intel-gfx] [PATCH v4 5/6] drm/i915: Don't back up pinned LMEM context images and rings during suspend
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.
Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to lose its content on suspend.
v3:
- Slight documentation clarification (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_object_types.h| 17 ++---
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_ring.c| 3 ++-
4 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 734cc8e16481..118691ce81d7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -288,16 +288,19 @@ struct drm_i915_gem_object {
I915_SELFTEST_DECLARE(struct list_head st_link);
unsigned long flags;
-#define I915_BO_ALLOC_CONTIGUOUS BIT(0)
-#define I915_BO_ALLOC_VOLATILE BIT(1)
-#define I915_BO_ALLOC_CPU_CLEAR BIT(2)
-#define I915_BO_ALLOC_USER BIT(3)
+#define I915_BO_ALLOC_CONTIGUOUS BIT(0)
+#define I915_BO_ALLOC_VOLATILEBIT(1)
+#define I915_BO_ALLOC_CPU_CLEAR BIT(2)
+#define I915_BO_ALLOC_USERBIT(3)
+/* Object is allowed to lose its contents on suspend / resume, even if pinned
*/
+#define I915_BO_ALLOC_PM_VOLATILE BIT(4)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
I915_BO_ALLOC_CPU_CLEAR | \
-I915_BO_ALLOC_USER)
-#define I915_BO_READONLY BIT(4)
-#define I915_TILING_QUIRK_BIT5 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_USER | \
+I915_BO_ALLOC_PM_VOLATILE)
+#define I915_BO_READONLY BIT(5)
+#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
/**
* @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index cb1c46724f70..03a00d193f40 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -60,6 +60,9 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region
*apply,
if (!pm_apply->backup_pinned)
return 0;
+ if (obj->flags & I915_BO_ALLOC_PM_VOLATILE)
+ return 0;
+
backup = i915_gem_object_create_shmem(i915, obj->base.size);
if (IS_ERR(backup))
return PTR_ERR(backup);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 6ba8daea2f56..3ef9eaf8c50e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -942,7 +942,8 @@ __lrc_alloc_state(struct intel_context *ce, struct
intel_engine_cs *engine)
context_size += PAGE_SIZE;
}
- obj = i915_gem_object_create_lmem(engine->i915, context_size, 0);
+ obj = i915_gem_object_create_lmem(engine->i915, context_size,
+ I915_BO_ALLOC_PM_VOLATILE);
if (IS_ERR(obj))
obj = i915_gem_object_create_shmem(engine->i915, context_size);
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index 7c4d5158e03b..2fdd52b62092 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -112,7 +112,8 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt
*ggtt, int size)
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE);
+ obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
+ I915_BO_ALLOC_PM_VOLATILE);
if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
--
2.31.1
[Intel-gfx] [PATCH v4 4/6] drm/i915/gt: Register the migrate contexts with their engines
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.
Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and traverse that list at resume time to reset the pinned
contexts.
This fixes the kms_pipe_crc_basic@suspend-read-crc-pipe-a selftest for now,
but proper LMEM backup / restore is needed for full suspend functionality.
However, note that even with full LMEM backup / restore it may be
desirable to keep the reset since backing up the migrate context images
must happen using memcpy() after the migrate context has become inactive,
and for performance- and other reasons we want to avoid memcpy() from
LMEM.
Also traverse the list at guc_init_lrc_mapping() calling
guc_kernel_context_pin() for the pinned contexts, like is already done
for the kernel context.
v2:
- Don't reset the contexts on each __engine_unpark() but rather at
resume time (Chris Wilson).
v3:
- Reset contexts in the engine sanitize callback. (Chris Wilson)
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Maarten Lankhorst
Cc: Brost Matthew
Cc: Chris Wilson
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 8 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 23 +++
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 ++
.../drm/i915/gt/intel_execlists_submission.c | 2 ++
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +++
drivers/gpu/drm/i915/gt/mock_engine.c | 2 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +++---
9 files changed, 60 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 930569a1a01f..12252c411159 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -153,6 +153,14 @@ struct intel_context {
/** sseu: Control eu/slice partitioning */
struct intel_sseu sseu;
+ /**
+* pinned_contexts_link: List link for the engine's pinned contexts.
+* This is only used if this is a perma-pinned kernel context and
+* the list is assumed to only be manipulated during driver load
+* or unload time so no mutex protection currently.
+*/
+ struct list_head pinned_contexts_link;
+
u8 wa_bb_page; /* if set, page num reserved for context workarounds */
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 332efea696a5..c606a4714904 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -320,6 +320,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
BUILD_BUG_ON(BITS_PER_TYPE(engine->mask) < I915_NUM_ENGINES);
+ INIT_LIST_HEAD(&engine->pinned_contexts_list);
engine->id = id;
engine->legacy_idx = INVALID_ENGINE;
engine->mask = BIT(id);
@@ -875,6 +876,8 @@ intel_engine_create_pinned_context(struct intel_engine_cs
*engine,
return ERR_PTR(err);
}
+ list_add_tail(&ce->pinned_contexts_link, &engine->pinned_contexts_list);
+
/*
* Give our perma-pinned kernel timelines a separate lockdep class,
* so that we can use them from within the normal user timelines
@@ -897,6 +900,7 @@ void intel_engine_destroy_pinned_context(struct
intel_context *ce)
list_del(&ce->timeline->engine_link);
mutex_unlock(&hwsp->vm->mutex);
+ list_del(&ce->pinned_contexts_link);
intel_context_unpin(ce);
intel_context_put(ce);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 1f07ac4e0672..dacd62773735 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -298,6 +298,29 @@ void intel_engine_init__pm(struct intel_engine_cs *engine)
intel_engine_init_heartbeat(engine);
}
+/**
+ * intel_engine_reset_pinned_contexts - Reset the pinned contexts of
+ * an engine.
+ * @engine: The engine whose pinned contexts we want to reset.
+ *
+ * Typically the pinned context LMEM images lose or get their content
+ * corrupted on suspend. This function resets their images.
+ */
+void intel_engine_reset_pinned_contexts(struct intel_engine_cs *engine)
+{
+ struct intel_context *ce;
+
+ list_for_each_entry(ce, &engine->pinned_contexts_list,
+ pinned_contexts_link) {
+ /* kernel context gets reset at __engine_unpark() */
+ if (ce == engine->kernel_context)
+ continue;
+
+ dbg_poison_ce(ce);
+ ce->ops->rese
[Intel-gfx] [PATCH v4 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict evictable objects using the gpu blitter. This will
be modified in an upcoming patch to backup pinned objects that are not used
by the blitter itself.
3: Backup remaining pinned objects using memcpy.
Also move uC suspend to after 2) to make sure we have a functional GuC
during 2) if using GuC submission.
v2:
- Major refactor to make sure gem_exec_suspend@hang-SX subtests work, and
suspend / resume works with a slightly modified GuC submission enabling
patch series.
v3:
- Fix a potential use-after-free (Matthew Auld)
- Use i915_gem_object_create_shmem() instead of
i915_gem_object_create_region (Matthew Auld)
- Minor simplifications (Matthew Auld)
- Fix up kerneldoc for i195_ttm_restore_region().
- Final lmem_suspend() call moved to i915_gem_backup_suspend from
i915_gem_suspend_late, since the latter gets called at driver unload
and we don't unnecessarily want to run it at that time.
v4:
- Interface change of ttm- & lmem suspend / resume functions to use
flags rather than bools. (Matthew Auld)
- Completely drop the i915_gem_backup_suspend change (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 87
drivers/gpu/drm/i915/gem/i915_gem_pm.h| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 30 ++-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 10 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c| 202 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h| 26 +++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 +-
drivers/gpu/drm/i915/i915_drv.c | 4 +-
10 files changed, 353 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 335a8c668848..5c8e022a7383 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -154,6 +154,7 @@ gem-y += \
gem/i915_gem_throttle.o \
gem/i915_gem_tiling.o \
gem/i915_gem_ttm.o \
+ gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 2471f36aaff3..734cc8e16481 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -534,6 +534,7 @@ struct drm_i915_gem_object {
struct {
struct sg_table *cached_io_st;
struct i915_gem_object_page_iter get_io_page;
+ struct drm_i915_gem_object *backup;
bool created:1;
} ttm;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 8b9d7d14c4bd..12b37b4c1192 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -5,6 +5,7 @@
*/
#include "gem/i915_gem_pm.h"
+#include "gem/i915_gem_ttm_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_gt_requests.h"
@@ -39,6 +40,84 @@ void i915_gem_suspend(struct drm_i915_private *i915)
i915_gem_drain_freed_objects(i915);
}
+static int lmem_restore(struct drm_i915_private *i915, u32 flags)
+{
+ struct intel_memory_region *mr;
+ int ret = 0, id;
+
+ for_each_memory_region(mr, i915, id) {
+ if (mr->type == INTEL_MEMORY_LOCAL) {
+ ret = i915_ttm_restore_region(mr, flags);
+ if (ret)
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static int lmem_suspend(struct drm_i915_private *i915, u32 flags)
+{
+ struct intel_memory_region *mr;
+ int ret = 0, id;
+
+ for_each_memory_region(mr, i915, id) {
+ if (mr->type == INTEL_MEMORY_LOCAL) {
+ ret = i915_ttm_backup_region(mr, flags);
+ if (ret)
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static void lmem_recover(struct drm_i915_private *i915)
+{
+ struct intel_memory_region *mr;
+ int id;
+
+ for_each_memory_region(mr, i915, id)
+ if (mr->type == INTEL_MEMORY_LOCAL)
+ i915_ttm_recover_region(mr);
+}
+
+int i915_gem_backup_suspend(struct drm_i915_private *i915)
+{
+ int ret;
+
+ /* Opportunistically try to evict unpinned objects */
+ ret = lmem_suspend(i915, I915_TTM_BACKUP_ALLOW_GPU
[Intel-gfx] [PATCH v4 2/6] drm/i915/gem: Implement a function to process all gem objects of a region
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the object lock is held.
Define a function that does this for us and that takes an argument that
defines the action to be performed on each object.
v3:
- Improve structure documentation a bit (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 70 ++
drivers/gpu/drm/i915/gem/i915_gem_region.h | 37
2 files changed, 107 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 1f557b2178ed..a016ccec36f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -80,3 +80,73 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
i915_gem_object_free(obj);
return ERR_PTR(err);
}
+
+/**
+ * i915_gem_process_region - Iterate over all objects of a region using ops
+ * to process and optionally skip objects
+ * @mr: The memory region
+ * @apply: ops and private data
+ *
+ * This function can be used to iterate over the regions object list,
+ * checking whether to skip objects, and, if not, lock the objects and
+ * process them using the supplied ops. Note that this function temporarily
+ * removes objects from the region list while iterating, so that if run
+ * concurrently with itself may not iterate over all objects.
+ *
+ * Return: 0 if successful, negative error code on failure.
+ */
+int i915_gem_process_region(struct intel_memory_region *mr,
+ struct i915_gem_apply_to_region *apply)
+{
+ const struct i915_gem_apply_to_region_ops *ops = apply->ops;
+ struct drm_i915_gem_object *obj;
+ struct list_head still_in_list;
+ int ret = 0;
+
+ /*
+* In the future, a non-NULL apply->ww could mean the caller is
+* already in a locking transaction and provides its own context.
+*/
+ GEM_WARN_ON(apply->ww);
+
+ INIT_LIST_HEAD(&still_in_list);
+ mutex_lock(&mr->objects.lock);
+ for (;;) {
+ struct i915_gem_ww_ctx ww;
+
+ obj = list_first_entry_or_null(&mr->objects.list, typeof(*obj),
+ mm.region_link);
+ if (!obj)
+ break;
+
+ list_move_tail(&obj->mm.region_link, &still_in_list);
+ if (!kref_get_unless_zero(&obj->base.refcount))
+ continue;
+
+ /*
+* Note: Someone else might be migrating the object at this
+* point. The object's region is not stable until we lock
+* the object.
+*/
+ mutex_unlock(&mr->objects.lock);
+ apply->ww = &ww;
+ for_i915_gem_ww(&ww, ret, apply->interruptible) {
+ ret = i915_gem_object_lock(obj, apply->ww);
+ if (ret)
+ continue;
+
+ if (obj->mm.region == mr)
+ ret = ops->process_obj(apply, obj);
+ /* Implicit object unlock */
+ }
+
+ i915_gem_object_put(obj);
+ mutex_lock(&mr->objects.lock);
+ if (ret)
+ break;
+ }
+ list_splice_tail(&still_in_list, &mr->objects.list);
+ mutex_unlock(&mr->objects.lock);
+
+ return ret;
+}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index 1008e580a89a..fcaa12d657d4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -12,6 +12,41 @@ struct intel_memory_region;
struct drm_i915_gem_object;
struct sg_table;
+struct i915_gem_apply_to_region;
+
+/**
+ * struct i915_gem_apply_to_region_ops - ops to use when iterating over all
+ * region objects.
+ */
+struct i915_gem_apply_to_region_ops {
+ /**
+* process_obj - Process the current object
+* @apply: Embed this for private data.
+* @obj: The current object.
+*
+* Note that if this function is part of a ww transaction, and
+* if returns -EDEADLK for one of the objects, it may be
+* rerun for that same object in the same pass.
+*/
+ int (*process_obj)(struct i915_gem_apply_to_region *apply,
+ struct drm_i915_gem_object *obj);
+};
+
+/**
+ * struct i915_gem_apply_to_region - Argument to the struct
+ * i915_gem_apply_to_region_ops functions.
+ * @ops: The ops for the operation.
+ * @ww: Locking context used for the transaction.
+ * @interruptible: Whether to perform object locking interruptible.
+ *
+ *
[Intel-gfx] [PATCH v4 1/6] drm/i915/ttm: Implement a function to copy the contents of two TTM-based objects
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for operation, so make sure we can
disable accelerated copies.
v2:
- Fix a missing return value check (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 4 ++
2 files changed, 64 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 2f672f06b169..22d59510d0c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -428,6 +428,7 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
bool clear,
struct ttm_resource *dst_mem,
+ struct ttm_tt *dst_ttm,
struct sg_table *dst_st)
{
struct drm_i915_private *i915 = container_of(bo->bdev, typeof(*i915),
@@ -437,14 +438,14 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
*bo,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct sg_table *src_st;
struct i915_request *rq;
- struct ttm_tt *ttm = bo->ttm;
+ struct ttm_tt *src_ttm = bo->ttm;
enum i915_cache_level src_level, dst_level;
int ret;
if (!i915->gt.migrate.context)
return -EINVAL;
- dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
+ dst_level = i915_ttm_cache_level(i915, dst_mem, dst_ttm);
if (clear) {
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
@@ -461,10 +462,10 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
*bo,
}
intel_engine_pm_put(i915->gt.migrate.context->engine);
} else {
- src_st = src_man->use_tt ? i915_ttm_tt_get_st(ttm) :
+ src_st = src_man->use_tt ? i915_ttm_tt_get_st(src_ttm) :
obj->ttm.cached_io_st;
- src_level = i915_ttm_cache_level(i915, bo->resource, ttm);
+ src_level = i915_ttm_cache_level(i915, bo->resource, src_ttm);
intel_engine_pm_get(i915->gt.migrate.context->engine);
ret = intel_context_migrate_copy(i915->gt.migrate.context,
NULL, src_st->sgl, src_level,
@@ -484,11 +485,14 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
*bo,
static void __i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
struct ttm_resource *dst_mem,
- struct sg_table *dst_st)
+ struct ttm_tt *dst_ttm,
+ struct sg_table *dst_st,
+ bool allow_accel)
{
- int ret;
+ int ret = -EINVAL;
- ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_st);
+ if (allow_accel)
+ ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_ttm, dst_st);
if (ret) {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct intel_memory_region *dst_reg, *src_reg;
@@ -503,7 +507,7 @@ static void __i915_ttm_move(struct ttm_buffer_object *bo,
bool clear,
GEM_BUG_ON(!dst_reg || !src_reg);
dst_iter = !cpu_maps_iomem(dst_mem) ?
- ttm_kmap_iter_tt_init(&_dst_iter.tt, bo->ttm) :
+ ttm_kmap_iter_tt_init(&_dst_iter.tt, dst_ttm) :
ttm_kmap_iter_iomap_init(&_dst_iter.io, &dst_reg->iomap,
dst_st, dst_reg->region.start);
@@ -558,7 +562,7 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool
evict,
clear = !cpu_maps_iomem(bo->resource) && (!ttm ||
!ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
- __i915_ttm_move(bo, clear, dst_mem, dst_st);
+ __i915_ttm_move(bo, clear, dst_mem, bo->ttm, dst_st, true);
ttm_bo_move_sync_cleanup(bo, dst_mem);
i915_ttm_adjust_domains_after_move(obj);
@@ -973,3 +977,50 @@ i915_gem_ttm_system_setup(struct drm_i915_private *i915,
intel_memory_region_set_name(mr, "system-ttm");
return mr;
}
+
+/**
+ * i915_gem_obj_copy_ttm - Copy the contents of one ttm-based gem object to
+ * another
+ * @dst: The destination object
+ * @src: The source object
+ * @allow_accel: Allow using the blitter. Otherwise TTM memcpy is used.
+ * @intr: Whether to perform waits interruptible:
+ *
+ * Note: The caller is responsible for assuring that the underlyin
[Intel-gfx] [PATCH v4 0/6] drm/i915: Suspend / resume backup- and restore of LMEM.
Implement backup and restore of LMEM during suspend / resume. What complicates things a bit is handling of pinned LMEM memory during suspend and the fact that we might be dealing with unmappable LMEM in the future, which makes us want to restrict the number of pinned objects that need memcpy resume. The first two patches are prereq patches implementing object content copy and a generic means of iterating through all objects in a region. The third patch adds the backup / recover / restore functions and the two last patches deal with restricting the number of objects we need to use memcpy for. v2: - Some polishing of patch 4/6, see patch commit message for details (Chris Wilson) - Rework of patch 3/6. v3: - Comment changes in patch 2/6 (Matthew Auld) - A number of changes to patch 3/6, see commit message. - Slightly reword comment in patch 5/6. (Matthew Auld). v4: - Various cleanups, among other things reworking the ttm / lmem backup- and resume interfaces somewhat. Thomas Hellström (6): drm/i915/ttm: Implement a function to copy the contents of two TTM-based objects drm/i915/gem: Implement a function to process all gem objects of a region drm/i915 Implement LMEM backup and restore for suspend / resume drm/i915/gt: Register the migrate contexts with their engines drm/i915: Don't back up pinned LMEM context images and rings during suspend drm/i915: Reduce the number of objects subject to memcpy recover drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 21 +- drivers/gpu/drm/i915/gem/i915_gem_pm.c| 91 drivers/gpu/drm/i915/gem/i915_gem_pm.h| 1 + drivers/gpu/drm/i915/gem/i915_gem_region.c| 70 ++ drivers/gpu/drm/i915/gem/i915_gem_region.h| 37 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 99 +++-- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 14 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c| 206 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h| 26 +++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 8 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 23 ++ drivers/gpu/drm/i915/gt/intel_engine_pm.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 + .../drm/i915/gt/intel_execlists_submission.c | 2 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +- drivers/gpu/drm/i915/gt/intel_gt.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 13 +- drivers/gpu/drm/i915/gt/intel_ring.c | 3 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 3 + drivers/gpu/drm/i915/gt/mock_engine.c | 2 + drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- 37 files changed, 644 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h -- 2.31.1
Re: [Intel-gfx] [PATCH] drm/i915: Make wa list per-gt
On Fri, Sep 17, 2021 at 10:08:45AM -0700, Matt Roper wrote:
> From: Venkata Sandeep Dhanalakota
>
> Support for multiple GT's within a single i915 device will be arriving
> soon. Since each GT may have its own fusing and require different
> workarounds, we need to make the GT workaround functions and multicast
> steering setup per-gt.
>
> Cc: Tvrtko Ursulin
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Venkata Sandeep Dhanalakota
> Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 143 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.h | 2 +-
> .../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 2 -
> drivers/gpu/drm/i915/i915_drv.h | 2 -
> drivers/gpu/drm/i915/i915_gem.c | 2 -
> 8 files changed, 81 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 55e87aff51d2..449ff6e83543 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -660,6 +660,8 @@ int intel_gt_init(struct intel_gt *gt)
> if (err)
> return err;
>
> + intel_gt_init_workarounds(gt);
> +
> /*
>* This is just a security blanket to placate dragons.
>* On some systems, we very sporadically observe that the first TLBs
> @@ -767,6 +769,7 @@ void intel_gt_driver_release(struct intel_gt *gt)
> if (vm) /* FIXME being called twice on error paths :( */
> i915_vm_put(vm);
>
> + intel_wa_list_free(>->wa_list);
> intel_gt_pm_fini(gt);
> intel_gt_fini_scratch(gt);
> intel_gt_fini_buffer_pool(gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index 6fdcde64c180..ce127cae9e49 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -72,6 +72,8 @@ struct intel_gt {
>
> struct intel_uc uc;
>
> + struct i915_wa_list wa_list;
> +
> struct intel_gt_timelines {
> spinlock_t lock; /* protects active_list */
> struct list_head active_list;
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index c314d4917b6b..1f0a54b383d9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -804,7 +804,7 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
> }
>
> static void
> -gen4_gt_workarounds_init(struct drm_i915_private *i915,
> +gen4_gt_workarounds_init(struct intel_gt *gt,
>struct i915_wa_list *wal)
> {
> /* WaDisable_RenderCache_OperationalFlush:gen4,ilk */
> @@ -812,29 +812,29 @@ gen4_gt_workarounds_init(struct drm_i915_private *i915,
> }
>
> static void
> -g4x_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +g4x_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> - gen4_gt_workarounds_init(i915, wal);
> + gen4_gt_workarounds_init(gt, wal);
>
> /* WaDisableRenderCachePipelinedFlush:g4x,ilk */
> wa_masked_en(wal, CACHE_MODE_0, CM0_PIPELINED_RENDER_FLUSH_DISABLE);
> }
>
> static void
> -ilk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +ilk_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> - g4x_gt_workarounds_init(i915, wal);
> + g4x_gt_workarounds_init(gt, wal);
>
> wa_masked_en(wal, _3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED);
> }
>
> static void
> -snb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +snb_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> }
>
> static void
> -ivb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +ivb_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> /* Apply the WaDisableRHWOOptimizationForRenderHang:ivb workaround. */
> wa_masked_dis(wal,
> @@ -850,7 +850,7 @@ ivb_gt_workarounds_init(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> }
>
> static void
> -vlv_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +vlv_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> /* WaForceL3Serialization:vlv */
> wa_write_clr(wal, GEN7_L3SQCREG4, L3SQ_URB_READ_CAM_MATCH_DISABLE);
> @@ -863,7 +863,7 @@ vlv_gt_workarounds_init(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> }
>
> static void
> -hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +hsw_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Add "intel_" as prefix in set_mocs_index() (rev3)
== Series Details ==
Series: drm/i915/gt: Add "intel_" as prefix in set_mocs_index() (rev3)
URL : https://patchwork.freedesktop.org/series/94721/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10605_full -> Patchwork_21088_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_21088_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@gem-mmap-type@gtt:
- {shard-rkl}:[INCOMPLETE][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-rkl-6/igt@i915_pm_rpm@gem-mmap-t...@gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-rkl-6/igt@i915_pm_rpm@gem-mmap-t...@gtt.html
* igt@i915_pm_rpm@gem-mmap-type@uc:
- {shard-rkl}:NOTRUN -> [FAIL][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-rkl-6/igt@i915_pm_rpm@gem-mmap-t...@uc.html
* igt@runner@aborted:
- {shard-rkl}:([FAIL][4], [FAIL][5], [FAIL][6]) ([i915#3002] /
[i915#3811]) -> ([FAIL][7], [FAIL][8], [FAIL][9]) ([i915#2029] / [i915#3002] /
[i915#3811])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-rkl-2/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-rkl-2/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-rkl-6/igt@run...@aborted.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-rkl-2/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-rkl-1/igt@run...@aborted.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-rkl-6/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_21088_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_sseu@engines:
- shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271]) +8 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-skl9/igt@gem_ctx_s...@engines.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [PASS][15] -> [SKIP][16] ([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109283])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb5/igt@gem_exec_par...@rsvd2-dirt.html
* igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#456]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb2/igt@gem_exec_susp...@basic-s0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb7/igt@gem_exec_susp...@basic-s0.html
* igt@gem_huc_copy@huc-copy:
- shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-kbl6/igt@gem_huc_c...@huc-copy.html
* igt@gem_media_vme:
- shard-tglb: NOTRUN -> [SKIP][22] ([i915#284])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb5/igt@gem_media_vme.html
* igt@gem_pread@exhaustion:
- shard-skl: NOTRUN -> [WARN][23] ([i915#2658])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-skl3/igt@gem_pr...@exhaustion.html
* igt@gen9_exec_parse@valid-registers:
- shard-tglb: NOTRUN -> [SKIP][24] ([i915#2856])
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb5/igt@gen9_exec_pa...@valid-register
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Make wa list per-gt (rev2)
== Series Details ==
Series: drm/i915: Make wa list per-gt (rev2)
URL : https://patchwork.freedesktop.org/series/94811/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10605_full -> Patchwork_21091_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_21091_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {shard-rkl}:([FAIL][1], [FAIL][2], [FAIL][3]) ([i915#3002] /
[i915#3811]) -> ([FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7]) ([i915#3002] /
[i915#3728])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-rkl-6/igt@run...@aborted.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-rkl-2/igt@run...@aborted.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-rkl-2/igt@run...@aborted.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-rkl-1/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-rkl-2/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-rkl-6/igt@run...@aborted.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-rkl-6/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_21091_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_import_export@flink:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#750])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb7/igt@drm_import_exp...@flink.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb2/igt@drm_import_exp...@flink.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl: [PASS][10] -> [INCOMPLETE][11] ([i915#146] /
[i915#198])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-skl6/igt@gem_ctx_isolation@preservation...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl4/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_ctx_sseu@engines:
- shard-skl: NOTRUN -> [SKIP][12] ([fdo#109271]) +9 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl10/igt@gem_ctx_s...@engines.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109283])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@gem_exec_par...@rsvd2-dirt.html
* igt@gem_media_vme:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#284])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@gem_media_vme.html
* igt@gem_pread@exhaustion:
- shard-skl: NOTRUN -> [WARN][17] ([i915#2658])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl8/igt@gem_pr...@exhaustion.html
* igt@gen9_exec_parse@valid-registers:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#2856])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@gen9_exec_pa...@valid-registers.html
* igt@i915_pm_rpm@pc8-residency:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109506] / [i915#2411])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@i915_pm_...@pc8-residency.html
* igt@kms_atomic@plane-invalid-params:
- shard-iclb: [PASS][20] -> [DMESG-WARN][21] ([i915#3728])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-iclb6/igt@kms_ato...@plane-invalid-params.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-iclb2/igt@kms_ato...@plane-invalid-params.html
* igt@kms_big_fb@linear-8bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111614]) +1 similar issue
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@kms_big...@linear-8bpp-rotate-270.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-kbl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#3777])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-kbl7/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_big_fb@yf-tiled-addfb-size-offset-overflow:
- shard-tglb: NOTRUN -> [SKIP][24] ([fdo#111615]
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Add "intel_" as prefix in set_mocs_index() (rev3)
On Fri, Sep 17, 2021 at 11:42:09PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gt: Add "intel_" as prefix in set_mocs_index() (rev3) > URL : https://patchwork.freedesktop.org/series/94721/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10605_full -> Patchwork_21088_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_21088_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_21088_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_21088_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs: > - shard-iclb: NOTRUN -> [INCOMPLETE][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-iclb7/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs.html As seen on other CI series, a bunch of snd_hda_intel "spurious response" errors, followed by <0>[ 228.961637] NMI watchdog: Watchdog detected hard LOCKUP on cpu 4 with CPU cores stuck in azx_interrupt. > > * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile: > - shard-iclb: [PASS][2] -> [SKIP][3] >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-iclb7/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-iclb2/igt@kms_flip_scaled_...@flip-32bpp-ytileccs-to-64bpp-ytile.html https://gitlab.freedesktop.org/drm/intel/-/issues/3701 except it's on a "ytileccs" subtest instead of just "ytile" > > * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt: > - shard-tglb: [PASS][4] -> [INCOMPLETE][5] >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-blt.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-blt.html > No clear error seen here. But renaming a function causes no functional change, so definitely not caused by this patch. Applied to drm-intel-gt-next. Thanks for the patch. Matt > > Known issues > > > Here are the changes found in Patchwork_21088_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_sseu@engines: > - shard-skl: NOTRUN -> [SKIP][6] ([fdo#109271]) +8 similar issues >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-skl9/igt@gem_ctx_s...@engines.html > > * igt@gem_exec_fair@basic-flow@rcs0: > - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar > issue >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html > > * igt@gem_exec_fair@basic-pace@rcs0: > - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html > > * igt@gem_exec_fair@basic-pace@vcs0: > - shard-kbl: [PASS][11] -> [SKIP][12] ([fdo#109271]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html > > * igt@gem_exec_fair@basic-pace@vcs1: > - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html > > * igt@gem_exec_params@rsvd2-dirt: > - shard-tglb: NOTRUN -> [SKIP][14] ([fdo#109283]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb5/igt@gem_exec_par...@rsvd2-dirt.html > > * igt@gem_exec_suspend@basic-s0: > - shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#456]) +1 > similar issue >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb2/igt@gem_exec_susp...@basic-s0.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21088/shard-tglb7/igt@gem_exec_susp...@basic-s0.html > > * igt@gem_huc_copy@huc-copy: > - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] /
Re: [Intel-gfx] [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.
Quoting Peter Zijlstra (2021-09-17 16:13:19) > On Thu, Sep 16, 2021 at 03:28:11PM +0200, Peter Zijlstra wrote: > > On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote: > > > > > > For merge logistics, can we pls have a stable branch? I expect that the > > > > i915 patches will be ready for 5.16. > > > > > > > > Or send it in for -rc2 so that the interface change doesn't cause > > > > needless > > > > conflicts, whatever you think is best. > > > > > Yeah, some central branch drm could pull from, would make upstreaming > > > patches that depends on it easier. :) > > > > I think I'll make tip/locking/wwmutex and include that in > > tip/locking/core, let me have a poke. > > This is now so. Enjoy! This is now merged to drm-intel-gt-next. Regards, Joonas
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Make wa list per-gt (rev2)
On Sat, Sep 18, 2021 at 01:46:39AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Make wa list per-gt (rev2) > URL : https://patchwork.freedesktop.org/series/94811/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10605_full -> Patchwork_21091_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_21091_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_21091_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_21091_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_atomic@plane-invalid-params: > - shard-iclb: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-iclb6/igt@kms_ato...@plane-invalid-params.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-iclb2/igt@kms_ato...@plane-invalid-params.html https://gitlab.freedesktop.org/drm/intel/-/issues/3728 > > * igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs: > - shard-kbl: NOTRUN -> [INCOMPLETE][3] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-kbl2/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_mc_ccs.html <0>[ 148.225355] NMI watchdog: Watchdog detected hard LOCKUP on cpu 2 with some CPU(s) stuck in snd_hda_codec's azx_interrupt(). We've seen this signature on other CI failures recently too; it seems to be something introduced by the 5.15-rc1 backmerge, although I'm not sure if there's a gitlab issue open for it yet. > > * igt@kms_sequence@queue-idle: > - shard-skl: [PASS][4] -> [FAIL][5] >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-skl8/igt@kms_seque...@queue-idle.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl3/igt@kms_seque...@queue-idle.html Looks like https://gitlab.freedesktop.org/drm/intel/-/issues/2441 was just closed because it couldn't be reproduced, but it seems to still be happening. Matt > > > Known issues > > > Here are the changes found in Patchwork_21091_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@drm_import_export@flink: > - shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([i915#750]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb7/igt@drm_import_exp...@flink.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb2/igt@drm_import_exp...@flink.html > > * igt@gem_ctx_isolation@preservation-s3@vcs0: > - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([i915#146] / > [i915#198]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-skl6/igt@gem_ctx_isolation@preservation...@vcs0.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl4/igt@gem_ctx_isolation@preservation...@vcs0.html > > * igt@gem_ctx_sseu@engines: > - shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271]) +9 similar > issues >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl10/igt@gem_ctx_s...@engines.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10605/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_params@rsvd2-dirt: > - shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109283]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@gem_exec_par...@rsvd2-dirt.html > > * igt@gem_media_vme: > - shard-tglb: NOTRUN -> [SKIP][14] ([i915#284]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@gem_media_vme.html > > * igt@gem_pread@exhaustion: > - shard-skl: NOTRUN -> [WARN][15] ([i915#2658]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-skl8/igt@gem_pr...@exhaustion.html > > * igt@gen9_exec_parse@valid-registers: > - shard-tglb: NOTRUN -> [SKIP][16] ([i915#2856]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shard-tglb1/igt@gen9_exec_pa...@valid-registers.html > > * igt@i915_pm_rpm@pc8-residency: > - shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109506] / [i915#2411]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21091/shar
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid
== Series Details == Series: drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid URL : https://patchwork.freedesktop.org/series/94858/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10611 -> Patchwork_21098 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21098 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21098, 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_21098/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21098: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-bxt-dsi: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10611/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html * igt@i915_module_load@reload: - fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10611/fi-snb-2600/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-snb-2600/igt@i915_module_l...@reload.html Known issues Here are the changes found in Patchwork_21098 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-cfl-guc: NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-cfl-guc/igt@amdgpu/amd_ba...@cs-compute.html * igt@amdgpu/amd_basic@cs-gfx: - fi-skl-6700k2: NOTRUN -> [SKIP][6] ([fdo#109271]) +31 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html * igt@amdgpu/amd_basic@query-info: - fi-glk-dsi: NOTRUN -> [SKIP][7] ([fdo#109271]) +17 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-glk-dsi/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@semaphore: - fi-icl-y: NOTRUN -> [SKIP][8] ([fdo#109315]) +17 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html - fi-bdw-5557u: NOTRUN -> [SKIP][9] ([fdo#109271]) +27 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-ivb-3770:NOTRUN -> [SKIP][10] ([fdo#109271]) +18 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-ivb-3770/igt@amdgpu/amd_cs_...@fork-compute0.html * igt@amdgpu/amd_cs_nop@nop-compute0: - fi-ilk-650: NOTRUN -> [SKIP][11] ([fdo#109271]) +18 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109315]) +17 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-rkl-11600/igt@amdgpu/amd_cs_...@sync-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-rkl-guc: [PASS][13] -> [INCOMPLETE][14] ([i915#4130]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10611/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html - fi-cfl-8700k: [PASS][15] -> [INCOMPLETE][16] ([i915#4130]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10611/fi-cfl-8700k/igt@core_hotunp...@unbind-rebind.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-cfl-8700k/igt@core_hotunp...@unbind-rebind.html - fi-bdw-5557u: NOTRUN -> [WARN][17] ([i915#3718]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_huc_copy@huc-copy: - fi-skl-6700k2: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html * igt@i915_module_load@reload: - fi-cfl-8109u: [PASS][19] -> [INCOMPLETE][20] ([i915#4130]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10611/fi-cfl-8109u/igt@i915_module_l...@reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21098/fi-cfl-8109u/igt@i915_module_l...@reload.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][21] ([fdo#109271] /
[Intel-gfx] [PATCH] drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid
Nested grids in grid-table cells are not specified as proper ReST
constructs.
Commit 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0")
added a couple of kerneldoc tables of the form:
+---+---+--+
| 1 | 31:0 | ++ |
+---+---+ || |
|...| | | Embedded `HXG Message`_ | |
+---+---+ || |
| n | 31:0 | ++ |
+---+---+--+
For "make htmldocs", they happen to work as one might expect,
but they are incompatible with "make latexdocs" and "make pdfdocs",
and cause the generated gpu.tex file to become incomplete and
unbuildable by xelatex.
Restore the compatibility by removing those nested grids in the tables.
Size comparison of generated gpu.tex:
Sphinx 2.4.4 Sphinx 4.2.0
v5.14: 3238686 3841631
v5.15-rc1:376270432729
with this fix: 3377846 3998095
Fixes: 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0")
Cc: John Harrison
Cc: Michal Wajdeczko
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: Jonathan Corbet
Signed-off-by: Akira Yokosawa
---
Hi all,
I know there is little interest in building pdfdocs (or LaTeX) version
of kernel-doc, and this issue does not matter most of you.
But "make pdfdocs" is supposed to work, give or take those tables
with squeezed columns, and at least it is expected to complete
without fatal errors.
I have no idea who is responsible to those grid-tables, so added
a lot of people in the To: and Cc: lists.
Does removing those nested grids look reasonable to you?
Any feedback is welcome!
Note: This patch is against the docs-next branch of Jon's -doc tree
(git://git.lwn.net/linux.git). It can be applied against v5.15-rc1
and v5.15-rc2 as well.
Thanks, Akira
--
.../gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h | 10 +-
.../drm/i915/gt/uc/abi/guc_communication_mmio_abi.h| 10 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index 99e1fad5ca20..c9086a600bce 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -102,11 +102,11 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
* |
+---+--+
* | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message
|
*
+---+---+--+
- * | 1 | 31:0 | ++
|
- * +---+---+ ||
|
- * |...| | | Embedded `HXG Message`_ |
|
- * +---+---+ ||
|
- * | n | 31:0 | ++
|
+ * | 1 | 31:0 |
|
+ * +---+---+
|
+ * |...| | [Embedded `HXG Message`_]
|
+ * +---+---+
|
+ * | n | 31:0 |
|
*
+---+---+--+
*/
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
index bbf1ddb77434..9baa3cb07d13 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
@@ -38,11 +38,11 @@
*
+---+---+--+
* | | Bits | Description
|
*
+===+===+==+
- * | 0 | 31:0 | ++
|
- * +---+---+ ||
|
- * |...| | | Embedded `HXG Message`_ |
|
- * +---+---+ ||
|
- * | n | 31:0 | ++
|
+ * | 0 | 31:0 |
|
+ * +---+---+
|
Re: [Intel-gfx] [PATCH 21/26] drm: use new iterator in drm_gem_plane_helper_prepare_fb v2
Am 17.09.21 um 16:55 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:35:08PM +0200, Christian König wrote:
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index e570398abd78..d8f9c6432544 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -143,6 +143,7 @@
*/
int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct
drm_plane_state *state)
{
+ struct dma_resv_iter cursor;
struct drm_gem_object *obj;
struct dma_fence *fence;
@@ -150,9 +151,18 @@ int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct drm_plane_st
return 0;
obj = drm_gem_fb_get_obj(state->fb, 0);
- fence = dma_resv_get_excl_unlocked(obj->resv);
- drm_atomic_set_fence_for_plane(state, fence);
+ rcu_read_lock();
+ dma_resv_iter_begin(&cursor, obj->resv, false);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
+ rcu_read_unlock();
+ /* TODO: We only use the first write fence here */
+ drm_atomic_set_fence_for_plane(state, fence);
Yeah I wonder whether we should/need to collate them all together. But I
guesss whomever hits that first with their funny multi-plane yuv or
whatever gets to do that. Or I'm not clear on what exactly your TODO here
means?
Yeah, exactly that. Basically we have use cases where where we have more
than one fence to wait for.
The TODO is here because adding that to the atomic helper is just not my
construction site at the moment.
Regards,
Christian.
+ return 0;
+ }
+ dma_resv_iter_end(&cursor);
+ rcu_read_unlock();
Imo we should do full dma_resv_lock here. atomic helpers are designed to
allow this, and it simplifies things. Also it really doesn't matter for
atomic, we should be able to do 60fps*a few planes easily :-)
-Daniel
+ drm_atomic_set_fence_for_plane(state, NULL);
return 0;
}
EXPORT_SYMBOL_GPL(drm_gem_plane_helper_prepare_fb);
--
2.25.1
Re: [Intel-gfx] [PATCH 01/26] dma-buf: add dma_resv_for_each_fence_unlocked v2
Am 20.09.21 um 10:43 schrieb Tvrtko Ursulin:
On 17/09/2021 14:23, Daniel Vetter wrote:
On Fri, Sep 17, 2021 at 02:34:48PM +0200, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they might be freed,
improve kerneldoc, rename _cursor to _iter, add
dma_resv_iter_is_exclusive, add dma_resv_iter_begin/end
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 61 +++
include/linux/dma-resv.h | 84
++
2 files changed, 145 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 84fbe60629e3..3e77cad2c9d4 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -323,6 +323,67 @@ void dma_resv_add_excl_fence(struct dma_resv
*obj, struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_resv_add_excl_fence);
+/**
+ * dma_resv_iter_walk_unlocked - walk over fences in a dma_resv obj
+ * @cursor: cursor to record the current position
+ * @first: if we should start over
+ *
+ * Return all the fences in the dma_resv object which are not yet
signaled.
+ * The returned fence has an extra local reference so will stay alive.
+ * If a concurrent modify is detected the whole iterration is
started over again.
+ */
+struct dma_fence *dma_resv_iter_walk_unlocked(struct dma_resv_iter
*cursor,
Bit ocd, but I'd still just call that iter_next.
+ bool first)
Hm I'd put all the init code into iter_begin ...
@Christian:
Could you engineer something in here which would, at least in debug
builds, catch failures to call "iter begin" before using the iterator
macro?
Yeah, I've already played with the thought of somehow teaching lockdep
that. But then abandoned this as abusive of lockdep.
+{
+ struct dma_resv *obj = cursor->obj;
Aren't we missing rcu_read_lock() around the entire thing here?
+
+ first |= read_seqcount_retry(&obj->seq, cursor->seq);
+ do {
+ /* Drop the reference from the previous round */
+ dma_fence_put(cursor->fence);
+
+ cursor->is_first = first;
+ if (first) {
+ cursor->seq = read_seqcount_begin(&obj->seq);
+ cursor->index = -1;
+ cursor->fences = dma_resv_shared_list(obj);
And then also call iter_begin from here. That way we guarantee that
read_seqcount_begin is always called before _retry(). It's not a problem
with the seqcount implementation (I think at least), but it definitely
looks funny.
Calling iter_begin here also makes it clear that we're essentially
restarting.
+
+ cursor->fence = dma_resv_excl_fence(obj);
+ if (cursor->fence &&
+ test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
Please use the right dma_fence wrapper here for this and don't look
at the
bits/flags outside of dma_fence.[hc] code. I just realized that we don't
have the right amount of barriers in there for the fastpath, i.e. if we
have:
x = 0; /* static initializer */
thread a
x = 1;
dma_fence_signal(fence);
thread b;
if (dma_fence_is_signalled(fence))
printk("%i\n", x);
Then you might actually be able to observe x == 0 in thread b. Which is
not what we want at all.
@Daniel:
What do you mean here - in terms of if 'x' is "external" (not part of
dma-fence), then are you suggesting dma-fence code should serialise it
by using barriers?
That would sound incorrect to me, or in other words, I think it's fine
if x == 0 is observed in your example thread B since that code is
mixing external data with dma-fence.
No, Daniel is right. The problem is that on architectures other than x86
barriers are per memory address (or rather cache line in practice).
So you need to be really careful that you see the fully consistent state
and not just one variable but others in the old state.
But this was buggy before as well. I'm just pulling the existing test
into the new iterator.
Hm also, there is that annoying bit where by using
dma_fence_is_signaled any code becomes a fence signaling critical
path, which I never bought into. There should be a way to test the
signaled status without actually doing the signaling. Or I am
misunderstanding something so badly that is really really has to be
like this?
You are mixing things up. Testing is unproblematic, signaling is the
problematic one.
So no open-coding of dma_fence flag bits code outside of drm_fence.[hc]
please. And yes i915-gem code is unfortunately a disaster.
Don't even miss an opportunity for some good trashing no? :D
But yes, deconstructed dma_fence_signal I thought we were supposed to
add to core. Or at least propose, don't exactly remember how that went.
The problem is that you need to grab a reference to call
dma_fence_signal while te
Re: [Intel-gfx] [PATCH 14/26] drm/i915: use the new iterator in i915_sw_fence_await_reservation v3
Am 20.09.21 um 10:47 schrieb Tvrtko Ursulin:
On 20/09/2021 09:45, Tvrtko Ursulin wrote:
On 17/09/2021 13:35, Christian König wrote:
Simplifying the code a bit.
v2: use dma_resv_for_each_fence instead, according to Tvrtko the
lock is
held here anyway.
v3: back to using dma_resv_for_each_fence_unlocked.
It did not work out - what happened?
Wait, my suggestion to try the locked iterator was against
i915_request_await_object. I haven't looked at this one at the time or
even now.
Exactly! I've mixed the two up and this one here is really called
without holding a lock.
Regards,
Christian.
Regards,
Tvrtko
Regards,
Tvrtko
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_sw_fence.c | 57
1 file changed, 15 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index c589a681da77..7635b0478ea5 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -572,56 +572,29 @@ int i915_sw_fence_await_reservation(struct
i915_sw_fence *fence,
unsigned long timeout,
gfp_t gfp)
{
- struct dma_fence *excl;
+ struct dma_resv_iter cursor;
+ struct dma_fence *f;
int ret = 0, pending;
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
- if (write) {
- struct dma_fence **shared;
- unsigned int count, i;
-
- ret = dma_resv_get_fences(resv, &excl, &count, &shared);
- if (ret)
- return ret;
-
- for (i = 0; i < count; i++) {
- if (shared[i]->ops == exclude)
- continue;
-
- pending = i915_sw_fence_await_dma_fence(fence,
- shared[i],
- timeout,
- gfp);
- if (pending < 0) {
- ret = pending;
- break;
- }
-
- ret |= pending;
- }
-
- for (i = 0; i < count; i++)
- dma_fence_put(shared[i]);
- kfree(shared);
- } else {
- excl = dma_resv_get_excl_unlocked(resv);
- }
-
- if (ret >= 0 && excl && excl->ops != exclude) {
- pending = i915_sw_fence_await_dma_fence(fence,
- excl,
- timeout,
+ rcu_read_lock();
+ dma_resv_iter_begin(&cursor, resv, write);
+ dma_resv_for_each_fence_unlocked(&cursor, f) {
+ rcu_read_unlock();
+ pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
gfp);
- if (pending < 0)
+ rcu_read_lock();
+ if (pending < 0) {
ret = pending;
- else
- ret |= pending;
- }
-
- dma_fence_put(excl);
+ break;
+ }
+ ret |= pending;
+ }
+ dma_resv_iter_end(&cursor);
+ rcu_read_unlock();
return ret;
}
Re: [Intel-gfx] [PATCH 03/26] dma-buf: use new iterator in dma_resv_copy_fences
Am 17.09.21 um 16:35 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:34:50PM +0200, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 86 --
1 file changed, 35 insertions(+), 51 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index a3c79a99fb44..406150dea5e4 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -426,74 +426,58 @@ EXPORT_SYMBOL_GPL(dma_resv_iter_walk);
*/
int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src)
{
- struct dma_resv_list *src_list, *dst_list;
- struct dma_fence *old, *new;
- unsigned int i;
+ struct dma_resv_iter cursor;
+ struct dma_resv_list *list;
+ struct dma_fence *f, *excl;
dma_resv_assert_held(dst);
- rcu_read_lock();
- src_list = dma_resv_shared_list(src);
-
-retry:
- if (src_list) {
- unsigned int shared_count = src_list->shared_count;
-
- rcu_read_unlock();
+ list = NULL;
+ excl = NULL;
- dst_list = dma_resv_list_alloc(shared_count);
- if (!dst_list)
- return -ENOMEM;
+ rcu_read_lock();
+ dma_resv_iter_begin(&cursor, src, true);
+ dma_resv_for_each_fence_unlocked(&cursor, f) {
- rcu_read_lock();
- src_list = dma_resv_shared_list(src);
- if (!src_list || src_list->shared_count > shared_count) {
- kfree(dst_list);
- goto retry;
- }
+ if (cursor.is_first) {
Maybe have a wrapper for this, like dma_resv_iter_is_reset or is_first or
is_restart (my preference) with some nice docs that this returns true
everytime we had to restart the sequence?
Exactly that's what I wanted to avoid since the is_first (or whatever)
function should only be used inside of the dma_resv.c code.
On the other hand I can just make that static here and document that it
should never be exported.
Christian.
Otherwise I fully agree, this is so much better with all the hairy
restarting and get_rcu and test_bit shovelled away somewhere.
Either way (but I much prefer a wrapper for is_first):
Reviewed-by: Daniel Vetter
+ dma_resv_list_free(list);
+ dma_fence_put(excl);
- dst_list->shared_count = 0;
- for (i = 0; i < src_list->shared_count; ++i) {
- struct dma_fence __rcu **dst;
- struct dma_fence *fence;
+ if (cursor.fences) {
+ unsigned int cnt = cursor.fences->shared_count;
- fence = rcu_dereference(src_list->shared[i]);
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
-&fence->flags))
- continue;
+ rcu_read_unlock();
+ list = dma_resv_list_alloc(cnt);
+ if (!list) {
+ dma_resv_iter_end(&cursor);
+ return -ENOMEM;
+ }
- if (!dma_fence_get_rcu(fence)) {
- dma_resv_list_free(dst_list);
- src_list = dma_resv_shared_list(src);
- goto retry;
- }
+ list->shared_count = 0;
+ rcu_read_lock();
- if (dma_fence_is_signaled(fence)) {
- dma_fence_put(fence);
- continue;
+ } else {
+ list = NULL;
}
-
- dst = &dst_list->shared[dst_list->shared_count++];
- rcu_assign_pointer(*dst, fence);
+ excl = NULL;
}
- } else {
- dst_list = NULL;
- }
- new = dma_fence_get_rcu_safe(&src->fence_excl);
+ dma_fence_get(f);
+ if (dma_resv_iter_is_exclusive(&cursor))
+ excl = f;
+ else
+ RCU_INIT_POINTER(list->shared[list->shared_count++], f);
+ }
+ dma_resv_iter_end(&cursor);
rcu_read_unlock();
- src_list = dma_resv_shared_list(dst);
- old = dma_resv_excl_fence(dst);
-
write_seqcount_begin(&dst->seq);
- /* write_seqcount_begin provides the necessary memory barrier */
- RCU_INIT_POINTER(dst->fence_excl, new);
- RCU_INIT_POINTER(dst->fence, dst_list);
+ excl = rcu_replace_pointer(dst->fence_excl, excl, dma_resv_held(dst));
+ list = rcu_replace_pointer(dst->fence, list, dma_resv_held(dst));
write_seq
Re: [Intel-gfx] [PATCH 20/26] drm: use new iterator in drm_gem_fence_array_add_implicit v2
Am 17.09.21 um 16:53 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:35:07PM +0200, Christian König wrote:
Simplifying the code a bit.
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
This will be gone as soon as I can land the last conversion patches. Plus
it's always called with dma_resv_lock held.
Yeah, already thought so as well. I will just keep that around to get
rid of dma_resv_get_excl_unlocked() for now until your patch lands.
Regards,
Christian.
I wouldn't bother tbh.
-Daniel
---
drivers/gpu/drm/drm_gem.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 09c820045859..c2c41b668f40 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1340,31 +1340,21 @@ int drm_gem_fence_array_add_implicit(struct xarray
*fence_array,
struct drm_gem_object *obj,
bool write)
{
- int ret;
- struct dma_fence **fences;
- unsigned int i, fence_count;
-
- if (!write) {
- struct dma_fence *fence =
- dma_resv_get_excl_unlocked(obj->resv);
-
- return drm_gem_fence_array_add(fence_array, fence);
- }
-
- ret = dma_resv_get_fences(obj->resv, NULL,
- &fence_count, &fences);
- if (ret || !fence_count)
- return ret;
-
- for (i = 0; i < fence_count; i++) {
- ret = drm_gem_fence_array_add(fence_array, fences[i]);
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
+ int ret = 0;
+
+ rcu_read_lock();
+ dma_resv_iter_begin(&cursor, obj->resv, write);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
+ rcu_read_unlock();
+ ret = drm_gem_fence_array_add(fence_array, fence);
+ rcu_read_lock();
if (ret)
break;
}
-
- for (; i < fence_count; i++)
- dma_fence_put(fences[i]);
- kfree(fences);
+ dma_resv_iter_end(&cursor);
+ rcu_read_unlock();
return ret;
}
EXPORT_SYMBOL(drm_gem_fence_array_add_implicit);
--
2.25.1
[Intel-gfx] Have you attended XDC 2021? Give us your feedback!
Hi, First of all, thanks organizers for such a great conference. It was smooth and, although there were some issues as it is usual in any conference, they were fixed promptly :-) I would like also to thank all of you for attending and participating either via submitting talks, watching them or joining the hallway track in IRC :-D Without you this conference won't make sense. Now it is time to gather feedback from you :-D * Do you have any comment on how was XDC 2021? - For example, have you tried the new streaming service (https://streaming.media.ccc.de/xdc2021)? Was it fine? * Do you think we can improve on something for future events? * What did you like most/least about the conference? You can reply privately to me if you wish. We will share all the gathered feedback among organizers and the X.Org Foundation board. Now that I got your attention... Did you like XDC 2021? What about organizing XDC 2023 (likely in Europe)? We know this is a decision that takes time (trigger internal discussion, looking for volunteers, budget, and a venue suitable for the event, etc). Therefore, we encourage potential interested parties to start the internal discussions now, so any question they have can be answered before we open the call for proposals for XDC 2023 next year. Please read [0] and feel free to contact me or the board for more info if needed. Thanks, Sam [0] https://www.x.org/wiki/Events/RFP/ signature.asc Description: This is a digitally signed message part
Re: [Intel-gfx] [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout
Am 17.09.21 um 16:43 schrieb Daniel Vetter:
On Fri, Sep 17, 2021 at 02:34:52PM +0200, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 68 ++
1 file changed, 10 insertions(+), 58 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 9b90bd9ac018..c7db553ab115 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -569,74 +569,26 @@ long dma_resv_wait_timeout(struct dma_resv *obj, bool
wait_all, bool intr,
unsigned long timeout)
{
long ret = timeout ? timeout : 1;
- unsigned int seq, shared_count;
+ struct dma_resv_iter cursor;
struct dma_fence *fence;
- int i;
-retry:
- shared_count = 0;
- seq = read_seqcount_begin(&obj->seq);
rcu_read_lock();
I missed this in my previous conversion reviews, but pls move the
rcu_read_lock into the iterator. That should simplify the flow in all of
these quite a bit more, and since the iter_next_unlocked grabs a full
reference for the iteration body we really don't need that protected by
rcu.
I intentionally didn't do that because it makes it much more clear that
we are using RCU here and there is absolutely no guarantee that the
collection won't change.
But I'm fine if we go down that route instead if you think that's the
way to go.
Thanks,
Christian.
We can't toss rcu protection for dma_resv anytime soon (if ever), but we
can at least make it an implementation detail.
- i = -1;
-
- fence = dma_resv_excl_fence(obj);
- if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- if (!dma_fence_get_rcu(fence))
- goto unlock_retry;
+ dma_resv_iter_begin(&cursor, obj, wait_all);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
+ rcu_read_unlock();
- if (dma_fence_is_signaled(fence)) {
- dma_fence_put(fence);
- fence = NULL;
+ ret = dma_fence_wait_timeout(fence, intr, ret);
+ if (ret <= 0) {
+ dma_resv_iter_end(&cursor);
+ return ret;
}
- } else {
- fence = NULL;
- }
-
- if (wait_all) {
- struct dma_resv_list *fobj = dma_resv_shared_list(obj);
-
- if (fobj)
- shared_count = fobj->shared_count;
-
- for (i = 0; !fence && i < shared_count; ++i) {
- struct dma_fence *lfence;
-
- lfence = rcu_dereference(fobj->shared[i]);
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
-&lfence->flags))
- continue;
-
- if (!dma_fence_get_rcu(lfence))
- goto unlock_retry;
-
- if (dma_fence_is_signaled(lfence)) {
- dma_fence_put(lfence);
- continue;
- }
-
- fence = lfence;
- break;
- }
+ rcu_read_lock();
}
-
+ dma_resv_iter_end(&cursor);
rcu_read_unlock();
- if (fence) {
- if (read_seqcount_retry(&obj->seq, seq)) {
- dma_fence_put(fence);
- goto retry;
- }
- ret = dma_fence_wait_timeout(fence, intr, ret);
- dma_fence_put(fence);
- if (ret > 0 && wait_all && (i + 1 < shared_count))
- goto retry;
- }
return ret;
-
-unlock_retry:
- rcu_read_unlock();
- goto retry;
I think we still have the same semantics, and it's so much tidier.
With the rcu_read_unlock stuff into iterators (also applies to previous
two patches):
Reviewed-by: Daniel Vetter
}
EXPORT_SYMBOL_GPL(dma_resv_wait_timeout);
--
2.25.1
Re: [Intel-gfx] [PATCH 13/26] drm/i915: use the new iterator in i915_gem_busy_ioctl
Am 20.09.21 um 10:45 schrieb Tvrtko Ursulin:
On 17/09/2021 13:35, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 32
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 6234e17259c1..b1cb7ba688da 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -82,8 +82,8 @@ i915_gem_busy_ioctl(struct drm_device *dev, void
*data,
{
struct drm_i915_gem_busy *args = data;
struct drm_i915_gem_object *obj;
- struct dma_resv_list *list;
- unsigned int seq;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
int err;
err = -ENOENT;
@@ -109,27 +109,17 @@ i915_gem_busy_ioctl(struct drm_device *dev,
void *data,
* to report the overall busyness. This is what the wait-ioctl
does.
*
*/
-retry:
- seq = raw_read_seqcount(&obj->base.resv->seq);
-
- /* Translate the exclusive fence to the READ *and* WRITE engine */
- args->busy =
busy_check_writer(dma_resv_excl_fence(obj->base.resv));
-
- /* Translate shared fences to READ set of engines */
- list = dma_resv_shared_list(obj->base.resv);
- if (list) {
- unsigned int shared_count = list->shared_count, i;
-
- for (i = 0; i < shared_count; ++i) {
- struct dma_fence *fence =
- rcu_dereference(list->shared[i]);
-
+ args->busy = false;
+ dma_resv_iter_begin(&cursor, obj->base.resv, true);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
You did not agree with my suggestion to reset args->busy on restart
and so preserve current behaviour?
No, I want to keep the restart behavior internally to the dma_resv
object and as far as I can see it should not make a difference here.
Regards,
Christian.
Regards,
Tvrtko
+ if (dma_resv_iter_is_exclusive(&cursor))
+ /* Translate the exclusive fence to the READ *and* WRITE
engine */
+ args->busy = busy_check_writer(fence);
+ else
+ /* Translate shared fences to READ set of engines */
args->busy |= busy_check_reader(fence);
- }
}
-
- if (args->busy && read_seqcount_retry(&obj->base.resv->seq, seq))
- goto retry;
+ dma_resv_iter_end(&cursor);
err = 0;
out:
Re: [Intel-gfx] [PATCH v2 4/9] vfio/ccw: Make the FSM complete and synchronize it to the mdev
On Thu, Sep 09 2021, Jason Gunthorpe wrote: > The subchannel should be left in a quiescent state unless the VFIO device > FD is opened. When the FD is opened bring the chanel to active and allow > the VFIO device to operate. When the device FD is closed then quiesce the > channel. > > To make this work the FSM needs to handle the transitions to/from open and > closed so everything is sequenced. Rename state NOT_OPER to BROKEN and use > it wheneven the driver has malfunctioned. STANDBY becomes CLOSED. The > normal case FSM looks like: > CLOSED -> IDLE -> PROCESS/PENDING* -> IDLE -> CLOSED > > With a possible branch off to BROKEN from any state. Once the device is in > BROKEN it cannot be recovered other than be reloading the driver. Hm, not sure whether it is a good idea to conflate "something went wrong" and "device is not operational". In the latter case, we will eventually get a removal of the css device when the common I/O layer has processed the channel report for the subchannel; while the former case could mean all kind of things, but the subchannel will likely stay around. I think NOT_OPER was always meant to be a transitional state. > > Delete the triply redundant calls to > vfio_ccw_sch_quiesce(). vfio_ccw_mdev_close_device() always leaves the > subchannel quiescent. vfio_ccw_mdev_remove() cannot return until > vfio_ccw_mdev_close_device() completes and vfio_ccw_sch_remove() cannot > return until vfio_ccw_mdev_remove() completes. Have the FSM code take care > of calling cp_free() when appropriate. I remember some serialization issues wrt cp_free() etc. coming up every now and than; that might need extra care (I'm taking a look.) > > Device reset becomes a CLOSE/OPEN sequence which now properly handles the > situation if the device becomes BROKEN. > > Machine shutdown via vfio_ccw_sch_shutdown() now simply tries to close and > leaves the device BROKEN (though arguably the bus should take care to > quiet down the subchannel HW during shutdown, not the drivers) The problem is that there is not really a uniform thing that can be done for shutdown; e.g. we can quiesce and then disable I/O and EADM subchannels, but CHSC subchannels cannot be quiesced.
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/debugfs: Do not report currently active engine when describing objects (rev2)
== Series Details == Series: drm/i915/debugfs: Do not report currently active engine when describing objects (rev2) URL : https://patchwork.freedesktop.org/series/94691/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10609 -> Patchwork_21097 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21097 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21097, 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_21097/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21097: ### IGT changes ### Possible regressions * igt@i915_module_load@reload: - fi-bsw-kefka: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-bsw-kefka/igt@i915_module_l...@reload.html - fi-bsw-nick:NOTRUN -> [INCOMPLETE][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-bsw-nick/igt@i915_module_l...@reload.html Known issues Here are the changes found in Patchwork_21097 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-ilk-650: NOTRUN -> [SKIP][3] ([fdo#109271]) +35 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-ilk-650/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +18 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@core_hotunplug@unbind-rebind: - fi-skl-6700k2: [PASS][6] -> [INCOMPLETE][7] ([i915#4130]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10609/fi-skl-6700k2/igt@core_hotunp...@unbind-rebind.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-skl-6700k2/igt@core_hotunp...@unbind-rebind.html - fi-rkl-guc: [PASS][8] -> [INCOMPLETE][9] ([i915#4130]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10609/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html - fi-bxt-dsi: [PASS][10] -> [INCOMPLETE][11] ([i915#4130]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10609/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html - fi-skl-guc: [PASS][12] -> [INCOMPLETE][13] ([i915#4130]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10609/fi-skl-guc/igt@core_hotunp...@unbind-rebind.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-skl-guc/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s3: - fi-bwr-2160:NOTRUN -> [SKIP][14] ([fdo#109271]) +60 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-bwr-2160/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-kbl-7567u: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-kbl-7567u/igt@gem_huc_c...@huc-copy.html * igt@i915_module_load@reload: - fi-icl-u2: NOTRUN -> [INCOMPLETE][16] ([i915#4130]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-icl-u2/igt@i915_module_l...@reload.html - fi-kbl-7567u: NOTRUN -> [DMESG-WARN][17] ([i915#4136]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-kbl-7567u/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: NOTRUN -> [FAIL][18] ([i915#1888] / [i915#2203]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7567u: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +8 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-kbl-7567u/igt@kms_chamel...@dp-crc-fast.html - fi-bsw-nick:NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +8 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21097/fi-bsw-nick/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@dp-hpd-fast: - fi-ilk-650: NO
Re: [Intel-gfx] [PATCH v2 2/9] vfio/ccw: Pass vfio_ccw_private not mdev_device to various functions
On Thu, Sep 09 2021, Jason Gunthorpe wrote: > mdev_device should only be used in functions assigned to ops callbacks, > interior functions should use the struct vfio_ccw_private instead of > repeatedly trying to get it from the mdev. > > Signed-off-by: Jason Gunthorpe > --- > drivers/s390/cio/vfio_ccw_ops.c | 37 + > 1 file changed, 15 insertions(+), 22 deletions(-) Reviewed-by: Cornelia Huck
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover
On Mon, 2021-09-20 at 12:05 +0100, Matthew Auld wrote:
> On 14/09/2021 20:31, Thomas Hellström wrote:
> > We really only need memcpy restore for objects that affect the
> > operability of the migrate context. That is, primarily the page-
> > table
> > objects of the migrate VM.
> >
> > Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need
> > early
> > restores using memcpy and a way to assign LMEM page-table object
> > flags
> > to be used by the vms.
> >
> > Restore objects without this flag with the gpu blitter and only
> > objects
> > carrying the flag using TTM memcpy.
> >
> > Initially mark the migrate, gt, gtt and vgpu vms to use this flag,
> > and
> > defer for a later audit which vms actually need it. Most
> > importantly, user-
> > allocated vms with pinned page-table objects can be restored using
> > the
> > blitter.
> >
> > Performance-wise memcpy restore is probably as fast as gpu restore
> > if not
> > faster, but using gpu restore will help tackling future
> > restrictions in
> > mappable LMEM size.
> >
> > Signed-off-by: Thomas Hellström
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
> > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++---
> > drivers/gpu/drm/i915/gem/i915_gem_pm.c | 5 -
> > drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 6 --
> > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
> > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
> > drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +++--
> > drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +++-
> > drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_gtt.c | 3 ++-
> > drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +++--
> > drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_ppgtt.c | 13 ---
> > --
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
> > drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
> > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++--
> > 17 files changed, 48 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index c2ab0e22db0a..8208fd5b72c3 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1287,7 +1287,7 @@ i915_gem_create_context(struct
> > drm_i915_private *i915,
> > } else if (HAS_FULL_PPGTT(i915)) {
> > struct i915_ppgtt *ppgtt;
> >
> > - ppgtt = i915_ppgtt_create(&i915->gt);
> > + ppgtt = i915_ppgtt_create(&i915->gt, 0);
> > if (IS_ERR(ppgtt)) {
> > drm_dbg(&i915->drm, "PPGTT setup failed
> > (%ld)\n",
> > PTR_ERR(ppgtt));
> > @@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct
> > drm_device *dev, void *data,
> > if (args->flags)
> > return -EINVAL;
> >
> > - ppgtt = i915_ppgtt_create(&i915->gt);
> > + ppgtt = i915_ppgtt_create(&i915->gt, 0);
> > if (IS_ERR(ppgtt))
> > return PTR_ERR(ppgtt);
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index 118691ce81d7..fa2ba9e2a4d0 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -294,13 +294,16 @@ struct drm_i915_gem_object {
> > #define I915_BO_ALLOC_USER BIT(3)
> > /* Object is allowed to lose its contents on suspend / resume,
> > even if pinned */
> > #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
> > +/* Object needs to be restored early using memcpy during resume */
> > +#define I915_BO_ALLOC_PM_EARLY BIT(5)
> > #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
> > I915_BO_ALLOC_VOLATILE | \
> > I915_BO_ALLOC_CPU_CLEAR | \
> > I915_BO_ALLOC_USER | \
> > - I915_BO_ALLOC_PM_VOLATILE)
> > -#define I915_BO_READONLY BIT(5)
> > -#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not
> > release! */
> > + I915_BO_ALLOC_PM_VOLATILE | \
> > + I915_BO_ALLOC_PM_EARLY)
> > +#define I915_BO_READONLY BIT(6)
> > +#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not
> > release! */
> >
> > /**
> > * @mem_flags - Mutable placement-related flags
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > index 8736ae1dfbb2..c4a75e1c12ee 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > +++ b/drivers/gpu/drm/
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover
On 14/09/2021 20:31, Thomas Hellström wrote:
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.
Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.
Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.
Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 6 --
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +++-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +++--
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 4 ++--
17 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
if (args->flags)
return -EINVAL;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
#define I915_BO_ALLOC_USERBIT(3)
/* Object is allowed to lose its contents on suspend / resume, even if pinned
*/
#define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
I915_BO_ALLOC_CPU_CLEAR | \
I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
/**
* @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 8736ae1dfbb2..c4a75e1c12ee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -98,8 +98,11 @@ int i915_gem_backup_suspend(struct drm_i915_private *i915)
* More objects may have become unpinned as requests were
* retired. Now try to evict again. The gt may be wedged here
* in which case we automatically fall back to memcpy.
+* We allow also backing up pinned objects that have not been
+* marked for early recover, and that may contain, for example,
+* page-tables for the migrate context.
*/
- re
Re: [Intel-gfx] [PATCH v3 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume
On Mon, 2021-09-20 at 11:49 +0100, Matthew Auld wrote:
> On 14/09/2021 20:31, Thomas Hellström wrote:
> > Just evict unpinned objects to system. For pinned LMEM objects,
> > make a backup system object and blit the contents to that.
> >
> > Backup is performed in three steps,
> > 1: Opportunistically evict evictable objects using the gpu blitter.
> > 2: After gt idle, evict evictable objects using the gpu blitter.
> > This will
> > be modified in an upcoming patch to backup pinned objects that are
> > not used
> > by the blitter itself.
> > 3: Backup remaining pinned objects using memcpy.
> >
> > Also move uC suspend to after 2) to make sure we have a functional
> > GuC
> > during 2) if using GuC submission.
> >
> > v2:
> > - Major refactor to make sure gem_exec_suspend@hang-SX subtests
> > work, and
> > suspend / resume works with a slightly modified GuC submission
> > enabling
> > patch series.
> >
> > v3:
> > - Fix a potential use-after-free (Matthew Auld)
> > - Use i915_gem_object_create_shmem() instead of
> > i915_gem_object_create_region (Matthew Auld)
> > - Minor simplifications (Matthew Auld)
> > - Fix up kerneldoc for i195_ttm_restore_region().
> > - Final lmem_suspend() call moved to i915_gem_backup_suspend from
> > i915_gem_suspend_late, since the latter gets called at driver
> > unload
> > and we don't unnecessarily want to run it at that time.
> >
> > Signed-off-by: Thomas Hellström
>
>
>
> > +
> > +static int i915_ttm_restore(struct i915_gem_apply_to_region
> > *apply,
> > + struct drm_i915_gem_object *obj)
> > +{
> > + struct i915_gem_ttm_pm_apply *pm_apply =
> > + container_of(apply, typeof(*pm_apply), base);
> > + struct drm_i915_gem_object *backup = obj->ttm.backup;
> > + struct ttm_buffer_object *backup_bo =
> > i915_gem_to_ttm(backup);
> > + struct ttm_operation_ctx ctx = {};
> > + int err;
> > +
> > + if (!backup)
> > + return 0;
> > +
> > + if (!pm_apply->allow_gpu && (obj->flags &
> > I915_BO_ALLOC_USER))
> > + return 0;
>
> Hmm, do we ever hit this? I would presume anything that userspace
> directly allocated in lmem can be kicked out with
> ttm_bo_validate(sys)
> i.e backup == NULL?
At this point, (before patch 6/6) I think we might do. Typical
candidates are dma-buf objects that have become pinned on exporting,
and perhaps framebuffers that are pinned, not sure they are unpinned
before we back them up.
But it might be that we should remove this after patch 6/6 where we
require a special flag for early recovers using memcpy.
/Thomas
>
> > +
> > + err = i915_gem_object_lock(backup, apply->ww);
> > + if (err)
> > + return err;
> > +
> > + /* Content may have been swapped. */
> > + err = ttm_tt_populate(backup_bo->bdev, backup_bo->ttm,
> > &ctx);
> > + if (!err) {
> > + err = i915_gem_obj_copy_ttm(obj, backup, pm_apply-
> > >allow_gpu,
> > + false);
> > + GEM_WARN_ON(err);
> > +
> > + obj->ttm.backup = NULL;
> > + err = 0;
> > + }
> > +
> > + i915_gem_ww_unlock_single(backup);
> > +
> > + if (!err)
> > + i915_gem_object_put(backup);
> > +
> > + return err;
> > +}
> > +
