[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/2] drm/i915/perf: Allow non-privileged access when OA buffer is not sampled
== Series Details == Series: series starting with [v3,1/2] drm/i915/perf: Allow non-privileged access when OA buffer is not sampled URL : https://patchwork.freedesktop.org/series/69645/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7367_full -> Patchwork_15321_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_15321_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15321_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_15321_full: ### IGT changes ### Possible regressions * igt@gem_eio@wait-wedge-1us: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-skl3/igt@gem_...@wait-wedge-1us.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-skl7/igt@gem_...@wait-wedge-1us.html Known issues Here are the changes found in Patchwork_15321_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@vcs1-mixed-process: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-iclb1/igt@gem_ctx_persiste...@vcs1-mixed-process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-iclb6/igt@gem_ctx_persiste...@vcs1-mixed-process.html * igt@gem_eio@suspend: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#111850]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-tglb6/igt@gem_...@suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-tglb8/igt@gem_...@suspend.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-iclb2/igt@gem_exec_paral...@vcs1-fds.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-iclb3/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-iclb3/igt@gem_exec_sched...@pi-ringfull-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-iclb4/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-vebox: - shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([fdo#111677]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-tglb3/igt@gem_exec_sched...@preempt-queue-chain-vebox.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-tglb6/igt@gem_exec_sched...@preempt-queue-chain-vebox.html * igt@gem_exec_suspend@basic-s0: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([fdo#111832]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-tglb2/igt@gem_exec_susp...@basic-s0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-tglb7/igt@gem_exec_susp...@basic-s0.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-hsw: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-hsw5/igt@gem_userptr_bl...@dmabuf-unsync.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-hsw1/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#111830 ]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-iclb2/igt@i915_pm...@dc6-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_selftest@live_hangcheck: - shard-hsw: [PASS][19] -> [DMESG-FAIL][20] ([fdo#111991]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-hsw6/igt@i915_selftest@live_hangcheck.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-hsw6/igt@i915_selftest@live_hangcheck.html * igt@kms_color@pipe-b-ctm-0-25: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([fdo#106107]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-skl3/igt@kms_co...@pipe-b-ctm-0-25.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15321/shard-skl2/igt@kms_co...@pipe-b-ctm-0-25.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) [23]: https://intel-gfx-ci.01.org/tree/drm-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: Do not read the transcoder register.
== Series Details ==
Series: drm/i915/dsi: Do not read the transcoder register.
URL : https://patchwork.freedesktop.org/series/69654/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7368 -> Patchwork_15324
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_15324:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload-no-display:
- {fi-kbl-7560u}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/fi-kbl-7560u/igt@i915_module_l...@reload-no-display.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/fi-kbl-7560u/igt@i915_module_l...@reload-no-display.html
* igt@runner@aborted:
- {fi-kbl-7560u}: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/fi-kbl-7560u/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_15324 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[PASS][4] -> [DMESG-WARN][5] ([fdo#112261])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/fi-skl-lmem/igt@i915_pm_...@module-reload.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/fi-skl-lmem/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_execlists:
- fi-bxt-dsi: [PASS][6] -> [INCOMPLETE][7] ([fdo#103927])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/fi-bxt-dsi/igt@i915_selftest@live_execlists.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/fi-bxt-dsi/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][8] -> [FAIL][9] ([fdo#109483])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][10] ([fdo#111700]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
[fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261
Participating hosts (49 -> 43)
--
Missing(6): fi-kbl-soraka fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7368 -> Patchwork_15324
CI-20190529: 20190529
CI_DRM_7368: e3c581b45b9211ca601f4aaf4b7a8cbea8667596 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5293: 4bb46f08f7cb6485642c4351cecdad93072d27a0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15324: ca4f6f41be0526483d983b81c333a622127dcc0d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ca4f6f41be05 drm/i915/dsi: Do not read the transcoder register.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/19] drm/i915/selftests: Force bonded submission to overlap
== Series Details == Series: series starting with [01/19] drm/i915/selftests: Force bonded submission to overlap URL : https://patchwork.freedesktop.org/series/69647/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7367_full -> Patchwork_15322_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_15322_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15322_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_15322_full: ### IGT changes ### Possible regressions * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled: - shard-skl: [PASS][1] -> [INCOMPLETE][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-skl6/igt@kms_draw_...@draw-method-xrgb2101010-render-ytiled.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-skl10/igt@kms_draw_...@draw-method-xrgb2101010-render-ytiled.html * igt@perf@oa-exponents: - shard-kbl: [PASS][3] -> [TIMEOUT][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-kbl7/igt@p...@oa-exponents.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-kbl1/igt@p...@oa-exponents.html - shard-iclb: [PASS][5] -> [TIMEOUT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-iclb3/igt@p...@oa-exponents.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-iclb6/igt@p...@oa-exponents.html * igt@runner@aborted: - shard-kbl: NOTRUN -> ([FAIL][7], [FAIL][8]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-kbl1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-kbl6/igt@run...@aborted.html New tests - New tests have been introduced between CI_DRM_7367_full and Patchwork_15322_full: ### New IGT tests (1) ### * igt@i915_selftest@live_late_gt_pm: - Statuses : 4 pass(s) - Exec time: [0.31, 2.47] s Known issues Here are the changes found in Patchwork_15322_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110841]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_eio@reset-stress: - shard-snb: [PASS][11] -> [FAIL][12] ([fdo#109661]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-snb4/igt@gem_...@reset-stress.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-snb5/igt@gem_...@reset-stress.html * igt@gem_exec_create@madvise: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([fdo#111747]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-tglb8/igt@gem_exec_cre...@madvise.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-tglb6/igt@gem_exec_cre...@madvise.html * igt@gem_exec_reloc@basic-write-read-active: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([fdo#106107]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-skl6/igt@gem_exec_re...@basic-write-read-active.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-skl10/igt@gem_exec_re...@basic-write-read-active.html * igt@gem_exec_schedule@fifo-bsd: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-iclb5/igt@gem_exec_sched...@fifo-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-iclb1/igt@gem_exec_sched...@fifo-bsd.html * igt@gem_exec_suspend@basic-s0: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111832]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-tglb2/igt@gem_exec_susp...@basic-s0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-tglb5/igt@gem_exec_susp...@basic-s0.html * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive: - shard-snb: [PASS][21] -> [TIMEOUT][22] ([fdo#112068 ]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7367/shard-snb4/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15322/shard-snb7/igt@gem_persistent_rel...@forked-interruptible-thra
[Intel-gfx] [PATCH 15/17] drm/i915/selftests: Flush the active callbacks
Before checking the current i915_active state for the asynchronous work
we submitted, flush any ongoing callback. This ensures that our sampling
is robust and does not sporadically fail due to bad timing as the work
is running on another cpu.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_context.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 3586af636304..d1203b4c1409 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -48,20 +48,25 @@ static int context_sync(struct intel_context *ce)
mutex_lock(&tl->mutex);
do {
- struct dma_fence *fence;
+ struct i915_request *rq;
long timeout;
- fence = i915_active_fence_get(&tl->last_request);
- if (!fence)
+ if (list_empty(&tl->requests))
break;
- timeout = dma_fence_wait_timeout(fence, false, HZ / 10);
+ rq = list_last_entry(&tl->requests, typeof(*rq), link);
+ i915_request_get(rq);
+
+ timeout = i915_request_wait(rq, 0, HZ / 10);
if (timeout < 0)
err = timeout;
else
- i915_request_retire_upto(to_request(fence));
+ i915_request_retire_upto(rq);
- dma_fence_put(fence);
+ spin_lock_irq(&rq->lock);
+ spin_unlock_irq(&rq->lock);
+
+ i915_request_put(rq);
} while (!err);
mutex_unlock(&tl->mutex);
@@ -282,6 +287,8 @@ static int __live_active_context(struct intel_engine_cs
*engine,
err = -EINVAL;
}
+ intel_engine_pm_unlock_wait(engine);
+
if (intel_engine_pm_is_awake(engine)) {
struct drm_printer p = drm_debug_printer(__func__);
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/17] drm/i915: Wait until the intel_wakeref idle callback is complete
When waiting for idle, serialise with any ongoing callback so that it
will have completed before completing the wait.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_wakeref.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wakeref.c
b/drivers/gpu/drm/i915/intel_wakeref.c
index 9b29176cc1ca..91feb53b2942 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -109,8 +109,15 @@ void __intel_wakeref_init(struct intel_wakeref *wf,
int intel_wakeref_wait_for_idle(struct intel_wakeref *wf)
{
- return wait_var_event_killable(&wf->wakeref,
- !intel_wakeref_is_active(wf));
+ int err;
+
+ err = wait_var_event_killable(&wf->wakeref,
+ !intel_wakeref_is_active(wf));
+ if (err)
+ return err;
+
+ intel_wakeref_unlock_wait(wf);
+ return 0;
}
static void wakeref_auto_timeout(struct timer_list *t)
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/17] drm/i915/gt: Only wait for register chipset flush if active
Only serialise with the chipset using an mmio if the chipset is
currently active. We expect that any writes into the chipset range will
simply be forgotten until it wakes up.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b5a9b87e4ec9..c4fd8d65b8a3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -304,7 +304,7 @@ void intel_gt_flush_ggtt_writes(struct intel_gt *gt)
intel_gt_chipset_flush(gt);
- with_intel_runtime_pm(uncore->rpm, wakeref) {
+ with_intel_runtime_pm_if_in_use(uncore->rpm, wakeref) {
unsigned long flags;
spin_lock_irqsave(&uncore->lock, flags);
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/17] drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
Since igt now defaults to not enabling ftrace-on-oops, we need to
manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
GEM_BUG_ON panicking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index c7985767296a..1753c84d6c0d 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -30,6 +30,8 @@
#include
+#include "i915_utils.h"
+
struct drm_i915_private;
#ifdef CONFIG_DRM_I915_DEBUG_GEM
@@ -39,6 +41,7 @@ struct drm_i915_private;
#define GEM_BUG_ON(condition) do { if (unlikely((condition))) {\
GEM_TRACE_ERR("%s:%d GEM_BUG_ON(%s)\n", \
__func__, __LINE__, __stringify(condition)); \
+ GEM_TRACE_DUMP(); \
BUG(); \
} \
} while(0)
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/18] drm/i915/gt: Only wait for register chipset flush if active
Chris Wilson writes:
> Only serialise with the chipset using an mmio if the chipset is
> currently active. We expect that any writes into the chipset range will
> simply be forgotten until it wakes up.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index b5a9b87e4ec9..c4fd8d65b8a3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -304,7 +304,7 @@ void intel_gt_flush_ggtt_writes(struct intel_gt *gt)
>
> intel_gt_chipset_flush(gt);
>
> - with_intel_runtime_pm(uncore->rpm, wakeref) {
> + with_intel_runtime_pm_if_in_use(uncore->rpm, wakeref) {
> unsigned long flags;
>
> spin_lock_irqsave(&uncore->lock, flags);
> --
> 2.24.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/17] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid, as we always manipulated the timeline only while
we held an engine wakeref.
And then we started retiring requests outside of struct_mutex, only
using the timelines.active_list and the timeline->mutex. There we
started manipulating intel_timeline.active_count outside of an engine
wakeref, and so introduced a race between __engine_park() and
intel_gt_retire_requests(), a race that could result in the
engine->kernel_context not being added to the active timelines and so
losing requests, which caused us to keep the system permanently powered
up [and unloadable].
The race would be easy to close if we could take the engine wakeref for
the timeline before we retire -- except timelines are not bound to any
engine and so we would need to keep all active engines awake. The
alternative is to guard intel_timeline_enter/intel_timeline_exit for use
outside of the timeline->mutex.
Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with
timeline->mutex")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 8 ++---
drivers/gpu/drm/i915/gt/intel_timeline.c | 34 +++
.../gpu/drm/i915/gt/intel_timeline_types.h| 2 +-
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index a79e6efb31a2..7559d6373f49 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -49,8 +49,8 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
continue;
intel_timeline_get(tl);
- GEM_BUG_ON(!tl->active_count);
- tl->active_count++; /* pin the list element */
+ GEM_BUG_ON(!atomic_read(&tl->active_count));
+ atomic_inc(&tl->active_count); /* pin the list element */
spin_unlock_irqrestore(&timelines->lock, flags);
if (timeout > 0) {
@@ -71,14 +71,14 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
/* Resume iteration after dropping lock */
list_safe_reset_next(tl, tn, link);
- if (!--tl->active_count)
+ if (atomic_dec_and_test(&tl->active_count))
list_del(&tl->link);
mutex_unlock(&tl->mutex);
/* Defer the final release to after the spinlock */
if (refcount_dec_and_test(&tl->kref.refcount)) {
- GEM_BUG_ON(tl->active_count);
+ GEM_BUG_ON(atomic_read(&tl->active_count));
list_add(&tl->link, &free);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 16a9e88d93de..4f914f0d5eab 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -334,15 +334,33 @@ void intel_timeline_enter(struct intel_timeline *tl)
struct intel_gt_timelines *timelines = &tl->gt->timelines;
unsigned long flags;
+ /*
+* Pretend we are serialised by the timeline->mutex.
+*
+* While generally true, there are a few exceptions to the rule
+* for the engine->kernel_context being used to manage power
+* transitions. As the engine_park may be called from under any
+* timeline, it uses the power mutex as a global serialisation
+* lock to prevent any other request entering its timeline.
+*
+* The rule is generally tl->mutex, otherwise engine->wakeref.mutex.
+*
+* However, intel_gt_retire_request() does not know which engine
+* it is retiring along and so cannot partake in the engine-pm
+* barrier, and there we use the tl->active_count as a means to
+* pin the timeline in the active_list while the locks are dropped.
+* Ergo, as that is outside of the engine-pm barrier, we need to
+* use atomic to manipulate tl->active_count.
+*/
lockdep_assert_held(&tl->mutex);
-
GEM_BUG_ON(!atomic_read(&tl->pin_count));
- if (tl->active_count++)
+
+ if (atomic_add_unless(&tl->active_count, 1, 0))
return;
- GEM_BUG_ON(!tl->active_count); /* overflow? */
spin_lock_irqsave(&timelines->lock, flags);
- list_add(&tl->link, &timelines->active_list);
+ if (!atomic_fetch_inc(&tl->active_count))
+ list_add(&tl->link, &timelines->active_list);
spin_unlock_irqrestore(&timelines->lock, flags);
}
@@ -351,14 +369,16 @@ void intel_timeline_exit(struct intel_ti
[Intel-gfx] [PATCH 06/17] drm/i915/gem: Merge GGTT vma flush into a single loop
We only need the one loop to find the dirty vma flush them, and their
chipset.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index db103d3c8760..63bd3ff84f5e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -279,18 +279,12 @@ i915_gem_object_flush_write_domain(struct
drm_i915_gem_object *obj,
switch (obj->write_domain) {
case I915_GEM_DOMAIN_GTT:
- for_each_ggtt_vma(vma, obj)
- intel_gt_flush_ggtt_writes(vma->vm->gt);
-
- intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
-
for_each_ggtt_vma(vma, obj) {
- if (vma->iomap)
- continue;
-
- i915_vma_unset_ggtt_write(vma);
+ if (i915_vma_unset_ggtt_write(vma))
+ intel_gt_flush_ggtt_writes(vma->vm->gt);
}
+ intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
break;
case I915_GEM_DOMAIN_WC:
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/17] drm/i915/gt: Schedule next retirement worker first
As we may park the gt during request retirement, we may then cancel the retirement worker only to then program the delayed worker once more. If we schedule the next delayed retirement worker first, if we then park the gt, the work remain cancelled [until we unpark]. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/drm/i915/gt/intel_gt_requests.c index 74356db43325..4dc3cbeb1b36 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c @@ -109,9 +109,9 @@ static void retire_work_handler(struct work_struct *work) struct intel_gt *gt = container_of(work, typeof(*gt), requests.retire_work.work); - intel_gt_retire_requests(gt); schedule_delayed_work(>->requests.retire_work, round_jiffies_up_relative(HZ)); + intel_gt_retire_requests(gt); } void intel_gt_init_requests(struct intel_gt *gt) -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/17] drm/i915: Protect the obj->vma.list during iteration
Take the obj->vma.lock to prevent modifications to the list as we
iterate, to avoid the dreaded the NULL pointer.
<1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
0150
<1>[ 347.820856] #PF: supervisor read access in kernel mode
<1>[ 347.820874] #PF: error_code(0x) - not-present page
<6>[ 347.820892] PGD 0 P4D 0
<4>[ 347.820908] Oops: [#1] PREEMPT SMP NOPTI
<4>[ 347.820926] CPU: 3 PID: 1303 Comm: gem_persistent_ Tainted: G U
5.4.0-rc7-CI-CI_DRM_7352+ #1
<4>[ 347.820956] Hardware name: /NUC6CAYB, BIOS
AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4>[ 347.821132] RIP: 0010:i915_gem_object_flush_write_domain+0xd9/0x1d0 [i915]
<4>[ 347.821157] Code: 0f 84 e9 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 75 11
e9 ed 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 74 26 48 8b 83 b0 00 00 00 <48> 8b
b8 50 01 00 00 e8 fb 20 fb ff 48 8b 83 30 03 00 00 49 39 c4
<4>[ 347.821210] RSP: 0018:c9a1f8f8 EFLAGS: 00010202
<4>[ 347.821229] RAX: RBX: c98479a0 RCX:
0018
<4>[ 347.821252] RDX: RSI: 000d RDI:
888275a090b0
<4>[ 347.821274] RBP: 8882673c8040 R08: 88825991b8d0 R09:
<4>[ 347.821297] R10: R11: R12:
8882673c8280
<4>[ 347.821319] R13: 8882673c8368 R14: R15:
888266a54000
<4>[ 347.821343] FS: 7f75865f4240() GS:888277b8()
knlGS:
<4>[ 347.821368] CS: 0010 DS: ES: CR0: 80050033
<4>[ 347.821389] CR2: 0150 CR3: 00025aee CR4:
003406e0
<4>[ 347.821411] Call Trace:
<4>[ 347.821555] i915_gem_object_prepare_read+0xea/0x2a0 [i915]
<4>[ 347.821706] intel_engine_cmd_parser+0x5ce/0xe90 [i915]
<4>[ 347.821834] ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
<4>[ 347.821990] i915_gem_do_execbuffer+0xb4c/0x2550 [i915]
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 63bd3ff84f5e..458945e1823e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -279,10 +279,12 @@ i915_gem_object_flush_write_domain(struct
drm_i915_gem_object *obj,
switch (obj->write_domain) {
case I915_GEM_DOMAIN_GTT:
+ spin_lock(&obj->vma.lock);
for_each_ggtt_vma(vma, obj) {
if (i915_vma_unset_ggtt_write(vma))
intel_gt_flush_ggtt_writes(vma->vm->gt);
}
+ spin_unlock(&obj->vma.lock);
intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
break;
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/17] drm/i915: Mark up the calling context for intel_wakeref_put()
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a working if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally are in process context,
we can typically use a plain mutex, and only defer to a work when we
know we are caller from an interrupt path.
Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in
IRQ contexts")
References: https://bugs.freedesktop.org/show_bug.cgi?id=111626
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c| 3 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.h| 10 +
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 1 -
drivers/gpu/drm/i915/gt/intel_gt_pm.h| 5 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 7 ++--
drivers/gpu/drm/i915/i915_active.c | 5 ++-
drivers/gpu/drm/i915/i915_pmu.c | 6 +--
drivers/gpu/drm/i915/intel_wakeref.c | 8 ++--
drivers/gpu/drm/i915/intel_wakeref.h | 44
11 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 722d3eec226e..4878d16176d5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -180,7 +180,8 @@ static int __engine_park(struct intel_wakeref *wf)
engine->execlists.no_priolist = false;
- intel_gt_pm_put(engine->gt);
+ /* While we call i915_vma_parked, we have to break the lock cycle */
+ intel_gt_pm_put_async(engine->gt);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
index 739c50fefcef..467475fce9c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
@@ -31,6 +31,16 @@ static inline void intel_engine_pm_put(struct
intel_engine_cs *engine)
intel_wakeref_put(&engine->wakeref);
}
+static inline void intel_engine_pm_put_async(struct intel_engine_cs *engine)
+{
+ intel_wakeref_put_async(&engine->wakeref);
+}
+
+static inline void intel_engine_pm_unlock_wait(struct intel_engine_cs *engine)
+{
+ intel_wakeref_unlock_wait(&engine->wakeref);
+}
+
void intel_engine_init__pm(struct intel_engine_cs *engine);
#endif /* INTEL_ENGINE_PM_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index e61f752a3cd5..7a9044ac4b75 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -105,7 +105,6 @@ static int __gt_park(struct intel_wakeref *wf)
static const struct intel_wakeref_ops wf_ops = {
.get = __gt_unpark,
.put = __gt_park,
- .flags = INTEL_WAKEREF_PUT_ASYNC,
};
void intel_gt_pm_init_early(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index b3e17399be9b..990efc27a4e4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -32,6 +32,11 @@ static inline void intel_gt_pm_put(struct intel_gt *gt)
intel_wakeref_put(>->wakeref);
}
+static inline void intel_gt_pm_put_async(struct intel_gt *gt)
+{
+ intel_wakeref_put_async(>->wakeref);
+}
+
static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
{
return intel_wakeref_wait_for_idle(>->wakeref);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 33ce258d484f..b65bc06855b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1172,7 +1172,7 @@ __execlists_schedule_out(struct i915_request *rq,
intel_engine_context_out(engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
- intel_gt_pm_put(engine->gt);
+ intel_gt_pm_put_async(engine->gt);
/*
* If this is part of a virtual engine, its next request may
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index b7007cd78c6f..0388f9375366 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1125,7 +1125,7 @@ int intel_engine_reset(struct intel_engine_cs *engine,
const char *msg)
out:
intel_engine_cancel_stop_cs(engine);
reset_finish_engine(engine);
- intel_engine_pm_put(engine);
+ intel_engine_pm_put_async(engine);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 20b9c83f43ad..851a6c4f65c6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/dr
[Intel-gfx] [PATCH 11/17] drm/i915/gt: Move new timelines to the end of active_list
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner.
References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_retire_requests()")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index bd973d950064..b190a5d9ab02 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -359,7 +359,7 @@ void intel_timeline_enter(struct intel_timeline *tl)
spin_lock(&timelines->lock);
if (!atomic_fetch_inc(&tl->active_count))
- list_add(&tl->link, &timelines->active_list);
+ list_add_tail(&tl->link, &timelines->active_list);
spin_unlock(&timelines->lock);
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/17] drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() needed to be atomic and
ordered in a nice onion with intel_ring_pin() so that the lifetimes
overlapped and were always safe.
Sadly, a few steps in intel_ring_unpin() were overlooked, such as
closing the read/write pointers of the ring and discarding the
intel_ring.vaddr, as these steps were not serialised with
intel_ring_pin() and so could leave the ring in disarray.
Fixes: 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_ring.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index ece20504d240..374b28f13ca0 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -57,9 +57,10 @@ int intel_ring_pin(struct intel_ring *ring)
i915_vma_make_unshrinkable(vma);
- GEM_BUG_ON(ring->vaddr);
- ring->vaddr = addr;
+ /* Discard any unused bytes beyond that submitted to hw. */
+ intel_ring_reset(ring, ring->emit);
+ ring->vaddr = addr;
return 0;
err_ring:
@@ -85,20 +86,14 @@ void intel_ring_unpin(struct intel_ring *ring)
if (!atomic_dec_and_test(&ring->pin_count))
return;
- /* Discard any unused bytes beyond that submitted to hw. */
- intel_ring_reset(ring, ring->emit);
-
i915_vma_unset_ggtt_write(vma);
if (i915_vma_is_map_and_fenceable(vma))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);
- GEM_BUG_ON(!ring->vaddr);
- ring->vaddr = NULL;
-
- i915_vma_unpin(vma);
i915_vma_make_purgeable(vma);
+ i915_vma_unpin(vma);
}
static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size)
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/17] drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap with other users of the engine->kernel_context waking
up and submitting their request before the idle-switch is queued, with
the result that the kernel_context is executed out-of-sequence most
likely upsetting the GPU and certainly ourselves when we try to retire
the out-of-sequence requests.
As such we need to hold onto the effective engine->kernel_context mutex
lock (via the engine pm mutex proxy) until we have finish queuing the
request to the engine.
v2: Serialise against concurrent intel_gt_retire_requests()
Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 3c0f490ff2c7..722d3eec226e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -75,6 +75,7 @@ static inline void __timeline_mark_unlock(struct
intel_context *ce,
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
{
+ struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
unsigned long flags;
bool result = true;
@@ -99,15 +100,13 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
* retiring the last request, thus all rings should be empty and
* all timelines idle.
*/
- flags = __timeline_mark_lock(engine->kernel_context);
+ flags = __timeline_mark_lock(ce);
- rq = __i915_request_create(engine->kernel_context, GFP_NOWAIT);
+ rq = __i915_request_create(ce, GFP_NOWAIT);
if (IS_ERR(rq))
/* Context switch failed, hope for the best! Maybe reset? */
goto out_unlock;
- intel_timeline_enter(i915_request_timeline(rq));
-
/* Check again on the next retirement. */
engine->wakeref_serial = engine->serial + 1;
i915_request_add_active_barriers(rq);
@@ -116,13 +115,17 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
rq->sched.attr.priority = I915_PRIORITY_BARRIER;
__i915_request_commit(rq);
+ __i915_request_queue(rq, NULL);
+
/* Release our exclusive hold on the engine */
__intel_wakeref_defer_park(&engine->wakeref);
- __i915_request_queue(rq, NULL);
+
+ /* And finally expose our selfselves to intel_gt_retire_requests() */
+ intel_timeline_enter(ce->timeline);
result = false;
out_unlock:
- __timeline_mark_unlock(engine->kernel_context, flags);
+ __timeline_mark_unlock(ce, flags);
return result;
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/17] drm/i915/gt: Flush the requests after wedging on suspend
Retire all requests if we resort to wedged the driver on suspend. They will now be idle, so we might as we free them before shutting down. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c index 7a9044ac4b75..f6b5169d623f 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c @@ -256,6 +256,7 @@ static void wait_for_suspend(struct intel_gt *gt) * the gpu quiet. */ intel_gt_set_wedged(gt); + intel_gt_retire_requests(gt); } intel_gt_pm_wait_for_idle(gt); -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/17] drm/i915/selftests: Exercise rc6 handling
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
possible rc6 context corruption. Poke at the bear!
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 13 ++
drivers/gpu/drm/i915/gt/selftest_rc6.c| 146 ++
drivers/gpu/drm/i915/gt/selftest_rc6.h| 12 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
5 files changed, 176 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/selftest_rc6.c
create mode 100644 drivers/gpu/drm/i915/gt/selftest_rc6.h
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 977a617a196d..7a0bc6dde009 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -783,3 +783,7 @@ u64 intel_rc6_residency_us(struct intel_rc6 *rc6,
i915_reg_t reg)
{
return DIV_ROUND_UP_ULL(intel_rc6_residency_ns(rc6, reg), 1000);
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_rc6.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index d1752f15702a..1d5bf93d1258 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -6,6 +6,7 @@
*/
#include "selftest_llc.h"
+#include "selftest_rc6.h"
static int live_gt_resume(void *arg)
{
@@ -58,3 +59,15 @@ int intel_gt_pm_live_selftests(struct drm_i915_private *i915)
return intel_gt_live_subtests(tests, &i915->gt);
}
+
+int intel_gt_pm_late_selftests(struct drm_i915_private *i915)
+{
+ static const struct i915_subtest tests[] = {
+ SUBTEST(live_rc6_ctx),
+ };
+
+ if (intel_gt_is_wedged(&i915->gt))
+ return 0;
+
+ return intel_gt_live_subtests(tests, &i915->gt);
+}
diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
new file mode 100644
index ..c8b729f7e93e
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -0,0 +1,146 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "intel_context.h"
+#include "intel_engine_pm.h"
+#include "intel_gt_requests.h"
+#include "intel_ring.h"
+#include "selftest_rc6.h"
+
+#include "selftests/i915_random.h"
+
+static const u32 *__live_rc6_ctx(struct intel_context *ce)
+{
+ struct i915_request *rq;
+ u32 const *result;
+ u32 cmd;
+ u32 *cs;
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return ERR_CAST(rq);
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ return cs;
+ }
+
+ cmd = MI_STORE_REGISTER_MEM | MI_USE_GGTT;
+ if (INTEL_GEN(rq->i915) >= 8)
+ cmd++;
+
+ *cs++ = cmd;
+ *cs++ = i915_mmio_reg_offset(GEN8_RC6_CTX_INFO);
+ *cs++ = ce->timeline->hwsp_offset + 8;
+ *cs++ = 0;
+ intel_ring_advance(rq, cs);
+
+ result = rq->hwsp_seqno + 2;
+ i915_request_add(rq);
+
+ return result;
+}
+
+static struct intel_engine_cs **
+randomised_engines(struct intel_gt *gt,
+ struct rnd_state *prng,
+ unsigned int *count)
+{
+ struct intel_engine_cs *engine, **engines;
+ enum intel_engine_id id;
+ int n;
+
+ n = 0;
+ for_each_engine(engine, gt, id)
+ n++;
+ if (!n)
+ return NULL;
+
+ engines = kmalloc_array(n, sizeof(*engines), GFP_KERNEL);
+ if (!engines)
+ return NULL;
+
+ n = 0;
+ for_each_engine(engine, gt, id)
+ engines[n++] = engine;
+
+ i915_prandom_shuffle(engines, sizeof(*engines), n, prng);
+
+ *count = n;
+ return engines;
+}
+
+int live_rc6_ctx(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs **engines;
+ unsigned int n, count;
+ I915_RND_STATE(prng);
+ int err = 0;
+
+ /* A read of CTX_INFO upsets rc6. Poke the bear! */
+ if (INTEL_GEN(gt->i915) < 8)
+ return 0;
+
+ engines = randomised_engines(gt, &prng, &count);
+ if (!engines)
+ return 0;
+
+ for (n = 0; n < count; n++) {
+ struct intel_engine_cs *engine = engines[n];
+ int pass;
+
+ for (pass = 0; pass < 2; pass++) {
+ struct intel_context *ce;
+ unsigned int resets =
+ i915_reset_engine_count(>->i915->gpu_error,
+ engine);
+ const u32 *res;
+
+ /* Use a sacrifical context */
+ ce =
intel_context_create(engine->kernel_context->gem_context,
+ engine);
+
[Intel-gfx] [PATCH 16/17] drm/i915/selftests: Be explicit in ERR_PTR handling
When setting up a full GGTT, we expect the next insert to fail with
-ENOSPC. Simplify the use of ERR_PTR to not confuse either the reader or
smatch.
Reported-by: Dan Carpenter
References: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 5f133d177212..06ef88510209 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -198,8 +198,8 @@ static int igt_overcommit(void *arg)
quirk_add(obj, &objects);
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
- if (!IS_ERR(vma) || PTR_ERR(vma) != -ENOSPC) {
- pr_err("Failed to evict+insert, i915_gem_object_ggtt_pin
returned err=%d\n", (int)PTR_ERR(vma));
+ if (vma != ERR_PTR(-ENOSPC)) {
+ pr_err("Failed to evict+insert, i915_gem_object_ggtt_pin
returned err=%d\n", (int)PTR_ERR_OR_ZERO(vma));
err = -EINVAL;
goto cleanup;
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/17] drm/i915/gt: Declare timeline.lock to be irq-free
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 -
drivers/gpu/drm/i915/gt/intel_reset.c | 9 -
drivers/gpu/drm/i915/gt/intel_timeline.c| 10 --
3 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 7559d6373f49..74356db43325 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -33,7 +33,6 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
{
struct intel_gt_timelines *timelines = >->timelines;
struct intel_timeline *tl, *tn;
- unsigned long flags;
bool interruptible;
LIST_HEAD(free);
@@ -43,7 +42,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
flush_submission(gt); /* kick the ksoftirqd tasklets */
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &timelines->active_list, link) {
if (!mutex_trylock(&tl->mutex))
continue;
@@ -51,7 +50,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
intel_timeline_get(tl);
GEM_BUG_ON(!atomic_read(&tl->active_count));
atomic_inc(&tl->active_count); /* pin the list element */
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
if (timeout > 0) {
struct dma_fence *fence;
@@ -67,7 +66,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
retire_requests(tl);
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
/* Resume iteration after dropping lock */
list_safe_reset_next(tl, tn, link);
@@ -82,7 +81,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
list_add(&tl->link, &free);
}
}
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &free, link)
__intel_timeline_free(&tl->kref);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 0388f9375366..36189238e13c 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -831,7 +831,6 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
{
struct intel_gt_timelines *timelines = >->timelines;
struct intel_timeline *tl;
- unsigned long flags;
bool ok;
if (!test_bit(I915_WEDGED, >->reset.flags))
@@ -853,7 +852,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
*
* No more can be submitted until we reset the wedged bit.
*/
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
list_for_each_entry(tl, &timelines->active_list, link) {
struct dma_fence *fence;
@@ -861,7 +860,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
if (!fence)
continue;
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
/*
* All internal dependencies (i915_requests) will have
@@ -874,10 +873,10 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
dma_fence_put(fence);
/* Restart iteration after droping lock */
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
tl = list_entry(&timelines->active_list, typeof(*tl), link);
}
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
/* We must reset pending GPU events before restoring our submission */
ok = !HAS_EXECLISTS(gt->i915); /* XXX better agnosticism desired */
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 4f914f0d5eab..bd973d950064 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -332,7 +332,6 @@ int intel_timeline_pin(struct intel_timeline *tl)
void intel_timeline_enter(struct intel_timeline *tl)
{
struct intel_gt_timelines *timelines = &tl->gt->timelines;
- unsigned long flags;
/*
* Pretend we are serialised by the timeline->mutex.
@@ -358,16 +357,15 @@ void intel_timeline_enter(struct intel_timeline *tl)
if (atomic_add_unless(&tl->a
[Intel-gfx] [PATCH 14/17] drm/i915/selftests: Force bonded submission to overlap
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pair is submitted, the pair were not destined
to run in parallel and we lose the information about the master engine
to dictate selection of the secondary. If the second request was
required to be run on a particular engine in a virtual set, that should
have been specified, rather than left to the whims of a random
unconnected requests!
In the selftest, I made the mistake of not ensuring the master would
overlap with its bonded pairs, meaning that it could indeed complete
before we submitted the bonds. Those bonds were then free to select any
available engine in their virtual set, and not the one expected by the
test.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 16ebe4d2308e..f3b0610d1f10 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -3036,15 +3036,21 @@ static int bond_virtual_engine(struct intel_gt *gt,
struct i915_gem_context *ctx;
struct i915_request *rq[16];
enum intel_engine_id id;
+ struct igt_spinner spin;
unsigned long n;
int err;
GEM_BUG_ON(nsibling >= ARRAY_SIZE(rq) - 1);
- ctx = kernel_context(gt->i915);
- if (!ctx)
+ if (igt_spinner_init(&spin, gt))
return -ENOMEM;
+ ctx = kernel_context(gt->i915);
+ if (!ctx) {
+ err = -ENOMEM;
+ goto err_spin;
+ }
+
err = 0;
rq[0] = ERR_PTR(-ENOMEM);
for_each_engine(master, gt, id) {
@@ -3055,7 +3061,7 @@ static int bond_virtual_engine(struct intel_gt *gt,
memset_p((void *)rq, ERR_PTR(-EINVAL), ARRAY_SIZE(rq));
- rq[0] = igt_request_alloc(ctx, master);
+ rq[0] = spinner_create_request(&spin, ctx, master, MI_NOOP);
if (IS_ERR(rq[0])) {
err = PTR_ERR(rq[0]);
goto out;
@@ -3068,10 +3074,17 @@ static int bond_virtual_engine(struct intel_gt *gt,
&fence,
GFP_KERNEL);
}
+
i915_request_add(rq[0]);
if (err < 0)
goto out;
+ if (!(flags & BOND_SCHEDULE) &&
+ !igt_wait_for_spinner(&spin, rq[0])) {
+ err = -EIO;
+ goto out;
+ }
+
for (n = 0; n < nsibling; n++) {
struct intel_context *ve;
@@ -3119,6 +3132,8 @@ static int bond_virtual_engine(struct intel_gt *gt,
}
}
onstack_fence_fini(&fence);
+ intel_engine_flush_submission(master);
+ igt_spinner_end(&spin);
if (i915_request_wait(rq[0], 0, HZ / 10) < 0) {
pr_err("Master request did not execute (on %s)!\n",
@@ -3156,6 +3171,8 @@ static int bond_virtual_engine(struct intel_gt *gt,
err = -EIO;
kernel_context_close(ctx);
+err_spin:
+ igt_spinner_fini(&spin);
return err;
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm: Extract page_flip_{internal, atomic}()
On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Yank out the code for the plane->fb/old_fb/crtc handling from
> the page flip path into page_flip_internal(), and provide a
> simpler variant for atomic drivers.
>
> We'll also move the fb vs. src viewport checks into the new
> functions as they are slightly different between the two paths.
> If the atomic .page_flip() implementations are guaranteed
> to call drm_atomic_plane_check() we could even drop the check
> entirely from page_flip_atomic(). For now toss in a FIXME.
>
> v2: Bit more polish in page_flip_internal()
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_plane.c | 159 +++-
> 1 file changed, 102 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 38878da5b704..6052475a20a5 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1031,13 +1031,109 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
> return drm_mode_cursor_common(dev, req, file_priv);
> }
>
> +static int page_flip_check_fbs(const struct drm_framebuffer *fb,
> +const struct drm_framebuffer *old_fb)
> +{
> + /* The framebuffer is currently unbound, presumably
> + * due to a hotplug event, that userspace has not
> + * yet discovered.
> + */
> + if (!old_fb)
> + return -EBUSY;
> +
> + if (old_fb->format != fb->format) {
> + DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
> format.\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int page_flip_internal(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *e,
> + u32 flags,
> + u32 target_vblank,
> + struct drm_modeset_acquire_ctx *ctx)
> +{
> + struct drm_plane *plane = crtc->primary;
> + int ret;
> +
> + WARN_ON(drm_drv_uses_atomic_modeset(crtc->dev));
> +
> + ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y,
> + &crtc->mode, fb);
> + if (ret)
> + return ret;
> +
> + ret = page_flip_check_fbs(fb, plane->fb);
> + if (ret)
> + return ret;
> +
> + plane->old_fb = plane->fb;
> + if (crtc->funcs->page_flip_target)
> + ret = crtc->funcs->page_flip_target(crtc, fb, e, flags,
> + target_vblank, ctx);
> + else
> + ret = crtc->funcs->page_flip(crtc, fb, e, flags, ctx);
> + if (ret) {
> + plane->old_fb = NULL;
> + return ret;
> + }
> +
> + plane->fb = fb;
> + drm_framebuffer_get(plane->fb);
> +
> + drm_framebuffer_put(plane->old_fb);
> + plane->old_fb = NULL;
> +
> + return 0;
> +}
> +
> +static int page_flip_atomic(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *e,
> + u32 flags,
> + u32 target_vblank,
> + struct drm_modeset_acquire_ctx *ctx)
> +{
> + struct drm_plane *plane = crtc->primary;
> + struct drm_plane_state *plane_state = plane->state;
> + int ret;
> +
> + WARN_ON(!drm_drv_uses_atomic_modeset(crtc->dev));
> +
> + /*
> + * FIXME: Can we assume all drivers end up calling
> + * drm_atomic_plane_check() in their page flip paths?
> + * If so we could remove this.
> + */
This is definitely wrong, core has to check these. Currently no driver
checks this at all. I think you're thinking of
drm_atomic_helper_check_plane_state().
That aside I'm kinda not getting the point of the shuffling/cleanup in the
first 4 patches here, so will skip them.
-Daniel
> + ret = drm_framebuffer_check_src_coords(plane_state->src_x,
> +plane_state->src_y,
> +plane_state->src_w,
> +plane_state->src_h,
> +fb);
> + if (ret)
> + return ret;
> +
> + ret = page_flip_check_fbs(fb, plane_state->fb);
> + if (ret)
> + return ret;
> +
> + if (crtc->funcs->page_flip_target)
> + return crtc->funcs->page_flip_target(crtc, fb, e, flags,
> + target_vblank, ctx);
> + else
> + return crtc->funcs->page_flip(crtc, fb, e, flags, ctx);
> +}
> +
> int drm_mode_page_flip_ioctl(struct drm_device *dev,
>void *data, struct drm_file *file_priv)
> {
> struct drm_mode_crtc_page_flip_target *page_flip = data;
> struct drm_crtc *crtc;
> struct dr
Re: [Intel-gfx] [PATCH 6/7] drm/atomic: Fix the early return in drm_atomic_set_mode_for_crtc()
On Fri, Nov 15, 2019 at 09:42:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The early return in drm_atomic_set_mode_for_crtc() isn't quite
> right. It would mistakenly return and fail to update
> crtc_state->enable if someone actually tried to set a zeroed
> mode on a currently disabled crtc. That should never actually
> happen in response to any userspace request as the zeroed mode
> would get rejected earlier. However there is some chance of this
> happening internally (eg. during hw state readout) so it seems
> best to not let the state become totally inconsistent.
>
> Additionally the early return will not be taken if we're trying to
> disable an already disabled crtc. While that is not actually
> harmful it is inconsistent, so let's handle that case as well.
>
> Testcase: igt/kms_selftest/check_atomic_set_mode_for_crtc
> Testcase: igt/kms_selftest/check_atomic_set_zeroed_mode_fort_crtc
> Reviewed-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 0d466d3b0809..a3a6a8137af4 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -68,8 +68,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
> *state,
> struct drm_mode_modeinfo umode;
>
> /* Early return for no change. */
> - if (mode && memcmp(&state->mode, mode, sizeof(*mode)) == 0)
> - return 0;
> + if (state->enable) {
Hm I think this would be clearer if you go with
if (state->enable == !!mode &&
(!mode || memcmp(&state->mode, mode, sizeof(*mode)) == 0))
return 0;
But also somewhat a bikeshed. I'm also wondering whether we shouldn't just
declare this a driver bug (it means enable and mode are already out of
sync), but I guess hw state readout is special sometimes.
Reviewed-by: Daniel Vetter
> + if (mode && memcmp(&state->mode, mode, sizeof(*mode)) == 0)
> + return 0;
> + } else {
> + if (!mode)
> + return 0;
> + }
>
> drm_property_blob_put(state->mode_blob);
> state->mode_blob = NULL;
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/17] drm/i915/gt: Only wait for register chipset flush if active
Chris Wilson writes:
> Only serialise with the chipset using an mmio if the chipset is
> currently active. We expect that any writes into the chipset range will
> simply be forgotten until it wakes up.
>
> Signed-off-by: Chris Wilson
From other threads,
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index b5a9b87e4ec9..c4fd8d65b8a3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -304,7 +304,7 @@ void intel_gt_flush_ggtt_writes(struct intel_gt *gt)
>
> intel_gt_chipset_flush(gt);
>
> - with_intel_runtime_pm(uncore->rpm, wakeref) {
> + with_intel_runtime_pm_if_in_use(uncore->rpm, wakeref) {
> unsigned long flags;
>
> spin_lock_irqsave(&uncore->lock, flags);
> --
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/17] drm/i915: Protect the obj->vma.list during iteration
Chris Wilson writes:
> Take the obj->vma.lock to prevent modifications to the list as we
> iterate, to avoid the dreaded the NULL pointer.
>
> <1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
> 0150
> <1>[ 347.820856] #PF: supervisor read access in kernel mode
> <1>[ 347.820874] #PF: error_code(0x) - not-present page
> <6>[ 347.820892] PGD 0 P4D 0
> <4>[ 347.820908] Oops: [#1] PREEMPT SMP NOPTI
> <4>[ 347.820926] CPU: 3 PID: 1303 Comm: gem_persistent_ Tainted: G U
>5.4.0-rc7-CI-CI_DRM_7352+ #1
> <4>[ 347.820956] Hardware name: /NUC6CAYB, BIOS
> AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
> <4>[ 347.821132] RIP: 0010:i915_gem_object_flush_write_domain+0xd9/0x1d0
> [i915]
> <4>[ 347.821157] Code: 0f 84 e9 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 75 11
> e9 ed 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 74 26 48 8b 83 b0 00 00 00 <48>
> 8b b8 50 01 00 00 e8 fb 20 fb ff 48 8b 83 30 03 00 00 49 39 c4
> <4>[ 347.821210] RSP: 0018:c9a1f8f8 EFLAGS: 00010202
> <4>[ 347.821229] RAX: RBX: c98479a0 RCX:
> 0018
> <4>[ 347.821252] RDX: RSI: 000d RDI:
> 888275a090b0
> <4>[ 347.821274] RBP: 8882673c8040 R08: 88825991b8d0 R09:
>
> <4>[ 347.821297] R10: R11: R12:
> 8882673c8280
> <4>[ 347.821319] R13: 8882673c8368 R14: R15:
> 888266a54000
> <4>[ 347.821343] FS: 7f75865f4240() GS:888277b8()
> knlGS:
> <4>[ 347.821368] CS: 0010 DS: ES: CR0: 80050033
> <4>[ 347.821389] CR2: 0150 CR3: 00025aee CR4:
> 003406e0
> <4>[ 347.821411] Call Trace:
> <4>[ 347.821555] i915_gem_object_prepare_read+0xea/0x2a0 [i915]
> <4>[ 347.821706] intel_engine_cmd_parser+0x5ce/0xe90 [i915]
> <4>[ 347.821834] ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
> <4>[ 347.821990] i915_gem_do_execbuffer+0xb4c/0x2550 [i915]
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 63bd3ff84f5e..458945e1823e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -279,10 +279,12 @@ i915_gem_object_flush_write_domain(struct
> drm_i915_gem_object *obj,
>
> switch (obj->write_domain) {
> case I915_GEM_DOMAIN_GTT:
> + spin_lock(&obj->vma.lock);
> for_each_ggtt_vma(vma, obj) {
> if (i915_vma_unset_ggtt_write(vma))
> intel_gt_flush_ggtt_writes(vma->vm->gt);
> }
> + spin_unlock(&obj->vma.lock);
>
> intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
> break;
> --
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/selftests: Add some selftests for drm_atomic_set_mode_for_crtc()
On Fri, Nov 15, 2019 at 09:42:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Test the basics of drm_atomic_set_mode_for_crtc(), and in particular
> verify that the function doesn't take the shortcut incorrectly.
>
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/selftests/Makefile| 3 +-
> .../gpu/drm/selftests/drm_modeset_selftests.h | 2 +
> .../gpu/drm/selftests/test-drm_atomic_uapi.c | 110 ++
> .../drm/selftests/test-drm_modeset_common.h | 2 +
> 4 files changed, 116 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
>
> diff --git a/drivers/gpu/drm/selftests/Makefile
> b/drivers/gpu/drm/selftests/Makefile
> index d2137342b371..a5adc25bd345 100644
> --- a/drivers/gpu/drm/selftests/Makefile
> +++ b/drivers/gpu/drm/selftests/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
>test-drm_format.o test-drm_framebuffer.o \
> - test-drm_damage_helper.o test-drm_dp_mst_helper.o
> + test-drm_damage_helper.o test-drm_dp_mst_helper.o \
> + test-drm_atomic_uapi.o
>
> obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
> test-drm_cmdline_parser.o
> diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> index 1898de0b4a4d..2cc4e2f43286 100644
> --- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> +++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> @@ -6,6 +6,8 @@
> *
> * Tests are executed in order by igt/drm_selftests_helper
> */
> +selftest(atomic_set_mode_for_crtc, igt_atomic_set_mode_for_crtc)
> +selftest(atomic_set_zeroed_mode_for_crtc,
> igt_atomic_set_zeroed_mode_for_crtc)
> selftest(check_plane_state, igt_check_plane_state)
> selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
> selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
> diff --git a/drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
> b/drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
> new file mode 100644
> index ..0f9a4d0d2541
> --- /dev/null
> +++ b/drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Test cases for the drm_atomic_uapi functions
> + */
> +
> +#define pr_fmt(fmt) "drm_atomic_uapi: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "test-drm_modeset_common.h"
> +
> +static const struct drm_display_mode zeroed_mode;
> +
> +static struct drm_driver mock_driver;
> +static struct drm_device mock_device;
> +static struct drm_crtc mock_crtc;
> +
> +static void init(void)
> +{
> + memset(&mock_driver, 0, sizeof(mock_driver));
> + memset(&mock_device, 0, sizeof(mock_device));
> + memset(&mock_crtc, 0, sizeof(mock_crtc));
> +
> + mock_device.driver = &mock_driver;
> + mock_crtc.dev = &mock_device;
> +
> + drm_mode_config_init(&mock_device);
> +}
Hm some todof for a real mock_driver would be nice. I think the static
stuff is a bit too icky, I think we should go a proper mock_drm_device a
la mock_gem_device in i915 selftests. and mock_drm_crtc. But meh ...
> +
> +static void cleanup(void)
> +{
> + drm_mode_config_cleanup(&mock_device);
> +}
> +
> +int igt_atomic_set_mode_for_crtc(void *ignored)
> +{
> + static const struct drm_display_mode mode1 = {
> + DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175,
> + 640, 656, 752, 800, 0, 480, 490, 492, 525, 0,
> + DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)
> + };
> + static const struct drm_display_mode mode2 = {
> + DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 65000,
> + 1024, 1048, 1184, 1344, 0, 768, 771, 777, 806, 0,
> + DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)
> + };
> + struct drm_crtc_state crtc_state = {
> + .crtc = &mock_crtc,
> + };
> + int ret;
> +
> + init();
> +
> + /*
> + * Make sure drm_atomic_set_mode_for_crtc()
> + * updates the crtc state correctly.
> + */
> + ret = drm_atomic_set_mode_for_crtc(&crtc_state, &mode1);
> + FAIL(ret < 0, "Unable to set mode on crtc\n");
> + FAIL_ON(!crtc_state.enable);
> + FAIL_ON(memcmp(&crtc_state.mode, &mode1, sizeof(mode1)));
> +
> + ret = drm_atomic_set_mode_for_crtc(&crtc_state, &mode2);
> + FAIL(ret < 0, "Unable to set mode on crtc\n");
> + FAIL_ON(!crtc_state.enable);
> + FAIL_ON(memcmp(&crtc_state.mode, &mode2, sizeof(mode2)));
> +
> + ret = drm_atomic_set_mode_for_crtc(&crtc_state, NULL);
> + FAIL(ret < 0, "Unable to unset mode on crtc\n");
> + FAIL_ON(crtc_state.enable);
> + FAIL_ON(memcmp(&crtc_state.mode, &zeroed_mode, sizeof(zeroed_mode))
Re: [Intel-gfx] [PATCH 7/7] drm/atomic: Reduce setplane locking
On Fri, Nov 15, 2019 at 09:42:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently setplane grabs all modeset locks, which seems a bit
> excessive. Let's reduce that to just the locks we really need
> on atomic drivers. For non-atomic drivers let's stick to the
> current scheme for now.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_plane.c | 56 +++--
> 1 file changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index ef0cc33b43ce..e40d8a93294b 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -680,10 +680,14 @@ static int __setplane_internal(struct drm_plane *plane,
> uint32_t src_w, uint32_t src_h,
> struct drm_modeset_acquire_ctx *ctx)
> {
> - int ret = 0;
> + int ret;
>
> WARN_ON(drm_drv_uses_atomic_modeset(plane->dev));
>
> + ret = drm_modeset_lock_all_ctx(plane->dev, ctx);
> + if (ret)
> + return ret;
There's pre-nv50 nouveau and shmob which have planes and aren't atomic (if
I checked correctly), so we could probably forgo this, but also feels
like totally not worth the audit trouble.
Reviewed-by: Daniel Vetter
> +
> /* No fb means shut it down */
> if (!fb) {
> plane->old_fb = plane->fb;
> @@ -767,32 +771,24 @@ static int setplane_internal(struct drm_plane *plane,
>uint32_t crtc_w, uint32_t crtc_h,
>/* src_{x,y,w,h} values are 16.16 fixed point */
>uint32_t src_x, uint32_t src_y,
> - uint32_t src_w, uint32_t src_h)
> + uint32_t src_w, uint32_t src_h,
> + struct drm_modeset_acquire_ctx *ctx)
> {
> - struct drm_modeset_acquire_ctx ctx;
> - int ret;
> -
> - DRM_MODESET_LOCK_ALL_BEGIN(plane->dev, ctx,
> -DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
> -
> if (drm_drv_uses_atomic_modeset(plane->dev))
> - ret = __setplane_atomic(plane, crtc, fb,
> - crtc_x, crtc_y, crtc_w, crtc_h,
> - src_x, src_y, src_w, src_h, &ctx);
> + return __setplane_atomic(plane, crtc, fb,
> + crtc_x, crtc_y, crtc_w, crtc_h,
> + src_x, src_y, src_w, src_h, ctx);
> else
> - ret = __setplane_internal(plane, crtc, fb,
> - crtc_x, crtc_y, crtc_w, crtc_h,
> - src_x, src_y, src_w, src_h, &ctx);
> -
> - DRM_MODESET_LOCK_ALL_END(ctx, ret);
> -
> - return ret;
> + return __setplane_internal(plane, crtc, fb,
> +crtc_x, crtc_y, crtc_w, crtc_h,
> +src_x, src_y, src_w, src_h, ctx);
> }
>
> int drm_mode_setplane(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> {
> struct drm_mode_set_plane *plane_req = data;
> + struct drm_modeset_acquire_ctx ctx;
> struct drm_plane *plane;
> struct drm_crtc *crtc = NULL;
> struct drm_framebuffer *fb = NULL;
> @@ -829,11 +825,22 @@ int drm_mode_setplane(struct drm_device *dev, void
> *data,
> }
> }
>
> + drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> +
> +retry:
> ret = setplane_internal(plane, crtc, fb,
> plane_req->crtc_x, plane_req->crtc_y,
> plane_req->crtc_w, plane_req->crtc_h,
> plane_req->src_x, plane_req->src_y,
> - plane_req->src_w, plane_req->src_h);
> + plane_req->src_w, plane_req->src_h, &ctx);
> + if (ret == -EDEADLK) {
> + ret = drm_modeset_backoff(&ctx);
> + if (!ret)
> + goto retry;
> + }
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
>
> if (fb)
> drm_framebuffer_put(fb);
> @@ -907,14 +914,9 @@ static int drm_mode_cursor_universal(struct drm_crtc
> *crtc,
> src_h = fb->height << 16;
> }
>
> - if (drm_drv_uses_atomic_modeset(dev))
> - ret = __setplane_atomic(plane, crtc, fb,
> - crtc_x, crtc_y, crtc_w, crtc_h,
> - 0, 0, src_w, src_h, ctx);
> - else
> - ret = __setplane_internal(plane, crtc, fb,
> - crtc_x, crtc_y, crtc_w, crtc_h,
> - 0, 0, src_w, src_h, ctx);
> + ret = setplane_internal(plane, crtc, fb,
> + crtc_x, crtc_y, crtc_w, crtc_h,
>
Re: [Intel-gfx] [PATCH 06/17] drm/i915/gem: Merge GGTT vma flush into a single loop
Chris Wilson writes:
> We only need the one loop to find the dirty vma flush them, and their
> chipset.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index db103d3c8760..63bd3ff84f5e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -279,18 +279,12 @@ i915_gem_object_flush_write_domain(struct
> drm_i915_gem_object *obj,
>
> switch (obj->write_domain) {
> case I915_GEM_DOMAIN_GTT:
> - for_each_ggtt_vma(vma, obj)
> - intel_gt_flush_ggtt_writes(vma->vm->gt);
> -
> - intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
> -
> for_each_ggtt_vma(vma, obj) {
> - if (vma->iomap)
> - continue;
> -
Is the story with iomap to just avoid fragility and
go with the same path, even if the flushes would be
superfluous?
-Mika
> - i915_vma_unset_ggtt_write(vma);
> + if (i915_vma_unset_ggtt_write(vma))
> + intel_gt_flush_ggtt_writes(vma->vm->gt);
> }
>
> + intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
> break;
>
> case I915_GEM_DOMAIN_WC:
> --
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/17] drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e14d64857e27 drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
0e0d80ce4269 drm/i915/gt: Close race between engine_park and
intel_gt_retire_requests
0b5064fe3a17 drm/i915/gt: Unlock engine-pm after queuing the kernel context
switch
5495539d7746 drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint
6fbb7bea4a75 drm/i915: Mark up the calling context for intel_wakeref_put()
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#14:
References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in
IRQ contexts")
total: 0 errors, 1 warnings, 0 checks, 239 lines checked
dfd3da54254c drm/i915/gem: Merge GGTT vma flush into a single loop
b31f2d6c64c4 drm/i915: Protect the obj->vma.list during iteration
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#9:
<1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
0150
total: 0 errors, 1 warnings, 0 checks, 12 lines checked
c0657a9ecb12 drm/i915: Wait until the intel_wakeref idle callback is complete
a1f5f04316e6 drm/i915/gt: Declare timeline.lock to be irq-free
3538cc446165 drm/i915/gt: Move new timelines to the end of active_list
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_retire_requests()")
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 7936a22dd466 ("drm/i915/gt: Wait
for new requests in intel_gt_retire_requests()")'
#10:
References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_retire_requests()")
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
1bccce657871 drm/i915/gt: Schedule next retirement worker first
89cb89b53169 drm/i915/gt: Flush the requests after wedging on suspend
931727919e07 drm/i915/selftests: Force bonded submission to overlap
108db4e60468 drm/i915/selftests: Flush the active callbacks
5dc926eaf8c6 drm/i915/selftests: Be explicit in ERR_PTR handling
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
References: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit f40a7b7558ef ("drm/i915: Initial
selftests for exercising eviction")'
#11:
References: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
-:25: WARNING:LONG_LINE: line over 100 characters
#25: FILE: drivers/gpu/drm/i915/selftests/i915_gem_evict.c:202:
+ pr_err("Failed to evict+insert, i915_gem_object_ggtt_pin
returned err=%d\n", (int)PTR_ERR_OR_ZERO(vma));
total: 1 errors, 2 warnings, 0 checks, 10 lines checked
924d7310cc96 drm/i915/selftests: Exercise rc6 handling
-:54: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#54:
new file mode 100644
-:59: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#59: FILE: drivers/gpu/drm/i915/gt/selftest_rc6.c:1:
+/*
-:60: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#60: FILE: drivers/gpu/drm/i915/gt/selftest_rc6.c:2:
+ * SPDX-License-Identifier: MIT
-:140: WARNING:LINE_SPACING: Missing a blank line after declarations
#140: FILE: drivers/gpu/drm/i915/gt/selftest_rc6.c:82:
+ unsigned int n, count;
+ I915_RND_STATE(prng);
-:211: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#211: FILE: drivers/gpu/drm/i915/gt/selftest_rc6.h:1:
+/*
-:212: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#212: FILE: drivers/gpu/drm/i915/gt/selftest_rc6.h:2:
+ * SPDX-License-Identifier: MIT
total: 0 errors, 6 warnings, 0 checks, 191 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/17] drm/i915/gem: Merge GGTT vma flush into a single loop
Quoting Mika Kuoppala (2019-11-19 10:48:22)
> Chris Wilson writes:
>
> > We only need the one loop to find the dirty vma flush them, and their
> > chipset.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
> > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index db103d3c8760..63bd3ff84f5e 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -279,18 +279,12 @@ i915_gem_object_flush_write_domain(struct
> > drm_i915_gem_object *obj,
> >
> > switch (obj->write_domain) {
> > case I915_GEM_DOMAIN_GTT:
> > - for_each_ggtt_vma(vma, obj)
> > - intel_gt_flush_ggtt_writes(vma->vm->gt);
> > -
> > - intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
> > -
> > for_each_ggtt_vma(vma, obj) {
> > - if (vma->iomap)
> > - continue;
> > -
>
> Is the story with iomap to just avoid fragility and
> go with the same path, even if the flushes would be
> superfluous?
The subtle difference between the two loops is the first is just
flushing anything the user had their hands on, and the second anything
the kernel was doing for itself.
I don't think it's that simple.
For userspace to invoke this function, it has called a set-domain ioctl.
So it should equally be marking its write with a set-domain ioctl for
set-domain to even work. At which point, we might as well just say that
this can only work if userspace does its due diligence in using
set-domain or userspace has to care about the CPU caches itself.
So given that userspace has to take care anyway, I don't see any harm
here in skipping the flushes if we have not marked them as dirty. Now,
having said that, we should then be marking all the ggtt as dirty for a
set-domain ggtt write...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Track ggtt writes from userspace on the bound vma
When userspace writes into the GTT itself, it is supposed to call
set-domain to let the kernel keep track and so manage the CPU/GPU
caches. As we track writes on the individual i915_vma, we should also be
sure to mark them as dirty.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index e2af63af67ad..9aebcf263191 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -149,9 +149,17 @@ i915_gem_object_set_to_gtt_domain(struct
drm_i915_gem_object *obj, bool write)
GEM_BUG_ON((obj->write_domain & ~I915_GEM_DOMAIN_GTT) != 0);
obj->read_domains |= I915_GEM_DOMAIN_GTT;
if (write) {
+ struct i915_vma *vma;
+
obj->read_domains = I915_GEM_DOMAIN_GTT;
obj->write_domain = I915_GEM_DOMAIN_GTT;
obj->mm.dirty = true;
+
+ spin_lock(&obj->vma.lock);
+ for_each_ggtt_vma(vma, obj)
+ if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
+ i915_vma_set_ggtt_write(vma);
+ spin_unlock(&obj->vma.lock);
}
i915_gem_object_unpin_pages(obj);
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/17] drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15325
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/index.html
New tests
-
New tests have been introduced between CI_DRM_7370 and Patchwork_15325:
### New IGT tests (1) ###
* igt@i915_selftest@live_late_gt_pm:
- Statuses : 38 pass(s)
- Exec time: [0.41, 1.44] s
Known issues
Here are the changes found in Patchwork_15325 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-bsw-kefka: [PASS][1] -> [INCOMPLETE][2] ([fdo# 111542])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-bsw-kefka/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-bsw-kefka/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_cpu_reloc@basic:
- fi-icl-dsi: [DMESG-WARN][3] ([fdo#106107]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-dsi/igt@gem_cpu_re...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-icl-dsi/igt@gem_cpu_re...@basic.html
* igt@i915_selftest@live_blt:
- fi-hsw-peppy: [DMESG-FAIL][5] ([fdo#112147]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-hsw-peppy/igt@i915_selftest@live_blt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-hsw-peppy/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-lmem:[DMESG-FAIL][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111407]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [SKIP][11] ([fdo#109271]) -> [PASS][12] +27 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][13] ([fdo#102614]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live_gt_pm:
- fi-icl-guc: [DMESG-FAIL][15] ([fdo#112205]) -> [INCOMPLETE][16]
([fdo#107713])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-guc/igt@i915_selftest@live_gt_pm.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/fi-icl-guc/igt@i915_selftest@live_gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo# 111542]: https://bugs.freedesktop.org/show_bug.cgi?id= 111542
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
[fdo#112205]: https://bugs.freedesktop.org/show_bug.cgi?id=112205
Participating hosts (49 -> 44)
--
Additional (1): fi-hsw-4770r
Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7370 -> Patchwork_15325
CI-20190529: 20190529
CI_DRM_7370: d2db945edccfe34bc3cc1d0accafac2036ad4e66 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5293: 4bb46f08f7cb6485642c4351cecdad93072d27a0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15325: 924d7310cc96e3131ed182b4d66c086109a73b7d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
924d7310cc96 drm/i915/selftests: Exercise rc6 handli
[Intel-gfx] [PATCH 4/4] drm/i915: Add cpu fault handler for mmap_offset
Fault handler to handle missing pages for shmem-backed objects.
v2: bail out of inserting PTEs when failing to insert the
fault address
v3: has struct page check
v4: Add self-test for validating CPU fault handler to ensure PTEs
are revoked when an object is unbound.
v5: Add comment where PTEs are revoked (Chris)
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 129 ++
.../drm/i915/gem/selftests/i915_gem_mman.c| 48 ++-
2 files changed, 145 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3913634ab717..b892f645ca2d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include "gt/intel_gt.h"
@@ -201,6 +202,71 @@ compute_partial_view(const struct drm_i915_gem_object *obj,
return view;
}
+static vm_fault_t i915_error_to_vmf_fault(int err)
+{
+ switch (err) {
+ default:
+ WARN_ONCE(err, "unhandled error in %s: %i\n", __func__, err);
+ /* fallthrough */
+ case -EIO: /* shmemfs failure from swap device */
+ case -EFAULT: /* purged object */
+ case -ENODEV: /* bad object, how did you get here! */
+ return VM_FAULT_SIGBUS;
+
+ case -ENOSPC: /* shmemfs allocation failure */
+ case -ENOMEM: /* our allocation failure */
+ return VM_FAULT_OOM;
+
+ case 0:
+ case -EAGAIN:
+ case -ERESTARTSYS:
+ case -EINTR:
+ case -EBUSY:
+ /*
+* EBUSY is ok: this just means that another thread
+* already did the job.
+*/
+ return VM_FAULT_NOPAGE;
+ }
+}
+
+static vm_fault_t i915_gem_fault_cpu(struct vm_fault *vmf)
+{
+ struct vm_area_struct *area = vmf->vma;
+ struct i915_mmap_offset *priv = area->vm_private_data;
+ struct drm_i915_gem_object *obj = priv->obj;
+ vm_fault_t vmf_ret;
+ unsigned long i, size = area->vm_end - area->vm_start;
+ bool write = area->vm_flags & VM_WRITE;
+ int ret;
+
+ if (!i915_gem_object_has_struct_page(obj))
+ return VM_FAULT_SIGBUS;
+
+ /* Sanity check that we allow writing into this object */
+ if (i915_gem_object_is_readonly(obj) && write)
+ return VM_FAULT_SIGBUS;
+
+ ret = i915_gem_object_pin_pages(obj);
+ if (ret)
+ return i915_error_to_vmf_fault(ret);
+
+ /* PTEs are revoked in obj->ops->put_pages() */
+ for (i = 0; i < size >> PAGE_SHIFT; i++) {
+ struct page *page = i915_gem_object_get_page(obj, i);
+
+ vmf_ret = vmf_insert_pfn(area,
+(unsigned long)area->vm_start + i *
PAGE_SIZE,
+page_to_pfn(page));
+ if (vmf_ret != VM_FAULT_NOPAGE)
+ break;
+ }
+
+ i915_gem_object_unpin_pages(obj);
+
+ return vmf_ret;
+}
+
/**
* i915_gem_fault - fault a page into the GTT
* @vmf: fault info
@@ -340,30 +406,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
intel_runtime_pm_put(rpm, wakeref);
i915_gem_object_unpin_pages(obj);
err:
- switch (ret) {
- default:
- WARN_ONCE(ret, "unhandled error in %s: %i\n", __func__, ret);
- /* fallthrough */
- case -EIO: /* shmemfs failure from swap device */
- case -EFAULT: /* purged object */
- case -ENODEV: /* bad object, how did you get here! */
- return VM_FAULT_SIGBUS;
-
- case -ENOSPC: /* shmemfs allocation failure */
- case -ENOMEM: /* our allocation failure */
- return VM_FAULT_OOM;
-
- case 0:
- case -EAGAIN:
- case -ERESTARTSYS:
- case -EINTR:
- case -EBUSY:
- /*
-* EBUSY is ok: this just means that another thread
-* already did the job.
-*/
- return VM_FAULT_NOPAGE;
- }
+ return i915_error_to_vmf_fault(ret);
}
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
@@ -647,6 +690,33 @@ static const struct vm_operations_struct
i915_gem_gtt_vm_ops = {
.close = i915_gem_vm_close,
};
+static const struct vm_operations_struct i915_gem_cpu_vm_ops = {
+ .fault = i915_gem_fault_cpu,
+ .open = i915_gem_vm_open,
+ .close = i915_gem_vm_close,
+};
+
+static void set_vmdata_mmap_offset(struct i915_mmap_offset *mmo, struct
vm_area_struct *vma)
+{
+ switch (mmo->mmap_type) {
+ case I915_MMAP_TYPE_WC:
+ vma->vm_page_prot =
+ pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+ break;
+ case I91
[Intel-gfx] [PATCH 3/4] drm/i915: cpu-map based dumb buffers
Prefer CPU WC mmaps via our new mmap offset plumbing otherwise fall-
back to GTT mmaps when hw doesn't support PAT
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Acked-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 ++
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 1 +
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index bb05c53c03c8..3913634ab717 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -540,6 +540,24 @@ __assign_gem_object_mmap_data(struct drm_file *file,
return ret;
}
+int
+i915_gem_mmap_dumb(struct drm_file *file,
+ struct drm_device *dev,
+ u32 handle,
+ u64 *offset)
+{
+ enum i915_mmap_type mmap_type;
+
+ if (boot_cpu_has(X86_FEATURE_PAT))
+ mmap_type = I915_MMAP_TYPE_WC;
+ else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
+ return -ENODEV;
+ else
+ mmap_type = I915_MMAP_TYPE_GTT;
+
+ return __assign_gem_object_mmap_data(file, handle, mmap_type, offset);
+}
+
/**
* i915_gem_mmap_offset_ioctl - prepare an object for GTT mmap'ing
* @dev: DRM device
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 4d3b493e853a..6e70b91dabc4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -24,6 +24,8 @@ void i915_mmap_offset_destroy(struct i915_mmap_offset *mmo,
struct mutex *mutex)
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
+int i915_gem_mmap_dumb(struct drm_file *file_priv, struct drm_device *dev,
+ u32 handle, u64 *offset);
int i915_gem_mmap_gtt_version(void);
#endif
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ac6d4470ce75..f7db0bbbe302 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2767,6 +2767,7 @@ static struct drm_driver driver = {
.get_scanout_position = i915_get_crtc_scanoutpos,
.dumb_create = i915_gem_dumb_create,
+ .dumb_map_offset = i915_gem_mmap_dumb,
.ioctls = i915_ioctls,
.num_ioctls = ARRAY_SIZE(i915_ioctls),
.fops = &i915_driver_fops,
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET
This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature
comes from the value returned by this ioctl which is the offset into the
device fd which userpace uses with mmap(2).
mmap_gtt was our initial mmap_offset implementation, this extends
our CPU mmap support to allow additional fault handlers that depends on
the object's backing pages.
Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
and use the zero extending behaviour of drm to differentiate between
them, when we inspect the flags.
v2:
- Drop the alias, just rename the struct (Chris)
- Don't bail out on no PAT when doing WB mmaps
- Prepare uAPI for further extensions
v3:
- drop MMAP_OFFSET_FLAGS
v4:
- Tweaks, header re-org
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 45 ---
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 1 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 ++
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
include/uapi/drm/i915_drm.h | 27 +++
7 files changed, 72 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
index ddc7f2a52b3e..87d8b27f426d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
@@ -28,8 +28,8 @@ int i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
-int i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file);
+int i915_gem_mmap_offset_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
int i915_gem_pread_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 36fffb671601..bb05c53c03c8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -145,6 +145,9 @@ static unsigned int tile_row_pages(const struct
drm_i915_gem_object *obj)
* 3 - Remove implicit set-domain(GTT) and synchronisation on initial
* pagefault; swapin remains transparent.
*
+ * 4 - Support multiple fault handlers per object depending on object's
+ * backing storage (a.k.a. MMAP_OFFSET).
+ *
* Restrictions:
*
* * snoopable objects cannot be accessed via the GTT. It can cause machine
@@ -172,7 +175,7 @@ static unsigned int tile_row_pages(const struct
drm_i915_gem_object *obj)
*/
int i915_gem_mmap_gtt_version(void)
{
- return 3;
+ return 4;
}
static inline struct i915_ggtt_view
@@ -538,7 +541,7 @@ __assign_gem_object_mmap_data(struct drm_file *file,
}
/**
- * i915_gem_mmap_gtt_ioctl - prepare an object for GTT mmap'ing
+ * i915_gem_mmap_offset_ioctl - prepare an object for GTT mmap'ing
* @dev: DRM device
* @data: GTT mapping ioctl data
* @file: GEM object info
@@ -553,13 +556,41 @@ __assign_gem_object_mmap_data(struct drm_file *file,
* userspace.
*/
int
-i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file)
+i915_gem_mmap_offset_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
{
- struct drm_i915_gem_mmap_gtt *args = data;
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_mmap_offset *args = data;
+ enum i915_mmap_type type;
+
+ switch (args->flags) {
+ case I915_MMAP_OFFSET_GTT:
+ if (!i915_ggtt_has_aperture(&i915->ggtt))
+ return -ENODEV;
+ type = I915_MMAP_TYPE_GTT;
+ break;
+
+ case I915_MMAP_OFFSET_WC:
+ if (!boot_cpu_has(X86_FEATURE_PAT))
+ return -ENODEV;
+ type = I915_MMAP_TYPE_WC;
+ break;
+
+ case I915_MMAP_OFFSET_WB:
+ type = I915_MMAP_TYPE_WB;
+ break;
+
+ case I915_MMAP_OFFSET_UC:
+ if (!boot_cpu_has(X86_FEATURE_PAT))
+ return -ENODEV;
+ type = I915_MMAP_TYPE_UC;
+ break;
+
+ default:
+ return -EINVAL;
+ }
- return __assign_gem_object_mmap_data(file, args->handle,
-I915_MMAP_TYPE_GTT,
+ return __assign_gem_object_mmap_data(file, args->handle, type,
&args->offset);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm
[Intel-gfx] [PATCH 1/4] drm/i915: Allow i915 to manage the vma offset nodes instead of drm core
Have i915 replace the core drm_gem_mmap implementation to overcome its
limitation in having only a single mmap offset node per gem object.
This change allows us to have multiple mmap offsets per object and
enables a mmapping instance to use unique fault-handlers per user vma.
This allows i915 to store extra data within vma->vm_private_data and
assign the pagefault ops for each mmap instance allowing objects to use
multiple fault handlers depending on its backing storage.
v2:
- Fix race condition exposed by gem_mmap_gtt@close-race. Simplify
lifetime management of the mmap offset objects be ensuring it is
owned by the parent gem object instead of refcounting.
- Track mmo used by fencing to avoid locking when revoking mmaps
during GPU reset.
- Rebase.
v3:
- Simplify mmo tracking
v4:
- use vma->mmo in __i915_gem_object_release_mmap_gtt
v5:
- Revoke CPU mmaps on i915_gem_object_unbind() since unlike GTT
mmaps, they don't have bound i915_vma objects. Rebase.
v6: Minor tweaks, header re-org (Chris)
v7:
- Call drm_vma_node_revoke for the mmo with corresponding file when
releasing the gem handle instead of in the mmo's teardown.
- Add flag I915_BO_READONLY instead of obj->readonly.
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 3 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 241 +++---
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 28 ++
drivers/gpu/drm/i915/gem/i915_gem_object.c| 18 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 7 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 19 ++
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 1 +
.../drm/i915/gem/selftests/i915_gem_mman.c| 20 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 7 +-
drivers/gpu/drm/i915/i915_drv.c | 11 +-
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
drivers/gpu/drm/i915/i915_vma.c | 3 +-
drivers/gpu/drm/i915/i915_vma.h | 3 +
16 files changed, 313 insertions(+), 58 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_mman.h
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index e2af63af67ad..fd1c6f12b77a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -13,6 +13,7 @@
#include "i915_gem_object.h"
#include "i915_vma.h"
#include "i915_gem_lmem.h"
+#include "i915_gem_mman.h"
static void __i915_gem_object_flush_for_display(struct drm_i915_gem_object
*obj)
{
@@ -255,7 +256,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
}
if (obj->userfault_count)
- __i915_gem_object_release_mmap(obj);
+ __i915_gem_object_release_mmap_gtt(obj);
/*
* As we no longer need a fence for GTT access,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d60973603cc1..36fffb671601 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -14,6 +14,7 @@
#include "i915_gem_gtt.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
+#include "i915_gem_mman.h"
#include "i915_trace.h"
#include "i915_vma.h"
@@ -219,7 +220,8 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
{
#define MIN_CHUNK_PAGES (SZ_1M >> PAGE_SHIFT)
struct vm_area_struct *area = vmf->vma;
- struct drm_i915_gem_object *obj = to_intel_bo(area->vm_private_data);
+ struct i915_mmap_offset *priv = area->vm_private_data;
+ struct drm_i915_gem_object *obj = priv->obj;
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *i915 = to_i915(dev);
struct intel_runtime_pm *rpm = &i915->runtime_pm;
@@ -312,6 +314,9 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
list_add(&obj->userfault_link, &i915->ggtt.userfault_list);
mutex_unlock(&i915->ggtt.vm.mutex);
+ /* Track the mmo associated with the fenced vma */
+ vma->mmo = priv;
+
if (IS_ACTIVE(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
@@ -358,28 +363,19 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
}
}
-void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
+void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
{
struct i915_vma *vma;
GEM_BUG_ON(!obj->userfault_count);
- obj->userfault_count = 0;
- list_del(&
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET
On 19/11/2019 13.37, Abdiel Janulgue wrote:
> +struct drm_i915_gem_mmap_offset {
> + /** Handle for the object being mapped. */
> + __u32 handle;
> + __u32 pad;
> + /**
> + * Fake offset to use for subsequent mmap call
> + *
> + * This is a fixed-size type for 32/64 compatibility.
> + */
> + __u64 offset;
> +
> + /**
> + * Flags for extended behaviour.
> + *
> + * It is mandatory that either one of the MMAP_OFFSET flags
> + * should be passed here.
> + */
> + __u64 flags;
> +#define I915_MMAP_OFFSET_GTT 0
> +#define I915_MMAP_OFFSET_WC 1
> +#define I915_MMAP_OFFSET_WB 2
> +#define I915_MMAP_OFFSET_UC 3
> +
> + __u64 extensions;
> +};
The simple memset IGT portion of this, coming up soon.
-Abdiel
___
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/dsi: Do not read the transcoder register.
== Series Details == Series: drm/i915/dsi: Do not read the transcoder register. URL : https://patchwork.freedesktop.org/series/69654/ State : success == Summary == CI Bug Log - changes from CI_DRM_7368_full -> Patchwork_15324_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_15324_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-iclb4/igt@gem_ctx_isolat...@vcs1-dirty-create.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-iclb8/igt@gem_ctx_isolat...@vcs1-dirty-create.html * igt@gem_eio@in-flight-contexts-10ms: - shard-snb: [PASS][3] -> [FAIL][4] ([fdo#111946]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-snb6/igt@gem_...@in-flight-contexts-10ms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-snb6/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_eio@suspend: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#111850]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-tglb1/igt@gem_...@suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-tglb1/igt@gem_...@suspend.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +15 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-iclb5/igt@gem_exec_sched...@preempt-queue-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-vebox: - shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([fdo#111677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-tglb5/igt@gem_exec_sched...@preempt-queue-chain-vebox.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-tglb6/igt@gem_exec_sched...@preempt-queue-chain-vebox.html * igt@gem_tiled_swapping@non-threaded: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#108686]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-iclb2/igt@gem_tiled_swapp...@non-threaded.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-iclb7/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@map-fixed-invalidate-busy: - shard-snb: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-snb7/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-snb7/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-hsw: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-hsw6/igt@gem_userptr_bl...@sync-unmap-cycles.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-hsw6/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@i915_selftest@live_gt_timelines: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111831]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-tglb3/igt@i915_selftest@live_gt_timelines.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-tglb7/igt@i915_selftest@live_gt_timelines.html * igt@i915_suspend@sysfs-reader: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([fdo#111832] / [fdo#111850]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-tglb8/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-tglb7/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-iclb: [PASS][23] -> [INCOMPLETE][24] ([fdo#107713]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7368/shard-iclb6/igt@kms_big...@linear-64bpp-rotate-0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15324/shard-iclb7/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_color@pipe-b-ctm-0-75: - shard-skl: [PASS][25] -> [DMESG-WARN][26] ([fdo#106107]) [25]: https://intel-gfx-ci.01.org/tree/drm-
Re: [Intel-gfx] [ANNOUNCEMENT] Documenting tests with igt_describe()
On 08/11/2019 11:04, Arkadiusz Hiler wrote: On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote: Quoting Arkadiusz Hiler (2019-11-07 17:38:20) We don't want you to translate C into English, we want you to provide a bit of that extra information that you would have put in the comments anyway. The comments should exist and are _inline_ with the code. And I encourage doing so. Detailed comments what this particular non-obvious chunk of code is doing are always welcome. In all the examples of igt_describe() I have seen, it is nowhere near the code so is useless; the information conveyed does not assist anyone in diagnosing or debugging the problem, so I yet to understand how it helps. They are supposed to document not the implementation but what is the grand idea behind a given subtest, so they are on a subtest level (or a group of subtests), which is our basic testing unit - this is what fails in CI, this is what you execute locally to reproduce the issue. Can you truly debug an issue or understand what the failure means without knowing what the test is supposed to prove? A lot of people here have struggled with this and often it takes a lot of time and requires advanced archeology with `git blame` hoping that there is at least one detailed enough commit message in there. If not then talking to people and relying on our tribal knowledge is required. As I have mentioned - getting the bigger picture from implementation details is hard. I get that you are not affected by this, but please do not deny the others. I kind of agree with Chris that I don't find that additional macro useful from the point of view of reading a particular test. A comment above the test function seems more appropriate, at least you don't have to look at 2 different places to find out about a particular test. Unless there is some untold goal here, like producing some kind of report in an automated way. -Lionel What is more useful, a link to the kernel coverage of the test and link to the test source code, or waffle? -Chris Those things are not exclusive. Coverage is extremely useful metric, source code is where the action happens but some higher-level explanations and waffles can coexist peacefully and make many lives much more pleasant. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V13 4/6] mdev: introduce mediated virtio bus
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
>
> On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
> > On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
> > > > On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
> > > > > +struct bus_type mdev_virtio_bus_type;
> > > > > +
> > > > > +struct mdev_virtio_device {
> > > > > + struct mdev_device mdev;
> > > > > + const struct mdev_virtio_ops *ops;
> > > > > + u16 class_id;
> > > > > +};
> > > > This seems to share nothing with mdev (ie mdev-vfio), why is it on the
> > > > same bus?
> > > I must be missing something - which bus do they share?
> > mdev_bus_type ?
> >
> > Jason
>
>
> Note: virtio has its own bus: mdev_virtio_bus_type. So they are not the same
> bus.
That is even worse, why involve struct mdev_device at all then?
Jason
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Track ggtt writes from userspace on the bound vma
== Series Details ==
Series: drm/i915/gem: Track ggtt writes from userspace on the bound vma
URL : https://patchwork.freedesktop.org/series/69672/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15326
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/index.html
Known issues
Here are the changes found in Patchwork_15326 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][1] -> [FAIL][2] ([fdo#108511])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_blt:
- fi-bsw-n3050: [PASS][3] -> [DMESG-FAIL][4] ([fdo#112176])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-bsw-n3050/igt@i915_selftest@live_blt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-bsw-n3050/igt@i915_selftest@live_blt.html
Possible fixes
* igt@gem_cpu_reloc@basic:
- fi-icl-dsi: [DMESG-WARN][5] ([fdo#106107]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-dsi/igt@gem_cpu_re...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-icl-dsi/igt@gem_cpu_re...@basic.html
* igt@i915_selftest@live_blt:
- fi-hsw-peppy: [DMESG-FAIL][7] ([fdo#112147]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-hsw-peppy/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-hsw-peppy/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-lmem:[DMESG-FAIL][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [SKIP][11] ([fdo#109271]) -> [PASS][12] +27 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][13] ([fdo#102614]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [FAIL][16] ([fdo#111045]
/ [fdo#111096])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15326/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
[fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
[fdo#112298]: https://bugs.freedesktop.org/show_bug.cgi?id=112298
Participating hosts (49 -> 44)
--
Additional (1): fi-hsw-4770r
Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7370 -> Patchwork_15326
CI-20190529: 20190529
CI_DRM_7370: d2db945edccfe34bc3cc1d0accafac2036ad4e66 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5293: 4bb46f08f7cb6485642c4351cecdad93072d27a0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15326: 6cb822fd72a04f74a4c0308c93e34feacf5e4c7a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6cb822fd72a0 drm/i915/gem: Track ggtt writes from userspace on the bound vma
== Logs ==
For more details see:
http
Re: [Intel-gfx] [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote: > > Also, see the other conversations we are having about a "virtual" bus > > and devices. I do not want to have two different ways of doing the same > > thing in the kernel at the same time please. Please work together with > > the Intel developers to solve this in a unified way, as you both > > need/want the same thing here. > > Sure, some functions looks similar, but the "virtual" bus does not contain a > management interface and it's not clear that how it can be used by userspace > driver. For this series, sysfs/GUID based management interface is reused and > we had a concrete example of how it would be used by userspace driver[1] and > a real hardware driver implementation[2]. The lifecycle stuff should be re-used through a library of this guid stuff, not by 'subclassing' mdev_device Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Allow i915 to manage the vma offset nodes instead of drm core
== Series Details == Series: series starting with [1/4] drm/i915: Allow i915 to manage the vma offset nodes instead of drm core URL : https://patchwork.freedesktop.org/series/69674/ State : warning == Summary == $ dim checkpatch origin/drm-tip badcc07981f3 drm/i915: Allow i915 to manage the vma offset nodes instead of drm core -:370: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #370: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:644: + + } -:401: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #401: new file mode 100644 -:406: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #406: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.h:1: +/* -:407: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #407: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.h:2: + * SPDX-License-Identifier: MIT -:626: CHECK:LINE_SPACING: Please don't use multiple blank lines #626: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:580: + -:801: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #801: FILE: drivers/gpu/drm/i915/i915_getparam.c:2: * SPDX-License-Identifier: MIT total: 0 errors, 4 warnings, 2 checks, 692 lines checked 614f0a31f6bf drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET -:183: WARNING:LONG_LINE: line over 100 characters #183: FILE: include/uapi/drm/i915_drm.h:398: +#define DRM_IOCTL_I915_GEM_MMAP_OFFSET DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_MMAP_GTT, struct drm_i915_gem_mmap_offset) total: 0 errors, 1 warnings, 0 checks, 150 lines checked f4981991370d drm/i915: cpu-map based dumb buffers -:23: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #23: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:545: +i915_gem_mmap_dumb(struct drm_file *file, + struct drm_device *dev, -:33: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or return #33: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:555: + return -ENODEV; + else -:51: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #51: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.h:28: +int i915_gem_mmap_dumb(struct drm_file *file_priv, struct drm_device *dev, + u32 handle, u64 *offset); total: 0 errors, 1 warnings, 2 checks, 39 lines checked 84e8b7b05885 drm/i915: Add cpu fault handler for mmap_offset ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [ANNOUNCEMENT] Documenting tests with igt_describe()
On Tue, Nov 19, 2019 at 02:37:17PM +0200, Lionel Landwerlin wrote: > On 08/11/2019 11:04, Arkadiusz Hiler wrote: > > On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote: > > > Quoting Arkadiusz Hiler (2019-11-07 17:38:20) > > > > We don't want you to translate C into English, we want you to provide a > > > > bit of > > > > that extra information that you would have put in the comments anyway. > > > The comments should exist and are _inline_ with the code. > > And I encourage doing so. Detailed comments what this particular > > non-obvious chunk of code is doing are always welcome. > > > > > In all the examples of igt_describe() I have seen, it is nowhere near > > > the code so is useless; the information conveyed does not assist > > > anyone in diagnosing or debugging the problem, so I yet to understand > > > how it helps. > > They are supposed to document not the implementation but what is the > > grand idea behind a given subtest, so they are on a subtest level (or a > > group of subtests), which is our basic testing unit - this is what fails > > in CI, this is what you execute locally to reproduce the issue. > > > > Can you truly debug an issue or understand what the failure means > > without knowing what the test is supposed to prove? > > > > A lot of people here have struggled with this and often it takes a lot > > of time and requires advanced archeology with `git blame` hoping that > > there is at least one detailed enough commit message in there. > > > > If not then talking to people and relying on our tribal knowledge is > > required. > > > > As I have mentioned - getting the bigger picture from implementation > > details is hard. I get that you are not affected by this, but please do > > not deny the others. > > > I kind of agree with Chris that I don't find that additional macro useful > from the point of view of reading a particular test. > > A comment above the test function seems more appropriate, at least you don't > have to look at 2 different places to find out about a particular test. > > > Unless there is some untold goal here, like producing some kind of report in > an automated way. Like this one? https://drm.pages.freedesktop.org/igt-gpu-tools/igt-kms-tests.html#kms_chamelium -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCEMENT] Documenting tests with igt_describe()
On Tue, Nov 19, 2019 at 02:37:17PM +0200, Lionel Landwerlin wrote: > On 08/11/2019 11:04, Arkadiusz Hiler wrote: > > On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote: > > > Quoting Arkadiusz Hiler (2019-11-07 17:38:20) > > > > We don't want you to translate C into English, we want you to provide a > > > > bit of > > > > that extra information that you would have put in the comments anyway. > > > The comments should exist and are _inline_ with the code. > > And I encourage doing so. Detailed comments what this particular > > non-obvious chunk of code is doing are always welcome. > > > > > In all the examples of igt_describe() I have seen, it is nowhere near > > > the code so is useless; the information conveyed does not assist > > > anyone in diagnosing or debugging the problem, so I yet to understand > > > how it helps. > > They are supposed to document not the implementation but what is the > > grand idea behind a given subtest, so they are on a subtest level (or a > > group of subtests), which is our basic testing unit - this is what fails > > in CI, this is what you execute locally to reproduce the issue. > > > > Can you truly debug an issue or understand what the failure means > > without knowing what the test is supposed to prove? > > > > A lot of people here have struggled with this and often it takes a lot > > of time and requires advanced archeology with `git blame` hoping that > > there is at least one detailed enough commit message in there. > > > > If not then talking to people and relying on our tribal knowledge is > > required. > > > > As I have mentioned - getting the bigger picture from implementation > > details is hard. I get that you are not affected by this, but please do > > not deny the others. > > > I kind of agree with Chris that I don't find that additional macro useful > from the point of view of reading a particular test. > > A comment above the test function seems more appropriate, at least you don't > have to look at 2 different places to find out about a particular test. There is no easy way of automated enforcing such comments unless we want to fork a tool like doxygen or write and maintain something on our own. You don't have to go to two places, you can organize the comments however you like, see what kms_chamelium is doing: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_chamelium.c#L456 You can even use a format string and igt_describe_f() in a loop or just slap it over whole igt_subtest_group(). Once again - this is the only way we have found to make this enforcible, and give us enough of flexibility to shuffle the text around. > Unless there is some untold goal here, like producing some kind of report in > an automated way. > > > -Lionel The goal is to have those descriptions in the first place and make them more accessible to people. You have to keep in mind that we have decently sized organization, people are coming and going. Not everyone becomes a seasoned kernel developer day one and not everyone looking at the tests and their results is a developer. There are some extra benefit that I see that is related to "automated report" you have mentioned but it was not the main reason: you can put the description of the tests with bugs filed with the CI. There is probably more ways in which we could expose that data. -- Cheers, Arek > > > What is more useful, a link to the kernel coverage of the test and > > > link to the test source code, or waffle? > > > -Chris > > Those things are not exclusive. Coverage is extremely useful metric, > > source code is where the action happens but some higher-level > > explanations and waffles can coexist peacefully and make many lives much > > more pleasant. > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 0/8] Add support for mipi dsi cmd mode
Addressed comments on RFC-v2 from Jani, thanks. Vandita Kulkarni (8): drm/i915/dsi: Configure transcoder operation for command mode. drm/i915/dsi: Add vblank calculation for command mode drm/i915/dsi: Add cmd mode flags in display mode private flags drm/i915/dsi: Add check for periodic command mode drm/i915/dsi: Use private flags to indicate TE in cmd mode drm/i915/dsi: Configure TE interrupt for cmd mode drm/i915/dsi: Add TE handler for dsi cmd mode. drm/i915/dsi: Initiate fame request in cmd mode drivers/gpu/drm/i915/display/icl_dsi.c| 150 -- drivers/gpu/drm/i915/display/intel_display.c | 10 ++ .../drm/i915/display/intel_display_types.h| 10 ++ drivers/gpu/drm/i915/display/intel_dsi.h | 3 + drivers/gpu/drm/i915/i915_irq.c | 119 +- 5 files changed, 277 insertions(+), 15 deletions(-) -- 2.21.0.5.gaeb582a ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 8/8] drm/i915/dsi: Initiate fame request in cmd mode
In TE Gate mode, on every flip we need to set the
frame update request bit. After this bit is set
transcoder hardware will automatically send the
frame data to the panel when it receives the TE event.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 22
drivers/gpu/drm/i915/display/intel_display.c | 10 +
drivers/gpu/drm/i915/display/intel_dsi.h | 3 +++
3 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 8db3a0f48c39..78fc32065661 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -198,6 +198,28 @@ static int dsi_send_pkt_payld(struct intel_dsi_host *host,
return 0;
}
+void gen11_dsi_frame_update(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 tmp, private_flags;
+ enum port port;
+
+ private_flags = crtc_state->hw.adjusted_mode.private_flags;
+
+ /* case 1 also covers dual link */
+ if (private_flags & I915_MODE_FLAG_DSI_USE_TE0)
+ port = PORT_A;
+ else if (private_flags & I915_MODE_FLAG_DSI_USE_TE1)
+ port = PORT_B;
+ else
+ return;
+
+ tmp = I915_READ(DSI_CMD_FRMCTL(port));
+ tmp |= DSI_FRAME_UPDATE_REQUEST;
+ I915_WRITE(DSI_CMD_FRMCTL(port), tmp);
+}
+
static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dccb94b24d14..5fc42689087a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14886,6 +14886,16 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_color_load_luts(new_crtc_state);
}
+ /*
+* Incase of mipi dsi command mode, we need to set frame update
+* for every commit
+*/
+ if ((INTEL_GEN(dev_priv) >= 11) &&
+ (intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))) {
+ if (new_crtc_state->hw.active)
+ gen11_dsi_frame_update(new_crtc_state);
+ }
+
/*
* Now that the vblank has passed, we can go ahead and program the
* optimal watermarks on platforms that need two-step watermark
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
b/drivers/gpu/drm/i915/display/intel_dsi.h
index b15be5814599..0c5366e23feb 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi.h
@@ -201,6 +201,9 @@ u32 bxt_dsi_get_pclk(struct intel_encoder *encoder,
struct intel_crtc_state *config);
void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
+/* icl_dsi.c */
+void gen11_dsi_frame_update(struct intel_crtc_state *crtc_state);
+
/* intel_dsi_vbt.c */
bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id);
void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 4/8] drm/i915/dsi: Add check for periodic command mode
If the GOP has programmed periodic command mode,
we need to disable that which would need a
deconfigure and configure sequence.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 96f912b153e9..5bbaac5980ca 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1306,6 +1306,21 @@ static void gen11_dsi_get_timings(struct intel_encoder
*encoder,
adjusted_mode->crtc_vblank_end = adjusted_mode->crtc_vtotal;
}
+bool gen11_dsi_is_periodic_cmd_mode(struct drm_i915_private *dev_priv,
+ struct intel_dsi *intel_dsi)
+{
+ u32 val;
+ enum transcoder dsi_trans;
+
+ if (intel_dsi->ports == BIT(PORT_B))
+ dsi_trans = TRANSCODER_DSI_1;
+ else
+ dsi_trans = TRANSCODER_DSI_0;
+
+ val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+ return (val & DSI_PERIODIC_FRAME_UPDATE_ENABLE);
+}
+
static void gen11_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -1324,6 +1339,10 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
gen11_dsi_get_timings(encoder, pipe_config);
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc);
+
+ if (gen11_dsi_is_periodic_cmd_mode(dev_priv, intel_dsi))
+ pipe_config->hw.adjusted_mode.private_flags |=
+ I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
}
static int gen11_dsi_compute_config(struct intel_encoder *encoder,
@@ -1354,6 +1373,9 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
pipe_config->clock_set = true;
pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
+ /* We would not opereate in peridoc command mode */
+ pipe_config->hw.adjusted_mode.private_flags &=
+ ~I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
return 0;
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 2/8] drm/i915/dsi: Add vblank calculation for command mode
Transcoder timing calculation differ for command mode.
v2: Use is_vid_mode, and use same I915_WRITE (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 39 +-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 089c630526bc..96f912b153e9 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -791,6 +791,7 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder
*encoder,
u16 hback_porch;
/* vertical timings */
u16 vtotal, vactive, vsync_start, vsync_end, vsync_shift;
+ int bpp, line_time_us, byte_clk_period_ns;
hactive = adjusted_mode->crtc_hdisplay;
htotal = adjusted_mode->crtc_htotal;
@@ -828,7 +829,7 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder
*encoder,
}
/* TRANS_HSYNC register to be programmed only for video mode */
- if (intel_dsi->operation_mode == INTEL_DSI_VIDEO_MODE) {
+ if (is_vid_mode(intel_dsi)) {
if (intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE) {
/* BSPEC: hsync size should be atleast 16 pixels */
@@ -852,12 +853,20 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder
*encoder,
}
/* program TRANS_VTOTAL register */
+ if (is_cmd_mode(intel_dsi)) {
+ bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
+ byte_clk_period_ns = 8 * 100 / intel_dsi->pclk;
+ htotal = hactive + 160;
+ line_time_us = (htotal * (bpp / 8) * byte_clk_period_ns) /
(1000 * intel_dsi->lane_count);
+ vtotal = vactive + DIV_ROUND_UP(460, line_time_us);
+ }
+
for_each_dsi_port(port, intel_dsi->ports) {
dsi_trans = dsi_port_to_transcoder(port);
/*
-* FIXME: Programing this by assuming progressive mode, since
-* non-interlaced info from VBT is not saved inside
-* struct drm_display_mode.
+* FIXME: Programing this by assuming progressive mode,
+* since non-interlaced info from VBT is not saved
+* inside struct drm_display_mode.
* For interlace mode: program required pixel minus 2
*/
I915_WRITE(VTOTAL(dsi_trans),
@@ -870,22 +879,26 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder
*encoder,
if (vsync_start < vactive)
DRM_ERROR("vsync_start less than vactive\n");
- /* program TRANS_VSYNC register */
- for_each_dsi_port(port, intel_dsi->ports) {
- dsi_trans = dsi_port_to_transcoder(port);
- I915_WRITE(VSYNC(dsi_trans),
- (vsync_start - 1) | ((vsync_end - 1) << 16));
+ /* program TRANS_VSYNC register for video mode only */
+ if (is_vid_mode(intel_dsi)) {
+ for_each_dsi_port(port, intel_dsi->ports) {
+ dsi_trans = dsi_port_to_transcoder(port);
+ I915_WRITE(VSYNC(dsi_trans),
+ (vsync_start - 1) | ((vsync_end - 1) << 16));
+ }
}
/*
-* FIXME: It has to be programmed only for interlaced
+* FIXME: It has to be programmed only for video modes and interlaced
* modes. Put the check condition here once interlaced
* info available as described above.
* program TRANS_VSYNCSHIFT register
*/
- for_each_dsi_port(port, intel_dsi->ports) {
- dsi_trans = dsi_port_to_transcoder(port);
- I915_WRITE(VSYNCSHIFT(dsi_trans), vsync_shift);
+ if (is_vid_mode(intel_dsi)) {
+ for_each_dsi_port(port, intel_dsi->ports) {
+ dsi_trans = dsi_port_to_transcoder(port);
+ I915_WRITE(VSYNCSHIFT(dsi_trans), vsync_shift);
+ }
}
/* program TRANS_VBLANK register, should be same as vtotal programmed */
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 5/8] drm/i915/dsi: Use private flags to indicate TE in cmd mode
On dsi cmd mode we do not receive vblanks instead
we would get TE and these flags indicate TE is expected on
which port.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 5bbaac5980ca..8db3a0f48c39 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1376,6 +1376,21 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
/* We would not opereate in peridoc command mode */
pipe_config->hw.adjusted_mode.private_flags &=
~I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
+
+ /*
+* In case of TE GATE cmd mode, we
+* receive TE from the slave if
+* dual link is enabled
+*/
+ if (is_cmd_mode(intel_dsi)) {
+ if (intel_dsi->ports == BIT(PORT_B))
+ pipe_config->hw.adjusted_mode.private_flags |=
+ I915_MODE_FLAG_DSI_USE_TE1;
+ else
+ pipe_config->hw.adjusted_mode.private_flags |=
+ I915_MODE_FLAG_DSI_USE_TE0;
+ }
+
return 0;
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 3/8] drm/i915/dsi: Add cmd mode flags in display mode private flags
Adding TE flags and periodic command mode flags
as part of private flags to indicate what TE interrupts
we would be getting instead of vblanks in case of mipi dsi
command mode.
v2: Add TE flag description (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_display_types.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 83ea04149b77..1e071cfb3ff7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -656,6 +656,16 @@ struct intel_crtc_scaler_state {
#define I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP (1<<1)
/* Flag to use the scanline counter instead of the pixel counter */
#define I915_MODE_FLAG_USE_SCANLINE_COUNTER (1<<2)
+/*
+ * TE0 or TE1 flag is set if the crtc has a DSI encoder which
+ * is operating in command mode.
+ * Flag to use TE from DSI0 instead of VBI in command mode
+ */
+#define I915_MODE_FLAG_DSI_USE_TE0 (1<<3)
+/* Flag to use TE from DSI1 instead of VBI in command mode */
+#define I915_MODE_FLAG_DSI_USE_TE1 (1<<4)
+/* Flag to indicate mipi dsi periodic command mode where we do not get TE */
+#define I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE (1<<5)
struct intel_pipe_wm {
struct intel_wm_level wm[5];
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 7/8] drm/i915/dsi: Add TE handler for dsi cmd mode.
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
v2: Pass only relevant masked bits to the handler (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 64 +
1 file changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a3d1fc0bfb56..a8c7043640db 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2230,6 +2230,62 @@ gen8_de_misc_irq_handler(struct drm_i915_private
*dev_priv, u32 iir)
DRM_ERROR("Unexpected DE Misc interrupt\n");
}
+void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv,
+ u32 te_trigger)
+{
+ enum pipe pipe = INVALID_PIPE;
+ enum transcoder dsi_trans;
+ enum port port;
+ u32 val, tmp;
+
+ /*
+* Incase of dual link, TE comes from DSI_1
+* this is to check if dual link is enabled
+*/
+ val = I915_READ(TRANS_DDI_FUNC_CTL2(TRANSCODER_DSI_0));
+ val &= PORT_SYNC_MODE_ENABLE;
+
+ /*
+* if dual link is enabled, then read DSI_0
+* transcoder registers
+*/
+ port = ((te_trigger & DSI1_TE && val) || (te_trigger & DSI0_TE)) ?
+ PORT_A : PORT_B;
+ dsi_trans = (port == PORT_A) ? TRANSCODER_DSI_0 : TRANSCODER_DSI_1;
+
+ /* Check if DSI configured in command mode */
+ val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+ val = (val & OP_MODE_MASK) >> 28;
+
+ if (val) {
+ DRM_ERROR("DSI trancoder not configured in command mode\n");
+ return;
+ }
+
+ /* Get PIPE for handling VBLANK event */
+ val = I915_READ(TRANS_DDI_FUNC_CTL(dsi_trans));
+ switch (val & TRANS_DDI_EDP_INPUT_MASK) {
+ case TRANS_DDI_EDP_INPUT_A_ON:
+ pipe = PIPE_A;
+ break;
+ case TRANS_DDI_EDP_INPUT_B_ONOFF:
+ pipe = PIPE_B;
+ break;
+ case TRANS_DDI_EDP_INPUT_C_ONOFF:
+ pipe = PIPE_C;
+ break;
+ default:
+ DRM_ERROR("Invalid PIPE\n");
+ }
+
+ /* clear TE in dsi IIR */
+ port = (te_trigger & DSI1_TE) ? PORT_B : PORT_A;
+ tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+ I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+
+ drm_handle_vblank(&dev_priv->drm, pipe);
+}
+
static irqreturn_t
gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
{
@@ -2294,6 +2350,14 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
found = true;
}
+ if (INTEL_GEN(dev_priv) >= 11) {
+ tmp_mask = iir & (DSI0_TE | DSI1_TE);
+ if (tmp_mask) {
+
gen11_dsi_te_interrupt_handler(dev_priv, tmp_mask);
+ found = true;
+ }
+ }
+
if (!found)
DRM_ERROR("Unexpected DE Port interrupt\n");
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 1/8] drm/i915/dsi: Configure transcoder operation for command mode.
Configure the transcoder to operate in TE GATE command mode
and take TE events from GPIO.
Also disable the periodic command mode, that GOP would have
programmed.
v2: Disable util pin (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index f688207932e0..089c630526bc 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -704,6 +704,18 @@ gen11_dsi_configure_transcoder(struct intel_encoder
*encoder,
tmp |= VIDEO_MODE_SYNC_PULSE;
break;
}
+ } else {
+ /*
+* FIXME: Retrieve this info from VBT.
+* As per the spec when dsi transcoder is operating
+* in TE GATE mode, TE comes from GPIO
+* which is UTIL PIN for DSI 0.
+* Also this GPIO would not be used for other
+* purposes is an assumption.
+*/
+ tmp &= ~OP_MODE_MASK;
+ tmp |= CMD_MODE_TE_GATE;
+ tmp |= TE_SOURCE_GPIO;
}
I915_WRITE(DSI_TRANS_FUNC_CONF(dsi_trans), tmp);
@@ -956,6 +968,32 @@ static void gen11_dsi_setup_timeouts(struct intel_encoder
*encoder)
}
}
+static void gen11_dsi_config_util_pin(struct intel_encoder *encoder,
+ bool enable)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ u32 tmp;
+
+ /*
+* used as TE i/p for DSI0,
+* for dual link/DSI1 TE is from slave DSI1
+* through GPIO.
+*/
+ if (is_vid_mode(intel_dsi) || (intel_dsi->ports & BIT(PORT_B)))
+ return;
+
+ tmp = I915_READ(UTIL_PIN_CTL);
+
+ if (enable) {
+ tmp |= UTIL_PIN_DIRECTION_INPUT;
+ tmp |= UTIL_PIN_ENABLE;
+ } else
+ tmp &= ~UTIL_PIN_ENABLE;
+
+ I915_WRITE(UTIL_PIN_CTL, tmp);
+}
+
static void
gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
@@ -977,6 +1015,9 @@ gen11_dsi_enable_port_and_phy(struct intel_encoder
*encoder,
/* setup D-PHY timings */
gen11_dsi_setup_dphy_timings(encoder);
+ /* Since transcoder is configured to take events from GPIO */
+ gen11_dsi_config_util_pin(encoder, true);
+
/* step 4h: setup DSI protocol timeouts */
gen11_dsi_setup_timeouts(encoder);
@@ -1107,6 +1148,15 @@ static void gen11_dsi_deconfigure_trancoder(struct
intel_encoder *encoder)
enum transcoder dsi_trans;
u32 tmp;
+ /* disable periodic update mode */
+ if (is_cmd_mode(intel_dsi)) {
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(DSI_CMD_FRMCTL(port));
+ tmp &= ~DSI_PERIODIC_FRAME_UPDATE_ENABLE;
+ I915_WRITE(DSI_CMD_FRMCTL(port), tmp);
+ }
+ }
+
/* put dsi link in ULPS */
for_each_dsi_port(port, intel_dsi->ports) {
dsi_trans = dsi_port_to_transcoder(port);
@@ -1210,6 +1260,8 @@ static void gen11_dsi_disable(struct intel_encoder
*encoder,
/* step3: disable port */
gen11_dsi_disable_port(encoder);
+ gen11_dsi_config_util_pin(encoder, false);
+
/* step4: disable IO power */
gen11_dsi_disable_io_power(encoder);
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V3 6/8] drm/i915/dsi: Configure TE interrupt for cmd mode
We need to configure TE interrupt in two places.
Port interrupt and DSI interrupt mask registers.
v2: Hide the private flags check inside configure_te (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 55 +++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dae00f7dd7df..a3d1fc0bfb56 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -41,6 +41,7 @@
#include "display/intel_hotplug.h"
#include "display/intel_lpe_audio.h"
#include "display/intel_psr.h"
+#include "display/intel_dsi.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_irq.h"
@@ -2571,12 +2572,46 @@ int ilk_enable_vblank(struct drm_crtc *crtc)
return 0;
}
+static bool gen11_dsi_configure_te(struct drm_i915_private *dev_priv,
+ struct drm_display_mode *mode, bool enable)
+{
+ enum port port;
+ u32 tmp;
+
+ if (!(mode->private_flags &
+ (I915_MODE_FLAG_DSI_USE_TE1 | I915_MODE_FLAG_DSI_USE_TE0)))
+ return false;
+
+ if (mode->private_flags & I915_MODE_FLAG_DSI_USE_TE1)
+ port = PORT_B;
+ else
+ port = PORT_A;
+
+ tmp = I915_READ(DSI_INTR_MASK_REG(port));
+ if (enable)
+ tmp &= ~DSI_TE_EVENT;
+ else
+ tmp |= DSI_TE_EVENT;
+
+ I915_WRITE(DSI_INTR_MASK_REG(port), tmp);
+ return true;
+}
+
int bdw_enable_vblank(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_vblank_crtc *vblank;
+ struct drm_display_mode *mode;
unsigned long irqflags;
+ vblank = &crtc->dev->vblank[drm_crtc_index(crtc)];
+ mode = &vblank->hwmode;
+
+ if (gen11_dsi_configure_te(dev_priv, mode, true))
+ return 0;
+
spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
@@ -2642,9 +2677,18 @@ void ilk_disable_vblank(struct drm_crtc *crtc)
void bdw_disable_vblank(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_vblank_crtc *vblank;
+ struct drm_display_mode *mode;
unsigned long irqflags;
+ vblank = &crtc->dev->vblank[drm_crtc_index(crtc)];
+ mode = &vblank->hwmode;
+
+ if (gen11_dsi_configure_te(dev_priv, mode, false))
+ return;
+
spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
@@ -3350,6 +3394,13 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
gen3_assert_iir_is_zero(uncore, EDP_PSR_IIR);
}
+ if (INTEL_GEN(dev_priv) >= 11) {
+ enum port port;
+
+ if (intel_bios_is_dsi_present(dev_priv, &port))
+ de_port_masked |= DSI0_TE | DSI1_TE;
+ }
+
for_each_pipe(dev_priv, pipe) {
dev_priv->de_irq_mask[pipe] = ~de_pipe_masked;
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for mipi dsi cmd mode (rev2)
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fdc21d81bb9e drm/i915/dsi: Configure transcoder operation for command mode.
-:60: CHECK:BRACES: braces {} should be used on all arms of this statement
#60: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:988:
+ if (enable) {
[...]
+ } else
[...]
-:63: CHECK:BRACES: Unbalanced braces around else statement
#63: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:991:
+ } else
total: 0 errors, 0 warnings, 2 checks, 82 lines checked
14ef58b82e3d drm/i915/dsi: Add vblank calculation for command mode
-:41: WARNING:LONG_LINE: line over 100 characters
#41: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:860:
+ line_time_us = (htotal * (bpp / 8) * byte_clk_period_ns) /
(1000 * intel_dsi->lane_count);
total: 0 errors, 1 warnings, 0 checks, 73 lines checked
efeb2e076cc1 drm/i915/dsi: Add cmd mode flags in display mode private flags
-:30: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#30: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:664:
+#define I915_MODE_FLAG_DSI_USE_TE0 (1<<3)
^
-:32: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#32: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:666:
+#define I915_MODE_FLAG_DSI_USE_TE1 (1<<4)
^
-:34: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#34: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:668:
+#define I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE (1<<5)
^
total: 0 errors, 0 warnings, 3 checks, 16 lines checked
ef45ca1a8eed drm/i915/dsi: Add check for periodic command mode
41fd924cda49 drm/i915/dsi: Use private flags to indicate TE in cmd mode
6222c0176bcb drm/i915/dsi: Configure TE interrupt for cmd mode
c61d2184cd7b drm/i915/dsi: Add TE handler for dsi cmd mode.
8d1db9bddfa7 drm/i915/dsi: Initiate fame request in cmd mode
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add support for mipi dsi cmd mode (rev2)
== Series Details == Series: Add support for mipi dsi cmd mode (rev2) URL : https://patchwork.freedesktop.org/series/69290/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/dsi: Configure transcoder operation for command mode. Okay! Commit: drm/i915/dsi: Add vblank calculation for command mode Okay! Commit: drm/i915/dsi: Add cmd mode flags in display mode private flags Okay! Commit: drm/i915/dsi: Add check for periodic command mode - +drivers/gpu/drm/i915/display/icl_dsi.c:1309:6: warning: symbol 'gen11_dsi_is_periodic_cmd_mode' was not declared. Should it be static? Commit: drm/i915/dsi: Use private flags to indicate TE in cmd mode Okay! Commit: drm/i915/dsi: Configure TE interrupt for cmd mode Okay! Commit: drm/i915/dsi: Add TE handler for dsi cmd mode. - +drivers/gpu/drm/i915/i915_irq.c:2233:6: warning: symbol 'gen11_dsi_te_interrupt_handler' was not declared. Should it be static? Commit: drm/i915/dsi: Initiate fame request in cmd mode Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCEMENT] Documenting tests with igt_describe()
On 19/11/2019 15:02, Arkadiusz Hiler wrote: The goal is to have those descriptions in the first place and make them more accessible to people. You have to keep in mind that we have decently sized organization, people are coming and going. Not everyone becomes a seasoned kernel developer day one and not everyone looking at the tests and their results is a developer. Right, that's what I didn't get from your first email. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7] drm/i915: Enable second dbuf slice for ICL and TGL
On Mon, 2019-11-18 at 20:25 +, Lisovskiy, Stanislav wrote:
P.S: (In addition to my last yesterday letter):
>
> That is actually a violation of BSpec, we are not using two slices
> for same
> pipe while we could. We had already enough of bw issues, why should
> we make our life even harder?
>
> > > > > > +/*
> > > > > > + * Table taken from Bspec 49255
> > > > > > + * Pipes do have some preferred DBuf slice affinity,
> > > > > > + * plus there are some hardcoded requirements on how
> > > > > > + * those should be distributed for multipipe scenarios.
> > > > > > + * For more DBuf slices algorithm can get even more messy
> > > > > > + * and less readable, so decided to use a table almost
> > > > > > + * as is from BSpec itself - that way it is at least
> > > > > > easier
> > > > > > + * to compare, change and check.
> > > > > > + */
> > > > > > +struct dbuf_slice_conf_entry tgl_allowed_dbufs[] = {
> > > > > > +{ { 0, 0, 0, 0 }, 0 },
> > > > > > +ICL_PIPE_A_DBUF_SLICES(DBUF_S1_BIT | DBUF_S2_BIT),
> > > > > > +ICL_PIPE_B_DBUF_SLICES(DBUF_S1_BIT | DBUF_S2_BIT),
> > > > > > +ICL_PIPE_C_DBUF_SLICES(DBUF_S1_BIT | DBUF_S2_BIT),
> > > > > > +ICL_PIPE_D_DBUF_SLICES(DBUF_S1_BIT | DBUF_S2_BIT),
> > > > > > +ICL_PIPE_AB_DBUF_SLICES(DBUF_S2_BIT, DBUF_S1_BIT),
> > > > > > +ICL_PIPE_AC_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT),
> > > > > > +ICL_PIPE_BC_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT),
> > > > > > +ICL_PIPE_AD_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT),
> > > > > > +ICL_PIPE_BD_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT),
> > > > > > +ICL_PIPE_CD_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT),
> > > > > > +ICL_PIPE_ABD_DBUF_SLICES(DBUF_S1_BIT, DBUF_S1_BIT,
> > > > > > DBUF_S2_BIT),
> > > > > > +ICL_PIPE_ABC_DBUF_SLICES(DBUF_S1_BIT, DBUF_S1_BIT,
> > > > > > DBUF_S2_BIT),
> > > > > > +ICL_PIPE_ACD_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT,
> > > > > > DBUF_S2_BIT),
> > > > > > +ICL_PIPE_BCD_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT,
> > > > > > DBUF_S2_BIT),
> > > > > > +ICL_PIPE_ABCD_DBUF_SLICES(DBUF_S1_BIT, DBUF_S1_BIT,
> > > > > > DBUF_S2_BIT,
> > > > > > DBUF_S2_BIT),
> > > > > > +};
> > > > >
> > > > > My eyes!
> > > > >
> > > > > I have to think we should be able to reduce all that to a
> > > > > handful
> > > > > of lines of code.
> > > >
> > > > Yeah, then we are going to have a huge function with lots of
> > > > weird
> > > > definitions, unfortunately BSpec table has quite strange DBuf
> > > > assignments like
> > > > +ICL_PIPE_AB_DBUF_SLICES(DBUF_S2_BIT, DBUF_S1_BIT),
> > > > +ICL_PIPE_AC_DBUF_SLICES(DBUF_S1_BIT, DBUF_S2_BIT),
> > > >
> > > > i.e slices can get mixed in a quite various ways. There is no
> > > > rational pattern in those and could be even dangerous to try to
> > > > optimize it some way, as one day it might change again in some
> > > > unpredictable way.
> > > >
> > > > Would you prefer to have it like
> > > >
> > > > if (pipes are A and B)
> > > > program S2 to A and S1 to B
> > > > if (pipes are A and C)
> > > > program S1 to A and S2 to C
> > > > ...
> > > >
> > > > I would prefer at least to see it in a comparable way with the
> > > > table we have in BSpec, rather than having lots of weird
> > > > looking
> > > > if-else statements, GEN checks and so on.
> > > >
> > > > I knew this table was not going to look like it is done
> > > > typically
> > > > here - but really my opinion that it is way better than
> > > > hardcoding
> > > > it into some weird algorithm, which would be hard to compare to
> > > > initial table, which is already strange enough.
> > > >
> > > > If you don't like it - could you please explain why this is
> > > > exactly
> > > > worse than having long functions with hardcoded checks?
> > >
> > > I think we should be able to encode this simply using the
> > > "Pipe and DBUF ordering" stuff from the spec. Ie. just specify
> > > what
> > > is the distance of each pipe from each dbuf slice. Then all we
> > > have
> > > to do is minimize the total distance. The following tables I
> > > think
> > > should encode that reasonably concisely:
> > >
> > > /* pipeA - DBUF_S1 - pipeB - pipeC - DBUF_S2 */
> > > static const u8 icl_dbuf_distance[][] {
> > > [PIPE_A] = { [DBUF_S1] = 1, [DBUF_S2] = 4, },
> > > [PIPE_B] = { [DBUF_S1] = 1, [DBUF_S2] = 2, },
> > > [PIPE_C] = { [DBUF_S1] = 2, [DBUF_S2] = 1, },
> > > };
> > >
> > > /* pipeD - DBUF_S2 - pipeC - pipeA - DBUF_S1 - pipeB */
> > > static const u8 tgl_dbuf_distance[][] {
> > > [PIPE_A] = { [DBUF_S1] = 1, [DBUF_S2] = 2, },
> > > [PIPE_B] = { [DBUF_S1] = 1, [DBUF_S2] = 4, },
> > > [PIPE_C] = { [DBUF_S1] = 2, [DBUF_S2] = 1, },
> > > [PIPE_D] = { [DBUF_S1] = 4, [DBUF_S2] = 1, },
> > > };
> >
> > I think you are missing my point. I will explain why.
> > My initial idea was similar, use some kind of distance
> > metrics and encode everything in a smart way.
> > Current BSpec table has sometimes slices swapped for no reason.
> >
> > There are seem to be some hardware constraints we are not aware
> > of. For example
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Allow i915 to manage the vma offset nodes instead of drm core
== Series Details ==
Series: series starting with [1/4] drm/i915: Allow i915 to manage the vma
offset nodes instead of drm core
URL : https://patchwork.freedesktop.org/series/69674/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15327
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_15327 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15327, 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_15327/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_15327:
### IGT changes ###
Possible regressions
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-gdg-551: [PASS][1] -> [FAIL][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-gdg-551/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-gdg-551/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-ilk-650: [PASS][3] -> [FAIL][4] +6 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-ilk-650/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-ilk-650/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-bwr-2160:[PASS][5] -> [FAIL][6] +5 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-bwr-2160/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-bwr-2160/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-blb-e6850: [PASS][7] -> [FAIL][8] +6 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-blb-e6850/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-blb-e6850/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bsw-kefka: [PASS][9] -> [FAIL][10] +3 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-bsw-kefka/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-bsw-kefka/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Known issues
Here are the changes found in Patchwork_15327 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][11] -> [DMESG-WARN][12] ([fdo#112261])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-n2820: [PASS][13] -> [FAIL][14] ([fdo#103191]) +4 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-byt-n2820/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-byt-n2820/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-byt-j1900: [PASS][15] -> [FAIL][16] ([fdo#103191]) +5 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-byt-j1900/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-byt-j1900/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-glk-dsi: [PASS][17] -> [FAIL][18] ([fdo#103191]) +3 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_cpu_reloc@basic:
- fi-icl-dsi: [DMESG-WARN][19] ([fdo#106107]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-dsi/igt@gem_cpu_re...@basic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15327/fi-icl-dsi/igt@gem_cpu_re...@basic.html
* igt@i915_pm_rpm@module-reload:
- {fi-kbl-7560u}: [FAIL][21] ([fdo#112269]) -> [PASS][22]
Re: [Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=
Dear Tomáš, On 2019-11-04 18:31, Tomas Janousek wrote: > On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote: >> On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 >> resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews >> the errors below. >> >> ``` >> [0.00] Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) >> (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 >> (2019-10-19) >> […] >> [1.596619] pci :00:1f.3: Adding to iommu group 12 >> [ 14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002) >> [ 14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops >> i915_audio_component_bind_ops [i915]) >> [ 14.760751] input: HDA Intel PCH Headphone Mic as >> /devices/pci:00/:00:1f.3/sound/card0/input16 >> [ 14.760790] input: HDA Intel PCH HDMI as >> /devices/pci:00/:00:1f.3/sound/card0/input17 >> [ 156.614284] snd_hda_intel :00:1f.3: No response from codec, disabling >> MSI: last cmd=0x20270503 >> [ 157.622232] snd_hda_intel :00:1f.3: No response from codec, resetting >> bus: last cmd=0x20270503 >> [ 158.626371] snd_hda_intel :00:1f.3: No response from codec, resetting >> bus: last cmd=0x20370503 >> [ 159.634102] snd_hda_intel :00:1f.3: No response from codec, resetting >> bus: last cmd=0x201f0500 >> [ 161.678121] snd_hda_intel :00:1f.3: No response from codec, resetting >> bus: last cmd=0x20270503 >> [ 162.682272] snd_hda_intel :00:1f.3: No response from codec, resetting >> bus: last cmd=0x20370503 >> [ 163.694234] snd_hda_intel :00:1f.3: No response from codec, resetting >> bus: last cmd=0x201f0500 >> [ 165.730142] snd_hda_intel :00:1f.3: No response from codec, resetting >> bus: last cmd=0x20270503 >> […] >> ``` > > Debian's 5.3.0-1-amd64 has a corrupted signature on the snd-hda-codec-hdmi > module which prevents the module from loading and causes these errors. Further > details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881 > > Workaround: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881#20 Thank you so much for pointing me to that bug report. The problem is now fixed in linux-image 5.3.9-1. Takashi, could a sanity check be added to `snd_hda_intel` to see if the codec module is loaded? Kind regards, Paul smime.p7s Description: S/MIME Cryptographic Signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for mipi dsi cmd mode (rev2)
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15328
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/index.html
Known issues
Here are the changes found in Patchwork_15328 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-u3/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-icl-u3/igt@debugfs_test@read_all_entries.html
- fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-u2/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-icl-u2/igt@debugfs_test@read_all_entries.html
- fi-icl-y: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-y/igt@debugfs_test@read_all_entries.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-icl-y/igt@debugfs_test@read_all_entries.html
- fi-icl-dsi: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-dsi/igt@debugfs_test@read_all_entries.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-icl-dsi/igt@debugfs_test@read_all_entries.html
- fi-icl-guc: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-icl-guc/igt@debugfs_test@read_all_entries.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-icl-guc/igt@debugfs_test@read_all_entries.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][11] -> [FAIL][12] ([fdo#108511])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_gem_contexts:
- fi-bsw-kefka: [PASS][13] -> [INCOMPLETE][14] ([fdo# 111542])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-bsw-kefka/igt@i915_selftest@live_gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-bsw-kefka/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {fi-kbl-7560u}: [FAIL][15] ([fdo#112269]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_blt:
- fi-hsw-peppy: [DMESG-FAIL][17] ([fdo#112147]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-hsw-peppy/igt@i915_selftest@live_blt.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-hsw-peppy/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-lmem:[DMESG-FAIL][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][21] ([fdo#111407]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [SKIP][23] ([fdo#109271]) -> [PASS][24] +27 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][25] ([fdo#102614]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15328/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo# 111542]: https
Re: [Intel-gfx] [PATCH V13 4/6] mdev: introduce mediated virtio bus
On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
+struct bus_type mdev_virtio_bus_type;
+
+struct mdev_virtio_device {
+ struct mdev_device mdev;
+ const struct mdev_virtio_ops *ops;
+ u16 class_id;
+};
This seems to share nothing with mdev (ie mdev-vfio), why is it on the
same bus?
I must be missing something - which bus do they share?
mdev_bus_type ?
Jason
Note: virtio has its own bus: mdev_virtio_bus_type. So they are not the same
bus.
That is even worse, why involve struct mdev_device at all then?
Jason
I don't quite get the question here.
My understanding for mdev is that it was a mediator between the driver
and physical device when it's hard to let them talk directly due to the
complexity of refactoring and maintenance. This is exact the case of
hardware that can offload virtio datapath but not control path. We want
to present a unified interface (standard virtio) instead of a vendor
specific interface, so a mediator level in the middle is a must. For
virtio driver, mediator present a full virtio compatible device. For
hardware, mediator will mediate the difference between the behavior
defined by virtio spec and real hardware.
And the reason why not inventing something new instead of existed mdev
is because mdev fits into the requirement of virtio-mdev very well:
1) mature framework which has been used by vGPU and other type for years
2) life cycle interface, have a unified interface for management instead
of a vendor specific one so less pain for management
3) device type management. In the case of virtio, user can choose to
create a vhost type of device or virtio type of device, or technically
it can choose which version or features of virtio device it want to create.
4) IOMMU support, mdev allows DMA isolation done at either parent level
or platform/bus level
5) vendor specific attributes
So in Parav's thread [1], if I understand correctly. The major concern
is the API multiplexer at a single mdev bus level. So comes to this
series which decouple VFIO and make mdev more generic to be suitable for
implementing a set of independent buses with similar functions.
Thanks
[1] https://www.spinics.net/lists/linux-rdma/msg85856.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
On 2019/11/19 下午8:40, Jason Gunthorpe wrote: On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote: Also, see the other conversations we are having about a "virtual" bus and devices. I do not want to have two different ways of doing the same thing in the kernel at the same time please. Please work together with the Intel developers to solve this in a unified way, as you both need/want the same thing here. Sure, some functions looks similar, but the "virtual" bus does not contain a management interface and it's not clear that how it can be used by userspace driver. For this series, sysfs/GUID based management interface is reused and we had a concrete example of how it would be used by userspace driver[1] and a real hardware driver implementation[2]. The lifecycle stuff should be re-used through a library of this guid stuff, not by 'subclassing' mdev_device Jason But mdev provides more than lifecycle management: type management, IOMMU support etc. And more could be added in the future. Having a library that serves exactly for the case of mdev seems less convenient than making mdev_device a 'parent class'. Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V13 4/6] mdev: introduce mediated virtio bus
On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
>
> On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
> > On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
> > > On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
> > > > On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
> > > > > On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
> > > > > > On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
> > > > > > > +struct bus_type mdev_virtio_bus_type;
> > > > > > > +
> > > > > > > +struct mdev_virtio_device {
> > > > > > > + struct mdev_device mdev;
> > > > > > > + const struct mdev_virtio_ops *ops;
> > > > > > > + u16 class_id;
> > > > > > > +};
> > > > > > This seems to share nothing with mdev (ie mdev-vfio), why is it on
> > > > > > the
> > > > > > same bus?
> > > > > I must be missing something - which bus do they share?
> > > > mdev_bus_type ?
> > > >
> > > > Jason
> > >
> > > Note: virtio has its own bus: mdev_virtio_bus_type. So they are not the
> > > same
> > > bus.
> > That is even worse, why involve struct mdev_device at all then?
> >
> > Jason
>
>
> I don't quite get the question here.
In the driver model the bus_type and foo_device are closely
linked. Creating 'mdev_device' instances and overriding the bus_type
is a very abusive thing to do.
> My understanding for mdev is that it was a mediator between the driver and
> physical device when it's hard to let them talk directly due to the
> complexity of refactoring and maintenance.
Really, mdev is to support vfio with a backend other than PCI, nothing
more.
Abusing it for other things is not appropriate. ie creating an
instance and not filling in most of the vfio focused ops is an abusive
thing to do.
> hardware that can offload virtio datapath but not control path. We want to
> present a unified interface (standard virtio) instead of a vendor specific
> interface, so a mediator level in the middle is a must. For virtio driver,
> mediator present a full virtio compatible device. For hardware, mediator
> will mediate the difference between the behavior defined by virtio spec and
> real hardware.
If you need to bind to the VFIO driver then mdev is the right thing to
use, otherwise it is not.
It certainly should not be used to bind to random kernel drivers. This
problem is what this virtual bus idea Intel is working on might solve.
It seems the only thing people care about with mdev is the GUID
lifecycle stuff, but at the same time folks like Parav are saying they
don't want to use that lifecycle stuff and prefer devlink
instead.
Most likely, at least for virtio-net, everyone else will be able to
use devlink as well, making it much less clear if that GUID lifecycle
stuff is a good idea or not.
Jason
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/19] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests
On 18/11/2019 23:02, Chris Wilson wrote:
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid, as we always manipulated the timeline only while
we held an engine wakeref.
And then we started retiring requests outside of struct_mutex, only
using the timelines.active_list and the timeline->mutex. There we
started manipulating intel_timeline.active_count outside of an engine
wakeref, and so introduced a race between __engine_park() and
intel_gt_retire_requests(), a race that could result in the
engine->kernel_context not being added to the active timelines and so
losing requests, which caused us to keep the system permanently powered
up [and unloadable].
The race would be easy to close if we could take the engine wakeref for
the timeline before we retire -- except timelines are not bound to any
engine and so we would need to keep all active engines awake. The
alternative is to guard intel_timeline_enter/intel_timeline_exit for use
outside of the timeline->mutex.
Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with
timeline->mutex")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 8 ++---
drivers/gpu/drm/i915/gt/intel_timeline.c | 34 +++
.../gpu/drm/i915/gt/intel_timeline_types.h| 2 +-
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index a79e6efb31a2..7559d6373f49 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -49,8 +49,8 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
continue;
intel_timeline_get(tl);
- GEM_BUG_ON(!tl->active_count);
- tl->active_count++; /* pin the list element */
+ GEM_BUG_ON(!atomic_read(&tl->active_count));
+ atomic_inc(&tl->active_count); /* pin the list element */
spin_unlock_irqrestore(&timelines->lock, flags);
if (timeout > 0) {
@@ -71,14 +71,14 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
/* Resume iteration after dropping lock */
list_safe_reset_next(tl, tn, link);
- if (!--tl->active_count)
+ if (atomic_dec_and_test(&tl->active_count))
list_del(&tl->link);
mutex_unlock(&tl->mutex);
/* Defer the final release to after the spinlock */
if (refcount_dec_and_test(&tl->kref.refcount)) {
- GEM_BUG_ON(tl->active_count);
+ GEM_BUG_ON(atomic_read(&tl->active_count));
list_add(&tl->link, &free);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 16a9e88d93de..4f914f0d5eab 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -334,15 +334,33 @@ void intel_timeline_enter(struct intel_timeline *tl)
struct intel_gt_timelines *timelines = &tl->gt->timelines;
unsigned long flags;
+ /*
+* Pretend we are serialised by the timeline->mutex.
+*
+* While generally true, there are a few exceptions to the rule
+* for the engine->kernel_context being used to manage power
+* transitions. As the engine_park may be called from under any
+* timeline, it uses the power mutex as a global serialisation
+* lock to prevent any other request entering its timeline.
+*
+* The rule is generally tl->mutex, otherwise engine->wakeref.mutex.
+*
+* However, intel_gt_retire_request() does not know which engine
+* it is retiring along and so cannot partake in the engine-pm
+* barrier, and there we use the tl->active_count as a means to
+* pin the timeline in the active_list while the locks are dropped.
+* Ergo, as that is outside of the engine-pm barrier, we need to
+* use atomic to manipulate tl->active_count.
+*/
lockdep_assert_held(&tl->mutex);
-
GEM_BUG_ON(!atomic_read(&tl->pin_count));
- if (tl->active_count++)
+
+ if (atomic_add_unless(&tl->active_count, 1, 0))
return;
- GEM_BUG_ON(!tl->active_count); /* overflow? */
spin_lock_irqsave(&timelines->lock, flags);
- list_add(&tl->link, &timelines->active_list);
+ if (!atomic_fetch_inc(&tl->active_count))
+ list_add(&tl->link, &timelines->active_list);
So retirement raced with this and has elevated the active_count? But
retirement does not add the timeline to the list, so we exit h
[Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
Fork and remap the same object into a new process space under a new file
descriptor. Principally to check list management and find scaling issues
in using such lists.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
tests/i915/gem_mmap_gtt.c | 72 ++-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index a5f9d934e..756940ca4 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -34,8 +34,9 @@
#include
#include
#include
-#include
#include
+#include
+#include
#include "drm.h"
#include "igt.h"
@@ -323,6 +324,73 @@ test_pf_nonblock(int i915)
igt_spin_free(i915, spin);
}
+static void
+test_fork_bomb(int i915)
+{
+ uint32_t *control;
+ uint32_t handle;
+ int dmabuf;
+
+ /* Rebind the same object into many different process adress spaces. */
+
+ control = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(control != MAP_FAILED);
+
+ handle = gem_create(i915, 4096);
+ dmabuf = prime_handle_to_fd(i915, handle);
+ gem_close(i915, handle);
+
+ igt_fork(child, 1) {
+ int fd[512];
+
+ atomic_fetch_add(&control[1], 1);
+ while (!READ_ONCE(control[0])) {
+ int children;
+
+ atomic_fetch_add(&control[2], 1);
+
+ for (int i = 0; i < ARRAY_SIZE(fd); i++) {
+ fd[i] = gem_reopen_driver(i915);
+
+ handle = prime_fd_to_handle(fd[i], dmabuf);
+ gem_mmap__gtt(fd[i], handle, 4096, PROT_WRITE);
+ gem_close(fd[i], handle);
+
+ /* leave the fd + mmap for process cleanup */
+ }
+
+ for (children = 0; children < 2; children++) {
+ if (fork() > 0) { /* child */
+ atomic_fetch_add(&control[1], 1);
+ for (int i = 0; i < ARRAY_SIZE(fd); i++)
+ close(fd[i]);
+ break;
+ }
+ }
+ if (children == 2) { /* parent */
+ sched_yield();
+ break;
+ }
+ }
+ atomic_fetch_add(&control[1], -1);
+ }
+
+ sleep(30);
+
+ *control = 1;
+ igt_waitchildren();
+
+ while (READ_ONCE(control[1])) {
+ int status = 0;
+ wait(&status);
+ }
+
+ igt_info("Spawned %d children\n", control[2]);
+
+ close(dmabuf);
+ munmap(control, 4096);
+}
+
static void
test_isolation(int i915)
{
@@ -1097,6 +1165,8 @@ igt_main
test_flink_race(fd);
igt_subtest("pf-nonblock")
test_pf_nonblock(fd);
+ igt_subtest("fork-bomb")
+ test_fork_bomb(fd);
igt_subtest("basic-small-bo")
test_huge_bo(fd, -1, I915_TILING_NONE);
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Cleanups around .crtc_enable/disable() (rev3)
On Mon, Nov 18, 2019 at 08:00:07PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Cleanups around .crtc_enable/disable() (rev3) > URL : https://patchwork.freedesktop.org/series/69352/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_7365 -> Patchwork_15318 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_15318 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_15318, 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_15318/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_15318: > > ### IGT changes ### > > Possible regressions > > * igt@runner@aborted: > - fi-apl-guc: NOTRUN -> [FAIL][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15318/fi-apl-guc/igt@run...@aborted.html <3>[ 172.016356] BUG jbd2_journal_head (Tainted: G U ): Redzone overwritten <3>[ 172.016440] - <3>[ 172.016544] INFO: 0xb51300f6-0xb51300f6. First byte 0xbf instead of 0xbb <3>[ 172.016640] INFO: Allocated in jbd2_journal_add_journal_head+0x93/0x1b0 age=1235 cpu=2 pid=2191 ... <3>[ 172.017564] INFO: Freed in jbd2_journal_put_journal_head+0xef/0x1b9 age=1148 cpu=0 pid=232 Doesn't really match the pattern in https://bugs.freedesktop.org/show_bug.cgi?id=111863 except by having bit 2 flipped as well. -- 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 04/19] drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
On 18/11/2019 23:02, Chris Wilson wrote:
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap with other users of the engine->kernel_context waking
up and submitting their request before the idle-switch is queued, with
the result that the kernel_context is executed out-of-sequence most
likely upsetting the GPU and certainly ourselves when we try to retire
the out-of-sequence requests.
As such we need to hold onto the effective engine->kernel_context mutex
lock (via the engine pm mutex proxy) until we have finish queuing the
request to the engine.
v2: Serialise against concurrent intel_gt_retire_requests()
Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 3c0f490ff2c7..722d3eec226e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -75,6 +75,7 @@ static inline void __timeline_mark_unlock(struct
intel_context *ce,
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
{
+ struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
unsigned long flags;
bool result = true;
@@ -99,15 +100,13 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
* retiring the last request, thus all rings should be empty and
* all timelines idle.
*/
- flags = __timeline_mark_lock(engine->kernel_context);
+ flags = __timeline_mark_lock(ce);
- rq = __i915_request_create(engine->kernel_context, GFP_NOWAIT);
+ rq = __i915_request_create(ce, GFP_NOWAIT);
if (IS_ERR(rq))
/* Context switch failed, hope for the best! Maybe reset? */
goto out_unlock;
- intel_timeline_enter(i915_request_timeline(rq));
-
/* Check again on the next retirement. */
engine->wakeref_serial = engine->serial + 1;
i915_request_add_active_barriers(rq);
@@ -116,13 +115,17 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
rq->sched.attr.priority = I915_PRIORITY_BARRIER;
__i915_request_commit(rq);
+ __i915_request_queue(rq, NULL);
+
/* Release our exclusive hold on the engine */
__intel_wakeref_defer_park(&engine->wakeref);
- __i915_request_queue(rq, NULL);
+
+ /* And finally expose our selfselves to intel_gt_retire_requests()
ourselves
*/
+ intel_timeline_enter(ce->timeline);
I haven't really managed to follow this.
What are these other clients which can queue requests and what in this
block prevents them doing so?
The change seems to be moving the queuing to before
__intel_wakeref_defer_park and intel_timeline_enter to last. Wakeref
defer extends the engine lifetime until the submitted rq is retired. But
how is that consider "unlocking"?
Regards,
Tvrtko
result = false;
out_unlock:
- __timeline_mark_unlock(engine->kernel_context, flags);
+ __timeline_mark_unlock(ce, flags);
return result;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/19] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests
Quoting Tvrtko Ursulin (2019-11-19 14:15:49)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > The general concept was that intel_timeline.active_count was locked by
> > the intel_timeline.mutex. The exception was for power management, where
> > the engine->kernel_context->timeline could be manipulated under the
> > global wakeref.mutex.
> >
> > This was quite solid, as we always manipulated the timeline only while
> > we held an engine wakeref.
> >
> > And then we started retiring requests outside of struct_mutex, only
> > using the timelines.active_list and the timeline->mutex. There we
> > started manipulating intel_timeline.active_count outside of an engine
> > wakeref, and so introduced a race between __engine_park() and
> > intel_gt_retire_requests(), a race that could result in the
> > engine->kernel_context not being added to the active timelines and so
> > losing requests, which caused us to keep the system permanently powered
> > up [and unloadable].
> >
> > The race would be easy to close if we could take the engine wakeref for
> > the timeline before we retire -- except timelines are not bound to any
> > engine and so we would need to keep all active engines awake. The
> > alternative is to guard intel_timeline_enter/intel_timeline_exit for use
> > outside of the timeline->mutex.
> >
> > Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with
> > timeline->mutex")
> > Signed-off-by: Chris Wilson
> > Cc: Matthew Auld
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_requests.c | 8 ++---
> > drivers/gpu/drm/i915/gt/intel_timeline.c | 34 +++
> > .../gpu/drm/i915/gt/intel_timeline_types.h| 2 +-
> > 3 files changed, 32 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > index a79e6efb31a2..7559d6373f49 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > @@ -49,8 +49,8 @@ long intel_gt_retire_requests_timeout(struct intel_gt
> > *gt, long timeout)
> > continue;
> >
> > intel_timeline_get(tl);
> > - GEM_BUG_ON(!tl->active_count);
> > - tl->active_count++; /* pin the list element */
> > + GEM_BUG_ON(!atomic_read(&tl->active_count));
> > + atomic_inc(&tl->active_count); /* pin the list element */
> > spin_unlock_irqrestore(&timelines->lock, flags);
> >
> > if (timeout > 0) {
> > @@ -71,14 +71,14 @@ long intel_gt_retire_requests_timeout(struct intel_gt
> > *gt, long timeout)
> >
> > /* Resume iteration after dropping lock */
> > list_safe_reset_next(tl, tn, link);
> > - if (!--tl->active_count)
> > + if (atomic_dec_and_test(&tl->active_count))
> > list_del(&tl->link);
> >
> > mutex_unlock(&tl->mutex);
> >
> > /* Defer the final release to after the spinlock */
> > if (refcount_dec_and_test(&tl->kref.refcount)) {
> > - GEM_BUG_ON(tl->active_count);
> > + GEM_BUG_ON(atomic_read(&tl->active_count));
> > list_add(&tl->link, &free);
> > }
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
> > b/drivers/gpu/drm/i915/gt/intel_timeline.c
> > index 16a9e88d93de..4f914f0d5eab 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
> > @@ -334,15 +334,33 @@ void intel_timeline_enter(struct intel_timeline *tl)
> > struct intel_gt_timelines *timelines = &tl->gt->timelines;
> > unsigned long flags;
> >
> > + /*
> > + * Pretend we are serialised by the timeline->mutex.
> > + *
> > + * While generally true, there are a few exceptions to the rule
> > + * for the engine->kernel_context being used to manage power
> > + * transitions. As the engine_park may be called from under any
> > + * timeline, it uses the power mutex as a global serialisation
> > + * lock to prevent any other request entering its timeline.
> > + *
> > + * The rule is generally tl->mutex, otherwise engine->wakeref.mutex.
> > + *
> > + * However, intel_gt_retire_request() does not know which engine
> > + * it is retiring along and so cannot partake in the engine-pm
> > + * barrier, and there we use the tl->active_count as a means to
> > + * pin the timeline in the active_list while the locks are dropped.
> > + * Ergo, as that is outside of the engine-pm barrier, we need to
> > + * use atomic to manipulate tl->active_count.
> > + */
> > lockdep_assert_held(&tl->mutex);
> > -
> > GEM_BUG_ON(!atomic_read(&tl->pin_count));
> > - if (tl->active_count++)
> > +
> > + if (atomic_add_unless(&tl->active_count, 1, 0))
> >
[Intel-gfx] ✗ GitLab.Pipeline: warning for i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
== Series Details ==
Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
URL : https://patchwork.freedesktop.org/series/69678/
State : warning
== Summary ==
Did not get list of undocumented tests for this run, something is wrong!
Other than that, pipeline status: FAILED.
see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/80517 for the
overview.
build:tests-fedora-clang has failed
(https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/975524):
atomic_fetch_add(&control[1], 1);
^~~~
/usr/lib64/clang/9.0.0/include/stdatomic.h:132:43: note: expanded from macro
'atomic_fetch_add'
#define atomic_fetch_add(object, operand) __c11_atomic_fetch_add(object,
operand, __ATOMIC_SEQ_CST)
^ ~~
../tests/i915/gem_mmap_gtt.c:375:3: error: address argument to atomic
operation must be a pointer to _Atomic type ('uint32_t *' (aka 'unsigned int
*') invalid)
atomic_fetch_add(&control[1], -1);
^~~~
/usr/lib64/clang/9.0.0/include/stdatomic.h:132:43: note: expanded from macro
'atomic_fetch_add'
#define atomic_fetch_add(object, operand) __c11_atomic_fetch_add(object,
operand, __ATOMIC_SEQ_CST)
^ ~~
4 errors generated.
ninja: build stopped: subcommand failed.
section_end:1574174572:build_script
[0Ksection_start:1574174572:after_script
[0Ksection_end:1574174574:after_script
[0Ksection_start:1574174574:upload_artifacts_on_failure
[0Ksection_end:1574174575:upload_artifacts_on_failure
[0K[31;1mERROR: Job failed: exit code 1
[0;m
== Logs ==
For more details see:
https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/80517
___
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 [01/17] drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
== Series Details == Series: series starting with [01/17] drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON URL : https://patchwork.freedesktop.org/series/69669/ State : success == Summary == CI Bug Log - changes from CI_DRM_7370_full -> Patchwork_15325_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_7370_full and Patchwork_15325_full: ### New IGT tests (1) ### * igt@i915_selftest@live_late_gt_pm: - Statuses : 8 pass(s) - Exec time: [0.34, 2.35] s Known issues Here are the changes found in Patchwork_15325_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-s3: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([fdo#111832]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-tglb2/igt@gem_ctx_isolat...@vcs1-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-tglb3/igt@gem_ctx_isolat...@vcs1-s3.html * igt@gem_ctx_persistence@vcs1-mixed-process: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-iclb4/igt@gem_ctx_persiste...@vcs1-mixed-process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-iclb5/igt@gem_ctx_persiste...@vcs1-mixed-process.html * igt@gem_ctx_shared@q-smoketest-blt: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#111735]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-tglb9/igt@gem_ctx_sha...@q-smoketest-blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-tglb6/igt@gem_ctx_sha...@q-smoketest-blt.html * igt@gem_eio@suspend: - shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111850]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-tglb3/igt@gem_...@suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-tglb3/igt@gem_...@suspend.html * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][9] -> [FAIL][10] ([fdo#109661]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-snb6/igt@gem_...@unwedge-stress.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive: - shard-snb: [PASS][13] -> [TIMEOUT][14] ([fdo#112068 ]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-snb4/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-snb7/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-hsw: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-hsw8/igt@gem_userptr_bl...@dmabuf-unsync.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-hsw1/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup: - shard-snb: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-snb7/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html * igt@kms_color@pipe-b-ctm-red-to-blue: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([fdo#106107]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-skl2/igt@kms_co...@pipe-b-ctm-red-to-blue.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-skl2/igt@kms_co...@pipe-b-ctm-red-to-blue.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15325/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@2x-flip-vs-suspend-interruptible: - shard-hsw: [PASS][23] -> [INCOMPLETE][24] ([fdo#103540]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7370/shard-hsw8/igt@kms_f...@2x-flip-vs-suspend-
Re: [Intel-gfx] [PATCH 04/19] drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
Quoting Tvrtko Ursulin (2019-11-19 14:35:04)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
> > the backend"), I erroneously concluded that we last modify the engine
> > inside __i915_request_commit() meaning that we could enable concurrent
> > submission for userspace as we enqueued this request. However, this
> > falls into a trap with other users of the engine->kernel_context waking
> > up and submitting their request before the idle-switch is queued, with
> > the result that the kernel_context is executed out-of-sequence most
> > likely upsetting the GPU and certainly ourselves when we try to retire
> > the out-of-sequence requests.
> >
> > As such we need to hold onto the effective engine->kernel_context mutex
> > lock (via the engine pm mutex proxy) until we have finish queuing the
> > request to the engine.
> >
> > v2: Serialise against concurrent intel_gt_retire_requests()
> >
> > Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
> > backend")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index 3c0f490ff2c7..722d3eec226e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -75,6 +75,7 @@ static inline void __timeline_mark_unlock(struct
> > intel_context *ce,
> >
> > static bool switch_to_kernel_context(struct intel_engine_cs *engine)
> > {
> > + struct intel_context *ce = engine->kernel_context;
> > struct i915_request *rq;
> > unsigned long flags;
> > bool result = true;
> > @@ -99,15 +100,13 @@ static bool switch_to_kernel_context(struct
> > intel_engine_cs *engine)
> >* retiring the last request, thus all rings should be empty and
> >* all timelines idle.
> >*/
> > - flags = __timeline_mark_lock(engine->kernel_context);
> > + flags = __timeline_mark_lock(ce);
> >
> > - rq = __i915_request_create(engine->kernel_context, GFP_NOWAIT);
> > + rq = __i915_request_create(ce, GFP_NOWAIT);
> > if (IS_ERR(rq))
> > /* Context switch failed, hope for the best! Maybe reset? */
> > goto out_unlock;
> >
> > - intel_timeline_enter(i915_request_timeline(rq));
> > -
> > /* Check again on the next retirement. */
> > engine->wakeref_serial = engine->serial + 1;
> > i915_request_add_active_barriers(rq);
> > @@ -116,13 +115,17 @@ static bool switch_to_kernel_context(struct
> > intel_engine_cs *engine)
> > rq->sched.attr.priority = I915_PRIORITY_BARRIER;
> > __i915_request_commit(rq);
> >
> > + __i915_request_queue(rq, NULL);
> > +
> > /* Release our exclusive hold on the engine */
> > __intel_wakeref_defer_park(&engine->wakeref);
> > - __i915_request_queue(rq, NULL);
> > +
> > + /* And finally expose our selfselves to intel_gt_retire_requests()
>
> ourselves
>
> */
> > + intel_timeline_enter(ce->timeline);
>
> I haven't really managed to follow this.
>
> What are these other clients which can queue requests and what in this
> block prevents them doing so?
There are 2 other parties and the GPU who have a stake in this.
A new gpu user will be waiting on the engine-pm to start their
engine_unpark. New waiters are predicated on engine->wakeref.count and
so intel_wakeref_defer_park() acts like a mutex_unlock of the
engine->wakeref.
The other party is intel_gt_retire_requests(), which is walking the list
of active timelines looking for completions. Meanwhile as soon as we
call __i915_request_queue(), the GPU may complete our request. Ergo,
if we put ourselves on the timelines.active_list (intel_timeline_enter)
before we raise the wakeref.count, we may see the request completion and
retire it causing an undeflow of the engine->wakeref.
> The change seems to be moving the queuing to before
> __intel_wakeref_defer_park and intel_timeline_enter to last. Wakeref
> defer extends the engine lifetime until the submitted rq is retired. But
> how is that consider "unlocking"?
static inline int
intel_wakeref_get(struct intel_wakeref *wf)
{
if (unlikely(!atomic_inc_not_zero(&wf->count)))
return __intel_wakeref_get_first(wf);
return 0;
}
As we build the switch_to_kernel_context(), wf->count is 0, and so all
new users will enter the slow path and take the mutex_lock(&wf->mutex).
As soon as we call intel_wakeref_defer_park(), we call
atomic_set_release(&wf->count, 1) and so all new users will take the
fast path and skip the mutex_lock. Hence why I connote it with being a
"mutex_unlock"
-Chris
___
Intel-gfx mailing list
Intel-gfx@list
Re: [Intel-gfx] [PATCH 05/19] drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint
On 18/11/2019 23:02, Chris Wilson wrote:
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() needed to be atomic and
ordered in a nice onion with intel_ring_pin() so that the lifetimes
overlapped and were always safe.
Sadly, a few steps in intel_ring_unpin() were overlooked, such as
closing the read/write pointers of the ring and discarding the
intel_ring.vaddr, as these steps were not serialised with
intel_ring_pin() and so could leave the ring in disarray.
Fixes: 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_ring.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index ece20504d240..374b28f13ca0 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -57,9 +57,10 @@ int intel_ring_pin(struct intel_ring *ring)
i915_vma_make_unshrinkable(vma);
- GEM_BUG_ON(ring->vaddr);
- ring->vaddr = addr;
+ /* Discard any unused bytes beyond that submitted to hw. */
+ intel_ring_reset(ring, ring->emit);
+ ring->vaddr = addr;
return 0;
err_ring:
@@ -85,20 +86,14 @@ void intel_ring_unpin(struct intel_ring *ring)
if (!atomic_dec_and_test(&ring->pin_count))
return;
- /* Discard any unused bytes beyond that submitted to hw. */
- intel_ring_reset(ring, ring->emit);
-
i915_vma_unset_ggtt_write(vma);
if (i915_vma_is_map_and_fenceable(vma))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);
- GEM_BUG_ON(!ring->vaddr);
- ring->vaddr = NULL;
-
- i915_vma_unpin(vma);
i915_vma_make_purgeable(vma);
+ i915_vma_unpin(vma);
}
static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Track ggtt writes from userspace on the bound vma
Chris Wilson writes:
> When userspace writes into the GTT itself, it is supposed to call
> set-domain to let the kernel keep track and so manage the CPU/GPU
> caches. As we track writes on the individual i915_vma, we should also be
> sure to mark them as dirty.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index e2af63af67ad..9aebcf263191 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -149,9 +149,17 @@ i915_gem_object_set_to_gtt_domain(struct
> drm_i915_gem_object *obj, bool write)
> GEM_BUG_ON((obj->write_domain & ~I915_GEM_DOMAIN_GTT) != 0);
> obj->read_domains |= I915_GEM_DOMAIN_GTT;
> if (write) {
> + struct i915_vma *vma;
> +
> obj->read_domains = I915_GEM_DOMAIN_GTT;
> obj->write_domain = I915_GEM_DOMAIN_GTT;
> obj->mm.dirty = true;
> +
> + spin_lock(&obj->vma.lock);
> + for_each_ggtt_vma(vma, obj)
> + if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
> + i915_vma_set_ggtt_write(vma);
> + spin_unlock(&obj->vma.lock);
> }
>
> i915_gem_object_unpin_pages(obj);
> --
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
== Series Details == Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects URL : https://patchwork.freedesktop.org/series/69678/ State : success == Summary == CI Bug Log - changes from CI_DRM_7371 -> IGTPW_3727 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/index.html Known issues Here are the changes found in IGTPW_3727 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [PASS][1] -> [DMESG-WARN][2] ([fdo#112261]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/fi-skl-6770hq/igt@i915_pm_...@module-reload.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-skl-lmem:[DMESG-WARN][3] ([fdo#112261]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-skl-lmem/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/fi-skl-lmem/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_blt: - fi-hsw-peppy: [DMESG-FAIL][5] ([fdo#112147]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-hsw-peppy/igt@i915_selftest@live_blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/fi-hsw-peppy/igt@i915_selftest@live_blt.html * igt@kms_busy@basic-flip-pipe-a: - fi-icl-u2: [TIMEOUT][7] ([fdo#111800]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][9] ([fdo#111407]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111800]: https://bugs.freedesktop.org/show_bug.cgi?id=111800 [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147 [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261 Participating hosts (50 -> 44) -- Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * IGT: IGT_5295 -> IGTPW_3727 CI-20190529: 20190529 CI_DRM_7371: 4a9a6d1fade97c450a0eabbc3436f1dc5518b15e @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_3727: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/index.html IGT_5295: 9211e4794e40135d797e6d056d6d8d40076acb92 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Testlist changes == +igt@gem_mmap_gtt@fork-bomb == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3727/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make pool objects read-only
For our current users we don't expect pool objects to be writable from the gpu. Signed-off-by: Matthew Auld Cc: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_pool.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c b/drivers/gpu/drm/i915/gt/intel_engine_pool.c index 3cdbd5f8b5be..397186818305 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_pool.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.c @@ -104,6 +104,8 @@ node_create(struct intel_engine_pool *pool, size_t sz) return ERR_CAST(obj); } + i915_gem_object_set_readonly(obj); + node->obj = obj; return node; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap with other users of the engine->kernel_context waking
up and submitting their request before the idle-switch is queued, with
the result that the kernel_context is executed out-of-sequence most
likely upsetting the GPU and certainly ourselves when we try to retire
the out-of-sequence requests.
As such we need to hold onto the effective engine->kernel_context mutex
lock (via the engine pm mutex proxy) until we have finish queuing the
request to the engine.
v2: Serialise against concurrent intel_gt_retire_requests()
v3: Describe the hairy locking scheme with intel_gt_retire_requests()
for future reference.
Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 31 ++-
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 3c0f490ff2c7..a7240e2dd873 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -75,6 +75,7 @@ static inline void __timeline_mark_unlock(struct
intel_context *ce,
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
{
+ struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
unsigned long flags;
bool result = true;
@@ -98,16 +99,30 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
* This should hold true as we can only park the engine after
* retiring the last request, thus all rings should be empty and
* all timelines idle.
+*
+* For unlocking, there are 2 other parties and the GPU who have a
+* stake here.
+*
+* A new gpu user will be waiting on the engine-pm to start their
+* engine_unpark. New waiters are predicated on engine->wakeref.count
+* and so intel_wakeref_defer_park() acts like a mutex_unlock of the
+* engine->wakeref.
+*
+* The other party is intel_gt_retire_requests(), which is walking the
+* list of active timelines looking for completions. Meanwhile as soon
+* as we call __i915_request_queue(), the GPU may complete our request.
+* Ergo, if we put ourselves on the timelines.active_list
+* (se intel_timeline_enter()) before we increment the
+* engine->wakeref.count, we may see the request completion and retire
+* it causing an undeflow of the engine->wakeref.
*/
- flags = __timeline_mark_lock(engine->kernel_context);
+ flags = __timeline_mark_lock(ce);
- rq = __i915_request_create(engine->kernel_context, GFP_NOWAIT);
+ rq = __i915_request_create(ce, GFP_NOWAIT);
if (IS_ERR(rq))
/* Context switch failed, hope for the best! Maybe reset? */
goto out_unlock;
- intel_timeline_enter(i915_request_timeline(rq));
-
/* Check again on the next retirement. */
engine->wakeref_serial = engine->serial + 1;
i915_request_add_active_barriers(rq);
@@ -116,13 +131,17 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
rq->sched.attr.priority = I915_PRIORITY_BARRIER;
__i915_request_commit(rq);
+ __i915_request_queue(rq, NULL);
+
/* Release our exclusive hold on the engine */
__intel_wakeref_defer_park(&engine->wakeref);
- __i915_request_queue(rq, NULL);
+
+ /* And finally expose ourselves to intel_gt_retire_requests() */
+ intel_timeline_enter(ce->timeline);
result = false;
out_unlock:
- __timeline_mark_unlock(engine->kernel_context, flags);
+ __timeline_mark_unlock(ce, flags);
return result;
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/19] drm/i915/gt: Schedule request retirement when submission idles
On 18/11/2019 23:02, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If userspace is idle, this task falls onto our background idle
worker, which only runs roughly once a second, meaning that userspace has
to have been idle for a couple of seconds before we enable RC6 again.
Naturally, this causes us to consume considerably more energy than
before as powersaving is effectively disabled while a display server
(here's looking at you Xorg) is running.
As execlists will get a completion event as the last context is
completed and the GPU goes idle, we can use our submission tasklet to
notice when the GPU is idle and kick the retire worker. Thus during
light workloads, we will do much more work to idle the GPU faster...
Hopefully with commensurate power saving!
References: https://bugs.freedesktop.org/show_bug.cgi?id=112315
References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_requests.h | 9 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 13 +
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
index fde546424c63..94b8758a45d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
@@ -7,7 +7,9 @@
#ifndef INTEL_GT_REQUESTS_H
#define INTEL_GT_REQUESTS_H
-struct intel_gt;
+#include
+
+#include "intel_gt_types.h"
long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout);
static inline void intel_gt_retire_requests(struct intel_gt *gt)
@@ -15,6 +17,11 @@ static inline void intel_gt_retire_requests(struct intel_gt
*gt)
intel_gt_retire_requests_timeout(gt, 0);
}
+static inline void intel_gt_schedule_retire_requests(struct intel_gt *gt)
+{
+ mod_delayed_work(system_wq, >->requests.retire_work, 0);
+}
+
int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
void intel_gt_init_requests(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 33ce258d484f..f7c8fec436a9 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -142,6 +142,7 @@
#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_reset.h"
@@ -2278,6 +2279,18 @@ static void execlists_submission_tasklet(unsigned long
data)
if (timeout && preempt_timeout(engine))
preempt_reset(engine);
}
+
+ /*
+* If the GPU is currently idle, retire the outstanding completed
+* requests. This will allow us to enter soft-rc6 as soon as possible,
+* albeit at the cost of running the retire worker much more frequently
+* (over the entire GT not just this engine) and emitting more idle
+* barriers (i.e. kernel context switches unpinning all that went
+* before) which may add some extra latency.
+*/
+ if (intel_engine_pm_is_awake(engine) &&
+ !execlists_active(&engine->execlists))
+ intel_gt_schedule_retire_requests(engine->gt);
I am still not a fan of doing this for all platforms.
Its not just the cost of retirement but there is
intel_engine_flush_submission on all engines in there as well which we
cannot avoid triggering from this path.
Would it be worth experimenting with additional per-engine retire
workers? Most of the code could be shared, just a little bit of
specialization to filter on engine.
Regards,
Tvrtko
}
static void __execlists_kick(struct intel_engine_execlists *execlists)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make pool objects read-only
Quoting Matthew Auld (2019-11-19 15:01:54)
> For our current users we don't expect pool objects to be writable from
> the gpu.
>
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow
buffers")
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlight
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.
On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.
So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012
Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.
Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller
to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for
the right controller depending on the VBT bit, instead of the i915 driver
relying on a "pwm_backlight" lookup getting registered which magically
points to the right controller.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_lpss.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 751ed38f2a10..63e81d8e675b 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -69,10 +69,6 @@ ACPI_MODULE_NAME("acpi_lpss");
#define LPSS_SAVE_CTX BIT(4)
#define LPSS_NO_D3_DELAY BIT(5)
-/* Crystal Cove PMIC shares same ACPI ID between different platforms */
-#define BYT_CRC_HRV2
-#define CHT_CRC_HRV3
-
struct lpss_private_data;
struct lpss_device_desc {
@@ -158,7 +154,7 @@ static void lpss_deassert_reset(struct lpss_private_data
*pdata)
*/
static struct pwm_lookup byt_pwm_lookup[] = {
PWM_LOOKUP_WITH_MODULE("80860F09:00", 0, ":00:02.0",
- "pwm_backlight", 0, PWM_POLARITY_NORMAL,
+ "pwm_soc_backlight", 0, PWM_POLARITY_NORMAL,
"pwm-lpss-platform"),
};
@@ -170,8 +166,7 @@ static void byt_pwm_setup(struct lpss_private_data *pdata)
if (!adev->pnp.unique_id || strcmp(adev->pnp.unique_id, "1"))
return;
- if (!acpi_dev_present("INT33FD", NULL, BYT_CRC_HRV))
- pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup));
+ pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup));
}
#define LPSS_I2C_ENABLE0x6c
@@ -204,7 +199,7 @@ static void byt_i2c_setup(struct lpss_private_data *pdata)
/* BSW PWM used for backlight control by the i915 driver */
static struct pwm_lookup bsw_pwm_lookup[] = {
PWM_LOOKUP_WITH_MODULE("80862288:00", 0, ":00:02.0",
- "pwm_backlight", 0, PWM_POLARITY_NORMAL,
+ "pwm_soc_backlight", 0, PWM_POLARITY_NORMAL,
"pwm-lpss-platform"),
};
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.
On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.
So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012
Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.
Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM
controller to "pwm_pmic_backlight" so that the i915 driver can do a
pwm_get() for the right controller depending on the VBT bit, instead of
the i915 driver relying on a "pwm_backlight" lookup getting registered
which magically points to the right controller.
Signed-off-by: Hans de Goede
---
drivers/mfd/intel_soc_pmic_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/intel_soc_pmic_core.c
b/drivers/mfd/intel_soc_pmic_core.c
index c9f35378d391..47188df3080d 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -38,7 +38,7 @@ static struct gpiod_lookup_table panel_gpio_table = {
/* PWM consumed by the Intel GFX */
static struct pwm_lookup crc_pwm_lookup[] = {
- PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0,
PWM_POLARITY_NORMAL),
+ PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_pmic_backlight",
0, PWM_POLARITY_NORMAL),
};
static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: DSI: select correct PWM controller to use based on the VBT
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.
On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.
So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012
Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.
This commit fixes using the wrong PWM controller on these devices by
calling pwm_get() for the right PWM controller based on the
VBT dsi.config.pwm_blc bit.
Note this is part of a series which contains 2 other patches which renames
the PWM lookup for the 1st SoC/LPSS PWM from "pwm_backlight" to
"pwm_pmic_backlight" and the PWM lookup for the Crystal Cove PMIC PWM
from "pwm_backlight" to "pwm_pmic_backlight".
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_panel.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index bc14e9c0285a..ddcf311d1114 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1840,13 +1840,22 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
enum pipe pipe)
{
struct drm_device *dev = connector->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_panel *panel = &connector->panel;
+ const char *desc;
int retval;
- /* Get the PWM chip for backlight control */
- panel->backlight.pwm = pwm_get(dev->dev, "pwm_backlight");
+ /* Get the right PWM chip for DSI backlight according to VBT */
+ if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
+ panel->backlight.pwm = pwm_get(dev->dev, "pwm_pmic_backlight");
+ desc = "PMIC";
+ } else {
+ panel->backlight.pwm = pwm_get(dev->dev, "pwm_soc_backlight");
+ desc = "SoC";
+ }
+
if (IS_ERR(panel->backlight.pwm)) {
- DRM_ERROR("Failed to own the pwm chip\n");
+ DRM_ERROR("Failed to get the %s PWM chip\n", desc);
panel->backlight.pwm = NULL;
return -ENODEV;
}
@@ -1873,6 +1882,7 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
CRC_PMIC_PWM_PERIOD_NS);
panel->backlight.enabled = panel->backlight.level != 0;
+ DRM_INFO("Using %s PWM for LCD backlight control\n", desc);
return 0;
}
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT
Hi All, This series needs to be merged through a single tree, to keep things bisectable. I have even considered just squashing all 3 patches into 1, but having separate commits seems better, but that does lead to an intermediate state where the backlight sysfs interface will be broken (and fixed 2 commits later). See below for some background info. The changes to drivers/acpi/acpi_lpss.c and drivers/mfd/intel_soc_pmic_core.c are quite small and should not lead to any conflicts, so I believe that it would be best to merge this entire series through the drm-intel tree. Lee, may I have your Acked-by for merging the mfd change through the drm-intel tree? Rafael, may I have your Acked-by for merging the acpi_lpss change through the drm-intel tree? Regards, Hans p.s. The promised background info: We have this long standing issue where instead of looking in the i915 VBT (Video BIOS Table) to see if we should use the PWM block of the SoC or of the PMIC to control the backlight of a DSI panel, we rely on drivers/acpi/acpi_lpss.c and/or drivers/mfd/intel_soc_pmic_core.c registering a pwm with the generic name of "pwm_backlight" and then the i915 panel code does a pwm_get(dev, "pwm_backlight"). We have some heuristics in drivers/acpi/acpi_lpss.c to not register the lookup if a Crystal Cove PMIC is presend and the mfd/intel_soc_pmic_core.c code simply assumes that since there is a PMIC the PMIC PWM block will be used. Basically we are winging it. Recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. This series renams the PWM lookups registered by the LPSS / intel_soc_pmic_core.c code from "pwm_backlight" to "pwm_soc_backlight" resp. "pwm_pmic_backlight" and in the LPSS case also dropping the heuristics when to register the lookup. This combined with teaching the i915 panel to call pwm_get for the right lookup-name depending on the VBT bits resolves this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Cleanups around .crtc_enable/disable() (rev4)
== Series Details == Series: drm/i915: Cleanups around .crtc_enable/disable() (rev4) URL : https://patchwork.freedesktop.org/series/69352/ State : success == Summary == CI Bug Log - changes from CI_DRM_7371 -> Patchwork_15329 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15329/index.html Known issues Here are the changes found in Patchwork_15329 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_busy@basic-flip-pipe-a: - fi-icl-u2: [TIMEOUT][1] ([fdo#111800]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15329/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][3] ([fdo#111407]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15329/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111800]: https://bugs.freedesktop.org/show_bug.cgi?id=111800 Participating hosts (50 -> 44) -- Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7371 -> Patchwork_15329 CI-20190529: 20190529 CI_DRM_7371: 4a9a6d1fade97c450a0eabbc3436f1dc5518b15e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5295: 9211e4794e40135d797e6d056d6d8d40076acb92 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_15329: db4218f02897a41488c48d54b5757b29fbc74c6e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == db4218f02897 drm/i915: Change .crtc_enable/disable() calling convention 3d8164cfaf48 drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable() fb22d42c4ead drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable() 18eae5a36d19 drm/i915: Pass dev_priv to cpt_verify_modeset() e654f5ae7ba6 drm/i915: Change watermark hook calling convention f12e66beeb39 drm/i915: Pass intel_crtc to ironlake_fdi_disable() 3255e30c8634 drm/i915: Move crtc_state to tighter scope 34bc068536a5 drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on() 27b52f9c78ba drm/i915: Add intel_crtc_vblank_off() 1cf7018c4c93 drm/i915: Change intel_encoders_() calling convention == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15329/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/17] drm/i915/selftests: Exercise rc6 handling
Hi Chris,
On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
> possible rc6 context corruption. Poke at the bear!
>
> Signed-off-by: Chris Wilson
> Cc: Imre Deak
> Cc: Mika Kuoppala
it looks good,
Reviewed-by: Andi Shyti
Tested-by: Andi Shyti
just a question, though
> diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> index d1752f15702a..1d5bf93d1258 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> @@ -6,6 +6,7 @@
> */
>
> #include "selftest_llc.h"
> +#include "selftest_rc6.h"
>
> static int live_gt_resume(void *arg)
> {
> @@ -58,3 +59,15 @@ int intel_gt_pm_live_selftests(struct drm_i915_private
> *i915)
>
> return intel_gt_live_subtests(tests, &i915->gt);
> }
> +
> +int intel_gt_pm_late_selftests(struct drm_i915_private *i915)
> +{
> + static const struct i915_subtest tests[] = {
> + SUBTEST(live_rc6_ctx),
> + };
> +
> + if (intel_gt_is_wedged(&i915->gt))
> + return 0;
> +
> + return intel_gt_live_subtests(tests, &i915->gt);
> +}
are you thinking of making this file a hub for all power
management selftests? wouldn't it be more neat if rc6, rps and
others have their own selftests declared independently,
considering that we might want to add more of them?
> +static const u32 *__live_rc6_ctx(struct intel_context *ce)
> +{
> + struct i915_request *rq;
> + u32 const *result;
'const' here? you like reckless life! :)
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/17] drm/i915/selftests: Exercise rc6 handling
Quoting Andi Shyti (2019-11-19 15:24:59)
> Hi Chris,
>
> On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> > Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
> > possible rc6 context corruption. Poke at the bear!
> >
> > Signed-off-by: Chris Wilson
> > Cc: Imre Deak
> > Cc: Mika Kuoppala
>
> it looks good,
>
> Reviewed-by: Andi Shyti
> Tested-by: Andi Shyti
>
> just a question, though
>
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> > b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> > index d1752f15702a..1d5bf93d1258 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
> > @@ -6,6 +6,7 @@
> > */
> >
> > #include "selftest_llc.h"
> > +#include "selftest_rc6.h"
> >
> > static int live_gt_resume(void *arg)
> > {
> > @@ -58,3 +59,15 @@ int intel_gt_pm_live_selftests(struct drm_i915_private
> > *i915)
> >
> > return intel_gt_live_subtests(tests, &i915->gt);
> > }
> > +
> > +int intel_gt_pm_late_selftests(struct drm_i915_private *i915)
> > +{
> > + static const struct i915_subtest tests[] = {
> > + SUBTEST(live_rc6_ctx),
> > + };
> > +
> > + if (intel_gt_is_wedged(&i915->gt))
> > + return 0;
> > +
> > + return intel_gt_live_subtests(tests, &i915->gt);
> > +}
>
> are you thinking of making this file a hub for all power
> management selftests? wouldn't it be more neat if rc6, rps and
> others have their own selftests declared independently,
> considering that we might want to add more of them?
The hub is over at intel_gt_pm_selftests :)
I started by adding this one there, except that this deliberately breaks
the system and so should be run at the end of CI and rebooted
afterwards.
>
> > +static const u32 *__live_rc6_ctx(struct intel_context *ce)
> > +{
> > + struct i915_request *rq;
> > + u32 const *result;
>
> 'const' here? you like reckless life! :)
Shame on me.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Schedule request retirement when submission idles
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20191118]
[cannot apply to v5.4-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Schedule-request-retirement-when-submission-idles/20191119-023819
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-e002-20191119 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-14) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/export.h:42:0,
from include/linux/linkage.h:7,
from include/linux/kernel.h:8,
from include/linux/interrupt.h:6,
from drivers/gpu/drm/i915/gt/intel_lrc.c:134:
drivers/gpu/drm/i915/gt/intel_lrc.c: In function
'execlists_submission_tasklet':
drivers/gpu/drm/i915/gt/intel_lrc.c:2235:7: error: implicit declaration of
function 'execlists_execlists'; did you mean 'execlists_active'?
[-Werror=implicit-function-declaration]
if (!execlists_execlists(&engine->execlists))
^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) :
__trace_if_value(cond))
^~~~
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2235:2: note: in expansion of macro 'if'
if (!execlists_execlists(&engine->execlists))
^~
cc1: some warnings being treated as errors
vim +/if +2235 drivers/gpu/drm/i915/gt/intel_lrc.c
2205
2206 /*
2207 * Check the unread Context Status Buffers and manage the submission of
new
2208 * contexts to the ELSP accordingly.
2209 */
2210 static void execlists_submission_tasklet(unsigned long data)
2211 {
2212 struct intel_engine_cs * const engine = (struct intel_engine_cs
*)data;
2213 bool timeout = preempt_timeout(engine);
2214
2215 process_csb(engine);
2216 if (!READ_ONCE(engine->execlists.pending[0]) || timeout) {
2217 unsigned long flags;
2218
2219 spin_lock_irqsave(&engine->active.lock, flags);
2220 __execlists_submission_tasklet(engine);
2221 spin_unlock_irqrestore(&engine->active.lock, flags);
2223 /* Recheck after serialising with direct-submission */
2224 if (timeout && preempt_timeout(engine))
2225 preempt_reset(engine);
2226 }
2227
2228 /*
2229 * If the GPU is currently idle, retire the outstanding
completed
2230 * requests. This will allow us to enter soft-rc6 as soon as
possible,
2231 * albeit at the cost of running the retire worker much more
frequently
2232 * (over the entire GT not just this engine) and emitting more
idle
2233 * barriers (i.e. kernel context switches) which may some extra
latency.
2234 */
> 2235 if (!execlists_execlists(&engine->execlists))
2236 intel_gt_schedule_retire_requests(engine->gt);
2237 }
2238
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Nov 19 (i915)
On 11/19/19 12:46 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20191118: on x86_64: ERROR: "pm_suspend_target_state" [drivers/gpu/drm/i915/i915.ko] undefined! # CONFIG_SUSPEND is not set -- ~Randy Reported-by: Randy Dunlap ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT
On Tue, 19 Nov 2019, Hans de Goede wrote: > Hi All, > > This series needs to be merged through a single tree, to keep things > bisectable. I have even considered just squashing all 3 patches into 1, > but having separate commits seems better, but that does lead to an > intermediate state where the backlight sysfs interface will be broken > (and fixed 2 commits later). See below for some background info. > > The changes to drivers/acpi/acpi_lpss.c and drivers/mfd/intel_soc_pmic_core.c > are quite small and should not lead to any conflicts, so I believe that > it would be best to merge this entire series through the drm-intel tree. > > Lee, may I have your Acked-by for merging the mfd change through the > drm-intel tree? > > Rafael, may I have your Acked-by for merging the acpi_lpss change through the > drm-intel tree? > > Regards, > > Hans > > p.s. > > The promised background info: > > We have this long standing issue where instead of looking in the i915 > VBT (Video BIOS Table) to see if we should use the PWM block of the SoC > or of the PMIC to control the backlight of a DSI panel, we rely on > drivers/acpi/acpi_lpss.c and/or drivers/mfd/intel_soc_pmic_core.c > registering a pwm with the generic name of "pwm_backlight" and then the > i915 panel code does a pwm_get(dev, "pwm_backlight"). > > We have some heuristics in drivers/acpi/acpi_lpss.c to not register the > lookup if a Crystal Cove PMIC is presend and the mfd/intel_soc_pmic_core.c > code simply assumes that since there is a PMIC the PMIC PWM block will > be used. Basically we are winging it. > > Recently I've learned about 2 different BYT devices: > Point of View MOBII TAB-P800W > Acer Switch 10 SW5-012 > > Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS > PWM controller (and the VBT correctly indicates this), so here our old > heuristics fail. > > This series renams the PWM lookups registered by the LPSS / > intel_soc_pmic_core.c code from "pwm_backlight" to "pwm_soc_backlight" resp. > "pwm_pmic_backlight" and in the LPSS case also dropping the heuristics when > to register the lookup. This combined with teaching the i915 panel to call > pwm_get for the right lookup-name depending on the VBT bits resolves this. Hans, thanks for your continued efforts in digging into the bottom of this! I'm sure there are a number of related bugs still open at fdo bugzilla. It all makes sense, Acked-by: Jani Nikula for merging through whichever tree. Thanks, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: DSI: select correct PWM controller to use based on the VBT
On Tue, Nov 19, 2019 at 04:18:18PM +0100, Hans de Goede wrote:
> At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
> different PWM controllers for controlling the LCD's backlight brightness.
> Either the one integrated into the PMIC or the one integrated into the
> SoC (the 1st LPSS PWM controller).
>
> So far in the LPSS code on BYT we have skipped registering the LPSS PWM
> controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
> present, assuming that in this case the PMIC PWM controller will be used.
>
> On CHT we have been relying on only 1 of the 2 PWM controllers being
> enabled in the DSDT at the same time; and always registered the lookup.
>
> So far this has been working, but the correct way to determine which PWM
> controller needs to be used is by checking a bit in the VBT table and
> recently I've learned about 2 different BYT devices:
> Point of View MOBII TAB-P800W
> Acer Switch 10 SW5-012
>
> Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
> PWM controller (and the VBT correctly indicates this), so here our old
> heuristics fail.
>
> This commit fixes using the wrong PWM controller on these devices by
> calling pwm_get() for the right PWM controller based on the
> VBT dsi.config.pwm_blc bit.
>
> Note this is part of a series which contains 2 other patches which renames
> the PWM lookup for the 1st SoC/LPSS PWM from "pwm_backlight" to
> "pwm_pmic_backlight" and the PWM lookup for the Crystal Cove PMIC PWM
> from "pwm_backlight" to "pwm_pmic_backlight".
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_panel.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index bc14e9c0285a..ddcf311d1114 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1840,13 +1840,22 @@ static int pwm_setup_backlight(struct intel_connector
> *connector,
> enum pipe pipe)
> {
> struct drm_device *dev = connector->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_panel *panel = &connector->panel;
> + const char *desc;
> int retval;
>
> - /* Get the PWM chip for backlight control */
> - panel->backlight.pwm = pwm_get(dev->dev, "pwm_backlight");
> + /* Get the right PWM chip for DSI backlight according to VBT */
> + if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
> + panel->backlight.pwm = pwm_get(dev->dev, "pwm_pmic_backlight");
> + desc = "PMIC";
> + } else {
> + panel->backlight.pwm = pwm_get(dev->dev, "pwm_soc_backlight");
> + desc = "SoC";
> + }
Might we want the same thing for the panel enable gpio?
> +
> if (IS_ERR(panel->backlight.pwm)) {
> - DRM_ERROR("Failed to own the pwm chip\n");
> + DRM_ERROR("Failed to get the %s PWM chip\n", desc);
> panel->backlight.pwm = NULL;
> return -ENODEV;
> }
> @@ -1873,6 +1882,7 @@ static int pwm_setup_backlight(struct intel_connector
> *connector,
>CRC_PMIC_PWM_PERIOD_NS);
> panel->backlight.enabled = panel->backlight.level != 0;
>
> + DRM_INFO("Using %s PWM for LCD backlight control\n", desc);
> return 0;
> }
>
> --
> 2.23.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/selftests: Exercise rc6 w/a handling
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
possible rc6 context corruption. Poke at the bear!
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Mika Kuoppala
Reviewed-by: Andi Shyti
Tested-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 18 +++
drivers/gpu/drm/i915/gt/selftest_rc6.c| 146 ++
drivers/gpu/drm/i915/gt/selftest_rc6.h| 12 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
5 files changed, 181 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/selftest_rc6.c
create mode 100644 drivers/gpu/drm/i915/gt/selftest_rc6.h
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 977a617a196d..7a0bc6dde009 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -783,3 +783,7 @@ u64 intel_rc6_residency_us(struct intel_rc6 *rc6,
i915_reg_t reg)
{
return DIV_ROUND_UP_ULL(intel_rc6_residency_ns(rc6, reg), 1000);
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_rc6.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index d1752f15702a..5e563b877368 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -6,6 +6,7 @@
*/
#include "selftest_llc.h"
+#include "selftest_rc6.h"
static int live_gt_resume(void *arg)
{
@@ -58,3 +59,20 @@ int intel_gt_pm_live_selftests(struct drm_i915_private *i915)
return intel_gt_live_subtests(tests, &i915->gt);
}
+
+int intel_gt_pm_late_selftests(struct drm_i915_private *i915)
+{
+ static const struct i915_subtest tests[] = {
+ /*
+* These tests may leave the system in an undesirable state.
+* They are intended to be run last in CI and the system
+* rebooted afterwards.
+*/
+ SUBTEST(live_rc6_ctx_wa),
+ };
+
+ if (intel_gt_is_wedged(&i915->gt))
+ return 0;
+
+ return intel_gt_live_subtests(tests, &i915->gt);
+}
diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
new file mode 100644
index ..67b7a6bc64f5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -0,0 +1,146 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "intel_context.h"
+#include "intel_engine_pm.h"
+#include "intel_gt_requests.h"
+#include "intel_ring.h"
+#include "selftest_rc6.h"
+
+#include "selftests/i915_random.h"
+
+static const u32 *__live_rc6_ctx(struct intel_context *ce)
+{
+ struct i915_request *rq;
+ const u32 *result;
+ u32 cmd;
+ u32 *cs;
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return ERR_CAST(rq);
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ return cs;
+ }
+
+ cmd = MI_STORE_REGISTER_MEM | MI_USE_GGTT;
+ if (INTEL_GEN(rq->i915) >= 8)
+ cmd++;
+
+ *cs++ = cmd;
+ *cs++ = i915_mmio_reg_offset(GEN8_RC6_CTX_INFO);
+ *cs++ = ce->timeline->hwsp_offset + 8;
+ *cs++ = 0;
+ intel_ring_advance(rq, cs);
+
+ result = rq->hwsp_seqno + 2;
+ i915_request_add(rq);
+
+ return result;
+}
+
+static struct intel_engine_cs **
+randomised_engines(struct intel_gt *gt,
+ struct rnd_state *prng,
+ unsigned int *count)
+{
+ struct intel_engine_cs *engine, **engines;
+ enum intel_engine_id id;
+ int n;
+
+ n = 0;
+ for_each_engine(engine, gt, id)
+ n++;
+ if (!n)
+ return NULL;
+
+ engines = kmalloc_array(n, sizeof(*engines), GFP_KERNEL);
+ if (!engines)
+ return NULL;
+
+ n = 0;
+ for_each_engine(engine, gt, id)
+ engines[n++] = engine;
+
+ i915_prandom_shuffle(engines, sizeof(*engines), n, prng);
+
+ *count = n;
+ return engines;
+}
+
+int live_rc6_ctx_wa(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs **engines;
+ unsigned int n, count;
+ I915_RND_STATE(prng);
+ int err = 0;
+
+ /* A read of CTX_INFO upsets rc6. Poke the bear! */
+ if (INTEL_GEN(gt->i915) < 8)
+ return 0;
+
+ engines = randomised_engines(gt, &prng, &count);
+ if (!engines)
+ return 0;
+
+ for (n = 0; n < count; n++) {
+ struct intel_engine_cs *engine = engines[n];
+ int pass;
+
+ for (pass = 0; pass < 2; pass++) {
+ struct intel_context *ce;
+ unsigned int resets =
+ i915_reset_engine_count(>->i915->gpu_error,
+
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Do not read the transcoder register.
On Tue, 19 Nov 2019, Vandita Kulkarni wrote:
> As per the Bspec, port mapping is fixed for mipi dsi.
>
> v2: Reuse the existing function (Jani)
>
> Signed-off-by: Vandita Kulkarni
Pushed, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 23f00a651738..dccb94b24d14 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10577,16 +10577,21 @@ static void haswell_get_ddi_port_state(struct
> intel_crtc *crtc,
> struct intel_crtc_state *pipe_config)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> struct intel_shared_dpll *pll;
> enum port port;
> u32 tmp;
>
> - tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe_config->cpu_transcoder));
> -
> - if (INTEL_GEN(dev_priv) >= 12)
> - port = TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
> - else
> - port = TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
> + if (transcoder_is_dsi(cpu_transcoder)) {
> + port = (cpu_transcoder == TRANSCODER_DSI_A) ?
> + PORT_A : PORT_B;
> + } else {
> + tmp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> + if (INTEL_GEN(dev_priv) >= 12)
> + port = TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
> + else
> + port = TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
> + }
>
> if (INTEL_GEN(dev_priv) >= 11)
> icelake_get_ddi_pll(dev_priv, port, pipe_config);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/19] drm/i915: Mark up the calling context for intel_wakeref_put()
On 18/11/2019 23:02, Chris Wilson wrote:
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a working if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally are in process context,
we can typically use a plain mutex, and only defer to a work when we
know we are caller from an interrupt path.
Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in IRQ
contexts")
References: https://bugs.freedesktop.org/show_bug.cgi?id=111626
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c| 3 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.h| 10 +
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 1 -
drivers/gpu/drm/i915/gt/intel_gt_pm.h| 5 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 7 ++--
drivers/gpu/drm/i915/i915_active.c | 5 ++-
drivers/gpu/drm/i915/i915_pmu.c | 6 +--
drivers/gpu/drm/i915/intel_wakeref.c | 8 ++--
drivers/gpu/drm/i915/intel_wakeref.h | 44
11 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 722d3eec226e..4878d16176d5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -180,7 +180,8 @@ static int __engine_park(struct intel_wakeref *wf)
engine->execlists.no_priolist = false;
- intel_gt_pm_put(engine->gt);
+ /* While we call i915_vma_parked, we have to break the lock cycle */
+ intel_gt_pm_put_async(engine->gt);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
index 739c50fefcef..467475fce9c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
@@ -31,6 +31,16 @@ static inline void intel_engine_pm_put(struct
intel_engine_cs *engine)
intel_wakeref_put(&engine->wakeref);
}
+static inline void intel_engine_pm_put_async(struct intel_engine_cs *engine)
+{
+ intel_wakeref_put_async(&engine->wakeref);
+}
+
+static inline void intel_engine_pm_unlock_wait(struct intel_engine_cs *engine)
+{
+ intel_wakeref_unlock_wait(&engine->wakeref);
+}
+
void intel_engine_init__pm(struct intel_engine_cs *engine);
#endif /* INTEL_ENGINE_PM_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index e61f752a3cd5..7a9044ac4b75 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -105,7 +105,6 @@ static int __gt_park(struct intel_wakeref *wf)
static const struct intel_wakeref_ops wf_ops = {
.get = __gt_unpark,
.put = __gt_park,
- .flags = INTEL_WAKEREF_PUT_ASYNC,
};
void intel_gt_pm_init_early(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index b3e17399be9b..990efc27a4e4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -32,6 +32,11 @@ static inline void intel_gt_pm_put(struct intel_gt *gt)
intel_wakeref_put(>->wakeref);
}
+static inline void intel_gt_pm_put_async(struct intel_gt *gt)
+{
+ intel_wakeref_put_async(>->wakeref);
+}
+
static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
{
return intel_wakeref_wait_for_idle(>->wakeref);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f7c8fec436a9..fec46afb9264 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1173,7 +1173,7 @@ __execlists_schedule_out(struct i915_request *rq,
intel_engine_context_out(engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
- intel_gt_pm_put(engine->gt);
+ intel_gt_pm_put_async(engine->gt);
Wait a minute.. wasn't the wakeref hierarchy supposed to be engine -> gt
so this place should be on the engine level?
/*
* If this is part of a virtual engine, its next request may
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index b7007cd78c6f..0388f9375366 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1125,7 +1125,7 @@ int intel_engine_reset(struct intel_engine_cs *engine,
const char *msg)
out:
intel_engine_cancel_stop_cs(engine);
reset_finish_engine(engine);
- intel_engine_pm_put(engine);
+ intel_engine_pm_put_async(engine);
return ret;
}
diff --git a/drivers/gpu/drm/i
Re: [Intel-gfx] [PATCH 12/19] drm/i915/gt: Declare timeline.lock to be irq-free
On 18/11/2019 23:02, Chris Wilson wrote:
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 -
drivers/gpu/drm/i915/gt/intel_reset.c | 9 -
drivers/gpu/drm/i915/gt/intel_timeline.c| 10 --
3 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 7559d6373f49..74356db43325 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -33,7 +33,6 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
{
struct intel_gt_timelines *timelines = >->timelines;
struct intel_timeline *tl, *tn;
- unsigned long flags;
bool interruptible;
LIST_HEAD(free);
@@ -43,7 +42,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout)
flush_submission(gt); /* kick the ksoftirqd tasklets */
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &timelines->active_list, link) {
if (!mutex_trylock(&tl->mutex))
continue;
@@ -51,7 +50,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
intel_timeline_get(tl);
GEM_BUG_ON(!atomic_read(&tl->active_count));
atomic_inc(&tl->active_count); /* pin the list element */
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
if (timeout > 0) {
struct dma_fence *fence;
@@ -67,7 +66,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
retire_requests(tl);
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
/* Resume iteration after dropping lock */
list_safe_reset_next(tl, tn, link);
@@ -82,7 +81,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
list_add(&tl->link, &free);
}
}
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &free, link)
__intel_timeline_free(&tl->kref);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 0388f9375366..36189238e13c 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -831,7 +831,6 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
{
struct intel_gt_timelines *timelines = >->timelines;
struct intel_timeline *tl;
- unsigned long flags;
bool ok;
if (!test_bit(I915_WEDGED, >->reset.flags))
@@ -853,7 +852,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
*
* No more can be submitted until we reset the wedged bit.
*/
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
list_for_each_entry(tl, &timelines->active_list, link) {
struct dma_fence *fence;
@@ -861,7 +860,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
if (!fence)
continue;
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
/*
* All internal dependencies (i915_requests) will have
@@ -874,10 +873,10 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
dma_fence_put(fence);
/* Restart iteration after droping lock */
- spin_lock_irqsave(&timelines->lock, flags);
+ spin_lock(&timelines->lock);
tl = list_entry(&timelines->active_list, typeof(*tl), link);
}
- spin_unlock_irqrestore(&timelines->lock, flags);
+ spin_unlock(&timelines->lock);
/* We must reset pending GPU events before restoring our submission */
ok = !HAS_EXECLISTS(gt->i915); /* XXX better agnosticism desired */
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 4f914f0d5eab..bd973d950064 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -332,7 +332,6 @@ int intel_timeline_pin(struct intel_timeline *tl)
void intel_timeline_enter(struct intel_timeline *tl)
{
struct intel_gt_timelines *timelines = &tl->gt->timelines;
- unsigned long flags;
/*
* Pretend we are serialised by the timeline->mutex.
@@ -358,16 +357,15 @@ void intel_timeline_enter(struct intel_timeline *tl)
if (atomic_add_unless(&tl->active_count, 1, 0))
ret
Re: [Intel-gfx] [PATCH 13/19] drm/i915/gt: Move new timelines to the end of active_list
On 18/11/2019 23:02, Chris Wilson wrote:
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner.
References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_retire_requests()")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index bd973d950064..b190a5d9ab02 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -359,7 +359,7 @@ void intel_timeline_enter(struct intel_timeline *tl)
spin_lock(&timelines->lock);
if (!atomic_fetch_inc(&tl->active_count))
- list_add(&tl->link, &timelines->active_list);
+ list_add_tail(&tl->link, &timelines->active_list);
spin_unlock(&timelines->lock);
}
If I am not missing something this should be on the micro-optimisation
level, well, mini-optimisation. Since for instance now it could wait on
the most recent request and when that finishes do mostly signalled
checks, or even less. With the change it would first sweep the already
completed ones and then wait for the most recent one. Nevertheless, I
don't see a problem with it so:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make pool objects read-only
== Series Details == Series: drm/i915: make pool objects read-only URL : https://patchwork.freedesktop.org/series/69684/ State : success == Summary == CI Bug Log - changes from CI_DRM_7371 -> Patchwork_15330 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15330/index.html Known issues Here are the changes found in Patchwork_15330 that come from known issues: ### IGT changes ### Issues hit * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][1] -> [DMESG-WARN][2] ([fdo#102614]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15330/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-skl-lmem:[DMESG-WARN][3] ([fdo#112261]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-skl-lmem/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15330/fi-skl-lmem/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_blt: - fi-hsw-peppy: [DMESG-FAIL][5] ([fdo#112147]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-hsw-peppy/igt@i915_selftest@live_blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15330/fi-hsw-peppy/igt@i915_selftest@live_blt.html * igt@kms_busy@basic-flip-pipe-a: - fi-icl-u2: [TIMEOUT][7] ([fdo#111800]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15330/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][9] ([fdo#111407]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7371/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15330/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111800]: https://bugs.freedesktop.org/show_bug.cgi?id=111800 [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147 [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261 Participating hosts (50 -> 44) -- Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7371 -> Patchwork_15330 CI-20190529: 20190529 CI_DRM_7371: 4a9a6d1fade97c450a0eabbc3436f1dc5518b15e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5295: 9211e4794e40135d797e6d056d6d8d40076acb92 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_15330: 9460222ac763d4123dad7d58533cde38684a1e73 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9460222ac763 drm/i915: make pool objects read-only == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15330/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/19] drm/i915/gt: Schedule next retirement worker first
On 18/11/2019 23:02, Chris Wilson wrote: As we may park the gt during request retirement, we may then cancel the retirement worker only to then program the delayed worker once more. If we schedule the next delayed retirement worker first, if we then park the gt, the work remain cancelled [until we unpark]. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/drm/i915/gt/intel_gt_requests.c index 74356db43325..4dc3cbeb1b36 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c @@ -109,9 +109,9 @@ static void retire_work_handler(struct work_struct *work) struct intel_gt *gt = container_of(work, typeof(*gt), requests.retire_work.work); - intel_gt_retire_requests(gt); schedule_delayed_work(>->requests.retire_work, round_jiffies_up_relative(HZ)); + intel_gt_retire_requests(gt); } void intel_gt_init_requests(struct intel_gt *gt) Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/19] drm/i915: Mark up the calling context for intel_wakeref_put()
Quoting Tvrtko Ursulin (2019-11-19 15:57:24)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index f7c8fec436a9..fec46afb9264 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1173,7 +1173,7 @@ __execlists_schedule_out(struct i915_request *rq,
> >
> > intel_engine_context_out(engine);
> > execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
> > - intel_gt_pm_put(engine->gt);
> > + intel_gt_pm_put_async(engine->gt);
>
> Wait a minute.. wasn't the wakeref hierarchy supposed to be engine -> gt
> so this place should be on the engine level?
Ssh. I lied.
We skip the engine-pm here for the CS interrupts so that we are not kept
waiting to call engine_park().
The excuse is that this wakeref for the GT interrupt, not the engine :)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > index b7007cd78c6f..0388f9375366 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > @@ -1125,7 +1125,7 @@ int intel_engine_reset(struct intel_engine_cs
> > *engine, const char *msg)
> > out:
> > intel_engine_cancel_stop_cs(engine);
> > reset_finish_engine(engine);
> > - intel_engine_pm_put(engine);
> > + intel_engine_pm_put_async(engine);
> > return ret;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> > b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> > index 20b9c83f43ad..851a6c4f65c6 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> > @@ -51,11 +51,12 @@ static int live_engine_pm(void *arg)
> > pr_err("intel_engine_pm_get_if_awake(%s)
> > failed under %s\n",
> > engine->name, p->name);
> > else
> > - intel_engine_pm_put(engine);
> > - intel_engine_pm_put(engine);
> > + intel_engine_pm_put_async(engine);
> > + intel_engine_pm_put_async(engine);
> > p->critical_section_end();
> >
> > - /* engine wakeref is sync (instant) */
> > + intel_engine_pm_unlock_wait(engine);
>
> From the context would it be clearer to name it
> intel_engine_pm_wait_put? sync_put? flush_put? To more clearly represent
> it is a pair of put_async.
Possibly, I am in mourning for spin_unlock_wait() and will keep on
protesting its demise!
intel_engine_pm_flush() is perhaps the clearest description in line with
say flush_work().
> > diff --git a/drivers/gpu/drm/i915/i915_active.c
> > b/drivers/gpu/drm/i915/i915_active.c
> > index 5448f37c8102..dca15ace88f6 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@ -672,12 +672,13 @@ void i915_active_acquire_barrier(struct i915_active
> > *ref)
> >* populated by i915_request_add_active_barriers() to point to the
> >* request that will eventually release them.
> >*/
> > - spin_lock_irqsave_nested(&ref->tree_lock, flags,
> > SINGLE_DEPTH_NESTING);
> > llist_for_each_safe(pos, next, take_preallocated_barriers(ref)) {
> > struct active_node *node = barrier_from_ll(pos);
> > struct intel_engine_cs *engine = barrier_to_engine(node);
> > struct rb_node **p, *parent;
> >
> > + spin_lock_irqsave_nested(&ref->tree_lock, flags,
> > + SINGLE_DEPTH_NESTING);
> > parent = NULL;
> > p = &ref->tree.rb_node;
> > while (*p) {
> > @@ -693,12 +694,12 @@ void i915_active_acquire_barrier(struct i915_active
> > *ref)
> > }
> > rb_link_node(&node->node, parent, p);
> > rb_insert_color(&node->node, &ref->tree);
> > + spin_unlock_irqrestore(&ref->tree_lock, flags);
> >
> > GEM_BUG_ON(!intel_engine_pm_is_awake(engine));
> > llist_add(barrier_to_ll(node), &engine->barrier_tasks);
> > intel_engine_pm_put(engine);
> > }
> > - spin_unlock_irqrestore(&ref->tree_lock, flags);
>
> Pros/cons of leaving the locks where they were and using put_async,
> versus this layout?
Usually just a single engine in the list (only for virtual engines will
there be more) so we save the worker invocation at typically no cost.
Thus getting into the engine_park() earlier while the GPU is still warm.
That and I'm still smarting from RT demanding all spin_lock_irq to be
reviewed and tightened.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm/i915/gt: Flush the requests after wedging on suspend
On 18/11/2019 23:02, Chris Wilson wrote: Retire all requests if we resort to wedged the driver on suspend. They will now be idle, so we might as we free them before shutting down. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c index 7a9044ac4b75..f6b5169d623f 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c @@ -256,6 +256,7 @@ static void wait_for_suspend(struct intel_gt *gt) * the gpu quiet. */ intel_gt_set_wedged(gt); + intel_gt_retire_requests(gt); } intel_gt_pm_wait_for_idle(gt); Reviewed-by: Tvrtko Ursulin Or given that parking is now sync it could work to make intel_gt_park_requests flush and then intel_gt_pm_wait_for_idle would handle it. But that would keep the GPU alive for too long, given that request retire can run independently. So perhaps this is better. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/17] drm/i915: Wait until the intel_wakeref idle callback is complete
Chris Wilson writes:
> When waiting for idle, serialise with any ongoing callback so that it
> will have completed before completing the wait.
Might be come apparent and evident when reading the patch
that introduce the intel_wakeref_unlock_wait(),
but reader is yearning for a why part.
The 'wait_for_idle' is kind of revaling of
why the need for sync tho.
-Mika
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_wakeref.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_wakeref.c
> b/drivers/gpu/drm/i915/intel_wakeref.c
> index 9b29176cc1ca..91feb53b2942 100644
> --- a/drivers/gpu/drm/i915/intel_wakeref.c
> +++ b/drivers/gpu/drm/i915/intel_wakeref.c
> @@ -109,8 +109,15 @@ void __intel_wakeref_init(struct intel_wakeref *wf,
>
> int intel_wakeref_wait_for_idle(struct intel_wakeref *wf)
> {
> - return wait_var_event_killable(&wf->wakeref,
> -!intel_wakeref_is_active(wf));
> + int err;
> +
> + err = wait_var_event_killable(&wf->wakeref,
> + !intel_wakeref_is_active(wf));
> + if (err)
> + return err;
> +
> + intel_wakeref_unlock_wait(wf);
> + return 0;
> }
>
> static void wakeref_auto_timeout(struct timer_list *t)
> --
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
