Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix the GT fence revocation runtime PM logic
On Tue, Mar 23, 2021 at 09:29:40PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix the GT fence revocation runtime PM logic > URL : https://patchwork.freedesktop.org/series/88300/ > State : success Patch is pushed to -din adding the tags for stable, Fixes and Chris' R-b. While applying I also added a code comment to i915_vma_revoke_fence() suggested by Chris explaining how the fence reg programming is deferred and fixed the __intel_runtime_pm_get_if_active() docbook comment. Thanks for the review. > == Summary == > > CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19833_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_19833_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-massive: > - shard-snb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-snb2/igt@gem_cre...@create-massive.html > - shard-skl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-skl8/igt@gem_cre...@create-massive.html > > * igt@gem_ctx_isolation@preservation-s3@vecs0: > - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl2/igt@gem_ctx_isolation@preservation...@vecs0.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-kbl1/igt@gem_ctx_isolation@preservation...@vecs0.html > > * igt@gem_ctx_persistence@process: > - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +7 > similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-snb7/igt@gem_ctx_persiste...@process.html > > * igt@gem_eio@unwedge-stress: > - shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / > [i915#3063]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb2/igt@gem_...@unwedge-stress.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-tglb1/igt@gem_...@unwedge-stress.html > > * igt@gem_exec_balancer@hang: > - shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([i915#1895]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb7/igt@gem_exec_balan...@hang.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-iclb1/igt@gem_exec_balan...@hang.html > > * igt@gem_exec_fair@basic-flow@rcs0: > - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar > issues >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html > > * igt@gem_exec_fair@basic-none-vip@rcs0: > - shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html > - shard-glk: NOTRUN -> [FAIL][13] ([i915#2842]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-glk1/igt@gem_exec_fair@basic-none-...@rcs0.html > > * igt@gem_exec_fair@basic-pace-solo@rcs0: > - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html > - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html > > * igt@gem_exec_fair@basic-pace@rcs0: > - shard-kbl: [PASS][18] -> [SKIP][19] ([fdo#109271]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html > > * igt@gem_exec_reloc@basic-parallel: > - shard-apl: NOTRUN -> [TIMEOUT][20] ([i915#3183]) >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-apl7/igt@gem_exec_re...@basic-parallel.html > > * igt@gem_exec_reloc@basic-wide-active@rcs0: > - shard-snb: NOTRUN -> [FAIL][21] ([i915#2389]) +2 similar issues >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html > > *
Re: [Intel-gfx] [PATCH 2/2] drm/hdcp: DP HDCP2.2 errata LC_Send_L_Prime=16
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Wednesday, March 24, 2021 10:16 AM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/hdcp: DP HDCP2.2 errata
> LC_Send_L_Prime=16
>
> Change is as per the errata. LGTM.
>
> Reviewed-by: Ankit Nautiyal
Hi Maarten ,
Could you please provide your Ack to merge it via drm-intel-next, since it is
a small change.
Thanks,
Anshuman Gupta.
>
> On 1/27/2021 1:54 PM, Anshuman Gupta wrote:
> > Fix LC_Send_L_Prime message timeout to 16 as documented in DP HDCP 2.2
> > errata page 3.
> >
> > https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_
> > Errata_v3_0.pdf
> >
> > Cc: Ramalingam C
> > Signed-off-by: Anshuman Gupta
> > ---
> > include/drm/drm_hdcp.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
> > 2b165a0f434f..0be3228e 100644
> > --- a/include/drm/drm_hdcp.h
> > +++ b/include/drm/drm_hdcp.h
> > @@ -231,7 +231,7 @@ struct hdcp2_rep_stream_ready {
> > #define HDCP_2_2_PAIRING_TIMEOUT_MS 200
> > #define HDCP_2_2_DP_PAIRING_READ_TIMEOUT_MS 5
> > #define HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS 20
> > -#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS 7
> > +#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS 16
> > #define HDCP_2_2_RECVID_LIST_TIMEOUT_MS 3000
> > #define HDCP_2_2_STREAM_READY_TIMEOUT_MS 100
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/hdcp: DP HDCP2.2 errata LC_Send_L_Prime=16
Change is as per the errata. LGTM.
Reviewed-by: Ankit Nautiyal
On 1/27/2021 1:54 PM, Anshuman Gupta wrote:
Fix LC_Send_L_Prime message timeout to 16 as documented
in DP HDCP 2.2 errata page 3.
https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_Errata_v3_0.pdf
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
include/drm/drm_hdcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 2b165a0f434f..0be3228e 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -231,7 +231,7 @@ struct hdcp2_rep_stream_ready {
#define HDCP_2_2_PAIRING_TIMEOUT_MS 200
#define HDCP_2_2_DP_PAIRING_READ_TIMEOUT_MS 5
#define HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS 20
-#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS 7
+#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS 16
#define HDCP_2_2_RECVID_LIST_TIMEOUT_MS 3000
#define HDCP_2_2_STREAM_READY_TIMEOUT_MS 100
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: add gem/gt TODO
== Series Details == Series: series starting with [1/2] drm/i915: add gem/gt TODO URL : https://patchwork.freedesktop.org/series/88329/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19837_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19837_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19837_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_19837_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-queues-forked-all: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb5/igt@gem_exec_whis...@basic-queues-forked-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb2/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gem_workarounds@suspend-resume-fd: - shard-snb: [PASS][3] -> [TIMEOUT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-snb5/igt@gem_workarou...@suspend-resume-fd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb6/igt@gem_workarou...@suspend-resume-fd.html Known issues Here are the changes found in Patchwork_19837_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_19837/shard-snb2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-hostile: - shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb7/igt@gem_ctx_persiste...@engines-hostile.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#1895] / [i915#3031]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb7/igt@gem_exec_balan...@hang.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb1/igt@gem_exec_balan...@hang.html * igt@gem_exec_create@legacy: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk6/igt@gem_exec_cre...@legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk8/igt@gem_exec_cre...@legacy.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html - shard-glk: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb3/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: NOTRUN -> [FAIL][19] ([i915#2849]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-apl: NOTRUN -> [TIMEOUT][20] ([i915#3183]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][21] ([i915#2389]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html *
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Disassociate display version from INTEL_GEN() (rev5)
On Tue, Mar 23, 2021 at 10:59:48PM +, Patchwork wrote: > == Series Details == > > Series: Disassociate display version from INTEL_GEN() (rev5) > URL : https://patchwork.freedesktop.org/series/88198/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19836_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19836_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19836_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_19836_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_big_fb@linear-16bpp-rotate-180: > - shard-glk: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk8/igt@kms_big...@linear-16bpp-rotate-180.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-glk4/igt@kms_big...@linear-16bpp-rotate-180.html Since this was a GLK failure it worried me a bit, but CI shows that this test also failed on builds 9881 and 9882 without my series here, so it seems to be a pre-existing issue. There's a TGL CRC mismatch reported at https://gitlab.freedesktop.org/drm/intel/-/issues/3236 that might be related? There aren't any failures resulting from this series, so applied to di-next. Thanks Ville and Lucas for the reviews. Matt > > > Known issues > > > Here are the changes found in Patchwork_19836_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_create@create-clear: > - shard-glk: [PASS][3] -> [FAIL][4] ([i915#3160]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk5/igt@gem_cre...@create-clear.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-glk6/igt@gem_cre...@create-clear.html > - shard-skl: [PASS][5] -> [FAIL][6] ([i915#1888] / [i915#3160]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl9/igt@gem_cre...@create-clear.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-skl10/igt@gem_cre...@create-clear.html > > * igt@gem_ctx_persistence@process: > - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +7 > similar issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-snb7/igt@gem_ctx_persiste...@process.html > > * igt@gem_exec_balancer@hang: > - shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([i915#1895] / > [i915#3031]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb7/igt@gem_exec_balan...@hang.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-iclb4/igt@gem_exec_balan...@hang.html > > * igt@gem_exec_fair@basic-deadline: > - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2846]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl3/igt@gem_exec_f...@basic-deadline.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-kbl2/igt@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-none-vip@rcs0: > - shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-tglb2/igt@gem_exec_fair@basic-none-...@rcs0.html > > * igt@gem_exec_fair@basic-none@vcs0: > - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar > issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html > - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar > issue >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk2/igt@gem_exec_fair@basic-n...@vcs0.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html > > * igt@gem_exec_fair@basic-pace-solo@rcs0: > - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar > issue >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html > > * igt@gem_exec_fair@basic-throttle@rcs0: > - shard-iclb: NOTRUN -> [FAIL][19] ([i915#2849]) >[19]: >
[Intel-gfx] ✓ Fi.CI.BAT: success for Simplify intel_setup_outputs() (rev3)
== Series Details ==
Series: Simplify intel_setup_outputs() (rev3)
URL : https://patchwork.freedesktop.org/series/87068/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9886 -> Patchwork_19844
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/index.html
Known issues
Here are the changes found in Patchwork_19844 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_flink_basic@bad-open:
- fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
* igt@gem_huc_copy@huc-copy:
- fi-byt-j1900: NOTRUN -> [SKIP][4] ([fdo#109271]) +27 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html
* igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g: [PASS][5] -> [TIMEOUT][6] ([i915#3145])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
* igt@i915_hangman@error-state-basic:
- fi-apl-guc: NOTRUN -> [DMESG-WARN][7] ([i915#1610])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-apl-guc/igt@i915_hang...@error-state-basic.html
* igt@i915_selftest@live@client:
- fi-glk-dsi: [PASS][8] -> [DMESG-FAIL][9] ([i915#3047])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-glk-dsi/igt@i915_selftest@l...@client.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-glk-dsi/igt@i915_selftest@l...@client.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> [FAIL][11] ([i915#2426])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-apl-guc/igt@run...@aborted.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-tgl-y: [DMESG-WARN][12] ([i915#402]) -> [PASS][13] +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-tgl-y/igt@debugfs_test@read_all_entries.html
* igt@gem_tiled_blits@basic:
- fi-kbl-8809g: [TIMEOUT][14] ([i915#2502] / [i915#3145]) ->
[PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-8809g: [SKIP][16] ([fdo#109271]) -> [PASS][17] +3 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-kbl-8809g/igt@kms_force_connector_ba...@prune-stale-modes.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-kbl-8809g/igt@kms_force_connector_ba...@prune-stale-modes.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][18] ([i915#3143]) -> [DMESG-WARN][19]
([i915#1982] / [i915#3143])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g: [SKIP][20] ([fdo#109271]) -> [SKIP][21] ([fdo#109271]
/ [fdo#111827]) +8 similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g: [SKIP][22] ([fdo#109271]) -> [SKIP][23] ([fdo#109271]
/ [i915#533])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19844/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
{name}: This element
[Intel-gfx] ✗ Fi.CI.IGT: failure for Disassociate display version from INTEL_GEN() (rev5)
== Series Details == Series: Disassociate display version from INTEL_GEN() (rev5) URL : https://patchwork.freedesktop.org/series/88198/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19836_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19836_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19836_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_19836_full: ### IGT changes ### Possible regressions * igt@kms_big_fb@linear-16bpp-rotate-180: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk8/igt@kms_big...@linear-16bpp-rotate-180.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-glk4/igt@kms_big...@linear-16bpp-rotate-180.html Known issues Here are the changes found in Patchwork_19836_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#3160]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk5/igt@gem_cre...@create-clear.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-glk6/igt@gem_cre...@create-clear.html - shard-skl: [PASS][5] -> [FAIL][6] ([i915#1888] / [i915#3160]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl9/igt@gem_cre...@create-clear.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-skl10/igt@gem_cre...@create-clear.html * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-snb7/igt@gem_ctx_persiste...@process.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([i915#1895] / [i915#3031]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb7/igt@gem_exec_balan...@hang.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-iclb4/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl3/igt@gem_exec_f...@basic-deadline.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-kbl2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-tglb2/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk2/igt@gem_exec_fair@basic-n...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: NOTRUN -> [FAIL][19] ([i915#2849]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][20] ([i915#3183]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-kbl6/igt@gem_exec_re...@basic-parallel.html - shard-apl: NOTRUN -> [TIMEOUT][21] ([i915#3183]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-apl1/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][22] ([i915#2389]) +2 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/shard-snb6/igt@gem_exec_reloc@basic-wide-act...@rcs0.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Simplify intel_setup_outputs() (rev3)
== Series Details ==
Series: Simplify intel_setup_outputs() (rev3)
URL : https://patchwork.freedesktop.org/series/87068/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
45ba56848b16 drm/i915/display: move vbt check to intel_ddi_init()
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 45c0673aac97 ("drm/i915/bios:
start using the intel_bios_encoder_data directly")'
#15:
v2: Rebase 45c0673aac97 re-using that check in intel_ddi_init() instead
total: 1 errors, 0 warnings, 0 checks, 29 lines checked
5ad9c9eb22d9 drm/i915/display: remove FIXME comment for intended feature
cb9bc7367eec drm/i915/display: remove strap checks from gen 9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: Skip display interruption setup when display is not available
== Series Details == Series: series starting with [v2,1/3] drm/i915: Skip display interruption setup when display is not available URL : https://patchwork.freedesktop.org/series/88301/ State : success == Summary == CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19834_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19834_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-hostile: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-snb6/igt@gem_ctx_persiste...@engines-hostile.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][2] -> [TIMEOUT][3] ([i915#2369] / [i915#3063]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb2/igt@gem_...@unwedge-stress.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][4] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-tglb8/igt@gem_exec_fair@basic-none-...@rcs0.html - shard-glk: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-glk3/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-tglb3/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][12] ([i915#3183]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-kbl3/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][13] ([i915#2389]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-snb6/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vecs0: - shard-skl: NOTRUN -> [DMESG-WARN][14] ([i915#1610] / [i915#2803]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-skl6/igt@gem_exec_schedule@u-fairsl...@vecs0.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy-odd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-iclb2/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#307]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk3/igt@gem_mmap_...@cpuset-medium-copy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-glk1/igt@gem_mmap_...@cpuset-medium-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-snb6/igt@gem_pwr...@basic-exhaustion.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-apl3/igt@gem_soft...@noreloc-s3.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-apl2/igt@gem_soft...@noreloc-s3.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][22] ([i915#3002]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-skl9/igt@gem_userptr_bl...@input-checking.html - shard-tglb: NOTRUN -> [DMESG-WARN][23] ([i915#3002]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/shard-tglb8/igt@gem_userptr_bl...@input-checking.html - shard-glk: NOTRUN
[Intel-gfx] ✓ Fi.CI.BAT: success for i915_vma: Rename vma_lookup to i915_vma_lookup
== Series Details ==
Series: i915_vma: Rename vma_lookup to i915_vma_lookup
URL : https://patchwork.freedesktop.org/series/88362/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9886 -> Patchwork_19843
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/index.html
Known issues
Here are the changes found in Patchwork_19843 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#2411] /
[i915#402])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
* igt@gem_huc_copy@huc-copy:
- fi-byt-j1900: NOTRUN -> [SKIP][4] ([fdo#109271]) +27 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html
* igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g: [PASS][5] -> [TIMEOUT][6] ([i915#3145])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
* igt@i915_hangman@error-state-basic:
- fi-apl-guc: NOTRUN -> [DMESG-WARN][7] ([i915#1610])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-apl-guc/igt@i915_hang...@error-state-basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: [PASS][8] -> [DMESG-WARN][9] ([i915#2203] /
[i915#2868])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html
* igt@prime_vgem@basic-userptr:
- fi-cml-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1610])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-cml-u2/igt@prime_v...@basic-userptr.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-cml-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> [FAIL][13] ([i915#2426])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-apl-guc/igt@run...@aborted.html
- fi-cml-u2: NOTRUN -> [FAIL][14] ([i915#2082] / [i915#2426] /
[i915#409])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-cml-u2/igt@run...@aborted.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-tgl-y/igt@debugfs_test@read_all_entries.html
* igt@gem_tiled_blits@basic:
- fi-kbl-8809g: [TIMEOUT][17] ([i915#2502] / [i915#3145]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][19] ([i915#3143]) -> [DMESG-WARN][20]
([i915#1982] / [i915#3143])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9886/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19843/fi-glk-dsi/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2411]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915_vma: Rename vma_lookup to i915_vma_lookup
== Series Details == Series: i915_vma: Rename vma_lookup to i915_vma_lookup URL : https://patchwork.freedesktop.org/series/88362/ State : warning == Summary == $ dim checkpatch origin/drm-tip 45c9457c9a34 i915_vma: Rename vma_lookup to i915_vma_lookup -:21: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #21: FILE: drivers/gpu/drm/i915/i915_vma.c:234: +i915_vma_lookup(struct drm_i915_gem_object *obj, struct i915_address_space *vm, -:32: ERROR:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Liam Howlett ' total: 1 errors, 0 warnings, 1 checks, 16 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: uAPI clean-ups part 2 (rev2)
== Series Details == Series: drm/i915: uAPI clean-ups part 2 (rev2) URL : https://patchwork.freedesktop.org/series/88196/ State : failure == Summary == Applying: drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE Applying: drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP Applying: drm/i915: Drop the CONTEXT_CLONE API Applying: drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2) error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gem/i915_gem_context.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0004 drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2) When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix the GT fence revocation runtime PM logic
== Series Details == Series: drm/i915: Fix the GT fence revocation runtime PM logic URL : https://patchwork.freedesktop.org/series/88300/ State : success == Summary == CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19833_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19833_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-snb2/igt@gem_cre...@create-massive.html - shard-skl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-skl8/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl2/igt@gem_ctx_isolation@preservation...@vecs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-kbl1/igt@gem_ctx_isolation@preservation...@vecs0.html * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-snb7/igt@gem_ctx_persiste...@process.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb2/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-tglb1/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([i915#1895]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb7/igt@gem_exec_balan...@hang.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-iclb1/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html - shard-glk: NOTRUN -> [FAIL][13] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-glk1/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][18] -> [SKIP][19] ([fdo#109271]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-apl: NOTRUN -> [TIMEOUT][20] ([i915#3183]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-apl7/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][21] ([i915#2389]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][22] ([i915#2389]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@bcs0: - shard-tglb: [PASS][23] -> [DMESG-WARN][24] ([i915#2803]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb2/igt@gem_exec_schedule@u-fairsl...@bcs0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@bcs0.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: settle on "adl-s" vs "adl_s" in WA comments
== Series Details == Series: series starting with [1/2] drm/i915: settle on "adl-s" vs "adl_s" in WA comments URL : https://patchwork.freedesktop.org/series/88299/ State : success == Summary == CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19832_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19832_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-apl: NOTRUN -> [SKIP][1] ([fdo#109271]) +234 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-apl7/igt@feature_discov...@display-4x.html * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-snb2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-snb6/igt@gem_ctx_persiste...@process.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#2369] / [i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb2/igt@gem_...@unwedge-stress.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-tglb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([i915#1895]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb7/igt@gem_exec_balan...@hang.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-iclb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-tglb2/igt@gem_exec_fair@basic-none-...@rcs0.html - shard-glk: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-glk1/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-tglb3/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2849]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][15] ([i915#3183]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-kbl4/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][16] ([i915#2389]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-snb6/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_schedule@u-fairslice-all: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1610] / [i915#2803]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl5/igt@gem_exec_sched...@u-fairslice-all.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-skl7/igt@gem_exec_sched...@u-fairslice-all.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#1610] / [i915#2803]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-kbl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html - shard-skl: NOTRUN -> [DMESG-WARN][21] ([i915#2803]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-skl1/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_mmap_gtt@big-copy-odd: - shard-glk: [PASS][22] -> [FAIL][23] ([i915#307]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk3/igt@gem_mmap_...@big-copy-odd.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/shard-glk1/igt@gem_mmap_...@big-copy-odd.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN
Re: [Intel-gfx] [PATCH v9 32/70] drm/i915: Prepare for obj->mm.lock removal, v2.
On Tue, 2021-03-23 at 16:18 +, Matthew Auld wrote:
> On Tue, 23 Mar 2021 at 15:52, Maarten Lankhorst
> wrote:
> >
> > From: Thomas Hellström
> >
> > Stolen objects need to lock, and we may call put_pages when
> > refcount drops to 0, ensure all calls are handled correctly.
> >
> > Changes since v1:
> > - Rebase on top of upstream changes.
> >
> > Idea-from: Thomas Hellström
> > Signed-off-by: Maarten Lankhorst
> >
> > Signed-off-by: Thomas Hellström
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 ++
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
> > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +++-
> > 3 files changed, 33 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 983f2d4b2a85..74de195b57de 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -144,6 +144,20 @@ i915_gem_object_put(struct drm_i915_gem_object
> > *obj)
> >
> > #define assert_object_held(obj) dma_resv_assert_held((obj)-
> > >base.resv)
> >
> > +/*
> > + * If more than one potential simultaneous locker, assert held.
> > + */
> > +static inline void assert_object_held_shared(struct
> > drm_i915_gem_object *obj)
> > +{
> > + /*
> > + * Note mm list lookup is protected by
>
> What is meant with mm list here? Maybe just a stale comment?
That would be the i915->mm lists, (shrink and purge).
>
> > + * kref_get_unless_zero().
> > + */
> > + if (IS_ENABLED(CONFIG_LOCKDEP) &&
> > + kref_read(>base.refcount) > 0)
> > + lockdep_assert_held(>mm.lock);
> > +}
> > +
> > static inline int __i915_gem_object_lock(struct
> > drm_i915_gem_object *obj,
> > struct i915_gem_ww_ctx
> > *ww,
> > bool intr)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > index a24617af3c93..2d0065fa6e80 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > @@ -19,7 +19,7 @@ void __i915_gem_object_set_pages(struct
> > drm_i915_gem_object *obj,
> > bool shrinkable;
> > int i;
> >
> > - lockdep_assert_held(>mm.lock);
> > + assert_object_held_shared(obj);
> >
> > if (i915_gem_object_is_volatile(obj))
> > obj->mm.madv = I915_MADV_DONTNEED;
> > @@ -70,6 +70,7 @@ void __i915_gem_object_set_pages(struct
> > drm_i915_gem_object *obj,
> > struct list_head *list;
> > unsigned long flags;
> >
> > + lockdep_assert_held(>mm.lock);
> > spin_lock_irqsave(>mm.obj_lock, flags);
> >
> > i915->mm.shrink_count++;
> > @@ -91,6 +92,8 @@ int i915_gem_object_get_pages(struct
> > drm_i915_gem_object *obj)
> > struct drm_i915_private *i915 = to_i915(obj->base.dev);
> > int err;
> >
> > + assert_object_held_shared(obj);
> > +
> > if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
> > drm_dbg(>drm,
> > "Attempting to obtain a purgeable
> > object\n");
> > @@ -118,6 +121,8 @@ int __i915_gem_object_get_pages(struct
> > drm_i915_gem_object *obj)
> > if (err)
> > return err;
> >
> > + assert_object_held_shared(obj);
> > +
> > if (unlikely(!i915_gem_object_has_pages(obj))) {
> > GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> >
> > @@ -145,7 +150,7 @@ void i915_gem_object_truncate(struct
> > drm_i915_gem_object *obj)
> > /* Try to discard unwanted pages */
> > void i915_gem_object_writeback(struct drm_i915_gem_object *obj)
> > {
> > - lockdep_assert_held(>mm.lock);
> > + assert_object_held_shared(obj);
> > GEM_BUG_ON(i915_gem_object_has_pages(obj));
> >
> > if (obj->ops->writeback)
> > @@ -176,6 +181,8 @@ __i915_gem_object_unset_pages(struct
> > drm_i915_gem_object *obj)
> > {
> > struct sg_table *pages;
> >
> > + assert_object_held_shared(obj);
> > +
> > pages = fetch_and_zero(>mm.pages);
> > if (IS_ERR_OR_NULL(pages))
> > return pages;
> > @@ -203,6 +210,9 @@ int __i915_gem_object_put_pages_locked(struct
> > drm_i915_gem_object *obj)
> > if (i915_gem_object_has_pinned_pages(obj))
> > return -EBUSY;
> >
> > + /* May be called by shrinker from within get_pages() (on
> > another bo) */
> > + assert_object_held_shared(obj);
> > +
> > i915_gem_object_release_mmap_offset(obj);
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > index 7cdb32d881d9..b0597de206de 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > +++
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
HI,
On 3/23/21 8:13 PM, Hans de Goede wrote:
> Hi,
>
> On 3/23/21 6:51 PM, Ville Syrjälä wrote:
>> On Tue, Mar 23, 2021 at 06:29:53PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/22/21 10:47 PM, Ville Syrjälä wrote:
On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
>> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
>>> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
Hi,
On 3/1/21 4:43 PM, Hans de Goede wrote:
> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> Predia Basic tablet would no longer properly light up after reboot.
>
> The backlight still turns back on after reboot, but the LCD shows an
> all black display. The display is also all black during the time that
> EFI / the GOP is managing it, so e.g. the grub menu also is not
> visible.
>
> In this scenario the panel is initialized so that it appears to be
> working
> and the fastboot code skips doing a modeset. Forcing a modeset by
> doing a
> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> /sys/class/graphics/fb0/blank causes the panel to work again.
>
> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown()
> into
> a no-op when set; and set this on vlv/chv devices when a DSI panel is
> detected, to work around this.
>
> Admittedly this is a bit of a big hammer, but these platforms have
> been
> around for quite some time now and they have always worked fine
> without
> the new behavior to shutdown everything on shutdown/reboot. This
> approach
> simply disables the recently introduced new shutdown behavior in this
> specific case where it is known to cause problems. Which is a nice and
> simple way to deal with this.
>
> Signed-off-by: Hans de Goede
Ping? Since sending this patch I've been seeing the issue addressed by
this on variour other CHT based devices too.
So we have various devices suffering from a black screen after reboot
now. This is pretty serious usability regression.
As such it would be good to get this reviewed, or another fix proposed.
>>>
>>> For the quirks we try to limit them to very specific vendor and model
>>> ids,
>>> so I wonder if it would be possible to get this information in here
>>> instead
>>> to all the vlv with dsi...
>>>
>>> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>>>
>>> Jani?
>>> Ville?
>>
>> We need to figure out why the panel doesn't start up again.
>
> Note it is the GOP which fails to light it up again. I think we turn
> something
> off, which after a power-on-reset is on, so the GOP expects it to be on.
Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
Are there any fast vs. slow boot settings in the BIOS setup?
>>>
>>> Ok, so I was running the tests which you requested and during this
>>> I managed to find the real problem.
>>>
>>> What happens on reboot is a really quick panel off/on cycle and that is
>>> causing the issue.
>>>
>>> I can reproduce this by doing:
>>>
>>> chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
>>> /sys/class/graphics/fb0/blank
>>>
>>> The problem is that we're not honoring panel_pwr_cycle_delay because
>>> intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
>>> because those sequences already contain the necessary delays, at least
>>> for most of the steps during the on/off sequences. It seems that the
>>> pwr-cycle delay is not handled by those v3+ sequences.
>>>
>>> So fixing this is as simple as switching to a regular msleep for the
>>> intel_dsi->panel_pwr_cycle_delay.
>>>
>>> Once we do that it would be good (for e.g. suspend/resume speed) to fix:
>>>
>>> /*
>>> * FIXME As we do with eDP, just make a note of the time here
>>> * and perform the wait before the next panel power on.
>>> */
>>>
>>> Which sits right above that msleep. Since I have a reproducer now which
>>> shows when the sleep is too short, it should now be easy ti fix the FIXME
>>> and test that the fix works. I'll do this in a separate patch and send
>>> a patch-set with both patches replacing this patch.
>>
>> Awesome. I'm really happy to avoid any quirks and whatnot since
>> they always come back to bite you later. Thanks for digging into it.
>>
>> Speaking of DSI, you wouldn't happen to have one these machines:
>> https://gitlab.freedesktop.org/drm/intel/-/issues/2698 ?
>
> Sorry I don't have any 10" Dell
Re: [Intel-gfx] [PATCH 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes
On Tue, Mar 23, 2021 at 02:55:35PM -0300, Jason Gunthorpe wrote:
> The driver core standard is to pass in the properly typed object, the
> properly typed attribute and the buffer data. It stems from the root
> kobject method:
>
> ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,..)
>
> Each subclass of kobject should provide their own function with the same
> signature but more specific types, eg struct device uses:
>
> ssize_t (*show)(struct device *dev, struct device_attribute *attr,..)
>
> In this case the existing signature is:
>
> ssize_t (*show)(struct kobject *kobj, struct device *dev,..)
>
> Where kobj is a 'struct mdev_type *' and dev is 'mdev_type->parent->dev'.
>
> Change the mdev_type related sysfs attribute functions to:
>
> ssize_t (*show)(struct mdev_type *mtype, struct mdev_type_attribute
> *attr,..)
>
> In order to restore type safety and match the driver core standard
>
> There are no current users of 'attr', but if it is ever needed it would be
> hard to add in retroactively, so do it now.
>
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/gpu/drm/i915/gvt/gvt.c| 21 +++--
> drivers/s390/cio/vfio_ccw_ops.c | 15 +--
> drivers/s390/crypto/vfio_ap_ops.c | 12 +++-
> drivers/vfio/mdev/mdev_core.c | 14 --
> drivers/vfio/mdev/mdev_sysfs.c| 11 ++-
> include/linux/mdev.h | 11 +++
> samples/vfio-mdev/mbochs.c| 26 +++---
> samples/vfio-mdev/mdpy.c | 24 ++--
> samples/vfio-mdev/mtty.c | 18 +-
> 9 files changed, 90 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index 4b47a18e9dfa0f..3703814a669b46 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -54,14 +54,15 @@ intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned
> int type_group_id)
> return >types[type_group_id];
> }
>
> -static ssize_t available_instances_show(struct kobject *kobj,
> - struct device *dev, char *buf)
> +static ssize_t available_instances_show(struct mdev_type *mtype,
> + struct mdev_type_attribute *attr,
> + char *buf)
> {
> struct intel_vgpu_type *type;
> unsigned int num = 0;
> - void *gvt = kdev_to_i915(dev)->gvt;
> + void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
>
> - type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
> + type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
Somewhere in this series you should probably
switch intel_gvt_find_vgpu_type to only get the mtype, as it can trivially
deduct the gvt from it (which also seems to have lost its type somewhere..)
Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/18] vfio/mdev: Remove kobj from mdev_parent_ops->create()
Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] vfio/gvt: Use mdev_get_type_group_id()
On Tue, Mar 23, 2021 at 02:55:33PM -0300, Jason Gunthorpe wrote: > intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the > supported_type_groups array, so the type_group_id is also the index into > gvt->types. Use it directly and remove the string matching. > > Signed-off-by: Jason Gunthorpe > --- > drivers/gpu/drm/i915/gvt/gvt.c | 24 +++- > drivers/gpu/drm/i915/gvt/gvt.h | 4 ++-- > drivers/gpu/drm/i915/gvt/kvmgt.c | 5 ++--- > 3 files changed, 11 insertions(+), 22 deletions(-) Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV
On Tue, Mar 23, 2021 at 02:55:32PM -0300, Jason Gunthorpe wrote: > Ideally all of this would be moved to kvmgt.c, but it is entangled with > the rest of the "generic" code in an odd way. Thus put in a kconfig > dependency so we don't get randconfig failures when the next patch creates > a link time dependency related to the use of MDEV_TYPE. Ideally that weird struct intel_gvt_mpt would go away entirely. But that is clearly out of scope for this patchset.. Looks good: Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
Hi,
On 3/23/21 6:51 PM, Ville Syrjälä wrote:
> On Tue, Mar 23, 2021 at 06:29:53PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/22/21 10:47 PM, Ville Syrjälä wrote:
>>> On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
Hi,
On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
>> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/1/21 4:43 PM, Hans de Goede wrote:
After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.
The backlight still turns back on after reboot, but the LCD shows an
all black display. The display is also all black during the time that
EFI / the GOP is managing it, so e.g. the grub menu also is not
visible.
In this scenario the panel is initialized so that it appears to be
working
and the fastboot code skips doing a modeset. Forcing a modeset by
doing a
chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
/sys/class/graphics/fb0/blank causes the panel to work again.
Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
a no-op when set; and set this on vlv/chv devices when a DSI panel is
detected, to work around this.
Admittedly this is a bit of a big hammer, but these platforms have been
around for quite some time now and they have always worked fine without
the new behavior to shutdown everything on shutdown/reboot. This
approach
simply disables the recently introduced new shutdown behavior in this
specific case where it is known to cause problems. Which is a nice and
simple way to deal with this.
Signed-off-by: Hans de Goede
>>>
>>> Ping? Since sending this patch I've been seeing the issue addressed by
>>> this on variour other CHT based devices too.
>>>
>>> So we have various devices suffering from a black screen after reboot
>>> now. This is pretty serious usability regression.
>>>
>>> As such it would be good to get this reviewed, or another fix proposed.
>>
>> For the quirks we try to limit them to very specific vendor and model
>> ids,
>> so I wonder if it would be possible to get this information in here
>> instead
>> to all the vlv with dsi...
>>
>> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>>
>> Jani?
>> Ville?
>
> We need to figure out why the panel doesn't start up again.
Note it is the GOP which fails to light it up again. I think we turn
something
off, which after a power-on-reset is on, so the GOP expects it to be on.
>>>
>>> Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
>>> Are there any fast vs. slow boot settings in the BIOS setup?
>>
>> Ok, so I was running the tests which you requested and during this
>> I managed to find the real problem.
>>
>> What happens on reboot is a really quick panel off/on cycle and that is
>> causing the issue.
>>
>> I can reproduce this by doing:
>>
>> chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
>> /sys/class/graphics/fb0/blank
>>
>> The problem is that we're not honoring panel_pwr_cycle_delay because
>> intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
>> because those sequences already contain the necessary delays, at least
>> for most of the steps during the on/off sequences. It seems that the
>> pwr-cycle delay is not handled by those v3+ sequences.
>>
>> So fixing this is as simple as switching to a regular msleep for the
>> intel_dsi->panel_pwr_cycle_delay.
>>
>> Once we do that it would be good (for e.g. suspend/resume speed) to fix:
>>
>> /*
>> * FIXME As we do with eDP, just make a note of the time here
>> * and perform the wait before the next panel power on.
>> */
>>
>> Which sits right above that msleep. Since I have a reproducer now which
>> shows when the sleep is too short, it should now be easy ti fix the FIXME
>> and test that the fix works. I'll do this in a separate patch and send
>> a patch-set with both patches replacing this patch.
>
> Awesome. I'm really happy to avoid any quirks and whatnot since
> they always come back to bite you later. Thanks for digging into it.
>
> Speaking of DSI, you wouldn't happen to have one these machines:
> https://gitlab.freedesktop.org/drm/intel/-/issues/2698 ?
Sorry I don't have any 10" Dell models in my collection.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 2/2] drm/doc: Add RFC section
On Tue, Mar 23, 2021 at 6:55 PM Jason Ekstrand wrote: > > On Tue, Mar 23, 2021 at 12:01 PM Simon Ser wrote: > > > > Side note: I feel like we could have better lines of communication > > between kernel devs and user-space devs. The new uAPI requirements seem > > to be a high barrier to entry for kernel devs. However sometimes > > user-space devs might be interested in helping out with the user-space > > part… > > > > Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that > > user-space devs can jump in if they're interested. And also provide > > feedback, since new uAPI is hard to spot in the sea of messages in > > dri-devel. > > That's a good suggestion. CCing wayland-dev or mesa-dev, as > appropriate, with such docs patches sounds like a good idea. I'm not > sure where we would put that in here but it would be good to call out. I'll add a suggestion to that extend, it's a good one. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/18] vfio/mdev: Remove kobj from mdev_parent_ops->create()
The kobj here is a type-erased version of mdev_type, which is already
stored in the struct mdev_device being passed in. It was only ever used to
compute the type_group_id, which is now extracted directly from the mdev.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
drivers/s390/cio/vfio_ccw_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/vfio/mdev/mdev_core.c | 2 +-
include/linux/mdev.h | 3 +--
samples/vfio-mdev/mbochs.c| 2 +-
samples/vfio-mdev/mdpy.c | 2 +-
samples/vfio-mdev/mtty.c | 2 +-
8 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 16e1e4a38aa1f6..6bf176e8426e63 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -689,7 +689,7 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(vdev->vfio_device);
}
-static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
+static int intel_vgpu_create(struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
struct intel_vgpu_type *type;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 68106be4ba7a19..06a82ec136080c 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -110,7 +110,7 @@ static struct attribute_group *mdev_type_groups[] = {
NULL,
};
-static int vfio_ccw_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+static int vfio_ccw_mdev_create(struct mdev_device *mdev)
{
struct vfio_ccw_private *private =
dev_get_drvdata(mdev_parent_dev(mdev));
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 41fc2e4135fe18..6d75ed07bcd49d 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -322,7 +322,7 @@ static void vfio_ap_matrix_init(struct ap_config_info *info,
matrix->adm_max = info->apxa ? info->Nd : 15;
}
-static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+static int vfio_ap_mdev_create(struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev;
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 3ba5e9464b4d20..71455812cb84cf 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -286,7 +286,7 @@ int mdev_device_create(struct mdev_type *type, const guid_t
*uuid)
goto mdev_fail;
}
- ret = parent->ops->create(>kobj, mdev);
+ ret = parent->ops->create(mdev);
if (ret)
goto ops_create_fail;
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 41e91936522394..c3a800051d6146 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -61,7 +61,6 @@ unsigned int mtype_get_type_group_id(struct kobject
*mtype_kobj);
* @create:Called to allocate basic resources in parent device's
* driver for a particular mediated device. It is
* mandatory to provide create ops.
- * @kobj: kobject of type for which 'create' is called.
* @mdev: mdev_device structure on of mediated device
* that is being created
* Returns integer: success (0) or error (< 0)
@@ -107,7 +106,7 @@ struct mdev_parent_ops {
const struct attribute_group **mdev_attr_groups;
struct attribute_group **supported_type_groups;
- int (*create)(struct kobject *kobj, struct mdev_device *mdev);
+ int (*create)(struct mdev_device *mdev);
int (*remove)(struct mdev_device *mdev);
int (*open)(struct mdev_device *mdev);
void(*release)(struct mdev_device *mdev);
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index a1af30df10a2ee..ac4d0dc2490705 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -506,7 +506,7 @@ static int mbochs_reset(struct mdev_device *mdev)
return 0;
}
-static int mbochs_create(struct kobject *kobj, struct mdev_device *mdev)
+static int mbochs_create(struct mdev_device *mdev)
{
const struct mbochs_type *type =
_types[mdev_get_type_group_id(mdev)];
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index 08c15f9f06a880..da88fd7dd42329 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -216,7 +216,7 @@ static int mdpy_reset(struct mdev_device *mdev)
return 0;
}
-static int mdpy_create(struct kobject *kobj, struct mdev_device *mdev)
+static int mdpy_create(struct mdev_device *mdev)
{
const struct mdpy_type *type =
_types[mdev_get_type_group_id(mdev)];
diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index 191a587a8d5ab1..f2e36c06ac6aa2 100644
--- a/samples/vfio-mdev/mtty.c
[Intel-gfx] [PATCH 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes
The driver core standard is to pass in the properly typed object, the
properly typed attribute and the buffer data. It stems from the root
kobject method:
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,..)
Each subclass of kobject should provide their own function with the same
signature but more specific types, eg struct device uses:
ssize_t (*show)(struct device *dev, struct device_attribute *attr,..)
In this case the existing signature is:
ssize_t (*show)(struct kobject *kobj, struct device *dev,..)
Where kobj is a 'struct mdev_type *' and dev is 'mdev_type->parent->dev'.
Change the mdev_type related sysfs attribute functions to:
ssize_t (*show)(struct mdev_type *mtype, struct mdev_type_attribute *attr,..)
In order to restore type safety and match the driver core standard
There are no current users of 'attr', but if it is ever needed it would be
hard to add in retroactively, so do it now.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c| 21 +++--
drivers/s390/cio/vfio_ccw_ops.c | 15 +--
drivers/s390/crypto/vfio_ap_ops.c | 12 +++-
drivers/vfio/mdev/mdev_core.c | 14 --
drivers/vfio/mdev/mdev_sysfs.c| 11 ++-
include/linux/mdev.h | 11 +++
samples/vfio-mdev/mbochs.c| 26 +++---
samples/vfio-mdev/mdpy.c | 24 ++--
samples/vfio-mdev/mtty.c | 18 +-
9 files changed, 90 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 4b47a18e9dfa0f..3703814a669b46 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -54,14 +54,15 @@ intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned
int type_group_id)
return >types[type_group_id];
}
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+ char *buf)
{
struct intel_vgpu_type *type;
unsigned int num = 0;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
num = 0;
else
@@ -70,19 +71,19 @@ static ssize_t available_instances_show(struct kobject
*kobj,
return sprintf(buf, "%u\n", num);
}
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_PCI_STRING);
}
-static ssize_t description_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t description_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
struct intel_vgpu_type *type;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
return 0;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 06a82ec136080c..74fe21eceb66cc 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -71,23 +71,26 @@ static int vfio_ccw_mdev_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
-static ssize_t name_show(struct kobject *kobj, struct device *dev, char *buf)
+static ssize_t name_show(struct mdev_type *mtype,
+struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "I/O subchannel (Non-QDIO)\n");
}
static MDEV_TYPE_ATTR_RO(name);
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_CCW_STRING);
}
static MDEV_TYPE_ATTR_RO(device_api);
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+ char *buf)
{
- struct vfio_ccw_private *private =
[Intel-gfx] [PATCH] i915_vma: Rename vma_lookup to i915_vma_lookup
Use i915 prefix to avoid name collision with future vma_lookup() in mm.
Signed-off-by: Liam R. Howlett
Reviewed-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index caa9b041616b..ee0028c697f6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -230,7 +230,7 @@ vma_create(struct drm_i915_gem_object *obj,
}
static struct i915_vma *
-vma_lookup(struct drm_i915_gem_object *obj,
+i915_vma_lookup(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
const struct i915_ggtt_view *view)
{
@@ -278,7 +278,7 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
GEM_BUG_ON(!atomic_read(>open));
spin_lock(>vma.lock);
- vma = vma_lookup(obj, vm, view);
+ vma = i915_vma_lookup(obj, vm, view);
spin_unlock(>vma.lock);
/* vma_create() will resolve the race if another creates the vma */
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/18] vfio/gvt: Use mdev_get_type_group_id()
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
supported_type_groups array, so the type_group_id is also the index into
gvt->types. Use it directly and remove the string matching.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c | 24 +++-
drivers/gpu/drm/i915/gvt/gvt.h | 4 ++--
drivers/gpu/drm/i915/gvt/kvmgt.c | 5 ++---
3 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index d1d8ee4a5f16a3..4b47a18e9dfa0f 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -46,22 +46,12 @@ static const char * const supported_hypervisors[] = {
[INTEL_GVT_HYPERVISOR_KVM] = "KVM",
};
-static struct intel_vgpu_type *intel_gvt_find_vgpu_type(struct intel_gvt *gvt,
- const char *name)
+static struct intel_vgpu_type *
+intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned int type_group_id)
{
- const char *driver_name =
- dev_driver_string(>gt->i915->drm.pdev->dev);
- int i;
-
- name += strlen(driver_name) + 1;
- for (i = 0; i < gvt->num_types; i++) {
- struct intel_vgpu_type *t = >types[i];
-
- if (!strncmp(t->name, name, sizeof(t->name)))
- return t;
- }
-
- return NULL;
+ if (WARN_ON(type_group_id >= gvt->num_types))
+ return NULL;
+ return >types[type_group_id];
}
static ssize_t available_instances_show(struct kobject *kobj,
@@ -71,7 +61,7 @@ static ssize_t available_instances_show(struct kobject *kobj,
unsigned int num = 0;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
num = 0;
else
@@ -92,7 +82,7 @@ static ssize_t description_show(struct kobject *kobj, struct
device *dev,
struct intel_vgpu_type *type;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
return 0;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 03c993d68f105a..0cf480f42850d2 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -569,8 +569,8 @@ struct intel_gvt_ops {
void (*vgpu_reset)(struct intel_vgpu *);
void (*vgpu_activate)(struct intel_vgpu *);
void (*vgpu_deactivate)(struct intel_vgpu *);
- struct intel_vgpu_type *(*gvt_find_vgpu_type)(struct intel_gvt *gvt,
- const char *name);
+ struct intel_vgpu_type *(*gvt_find_vgpu_type)(
+ struct intel_gvt *gvt, unsigned int type_group_id);
bool (*get_gvt_attrs)(struct attribute_group ***intel_vgpu_type_groups);
int (*vgpu_query_plane)(struct intel_vgpu *vgpu, void *);
int (*vgpu_get_dmabuf)(struct intel_vgpu *vgpu, unsigned int);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index b4348256ae9591..16e1e4a38aa1f6 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -700,10 +700,9 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
pdev = mdev_parent_dev(mdev);
gvt = kdev_to_i915(pdev)->gvt;
- type = intel_gvt_ops->gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_ops->gvt_find_vgpu_type(gvt,
+mdev_get_type_group_id(mdev));
if (!type) {
- gvt_vgpu_err("failed to find type %s to create\n",
- kobject_name(kobj));
ret = -EINVAL;
goto out;
}
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV
At some point there may have been some reason for this weird split in this driver, but today only the VFIO side is actually implemented. However, it got messed up at some point and mdev code was put in gvt.c and is pretending to be "generic" by masquerading as some generic attribute list: static MDEV_TYPE_ATTR_RO(description); But MDEV_TYPE attributes are only usable with mdev_device, nothing else. Ideally all of this would be moved to kvmgt.c, but it is entangled with the rest of the "generic" code in an odd way. Thus put in a kconfig dependency so we don't get randconfig failures when the next patch creates a link time dependency related to the use of MDEV_TYPE. Signed-off-by: Jason Gunthorpe --- drivers/gpu/drm/i915/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca778..483e9ff8ca1d23 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -101,6 +101,7 @@ config DRM_I915_GVT bool "Enable Intel GVT-g graphics virtualization host support" depends on DRM_I915 depends on 64BIT + depends on VFIO_MDEV default n help Choose this option if you want to enable Intel GVT-g graphics -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/18] Make vfio_mdev type safe
Prologue This is series #2 in part of a larger work that arose from the minor remark that the mdev_parent_ops indirection shim is useless and complicates things. It follows the "Embed struct vfio_device in all sub-structures" already sent, and must be applied on top of it. A preview of the future series's is here: https://github.com/jgunthorpe/linux/pull/3/commits This series: vfio_mdev has a number of different objects: mdev_parent, mdev_type and mdev_device. Unfortunately the types of these have been erased in various places throughout the API, and this makes it very hard to understand this code or maintain it by the time it reaches all of the drivers. This series puts in all the types and aligns some of the design with the driver core standard for a driver core bus driver: - Replace 'struct device *' with 'struct mdev_device * - Replace 'struct device *' with 'struct mdev_type *' and mtype_get_parent_dev() - Replace 'struct kobject *' with 'struct mdev_type *' Now that types are clear it is easy to spot a few places that have duplicated information. More significantly we can now understand how to directly fix the obfuscated 'kobj->name' matching by realizing the the kobj is a mdev_type, which is linked to the supported_types_list provided by the driver, and thus the core code can directly return the array indexes all the drivers actually want. Jason Jason Gunthorpe (18): vfio/mdev: Fix missing static's on MDEV_TYPE_ATTR's vfio/mdev: Add missing typesafety around mdev_device vfio/mdev: Simplify driver registration vfio/mdev: Use struct mdev_type in struct mdev_device vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer vfio/mdev: Expose mdev_get/put_parent to mdev_private.h vfio/mdev: Add missing reference counting to mdev_type vfio/mdev: Reorganize mdev_device_create() vfio/mdev: Add missing error handling to dev_set_name() vfio/mdev: Remove duplicate storage of parent in mdev_device vfio/mdev: Add mdev/mtype_get_type_group_id() vfio/mtty: Use mdev_get_type_group_id() vfio/mdpy: Use mdev_get_type_group_id() vfio/mbochs: Use mdev_get_type_group_id() vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV vfio/gvt: Use mdev_get_type_group_id() vfio/mdev: Remove kobj from mdev_parent_ops->create() vfio/mdev: Correct the function signatures for the mdev_type_attributes .../driver-api/vfio-mediated-device.rst | 9 +- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/gvt/gvt.c| 41 ++--- drivers/gpu/drm/i915/gvt/gvt.h| 4 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 7 +- drivers/s390/cio/vfio_ccw_ops.c | 17 +- drivers/s390/crypto/vfio_ap_ops.c | 14 +- drivers/vfio/mdev/mdev_core.c | 160 ++ drivers/vfio/mdev/mdev_driver.c | 19 +-- drivers/vfio/mdev/mdev_private.h | 40 ++--- drivers/vfio/mdev/mdev_sysfs.c| 59 --- drivers/vfio/mdev/vfio_mdev.c | 29 ++-- drivers/vfio/vfio_iommu_type1.c | 25 +-- include/linux/mdev.h | 80 ++--- samples/vfio-mdev/mbochs.c| 55 +++--- samples/vfio-mdev/mdpy.c | 56 +++--- samples/vfio-mdev/mtty.c | 66 ++-- 17 files changed, 306 insertions(+), 376 deletions(-) -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: add gem/gt TODO
On Tue, Mar 23, 2021 at 8:18 AM Daniel Vetter wrote: > > On Tue, Mar 23, 2021 at 08:34:55AM -0400, Rodrigo Vivi wrote: > > On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote: > > > On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote: > > > > On Tue, 23 Mar 2021, Daniel Vetter wrote: > > > > > We've discussed a bit how to get the gem/gt team better integrated > > > > > and collaborate more with the wider community and agreed to the > > > > > following: > > > > > > > > > > - all gem/gt patches are reviewed on dri-devel for now. That's > > > > > overkill, but in the past there was definitely too little of that. > > > > > > > > > > - i915-gem folks are encouraged to cross review core patches from > > > > > other teams > > > > > > > > > > - big features (especially uapi changes) need to be discussed in an > > > > > rfc patch that documents the interface and big picture design, > > > > > before we get lost in the details of the code > > > > > > > > > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back > > > > > on track, like we've e.g. done with DAL/DC to get that in shape. > > > > > > > > I personally think there should be a lower bar for discussing and > > > > editing the TODO items than via patches on the mailing list. Granted, > > > > the TODO file enforces the discussion happens at a large enough > > > > audience, but for at least some of the items I'd suggest filing gitlab > > > > issues [1], with todo label, and tracking there. > > > > I also don't like the todo list in files and I agree that gitlab issues > > section should be better... > > > > > In general yes, and I'd go even further: it's up to each team/contributor > > > how they track review feedback and further work, whether that's gitlab or > > > some notes or just in their heads. > > > > > > This is a different situation here, and the "changes require big audience" > > > is a feature, not a bug. But it is a very exceptional situation, I think > > > this is only the 2nd time we're using a formal TODO for a gpu driver. If > > > we ignore gma500 in staging, which for me only showed that the separate > > > staging tree doesn't work so well for complex drivers like we have. > > > > ... but I understand the motivation, so > > > > Acked-by: Rodrigo Vivi > > > > However... what about: > > > > 1. moving the smaller items to gitlab at least? > > 2. having both, all the entries in the todo file have gitlab issue > > associated and the number-id is also here in the todo file? > > Yeah that sounds reasonable. tbh we haven't started any of the > intel-internal planning on most of these (ttm and scheduler are started), > so none of these tracking things exist yet at all ... I'm a fan of this. GitLab issues provide a good place to organize the chatter on any particular ToDo item. I'd also rather see people chattering about this stuff on public GitLab than JIRA, when possible. The last patch in the series closing out a ToDo can be a patch to this file to remove the bullet point. --Jason > -Daniel > > > > > > -Daniel > > > > > > > > > > > BR, > > > > Jani. > > > > > > > > > > > > [1] https://gitlab.freedesktop.org/drm/intel/-/issues > > > > > > > > > > > > > > > > > > > > > > Cc: Jani Nikula > > > > > Cc: Joonas Lahtinen > > > > > Cc: Rodrigo Vivi > > > > > Cc: Jason Ekstrand > > > > > Cc: Dave Airlie > > > > > Signed-off-by: Daniel Vetter > > > > > --- > > > > > drivers/gpu/drm/i915/TODO.txt | 36 > > > > > +++ > > > > > 1 file changed, 36 insertions(+) > > > > > create mode 100644 drivers/gpu/drm/i915/TODO.txt > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/TODO.txt > > > > > b/drivers/gpu/drm/i915/TODO.txt > > > > > new file mode 100644 > > > > > index ..d2e5bbb6339d > > > > > --- /dev/null > > > > > +++ b/drivers/gpu/drm/i915/TODO.txt > > > > > @@ -0,0 +1,36 @@ > > > > > +gem/gt TODO items > > > > > +- > > > > > + > > > > > +- For discrete memory manager, merge enough dg1 to be able to > > > > > refactor it to > > > > > + TTM. Then land pci ids (just in case that turns up an uapi > > > > > problem). TTM has > > > > > + improved a lot the past 2 years, there's no reason anymore not to > > > > > use it. > > > > > + > > > > > +- Come up with a plan what to do with drm/scheduler and how to get > > > > > there. > > > > > + > > > > > +- There's a lot of complexity added past few years to make > > > > > relocations faster. > > > > > + That doesn't make sense given hw and gpu apis moved away from this > > > > > model years > > > > > + ago: > > > > > + 1. Land a modern pre-bound uapi like VM_BIND > > > > > + 2. Any complexity added in this area past few years which can't be > > > > > justified > > > > > + with VM_BIND using userspace should be removed. Looking at amdgpu > > > > > dma_resv on > > > > > + the bo and vm, plus some lru locks is all that needed. No complex > > > > > rcu, > > > > > + refcounts, caching, ...
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915/display: Simplify GLK display version tests
On Tue, Mar 23, 2021 at 07:40:58PM +0200, Ville Syrjälä wrote: > On Tue, Mar 23, 2021 at 10:27:34AM -0700, Matt Roper wrote: > > On Tue, Mar 23, 2021 at 07:25:57PM +0200, Ville Syrjälä wrote: > > > On Mon, Mar 22, 2021 at 04:38:40PM -0700, Matt Roper wrote: > > > > GLK has always been a bit of a special case since it reports INTEL_GEN() > > > > as 9, but has version 10 display IP. Now we can properly represent the > > > > display version as 10 and simplify the display generation tests > > > > throughout the display code. > > > > > > > > Aside from manually adding the version to the glk_info structure, the > > > > rest of this patch is generated with a Coccinelle semantic patch. Note > > > > that we also need to switch any code that matches gen10 today but *not* > > > > GLK to be CNL-specific: > > > > > > > > @@ expression dev_priv; @@ > > > > - DISPLAY_VER(dev_priv) > 9 > > > > + DISPLAY_VER(dev_priv) >= 10 > > > > > > > > @@ expression dev_priv, E; @@ > > > > ( > > > > - DISPLAY_VER(dev_priv) >= 10 && E > > > > + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E > > > > | > > > > - DISPLAY_VER(dev_priv) >= 10 > > > > + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) > > > > | > > > > - IS_DISPLAY_RANGE(dev_priv, 10, E) > > > > + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) > > > > ) > > > > > > > > @@ expression dev_priv, E, E2; @@ > > > > ( > > > > - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) > > > > + IS_DISPLAY_VER(dev_priv, 10) > > > > | > > > > - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) > > > > + E || IS_DISPLAY_VER(dev_priv, 10) > > > > | > > > > - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) > > > > + IS_DISPLAY_VER(dev_priv, 10) > > > > | > > > > - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) > > > > + E || IS_DISPLAY_VER(dev_priv, 10) > > > > | > > > > - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) > > > > + E || E2 || IS_DISPLAY_VER(dev_priv, 10) > > > > | > > > > - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) > > > > + IS_DISPLAY_VER(dev_priv, 10) > > > > | > > > > - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) > > > > + IS_DISPLAY_VER(dev_priv, 10) > > > > ) > > > > > > > > @@ expression dev_priv; @@ > > > > - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) > > > > + IS_DISPLAY_VER(dev_priv, 9) > > > > > > > > @@ expression dev_priv; @@ > > > > ( > > > > - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > > > > + DISPLAY_VER(dev_priv) < 10 > > > > | > > > > - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > > > > + DISPLAY_VER(dev_priv) >= 10 > > > > ) > > > > > > > > @@ expression dev_priv, E; @@ > > > > - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, > > > > 10) > > > > + E || DISPLAY_VER(dev_priv) >= 10 > > > > > > > > @@ expression dev_priv, E; @@ > > > > - (IS_DISPLAY_RANGE(dev_priv, 11, E) || > > > > IS_DISPLAY_VER(dev_priv, 10)) > > > > + IS_DISPLAY_RANGE(dev_priv, 10, E) > > > > > > > > @@ expression dev_priv; @@ > > > > ( > > > > - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || > > > > IS_GEN9_LP(dev_priv) > > > > + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) > > > > | > > > > - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || > > > > IS_CANNONLAKE(dev_priv) > > > > + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 > > > > ) > > > > > > > > @@ expression dev_priv, E; @@ > > > > - !(DISPLAY_VER(dev_priv) >= E) > > > > + DISPLAY_VER(dev_priv) < E > > > > > > > > v2: > > > > - Convert gen10 conditions that don't include GLK into CNL conditions. > > > >(Ville) > > > > > > > > v3: > > > > - Rework coccinelle rules so that "ver>=10" turns into > > > > "ver>=11||is_cnl." (Ville) > > > > > > > > v3.1: > > > > - Manually re-add the ".display.version = 10" to glk_info after > > > >regenerating patch via Coccinelle. > > > > > > > > v4: > > > > - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) > > > > > > Ugh. One thing that occurred to me when looking at i915_irq.c is that > > > IS_GEN9_LP() is now maybe broken on glk? So seems to me all uses of > > > IS_GEN9_LP() need to be reviewed and potentially changed. > > > > Broken how? That macro still uses the gen/gt version instead of the > > display number, so I think it still behaves the same as before? > > Oh you're not changng it to to use display ver? I guess it still kinda > works
Re: [Intel-gfx] [PATCH 2/2] drm/doc: Add RFC section
On Tue, Mar 23, 2021 at 12:01 PM Simon Ser wrote: > > Side note: I feel like we could have better lines of communication > between kernel devs and user-space devs. The new uAPI requirements seem > to be a high barrier to entry for kernel devs. However sometimes > user-space devs might be interested in helping out with the user-space > part… > > Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that > user-space devs can jump in if they're interested. And also provide > feedback, since new uAPI is hard to spot in the sea of messages in > dri-devel. That's a good suggestion. CCing wayland-dev or mesa-dev, as appropriate, with such docs patches sounds like a good idea. I'm not sure where we would put that in here but it would be good to call out. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature. i965
was already in maintenance mode at the time and iris uses syncobj for
everything.
Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that. We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally. This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads. It won't crash in that case; it just doesn't guarantee any
ordering between those two submits.
Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance. One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make scheduler changes going
forward. Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline which may help us reduce locking.
v2 (Jason Ekstrand):
- Update the comment on i915_gem_context::syncobj to mention that it's
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 47 ---
.../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 16 +++
3 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f88bac19333ec..e094f4a1ca4cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -67,6 +67,8 @@
#include
#include
+#include
+
#include "gt/gen6_ppgtt.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_heartbeat.h"
@@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->vm = vm;
}
- GEM_BUG_ON(ce->timeline);
- if (ctx->timeline)
- ce->timeline = intel_timeline_get(ctx->timeline);
-
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
@@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
- if (ctx->timeline)
- intel_timeline_put(ctx->timeline);
+ if (ctx->syncobj)
+ drm_syncobj_put(ctx->syncobj);
put_pid(ctx->pid);
mutex_destroy(>mutex);
@@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
i915_vm_close(vm);
}
-static void __set_timeline(struct intel_timeline **dst,
- struct intel_timeline *src)
-{
- struct intel_timeline *old = *dst;
-
- *dst = src ? intel_timeline_get(src) : NULL;
-
- if (old)
- intel_timeline_put(old);
-}
-
-static void __apply_timeline(struct intel_context *ce, void *timeline)
-{
- __set_timeline(>timeline, timeline);
-}
-
-static void __assign_timeline(struct i915_gem_context *ctx,
- struct intel_timeline *timeline)
-{
- __set_timeline(>timeline, timeline);
- context_apply_all(ctx, __apply_timeline, timeline);
-}
-
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
struct i915_gem_context *ctx;
+ int ret;
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
!HAS_EXECLISTS(i915))
@@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
}
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
- struct intel_timeline *timeline;
-
- timeline = intel_timeline_create(>gt);
- if (IS_ERR(timeline)) {
+ ret = drm_syncobj_create(>syncobj,
+DRM_SYNCOBJ_CREATE_SIGNALED,
+NULL);
+ if (ret) {
context_close(ctx);
- return ERR_CAST(timeline);
+ return ERR_PTR(ret);
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
On Tue, Mar 23, 2021 at 06:29:53PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/22/21 10:47 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> >>> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 3/1/21 4:43 PM, Hans de Goede wrote:
> >> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> >> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> >> Predia Basic tablet would no longer properly light up after reboot.
> >>
> >> The backlight still turns back on after reboot, but the LCD shows an
> >> all black display. The display is also all black during the time that
> >> EFI / the GOP is managing it, so e.g. the grub menu also is not
> >> visible.
> >>
> >> In this scenario the panel is initialized so that it appears to be
> >> working
> >> and the fastboot code skips doing a modeset. Forcing a modeset by
> >> doing a
> >> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> >> /sys/class/graphics/fb0/blank causes the panel to work again.
> >>
> >> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> >> a no-op when set; and set this on vlv/chv devices when a DSI panel is
> >> detected, to work around this.
> >>
> >> Admittedly this is a bit of a big hammer, but these platforms have been
> >> around for quite some time now and they have always worked fine without
> >> the new behavior to shutdown everything on shutdown/reboot. This
> >> approach
> >> simply disables the recently introduced new shutdown behavior in this
> >> specific case where it is known to cause problems. Which is a nice and
> >> simple way to deal with this.
> >>
> >> Signed-off-by: Hans de Goede
> >
> > Ping? Since sending this patch I've been seeing the issue addressed by
> > this on variour other CHT based devices too.
> >
> > So we have various devices suffering from a black screen after reboot
> > now. This is pretty serious usability regression.
> >
> > As such it would be good to get this reviewed, or another fix proposed.
>
> For the quirks we try to limit them to very specific vendor and model
> ids,
> so I wonder if it would be possible to get this information in here
> instead
> to all the vlv with dsi...
>
> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>
> Jani?
> Ville?
> >>>
> >>> We need to figure out why the panel doesn't start up again.
> >>
> >> Note it is the GOP which fails to light it up again. I think we turn
> >> something
> >> off, which after a power-on-reset is on, so the GOP expects it to be on.
> >
> > Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
> > Are there any fast vs. slow boot settings in the BIOS setup?
>
> Ok, so I was running the tests which you requested and during this
> I managed to find the real problem.
>
> What happens on reboot is a really quick panel off/on cycle and that is
> causing the issue.
>
> I can reproduce this by doing:
>
> chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
> /sys/class/graphics/fb0/blank
>
> The problem is that we're not honoring panel_pwr_cycle_delay because
> intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
> because those sequences already contain the necessary delays, at least
> for most of the steps during the on/off sequences. It seems that the
> pwr-cycle delay is not handled by those v3+ sequences.
>
> So fixing this is as simple as switching to a regular msleep for the
> intel_dsi->panel_pwr_cycle_delay.
>
> Once we do that it would be good (for e.g. suspend/resume speed) to fix:
>
> /*
> * FIXME As we do with eDP, just make a note of the time here
> * and perform the wait before the next panel power on.
> */
>
> Which sits right above that msleep. Since I have a reproducer now which
> shows when the sleep is too short, it should now be easy ti fix the FIXME
> and test that the fix works. I'll do this in a separate patch and send
> a patch-set with both patches replacing this patch.
Awesome. I'm really happy to avoid any quirks and whatnot since
they always come back to bite you later. Thanks for digging into it.
Speaking of DSI, you wouldn't happen to have one these machines:
https://gitlab.freedesktop.org/drm/intel/-/issues/2698 ? Haven't gotten
a response from the bug reporter so no idea if my quick patch helps or
not.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API
On Tue, Mar 23, 2021 at 11:23 AM Tvrtko Ursulin wrote: > > > On 23/03/2021 13:23, Daniel Vetter wrote: > > On Tue, Mar 23, 2021 at 09:14:36AM +, Tvrtko Ursulin wrote: > >> > >> On 22/03/2021 16:43, Daniel Vetter wrote: > >>> On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin > >>> wrote: > > > On 22/03/2021 14:57, Daniel Vetter wrote: > > On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin > > wrote: > >> > >> > >> On 22/03/2021 14:09, Daniel Vetter wrote: > >>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote: > > On 19/03/2021 22:38, Jason Ekstrand wrote: > > This API allows one context to grab bits out of another context upon > > creation. It can be used as a short-cut for setparam(getparam()) > > for > > things like I915_CONTEXT_PARAM_VM. However, it's never been used > > by any > > real userspace. It's used by a few IGT tests and that's it. Since > > it > > doesn't add any real value (most of the stuff you can CLONE you can > > copy > > in other ways), drop it. > > No complaints to remove if it ended up unused outside IGT. Latter is > a _big_ > problem though, since it is much more that a few IGT tests. So I > really > think there really needs to be an evaluation and a plan for that (we > don't > want to lose 50% of the coverage over night). > > > There is one thing that this API allows you to clone which you > > cannot > > clone via getparam/setparam: timelines. However, timelines are an > > implementation detail of i915 and not really something that needs > > to be > > Not really true timelines are i915 implementation detail. They are > in fact a > dma-fence context:seqno concept, nothing more that than. I think you > are > probably confusing struct intel_timeline with the timeline wording > in the > uapi. Former is i915 implementation detail, but context:seqno are > truly > userspace timelines. > >>> > >>> I think you're both saying the same thing and talking a bit past each > >>> another. > >>> > >>> Yes the timeline is just a string of dma_fence, that's correct. Now > >>> usually if you submit batches with execbuf, we have 3 ways to > >>> synchronize > >>> concurrent submission: implicit sync, sync_file and drm_syncob. They > >>> all > >>> map to different needs in different protocols/render apis. > >>> > >>> Now in one additional case the kernel makes sure that batchbuffers are > >>> ordered, and that's when you submit them to the same hw ctx. Because > >>> there's only 1 hw context and you really can't have batchbuffers run > >>> on > >>> that single hw context out of order. That's what the timeline object > >>> we > >>> talk about here is. But that largely is an internal implementation > >>> detail, > >>> which happens to also use most/all the same infrastructure as the > >>> dma_fence uapi pieces above. > >>> > >>> Now the internal implementation detail leaking here is that we exposed > >>> this to userspace, without there being any need for this. What Jason > >>> implements with syncobj in the next patch is essentially what > >>> userspace > >>> should have been using for cross-engine sync. media userspace doesn't > >>> care > >>> about interop with winsys/client apis, so they equally could have used > >>> implicit sync or sync_file here (which I think is the solution now > >>> for the > >>> new uapi prepped internally), since they all are about equally > >>> powerful > >>> for stringing batchbuffers together. > >> > >> Are you saying we exposed a single timeline of execution per hw context > >> via the single timeline flag?! > > > > Nope. > > > >> Timelines of execution were always exposed. Any "engine" (ring > >> previously) in I915_EXEC_RING_MASK was a single timeline of execution. > >> It is completely the same with engine map engines, which are also > >> different indices into I915_EXEC_RING_MASK space. > >> > >> Userspace was aware of these timelines forever as well. Media was > >> creating multiple contexts to have multiple timelines (so parallelism). > >> Everyone knew that engine-hopping submissions needs to be either > >> implicitly or explicitly synchronised, etc. > > > > Yup, I think we're saying the same thing here. > > > >> So I really don't see that we have leaked timelines as a concept *now*. > >> What the patch has exposed to userspace is a new way to sync between > >> timelines and nothing more. > > > > We've leaked it as something you can now share across hw context. >
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj
On Tue, Mar 23, 2021 at 4:35 AM Tvrtko Ursulin
wrote:
>
>
> On 22/03/2021 16:10, Jason Ekstrand wrote:
> > On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
>
> [snip]
>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> index 96403130a373d..2c56796f6a71b 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> @@ -3295,6 +3295,15 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >>>goto err_vma;
> >>>}
> >>>
> >>> + if (eb.gem_context->syncobj) {
> >>> + struct dma_fence *fence;
> >>> +
> >>> + fence = drm_syncobj_fence_get(eb.gem_context->syncobj);
> >>
> >> Who drops this reference?
> >
> > i915_request_await_dma_fence() below consumes a reference.
>
> Not sure, please check on difference wrt input fence handling.
Gah. You were right. It takes a reference if it needs one. I
thought I was being symmetric with the other syncobj usage but it was
well hidden inside our confusing tear-down paths.
> >>> + err = i915_request_await_dma_fence(eb.request, fence);
> >>> + if (err)
> >>> + goto err_ext;
> >>> + }
> >>> +
> >>>if (in_fence) {
> >>>if (args->flags & I915_EXEC_FENCE_SUBMIT)
> >>>err = i915_request_await_execution(eb.request,
> >>> @@ -3351,6 +3360,12 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >>>fput(out_fence->file);
> >>>}
> >>>}
> >>> +
> >>> + if (eb.gem_context->syncobj) {
At Daniel's request, I've wrapped these in unlikely()
> >>> + drm_syncobj_replace_fence(eb.gem_context->syncobj,
> >>> + >fence);
> >>> + }
> >>> +
> >>>i915_request_put(eb.request);
> >>>
> >>>err_vma:
> >>>
> >>
> >> So essentially moving the synchronisation to top level which is extra
> >> work, but given limited and questionable usage of the uapi may be
> >> acceptable. Need full picture on motivation to understand.
> >
> > For one thing, the GuC scheduler doesn't natively have a concept of
> > "timelines" which can be shared like this. To work with the GuC
>
> Confused - neither does execlists. It is handled in common layer in
> i915. GuC scheduler has the same concept of one hw context is one
> timeline because that is the hw concept and not backend specific.
>
> > scheduler as currently proposed in DII, they've asked the media driver
> > to stop using this flag in favor of passing a sync file from batch to
> > batch. If we want to slide GuC scheduling in smoothly, we've got to
> > keep it working. This means either making timelines a concept there
> > or doing an emulation like this.
>
> Hm not aware and don't see that GuC backend can't or doesn't implement
> this. Perhaps this would be best discussed once GuC patches are posted.
>
> >> Semantics are also not 1:1 since dma fence context will be different.
> >
> > Could you elaborate?
>
> Exported dma fence context as an "timeline" id will be single with the
> current patch and multiple contexts with this implementation.
>
> Daniel also raised another difference caused by lack of serialisation
> due multiple tl->mutex here.
>
> I don't think this is important, it was never part of a contract what
> happens with racing execbufs, but it is definitely required covering
> both topics in the commit message.
I've updated the commit message as follows:
drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature. i965
was already in maintenance mode at the time and iris uses syncobj for
everything.
Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that. We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally. This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads. It won't crash in that case; it just doesn't guarantee any
ordering between those two submits.
Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance. One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Warn when display irq functions are called without display
== Series Details == Series: series starting with [1/3] drm/i915: Warn when display irq functions are called without display URL : https://patchwork.freedesktop.org/series/88294/ State : success == Summary == CI Bug Log - changes from CI_DRM_9880_full -> Patchwork_19829_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19829_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-glk4/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/shard-tglb2/igt@gem_exec_fair@basic-p...@vecs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2849]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-skl: NOTRUN -> [TIMEOUT][10] ([i915#3183]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-skl10/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_schedule@u-fairslice-all: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1610] / [i915#2803]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/shard-skl9/igt@gem_exec_sched...@u-fairslice-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-skl1/igt@gem_exec_sched...@u-fairslice-all.html * igt@gem_exec_whisper@basic-queues-all: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/shard-glk8/igt@gem_exec_whis...@basic-queues-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-glk1/igt@gem_exec_whis...@basic-queues-all.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-skl6/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy: - shard-skl: [PASS][16] -> [FAIL][17] ([i915#307]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/shard-skl8/igt@gem_mmap_...@big-copy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-skl7/igt@gem_mmap_...@big-copy.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-skl6/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][19] ([i915#3002]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-apl3/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@process-exit-mmap@wb: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1699]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-skl6/igt@gem_userptr_blits@process-exit-m...@wb.html * igt@gem_userptr_blits@vma-merge: - shard-snb: NOTRUN -> [FAIL][21] ([i915#2724]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-snb7/igt@gem_userptr_bl...@vma-merge.html * igt@gen7_exec_parse@basic-offset: - shard-apl: NOTRUN -> [SKIP][22] ([fdo#109271]) +205 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/shard-apl7/igt@gen7_exec_pa...@basic-offset.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: NOTRUN -> [DMESG-WARN][23] ([i915#180]) [23]:
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915/display: Simplify GLK display version tests
On Tue, Mar 23, 2021 at 10:27:34AM -0700, Matt Roper wrote: > On Tue, Mar 23, 2021 at 07:25:57PM +0200, Ville Syrjälä wrote: > > On Mon, Mar 22, 2021 at 04:38:40PM -0700, Matt Roper wrote: > > > GLK has always been a bit of a special case since it reports INTEL_GEN() > > > as 9, but has version 10 display IP. Now we can properly represent the > > > display version as 10 and simplify the display generation tests > > > throughout the display code. > > > > > > Aside from manually adding the version to the glk_info structure, the > > > rest of this patch is generated with a Coccinelle semantic patch. Note > > > that we also need to switch any code that matches gen10 today but *not* > > > GLK to be CNL-specific: > > > > > > @@ expression dev_priv; @@ > > > - DISPLAY_VER(dev_priv) > 9 > > > + DISPLAY_VER(dev_priv) >= 10 > > > > > > @@ expression dev_priv, E; @@ > > > ( > > > - DISPLAY_VER(dev_priv) >= 10 && E > > > + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E > > > | > > > - DISPLAY_VER(dev_priv) >= 10 > > > + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) > > > | > > > - IS_DISPLAY_RANGE(dev_priv, 10, E) > > > + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) > > > ) > > > > > > @@ expression dev_priv, E, E2; @@ > > > ( > > > - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) > > > + IS_DISPLAY_VER(dev_priv, 10) > > > | > > > - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) > > > + E || IS_DISPLAY_VER(dev_priv, 10) > > > | > > > - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) > > > + IS_DISPLAY_VER(dev_priv, 10) > > > | > > > - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) > > > + E || IS_DISPLAY_VER(dev_priv, 10) > > > | > > > - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) > > > + E || E2 || IS_DISPLAY_VER(dev_priv, 10) > > > | > > > - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) > > > + IS_DISPLAY_VER(dev_priv, 10) > > > | > > > - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) > > > + IS_DISPLAY_VER(dev_priv, 10) > > > ) > > > > > > @@ expression dev_priv; @@ > > > - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) > > > + IS_DISPLAY_VER(dev_priv, 9) > > > > > > @@ expression dev_priv; @@ > > > ( > > > - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > > > + DISPLAY_VER(dev_priv) < 10 > > > | > > > - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > > > + DISPLAY_VER(dev_priv) >= 10 > > > ) > > > > > > @@ expression dev_priv, E; @@ > > > - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) > > > + E || DISPLAY_VER(dev_priv) >= 10 > > > > > > @@ expression dev_priv, E; @@ > > > - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, > > > 10)) > > > + IS_DISPLAY_RANGE(dev_priv, 10, E) > > > > > > @@ expression dev_priv; @@ > > > ( > > > - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || > > > IS_GEN9_LP(dev_priv) > > > + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) > > > | > > > - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || > > > IS_CANNONLAKE(dev_priv) > > > + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 > > > ) > > > > > > @@ expression dev_priv, E; @@ > > > - !(DISPLAY_VER(dev_priv) >= E) > > > + DISPLAY_VER(dev_priv) < E > > > > > > v2: > > > - Convert gen10 conditions that don't include GLK into CNL conditions. > > >(Ville) > > > > > > v3: > > > - Rework coccinelle rules so that "ver>=10" turns into > > > "ver>=11||is_cnl." (Ville) > > > > > > v3.1: > > > - Manually re-add the ".display.version = 10" to glk_info after > > >regenerating patch via Coccinelle. > > > > > > v4: > > > - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) > > > > Ugh. One thing that occurred to me when looking at i915_irq.c is that > > IS_GEN9_LP() is now maybe broken on glk? So seems to me all uses of > > IS_GEN9_LP() need to be reviewed and potentially changed. > > Broken how? That macro still uses the gen/gt version instead of the > display number, so I think it still behaves the same as before? Oh you're not changng it to to use display ver? I guess it still kinda works then. But it's going to be pretty confusing to use that for display stuff now. Ie. we should probably stop using it. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 68/70] drm/i915: Pass ww ctx to pin_map
On Tue, 23 Mar 2021 at 15:51, Maarten Lankhorst
wrote:
>
> This will allow us to explicitly pass the ww to pin_pages,
> when it starts taking it.
>
> This allows us to finally kill off the explicit passing of ww
> by retrieving it from the obj.
>
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 7 ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 +
> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 4 ++--
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +++
> .../drm/i915/gem/selftests/i915_gem_context.c | 8 ---
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
> .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_timeline.c | 7 ---
> drivers/gpu/drm/i915/gt/intel_timeline.h | 3 ++-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/gt/mock_engine.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
> drivers/gpu/drm/i915/gt/selftest_rps.c| 10 -
> .../gpu/drm/i915/gt/selftest_workarounds.c| 6 +++---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 ++--
> drivers/gpu/drm/i915/i915_perf.c | 4 ++--
> drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
> 24 files changed, 60 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index dcfcae9c841b..73dd2a7673f5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1340,7 +1340,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
> if (err)
> goto err_pool;
>
> - cmd = i915_gem_object_pin_map(pool->obj, pool->type);
> + cmd = i915_gem_object_pin_map(pool->obj, >ww, pool->type);
> if (IS_ERR(cmd)) {
> err = PTR_ERR(cmd);
> goto err_pool;
> @@ -2489,7 +2489,8 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
> goto err_shadow;
> }
>
> - pw->shadow_map = i915_gem_object_pin_map(shadow->obj, I915_MAP_WB);
> + pw->shadow_map = i915_gem_object_pin_map(shadow->obj, >ww,
> +I915_MAP_WB);
> if (IS_ERR(pw->shadow_map)) {
> err = PTR_ERR(pw->shadow_map);
> goto err_trampoline;
> @@ -2500,7 +2501,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
>
> pw->batch_map = ERR_PTR(-ENODEV);
> if (needs_clflush && i915_has_memcpy_from_wc())
> - pw->batch_map = i915_gem_object_pin_map(batch, I915_MAP_WC);
> + pw->batch_map = i915_gem_object_pin_map(batch, >ww,
> I915_MAP_WC);
>
> if (IS_ERR(pw->batch_map)) {
> err = i915_gem_object_pin_pages(batch);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 2561a2f1e54f..edac8ee3be9a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -439,7 +439,7 @@ vm_access(struct vm_area_struct *area, unsigned long addr,
> goto out;
>
> /* As this is primarily for debugging, let's focus on simplicity */
> - vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
> + vaddr = i915_gem_object_pin_map(obj, , I915_MAP_FORCE_WC);
> if (IS_ERR(vaddr)) {
> err = PTR_ERR(vaddr);
> goto out;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 1a8ec4035112..9bd9b47dcc8d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -450,6 +450,7 @@ void i915_gem_object_writeback(struct drm_i915_gem_object
> *obj);
> * ERR_PTR() on error.
> */
> void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
> + struct i915_gem_ww_ctx *ww,
>enum i915_map_type type);
>
> void *__must_check i915_gem_object_pin_map_unlocked(struct
> drm_i915_gem_object *obj,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> index df8e8c18c6c9..fae18622d2da 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> @@ -58,7 +58,7 @@ struct i915_vma
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
Hi,
On 3/22/21 10:47 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
>>> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/1/21 4:43 PM, Hans de Goede wrote:
>> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
>> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
>> Predia Basic tablet would no longer properly light up after reboot.
>>
>> The backlight still turns back on after reboot, but the LCD shows an
>> all black display. The display is also all black during the time that
>> EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
>>
>> In this scenario the panel is initialized so that it appears to be
>> working
>> and the fastboot code skips doing a modeset. Forcing a modeset by doing a
>> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
>> /sys/class/graphics/fb0/blank causes the panel to work again.
>>
>> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
>> a no-op when set; and set this on vlv/chv devices when a DSI panel is
>> detected, to work around this.
>>
>> Admittedly this is a bit of a big hammer, but these platforms have been
>> around for quite some time now and they have always worked fine without
>> the new behavior to shutdown everything on shutdown/reboot. This approach
>> simply disables the recently introduced new shutdown behavior in this
>> specific case where it is known to cause problems. Which is a nice and
>> simple way to deal with this.
>>
>> Signed-off-by: Hans de Goede
>
> Ping? Since sending this patch I've been seeing the issue addressed by
> this on variour other CHT based devices too.
>
> So we have various devices suffering from a black screen after reboot
> now. This is pretty serious usability regression.
>
> As such it would be good to get this reviewed, or another fix proposed.
For the quirks we try to limit them to very specific vendor and model ids,
so I wonder if it would be possible to get this information in here instead
to all the vlv with dsi...
Or avoid the quirk "infra" and skip to all vlv with active dsi?!
Jani?
Ville?
>>>
>>> We need to figure out why the panel doesn't start up again.
>>
>> Note it is the GOP which fails to light it up again. I think we turn
>> something
>> off, which after a power-on-reset is on, so the GOP expects it to be on.
>
> Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
> Are there any fast vs. slow boot settings in the BIOS setup?
Ok, so I was running the tests which you requested and during this
I managed to find the real problem.
What happens on reboot is a really quick panel off/on cycle and that is
causing the issue.
I can reproduce this by doing:
chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
/sys/class/graphics/fb0/blank
The problem is that we're not honoring panel_pwr_cycle_delay because
intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
because those sequences already contain the necessary delays, at least
for most of the steps during the on/off sequences. It seems that the
pwr-cycle delay is not handled by those v3+ sequences.
So fixing this is as simple as switching to a regular msleep for the
intel_dsi->panel_pwr_cycle_delay.
Once we do that it would be good (for e.g. suspend/resume speed) to fix:
/*
* FIXME As we do with eDP, just make a note of the time here
* and perform the wait before the next panel power on.
*/
Which sits right above that msleep. Since I have a reproducer now which
shows when the sleep is too short, it should now be easy ti fix the FIXME
and test that the fix works. I'll do this in a separate patch and send
a patch-set with both patches replacing this patch.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915/display: Simplify GLK display version tests
On Tue, Mar 23, 2021 at 07:25:57PM +0200, Ville Syrjälä wrote: > On Mon, Mar 22, 2021 at 04:38:40PM -0700, Matt Roper wrote: > > GLK has always been a bit of a special case since it reports INTEL_GEN() > > as 9, but has version 10 display IP. Now we can properly represent the > > display version as 10 and simplify the display generation tests > > throughout the display code. > > > > Aside from manually adding the version to the glk_info structure, the > > rest of this patch is generated with a Coccinelle semantic patch. Note > > that we also need to switch any code that matches gen10 today but *not* > > GLK to be CNL-specific: > > > > @@ expression dev_priv; @@ > > - DISPLAY_VER(dev_priv) > 9 > > + DISPLAY_VER(dev_priv) >= 10 > > > > @@ expression dev_priv, E; @@ > > ( > > - DISPLAY_VER(dev_priv) >= 10 && E > > + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E > > | > > - DISPLAY_VER(dev_priv) >= 10 > > + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) > > | > > - IS_DISPLAY_RANGE(dev_priv, 10, E) > > + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) > > ) > > > > @@ expression dev_priv, E, E2; @@ > > ( > > - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) > > + IS_DISPLAY_VER(dev_priv, 10) > > | > > - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) > > + E || IS_DISPLAY_VER(dev_priv, 10) > > | > > - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) > > + IS_DISPLAY_VER(dev_priv, 10) > > | > > - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) > > + E || IS_DISPLAY_VER(dev_priv, 10) > > | > > - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) > > + E || E2 || IS_DISPLAY_VER(dev_priv, 10) > > | > > - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) > > + IS_DISPLAY_VER(dev_priv, 10) > > | > > - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) > > + IS_DISPLAY_VER(dev_priv, 10) > > ) > > > > @@ expression dev_priv; @@ > > - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) > > + IS_DISPLAY_VER(dev_priv, 9) > > > > @@ expression dev_priv; @@ > > ( > > - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > > + DISPLAY_VER(dev_priv) < 10 > > | > > - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > > + DISPLAY_VER(dev_priv) >= 10 > > ) > > > > @@ expression dev_priv, E; @@ > > - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) > > + E || DISPLAY_VER(dev_priv) >= 10 > > > > @@ expression dev_priv, E; @@ > > - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, > > 10)) > > + IS_DISPLAY_RANGE(dev_priv, 10, E) > > > > @@ expression dev_priv; @@ > > ( > > - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || > > IS_GEN9_LP(dev_priv) > > + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) > > | > > - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || > > IS_CANNONLAKE(dev_priv) > > + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 > > ) > > > > @@ expression dev_priv, E; @@ > > - !(DISPLAY_VER(dev_priv) >= E) > > + DISPLAY_VER(dev_priv) < E > > > > v2: > > - Convert gen10 conditions that don't include GLK into CNL conditions. > >(Ville) > > > > v3: > > - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." > > (Ville) > > > > v3.1: > > - Manually re-add the ".display.version = 10" to glk_info after > >regenerating patch via Coccinelle. > > > > v4: > > - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) > > Ugh. One thing that occurred to me when looking at i915_irq.c is that > IS_GEN9_LP() is now maybe broken on glk? So seems to me all uses of > IS_GEN9_LP() need to be reviewed and potentially changed. Broken how? That macro still uses the gen/gt version instead of the display number, so I think it still behaves the same as before? Matt > > > > > Cc: Ville Syrjälä > > Signed-off-by: Matt Roper > > Reviewed-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/display/intel_atomic.c | 7 ++-- > > drivers/gpu/drm/i915/display/intel_audio.c| 2 +- > > drivers/gpu/drm/i915/display/intel_bios.c | 3 +- > > drivers/gpu/drm/i915/display/intel_cdclk.c| 26 +++-- > > drivers/gpu/drm/i915/display/intel_color.c| 8 ++-- > > drivers/gpu/drm/i915/display/intel_crtc.c | 2 +- > > drivers/gpu/drm/i915/display/intel_display.c | 9 ++--- > > .../drm/i915/display/intel_display_debugfs.c | 5 +-- > > .../drm/i915/display/intel_display_power.c| 2 +- >
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915/display: Simplify GLK display version tests
On Mon, Mar 22, 2021 at 04:38:40PM -0700, Matt Roper wrote: > GLK has always been a bit of a special case since it reports INTEL_GEN() > as 9, but has version 10 display IP. Now we can properly represent the > display version as 10 and simplify the display generation tests > throughout the display code. > > Aside from manually adding the version to the glk_info structure, the > rest of this patch is generated with a Coccinelle semantic patch. Note > that we also need to switch any code that matches gen10 today but *not* > GLK to be CNL-specific: > > @@ expression dev_priv; @@ > - DISPLAY_VER(dev_priv) > 9 > + DISPLAY_VER(dev_priv) >= 10 > > @@ expression dev_priv, E; @@ > ( > - DISPLAY_VER(dev_priv) >= 10 && E > + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E > | > - DISPLAY_VER(dev_priv) >= 10 > + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) > | > - IS_DISPLAY_RANGE(dev_priv, 10, E) > + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) > ) > > @@ expression dev_priv, E, E2; @@ > ( > - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) > + IS_DISPLAY_VER(dev_priv, 10) > | > - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) > + E || IS_DISPLAY_VER(dev_priv, 10) > | > - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) > + IS_DISPLAY_VER(dev_priv, 10) > | > - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) > + E || IS_DISPLAY_VER(dev_priv, 10) > | > - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) > + E || E2 || IS_DISPLAY_VER(dev_priv, 10) > | > - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) > + IS_DISPLAY_VER(dev_priv, 10) > | > - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) > + IS_DISPLAY_VER(dev_priv, 10) > ) > > @@ expression dev_priv; @@ > - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) > + IS_DISPLAY_VER(dev_priv, 9) > > @@ expression dev_priv; @@ > ( > - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > + DISPLAY_VER(dev_priv) < 10 > | > - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) > + DISPLAY_VER(dev_priv) >= 10 > ) > > @@ expression dev_priv, E; @@ > - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) > + E || DISPLAY_VER(dev_priv) >= 10 > > @@ expression dev_priv, E; @@ > - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10)) > + IS_DISPLAY_RANGE(dev_priv, 10, E) > > @@ expression dev_priv; @@ > ( > - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || > IS_GEN9_LP(dev_priv) > + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) > | > - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || > IS_CANNONLAKE(dev_priv) > + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 > ) > > @@ expression dev_priv, E; @@ > - !(DISPLAY_VER(dev_priv) >= E) > + DISPLAY_VER(dev_priv) < E > > v2: > - Convert gen10 conditions that don't include GLK into CNL conditions. >(Ville) > > v3: > - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." > (Ville) > > v3.1: > - Manually re-add the ".display.version = 10" to glk_info after >regenerating patch via Coccinelle. > > v4: > - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) Ugh. One thing that occurred to me when looking at i915_irq.c is that IS_GEN9_LP() is now maybe broken on glk? So seems to me all uses of IS_GEN9_LP() need to be reviewed and potentially changed. > > Cc: Ville Syrjälä > Signed-off-by: Matt Roper > Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_atomic.c | 7 ++-- > drivers/gpu/drm/i915/display/intel_audio.c| 2 +- > drivers/gpu/drm/i915/display/intel_bios.c | 3 +- > drivers/gpu/drm/i915/display/intel_cdclk.c| 26 +++-- > drivers/gpu/drm/i915/display/intel_color.c| 8 ++-- > drivers/gpu/drm/i915/display/intel_crtc.c | 2 +- > drivers/gpu/drm/i915/display/intel_display.c | 9 ++--- > .../drm/i915/display/intel_display_debugfs.c | 5 +-- > .../drm/i915/display/intel_display_power.c| 2 +- > drivers/gpu/drm/i915/display/intel_dp.c | 6 +-- > drivers/gpu/drm/i915/display/intel_fbc.c | 4 +- > drivers/gpu/drm/i915/display/intel_hdcp.c | 1 - > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +++ > drivers/gpu/drm/i915/display/intel_psr.c | 7 ++-- > drivers/gpu/drm/i915/display/intel_vdsc.c | 6 +-- > .../drm/i915/display/skl_universal_plane.c| 37 +-- >
Re: [Intel-gfx] [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote:
> On Thu, 18 Mar 2021, Lyude Paul wrote:
> > Actually-NAK this. I just realized I've been misreading the bug and that
> > this
> > doesn't actually seem to be fixed. Will resend once I figure out what's
> > going on
>
> Well, I think there are actually multiple issues on multiple
> machines. This fixes the issue on ThinkPad X1 Titanium Gen1 [1].
>
> I suspect reverting 98e497e203a5 ("drm/i915/dpcd_bl: uncheck PWM_PIN_CAP
> when detect eDP backlight capabilities") would too. But then that would
> break *other* machines that claim support for *both* eDP PWM pin and
> DPCD backlight control, I think.
>
> I think there are issues with how we try setup DPCD backlight if the GOP
> has set up PWM backlight. For example, we don't set the backlight
> control mode correctly until the next disable/enable sequence. However,
> I tried to fix this, and I think I was doing all the right things, and
> DPCD reads seemed to confirm this, yet I was not able to control
> brightness using DPCD. I don't know what gives, but I do know eDP PWM
> pin control works.
Should we go ahead and push the VESA fix for this then? If you're willing to
test future patches on that machine, we could give another shot at enabling this
in the future if we find reason to.
>
>
> BR,
> Jani.
>
>
> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/3158
>
>
> >
> > On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> > > Looks like that there actually are another subset of laptops on the market
> > > that don't support the Intel HDR backlight interface, but do advertise
> > > support for the VESA DPCD backlight interface despite the fact it doesn't
> > > seem to work.
> > >
> > > Note though I'm not entirely clear on this - on one of the machines where
> > > this issue was observed, I also noticed that we appeared to be rejecting
> > > the VBT defined backlight frequency in
> > > intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
> > >
> > > /* Use highest possible value of Pn for more granularity of brightness
> > > * adjustment while satifying the conditions below.
> > > * ...
> > > * - FxP is within 25% of desired value.
> > > * Note: 25% is arbitrary value and may need some tweak.
> > > */
> > >
> > > So it's possible that this value might just need to be tweaked, but for
> > > now
> > > let's just disable the VESA backlight interface unless it's specified in
> > > the VBT just to be safe. We might be able to try enabling this again by
> > > default in the future.
> > >
> > > Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces
> > > through
> > > enable_dpcd_backlight")
> > > Cc: Jani Nikula
> > > Cc: Rodrigo Vivi
> > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
> > > Signed-off-by: Lyude Paul
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index 651884390137..4f8337c7fd2e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > intel_connector *connector)
> > > break;
> > > case INTEL_BACKLIGHT_DISPLAY_DDI:
> > > try_intel_interface = true;
> > > - try_vesa_interface = true;
> > > break;
> > > default:
> > > return -ENODEV;
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/doc: Add RFC section
Side note: I feel like we could have better lines of communication between kernel devs and user-space devs. The new uAPI requirements seem to be a high barrier to entry for kernel devs. However sometimes user-space devs might be interested in helping out with the user-space part… Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that user-space devs can jump in if they're interested. And also provide feedback, since new uAPI is hard to spot in the sea of messages in dri-devel. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove obj->mm.lock! (rev18)
== Series Details ==
Series: drm/i915: Remove obj->mm.lock! (rev18)
URL : https://patchwork.freedesktop.org/series/82337/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9885 -> Patchwork_19841
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_19841 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19841, 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_19841/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19841:
### IGT changes ###
Possible regressions
* igt@prime_vgem@basic-userptr:
- fi-tgl-y: [PASS][1] -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-tgl-y/igt@prime_v...@basic-userptr.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-tgl-y/igt@prime_v...@basic-userptr.html
- fi-icl-u2: [PASS][3] -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-icl-u2/igt@prime_v...@basic-userptr.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-icl-u2/igt@prime_v...@basic-userptr.html
- fi-tgl-u2: [PASS][5] -> [SKIP][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-tgl-u2/igt@prime_v...@basic-userptr.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-tgl-u2/igt@prime_v...@basic-userptr.html
- fi-cml-s: [PASS][7] -> [SKIP][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-cml-s/igt@prime_v...@basic-userptr.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-cml-s/igt@prime_v...@basic-userptr.html
- fi-icl-y: [PASS][9] -> [SKIP][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-icl-y/igt@prime_v...@basic-userptr.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-icl-y/igt@prime_v...@basic-userptr.html
- fi-cml-u2: [PASS][11] -> [SKIP][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-cml-u2/igt@prime_v...@basic-userptr.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-cml-u2/igt@prime_v...@basic-userptr.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_parallel@engines@contexts:
- {fi-rkl-11500t}:[FAIL][13] ([i915#3277] / [i915#3283]) -> [FAIL][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-rkl-11500t/igt@gem_exec_parallel@engi...@contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-rkl-11500t/igt@gem_exec_parallel@engi...@contexts.html
* igt@gem_exec_parallel@engines@fds:
- {fi-rkl-11500t}:[FAIL][15] ([i915#3283]) -> [FAIL][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-rkl-11500t/igt@gem_exec_parallel@engi...@fds.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-rkl-11500t/igt@gem_exec_parallel@engi...@fds.html
* igt@prime_vgem@basic-userptr:
- {fi-ehl-2}: [PASS][17] -> [SKIP][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-ehl-2/igt@prime_v...@basic-userptr.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-ehl-2/igt@prime_v...@basic-userptr.html
- {fi-jsl-1}: [PASS][19] -> [SKIP][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-jsl-1/igt@prime_v...@basic-userptr.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-jsl-1/igt@prime_v...@basic-userptr.html
- {fi-ehl-1}: [PASS][21] -> [SKIP][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-ehl-1/igt@prime_v...@basic-userptr.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-ehl-1/igt@prime_v...@basic-userptr.html
- {fi-tgl-dsi}: [PASS][23] -> [SKIP][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-tgl-dsi/igt@prime_v...@basic-userptr.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-tgl-dsi/igt@prime_v...@basic-userptr.html
- {fi-rkl-11500t}:[PASS][25] -> [SKIP][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9885/fi-rkl-11500t/igt@prime_v...@basic-userptr.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19841/fi-rkl-11500t/igt@prime_v...@basic-userptr.html
Known issues
Here are the changes found in Patchwork_19841 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN ->
Re: [Intel-gfx] [PATCH v5] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
On Thu, Mar 11, 2021 at 01:11:48PM +0200, Joonas Lahtinen wrote:
> Quoting Tvrtko Ursulin (2021-03-11 12:45:54)
> >
> > On 05/03/2021 12:58, Cooper Chiou wrote:
> > > WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to
> > > resolve VP8 hardware encoding system hang up on GT1 sku for
> > > ChromiumOS projects
> > >
> > > Slice specific MMIO read inaccurate so MGSR needs to be programmed
> > > appropriately to get correct reads from these slicet-related MMIOs.
> > >
> > > It dictates that before any MMIO read into Slice/Subslice specific
> > > registers, MCR packet control register(0xFDC) needs to be programmed
> > > to point to any enabled slice/subslice pair, especially GT1 fused sku
> > > since this issue can be reproduced on VP8 hardware encoding via ffmpeg
> > > on ChromiumOS devices.
> > > When exit PC7, MGSR will reset so that we have to skip fused subslice ID.
> > >
> > > Reference: HSD#1508045018,1405586840, BSID#0575
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Rodrigo Vivi
> > > Cc: Jani Nikula
> > > Cc: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > Cc: William Tseng
> > > Cc: Lee Shawn C
> > >
> > > Signed-off-by: Cooper Chiou
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 37 +
> > > 1 file changed, 37 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index 3b4a7da60f0b..eb2a587b06b8 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > @@ -878,9 +878,46 @@ hsw_gt_workarounds_init(struct drm_i915_private
> > > *i915, struct i915_wa_list *wal)
> > > wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> > > }
> > >
> > > +static void
> > > +gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
> > > +{
> > > + const struct sseu_dev_info *sseu = >gt.info.sseu;
> > > + unsigned int slice, subslice;
> > > + u32 mcr, mcr_mask;
> > > +
> > > + GEM_BUG_ON(INTEL_GEN(i915) < 9);
> > > +
> > > + /*
> > > + * WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml
> > > + * Before any MMIO read into slice/subslice specific registers, MCR
> > > + * packet control register needs to be programmed to point to any
> > > + * enabled s/ss pair. Otherwise, incorrect values will be returned.
> > > + * This means each subsequent MMIO read will be forwarded to an
> > > + * specific s/ss combination, but this is OK since these registers
> > > + * are consistent across s/ss in almost all cases. In the rare
> > > + * occasions, such as INSTDONE, where this value is dependent
> > > + * on s/ss combo, the read should be done with read_subslice_reg.
> > > + */
> > > + slice = ffs(sseu->slice_mask) - 1;
> > > + GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
> > > + subslice = ffs(intel_sseu_get_subslices(sseu, slice));
> > > + GEM_BUG_ON(!subslice);
> > > + subslice--;
> > > +
> > > + mcr = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> > > + mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
> > > +
> > > + drm_dbg(>drm, "MCR slice:%d/subslice:%d = %x\n", slice,
> > > subslice, mcr);
> > > +
> > > + wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr);
> > > +}
> > > +
> > > static void
> > > gen9_gt_workarounds_init(struct drm_i915_private *i915, struct
> > > i915_wa_list *wal)
> > > {
> > > + /* WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml,gen9 */
> > > + gen9_wa_init_mcr(i915, wal);
> > > +
> > > /* WaDisableKillLogic:bxt,skl,kbl */
> > > if (!IS_COFFEELAKE(i915) && !IS_COMETLAKE(i915))
> > > wa_write_or(wal,
> > >
> >
> > 1)
> > Patch mechanics are fine.
> >
> > 2)
> > We have confirmation from the HW folks this actually needs doing on Gen9
> > even if docs fail to mention it.
> >
> > So even if the immediate fix is for VP8 encode, which is not fully open,
> > this is the right thing to do in general and would have been done if the
> > WA was properly documented from the start.
> >
> > 3)
> > 3d performance regression cannot be reproduced on the machine where it
> > was originally reported. (Or on other machines.)
> >
> > So:
> >
> > Reviewed-by: Tvrtko Ursulin
> >
> > + Joonas for ack to merge due the second point above.
>
> If this does not effect any fully Open Source userspace, this needs to be
> carried downstream in the Chrome OS kernel tree.
>
> Gen9 has been out there without this W/A for a long time. There is always
> potential for changing existing deployments' behaviour to the worse when
> adding W/As. If it had been implemented from the very beginning, then it
> would have undergone all the testing not to interfere with existing
> workloads. Merging it after the fact makes the risk much higher.
>
> It's an unnecessary risk of regressions to
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API
On 23/03/2021 13:23, Daniel Vetter wrote: On Tue, Mar 23, 2021 at 09:14:36AM +, Tvrtko Ursulin wrote: On 22/03/2021 16:43, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin wrote: On 22/03/2021 14:57, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin wrote: On 22/03/2021 14:09, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote: On 19/03/2021 22:38, Jason Ekstrand wrote: This API allows one context to grab bits out of another context upon creation. It can be used as a short-cut for setparam(getparam()) for things like I915_CONTEXT_PARAM_VM. However, it's never been used by any real userspace. It's used by a few IGT tests and that's it. Since it doesn't add any real value (most of the stuff you can CLONE you can copy in other ways), drop it. No complaints to remove if it ended up unused outside IGT. Latter is a _big_ problem though, since it is much more that a few IGT tests. So I really think there really needs to be an evaluation and a plan for that (we don't want to lose 50% of the coverage over night). There is one thing that this API allows you to clone which you cannot clone via getparam/setparam: timelines. However, timelines are an implementation detail of i915 and not really something that needs to be Not really true timelines are i915 implementation detail. They are in fact a dma-fence context:seqno concept, nothing more that than. I think you are probably confusing struct intel_timeline with the timeline wording in the uapi. Former is i915 implementation detail, but context:seqno are truly userspace timelines. I think you're both saying the same thing and talking a bit past each another. Yes the timeline is just a string of dma_fence, that's correct. Now usually if you submit batches with execbuf, we have 3 ways to synchronize concurrent submission: implicit sync, sync_file and drm_syncob. They all map to different needs in different protocols/render apis. Now in one additional case the kernel makes sure that batchbuffers are ordered, and that's when you submit them to the same hw ctx. Because there's only 1 hw context and you really can't have batchbuffers run on that single hw context out of order. That's what the timeline object we talk about here is. But that largely is an internal implementation detail, which happens to also use most/all the same infrastructure as the dma_fence uapi pieces above. Now the internal implementation detail leaking here is that we exposed this to userspace, without there being any need for this. What Jason implements with syncobj in the next patch is essentially what userspace should have been using for cross-engine sync. media userspace doesn't care about interop with winsys/client apis, so they equally could have used implicit sync or sync_file here (which I think is the solution now for the new uapi prepped internally), since they all are about equally powerful for stringing batchbuffers together. Are you saying we exposed a single timeline of execution per hw context via the single timeline flag?! Nope. Timelines of execution were always exposed. Any "engine" (ring previously) in I915_EXEC_RING_MASK was a single timeline of execution. It is completely the same with engine map engines, which are also different indices into I915_EXEC_RING_MASK space. Userspace was aware of these timelines forever as well. Media was creating multiple contexts to have multiple timelines (so parallelism). Everyone knew that engine-hopping submissions needs to be either implicitly or explicitly synchronised, etc. Yup, I think we're saying the same thing here. So I really don't see that we have leaked timelines as a concept *now*. What the patch has exposed to userspace is a new way to sync between timelines and nothing more. We've leaked it as something you can now share across hw context. Okay so we agree on most things but apparently have different definitions of what it means to leak internal implementation details. While at the same time proof that we haven't leaked the internal implementation details is that Jason was able to implement the single timeline flag with a drm syncobj at the execbuf top level. (Well mostly, ignoring the probably inconsequential difference of one vs multiple fence contexts.) It's not a matching implementation. It's only good enough for what media needs, and essentially what media should have done to begin with. There's substantially different behaviour between SINGLE_TIMELINE and what Jason has done here when you race concurrent execbuf calls: Former guarantees total ordering, the latter doesn't even try. They are not the same thing, but luckily userspace doesn't care about that difference. Sounds like a very important difference to stress in the commit message. Secondly, I am unclear whether we have agreement on whether the single timeline flag is leaking implementation details of the execlists scheduler to userspace or
Re: [Intel-gfx] [PATCH v9 32/70] drm/i915: Prepare for obj->mm.lock removal, v2.
On Tue, 23 Mar 2021 at 15:52, Maarten Lankhorst
wrote:
>
> From: Thomas Hellström
>
> Stolen objects need to lock, and we may call put_pages when
> refcount drops to 0, ensure all calls are handled correctly.
>
> Changes since v1:
> - Rebase on top of upstream changes.
>
> Idea-from: Thomas Hellström
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 ++
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +++-
> 3 files changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 983f2d4b2a85..74de195b57de 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -144,6 +144,20 @@ i915_gem_object_put(struct drm_i915_gem_object *obj)
>
> #define assert_object_held(obj) dma_resv_assert_held((obj)->base.resv)
>
> +/*
> + * If more than one potential simultaneous locker, assert held.
> + */
> +static inline void assert_object_held_shared(struct drm_i915_gem_object *obj)
> +{
> + /*
> +* Note mm list lookup is protected by
What is meant with mm list here? Maybe just a stale comment?
> +* kref_get_unless_zero().
> +*/
> + if (IS_ENABLED(CONFIG_LOCKDEP) &&
> + kref_read(>base.refcount) > 0)
> + lockdep_assert_held(>mm.lock);
> +}
> +
> static inline int __i915_gem_object_lock(struct drm_i915_gem_object *obj,
> struct i915_gem_ww_ctx *ww,
> bool intr)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index a24617af3c93..2d0065fa6e80 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -19,7 +19,7 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
> *obj,
> bool shrinkable;
> int i;
>
> - lockdep_assert_held(>mm.lock);
> + assert_object_held_shared(obj);
>
> if (i915_gem_object_is_volatile(obj))
> obj->mm.madv = I915_MADV_DONTNEED;
> @@ -70,6 +70,7 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
> *obj,
> struct list_head *list;
> unsigned long flags;
>
> + lockdep_assert_held(>mm.lock);
> spin_lock_irqsave(>mm.obj_lock, flags);
>
> i915->mm.shrink_count++;
> @@ -91,6 +92,8 @@ int i915_gem_object_get_pages(struct
> drm_i915_gem_object *obj)
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> int err;
>
> + assert_object_held_shared(obj);
> +
> if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
> drm_dbg(>drm,
> "Attempting to obtain a purgeable object\n");
> @@ -118,6 +121,8 @@ int __i915_gem_object_get_pages(struct
> drm_i915_gem_object *obj)
> if (err)
> return err;
>
> + assert_object_held_shared(obj);
> +
> if (unlikely(!i915_gem_object_has_pages(obj))) {
> GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
>
> @@ -145,7 +150,7 @@ void i915_gem_object_truncate(struct drm_i915_gem_object
> *obj)
> /* Try to discard unwanted pages */
> void i915_gem_object_writeback(struct drm_i915_gem_object *obj)
> {
> - lockdep_assert_held(>mm.lock);
> + assert_object_held_shared(obj);
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
>
> if (obj->ops->writeback)
> @@ -176,6 +181,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
> *obj)
> {
> struct sg_table *pages;
>
> + assert_object_held_shared(obj);
> +
> pages = fetch_and_zero(>mm.pages);
> if (IS_ERR_OR_NULL(pages))
> return pages;
> @@ -203,6 +210,9 @@ int __i915_gem_object_put_pages_locked(struct
> drm_i915_gem_object *obj)
> if (i915_gem_object_has_pinned_pages(obj))
> return -EBUSY;
>
> + /* May be called by shrinker from within get_pages() (on another bo)
> */
> + assert_object_held_shared(obj);
> +
> i915_gem_object_release_mmap_offset(obj);
>
> /*
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 7cdb32d881d9..b0597de206de 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -637,13 +637,15 @@ static int __i915_gem_object_create_stolen(struct
> intel_memory_region *mem,
> cache_level = HAS_LLC(mem->i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
> i915_gem_object_set_cache_coherency(obj, cache_level);
>
> - err = i915_gem_object_pin_pages(obj);
> - if (err)
> - return err;
> + if
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Remove obj->mm.lock! (rev18)
== Series Details == Series: drm/i915: Remove obj->mm.lock! (rev18) URL : https://patchwork.freedesktop.org/series/82337/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove obj->mm.lock! (rev18)
== Series Details == Series: drm/i915: Remove obj->mm.lock! (rev18) URL : https://patchwork.freedesktop.org/series/82337/ 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_ring_submission.c:1196:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove obj->mm.lock! (rev18)
== Series Details ==
Series: drm/i915: Remove obj->mm.lock! (rev18)
URL : https://patchwork.freedesktop.org/series/82337/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
21e30af84d60 drm/i915: Do not share hwsp across contexts any more, v8.
-:565: WARNING:CONSTANT_COMPARISON: Comparisons should place the constant on
the right side of the test
#565: FILE: drivers/gpu/drm/i915/gt/intel_timeline.c:286:
+ if (TIMELINE_SEQNO_BYTES <= BIT(5) && (next_ofs & BIT(5)))
total: 0 errors, 1 warnings, 0 checks, 967 lines checked
3dcc3090a8aa drm/i915: Pin timeline map after first timeline pin, v4.
-:16: WARNING:TYPO_SPELLING: 'arithmatic' may be misspelled - perhaps
'arithmetic'?
#16:
- Fix NULL + XX arithmatic, use casts. (kbuild)
^^
total: 0 errors, 1 warnings, 0 checks, 288 lines checked
61e73e406004 drm/i915: Move cmd parser pinning to execbuffer
263d87a59478 drm/i915: Add missing -EDEADLK handling to execbuf pinning, v2.
-:59: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#59: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:452:
+ err = i915_vma_pin_ww(vma, >ww,
entry->pad_to_size,
total: 0 errors, 0 warnings, 1 checks, 75 lines checked
d0fd03b71eac drm/i915: Ensure we hold the object mutex in pin correctly.
5f9f5fded601 drm/i915: Add gem object locking to madvise.
ec224070faa9 drm/i915: Move HAS_STRUCT_PAGE to obj->flags
-:110: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#110: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.c:63:
+ struct lock_class_key *key, unsigned flags)
-:133: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#133: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:53:
+ unsigned alloc_flags);
total: 0 errors, 2 warnings, 0 checks, 350 lines checked
f1417f7189ac drm/i915: Rework struct phys attachment handling
c5121d3bf030 drm/i915: Convert i915_gem_object_attach_phys() to ww locking, v2.
cd80a5137639 drm/i915: make lockdep slightly happier about execbuf.
81d63e3444e2 drm/i915: Disable userptr pread/pwrite support.
e170f0547221 drm/i915: No longer allow exporting userptr through dma-buf
13f46a38f0eb drm/i915: Reject more ioctls for userptr, v2.
76fa2e87da9c drm/i915: Reject UNSYNCHRONIZED for userptr, v2.
efd70139bae3 drm/i915: Make compilation of userptr code depend on MMU_NOTIFIER.
1f380a5600a4 drm/i915: Fix userptr so we do not have to worry about
obj->mm.lock, v7.
-:332: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#332: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:605:
+static inline int i915_gem_object_userptr_submit_init(struct
drm_i915_gem_object *obj) { GEM_BUG_ON(1); return -ENODEV; }
-:333: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#333: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:606:
+static inline int i915_gem_object_userptr_submit_done(struct
drm_i915_gem_object *obj) { GEM_BUG_ON(1); return -ENODEV; }
-:334: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#334: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:607:
+static inline void i915_gem_object_userptr_submit_fini(struct
drm_i915_gem_object *obj) { GEM_BUG_ON(1); }
-:335: WARNING:LONG_LINE: line length of 118 exceeds 100 columns
#335: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:608:
+static inline int i915_gem_object_userptr_validate(struct drm_i915_gem_object
*obj) { GEM_BUG_ON(1); return -ENODEV; }
-:394: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#394: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:2:
* SPDX-License-Identifier: MIT
-:398: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each
line
#398: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:6:
+ *
+ * Based on amdgpu_mn, which bears the following notice:
-:399: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each
line
#399: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:7:
+ * Based on amdgpu_mn, which bears the following notice:
+ *
-:484: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#484: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:63:
+ struct drm_i915_gem_object *obj = container_of(mni, struct
drm_i915_gem_object, userptr.notifier);
-:1172: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#1172: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:300:
+ pinned = ret = 0;
-:1187: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1187: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:315:
+ if (mmu_interval_read_retry(>userptr.notifier,
+ !obj->userptr.page_ref ? notifier_seq :
-:1334: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#1334: FILE: drivers/gpu/drm/i915/i915_drv.h:564:
+ spinlock_t notifier_lock;
total: 0 errors, 8 warnings, 3 checks,
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Fail too long user submissions by default
On Thu, 18 Mar 2021 at 17:04, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting > to 20s, and this timeout is applied to all users contexts using the > previously added watchdog facility. > > Result of this is that any user submission will simply fail after this > timeout, either causing a reset (for non-preemptable), or incomplete > results. > > This can have an effect that workloads which used to work fine will > suddenly start failing. Even workloads comprised of short batches but in > long dependency chains can be terminated. > > And becuase of lack of agreement on usefulness and safety of fence error because > propagation this partial execution can be invisible to userspace even if > it is "listening" to returned fence status. > > Another interaction is with hangcheck where care needs to be taken timeout > is not set lower or close to three times the heartbeat interval. Otherwise > a hang in any application can cause complete termination of all > submissions from unrelated clients. Any users modifying the per engine > heartbeat intervals therefore need to be aware of this potential denial of > service to avoid inadvertently enabling it. > > Given all this I am personally not convinced the scheme is a good idea. > Intuitively it feels object importers would be better positioned to > enforce the time they are willing to wait for something to complete. > > v2: > * Improved commit message and Kconfig text. > * Pull in some helper code from patch which got dropped. > > v3: > * Bump timeout to 20s to see if it helps Tigerlake. > > Signed-off-by: Tvrtko Ursulin > Cc: Daniel Vetter Acked-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 09/70] drm/i915: Convert i915_gem_object_attach_phys() to ww locking, v2.
Simple adding of i915_gem_object_lock, we may start to pass ww to
get_pages() in the future, but that won't be the case here;
We override shmem's get_pages() handling by calling
i915_gem_object_get_pages_phys(), no ww is needed.
Changes since v1:
- Call shmem put pages directly, the callback would
go down the phys free path.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 12 ++--
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 17 ++---
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 75e8734f50d2..c8eb0df904f7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -69,10 +69,11 @@ int i915_gem_object_pread_phys(struct drm_i915_gem_object
*obj,
const struct drm_i915_gem_pread *args);
int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj, int align);
+void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj,
+struct sg_table *pages);
void i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj,
struct sg_table *pages);
-
void i915_gem_flush_free_objects(struct drm_i915_private *i915);
struct sg_table *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index ed283e168f2f..06c481ff79d8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -201,7 +201,7 @@ static int i915_gem_object_shmem_to_phys(struct
drm_i915_gem_object *obj)
__i915_gem_object_pin_pages(obj);
if (!IS_ERR_OR_NULL(pages))
- i915_gem_shmem_ops.put_pages(obj, pages);
+ i915_gem_object_put_pages_shmem(obj, pages);
i915_gem_object_release_memory_region(obj);
return 0;
@@ -232,7 +232,13 @@ int i915_gem_object_attach_phys(struct drm_i915_gem_object
*obj, int align)
if (err)
return err;
- mutex_lock_nested(>mm.lock, I915_MM_GET_PAGES);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
+ if (err)
+ return err;
+
+ err = mutex_lock_interruptible_nested(>mm.lock, I915_MM_GET_PAGES);
+ if (err)
+ goto err_unlock;
if (unlikely(!i915_gem_object_has_struct_page(obj)))
goto out;
@@ -263,6 +269,8 @@ int i915_gem_object_attach_phys(struct drm_i915_gem_object
*obj, int align)
out:
mutex_unlock(>mm.lock);
+err_unlock:
+ i915_gem_object_unlock(obj);
return err;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index c9820c19c5f2..59fb16a82270 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -296,18 +296,12 @@ __i915_gem_object_release_shmem(struct
drm_i915_gem_object *obj,
__start_cpu_write(obj);
}
-static void
-shmem_put_pages(struct drm_i915_gem_object *obj, struct sg_table *pages)
+void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct
sg_table *pages)
{
struct sgt_iter sgt_iter;
struct pagevec pvec;
struct page *page;
- if (unlikely(!i915_gem_object_has_struct_page(obj))) {
- i915_gem_object_put_pages_phys(obj, pages);
- return;
- }
-
__i915_gem_object_release_shmem(obj, pages, true);
i915_gem_gtt_finish_pages(obj, pages);
@@ -336,6 +330,15 @@ shmem_put_pages(struct drm_i915_gem_object *obj, struct
sg_table *pages)
kfree(pages);
}
+static void
+shmem_put_pages(struct drm_i915_gem_object *obj, struct sg_table *pages)
+{
+ if (likely(i915_gem_object_has_struct_page(obj)))
+ i915_gem_object_put_pages_shmem(obj, pages);
+ else
+ i915_gem_object_put_pages_phys(obj, pages);
+}
+
static int
shmem_pwrite(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_pwrite *arg)
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 32/70] drm/i915: Prepare for obj->mm.lock removal, v2.
From: Thomas Hellström
Stolen objects need to lock, and we may call put_pages when
refcount drops to 0, ensure all calls are handled correctly.
Changes since v1:
- Rebase on top of upstream changes.
Idea-from: Thomas Hellström
Signed-off-by: Maarten Lankhorst
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 ++
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +++-
3 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 983f2d4b2a85..74de195b57de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -144,6 +144,20 @@ i915_gem_object_put(struct drm_i915_gem_object *obj)
#define assert_object_held(obj) dma_resv_assert_held((obj)->base.resv)
+/*
+ * If more than one potential simultaneous locker, assert held.
+ */
+static inline void assert_object_held_shared(struct drm_i915_gem_object *obj)
+{
+ /*
+* Note mm list lookup is protected by
+* kref_get_unless_zero().
+*/
+ if (IS_ENABLED(CONFIG_LOCKDEP) &&
+ kref_read(>base.refcount) > 0)
+ lockdep_assert_held(>mm.lock);
+}
+
static inline int __i915_gem_object_lock(struct drm_i915_gem_object *obj,
struct i915_gem_ww_ctx *ww,
bool intr)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index a24617af3c93..2d0065fa6e80 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -19,7 +19,7 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
*obj,
bool shrinkable;
int i;
- lockdep_assert_held(>mm.lock);
+ assert_object_held_shared(obj);
if (i915_gem_object_is_volatile(obj))
obj->mm.madv = I915_MADV_DONTNEED;
@@ -70,6 +70,7 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
*obj,
struct list_head *list;
unsigned long flags;
+ lockdep_assert_held(>mm.lock);
spin_lock_irqsave(>mm.obj_lock, flags);
i915->mm.shrink_count++;
@@ -91,6 +92,8 @@ int i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
int err;
+ assert_object_held_shared(obj);
+
if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
drm_dbg(>drm,
"Attempting to obtain a purgeable object\n");
@@ -118,6 +121,8 @@ int __i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
if (err)
return err;
+ assert_object_held_shared(obj);
+
if (unlikely(!i915_gem_object_has_pages(obj))) {
GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
@@ -145,7 +150,7 @@ void i915_gem_object_truncate(struct drm_i915_gem_object
*obj)
/* Try to discard unwanted pages */
void i915_gem_object_writeback(struct drm_i915_gem_object *obj)
{
- lockdep_assert_held(>mm.lock);
+ assert_object_held_shared(obj);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
if (obj->ops->writeback)
@@ -176,6 +181,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
{
struct sg_table *pages;
+ assert_object_held_shared(obj);
+
pages = fetch_and_zero(>mm.pages);
if (IS_ERR_OR_NULL(pages))
return pages;
@@ -203,6 +210,9 @@ int __i915_gem_object_put_pages_locked(struct
drm_i915_gem_object *obj)
if (i915_gem_object_has_pinned_pages(obj))
return -EBUSY;
+ /* May be called by shrinker from within get_pages() (on another bo) */
+ assert_object_held_shared(obj);
+
i915_gem_object_release_mmap_offset(obj);
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 7cdb32d881d9..b0597de206de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -637,13 +637,15 @@ static int __i915_gem_object_create_stolen(struct
intel_memory_region *mem,
cache_level = HAS_LLC(mem->i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
i915_gem_object_set_cache_coherency(obj, cache_level);
- err = i915_gem_object_pin_pages(obj);
- if (err)
- return err;
+ if (WARN_ON(!i915_gem_object_trylock(obj)))
+ return -EBUSY;
- i915_gem_object_init_memory_region(obj, mem);
+ err = i915_gem_object_pin_pages(obj);
+ if (!err)
+ i915_gem_object_init_memory_region(obj, mem);
+ i915_gem_object_unlock(obj);
- return 0;
+ return err;
}
static int
[Intel-gfx] [PATCH v9 29/70] drm/i915: Defer pin calls in buffer pool until first use by caller.
We need to take the obj lock to pin pages, so wait until the callers
have done so, before making the object unshrinkable.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 6 +++
.../gpu/drm/i915/gt/intel_gt_buffer_pool.c| 47 +--
.../gpu/drm/i915/gt/intel_gt_buffer_pool.h| 5 ++
.../drm/i915/gt/intel_gt_buffer_pool_types.h | 1 +
5 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b5ca9eb53565..37fecd295eb6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1342,6 +1342,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
err = PTR_ERR(cmd);
goto err_pool;
}
+ intel_gt_buffer_pool_mark_used(pool);
memset32(cmd, 0, pool->obj->base.size / sizeof(u32));
@@ -2637,6 +2638,7 @@ static int eb_parse(struct i915_execbuffer *eb)
err = PTR_ERR(shadow);
goto err;
}
+ intel_gt_buffer_pool_mark_used(pool);
i915_gem_object_set_readonly(shadow->obj);
shadow->private = pool;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index d6dac21fce0b..df8e8c18c6c9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -55,6 +55,9 @@ struct i915_vma *intel_emit_vma_fill_blt(struct intel_context
*ce,
if (unlikely(err))
goto out_put;
+ /* we pinned the pool, mark it as such */
+ intel_gt_buffer_pool_mark_used(pool);
+
cmd = i915_gem_object_pin_map(pool->obj, pool->type);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
@@ -277,6 +280,9 @@ struct i915_vma *intel_emit_vma_copy_blt(struct
intel_context *ce,
if (unlikely(err))
goto out_put;
+ /* we pinned the pool, mark it as such */
+ intel_gt_buffer_pool_mark_used(pool);
+
cmd = i915_gem_object_pin_map(pool->obj, pool->type);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index 06d84cf09570..c59468107598 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -98,28 +98,6 @@ static void pool_free_work(struct work_struct *wrk)
round_jiffies_up_relative(HZ));
}
-static int pool_active(struct i915_active *ref)
-{
- struct intel_gt_buffer_pool_node *node =
- container_of(ref, typeof(*node), active);
- struct dma_resv *resv = node->obj->base.resv;
- int err;
-
- if (dma_resv_trylock(resv)) {
- dma_resv_add_excl_fence(resv, NULL);
- dma_resv_unlock(resv);
- }
-
- err = i915_gem_object_pin_pages(node->obj);
- if (err)
- return err;
-
- /* Hide this pinned object from the shrinker until retired */
- i915_gem_object_make_unshrinkable(node->obj);
-
- return 0;
-}
-
__i915_active_call
static void pool_retire(struct i915_active *ref)
{
@@ -129,10 +107,13 @@ static void pool_retire(struct i915_active *ref)
struct list_head *list = bucket_for_size(pool, node->obj->base.size);
unsigned long flags;
- i915_gem_object_unpin_pages(node->obj);
+ if (node->pinned) {
+ i915_gem_object_unpin_pages(node->obj);
- /* Return this object to the shrinker pool */
- i915_gem_object_make_purgeable(node->obj);
+ /* Return this object to the shrinker pool */
+ i915_gem_object_make_purgeable(node->obj);
+ node->pinned = false;
+ }
GEM_BUG_ON(node->age);
spin_lock_irqsave(>lock, flags);
@@ -144,6 +125,19 @@ static void pool_retire(struct i915_active *ref)
round_jiffies_up_relative(HZ));
}
+void intel_gt_buffer_pool_mark_used(struct intel_gt_buffer_pool_node *node)
+{
+ assert_object_held(node->obj);
+
+ if (node->pinned)
+ return;
+
+ __i915_gem_object_pin_pages(node->obj);
+ /* Hide this pinned object from the shrinker until retired */
+ i915_gem_object_make_unshrinkable(node->obj);
+ node->pinned = true;
+}
+
static struct intel_gt_buffer_pool_node *
node_create(struct intel_gt_buffer_pool *pool, size_t sz,
enum i915_map_type type)
@@ -159,7 +153,8 @@ node_create(struct intel_gt_buffer_pool *pool, size_t sz,
node->age = 0;
node->pool = pool;
- i915_active_init(>active, pool_active, pool_retire);
+ node->pinned = false;
+ i915_active_init(>active,
[Intel-gfx] [PATCH v9 24/70] drm/i915: Move pinning to inside engine_wa_list_verify()
This should be done as part of the ww loop, in order to remove a
i915_vma_pin that needs ww held.
Now only i915_ggtt_pin() callers remaining.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gtt.c| 14 +-
drivers/gpu/drm/i915/gt/intel_gtt.h| 3 +++
drivers/gpu/drm/i915/gt/intel_workarounds.c| 10 --
drivers/gpu/drm/i915/gt/selftest_execlists.c | 5 +++--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_mocs.c| 3 ++-
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 6 +++---
7 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index d34770ae4c9a..1b532a2791ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -427,7 +427,6 @@ __vm_create_scratch_for_read(struct i915_address_space *vm,
unsigned long size)
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- int err;
obj = i915_gem_object_create_internal(vm->i915, PAGE_ALIGN(size));
if (IS_ERR(obj))
@@ -441,6 +440,19 @@ __vm_create_scratch_for_read(struct i915_address_space
*vm, unsigned long size)
return vma;
}
+ return vma;
+}
+
+struct i915_vma *
+__vm_create_scratch_for_read_pinned(struct i915_address_space *vm, unsigned
long size)
+{
+ struct i915_vma *vma;
+ int err;
+
+ vma = __vm_create_scratch_for_read(vm, size);
+ if (IS_ERR(vma))
+ return vma;
+
err = i915_vma_pin(vma, 0, 0,
i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
if (err) {
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 24b5808df16d..784c4372b405 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -581,6 +581,9 @@ void i915_vm_free_pt_stash(struct i915_address_space *vm,
struct i915_vma *
__vm_create_scratch_for_read(struct i915_address_space *vm, unsigned long
size);
+struct i915_vma *
+__vm_create_scratch_for_read_pinned(struct i915_address_space *vm, unsigned
long size);
+
static inline struct sgt_dma {
struct scatterlist *sg;
dma_addr_t dma, max;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3b4a7da60f0b..bb2357119792 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2211,10 +2211,15 @@ static int engine_wa_list_verify(struct intel_context
*ce,
if (err)
goto err_pm;
+ err = i915_vma_pin_ww(vma, , 0, 0,
+ i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+ if (err)
+ goto err_unpin;
+
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto err_unpin;
+ goto err_vma;
}
err = i915_request_await_object(rq, vma->obj, true);
@@ -2255,6 +2260,8 @@ static int engine_wa_list_verify(struct intel_context *ce,
err_rq:
i915_request_put(rq);
+err_vma:
+ i915_vma_unpin(vma);
err_unpin:
intel_context_unpin(ce);
err_pm:
@@ -2265,7 +2272,6 @@ static int engine_wa_list_verify(struct intel_context *ce,
}
i915_gem_ww_ctx_fini();
intel_engine_pm_put(ce->engine);
- i915_vma_unpin(vma);
i915_vma_put(vma);
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index f625c29023ea..a6e77a161b70 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -4165,8 +4165,9 @@ static int preserved_virtual_engine(struct intel_gt *gt,
int err = 0;
u32 *cs;
- scratch = __vm_create_scratch_for_read([0]->gt->ggtt->vm,
- PAGE_SIZE);
+ scratch =
+ __vm_create_scratch_for_read_pinned([0]->gt->ggtt->vm,
+ PAGE_SIZE);
if (IS_ERR(scratch))
return PTR_ERR(scratch);
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 279091e41b41..1f7a120606e6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -27,7 +27,7 @@
static struct i915_vma *create_scratch(struct intel_gt *gt)
{
- return __vm_create_scratch_for_read(>ggtt->vm, PAGE_SIZE);
+ return __vm_create_scratch_for_read_pinned(>ggtt->vm, PAGE_SIZE);
}
static bool is_active(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index 44609d1c7780..01dd050d4161 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
[Intel-gfx] [PATCH v9 26/70] drm/i915: Make lrc_init_wa_ctx compatible with ww locking, v3.
Make creation separate from pinning, in order to take the lock only
once, and pin the mapping with the lock held.
Changes since v1:
- Rebase on top of upstream changes.
Changes since v2:
- Fully clear wa_ctx on error.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 49 ++---
1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8508b8d701c1..a2b916d27a39 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1421,7 +1421,7 @@ gen10_init_indirectctx_bb(struct intel_engine_cs *engine,
u32 *batch)
#define CTX_WA_BB_SIZE (PAGE_SIZE)
-static int lrc_setup_wa_ctx(struct intel_engine_cs *engine)
+static int lrc_create_wa_ctx(struct intel_engine_cs *engine)
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -1437,10 +1437,6 @@ static int lrc_setup_wa_ctx(struct intel_engine_cs
*engine)
goto err;
}
- err = i915_ggtt_pin(vma, NULL, 0, PIN_HIGH);
- if (err)
- goto err;
-
engine->wa_ctx.vma = vma;
return 0;
@@ -1452,9 +1448,6 @@ static int lrc_setup_wa_ctx(struct intel_engine_cs
*engine)
void lrc_fini_wa_ctx(struct intel_engine_cs *engine)
{
i915_vma_unpin_and_release(>wa_ctx.vma, 0);
-
- /* Called on error unwind, clear all flags to prevent further use */
- memset(>wa_ctx, 0, sizeof(engine->wa_ctx));
}
typedef u32 *(*wa_bb_func_t)(struct intel_engine_cs *engine, u32 *batch);
@@ -1466,6 +1459,7 @@ void lrc_init_wa_ctx(struct intel_engine_cs *engine)
_ctx->indirect_ctx, _ctx->per_ctx
};
wa_bb_func_t wa_bb_fn[ARRAY_SIZE(wa_bb)];
+ struct i915_gem_ww_ctx ww;
void *batch, *batch_ptr;
unsigned int i;
int err;
@@ -1494,7 +1488,7 @@ void lrc_init_wa_ctx(struct intel_engine_cs *engine)
return;
}
- err = lrc_setup_wa_ctx(engine);
+ err = lrc_create_wa_ctx(engine);
if (err) {
/*
* We continue even if we fail to initialize WA batch
@@ -1507,7 +1501,22 @@ void lrc_init_wa_ctx(struct intel_engine_cs *engine)
return;
}
+ if (!engine->wa_ctx.vma)
+ return;
+
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock(wa_ctx->vma->obj, );
+ if (!err)
+ err = i915_ggtt_pin(wa_ctx->vma, , 0, PIN_HIGH);
+ if (err)
+ goto err;
+
batch = i915_gem_object_pin_map(wa_ctx->vma->obj, I915_MAP_WB);
+ if (IS_ERR(batch)) {
+ err = PTR_ERR(batch);
+ goto err_unpin;
+ }
/*
* Emit the two workaround batch buffers, recording the offset from the
@@ -1532,8 +1541,26 @@ void lrc_init_wa_ctx(struct intel_engine_cs *engine)
__i915_gem_object_release_map(wa_ctx->vma->obj);
/* Verify that we can handle failure to setup the wa_ctx */
- if (err || i915_inject_probe_error(engine->i915, -ENODEV))
- lrc_fini_wa_ctx(engine);
+ if (!err)
+ err = i915_inject_probe_error(engine->i915, -ENODEV);
+
+err_unpin:
+ if (err)
+ i915_vma_unpin(wa_ctx->vma);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
+ if (err) {
+ i915_vma_put(engine->wa_ctx.vma);
+
+ /* Clear all flags to prevent further use */
+ memset(wa_ctx, 0, sizeof(*wa_ctx));
+ }
}
static void st_runtime_underflow(struct intel_context_stats *stats, s32 dt)
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 55/70] drm/i915/selftests: Prepare ring submission for obj->mm.lock removal
Use unlocked versions when the ww lock is not held.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
index 6cd9f6bc240c..c12e74171b63 100644
--- a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
@@ -35,7 +35,7 @@ static struct i915_vma *create_wally(struct intel_engine_cs
*engine)
return ERR_PTR(err);
}
- cs = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cs = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cs)) {
i915_gem_object_put(obj);
return ERR_CAST(cs);
@@ -212,7 +212,7 @@ static int __live_ctx_switch_wa(struct intel_engine_cs
*engine)
if (IS_ERR(bb))
return PTR_ERR(bb);
- result = i915_gem_object_pin_map(bb->obj, I915_MAP_WC);
+ result = i915_gem_object_pin_map_unlocked(bb->obj, I915_MAP_WC);
if (IS_ERR(result)) {
intel_context_put(bb->private);
i915_vma_unpin_and_release(, 0);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 60/70] drm/i915/selftests: Prepare gtt tests for obj->mm.lock removal
We need to lock the global gtt dma_resv, use i915_vm_lock_objects
to handle this correctly. Add ww handling for this where required.
Add the object lock around unpin/put pages, and use the unlocked
versions of pin_pages and pin_map where required.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 92 ++-
1 file changed, 67 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 5be6dcf4357e..2e4f06eaacc1 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -130,7 +130,7 @@ fake_dma_object(struct drm_i915_private *i915, u64 size)
obj->cache_level = I915_CACHE_NONE;
/* Preallocate the "backing storage" */
- if (i915_gem_object_pin_pages(obj))
+ if (i915_gem_object_pin_pages_unlocked(obj))
goto err_obj;
i915_gem_object_unpin_pages(obj);
@@ -146,6 +146,7 @@ static int igt_ppgtt_alloc(void *arg)
{
struct drm_i915_private *dev_priv = arg;
struct i915_ppgtt *ppgtt;
+ struct i915_gem_ww_ctx ww;
u64 size, last, limit;
int err = 0;
@@ -171,6 +172,12 @@ static int igt_ppgtt_alloc(void *arg)
limit = totalram_pages() << PAGE_SHIFT;
limit = min(ppgtt->vm.total, limit);
+ i915_gem_ww_ctx_init(, false);
+retry:
+ err = i915_vm_lock_objects(>vm, );
+ if (err)
+ goto err_ppgtt_cleanup;
+
/* Check we can allocate the entire range */
for (size = 4096; size <= limit; size <<= 2) {
struct i915_vm_pt_stash stash = {};
@@ -215,6 +222,13 @@ static int igt_ppgtt_alloc(void *arg)
}
err_ppgtt_cleanup:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
i915_vm_put(>vm);
return err;
}
@@ -276,7 +290,7 @@ static int lowlevel_hole(struct i915_address_space *vm,
GEM_BUG_ON(obj->base.size != BIT_ULL(size));
- if (i915_gem_object_pin_pages(obj)) {
+ if (i915_gem_object_pin_pages_unlocked(obj)) {
i915_gem_object_put(obj);
kfree(order);
break;
@@ -297,20 +311,36 @@ static int lowlevel_hole(struct i915_address_space *vm,
if (vm->allocate_va_range) {
struct i915_vm_pt_stash stash = {};
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(, false);
+retry:
+ err = i915_vm_lock_objects(vm, );
+ if (err)
+ goto alloc_vm_end;
+ err = -ENOMEM;
if (i915_vm_alloc_pt_stash(vm, ,
BIT_ULL(size)))
- break;
-
- if (i915_vm_pin_pt_stash(vm, )) {
- i915_vm_free_pt_stash(vm, );
- break;
- }
+ goto alloc_vm_end;
- vm->allocate_va_range(vm, ,
- addr, BIT_ULL(size));
+ err = i915_vm_pin_pt_stash(vm, );
+ if (!err)
+ vm->allocate_va_range(vm, ,
+ addr,
BIT_ULL(size));
i915_vm_free_pt_stash(vm, );
+alloc_vm_end:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
+ if (err)
+ break;
}
mock_vma->pages = obj->mm.pages;
@@ -1166,7 +1196,7 @@ static int igt_ggtt_page(void *arg)
if (IS_ERR(obj))
return PTR_ERR(obj);
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err)
goto out_free;
@@ -1333,7 +1363,7 @@ static int igt_gtt_reserve(void *arg)
goto out;
}
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err)
[Intel-gfx] [PATCH v9 67/70] drm/i915: Add ww context to prepare_(read/write)
This will allow us to explicitly pass the ww to pin_pages, when it starts
taking it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2 ++
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 ---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
7 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index e3537922183b..a5b3a21faf9c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -534,6 +534,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
* flush the object from the CPU cache.
*/
int i915_gem_object_prepare_read(struct drm_i915_gem_object *obj,
+struct i915_gem_ww_ctx *ww,
unsigned int *needs_clflush)
{
int ret;
@@ -578,6 +579,7 @@ int i915_gem_object_prepare_read(struct drm_i915_gem_object
*obj,
}
int i915_gem_object_prepare_write(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww,
unsigned int *needs_clflush)
{
int ret;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f85ca10bf7f3..dcfcae9c841b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1154,9 +1154,10 @@ static void reloc_cache_reset(struct reloc_cache *cache,
struct i915_execbuffer
}
static void *reloc_kmap(struct drm_i915_gem_object *obj,
- struct reloc_cache *cache,
+ struct i915_execbuffer *eb,
unsigned long pageno)
{
+ struct reloc_cache *cache = >reloc_cache;
void *vaddr;
struct page *page;
@@ -1166,7 +1167,7 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
unsigned int flushes;
int err;
- err = i915_gem_object_prepare_write(obj, );
+ err = i915_gem_object_prepare_write(obj, >ww, );
if (err)
return ERR_PTR(err);
@@ -1266,7 +1267,7 @@ static void *reloc_vaddr(struct drm_i915_gem_object *obj,
if ((cache->vaddr & KMAP) == 0)
vaddr = reloc_iomap(obj, eb, page);
if (!vaddr)
- vaddr = reloc_kmap(obj, cache, page);
+ vaddr = reloc_kmap(obj, eb, page);
}
return vaddr;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7a252dc4237f..1a8ec4035112 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -480,8 +480,10 @@ static inline void i915_gem_object_unpin_map(struct
drm_i915_gem_object *obj)
void __i915_gem_object_release_map(struct drm_i915_gem_object *obj);
int i915_gem_object_prepare_read(struct drm_i915_gem_object *obj,
+struct i915_gem_ww_ctx *ww,
unsigned int *needs_clflush);
int i915_gem_object_prepare_write(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww,
unsigned int *needs_clflush);
#define CLFLUSH_BEFORE BIT(0)
#define CLFLUSH_AFTER BIT(1)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 80eeb59aae67..8b07bb77bb86 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -987,7 +987,7 @@ __cpu_check_shmem(struct drm_i915_gem_object *obj, u32
dword, u32 val)
int err;
i915_gem_object_lock(obj, NULL);
- err = i915_gem_object_prepare_read(obj, _flush);
+ err = i915_gem_object_prepare_read(obj, NULL, _flush);
if (err)
goto err_unlock;
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 8f2e447bd503..8f5b1e44d534 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -29,7 +29,7 @@ static int cpu_set(struct context *ctx, unsigned long offset,
u32 v)
int err;
i915_gem_object_lock(ctx->obj, NULL);
- err = i915_gem_object_prepare_write(ctx->obj, _clflush);
+ err = i915_gem_object_prepare_write(ctx->obj, NULL, _clflush);
if (err)
goto out;
@@ -62,7 +62,7 @@
[Intel-gfx] [PATCH v9 56/70] drm/i915/selftests: Prepare timeline tests for obj->mm.lock removal
We can no longer call intel_timeline_pin with a null argument,
so add a ww loop that locks the backing object.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 30 +
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index fa4b965ed5ee..9adbd9d147be 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -37,6 +37,26 @@ static unsigned long hwsp_cacheline(struct intel_timeline
*tl)
return (address + offset_in_page(tl->hwsp_offset)) /
TIMELINE_SEQNO_BYTES;
}
+static int selftest_tl_pin(struct intel_timeline *tl)
+{
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(, false);
+retry:
+ err = i915_gem_object_lock(tl->hwsp_ggtt->obj, );
+ if (!err)
+ err = intel_timeline_pin(tl, );
+
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+ return err;
+}
+
/* Only half of seqno's are usable, see __intel_timeline_get_seqno() */
#define CACHELINES_PER_PAGE (PAGE_SIZE / TIMELINE_SEQNO_BYTES / 2)
@@ -79,7 +99,7 @@ static int __mock_hwsp_timeline(struct mock_hwsp_freelist
*state,
if (IS_ERR(tl))
return PTR_ERR(tl);
- err = intel_timeline_pin(tl, NULL);
+ err = selftest_tl_pin(tl);
if (err) {
intel_timeline_put(tl);
return err;
@@ -465,7 +485,7 @@ checked_tl_write(struct intel_timeline *tl, struct
intel_engine_cs *engine, u32
struct i915_request *rq;
int err;
- err = intel_timeline_pin(tl, NULL);
+ err = selftest_tl_pin(tl);
if (err) {
rq = ERR_PTR(err);
goto out;
@@ -665,7 +685,7 @@ static int live_hwsp_wrap(void *arg)
if (!tl->has_initial_breadcrumb)
goto out_free;
- err = intel_timeline_pin(tl, NULL);
+ err = selftest_tl_pin(tl);
if (err)
goto out_free;
@@ -812,13 +832,13 @@ static int setup_watcher(struct hwsp_watcher *w, struct
intel_gt *gt)
if (IS_ERR(obj))
return PTR_ERR(obj);
- w->map = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ w->map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(w->map)) {
i915_gem_object_put(obj);
return PTR_ERR(w->map);
}
- vma = i915_gem_object_ggtt_pin_ww(obj, NULL, NULL, 0, 0, 0);
+ vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
if (IS_ERR(vma)) {
i915_gem_object_put(obj);
return PTR_ERR(vma);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 46/70] drm/i915/selftests: Prepare execbuf tests for obj->mm.lock removal.
Also quite simple, a single call needs to use the unlocked version.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
index e1d50a5a1477..4df505e4c53a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
@@ -116,7 +116,7 @@ static int igt_gpu_reloc(void *arg)
if (IS_ERR(scratch))
return PTR_ERR(scratch);
- map = i915_gem_object_pin_map(scratch, I915_MAP_WC);
+ map = i915_gem_object_pin_map_unlocked(scratch, I915_MAP_WC);
if (IS_ERR(map)) {
err = PTR_ERR(map);
goto err_scratch;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 00/70] drm/i915: Remove obj->mm.lock!
Small fix to timeline patch and a fix for BSW. Maarten Lankhorst (69): drm/i915: Do not share hwsp across contexts any more, v8. drm/i915: Pin timeline map after first timeline pin, v4. drm/i915: Move cmd parser pinning to execbuffer drm/i915: Add missing -EDEADLK handling to execbuf pinning, v2. drm/i915: Ensure we hold the object mutex in pin correctly. drm/i915: Add gem object locking to madvise. drm/i915: Move HAS_STRUCT_PAGE to obj->flags drm/i915: Rework struct phys attachment handling drm/i915: Convert i915_gem_object_attach_phys() to ww locking, v2. drm/i915: make lockdep slightly happier about execbuf. drm/i915: Disable userptr pread/pwrite support. drm/i915: No longer allow exporting userptr through dma-buf drm/i915: Reject more ioctls for userptr, v2. drm/i915: Reject UNSYNCHRONIZED for userptr, v2. drm/i915: Make compilation of userptr code depend on MMU_NOTIFIER. drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7. drm/i915: Flatten obj->mm.lock drm/i915: Populate logical context during first pin. drm/i915: Make ring submission compatible with obj->mm.lock removal, v2. drm/i915: Handle ww locking in init_status_page drm/i915: Rework clflush to work correctly without obj->mm.lock. drm/i915: Pass ww ctx to intel_pin_to_display_plane drm/i915: Add object locking to vm_fault_cpu drm/i915: Move pinning to inside engine_wa_list_verify() drm/i915: Take reservation lock around i915_vma_pin. drm/i915: Make lrc_init_wa_ctx compatible with ww locking, v3. drm/i915: Make __engine_unpark() compatible with ww locking. drm/i915: Take obj lock around set_domain ioctl drm/i915: Defer pin calls in buffer pool until first use by caller. drm/i915: Fix pread/pwrite to work with new locking rules. drm/i915: Fix workarounds selftest, part 1 drm/i915: Add igt_spinner_pin() to allow for ww locking around spinner. drm/i915: Add ww locking around vm_access() drm/i915: Increase ww locking for perf. drm/i915: Lock ww in ucode objects correctly drm/i915: Add ww locking to dma-buf ops, v2. drm/i915: Add missing ww lock in intel_dsb_prepare. drm/i915: Fix ww locking in shmem_create_from_object drm/i915: Use a single page table lock for each gtt. drm/i915/selftests: Prepare huge_pages testcases for obj->mm.lock removal. drm/i915/selftests: Prepare client blit for obj->mm.lock removal. drm/i915/selftests: Prepare coherency tests for obj->mm.lock removal. drm/i915/selftests: Prepare context tests for obj->mm.lock removal. drm/i915/selftests: Prepare dma-buf tests for obj->mm.lock removal. drm/i915/selftests: Prepare execbuf tests for obj->mm.lock removal. drm/i915/selftests: Prepare mman testcases for obj->mm.lock removal. drm/i915/selftests: Prepare object tests for obj->mm.lock removal. drm/i915/selftests: Prepare object blit tests for obj->mm.lock removal. drm/i915/selftests: Prepare igt_gem_utils for obj->mm.lock removal drm/i915/selftests: Prepare context selftest for obj->mm.lock removal drm/i915/selftests: Prepare hangcheck for obj->mm.lock removal drm/i915/selftests: Prepare execlists and lrc selftests for obj->mm.lock removal drm/i915/selftests: Prepare mocs tests for obj->mm.lock removal drm/i915/selftests: Prepare ring submission for obj->mm.lock removal drm/i915/selftests: Prepare timeline tests for obj->mm.lock removal drm/i915/selftests: Prepare i915_request tests for obj->mm.lock removal drm/i915/selftests: Prepare memory region tests for obj->mm.lock removal drm/i915/selftests: Prepare cs engine tests for obj->mm.lock removal drm/i915/selftests: Prepare gtt tests for obj->mm.lock removal drm/i915: Finally remove obj->mm.lock. drm/i915: Keep userpointer bindings if seqcount is unchanged, v2. drm/i915: Move gt_revoke() slightly drm/i915: Add missing -EDEADLK path in execbuffer ggtt pinning. drm/i915: Fix pin_map in scheduler selftests drm/i915: Add ww parameter to get_pages() callback drm/i915: Add ww context to prepare_(read/write) drm/i915: Pass ww ctx to pin_map drm/i915: Pass ww ctx to i915_gem_object_pin_pages drm/i915: Remove asynchronous vma binding Thomas Hellström (1): drm/i915: Prepare for obj->mm.lock removal, v2. drivers/gpu/drm/i915/Makefile | 1 - drivers/gpu/drm/i915/display/intel_display.c | 71 +- drivers/gpu/drm/i915/display/intel_display.h | 2 +- drivers/gpu/drm/i915/display/intel_dsb.c | 2 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/display/intel_overlay.c | 34 +- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 67 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 106 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 240 - drivers/gpu/drm/i915/gem/i915_gem_fence.c | 95 -- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 9 +-
[Intel-gfx] [PATCH v9 66/70] drm/i915: Add ww parameter to get_pages() callback
We will need this to support eviction with lmem, so
explicitly pass ww as a parameter.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_pages.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_region.h | 4 +++-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-
drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c | 3 ++-
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 9 ++---
drivers/gpu/drm/i915/gvt/dmabuf.c| 3 ++-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 3 ++-
13 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 0926e0895ee6..1b3998c066a7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -199,7 +199,8 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object
*gem_obj, int flags)
return drm_gem_dmabuf_export(gem_obj->dev, _info);
}
-static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
+static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww)
{
struct sg_table *pages;
unsigned int sg_page_sizes;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index 21cc40897ca8..90777fb5f5e0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -30,7 +30,8 @@ static void internal_free_pages(struct sg_table *st)
kfree(st);
}
-static int i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
+static int i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct sg_table *st;
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 a5bc42c7087a..280f54a75ab1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -50,7 +50,8 @@ struct drm_i915_gem_object_ops {
* being released or under memory pressure (where we attempt to
* reap pages for the shrinker).
*/
- int (*get_pages)(struct drm_i915_gem_object *obj);
+ int (*get_pages)(struct drm_i915_gem_object *obj,
+struct i915_gem_ww_ctx *ww);
void (*put_pages)(struct drm_i915_gem_object *obj,
struct sg_table *pages);
void (*truncate)(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index aed8a37ccdc9..58e222030e10 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -100,7 +100,7 @@ int i915_gem_object_get_pages(struct
drm_i915_gem_object *obj)
return -EFAULT;
}
- err = obj->ops->get_pages(obj);
+ err = obj->ops->get_pages(obj, NULL);
GEM_BUG_ON(!err && !i915_gem_object_has_pages(obj));
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 6a84fb6dde24..6cb8b70c19bf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -20,7 +20,8 @@ i915_gem_object_put_pages_buddy(struct drm_i915_gem_object
*obj,
}
int
-i915_gem_object_get_pages_buddy(struct drm_i915_gem_object *obj)
+i915_gem_object_get_pages_buddy(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww)
{
const u64 max_segment = i915_sg_segment_size();
struct intel_memory_region *mem = obj->mm.region;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index ebddc86d78f7..c6f250aac925 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -9,10 +9,12 @@
#include
struct intel_memory_region;
+struct i915_gem_ww_ctx;
struct drm_i915_gem_object;
struct sg_table;
-int i915_gem_object_get_pages_buddy(struct drm_i915_gem_object *obj);
+int i915_gem_object_get_pages_buddy(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww);
void i915_gem_object_put_pages_buddy(struct drm_i915_gem_object *obj,
[Intel-gfx] [PATCH v9 58/70] drm/i915/selftests: Prepare memory region tests for obj->mm.lock removal
Use the unlocked variants for pin_map and pin_pages, and add lock
around unpinning/putting pages.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index 3e583139f767..759ac7e26e13 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -31,10 +31,12 @@ static void close_objects(struct intel_memory_region *mem,
struct drm_i915_gem_object *obj, *on;
list_for_each_entry_safe(obj, on, objects, st_link) {
+ i915_gem_object_lock(obj, NULL);
if (i915_gem_object_has_pinned_pages(obj))
i915_gem_object_unpin_pages(obj);
/* No polluting the memory region between tests */
__i915_gem_object_put_pages(obj);
+ i915_gem_object_unlock(obj);
list_del(>st_link);
i915_gem_object_put(obj);
}
@@ -69,7 +71,7 @@ static int igt_mock_fill(void *arg)
break;
}
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
i915_gem_object_put(obj);
break;
@@ -109,7 +111,7 @@ igt_object_create(struct intel_memory_region *mem,
if (IS_ERR(obj))
return obj;
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err)
goto put;
@@ -123,8 +125,10 @@ igt_object_create(struct intel_memory_region *mem,
static void igt_object_release(struct drm_i915_gem_object *obj)
{
+ i915_gem_object_lock(obj, NULL);
i915_gem_object_unpin_pages(obj);
__i915_gem_object_put_pages(obj);
+ i915_gem_object_unlock(obj);
list_del(>st_link);
i915_gem_object_put(obj);
}
@@ -509,7 +513,7 @@ static int igt_cpu_check(struct drm_i915_gem_object *obj,
u32 dword, u32 val)
if (err)
return err;
- ptr = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ ptr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(ptr))
return PTR_ERR(ptr);
@@ -614,7 +618,7 @@ static int igt_lmem_create(void *arg)
if (IS_ERR(obj))
return PTR_ERR(obj);
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err)
goto out_put;
@@ -653,7 +657,7 @@ static int igt_lmem_write_gpu(void *arg)
goto out_file;
}
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err)
goto out_put;
@@ -725,7 +729,7 @@ static int igt_lmem_write_cpu(void *arg)
if (IS_ERR(obj))
return PTR_ERR(obj);
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto out_put;
@@ -828,7 +832,7 @@ create_region_for_mapping(struct intel_memory_region *mr,
u64 size, u32 type,
return obj;
}
- addr = i915_gem_object_pin_map(obj, type);
+ addr = i915_gem_object_pin_map_unlocked(obj, type);
if (IS_ERR(addr)) {
i915_gem_object_put(obj);
if (PTR_ERR(addr) == -ENXIO)
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 42/70] drm/i915/selftests: Prepare client blit for obj->mm.lock removal.
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index 175581724d44..baec7bd1fa53 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -52,7 +52,7 @@ static int __igt_client_fill(struct intel_engine_cs *engine)
goto err_flush;
}
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto err_put;
@@ -171,7 +171,7 @@ static int prepare_blit(const struct tiled_blits *t,
u32 src_pitch, dst_pitch;
u32 cmd, *cs;
- cs = i915_gem_object_pin_map(batch, I915_MAP_WC);
+ cs = i915_gem_object_pin_map_unlocked(batch, I915_MAP_WC);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -391,7 +391,7 @@ static int verify_buffer(const struct tiled_blits *t,
y = i915_prandom_u32_max_state(t->height, prng);
p = y * t->width + x;
- vaddr = i915_gem_object_pin_map(buf->vma->obj, I915_MAP_WC);
+ vaddr = i915_gem_object_pin_map_unlocked(buf->vma->obj, I915_MAP_WC);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
@@ -578,7 +578,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
int err;
int i;
- map = i915_gem_object_pin_map(t->scratch.vma->obj, I915_MAP_WC);
+ map = i915_gem_object_pin_map_unlocked(t->scratch.vma->obj,
I915_MAP_WC);
if (IS_ERR(map))
return PTR_ERR(map);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 52/70] drm/i915/selftests: Prepare hangcheck for obj->mm.lock removal
Convert a few calls to use the unlocked versions.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index cdb0ceff3be1..608a67f9c631 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -61,15 +61,15 @@ static int hang_init(struct hang *h, struct intel_gt *gt)
}
i915_gem_object_set_cache_coherency(h->hws, I915_CACHE_LLC);
- vaddr = i915_gem_object_pin_map(h->hws, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map_unlocked(h->hws, I915_MAP_WB);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto err_obj;
}
h->seqno = memset(vaddr, 0xff, PAGE_SIZE);
- vaddr = i915_gem_object_pin_map(h->obj,
- i915_coherent_map_type(gt->i915));
+ vaddr = i915_gem_object_pin_map_unlocked(h->obj,
+
i915_coherent_map_type(gt->i915));
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto err_unpin_hws;
@@ -130,7 +130,7 @@ hang_create_request(struct hang *h, struct intel_engine_cs
*engine)
return ERR_CAST(obj);
}
- vaddr = i915_gem_object_pin_map(obj, i915_coherent_map_type(gt->i915));
+ vaddr = i915_gem_object_pin_map_unlocked(obj,
i915_coherent_map_type(gt->i915));
if (IS_ERR(vaddr)) {
i915_gem_object_put(obj);
i915_vm_put(vm);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 70/70] drm/i915: Remove asynchronous vma binding
The current asynchronous work is done in a dma_fence_work, which
has signalling annotations, because dma_fence_work signals on completion.
On braswell, we can call stop_machine inside fence_work, causing a splat
because memory allocation inside stop_machine is allowed.
Strictly speaking this is a false positive, but go for safe and remove
asynchronous vma binding entirely.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 3 -
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 -
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 1 -
drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 -
drivers/gpu/drm/i915/gt/intel_gtt.h| 2 -
drivers/gpu/drm/i915/i915_gem.c| 6 -
drivers/gpu/drm/i915/i915_vma.c| 174 +++--
drivers/gpu/drm/i915/i915_vma.h| 5 +-
drivers/gpu/drm/i915/i915_vma_types.h | 3 -
9 files changed, 21 insertions(+), 178 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 48b2258091c3..52b35b1a14f1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -505,9 +505,6 @@ static void dbg_poison(struct i915_ggtt *ggtt,
if (!drm_mm_node_allocated(>error_capture))
return;
- if (ggtt->vm.bind_async_flags & I915_VMA_GLOBAL_BIND)
- return; /* beware stop_machine() inversion */
-
GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
mutex_lock(>error_mutex);
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index e08dff376339..0c5a9a767849 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -436,7 +436,6 @@ struct i915_ppgtt *gen6_ppgtt_create(struct intel_gt *gt)
ppgtt->base.vm.pd_shift = ilog2(SZ_4K * SZ_4K / sizeof(gen6_pte_t));
ppgtt->base.vm.top = 1;
- ppgtt->base.vm.bind_async_flags = I915_VMA_LOCAL_BIND;
ppgtt->base.vm.allocate_va_range = gen6_alloc_va_range;
ppgtt->base.vm.clear_range = gen6_ppgtt_clear_range;
ppgtt->base.vm.insert_entries = gen6_ppgtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 176c19633412..92f8a23e66cc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -736,7 +736,6 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt)
goto err_free_pd;
}
- ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index c2fc49495029..2a36b09a3761 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -127,7 +127,6 @@ void i915_ggtt_suspend(struct i915_ggtt *ggtt)
list_for_each_entry_safe(vma, vn, >vm.bound_list, vm_link) {
GEM_BUG_ON(!drm_mm_node_allocated(>node));
- i915_vma_wait_for_bind(vma);
if (i915_vma_is_pinned(vma))
continue;
@@ -671,7 +670,6 @@ static int init_aliasing_ppgtt(struct i915_ggtt *ggtt)
ppgtt->vm.allocate_va_range(>vm, , 0, ggtt->vm.total);
ggtt->alias = ppgtt;
- ggtt->vm.bind_async_flags |= ppgtt->vm.bind_async_flags;
GEM_BUG_ON(ggtt->vm.vma_ops.bind_vma != ggtt_bind_vma);
ggtt->vm.vma_ops.bind_vma = aliasing_gtt_bind_vma;
@@ -911,8 +909,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
IS_CHERRYVIEW(i915) /* fails with concurrent use/update */) {
ggtt->vm.insert_entries = bxt_vtd_ggtt_insert_entries__BKL;
ggtt->vm.insert_page= bxt_vtd_ggtt_insert_page__BKL;
- ggtt->vm.bind_async_flags =
- I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
}
ggtt->invalidate = gen8_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index e67e34e17913..d9d2ca8b4b61 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -230,8 +230,6 @@ struct i915_address_space {
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
- unsigned int bind_async_flags;
-
/*
* Each active user context has its own address space (in full-ppgtt).
* Since the vm may be shared between multiple contexts, we count how
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d23a417295f8..a45ff3b76e93 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -943,12 +943,6 @@
[Intel-gfx] [PATCH v9 19/70] drm/i915: Make ring submission compatible with obj->mm.lock removal, v2.
We map the initial context during first pin.
This allows us to remove pin_map from state allocation, which saves
us a few retry loops. We won't need this until first pin anyway.
intel_ring_submission_setup() is also reworked slightly to do all
pinning in a single ww loop.
Changes since v1:
- Handle -EDEADLK backoff in intel_ring_submission_setup() better.
- Handle smatch errors reported by Dan and testbot.
Signed-off-by: Maarten Lankhorst
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 184 +++---
1 file changed, 118 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 282089d64789..f8ad891ad635 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -436,6 +436,26 @@ static void ring_context_destroy(struct kref *ref)
intel_context_free(ce);
}
+static int ring_context_init_default_state(struct intel_context *ce,
+ struct i915_gem_ww_ctx *ww)
+{
+ struct drm_i915_gem_object *obj = ce->state->obj;
+ void *vaddr;
+
+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
+ shmem_read(ce->engine->default_state, 0,
+ vaddr, ce->engine->context_size);
+
+ i915_gem_object_flush_map(obj);
+ __i915_gem_object_release_map(obj);
+
+ __set_bit(CONTEXT_VALID_BIT, >flags);
+ return 0;
+}
+
static int ring_context_pre_pin(struct intel_context *ce,
struct i915_gem_ww_ctx *ww,
void **unused)
@@ -443,6 +463,13 @@ static int ring_context_pre_pin(struct intel_context *ce,
struct i915_address_space *vm;
int err = 0;
+ if (ce->engine->default_state &&
+ !test_bit(CONTEXT_VALID_BIT, >flags)) {
+ err = ring_context_init_default_state(ce, ww);
+ if (err)
+ return err;
+ }
+
vm = vm_alias(ce->vm);
if (vm)
err = gen6_ppgtt_pin(i915_vm_to_ppgtt((vm)), ww);
@@ -498,22 +525,6 @@ alloc_context_vma(struct intel_engine_cs *engine)
if (IS_IVYBRIDGE(i915))
i915_gem_object_set_cache_coherency(obj, I915_CACHE_L3_LLC);
- if (engine->default_state) {
- void *vaddr;
-
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
- if (IS_ERR(vaddr)) {
- err = PTR_ERR(vaddr);
- goto err_obj;
- }
-
- shmem_read(engine->default_state, 0,
- vaddr, engine->context_size);
-
- i915_gem_object_flush_map(obj);
- __i915_gem_object_release_map(obj);
- }
-
vma = i915_vma_instance(obj, >gt->ggtt->vm, NULL);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
@@ -545,8 +556,6 @@ static int ring_context_alloc(struct intel_context *ce)
return PTR_ERR(vma);
ce->state = vma;
- if (engine->default_state)
- __set_bit(CONTEXT_VALID_BIT, >flags);
}
return 0;
@@ -1151,37 +1160,15 @@ static int gen7_ctx_switch_bb_setup(struct
intel_engine_cs * const engine,
return gen7_setup_clear_gpr_bb(engine, vma);
}
-static int gen7_ctx_switch_bb_init(struct intel_engine_cs *engine)
+static int gen7_ctx_switch_bb_init(struct intel_engine_cs *engine,
+ struct i915_gem_ww_ctx *ww,
+ struct i915_vma *vma)
{
- struct drm_i915_gem_object *obj;
- struct i915_vma *vma;
- int size;
int err;
- size = gen7_ctx_switch_bb_setup(engine, NULL /* probe size */);
- if (size <= 0)
- return size;
-
- size = ALIGN(size, PAGE_SIZE);
- obj = i915_gem_object_create_internal(engine->i915, size);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
- vma = i915_vma_instance(obj, engine->gt->vm, NULL);
- if (IS_ERR(vma)) {
- err = PTR_ERR(vma);
- goto err_obj;
- }
-
- vma->private = intel_context_create(engine); /* dummy residuals */
- if (IS_ERR(vma->private)) {
- err = PTR_ERR(vma->private);
- goto err_obj;
- }
-
- err = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_HIGH);
+ err = i915_vma_pin_ww(vma, ww, 0, 0, PIN_USER | PIN_HIGH);
if (err)
- goto err_private;
+ return err;
err = i915_vma_sync(vma);
if (err)
@@ -1196,17 +1183,53 @@ static int gen7_ctx_switch_bb_init(struct
intel_engine_cs *engine)
err_unpin:
i915_vma_unpin(vma);
-err_private:
-
[Intel-gfx] [PATCH v9 61/70] drm/i915: Finally remove obj->mm.lock.
With all callers and selftests fixed to use ww locking, we can now
finally remove this lock.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 -
drivers/gpu/drm/i915/gem/i915_gem_object.h| 5 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 -
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 43 ---
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 34 ---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 37 +++-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.h | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 -
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 +-
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 6 ---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
14 files changed, 55 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 821cb40f8d73..ea74cbca95be 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -62,8 +62,6 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops,
struct lock_class_key *key, unsigned flags)
{
- mutex_init(>mm.lock);
-
spin_lock_init(>vma.lock);
INIT_LIST_HEAD(>vma.list);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 5fffa6f07560..7a252dc4237f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -155,7 +155,7 @@ static inline void assert_object_held_shared(struct
drm_i915_gem_object *obj)
*/
if (IS_ENABLED(CONFIG_LOCKDEP) &&
kref_read(>base.refcount) > 0)
- lockdep_assert_held(>mm.lock);
+ assert_object_held(obj);
}
static inline int __i915_gem_object_lock(struct drm_i915_gem_object *obj,
@@ -384,7 +384,7 @@ int __i915_gem_object_get_pages(struct drm_i915_gem_object
*obj);
static inline int __must_check
i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
{
- might_lock(>mm.lock);
+ assert_object_held(obj);
if (atomic_inc_not_zero(>mm.pages_pin_count))
return 0;
@@ -430,7 +430,6 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
}
int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
-int __i915_gem_object_put_pages_locked(struct drm_i915_gem_object *obj);
void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
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 4c0a34231623..a5bc42c7087a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -222,7 +222,6 @@ struct drm_i915_gem_object {
* Protects the pages and their use. Do not use directly, but
* instead go through the pin/unpin interfaces.
*/
- struct mutex lock;
atomic_t pages_pin_count;
atomic_t shrink_pin;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 5b8af8f83ee3..aed8a37ccdc9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -70,7 +70,7 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
*obj,
struct list_head *list;
unsigned long flags;
- lockdep_assert_held(>mm.lock);
+ assert_object_held(obj);
spin_lock_irqsave(>mm.obj_lock, flags);
i915->mm.shrink_count++;
@@ -117,9 +117,7 @@ int __i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
{
int err;
- err = mutex_lock_interruptible(>mm.lock);
- if (err)
- return err;
+ assert_object_held(obj);
assert_object_held_shared(obj);
@@ -128,15 +126,13 @@ int __i915_gem_object_get_pages(struct
drm_i915_gem_object *obj)
err = i915_gem_object_get_pages(obj);
if (err)
- goto unlock;
+ return err;
smp_mb__before_atomic();
}
atomic_inc(>mm.pages_pin_count);
-unlock:
- mutex_unlock(>mm.lock);
- return err;
+ return 0;
}
int i915_gem_object_pin_pages_unlocked(struct drm_i915_gem_object *obj)
@@ -223,7 +219,7 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
return pages;
}
-int __i915_gem_object_put_pages_locked(struct
[Intel-gfx] [PATCH v9 28/70] drm/i915: Take obj lock around set_domain ioctl
We need to lock the object to move it to the correct domain,
add the missing lock.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 41 ++
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 41dae0d83dbb..e3537922183b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -456,13 +456,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
* userptr validity
*/
err = i915_gem_object_userptr_validate(obj);
- if (!err)
- err = i915_gem_object_wait(obj,
- I915_WAIT_INTERRUPTIBLE |
- I915_WAIT_PRIORITY |
- (write_domain ?
I915_WAIT_ALL : 0),
- MAX_SCHEDULE_TIMEOUT);
- goto out;
+ goto out_wait;
}
/*
@@ -476,6 +470,10 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
goto out;
}
+ err = i915_gem_object_lock_interruptible(obj, NULL);
+ if (err)
+ goto out;
+
/*
* Flush and acquire obj->pages so that we are coherent through
* direct access in memory with previous cached writes through
@@ -487,7 +485,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
*/
err = i915_gem_object_pin_pages(obj);
if (err)
- goto out;
+ goto out_unlock;
/*
* Already in the desired write domain? Nothing for us to do!
@@ -500,10 +498,6 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
* without having to further check the requested write_domain.
*/
if (READ_ONCE(obj->write_domain) == read_domains)
- goto out_wait;
-
- err = i915_gem_object_lock_interruptible(obj, NULL);
- if (err)
goto out_unpin;
if (read_domains & I915_GEM_DOMAIN_WC)
@@ -513,19 +507,22 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
else
i915_gem_object_set_to_cpu_domain(obj, write_domain);
- i915_gem_object_unlock(obj);
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_unlock:
+ i915_gem_object_unlock(obj);
out_wait:
- err = i915_gem_object_wait(obj,
- I915_WAIT_INTERRUPTIBLE |
- I915_WAIT_PRIORITY |
- (write_domain ? I915_WAIT_ALL : 0),
- MAX_SCHEDULE_TIMEOUT);
- if (write_domain)
- i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
+ if (!err) {
+ err = i915_gem_object_wait(obj,
+ I915_WAIT_INTERRUPTIBLE |
+ I915_WAIT_PRIORITY |
+ (write_domain ? I915_WAIT_ALL : 0),
+ MAX_SCHEDULE_TIMEOUT);
+ if (write_domain)
+ i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
+ }
-out_unpin:
- i915_gem_object_unpin_pages(obj);
out:
i915_gem_object_put(obj);
return err;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 41/70] drm/i915/selftests: Prepare huge_pages testcases for obj->mm.lock removal.
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 28 ++-
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 515dbc468175..d85ca79ac433 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -585,7 +585,7 @@ static int igt_mock_ppgtt_misaligned_dma(void *arg)
goto out_put;
}
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err)
goto out_put;
@@ -649,15 +649,19 @@ static int igt_mock_ppgtt_misaligned_dma(void *arg)
break;
}
+ i915_gem_object_lock(obj, NULL);
i915_gem_object_unpin_pages(obj);
__i915_gem_object_put_pages(obj);
+ i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
}
return 0;
out_unpin:
+ i915_gem_object_lock(obj, NULL);
i915_gem_object_unpin_pages(obj);
+ i915_gem_object_unlock(obj);
out_put:
i915_gem_object_put(obj);
@@ -671,8 +675,10 @@ static void close_object_list(struct list_head *objects,
list_for_each_entry_safe(obj, on, objects, st_link) {
list_del(>st_link);
+ i915_gem_object_lock(obj, NULL);
i915_gem_object_unpin_pages(obj);
__i915_gem_object_put_pages(obj);
+ i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
}
}
@@ -709,7 +715,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
break;
}
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
i915_gem_object_put(obj);
break;
@@ -885,7 +891,7 @@ static int igt_mock_ppgtt_64K(void *arg)
if (IS_ERR(obj))
return PTR_ERR(obj);
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err)
goto out_object_put;
@@ -939,8 +945,10 @@ static int igt_mock_ppgtt_64K(void *arg)
}
i915_vma_unpin(vma);
+ i915_gem_object_lock(obj, NULL);
i915_gem_object_unpin_pages(obj);
__i915_gem_object_put_pages(obj);
+ i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
}
}
@@ -950,7 +958,9 @@ static int igt_mock_ppgtt_64K(void *arg)
out_vma_unpin:
i915_vma_unpin(vma);
out_object_unpin:
+ i915_gem_object_lock(obj, NULL);
i915_gem_object_unpin_pages(obj);
+ i915_gem_object_unlock(obj);
out_object_put:
i915_gem_object_put(obj);
@@ -1012,7 +1022,7 @@ static int __cpu_check_vmap(struct drm_i915_gem_object
*obj, u32 dword, u32 val)
if (err)
return err;
- ptr = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ ptr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(ptr))
return PTR_ERR(ptr);
@@ -1292,7 +1302,7 @@ static int igt_ppgtt_smoke_huge(void *arg)
return err;
}
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
if (err == -ENXIO || err == -E2BIG) {
i915_gem_object_put(obj);
@@ -1315,8 +1325,10 @@ static int igt_ppgtt_smoke_huge(void *arg)
__func__, size, i);
}
out_unpin:
+ i915_gem_object_lock(obj, NULL);
i915_gem_object_unpin_pages(obj);
__i915_gem_object_put_pages(obj);
+ i915_gem_object_unlock(obj);
out_put:
i915_gem_object_put(obj);
@@ -1390,7 +1402,7 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
i915_gem_object_put(obj);
goto out;
@@ -1404,8 +1416,10 @@ static int igt_ppgtt_sanity_check(void *arg)
err = igt_write_huge(ctx, obj);
+
[Intel-gfx] [PATCH v9 62/70] drm/i915: Keep userpointer bindings if seqcount is unchanged, v2.
Instead of force unbinding and rebinding every time, we try to check
if our notifier seqcount is still correct when pages are bound. This
way we only rebind userptr when we need to, and prevent stalls.
Changes since v1:
- Missing mutex_unlock, reported by kbuild.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Reviewed-by: Thomas Hellström
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 27 ++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 3babecd14b47..09b4219eab5d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -281,12 +281,33 @@ int i915_gem_object_userptr_submit_init(struct
drm_i915_gem_object *obj)
if (ret)
return ret;
- /* Make sure userptr is unbound for next attempt, so we don't use stale
pages. */
- ret = i915_gem_object_userptr_unbind(obj, false);
+ /* optimistically try to preserve current pages while unlocked */
+ if (i915_gem_object_has_pages(obj) &&
+ !mmu_interval_check_retry(>userptr.notifier,
+ obj->userptr.notifier_seq)) {
+ spin_lock(>mm.notifier_lock);
+ if (obj->userptr.pvec &&
+ !mmu_interval_read_retry(>userptr.notifier,
+obj->userptr.notifier_seq)) {
+ obj->userptr.page_ref++;
+
+ /* We can keep using the current binding, this is the
fastpath */
+ ret = 1;
+ }
+ spin_unlock(>mm.notifier_lock);
+ }
+
+ if (!ret) {
+ /* Make sure userptr is unbound for next attempt, so we don't
use stale pages. */
+ ret = i915_gem_object_userptr_unbind(obj, false);
+ }
i915_gem_object_unlock(obj);
- if (ret)
+ if (ret < 0)
return ret;
+ if (ret > 0)
+ return 0;
+
notifier_seq = mmu_interval_read_begin(>userptr.notifier);
pvec = kvmalloc_array(num_pages, sizeof(struct page *), GFP_KERNEL);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 44/70] drm/i915/selftests: Prepare context tests for obj->mm.lock removal.
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index df949320f2b5..82d5d37e9b66 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1092,7 +1092,7 @@ __read_slice_count(struct intel_context *ce,
if (ret < 0)
return ret;
- buf = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ buf = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(buf)) {
ret = PTR_ERR(buf);
return ret;
@@ -1509,7 +1509,7 @@ static int write_to_scratch(struct i915_gem_context *ctx,
if (IS_ERR(obj))
return PTR_ERR(obj);
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out;
@@ -1620,7 +1620,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
if (err)
goto out_vm;
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out;
@@ -1656,7 +1656,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
if (err)
goto out_vm;
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out;
@@ -1715,7 +1715,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
}
i915_request_put(rq);
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out_vm;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 63/70] drm/i915: Move gt_revoke() slightly
We get a lockdep splat when the reset mutex is held, because it can be
taken from fence_wait. This conflicts with the mmu notifier we have,
because we recurse between reset mutex and mmap lock -> mmu notifier.
Remove this recursion by calling revoke_mmaps before taking the lock.
The reset code still needs fixing, as taking mmap locks during reset
is not allowed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_reset.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 990cb4adbb9a..447f589750c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -970,8 +970,6 @@ static int do_reset(struct intel_gt *gt,
intel_engine_mask_t stalled_mask)
{
int err, i;
- gt_revoke(gt);
-
err = __intel_gt_reset(gt, ALL_ENGINES);
for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
msleep(10 * (i + 1));
@@ -1026,6 +1024,9 @@ void intel_gt_reset(struct intel_gt *gt,
might_sleep();
GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >reset.flags));
+
+ gt_revoke(gt);
+
mutex_lock(>reset.mutex);
/* Clear any previous failed attempts at recovery. Time to try again. */
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 39/70] drm/i915: Fix ww locking in shmem_create_from_object
Quick fix, just use the unlocked version. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gt/shmem_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c index a4d8fc9e2374..f8f02aab842b 100644 --- a/drivers/gpu/drm/i915/gt/shmem_utils.c +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c @@ -39,7 +39,7 @@ struct file *shmem_create_from_object(struct drm_i915_gem_object *obj) return file; } - ptr = i915_gem_object_pin_map(obj, I915_MAP_WB); + ptr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB); if (IS_ERR(ptr)) return ERR_CAST(ptr); -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 49/70] drm/i915/selftests: Prepare object blit tests for obj->mm.lock removal.
Use some unlocked versions where we're not holding the ww lock.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
index c4c04fb97d14..8c335d1a8406 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
@@ -262,7 +262,7 @@ static int igt_fill_blt_thread(void *arg)
goto err_flush;
}
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto err_put;
@@ -380,7 +380,7 @@ static int igt_copy_blt_thread(void *arg)
goto err_flush;
}
- vaddr = i915_gem_object_pin_map(src, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map_unlocked(src, I915_MAP_WB);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto err_put_src;
@@ -400,7 +400,7 @@ static int igt_copy_blt_thread(void *arg)
goto err_put_src;
}
- vaddr = i915_gem_object_pin_map(dst, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map_unlocked(dst, I915_MAP_WB);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto err_put_dst;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 38/70] drm/i915: Add missing ww lock in intel_dsb_prepare.
Because of the long lifetime of the mapping, we cannot wrap this in a
simple limited ww lock. Just use the unlocked version of pin_map,
because we'll likely release the mapping a lot later, in a different
thread.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_dsb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 566fa72427b3..857126822a88 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -293,7 +293,7 @@ void intel_dsb_prepare(struct intel_crtc_state *crtc_state)
goto out;
}
- buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+ buf = i915_gem_object_pin_map_unlocked(vma->obj, I915_MAP_WC);
if (IS_ERR(buf)) {
drm_err(>drm, "Command buffer creation failed\n");
i915_vma_unpin_and_release(, I915_VMA_RELEASE_MAP);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 35/70] drm/i915: Increase ww locking for perf.
We need to lock a few more objects, some temporarily,
add ww lock where needed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_perf.c | 56
1 file changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2fd2c13b76ac..66f1f25119b5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1573,7 +1573,7 @@ static int alloc_oa_buffer(struct i915_perf_stream
*stream)
stream->oa_buffer.vma = vma;
stream->oa_buffer.vaddr =
- i915_gem_object_pin_map(bo, I915_MAP_WB);
+ i915_gem_object_pin_map_unlocked(bo, I915_MAP_WB);
if (IS_ERR(stream->oa_buffer.vaddr)) {
ret = PTR_ERR(stream->oa_buffer.vaddr);
goto err_unpin;
@@ -1627,6 +1627,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
const u32 base = stream->engine->mmio_base;
#define CS_GPR(x) GEN8_RING_CS_GPR(base, x)
u32 *batch, *ts0, *cs, *jump;
+ struct i915_gem_ww_ctx ww;
int ret, i;
enum {
START_TS,
@@ -1644,15 +1645,21 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
return PTR_ERR(bo);
}
+ i915_gem_ww_ctx_init(, true);
+retry:
+ ret = i915_gem_object_lock(bo, );
+ if (ret)
+ goto out_ww;
+
/*
* We pin in GGTT because we jump into this buffer now because
* multiple OA config BOs will have a jump to this address and it
* needs to be fixed during the lifetime of the i915/perf stream.
*/
- vma = i915_gem_object_ggtt_pin(bo, NULL, 0, 0, PIN_HIGH);
+ vma = i915_gem_object_ggtt_pin_ww(bo, , NULL, 0, 0, PIN_HIGH);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
- goto err_unref;
+ goto out_ww;
}
batch = cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
@@ -1786,12 +1793,19 @@ static int alloc_noa_wait(struct i915_perf_stream
*stream)
__i915_gem_object_release_map(bo);
stream->noa_wait = vma;
- return 0;
+ goto out_ww;
err_unpin:
i915_vma_unpin_and_release(, 0);
-err_unref:
- i915_gem_object_put(bo);
+out_ww:
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff();
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+ if (ret)
+ i915_gem_object_put(bo);
return ret;
}
@@ -1834,6 +1848,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
{
struct drm_i915_gem_object *obj;
struct i915_oa_config_bo *oa_bo;
+ struct i915_gem_ww_ctx ww;
size_t config_length = 0;
u32 *cs;
int err;
@@ -1854,10 +1869,16 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
goto err_free;
}
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock(obj, );
+ if (err)
+ goto out_ww;
+
cs = i915_gem_object_pin_map(obj, I915_MAP_WB);
if (IS_ERR(cs)) {
err = PTR_ERR(cs);
- goto err_oa_bo;
+ goto out_ww;
}
cs = write_cs_mi_lri(cs,
@@ -1885,19 +1906,28 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
NULL);
if (IS_ERR(oa_bo->vma)) {
err = PTR_ERR(oa_bo->vma);
- goto err_oa_bo;
+ goto out_ww;
}
oa_bo->oa_config = i915_oa_config_get(oa_config);
llist_add(_bo->node, >oa_config_bos);
- return oa_bo;
+out_ww:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
-err_oa_bo:
- i915_gem_object_put(obj);
+ if (err)
+ i915_gem_object_put(obj);
err_free:
- kfree(oa_bo);
- return ERR_PTR(err);
+ if (err) {
+ kfree(oa_bo);
+ return ERR_PTR(err);
+ }
+ return oa_bo;
}
static struct i915_vma *
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 21/70] drm/i915: Rework clflush to work correctly without obj->mm.lock.
Pin in the caller, not in the work itself. This should also
work better for dma-fence annotations.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index a28f8c912a3e..e4c24558eaa8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -27,15 +27,8 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
static int clflush_work(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
- struct drm_i915_gem_object *obj = clflush->obj;
- int err;
- err = i915_gem_object_pin_pages(obj);
- if (err)
- return err;
-
- __do_clflush(obj);
- i915_gem_object_unpin_pages(obj);
+ __do_clflush(clflush->obj);
return 0;
}
@@ -44,6 +37,7 @@ static void clflush_release(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
+ i915_gem_object_unpin_pages(clflush->obj);
i915_gem_object_put(clflush->obj);
}
@@ -61,6 +55,11 @@ static struct clflush *clflush_work_create(struct
drm_i915_gem_object *obj)
if (!clflush)
return NULL;
+ if (__i915_gem_object_get_pages(obj) < 0) {
+ kfree(clflush);
+ return NULL;
+ }
+
dma_fence_work_init(>base, _ops);
clflush->obj = i915_gem_object_get(obj); /* obj <-> clflush cycle */
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 65/70] drm/i915: Fix pin_map in scheduler selftests
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/selftests/i915_scheduler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_scheduler.c
b/drivers/gpu/drm/i915/selftests/i915_scheduler.c
index f54bdbeaa48b..4c306e40c416 100644
--- a/drivers/gpu/drm/i915/selftests/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/selftests/i915_scheduler.c
@@ -645,7 +645,7 @@ static int __igt_schedule_cycle(struct drm_i915_private
*i915,
if (IS_ERR(obj))
return PTR_ERR(obj);
- time = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ time = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(time)) {
err = PTR_ERR(time);
goto out_obj;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 37/70] drm/i915: Add ww locking to dma-buf ops, v2.
vmap is using pin_pages, but needs to use ww locking,
add pin_pages_unlocked to correctly lock the mapping.
Also add ww locking to begin/end cpu access.
Changes since v1:
- Fix i915_gem_map_dma_buf by using pin_pages_unlocked().
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 62 --
1 file changed, 34 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index c7100a83b8ea..0926e0895ee6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -25,7 +25,7 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
struct scatterlist *src, *dst;
int ret, i;
- ret = i915_gem_object_pin_pages(obj);
+ ret = i915_gem_object_pin_pages_unlocked(obj);
if (ret)
goto err;
@@ -82,7 +82,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf,
struct dma_buf_map *map
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
void *vaddr;
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
@@ -123,42 +123,48 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
bool write = (direction == DMA_BIDIRECTIONAL || direction ==
DMA_TO_DEVICE);
+ struct i915_gem_ww_ctx ww;
int err;
- err = i915_gem_object_pin_pages(obj);
- if (err)
- return err;
-
- err = i915_gem_object_lock_interruptible(obj, NULL);
- if (err)
- goto out;
-
- i915_gem_object_set_to_cpu_domain(obj, write);
- i915_gem_object_unlock(obj);
-
-out:
- i915_gem_object_unpin_pages(obj);
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock(obj, );
+ if (!err)
+ err = i915_gem_object_pin_pages(obj);
+ if (!err) {
+ i915_gem_object_set_to_cpu_domain(obj, write);
+ i915_gem_object_unpin_pages(obj);
+ }
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
return err;
}
static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+ struct i915_gem_ww_ctx ww;
int err;
- err = i915_gem_object_pin_pages(obj);
- if (err)
- return err;
-
- err = i915_gem_object_lock_interruptible(obj, NULL);
- if (err)
- goto out;
-
- i915_gem_object_set_to_gtt_domain(obj, false);
- i915_gem_object_unlock(obj);
-
-out:
- i915_gem_object_unpin_pages(obj);
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock(obj, );
+ if (!err)
+ err = i915_gem_object_pin_pages(obj);
+ if (!err) {
+ i915_gem_object_set_to_gtt_domain(obj, false);
+ i915_gem_object_unpin_pages(obj);
+ }
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
return err;
}
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 23/70] drm/i915: Add object locking to vm_fault_cpu
Take a simple lock so we hold ww around (un)pin_pages as needed. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index c0034d811e50..163208a6260d 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -246,6 +246,9 @@ static vm_fault_t vm_fault_cpu(struct vm_fault *vmf) area->vm_flags & VM_WRITE)) return VM_FAULT_SIGBUS; + if (i915_gem_object_lock_interruptible(obj, NULL)) + return VM_FAULT_NOPAGE; + err = i915_gem_object_pin_pages(obj); if (err) goto out; @@ -269,6 +272,7 @@ static vm_fault_t vm_fault_cpu(struct vm_fault *vmf) i915_gem_object_unpin_pages(obj); out: + i915_gem_object_unlock(obj); return i915_error_to_vmf_fault(err); } -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 57/70] drm/i915/selftests: Prepare i915_request tests for obj->mm.lock removal
Straightforward conversion by using unlocked versions.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/selftests/i915_request.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 8035ea7565ed..a27cc504f839 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -619,7 +619,7 @@ static struct i915_vma *empty_batch(struct drm_i915_private
*i915)
if (IS_ERR(obj))
return ERR_CAST(obj);
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto err;
@@ -781,7 +781,7 @@ static struct i915_vma *recursive_batch(struct
drm_i915_private *i915)
if (err)
goto err;
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto err;
@@ -816,7 +816,7 @@ static int recursive_batch_resolve(struct i915_vma *batch)
{
u32 *cmd;
- cmd = i915_gem_object_pin_map(batch->obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(batch->obj, I915_MAP_WC);
if (IS_ERR(cmd))
return PTR_ERR(cmd);
@@ -1069,8 +1069,8 @@ static int live_sequential_engines(void *arg)
if (!request[idx])
break;
- cmd = i915_gem_object_pin_map(request[idx]->batch->obj,
- I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(request[idx]->batch->obj,
+ I915_MAP_WC);
if (!IS_ERR(cmd)) {
*cmd = MI_BATCH_BUFFER_END;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 25/70] drm/i915: Take reservation lock around i915_vma_pin.
We previously complained when ww == NULL.
This function is now only used in selftests to pin an object,
and ww locking is now fixed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
.../i915/gem/selftests/i915_gem_coherency.c | 12 ---
drivers/gpu/drm/i915/i915_gem.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 4 +---
drivers/gpu/drm/i915/i915_vma.h | 20 +++
4 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index b5dbf15570fc..3eec385d43bb 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -218,15 +218,13 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
u32 *cs;
int err;
+ vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
i915_gem_object_lock(ctx->obj, NULL);
i915_gem_object_set_to_gtt_domain(ctx->obj, false);
- vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
- if (IS_ERR(vma)) {
- err = PTR_ERR(vma);
- goto out_unlock;
- }
-
rq = intel_engine_create_kernel_request(ctx->engine);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
@@ -265,9 +263,7 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
i915_request_add(rq);
out_unpin:
i915_vma_unpin(vma);
-out_unlock:
i915_gem_object_unlock(ctx->obj);
-
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3dee4e31fb14..8373662e4b5f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -920,7 +920,11 @@ i915_gem_object_ggtt_pin_ww(struct drm_i915_gem_object
*obj,
return ERR_PTR(ret);
}
- ret = i915_vma_pin_ww(vma, ww, size, alignment, flags | PIN_GLOBAL);
+ if (ww)
+ ret = i915_vma_pin_ww(vma, ww, size, alignment, flags |
PIN_GLOBAL);
+ else
+ ret = i915_vma_pin(vma, size, alignment, flags | PIN_GLOBAL);
+
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 1ffda2aaa7a0..265e3a3079e2 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -863,9 +863,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
int err;
#ifdef CONFIG_PROVE_LOCKING
- if (debug_locks && lockdep_is_held(>vm->i915->drm.struct_mutex))
- WARN_ON(!ww);
- if (debug_locks && ww && vma->resv)
+ if (debug_locks && !WARN_ON(!ww) && vma->resv)
assert_vma_held(vma);
#endif
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 6b48f5c42488..8df784a026d2 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -246,10 +246,22 @@ i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
static inline int __must_check
i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
{
-#ifdef CONFIG_LOCKDEP
- WARN_ON_ONCE(vma->resv && dma_resv_held(vma->resv));
-#endif
- return i915_vma_pin_ww(vma, NULL, size, alignment, flags);
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock(vma->obj, );
+ if (!err)
+ err = i915_vma_pin_ww(vma, , size, alignment, flags);
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
+ return err;
}
int i915_ggtt_pin(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 69/70] drm/i915: Pass ww ctx to i915_gem_object_pin_pages
This is the final part of passing ww ctx to the get_pages() callbacks.
Now we no longer have to implicitly get ww ctx by using get_ww_ctx.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 4 +--
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 35 +--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 11 +++---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +--
drivers/gpu/drm/i915/i915_gem.c | 6 ++--
drivers/gpu/drm/i915/i915_vma.c | 7 ++--
13 files changed, 70 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 56b63731af60..31f9685557f7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1155,7 +1155,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
if (!ret && phys_cursor)
ret = i915_gem_object_attach_phys(obj, alignment);
if (!ret)
- ret = i915_gem_object_pin_pages(obj);
+ ret = i915_gem_object_pin_pages(obj, );
if (ret)
goto err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index e4c24558eaa8..109f5c8b802a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -55,7 +55,7 @@ static struct clflush *clflush_work_create(struct
drm_i915_gem_object *obj)
if (!clflush)
return NULL;
- if (__i915_gem_object_get_pages(obj) < 0) {
+ if (__i915_gem_object_get_pages(obj, NULL) < 0) {
kfree(clflush);
return NULL;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 1b3998c066a7..35ac62d4dea2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -130,7 +130,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
retry:
err = i915_gem_object_lock(obj, );
if (!err)
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages(obj, );
if (!err) {
i915_gem_object_set_to_cpu_domain(obj, write);
i915_gem_object_unpin_pages(obj);
@@ -154,7 +154,7 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direct
retry:
err = i915_gem_object_lock(obj, );
if (!err)
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages(obj, );
if (!err) {
i915_gem_object_set_to_gtt_domain(obj, false);
i915_gem_object_unpin_pages(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index a5b3a21faf9c..27dde2b9597e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -430,6 +430,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_gem_object *obj;
u32 read_domains = args->read_domains;
u32 write_domain = args->write_domain;
+ struct i915_gem_ww_ctx ww;
int err;
/* Only handle setting domains to types used by the CPU. */
@@ -456,7 +457,15 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
* userptr validity
*/
err = i915_gem_object_userptr_validate(obj);
- goto out_wait;
+ if (err)
+ goto out;
+
+ err = i915_gem_object_wait(obj,
+ I915_WAIT_INTERRUPTIBLE |
+ I915_WAIT_PRIORITY |
+ (write_domain ? I915_WAIT_ALL : 0),
+ MAX_SCHEDULE_TIMEOUT);
+ goto out;
}
/*
@@ -470,9 +479,11 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
goto out;
}
- err = i915_gem_object_lock_interruptible(obj, NULL);
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock_interruptible(obj, );
if (err)
- goto out;
+ goto out_ww;
/*
* Flush and acquire obj->pages so that we are coherent through
@@ -483,9 +494,9 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
[Intel-gfx] [PATCH v9 51/70] drm/i915/selftests: Prepare context selftest for obj->mm.lock removal
Only needs to convert a single call to the unlocked version.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index a02fd70644e2..b9bdd1d23243 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -87,8 +87,8 @@ static int __live_context_size(struct intel_engine_cs *engine)
if (err)
goto err;
- vaddr = i915_gem_object_pin_map(ce->state->obj,
- i915_coherent_map_type(engine->i915));
+ vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
+
i915_coherent_map_type(engine->i915));
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
intel_context_unpin(ce);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 50/70] drm/i915/selftests: Prepare igt_gem_utils for obj->mm.lock removal
igt_emit_store_dw needs to use the unlocked version, as it's not
holding a lock. This fixes igt_gpu_fill_dw() which is used by
some other selftests.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c
b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c
index b7e064667d39..ba8c06778b6c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c
+++ b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c
@@ -56,7 +56,7 @@ igt_emit_store_dw(struct i915_vma *vma,
if (IS_ERR(obj))
return ERR_CAST(obj);
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto err;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 05/70] drm/i915: Ensure we hold the object mutex in pin correctly.
Currently we have a lot of places where we hold the gem object lock,
but haven't yet been converted to the ww dance. Complain loudly about
those places.
i915_vma_pin shouldn't have the obj lock held, so we can do a ww dance,
while i915_vma_pin_ww should.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström #irc
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 11 ++-
drivers/gpu/drm/i915/i915_vma.h | 3 +++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index 0f7c0a148b80..b03e197b1d99 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -176,7 +176,7 @@ int intel_renderstate_init(struct intel_renderstate *so,
if (err)
goto err_context;
- err = i915_vma_pin(so->vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ err = i915_vma_pin_ww(so->vma, >ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
goto err_context;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index caa9b041616b..7310893086f7 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -865,6 +865,8 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
#ifdef CONFIG_PROVE_LOCKING
if (debug_locks && lockdep_is_held(>vm->i915->drm.struct_mutex))
WARN_ON(!ww);
+ if (debug_locks && ww && vma->resv)
+ assert_vma_held(vma);
#endif
BUILD_BUG_ON(PIN_GLOBAL != I915_VMA_GLOBAL_BIND);
@@ -1020,8 +1022,15 @@ int i915_ggtt_pin(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
GEM_BUG_ON(!i915_vma_is_ggtt(vma));
+#ifdef CONFIG_LOCKDEP
+ WARN_ON(!ww && vma->resv && dma_resv_held(vma->resv));
+#endif
+
do {
- err = i915_vma_pin_ww(vma, ww, 0, align, flags | PIN_GLOBAL);
+ if (ww)
+ err = i915_vma_pin_ww(vma, ww, 0, align, flags |
PIN_GLOBAL);
+ else
+ err = i915_vma_pin(vma, 0, align, flags | PIN_GLOBAL);
if (err != -ENOSPC) {
if (!err) {
err = i915_vma_wait_for_bind(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index a64adc8c883b..3c914c9de9a9 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -243,6 +243,9 @@ i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
static inline int __must_check
i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
{
+#ifdef CONFIG_LOCKDEP
+ WARN_ON_ONCE(vma->resv && dma_resv_held(vma->resv));
+#endif
return i915_vma_pin_ww(vma, NULL, size, alignment, flags);
}
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 48/70] drm/i915/selftests: Prepare object tests for obj->mm.lock removal.
Convert a single pin_pages call to use the unlocked version.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
index bf853c40ec65..740ee8086a27 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
@@ -47,7 +47,7 @@ static int igt_gem_huge(void *arg)
if (IS_ERR(obj))
return PTR_ERR(obj);
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
pr_err("Failed to allocate %u pages (%lu total), err=%d\n",
nreal, obj->base.size / PAGE_SIZE, err);
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 54/70] drm/i915/selftests: Prepare mocs tests for obj->mm.lock removal
Use pin_map_unlocked when we're not holding locks.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index 01dd050d4161..e55a887d11e2 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -79,7 +79,7 @@ static int live_mocs_init(struct live_mocs *arg, struct
intel_gt *gt)
if (IS_ERR(arg->scratch))
return PTR_ERR(arg->scratch);
- arg->vaddr = i915_gem_object_pin_map(arg->scratch->obj, I915_MAP_WB);
+ arg->vaddr = i915_gem_object_pin_map_unlocked(arg->scratch->obj,
I915_MAP_WB);
if (IS_ERR(arg->vaddr)) {
err = PTR_ERR(arg->vaddr);
goto err_scratch;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 30/70] drm/i915: Fix pread/pwrite to work with new locking rules.
We are removing obj->mm.lock, and need to take the reservation lock
before we can pin pages. Move the pinning pages into the helper, and
merge gtt pwrite/pread preparation and cleanup paths.
The fence lock is also removed; it will conflict with fence annotations,
because of memory allocations done when pagefaulting inside copy_*_user.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_fence.c | 95 -
drivers/gpu/drm/i915/gem/i915_gem_object.h | 5 -
drivers/gpu/drm/i915/i915_gem.c| 215 +++--
4 files changed, 112 insertions(+), 204 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gem/i915_gem_fence.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 33c2100414a0..70a535798ef5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -140,7 +140,6 @@ gem-y += \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer.o \
- gem/i915_gem_fence.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_object_blt.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_fence.c
b/drivers/gpu/drm/i915/gem/i915_gem_fence.c
deleted file mode 100644
index 8ab842c80f99..
--- a/drivers/gpu/drm/i915/gem/i915_gem_fence.c
+++ /dev/null
@@ -1,95 +0,0 @@
-/*
- * SPDX-License-Identifier: MIT
- *
- * Copyright © 2019 Intel Corporation
- */
-
-#include "i915_drv.h"
-#include "i915_gem_object.h"
-
-struct stub_fence {
- struct dma_fence dma;
- struct i915_sw_fence chain;
-};
-
-static int __i915_sw_fence_call
-stub_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
-{
- struct stub_fence *stub = container_of(fence, typeof(*stub), chain);
-
- switch (state) {
- case FENCE_COMPLETE:
- dma_fence_signal(>dma);
- break;
-
- case FENCE_FREE:
- dma_fence_put(>dma);
- break;
- }
-
- return NOTIFY_DONE;
-}
-
-static const char *stub_driver_name(struct dma_fence *fence)
-{
- return DRIVER_NAME;
-}
-
-static const char *stub_timeline_name(struct dma_fence *fence)
-{
- return "object";
-}
-
-static void stub_release(struct dma_fence *fence)
-{
- struct stub_fence *stub = container_of(fence, typeof(*stub), dma);
-
- i915_sw_fence_fini(>chain);
-
- BUILD_BUG_ON(offsetof(typeof(*stub), dma));
- dma_fence_free(>dma);
-}
-
-static const struct dma_fence_ops stub_fence_ops = {
- .get_driver_name = stub_driver_name,
- .get_timeline_name = stub_timeline_name,
- .release = stub_release,
-};
-
-struct dma_fence *
-i915_gem_object_lock_fence(struct drm_i915_gem_object *obj)
-{
- struct stub_fence *stub;
-
- assert_object_held(obj);
-
- stub = kmalloc(sizeof(*stub), GFP_KERNEL);
- if (!stub)
- return NULL;
-
- i915_sw_fence_init(>chain, stub_notify);
- dma_fence_init(>dma, _fence_ops, >chain.wait.lock,
- 0, 0);
-
- if (i915_sw_fence_await_reservation(>chain,
- obj->base.resv, NULL, true,
-
i915_fence_timeout(to_i915(obj->base.dev)),
- I915_FENCE_GFP) < 0)
- goto err;
-
- dma_resv_add_excl_fence(obj->base.resv, >dma);
-
- return >dma;
-
-err:
- stub_release(>dma);
- return NULL;
-}
-
-void i915_gem_object_unlock_fence(struct drm_i915_gem_object *obj,
- struct dma_fence *fence)
-{
- struct stub_fence *stub = container_of(fence, typeof(*stub), dma);
-
- i915_sw_fence_commit(>chain);
-}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index fef0d62f3eb7..6c3f75adb53c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -189,11 +189,6 @@ static inline void i915_gem_object_unlock(struct
drm_i915_gem_object *obj)
dma_resv_unlock(obj->base.resv);
}
-struct dma_fence *
-i915_gem_object_lock_fence(struct drm_i915_gem_object *obj);
-void i915_gem_object_unlock_fence(struct drm_i915_gem_object *obj,
- struct dma_fence *fence);
-
static inline void
i915_gem_object_set_readonly(struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8373662e4b5f..eeb952889e4a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -204,7 +204,6 @@ i915_gem_shmem_pread(struct drm_i915_gem_object *obj,
{
unsigned int needs_clflush;
unsigned int idx, offset;
- struct dma_fence *fence;
char __user *user_data;
u64 remain;
int ret;
@@ -213,19 +212,17 @@
[Intel-gfx] [PATCH v9 47/70] drm/i915/selftests: Prepare mman testcases for obj->mm.lock removal.
Ensure we hold the lock around put_pages, and use the unlocked wrappers
for pinning pages and mappings.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 49f17708c143..090e77c2a6dc 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -306,7 +306,7 @@ static int igt_partial_tiling(void *arg)
if (IS_ERR(obj))
return PTR_ERR(obj);
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
pr_err("Failed to allocate %u pages (%lu total), err=%d\n",
nreal, obj->base.size / PAGE_SIZE, err);
@@ -443,7 +443,7 @@ static int igt_smoke_tiling(void *arg)
if (IS_ERR(obj))
return PTR_ERR(obj);
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
pr_err("Failed to allocate %u pages (%lu total), err=%d\n",
nreal, obj->base.size / PAGE_SIZE, err);
@@ -782,7 +782,7 @@ static int wc_set(struct drm_i915_gem_object *obj)
{
void *vaddr;
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
@@ -798,7 +798,7 @@ static int wc_check(struct drm_i915_gem_object *obj)
void *vaddr;
int err = 0;
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
@@ -1300,7 +1300,9 @@ static int __igt_mmap_revoke(struct drm_i915_private
*i915,
}
if (type != I915_MMAP_TYPE_GTT) {
+ i915_gem_object_lock(obj, NULL);
__i915_gem_object_put_pages(obj);
+ i915_gem_object_unlock(obj);
if (i915_gem_object_has_pages(obj)) {
pr_err("Failed to put-pages object!\n");
err = -EINVAL;
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 43/70] drm/i915/selftests: Prepare coherency tests for obj->mm.lock removal.
Straightforward conversion, just convert a bunch of calls to unlocked versions. Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c index 3eec385d43bb..8f2e447bd503 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c @@ -174,7 +174,7 @@ static int wc_set(struct context *ctx, unsigned long offset, u32 v) if (err) return err; - map = i915_gem_object_pin_map(ctx->obj, I915_MAP_WC); + map = i915_gem_object_pin_map_unlocked(ctx->obj, I915_MAP_WC); if (IS_ERR(map)) return PTR_ERR(map); @@ -201,7 +201,7 @@ static int wc_get(struct context *ctx, unsigned long offset, u32 *v) if (err) return err; - map = i915_gem_object_pin_map(ctx->obj, I915_MAP_WC); + map = i915_gem_object_pin_map_unlocked(ctx->obj, I915_MAP_WC); if (IS_ERR(map)) return PTR_ERR(map); -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 15/70] drm/i915: Make compilation of userptr code depend on MMU_NOTIFIER.
Now that unsynchronized mappings are removed, the only time userptr
works is when the MMU notifier is enabled. Put all of the userptr
code behind a mmu notifier ifdef.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 58 +++
drivers/gpu/drm/i915/i915_drv.h | 2 +
5 files changed, 31 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3c37a85c0d9d..795c68fcc6ed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1971,8 +1971,10 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb,
err = 0;
}
+#ifdef CONFIG_MMU_NOTIFIER
if (!err)
flush_workqueue(eb->i915->mm.userptr_wq);
+#endif
err_relock:
i915_gem_ww_ctx_init(>ww, true);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 1008c6c47809..69509dbd01c7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -576,7 +576,11 @@ void __i915_gem_object_invalidate_frontbuffer(struct
drm_i915_gem_object *obj,
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
{
+#ifdef CONFIG_MMU_NOTIFIER
return obj->userptr.mm;
+#else
+ return false;
+#endif
}
static inline void
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 0320508b66b3..414322619781 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -296,6 +296,7 @@ struct drm_i915_gem_object {
unsigned long *bit_17;
union {
+#ifdef CONFIG_MMU_NOTIFIER
struct i915_gem_userptr {
uintptr_t ptr;
@@ -303,6 +304,7 @@ struct drm_i915_gem_object {
struct i915_mmu_object *mmu_object;
struct work_struct *work;
} userptr;
+#endif
struct drm_mm_node *stolen;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 80bc10b4ac74..b466ab2def4d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -15,6 +15,8 @@
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
+#if defined(CONFIG_MMU_NOTIFIER)
+
struct i915_mm_struct {
struct mm_struct *mm;
struct drm_i915_private *i915;
@@ -24,7 +26,6 @@ struct i915_mm_struct {
struct rcu_work work;
};
-#if defined(CONFIG_MMU_NOTIFIER)
#include
struct i915_mmu_notifier {
@@ -217,15 +218,11 @@ i915_mmu_notifier_find(struct i915_mm_struct *mm)
}
static int
-i915_gem_userptr_init__mmu_notifier(struct drm_i915_gem_object *obj,
- unsigned flags)
+i915_gem_userptr_init__mmu_notifier(struct drm_i915_gem_object *obj)
{
struct i915_mmu_notifier *mn;
struct i915_mmu_object *mo;
- if (flags & I915_USERPTR_UNSYNCHRONIZED)
- return -ENODEV;
-
if (GEM_WARN_ON(!obj->userptr.mm))
return -EINVAL;
@@ -258,32 +255,6 @@ i915_mmu_notifier_free(struct i915_mmu_notifier *mn,
kfree(mn);
}
-#else
-
-static void
-__i915_gem_userptr_set_active(struct drm_i915_gem_object *obj, bool value)
-{
-}
-
-static void
-i915_gem_userptr_release__mmu_notifier(struct drm_i915_gem_object *obj)
-{
-}
-
-static int
-i915_gem_userptr_init__mmu_notifier(struct drm_i915_gem_object *obj,
- unsigned flags)
-{
- return -ENODEV;
-}
-
-static void
-i915_mmu_notifier_free(struct i915_mmu_notifier *mn,
- struct mm_struct *mm)
-{
-}
-
-#endif
static struct i915_mm_struct *
__i915_mm_struct_find(struct drm_i915_private *i915, struct mm_struct *real)
@@ -725,6 +696,8 @@ static const struct drm_i915_gem_object_ops
i915_gem_userptr_ops = {
.release = i915_gem_userptr_release,
};
+#endif
+
/*
* Creates a new mm object that wraps some normal memory from the process
* context - user memory.
@@ -765,12 +738,12 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file)
{
- static struct lock_class_key lock_class;
+ static struct lock_class_key __maybe_unused lock_class;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_userptr *args = data;
- struct drm_i915_gem_object *obj;
- int ret;
- u32 handle;
+ struct drm_i915_gem_object __maybe_unused *obj;
+
[Intel-gfx] [PATCH v9 18/70] drm/i915: Populate logical context during first pin.
This allows us to remove pin_map from state allocation, which saves
us a few retry loops. We won't need this until first pin, anyway.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
.../drm/i915/gt/intel_execlists_submission.c | 26 ---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 85ff5fe861b4..ca6a85537274 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2206,11 +2206,31 @@ static void execlists_preempt(struct timer_list *timer)
execlists_kick(timer, preempt);
}
+static int
+__execlists_context_pre_pin(struct intel_context *ce,
+ struct intel_engine_cs *engine,
+ struct i915_gem_ww_ctx *ww, void **vaddr)
+{
+ int err;
+
+ err = lrc_pre_pin(ce, engine, ww, vaddr);
+ if (err)
+ return err;
+
+ if (!__test_and_set_bit(CONTEXT_INIT_BIT, >flags)) {
+ lrc_init_state(ce, engine, *vaddr);
+
+__i915_gem_object_flush_map(ce->state->obj, 0,
engine->context_size);
+ }
+
+ return 0;
+}
+
static int execlists_context_pre_pin(struct intel_context *ce,
struct i915_gem_ww_ctx *ww,
void **vaddr)
{
- return lrc_pre_pin(ce, ce->engine, ww, vaddr);
+ return __execlists_context_pre_pin(ce, ce->engine, ww, vaddr);
}
static int execlists_context_pin(struct intel_context *ce, void *vaddr)
@@ -3088,8 +3108,8 @@ static int virtual_context_pre_pin(struct intel_context
*ce,
{
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
- /* Note: we must use a real engine class for setting up reg state */
- return lrc_pre_pin(ce, ve->siblings[0], ww, vaddr);
+/* Note: we must use a real engine class for setting up reg state */
+ return __execlists_context_pre_pin(ce, ve->siblings[0], ww, vaddr);
}
static int virtual_context_pin(struct intel_context *ce, void *vaddr)
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 16/70] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transfer those
pages in .get_pages() to the bo. As a final check before installing
the fences, we ensure that the mmu notifier was not called; if it is,
we return -EAGAIN to userspace to signal it has to start over.
Changes since v1:
- Unbinding is done in submit_init only. submit_begin() removed.
- MMU_NOTFIER -> MMU_NOTIFIER
Changes since v2:
- Make i915->mm.notifier a spinlock.
Changes since v3:
- Add WARN_ON if there are any page references left, should have been 0.
- Return 0 on success in submit_init(), bug from spinlock conversion.
- Release pvec outside of notifier_lock (Thomas).
Changes since v4:
- Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
- Actually check all invalidations in eb_move_to_gpu. (Thomas)
- Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
Changes since v5:
- Clarify why check on PF_EXITING is (temporarily) required.
Changes since v6:
- Ensure userptr validity is checked in set_domain through a special path.
Signed-off-by: Maarten Lankhorst
Acked-by: Dave Airlie
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 18 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 101 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 796 ++
drivers/gpu/drm/i915/i915_drv.h | 9 +-
drivers/gpu/drm/i915/i915_gem.c | 5 +-
8 files changed, 395 insertions(+), 584 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 2f4980bf742e..76cb9f5c66aa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -468,14 +468,28 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
if (!obj)
return -ENOENT;
+ if (i915_gem_object_is_userptr(obj)) {
+ /*
+* Try to grab userptr pages, iris uses set_domain to check
+* userptr validity
+*/
+ err = i915_gem_object_userptr_validate(obj);
+ if (!err)
+ err = i915_gem_object_wait(obj,
+ I915_WAIT_INTERRUPTIBLE |
+ I915_WAIT_PRIORITY |
+ (write_domain ?
I915_WAIT_ALL : 0),
+ MAX_SCHEDULE_TIMEOUT);
+ goto out;
+ }
+
/*
* Proxy objects do not control access to the backing storage, ergo
* they cannot be used as a means to manipulate the cache domain
* tracking for that backing storage. The proxy object is always
* considered to be outside of any cache domain.
*/
- if (i915_gem_object_is_proxy(obj) &&
- !i915_gem_object_is_userptr(obj)) {
+ if (i915_gem_object_is_proxy(obj)) {
err = -ENXIO;
goto out;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 795c68fcc6ed..b5ca9eb53565 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -53,14 +53,16 @@ enum {
/* __EXEC_OBJECT_NO_RESERVE is BIT(31), defined in i915_vma.h */
#define __EXEC_OBJECT_HAS_PIN BIT(30)
#define __EXEC_OBJECT_HAS_FENCEBIT(29)
-#define __EXEC_OBJECT_NEEDS_MAPBIT(28)
-#define __EXEC_OBJECT_NEEDS_BIAS BIT(27)
-#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 27) /* all of the above + */
+#define __EXEC_OBJECT_USERPTR_INIT BIT(28)
+#define __EXEC_OBJECT_NEEDS_MAPBIT(27)
+#define __EXEC_OBJECT_NEEDS_BIAS BIT(26)
+#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 26) /* all of the above + */
#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_ENGINE_PINNED BIT(30)
-#define __EXEC_INTERNAL_FLAGS (~0u << 30)
+#define __EXEC_USERPTR_USEDBIT(29)
+#define __EXEC_INTERNAL_FLAGS (~0u << 29)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -871,6 +873,26 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
}
eb_add_vma(eb, i, batch, vma);
+
+ if (i915_gem_object_is_userptr(vma->obj)) {
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+ if (err) {
+ if (i + 1 <
[Intel-gfx] [PATCH v9 20/70] drm/i915: Handle ww locking in init_status_page
Try to pin to ggtt first, and use a full ww loop to handle
eviction correctly.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 37 +++
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e6cefd00b4a1..859c79b0d6ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -602,6 +602,7 @@ static void cleanup_status_page(struct intel_engine_cs
*engine)
}
static int pin_ggtt_status_page(struct intel_engine_cs *engine,
+ struct i915_gem_ww_ctx *ww,
struct i915_vma *vma)
{
unsigned int flags;
@@ -622,12 +623,13 @@ static int pin_ggtt_status_page(struct intel_engine_cs
*engine,
else
flags = PIN_HIGH;
- return i915_ggtt_pin(vma, NULL, 0, flags);
+ return i915_ggtt_pin(vma, ww, 0, flags);
}
static int init_status_page(struct intel_engine_cs *engine)
{
struct drm_i915_gem_object *obj;
+ struct i915_gem_ww_ctx ww;
struct i915_vma *vma;
void *vaddr;
int ret;
@@ -653,30 +655,39 @@ static int init_status_page(struct intel_engine_cs
*engine)
vma = i915_vma_instance(obj, >gt->ggtt->vm, NULL);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
- goto err;
+ goto err_put;
}
+ i915_gem_ww_ctx_init(, true);
+retry:
+ ret = i915_gem_object_lock(obj, );
+ if (!ret && !HWS_NEEDS_PHYSICAL(engine->i915))
+ ret = pin_ggtt_status_page(engine, , vma);
+ if (ret)
+ goto err;
+
vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
- goto err;
+ goto err_unpin;
}
engine->status_page.addr = memset(vaddr, 0, PAGE_SIZE);
engine->status_page.vma = vma;
- if (!HWS_NEEDS_PHYSICAL(engine->i915)) {
- ret = pin_ggtt_status_page(engine, vma);
- if (ret)
- goto err_unpin;
- }
-
- return 0;
-
err_unpin:
- i915_gem_object_unpin_map(obj);
+ if (ret)
+ i915_vma_unpin(vma);
err:
- i915_gem_object_put(obj);
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff();
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+err_put:
+ if (ret)
+ i915_gem_object_put(obj);
return ret;
}
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 17/70] drm/i915: Flatten obj->mm.lock
With userptr fixed, there is no need for all separate lockdep classes
now, and we can remove all lockdep tricks used. A trylock in the
shrinker is all we need now to flatten the locking hierarchy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +--
drivers/gpu/drm/i915/gem/i915_gem_object.h | 20 ++--
drivers/gpu/drm/i915/gem/i915_gem_pages.c| 34 ++--
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 10 +++---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
6 files changed, 27 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6083b9c14be6..821cb40f8d73 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -62,7 +62,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops,
struct lock_class_key *key, unsigned flags)
{
- __mutex_init(>mm.lock, ops->name ?: "obj->mm.lock", key);
+ mutex_init(>mm.lock);
spin_lock_init(>vma.lock);
INIT_LIST_HEAD(>vma.list);
@@ -86,9 +86,6 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
mutex_init(>mm.get_page.lock);
INIT_RADIX_TREE(>mm.get_dma_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(>mm.get_dma_page.lock);
-
- if (IS_ENABLED(CONFIG_LOCKDEP) && i915_gem_object_is_shrinkable(obj))
- fs_reclaim_taints_mutex(>mm.lock);
}
/**
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index b5af9c440ac5..a0e1c4ff0de4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -372,27 +372,10 @@ void __i915_gem_object_set_pages(struct
drm_i915_gem_object *obj,
int i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
- I915_MM_NORMAL = 0,
- /*
-* Only used by struct_mutex, when called "recursively" from
-* direct-reclaim-esque. Safe because there is only every one
-* struct_mutex in the entire system.
-*/
- I915_MM_SHRINKER = 1,
- /*
-* Used for obj->mm.lock when allocating pages. Safe because the object
-* isn't yet on any LRU, and therefore the shrinker can't deadlock on
-* it. As soon as the object has pages, obj->mm.lock nests within
-* fs_reclaim.
-*/
- I915_MM_GET_PAGES = 1,
-};
-
static inline int __must_check
i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
{
- might_lock_nested(>mm.lock, I915_MM_GET_PAGES);
+ might_lock(>mm.lock);
if (atomic_inc_not_zero(>mm.pages_pin_count))
return 0;
@@ -436,6 +419,7 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
}
int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
+int __i915_gem_object_put_pages_locked(struct drm_i915_gem_object *obj);
void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index e7d7650072c5..e947d4c0da1f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -114,7 +114,7 @@ int __i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
{
int err;
- err = mutex_lock_interruptible_nested(>mm.lock, I915_MM_GET_PAGES);
+ err = mutex_lock_interruptible(>mm.lock);
if (err)
return err;
@@ -196,21 +196,13 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
return pages;
}
-int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
+int __i915_gem_object_put_pages_locked(struct drm_i915_gem_object *obj)
{
struct sg_table *pages;
- int err;
if (i915_gem_object_has_pinned_pages(obj))
return -EBUSY;
- /* May be called by shrinker from within get_pages() (on another bo) */
- mutex_lock(>mm.lock);
- if (unlikely(atomic_read(>mm.pages_pin_count))) {
- err = -EBUSY;
- goto unlock;
- }
-
i915_gem_object_release_mmap_offset(obj);
/*
@@ -226,14 +218,22 @@ int __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
* get_pages backends we should be better able to handle the
* cancellation of the async task in a more uniform manner.
*/
- if (!pages)
- pages = ERR_PTR(-EINVAL);
-
- if (!IS_ERR(pages))
+ if
[Intel-gfx] [PATCH v9 34/70] drm/i915: Add ww locking around vm_access()
i915_gem_object_pin_map potentially needs a ww context, so ensure we
have one we can revoke.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 163208a6260d..2561a2f1e54f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -421,7 +421,9 @@ vm_access(struct vm_area_struct *area, unsigned long addr,
{
struct i915_mmap_offset *mmo = area->vm_private_data;
struct drm_i915_gem_object *obj = mmo->obj;
+ struct i915_gem_ww_ctx ww;
void *vaddr;
+ int err = 0;
if (i915_gem_object_is_readonly(obj) && write)
return -EACCES;
@@ -430,10 +432,18 @@ vm_access(struct vm_area_struct *area, unsigned long addr,
if (addr >= obj->base.size)
return -EINVAL;
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock(obj, );
+ if (err)
+ goto out;
+
/* As this is primarily for debugging, let's focus on simplicity */
vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
- if (IS_ERR(vaddr))
- return PTR_ERR(vaddr);
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ goto out;
+ }
if (write) {
memcpy(vaddr + addr, buf, len);
@@ -443,6 +453,16 @@ vm_access(struct vm_area_struct *area, unsigned long addr,
}
i915_gem_object_unpin_map(obj);
+out:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
+ if (err)
+ return err;
return len;
}
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 68/70] drm/i915: Pass ww ctx to pin_map
This will allow us to explicitly pass the ww to pin_pages,
when it starts taking it.
This allows us to finally kill off the explicit passing of ww
by retrieving it from the obj.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 7 ---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 +
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +++
.../drm/i915/gem/selftests/i915_gem_context.c | 8 ---
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 7 ---
drivers/gpu/drm/i915/gt/intel_timeline.h | 3 ++-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 10 -
.../gpu/drm/i915/gt/selftest_workarounds.c| 6 +++---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
24 files changed, 60 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index dcfcae9c841b..73dd2a7673f5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1340,7 +1340,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
if (err)
goto err_pool;
- cmd = i915_gem_object_pin_map(pool->obj, pool->type);
+ cmd = i915_gem_object_pin_map(pool->obj, >ww, pool->type);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto err_pool;
@@ -2489,7 +2489,8 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
goto err_shadow;
}
- pw->shadow_map = i915_gem_object_pin_map(shadow->obj, I915_MAP_WB);
+ pw->shadow_map = i915_gem_object_pin_map(shadow->obj, >ww,
+I915_MAP_WB);
if (IS_ERR(pw->shadow_map)) {
err = PTR_ERR(pw->shadow_map);
goto err_trampoline;
@@ -2500,7 +2501,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
pw->batch_map = ERR_PTR(-ENODEV);
if (needs_clflush && i915_has_memcpy_from_wc())
- pw->batch_map = i915_gem_object_pin_map(batch, I915_MAP_WC);
+ pw->batch_map = i915_gem_object_pin_map(batch, >ww,
I915_MAP_WC);
if (IS_ERR(pw->batch_map)) {
err = i915_gem_object_pin_pages(batch);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2561a2f1e54f..edac8ee3be9a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -439,7 +439,7 @@ vm_access(struct vm_area_struct *area, unsigned long addr,
goto out;
/* As this is primarily for debugging, let's focus on simplicity */
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+ vaddr = i915_gem_object_pin_map(obj, , I915_MAP_FORCE_WC);
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
goto out;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 1a8ec4035112..9bd9b47dcc8d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -450,6 +450,7 @@ void i915_gem_object_writeback(struct drm_i915_gem_object
*obj);
* ERR_PTR() on error.
*/
void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww,
enum i915_map_type type);
void *__must_check i915_gem_object_pin_map_unlocked(struct drm_i915_gem_object
*obj,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
index df8e8c18c6c9..fae18622d2da 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
@@ -58,7 +58,7 @@ struct i915_vma *intel_emit_vma_fill_blt(struct intel_context
*ce,
/* we pinned the pool, mark it as such */
intel_gt_buffer_pool_mark_used(pool);
- cmd = i915_gem_object_pin_map(pool->obj, pool->type);
+ cmd = i915_gem_object_pin_map(pool->obj,
