Re: [Intel-gfx] [PATCH 2/4] drm/i915: clean up virtual PCH special case handling
On 05/31/2018 07:56 PM, Jani Nikula wrote:
Use intel_pch_type() also for mapping the no PCH case (PCH id 0) to
PCH_NONE to simplify code.
Also make sure that intel_pch_type() knows all the PCH ids returned by
intel_virt_detect_pch(). Loudly fail if this isn't the case; this
shouldn't happen anyway.
Cc: Colin Xu
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c42e389a27f3..1842a067a604 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -282,13 +282,12 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
} else if (intel_is_virt_pch(id, pch->subsystem_vendor,
pch->subsystem_device)) {
id = intel_virt_detect_pch(dev_priv);
- if (id) {
- pch_type = intel_pch_type(dev_priv, id);
- if (WARN_ON(pch_type == PCH_NONE))
- pch_type = PCH_NOP;
- } else {
- pch_type = PCH_NONE;
- }
+ pch_type = intel_pch_type(dev_priv, id);
+
+ /* Sanity check virtual PCH id */
+ if (WARN_ON(id && pch_type == PCH_NONE))
+ id = 0;
+
dev_priv->pch_type = pch_type;
dev_priv->pch_id = id;
break;
Tested on BXT gvt-g and got expected behaviour.
Tested-by: Colin Xu
Reviewed-by: Colin Xu
--
Best Regards,
Colin Xu
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On 05/31/2018 07:56 PM, Jani Nikula wrote:
Virtualized non-PCH systems such as Broxton or Geminilake should use
PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
specific case to indicate a PCH system without south display.
Reported-by: Colin Xu
Cc: Colin Xu
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8f002ae22e62..c42e389a27f3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -287,7 +287,7 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
if (WARN_ON(pch_type == PCH_NONE))
pch_type = PCH_NOP;
} else {
- pch_type = PCH_NOP;
+ pch_type = PCH_NONE;
}
dev_priv->pch_type = pch_type;
dev_priv->pch_id = id;
Tested on BXT gvt-g and got expected behaviour.
Tested-by: Colin Xu
Reviewed-by: Colin Xu
--
Best Regards,
Colin Xu
___
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: Assert we idle in the kernel context
== Series Details == Series: drm/i915: Assert we idle in the kernel context URL : https://patchwork.freedesktop.org/series/44052/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4268_full -> Patchwork_9165_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9165_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9165_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44052/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9165_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: SKIP -> PASS +3 igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt: shard-hsw: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9165_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> INCOMPLETE (fdo#103665) shard-glk: PASS -> FAIL (fdo#105347) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_cursor_legacy@flip-vs-cursor-legacy: shard-hsw: PASS -> FAIL (fdo#102670) igt@kms_flip@2x-wf_vblank-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#103928) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) +2 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_eio@hibernate: shard-snb: FAIL (fdo#105957) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4268 -> Patchwork_9165 CI_DRM_4268: 7138a144b0da03dcbe54731f7ac0dab6948beafb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4503: ae0ea2a0cff1cf8516d18ada5b9db01c56b73ed9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9165: 3ee19b0cecdd0ca6020bda92f61c98019202ae45 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9165/shards.html ___ 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: Assert we idle in the kernel context
== Series Details == Series: drm/i915: Assert we idle in the kernel context URL : https://patchwork.freedesktop.org/series/44052/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9165 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44052/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9165 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_flip@basic-flip-vs-modeset: fi-hsw-4770r: PASS -> DMESG-WARN (fdo#105602) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927) Possible fixes igt@kms_chamelium@hdmi-hpd-fast: fi-kbl-7500u: FAIL (fdo#103841, fdo#102672) -> SKIP igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 == Participating hosts (42 -> 40) == Additional (1): fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4268 -> Patchwork_9165 CI_DRM_4268: 7138a144b0da03dcbe54731f7ac0dab6948beafb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4503: ae0ea2a0cff1cf8516d18ada5b9db01c56b73ed9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9165: 3ee19b0cecdd0ca6020bda92f61c98019202ae45 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3ee19b0cecdd drm/i915: Assert we idle in the kernel context == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9165/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Assert we idle in the kernel context
== Series Details ==
Series: drm/i915: Assert we idle in the kernel context
URL : https://patchwork.freedesktop.org/series/44052/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3ee19b0cecdd drm/i915: Assert we idle in the kernel context
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#9:
References: 4dfacb0bcbee ("drm/i915: Switch to kernel context before idling at
runtime")
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 4dfacb0bcbee ("drm/i915: Switch
to kernel context before idling at runtime")'
#9:
References: 4dfacb0bcbee ("drm/i915: Switch to kernel context before idling at
runtime")
total: 1 errors, 1 warnings, 0 checks, 49 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Assert we idle in the kernel context
Now that we always switch to the kernel context upon idling, we can
make that assertion.
References: 4dfacb0bcbee ("drm/i915: Switch to kernel context before idling at
runtime")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f5c4ef052001..66bb81cd43cd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3498,6 +3498,22 @@ new_requests_since_last_retire(const struct
drm_i915_private *i915)
work_pending(>gt.idle_work.work));
}
+static void assert_kernel_context_is_current(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ if (i915_terminally_wedged(>gpu_error))
+ return;
+
+ GEM_BUG_ON(i915->gt.active_requests);
+ for_each_engine(engine, i915, id) {
+
GEM_BUG_ON(__i915_gem_active_peek(>timeline.last_request));
+ GEM_BUG_ON(engine->last_retired_context !=
+ to_intel_context(i915->kernel_context, engine));
+ }
+}
+
static void
i915_gem_idle_work_handler(struct work_struct *work)
{
@@ -3558,6 +3574,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
+ assert_kernel_context_is_current(dev_priv);
+
epoch = __i915_gem_park(dev_priv);
rearm_hangcheck = false;
@@ -4944,19 +4962,6 @@ void __i915_gem_object_release_unless_active(struct
drm_i915_gem_object *obj)
i915_gem_object_put(obj);
}
-static void assert_kernel_context_is_current(struct drm_i915_private *i915)
-{
- struct i915_gem_context *kctx = i915->kernel_context;
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- GEM_BUG_ON(i915->gt.active_requests);
- for_each_engine(engine, i915, id) {
-
GEM_BUG_ON(__i915_gem_active_peek(>timeline.last_request));
- GEM_BUG_ON(engine->last_retired_context->gem_context != kctx);
- }
-}
-
void i915_gem_sanitize(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
--
2.17.1
___
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/11] drm/i915: Be irqsafe inside reset (rev3)
== Series Details == Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3) URL : https://patchwork.freedesktop.org/series/44041/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4268_full -> Patchwork_9163_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9163_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9163_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44041/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9163_full: === IGT changes === Possible regressions igt@drv_selftest@live_hangcheck: shard-apl: PASS -> DMESG-FAIL Warnings igt@drv_selftest@live_execlists: shard-apl: PASS -> SKIP +1 igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP +2 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +3 igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt: shard-hsw: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9163_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_hangcheck: shard-kbl: DMESG-FAIL (fdo#106560) -> PASS igt@gem_eio@hibernate: shard-snb: FAIL (fdo#105957) -> PASS igt@gem_eio@suspend: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: FAIL (fdo#105703) -> PASS fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4268 -> Patchwork_9163 CI_DRM_4268: 7138a144b0da03dcbe54731f7ac0dab6948beafb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4503: ae0ea2a0cff1cf8516d18ada5b9db01c56b73ed9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9163: eb2138838e704ba6d157a492695a3467dd17e4c4 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9163/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable preemption if it fails
Quoting Singh, Satyeshwar (2018-05-31 22:17:25) > Hi Chris, > Isn't this dependent upon the workload submitted to the GuC? Meaning we have > one workload that refused to be preempted (really long shader for example) > but it went away on its own. Other workloads that come in later are > preemptible. However, if we turn off preemption permanently, then all future > workloads will not be preempted either which may not be desirable. Whoever implements the recovery mechanism can clear the flag. You may like to clear the flag on reset? We would have to be more careful about the manipulation of engine->flags as it's not serialised atm (since it's _meant_ to be write-once during init). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable preemption if it fails
Hi Chris,
Isn't this dependent upon the workload submitted to the GuC? Meaning we have
one workload that refused to be preempted (really long shader for example) but
it went away on its own. Other workloads that come in later are preemptible.
However, if we turn off preemption permanently, then all future workloads will
not be preempted either which may not be desirable.
-Satyeshwar
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Chris Wilson
Sent: Thursday, May 31, 2018 1:47 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915/guc: Disable preemption if it fails
If we fail to tell the GuC to perform preemption, we get stuck attempting to
continually retry inject_preempt_context() until we eventually timeout and
reset the GPU (approximately emitting the same warning 1000 times). Bail after
the first failure, emit the WARN and stop trying to do any further preemption
on this engine.
References:
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_2235/shard-apl4/igt@gem_exec_sched...@preempt-bsd.html
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Michel Thierry
Cc: Michałt Winiarski
---
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 133367a17863..24bdac205c45 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -588,6 +588,7 @@ static void inject_preempt_context(struct work_struct *work)
data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
if (WARN_ON(intel_guc_send(guc, data, ARRAY_SIZE(data {
+ engine->flags &= ~I915_ENGINE_HAS_PREEMPTION; /* XXX racy! */
execlists_clear_active(>execlists,
EXECLISTS_ACTIVE_PREEMPT);
tasklet_schedule(>execlists.tasklet);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable preemption if it fails
On 5/31/2018 1:47 PM, Chris Wilson wrote:
If we fail to tell the GuC to perform preemption, we get stuck
attempting to continually retry inject_preempt_context() until we
eventually timeout and reset the GPU (approximately emitting the same
warning 1000 times). Bail after the first failure, emit the WARN and
I only see 340 warnings in the 4 seconds before it timed out.
<7>[ ] [drm:intel_guc_send_mmio [i915]] INTEL_GUC_SEND: Action 0x2
failed; ret=-110 status=0x0002 response=0x4000
The status is the same as the action, so something really bad happened
inside there.
stop trying to do any further preemption on this engine.
References:
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_2235/shard-apl4/igt@gem_exec_sched...@preempt-bsd.html
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Michel Thierry
Cc: Michałt Winiarski
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 133367a17863..24bdac205c45 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -588,6 +588,7 @@ static void inject_preempt_context(struct work_struct *work)
data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
if (WARN_ON(intel_guc_send(guc, data, ARRAY_SIZE(data {
+ engine->flags &= ~I915_ENGINE_HAS_PREEMPTION; /* XXX racy! */
execlists_clear_active(>execlists,
EXECLISTS_ACTIVE_PREEMPT);
tasklet_schedule(>execlists.tasklet);
___
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/guc: Disable preemption if it fails
== Series Details == Series: drm/i915/guc: Disable preemption if it fails URL : https://patchwork.freedesktop.org/series/44045/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9164 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9164 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9164, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44045/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9164: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9164 that come from known issues: === IGT changes === Issues hit igt@gem_exec_create@basic: fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719) igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) Possible fixes igt@kms_chamelium@hdmi-hpd-fast: fi-kbl-7500u: FAIL (fdo#103841, fdo#102672) -> SKIP igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 == Participating hosts (42 -> 40) == Additional (1): fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4268 -> Patchwork_9164 CI_DRM_4268: 7138a144b0da03dcbe54731f7ac0dab6948beafb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4503: ae0ea2a0cff1cf8516d18ada5b9db01c56b73ed9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9164: 815a8c14e179ccb07fe20b90affeb87ca3b49368 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 815a8c14e179 drm/i915/guc: Disable preemption if it fails == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9164/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/perf: fix ctx_id read with GuC & ICL
On 31/05/18 21:46, Michel Thierry wrote:
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches exactly the hw_id stored into the context descriptor.
When using GuC submission we have an issue of a non matching hw_id
because GuC uses bit 20 of the hw_id to signal proxy submission. This
change makes introduces a mask to compare only the relevant bits.
Choose one: makes or introduces ;)
On ICL the context descriptor format has changed and we failed to
address this. On top of using a mask we also need to shift the bits
properly.
Someone is going to complain this should be two patches (one to
address the GuC-ness and one for Gen11), but not me.
Reviewed-by: Michel Thierry
Kind of agree, but that's a pain.
We can put it as a fix of the first commit that enabled gen8 and I'll do
the backport in stable versions.
Cheers,
-
Lionel
Signed-off-by: Lionel Landwerlin
Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104252
BSpec: 1237
Testcase: igt/perf/gen8-unprivileged-single-ctx-counters
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 123 ---
drivers/gpu/drm/i915/intel_lrc.c | 5 ++
3 files changed, 101 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 58ab9259fb73..0ccda488a8db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1953,6 +1953,7 @@ struct drm_i915_private {
struct intel_context *pinned_ctx;
u32 specific_ctx_id;
+ u32 specific_ctx_id_mask;
struct hrtimer poll_check_timer;
wait_queue_head_t poll_wq;
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 4a62024cbf85..d5e5d4635f1f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -738,12 +738,7 @@ static int gen8_append_oa_reports(struct
i915_perf_stream *stream,
continue;
}
- /*
- * XXX: Just keep the lower 21 bits for now since I'm not
- * entirely sure if the HW touches any of the higher bits in
- * this field
- */
- ctx_id = report32[2] & 0x1f;
+ ctx_id = report32[2] & dev_priv->perf.oa.specific_ctx_id_mask;
/*
* Squash whatever is in the CTX_ID field if it's marked as
@@ -1204,6 +1199,36 @@ static int i915_oa_read(struct
i915_perf_stream *stream,
return dev_priv->perf.oa.ops.read(stream, buf, count, offset);
}
+static int oa_get_render_lrca(struct drm_i915_private *i915,
+ struct i915_gem_context *ctx,
+ u32 *lrca)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ struct intel_context *ce;
+ int ret;
+
+ ret = i915_mutex_lock_interruptible(>drm);
+ if (ret)
+ return ret;
+
+ /*
+ * As the ID is the gtt offset of the context's vma we
+ * pin the vma to ensure the ID remains fixed.
+ *
+ * NB: implied RCS engine...
+ */
+ ce = intel_context_pin(ctx, engine);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ i915->perf.oa.pinned_ctx = ce;
+
+ *lrca = i915_ggtt_offset(ce->state);
+
+ return 0;
+}
+
/**
* oa_get_render_ctx_id - determine and hold ctx hw id
* @stream: An i915-perf stream opened for OA metrics
@@ -1216,40 +1241,81 @@ static int i915_oa_read(struct
i915_perf_stream *stream,
*/
static int oa_get_render_ctx_id(struct i915_perf_stream *stream)
{
- struct drm_i915_private *dev_priv = stream->dev_priv;
+ struct drm_i915_private *i915 = stream->dev_priv;
- if (HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
- dev_priv->perf.oa.specific_ctx_id = stream->ctx->hw_id;
- } else {
- struct intel_engine_cs *engine = dev_priv->engine[RCS];
- struct intel_context *ce;
+ switch (INTEL_GEN(i915)) {
+ case 7: {
int ret;
- ret = i915_mutex_lock_interruptible(_priv->drm);
+ ret = oa_get_render_lrca(i915, stream->ctx,
+ >perf.oa.specific_ctx_id);
if (ret)
return ret;
/*
- * As the ID is the gtt offset of the context's vma we
- * pin the vma to ensure the ID remains fixed.
- *
- * NB: implied RCS engine...
+ * On Haswell we don't do any post processing of the reports
+ * and don't need to use the mask.
*/
- ce = intel_context_pin(stream->ctx, engine);
- mutex_unlock(_priv->drm.struct_mutex);
- if
Re: [Intel-gfx] [PATCH 1/2] drm/i915: drop one bit on the hw_id when using guc
On 31/05/18 21:33, Michel Thierry wrote:
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should avoid allocating
the hw_id on that bit and restriction to bits [0:19] (i.e 20bits
instead of 21).
Signed-off-by: Lionel Landwerlin
BSpec: 1237
---
drivers/gpu/drm/i915/i915_drv.h | 18 ++
drivers/gpu/drm/i915/i915_gem_context.c | 7 +--
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 64659d4efeda..58ab9259fb73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1841,6 +1841,7 @@ struct drm_i915_private {
*/
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define MAX_GUC_CONTEXT_HW_ID (1<<20) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
bool dynamic_sseu;
@@ -3262,6 +3263,23 @@ i915_gem_context_lookup(struct
drm_i915_file_private *file_priv, u32 id)
return ctx;
}
+static inline u32
+i915_gem_context_max_hw_id(struct drm_i915_private *i915)
+{
+ /* TODO: Confirm the max number on Gen11 with GuC */
+ if (INTEL_GEN(i915) >= 11)
+ return GEN11_MAX_CONTEXT_HW_ID;
+
+ /*
+ * When using GuC in proxy submission, GuC consumes the highest
bit in
+ * the context id to indicate proxy submission.
+ */
+ if (USES_GUC_SUBMISSION(i915))
+ return MAX_GUC_CONTEXT_HW_ID;
+
+ return MAX_CONTEXT_HW_ID;
+}
+
What was the reason of moving this out of i915_gem_context.c? I don't
see any other user.
Yeah, I was initially thinking I would reuse that in i915_perf.c, but
that's not the case.
I can send a v2 to put it back in.
Everything else looks good to me so
Reviewed-by: Michel Thierry
int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
bool allowed);
bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private
*i915);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ff08515d0c67..b686c04d98a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -205,13 +205,8 @@ static void context_close(struct
i915_gem_context *ctx)
static int assign_hw_id(struct drm_i915_private *dev_priv,
unsigned *out)
{
+ unsigned int max = i915_gem_context_max_hw_id(dev_priv);
int ret;
- unsigned int max;
-
- if (INTEL_GEN(dev_priv) >= 11)
- max = GEN11_MAX_CONTEXT_HW_ID;
- else
- max = MAX_CONTEXT_HW_ID;
ret = ida_simple_get(_priv->contexts.hw_ida,
0, max, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 26e43eb0ef31..94f9c4795190 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -200,7 +200,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
*
* bits 0-11: flags, GEN8_CTX_* (cached in
ctx->desc_template)
* bits 12-31: LRCA, GTT address of (the HWSP of) this context
- * bits 32-52: ctx ID, a globally unique tag
+ * bits 32-52: ctx ID, a globally unique tag (highest bit
used by GuC)
* bits 53-54: mbz, reserved for use by hardware
* bits 55-63: group ID, currently unused and set to 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 drm/i915/guc: Disable preemption if it fails
== Series Details == Series: drm/i915/guc: Disable preemption if it fails URL : https://patchwork.freedesktop.org/series/44045/ State : warning == Summary == $ dim checkpatch origin/drm-tip 815a8c14e179 drm/i915/guc: Disable preemption if it fails -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: References: https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_2235/shard-apl4/igt@gem_exec_sched...@preempt-bsd.html total: 0 errors, 1 warnings, 0 checks, 7 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3)
== Series Details == Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3) URL : https://patchwork.freedesktop.org/series/44041/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9163 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44041/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_9163 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719) Possible fixes igt@kms_chamelium@hdmi-hpd-fast: fi-kbl-7500u: FAIL (fdo#103841, fdo#102672) -> SKIP igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (42 -> 40) == Additional (1): fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4268 -> Patchwork_9163 CI_DRM_4268: 7138a144b0da03dcbe54731f7ac0dab6948beafb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4503: ae0ea2a0cff1cf8516d18ada5b9db01c56b73ed9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9163: eb2138838e704ba6d157a492695a3467dd17e4c4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == eb2138838e70 drm/i915: Hold request reference for submission until retirement 5cb96575ec5c drm/i915: Move engine request retirement to intel_engine_cs 9d9175a4bd19 drm/i915: Wait for engines to idle before retiring f68f438e5165 drm/i915: Move rate-limiting request retire to after submission 54bfb646a85a drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) 765d6aaa9b4a drm/i915/execlists: Unify CSB access pointers db1455d68cf7 drm/i915/execlists: Process one CSB interrupt at a time 4430842b2698 drm/i915/execlists: Pull CSB reset under the timeline.lock 805cf1fa48d2 drm/i915/execlists: Pull submit after dequeue under timeline lock 80c4b2f2bb87 drm/i915/execlists: Reset the CSB head tracking on reset/sanitization 4f0a70687283 drm/i915: Be irqsafe inside reset == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9163/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/guc: Disable preemption if it fails
If we fail to tell the GuC to perform preemption, we get stuck
attempting to continually retry inject_preempt_context() until we
eventually timeout and reset the GPU (approximately emitting the same
warning 1000 times). Bail after the first failure, emit the WARN and
stop trying to do any further preemption on this engine.
References:
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_2235/shard-apl4/igt@gem_exec_sched...@preempt-bsd.html
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Michel Thierry
Cc: Michałt Winiarski
---
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 133367a17863..24bdac205c45 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -588,6 +588,7 @@ static void inject_preempt_context(struct work_struct *work)
data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
if (WARN_ON(intel_guc_send(guc, data, ARRAY_SIZE(data {
+ engine->flags &= ~I915_ENGINE_HAS_PREEMPTION; /* XXX racy! */
execlists_clear_active(>execlists,
EXECLISTS_ACTIVE_PREEMPT);
tasklet_schedule(>execlists.tasklet);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/perf: fix ctx_id read with GuC & ICL
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches exactly the hw_id stored into the context descriptor.
When using GuC submission we have an issue of a non matching hw_id
because GuC uses bit 20 of the hw_id to signal proxy submission. This
change makes introduces a mask to compare only the relevant bits.
Choose one: makes or introduces ;)
On ICL the context descriptor format has changed and we failed to
address this. On top of using a mask we also need to shift the bits
properly.
Someone is going to complain this should be two patches (one to address
the GuC-ness and one for Gen11), but not me.
Reviewed-by: Michel Thierry
Signed-off-by: Lionel Landwerlin
Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104252
BSpec: 1237
Testcase: igt/perf/gen8-unprivileged-single-ctx-counters
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 123 ---
drivers/gpu/drm/i915/intel_lrc.c | 5 ++
3 files changed, 101 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 58ab9259fb73..0ccda488a8db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1953,6 +1953,7 @@ struct drm_i915_private {
struct intel_context *pinned_ctx;
u32 specific_ctx_id;
+ u32 specific_ctx_id_mask;
struct hrtimer poll_check_timer;
wait_queue_head_t poll_wq;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4a62024cbf85..d5e5d4635f1f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -738,12 +738,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
continue;
}
- /*
-* XXX: Just keep the lower 21 bits for now since I'm not
-* entirely sure if the HW touches any of the higher bits in
-* this field
-*/
- ctx_id = report32[2] & 0x1f;
+ ctx_id = report32[2] & dev_priv->perf.oa.specific_ctx_id_mask;
/*
* Squash whatever is in the CTX_ID field if it's marked as
@@ -1204,6 +1199,36 @@ static int i915_oa_read(struct i915_perf_stream *stream,
return dev_priv->perf.oa.ops.read(stream, buf, count, offset);
}
+static int oa_get_render_lrca(struct drm_i915_private *i915,
+ struct i915_gem_context *ctx,
+ u32 *lrca)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ struct intel_context *ce;
+ int ret;
+
+ ret = i915_mutex_lock_interruptible(>drm);
+ if (ret)
+ return ret;
+
+ /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*
+* NB: implied RCS engine...
+*/
+ ce = intel_context_pin(ctx, engine);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ i915->perf.oa.pinned_ctx = ce;
+
+ *lrca = i915_ggtt_offset(ce->state);
+
+ return 0;
+}
+
/**
* oa_get_render_ctx_id - determine and hold ctx hw id
* @stream: An i915-perf stream opened for OA metrics
@@ -1216,40 +1241,81 @@ static int i915_oa_read(struct i915_perf_stream *stream,
*/
static int oa_get_render_ctx_id(struct i915_perf_stream *stream)
{
- struct drm_i915_private *dev_priv = stream->dev_priv;
+ struct drm_i915_private *i915 = stream->dev_priv;
- if (HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
- dev_priv->perf.oa.specific_ctx_id = stream->ctx->hw_id;
- } else {
- struct intel_engine_cs *engine = dev_priv->engine[RCS];
- struct intel_context *ce;
+ switch (INTEL_GEN(i915)) {
+ case 7: {
int ret;
- ret = i915_mutex_lock_interruptible(_priv->drm);
+ ret = oa_get_render_lrca(i915, stream->ctx,
+>perf.oa.specific_ctx_id);
if (ret)
return ret;
/*
-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*
-* NB: implied RCS engine...
+* On Haswell we don't do any post processing of the reports
+* and don't need to use the mask.
*/
- ce = intel_context_pin(stream->ctx,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3)
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3)
URL : https://patchwork.freedesktop.org/series/44041/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4f0a70687283 drm/i915: Be irqsafe inside reset
80c4b2f2bb87 drm/i915/execlists: Reset the CSB head tracking on
reset/sanitization
-:41: WARNING:LONG_LINE: line over 100 characters
#41: FILE: drivers/gpu/drm/i915/intel_lrc.c:979:
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
total: 0 errors, 1 warnings, 0 checks, 42 lines checked
805cf1fa48d2 drm/i915/execlists: Pull submit after dequeue under timeline lock
4430842b2698 drm/i915/execlists: Pull CSB reset under the timeline.lock
db1455d68cf7 drm/i915/execlists: Process one CSB interrupt at a time
-:35: WARNING:MEMORY_BARRIER: memory barrier without comment
#35: FILE: drivers/gpu/drm/i915/intel_lrc.c:966:
+ smp_mb__after_atomic();
-:77: WARNING:LONG_LINE: line over 100 characters
#77: FILE: drivers/gpu/drm/i915/intel_lrc.c:990:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:78: WARNING:LONG_LINE: line over 100 characters
#78: FILE: drivers/gpu/drm/i915/intel_lrc.c:991:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-:140: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#140: FILE: drivers/gpu/drm/i915/intel_lrc.c:1022:
+ status, buf[2*head + 1],
^
-:176: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#176: FILE: drivers/gpu/drm/i915/intel_lrc.c:1040:
+ buf[2*head + 1] == execlists->preempt_complete_status) {
^
total: 0 errors, 3 warnings, 2 checks, 301 lines checked
765d6aaa9b4a drm/i915/execlists: Unify CSB access pointers
54bfb646a85a drm/i915/execlists: Direct submission of new requests (avoid
tasklet/ksoftirqd)
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
Comparing the impact on the maximum latency observed (that is the time stolen
-:102: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit 27af5eea54d1 ("drm/i915:
Move execlists irq handler to a bottom half")'
#102:
References: 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom
half")
total: 1 errors, 1 warnings, 0 checks, 359 lines checked
f68f438e5165 drm/i915: Move rate-limiting request retire to after submission
9d9175a4bd19 drm/i915: Wait for engines to idle before retiring
5cb96575ec5c drm/i915: Move engine request retirement to intel_engine_cs
eb2138838e70 drm/i915: Hold request reference for submission until retirement
___
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/11] drm/i915: Be irqsafe inside reset (rev2)
== Series Details == Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev2) URL : https://patchwork.freedesktop.org/series/44041/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9162 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44041/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9162 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725, fdo#106248) igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_chamelium@hdmi-hpd-fast: fi-kbl-7500u: FAIL (fdo#103841, fdo#102672) -> SKIP igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 == Participating hosts (42 -> 40) == Additional (1): fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4268 -> Patchwork_9162 CI_DRM_4268: 7138a144b0da03dcbe54731f7ac0dab6948beafb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4503: ae0ea2a0cff1cf8516d18ada5b9db01c56b73ed9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9162: f14b08071ab62b30a7662d290c8f7af8e0a6de6d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f14b08071ab6 drm/i915: Hold request reference for submission until retirement f9ddd078e8f5 drm/i915: Move engine request retirement to intel_engine_cs 2f23f62da048 drm/i915: Wait for engines to idle before retiring 95590ea35f5d drm/i915: Move rate-limiting request retire to after submission fc7a70b009e1 drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) 0c7415c81af2 drm/i915/execlists: Unify CSB access pointers bd7b385b52f6 drm/i915/execlists: Process one CSB interrupt at a time 089902205660 drm/i915/execlists: Pull CSB reset under the timeline.lock d75be47cd2c7 drm/i915/execlists: Pull submit after dequeue under timeline lock 827a42f841af drm/i915/execlists: Reset the CSB head tracking on reset/sanitization df8d5c388e8c drm/i915: Be irqsafe inside reset == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9162/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: drop one bit on the hw_id when using guc
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should avoid allocating
the hw_id on that bit and restriction to bits [0:19] (i.e 20bits
instead of 21).
Signed-off-by: Lionel Landwerlin
BSpec: 1237
---
drivers/gpu/drm/i915/i915_drv.h | 18 ++
drivers/gpu/drm/i915/i915_gem_context.c | 7 +--
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64659d4efeda..58ab9259fb73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1841,6 +1841,7 @@ struct drm_i915_private {
*/
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define MAX_GUC_CONTEXT_HW_ID (1<<20) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
bool dynamic_sseu;
@@ -3262,6 +3263,23 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+static inline u32
+i915_gem_context_max_hw_id(struct drm_i915_private *i915)
+{
+ /* TODO: Confirm the max number on Gen11 with GuC */
+ if (INTEL_GEN(i915) >= 11)
+ return GEN11_MAX_CONTEXT_HW_ID;
+
+ /*
+* When using GuC in proxy submission, GuC consumes the highest bit in
+* the context id to indicate proxy submission.
+*/
+ if (USES_GUC_SUBMISSION(i915))
+ return MAX_GUC_CONTEXT_HW_ID;
+
+ return MAX_CONTEXT_HW_ID;
+}
+
What was the reason of moving this out of i915_gem_context.c? I don't
see any other user.
Everything else looks good to me so
Reviewed-by: Michel Thierry
int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
bool allowed);
bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ff08515d0c67..b686c04d98a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -205,13 +205,8 @@ static void context_close(struct i915_gem_context *ctx)
static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)
{
+ unsigned int max = i915_gem_context_max_hw_id(dev_priv);
int ret;
- unsigned int max;
-
- if (INTEL_GEN(dev_priv) >= 11)
- max = GEN11_MAX_CONTEXT_HW_ID;
- else
- max = MAX_CONTEXT_HW_ID;
ret = ida_simple_get(_priv->contexts.hw_ida,
0, max, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 26e43eb0ef31..94f9c4795190 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -200,7 +200,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
*
* bits 0-11:flags, GEN8_CTX_* (cached in ctx->desc_template)
* bits 12-31:LRCA, GTT address of (the HWSP of) this context
- * bits 32-52:ctx ID, a globally unique tag
+ * bits 32-52:ctx ID, a globally unique tag (highest bit used by GuC)
* bits 53-54:mbz, reserved for use by hardware
* bits 55-63:group ID, currently unused and set to 0
*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Hold request reference for submission until retirement
Currently the async submission backends (guc and execlists) hold a extra
reference to the requests being processed as they are not serialised with
request retirement. If we instead, prevent the request being dropped
from the engine timeline until after submission has finished processing
the request, we can use a single reference held for the entire
submission process (currently, it is held only for the submission
fence).
By doing so we remove a few atomics from inside the irqoff path, on the
order of 200ns as measured by gem_syslatency, bringing the impact of
direct submission into line with the previous tasklet implementation.
The tradeoff is that as we may postpone the retirement, we have to check
for any residual requests after detecting that the engines are idle.
v2: switch-to-kernel-context needs to be cognisant of the delayed
release on the engine->timeline again.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 20 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 42 +
drivers/gpu/drm/i915/intel_guc_submission.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.c| 10 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +-
6 files changed, 49 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 94e4db1870aa..cfce2531c19f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -641,7 +641,7 @@ static bool engine_has_kernel_context_barrier(struct
intel_engine_cs *engine)
return true;
/* The engine is idle; check that it is idling in the kernel context. */
- return engine->last_retired_context == ce;
+ return intel_engine_has_kernel_context(engine);
}
int i915_gem_switch_to_kernel_context(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f91942e4d852..2cfa6f3a2f16 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -347,17 +347,15 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_upto(struct intel_engine_cs *engine,
struct i915_request *rq)
{
+ struct list_head * const requests = >timeline.requests;
struct i915_request *tmp;
if (list_empty(>link))
return;
- do {
- tmp = list_first_entry(>timeline.requests,
- typeof(*tmp), link);
-
- intel_engine_retire_request(engine, tmp);
- } while (tmp != rq);
+ do
+ tmp = list_first_entry(requests, typeof(*tmp), link);
+ while (intel_engine_retire_request(engine, tmp) && tmp != rq);
}
static void i915_request_retire(struct i915_request *request)
@@ -376,6 +374,8 @@ static void i915_request_retire(struct i915_request
*request)
trace_i915_request_retire(request);
+ __retire_engine_upto(request->engine, request);
+
advance_ring(request);
free_capture_list(request);
@@ -414,8 +414,6 @@ static void i915_request_retire(struct i915_request
*request)
atomic_dec_if_positive(>gem_context->ban_score);
intel_context_unpin(request->hw_context);
- __retire_engine_upto(request->engine, request);
-
unreserve_gt(request->i915);
i915_sched_node_fini(request->i915, >sched);
@@ -722,8 +720,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->timeline->fence_context,
timeline_get_seqno(rq->timeline));
- /* We bump the ref for the fence chain */
- i915_sw_fence_init(_request_get(rq)->submit, submit_notify);
+ /* We bump the ref for the fence chain and for the submit backend. */
+ refcount_set(>fence.refcount.refcount, 3);
+
+ i915_sw_fence_init(>submit, submit_notify);
init_waitqueue_head(>execute);
i915_sched_node_init(>sched);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index cce7234b9071..6fa2ef8862ce 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1035,11 +1035,11 @@ bool intel_engines_are_idle(struct drm_i915_private
*dev_priv)
* executed if the engine is already idle, is the kernel context
* (#i915.kernel_context).
*/
-bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine)
+bool intel_engine_has_kernel_context(struct intel_engine_cs *engine)
{
const struct intel_context *kernel_context =
to_intel_context(engine->i915->kernel_context, engine);
- struct i915_request *rq;
+ const struct intel_context *last;
lockdep_assert_held(>i915->drm.struct_mutex);
@@
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915: Be irqsafe inside reset (rev2)
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev2)
URL : https://patchwork.freedesktop.org/series/44041/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
df8d5c388e8c drm/i915: Be irqsafe inside reset
827a42f841af drm/i915/execlists: Reset the CSB head tracking on
reset/sanitization
-:41: WARNING:LONG_LINE: line over 100 characters
#41: FILE: drivers/gpu/drm/i915/intel_lrc.c:979:
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
total: 0 errors, 1 warnings, 0 checks, 42 lines checked
d75be47cd2c7 drm/i915/execlists: Pull submit after dequeue under timeline lock
089902205660 drm/i915/execlists: Pull CSB reset under the timeline.lock
bd7b385b52f6 drm/i915/execlists: Process one CSB interrupt at a time
-:35: WARNING:MEMORY_BARRIER: memory barrier without comment
#35: FILE: drivers/gpu/drm/i915/intel_lrc.c:966:
+ smp_mb__after_atomic();
-:77: WARNING:LONG_LINE: line over 100 characters
#77: FILE: drivers/gpu/drm/i915/intel_lrc.c:990:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:78: WARNING:LONG_LINE: line over 100 characters
#78: FILE: drivers/gpu/drm/i915/intel_lrc.c:991:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-:140: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#140: FILE: drivers/gpu/drm/i915/intel_lrc.c:1022:
+ status, buf[2*head + 1],
^
-:176: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#176: FILE: drivers/gpu/drm/i915/intel_lrc.c:1040:
+ buf[2*head + 1] == execlists->preempt_complete_status) {
^
total: 0 errors, 3 warnings, 2 checks, 301 lines checked
0c7415c81af2 drm/i915/execlists: Unify CSB access pointers
fc7a70b009e1 drm/i915/execlists: Direct submission of new requests (avoid
tasklet/ksoftirqd)
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
Comparing the impact on the maximum latency observed (that is the time stolen
-:102: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit 27af5eea54d1 ("drm/i915:
Move execlists irq handler to a bottom half")'
#102:
References: 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom
half")
total: 1 errors, 1 warnings, 0 checks, 359 lines checked
95590ea35f5d drm/i915: Move rate-limiting request retire to after submission
2f23f62da048 drm/i915: Wait for engines to idle before retiring
f9ddd078e8f5 drm/i915: Move engine request retirement to intel_engine_cs
f14b08071ab6 drm/i915: Hold request reference for submission until retirement
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/perf: fix context filtering with GuC & ICL
== Series Details == Series: drm/i915/perf: fix context filtering with GuC & ICL URL : https://patchwork.freedesktop.org/series/44043/ State : failure == Summary == Applying: drm/i915: drop one bit on the hw_id when using guc error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_drv.h). error: could not build fake ancestor Patch failed at 0001 drm/i915: drop one bit on the hw_id when using guc The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on average! Deferring our work to a tasklet allowed us to do the
processing with irqs enabled, reducing the impact to an average of about
50us.
We have since eradicated the use of forcewaked mmio from inside the CSB
processing and ELSP submission, bringing the impact down to around 5us
(on Kabylake); an order of magnitude better than our measurements 2
years ago on Broadwell and only about 2x worse on average than the
gem_syslatency on an unladen system.
In this iteration of the tasklet-vs-direct submission debate, we seek a
compromise where by we submit new requests immediately to the HW but
defer processing the CS interrupt onto a tasklet. We gain the advantage
of low-latency and ksoftirqd avoidance when waking up the HW, while
avoiding the system-wide starvation of our CS irq-storms.
Comparing the impact on the maximum latency observed (that is the time stolen
from an RT process) over a 120s interval, repeated several times (using
gem_syslatency, similar to RT's cyclictest) while the system is fully
laden with i915 nops, we see that direct submission an actually improve
the worse case.
Maximum latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 2)
x Always using tasklets (a couple of >1000us outliers removed)
+ Only using tasklets from CS irq, direct submission of requests
++
| + |
| + |
| + |
| + + |
| + + + |
| + + + + x x x |
| +++ + + + x x x x x x |
| +++ + ++ + + *x x x x x x |
| +++ + ++ + * *x x * x x x |
|+ +++ + ++ * * +*xxx * x x xx |
|* +++ + * *x+**xx+ * x x x |
| **x*++**+*x*xx+ * +x xx x x|
|x* **+***++*+***xx* xx*x xxx +x+|
| |__MA___| |
| |__M__A| |
++
N Min MaxMedian AvgStddev
x 11891 186 124 125.28814 16.279137
+ 12092 187 109 112.00833 13.458617
Difference at 95.0% confidence
-13.2798 +/- 3.79219
-10.5994% +/- 3.02677%
(Student's t, pooled s = 14.9237)
However the mean latency is adversely affected:
Mean latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 1)
x Always using tasklets
+ Only using tasklets from CS irq, direct submission of requests
++
| xx+ ++ |
| xx+ ++ |
| xx + +++ ++ |
| xxx + ++ |
| xxx + ++ |
| xxx + +++|
| xxx + ++ |
| ++ ++ |
| ++ ++ |
| xx+++ |
| xxxx +++ |
|x x x ++ ++ +|
| |__A__| |
| |A___||
++
N Min MaxMedian AvgStddev
x 120 3.506 3.727 3.631 3.63214170.02773109
+ 120 3.834 4.149 4.039 4.0375167 0.041221676
Difference at 95.0% confidence
0.405375 +/- 0.00888913
11.1608%
[Intel-gfx] [PATCH 0/2] drm/i915/perf: fix context filtering with GuC & ICL
Hi all, Here are a couple of fixes due to something that was overlooked on the context id in the OA reports. I assumed it was constructed by the OA unit but after discussion with HW people, the value turns out to be copied from the context descriptor. We had a test catching this in CI but only with GuC. Cheers, Lionel Landwerlin (2): drm/i915: drop one bit on the hw_id when using guc drm/i915/perf: fix ctx_id read with GuC & ICL drivers/gpu/drm/i915/i915_drv.h | 19 drivers/gpu/drm/i915/i915_gem_context.c | 7 +- drivers/gpu/drm/i915/i915_perf.c| 123 ++-- drivers/gpu/drm/i915/intel_lrc.c| 7 +- 4 files changed, 121 insertions(+), 35 deletions(-) -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/perf: fix ctx_id read with GuC & ICL
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches exactly the hw_id stored into the context descriptor.
When using GuC submission we have an issue of a non matching hw_id
because GuC uses bit 20 of the hw_id to signal proxy submission. This
change makes introduces a mask to compare only the relevant bits.
On ICL the context descriptor format has changed and we failed to
address this. On top of using a mask we also need to shift the bits
properly.
Signed-off-by: Lionel Landwerlin
Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104252
BSpec: 1237
Testcase: igt/perf/gen8-unprivileged-single-ctx-counters
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 123 ---
drivers/gpu/drm/i915/intel_lrc.c | 5 ++
3 files changed, 101 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 58ab9259fb73..0ccda488a8db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1953,6 +1953,7 @@ struct drm_i915_private {
struct intel_context *pinned_ctx;
u32 specific_ctx_id;
+ u32 specific_ctx_id_mask;
struct hrtimer poll_check_timer;
wait_queue_head_t poll_wq;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4a62024cbf85..d5e5d4635f1f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -738,12 +738,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
continue;
}
- /*
-* XXX: Just keep the lower 21 bits for now since I'm not
-* entirely sure if the HW touches any of the higher bits in
-* this field
-*/
- ctx_id = report32[2] & 0x1f;
+ ctx_id = report32[2] & dev_priv->perf.oa.specific_ctx_id_mask;
/*
* Squash whatever is in the CTX_ID field if it's marked as
@@ -1204,6 +1199,36 @@ static int i915_oa_read(struct i915_perf_stream *stream,
return dev_priv->perf.oa.ops.read(stream, buf, count, offset);
}
+static int oa_get_render_lrca(struct drm_i915_private *i915,
+ struct i915_gem_context *ctx,
+ u32 *lrca)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ struct intel_context *ce;
+ int ret;
+
+ ret = i915_mutex_lock_interruptible(>drm);
+ if (ret)
+ return ret;
+
+ /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*
+* NB: implied RCS engine...
+*/
+ ce = intel_context_pin(ctx, engine);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ i915->perf.oa.pinned_ctx = ce;
+
+ *lrca = i915_ggtt_offset(ce->state);
+
+ return 0;
+}
+
/**
* oa_get_render_ctx_id - determine and hold ctx hw id
* @stream: An i915-perf stream opened for OA metrics
@@ -1216,40 +1241,81 @@ static int i915_oa_read(struct i915_perf_stream *stream,
*/
static int oa_get_render_ctx_id(struct i915_perf_stream *stream)
{
- struct drm_i915_private *dev_priv = stream->dev_priv;
+ struct drm_i915_private *i915 = stream->dev_priv;
- if (HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
- dev_priv->perf.oa.specific_ctx_id = stream->ctx->hw_id;
- } else {
- struct intel_engine_cs *engine = dev_priv->engine[RCS];
- struct intel_context *ce;
+ switch (INTEL_GEN(i915)) {
+ case 7: {
int ret;
- ret = i915_mutex_lock_interruptible(_priv->drm);
+ ret = oa_get_render_lrca(i915, stream->ctx,
+>perf.oa.specific_ctx_id);
if (ret)
return ret;
/*
-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*
-* NB: implied RCS engine...
+* On Haswell we don't do any post processing of the reports
+* and don't need to use the mask.
*/
- ce = intel_context_pin(stream->ctx, engine);
- mutex_unlock(_priv->drm.struct_mutex);
- if (IS_ERR(ce))
- return PTR_ERR(ce);
+
[Intel-gfx] [PATCH 1/2] drm/i915: drop one bit on the hw_id when using guc
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should avoid allocating
the hw_id on that bit and restriction to bits [0:19] (i.e 20bits
instead of 21).
Signed-off-by: Lionel Landwerlin
BSpec: 1237
---
drivers/gpu/drm/i915/i915_drv.h | 18 ++
drivers/gpu/drm/i915/i915_gem_context.c | 7 +--
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64659d4efeda..58ab9259fb73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1841,6 +1841,7 @@ struct drm_i915_private {
*/
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define MAX_GUC_CONTEXT_HW_ID (1<<20) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
bool dynamic_sseu;
@@ -3262,6 +3263,23 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+static inline u32
+i915_gem_context_max_hw_id(struct drm_i915_private *i915)
+{
+ /* TODO: Confirm the max number on Gen11 with GuC */
+ if (INTEL_GEN(i915) >= 11)
+ return GEN11_MAX_CONTEXT_HW_ID;
+
+ /*
+* When using GuC in proxy submission, GuC consumes the highest bit in
+* the context id to indicate proxy submission.
+*/
+ if (USES_GUC_SUBMISSION(i915))
+ return MAX_GUC_CONTEXT_HW_ID;
+
+ return MAX_CONTEXT_HW_ID;
+}
+
int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
bool allowed);
bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ff08515d0c67..b686c04d98a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -205,13 +205,8 @@ static void context_close(struct i915_gem_context *ctx)
static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)
{
+ unsigned int max = i915_gem_context_max_hw_id(dev_priv);
int ret;
- unsigned int max;
-
- if (INTEL_GEN(dev_priv) >= 11)
- max = GEN11_MAX_CONTEXT_HW_ID;
- else
- max = MAX_CONTEXT_HW_ID;
ret = ida_simple_get(_priv->contexts.hw_ida,
0, max, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 26e43eb0ef31..94f9c4795190 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -200,7 +200,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
*
* bits 0-11:flags, GEN8_CTX_* (cached in ctx->desc_template)
* bits 12-31:LRCA, GTT address of (the HWSP of) this context
- * bits 32-52:ctx ID, a globally unique tag
+ * bits 32-52:ctx ID, a globally unique tag (highest bit used by GuC)
* bits 53-54:mbz, reserved for use by hardware
* bits 55-63:group ID, currently unused and set to 0
*
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/11] drm/i915: Be irqsafe inside reset
== Series Details == Series: series starting with [01/11] drm/i915: Be irqsafe inside reset URL : https://patchwork.freedesktop.org/series/44041/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9160 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9160 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9160, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44041/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9160: === IGT changes === Possible regressions igt@gem_render_tiled_blits@basic: fi-cfl-s3: PASS -> INCOMPLETE Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9160 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-plain-flip: fi-cnl-y3: PASS -> INCOMPLETE (fdo#105086, fdo#104962) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927) igt@prime_vgem@basic-fence-flip: fi-glk-j4005: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_chamelium@hdmi-hpd-fast: fi-kbl-7500u: FAIL (fdo#102672, fdo#103841) -> SKIP fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104962 https://bugs.freedesktop.org/show_bug.cgi?id=104962 fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086 == Participating hosts (42 -> 40) == Additional (1): fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4268 -> Patchwork_9160 CI_DRM_4268: 7138a144b0da03dcbe54731f7ac0dab6948beafb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4503: ae0ea2a0cff1cf8516d18ada5b9db01c56b73ed9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9160: d0aacc9e35bdcbfc2de3f612727fb5829cb6b5a2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d0aacc9e35bd drm/i915: Hold request reference for submission until retirement cda0eeead5d8 drm/i915: Move engine request retirement to intel_engine_cs 91807ea0b483 drm/i915: Wait for engines to idle before retiring 0e1792ea6ee9 drm/i915: Move rate-limiting request retire to after submission 3050c9d29fb3 drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) cedc7a7c2b86 drm/i915/execlists: Unify CSB access pointers ae196ee5aeae drm/i915/execlists: Process one CSB interrupt at a time a70428062fe9 drm/i915/execlists: Pull CSB reset under the timeline.lock f0a4fe328767 drm/i915/execlists: Pull submit after dequeue under timeline lock 14fd12cfeba8 drm/i915/execlists: Reset the CSB head tracking on reset/sanitization 1ba6410ddc51 drm/i915: Be irqsafe inside reset == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9160/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel 8/8] sna/video/sprite: Try disabling plane before giving up on colorkey
Quoting Chris Wilson (2018-05-31 10:30:13) > Quoting Ville Syrjala (2018-05-29 19:33:15) > > From: Ville Syrjälä > > > > When we're trying to reinstate the colorkey we might fail on account of > > the plane still being enable with a configuration that prevent the > > use of colorkey. This happens easily with NV12 since the plane scaler > > required by even unscaled NV12 is not compatible with colorkey. > > > > To work around the problem let's try disabling the plane first, then > > re-enable the colorkey, and finally we will try to re-enable the plane. > > The plane re-enable may fail, in which case we'll head to the GPU > > scaling fallback path. The cost is a flash of the colorkey when the > > plane blink off and then back on. > > > > Help me atomic ioctl, you're my only hope! > > > > Signed-off-by: Ville Syrjälä > > Though I glazed over at the asm patches, I concur that merely adding > further crud is the easiest way to add colorspace encoding support. The > rest of the patches looked fine, so the series is > > Reviewed-by: Chris Wilson > > Thanks, And pushed, double thanks. -Chris ___ 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/11] drm/i915: Be irqsafe inside reset
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset
URL : https://patchwork.freedesktop.org/series/44041/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1ba6410ddc51 drm/i915: Be irqsafe inside reset
14fd12cfeba8 drm/i915/execlists: Reset the CSB head tracking on
reset/sanitization
-:41: WARNING:LONG_LINE: line over 100 characters
#41: FILE: drivers/gpu/drm/i915/intel_lrc.c:979:
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
total: 0 errors, 1 warnings, 0 checks, 42 lines checked
f0a4fe328767 drm/i915/execlists: Pull submit after dequeue under timeline lock
a70428062fe9 drm/i915/execlists: Pull CSB reset under the timeline.lock
ae196ee5aeae drm/i915/execlists: Process one CSB interrupt at a time
-:35: WARNING:MEMORY_BARRIER: memory barrier without comment
#35: FILE: drivers/gpu/drm/i915/intel_lrc.c:966:
+ smp_mb__after_atomic();
-:77: WARNING:LONG_LINE: line over 100 characters
#77: FILE: drivers/gpu/drm/i915/intel_lrc.c:990:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
-:78: WARNING:LONG_LINE: line over 100 characters
#78: FILE: drivers/gpu/drm/i915/intel_lrc.c:991:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-:140: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#140: FILE: drivers/gpu/drm/i915/intel_lrc.c:1022:
+ status, buf[2*head + 1],
^
-:176: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#176: FILE: drivers/gpu/drm/i915/intel_lrc.c:1040:
+ buf[2*head + 1] == execlists->preempt_complete_status) {
^
total: 0 errors, 3 warnings, 2 checks, 301 lines checked
cedc7a7c2b86 drm/i915/execlists: Unify CSB access pointers
3050c9d29fb3 drm/i915/execlists: Direct submission of new requests (avoid
tasklet/ksoftirqd)
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
Comparing the impact on the maximum latency observed (that is the time stolen
-:100: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit 27af5eea54d1 ("drm/i915:
Move execlists irq handler to a bottom half")'
#100:
References: 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom
half")
total: 1 errors, 1 warnings, 0 checks, 358 lines checked
0e1792ea6ee9 drm/i915: Move rate-limiting request retire to after submission
91807ea0b483 drm/i915: Wait for engines to idle before retiring
cda0eeead5d8 drm/i915: Move engine request retirement to intel_engine_cs
d0aacc9e35bd drm/i915: Hold request reference for submission until retirement
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/11] drm/i915: Move rate-limiting request retire to after submission
Our long standing defense against a single client from flooding the
system with requests (causing mempressure and stalls across the whole
system) is to retire the old request on every allocation. (By retiring
the oldest, we try to keep returning requests back to the system in a
steady flow.) This adds an extra step into the submission path that we
can reduce simply by moving it to after the submission itself.
We already do try to clean up a stale request list after submission, so
always retiring all completed requests fits in as a natural extension.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f187250e60c6..796dad25e6ba 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -694,12 +694,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
if (ret)
goto err_unreserve;
- /* Move our oldest request to the slab-cache (if not in use!) */
- rq = list_first_entry(>ring->request_list, typeof(*rq), ring_link);
- if (!list_is_last(>ring_link, >ring->request_list) &&
- i915_request_completed(rq))
- i915_request_retire(rq);
-
/*
* Beware: Dragons be flying overhead.
*
@@ -1122,6 +1116,8 @@ void __i915_request_add(struct i915_request *request,
bool flush_caches)
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
/*
+* Move our oldest requests to the slab-cache (if not in use!)
+*
* In typical scenarios, we do not expect the previous request on
* the timeline to be still tracked by timeline->last_request if it
* has been completed. If the completed request is still here, that
@@ -1138,8 +1134,22 @@ void __i915_request_add(struct i915_request *request,
bool flush_caches)
* work on behalf of others -- but instead we should benefit from
* improved resource management. (Well, that's the theory at least.)
*/
- if (prev && i915_request_completed(prev))
- i915_request_retire_upto(prev);
+ do {
+ prev = list_first_entry(>request_list,
+ typeof(*prev), ring_link);
+
+ /*
+* Keep the current request, the caller may not be
+* expecting it to be retired (and freed!) immediately,
+* and preserving one request from the client allows us to
+* carry forward frequently reused state onto the next
+* submission.
+*/
+ if (prev == request || !i915_request_completed(prev))
+ break;
+
+ i915_request_retire(prev);
+ } while (1);
}
static unsigned long local_clock_us(unsigned int *cpu)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] drm/i915/execlists: Unify CSB access pointers
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce the CSB access inside the irq handler to a set of
read/write/buffer pointers and treat the various paths identically and
not worry about forcewake.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel_lrc.c| 116 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 23 +++--
3 files changed, 65 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 13448ea76f57..bc0193199a03 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,7 +25,6 @@
#include
#include "i915_drv.h"
-#include "i915_vgpu.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
@@ -456,21 +455,10 @@ static void intel_engine_init_batch_pool(struct
intel_engine_cs *engine)
i915_gem_batch_pool_init(>batch_pool, engine);
}
-static bool csb_force_mmio(struct drm_i915_private *i915)
-{
- /* Older GVT emulation depends upon intercepting CSB mmio */
- if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
- return true;
-
- return false;
-}
-
static void intel_engine_init_execlist(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
- execlists->csb_use_mmio = csb_force_mmio(engine->i915);
-
execlists->port_mask = 1;
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index df2b7005df65..7b36aa984304 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
#include
#include "i915_drv.h"
#include "i915_gem_render_state.h"
+#include "i915_vgpu.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_workarounds.h"
@@ -953,44 +954,23 @@ static void process_csb(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
- struct drm_i915_private *i915 = engine->i915;
-
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
- bool fw = false;
+ const u32 * const buf = execlists->csb_status;
+ u8 head, tail;
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_use_mmio)) {
- intel_uncore_forcewake_get(i915, execlists->fw_domains);
- fw = true;
-
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+ /* Note that csb_write, csb_status may be either in HWSP or mmio */
+ head = execlists->csb_head;
+ tail = READ_ONCE(*execlists->csb_write);
+ GEM_TRACE("%s cs-irq head=%d, tail=%d\n", engine->name, head, tail);
+ if (unlikely(head == tail))
+ return;
- head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ rmb(); /* Hopefully paired with a wmb() in HW */
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- engine->name,
- head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
-
- while (head != tail) {
+ do {
struct i915_request *rq;
unsigned int status;
unsigned int count;
@@ -1016,12 +996,12 @@ static void process_csb(struct intel_engine_cs *engine)
* status notifier.
*/
- status = READ_ONCE(buf[2 * head]); /* maybe mmio! */
GEM_TRACE("%s csb[%d]: status=0x%08x:0x%08x,
[Intel-gfx] [PATCH 03/11] drm/i915/execlists: Pull submit after dequeue under timeline lock
In the next patch, we will begin processing the CSB from inside the
interrupt handler. This means that updating the execlists->port[] will
no longer be locked by the tasklet but by the engine->timeline.lock
instead. Pull dequeue and submit under the same lock for protection.
(An alternative, future, plan is to keep the in/out arrays separate for
concurrent processing and reduced lock coverage.)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e5cf049c18f8..d207a1bf9dc9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -562,7 +562,7 @@ static void complete_preempt_context(struct
intel_engine_execlists *execlists)
execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
}
-static bool __execlists_dequeue(struct intel_engine_cs *engine)
+static void __execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
@@ -617,11 +617,11 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
* the HW to indicate that it has had a chance to respond.
*/
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_HWACK))
- return false;
+ return;
if (need_preempt(engine, last, execlists->queue_priority)) {
inject_preempt_context(engine);
- return false;
+ return;
}
/*
@@ -646,7 +646,7 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
* priorities of the ports haven't been switch.
*/
if (port_count([1]))
- return false;
+ return;
/*
* WaIdleLiteRestore:bdw,skl
@@ -746,8 +746,10 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
port != execlists->port ? rq_prio(last) : INT_MIN;
execlists->first = rb;
- if (submit)
+ if (submit) {
port_assign(port, last);
+ execlists_submit_ports(engine);
+ }
/* We must always keep the beast fed if we have work piled up */
GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
@@ -756,24 +758,19 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
if (last)
execlists_user_begin(execlists, execlists->port);
- return submit;
+ /* If the engine is now idle, so should be the flag; and vice versa. */
+ GEM_BUG_ON(execlists_is_active(>execlists,
+ EXECLISTS_ACTIVE_USER) ==
+ !port_isset(engine->execlists.port));
}
static void execlists_dequeue(struct intel_engine_cs *engine)
{
- struct intel_engine_execlists * const execlists = >execlists;
unsigned long flags;
- bool submit;
spin_lock_irqsave(>timeline.lock, flags);
- submit = __execlists_dequeue(engine);
+ __execlists_dequeue(engine);
spin_unlock_irqrestore(>timeline.lock, flags);
-
- if (submit)
- execlists_submit_ports(engine);
-
- GEM_BUG_ON(port_isset(execlists->port) &&
- !execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
}
void
@@ -1156,11 +1153,6 @@ static void execlists_submission_tasklet(unsigned long
data)
if (!execlists_is_active(>execlists, EXECLISTS_ACTIVE_PREEMPT))
execlists_dequeue(engine);
-
- /* If the engine is now idle, so should be the flag; and vice versa. */
- GEM_BUG_ON(execlists_is_active(>execlists,
- EXECLISTS_ACTIVE_USER) ==
- !port_isset(engine->execlists.port));
}
static void queue_request(struct intel_engine_cs *engine,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915: Move engine request retirement to intel_engine_cs
In the next patch, we will move ownership of the fence reference to the
submission backend and will want to drop its final reference when
retiring it from the submission backend. We will also need a catch up
when parking the engine to cleanup any residual entries in the engine
timeline. In short, move the engine retirement from i915_request.c to
intel_engine_cs.c for future use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 47 +
drivers/gpu/drm/i915/intel_engine_cs.c | 54 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
3 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 796dad25e6ba..f91942e4d852 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -344,50 +344,6 @@ static void free_capture_list(struct i915_request *request)
}
}
-static void __retire_engine_request(struct intel_engine_cs *engine,
- struct i915_request *rq)
-{
- GEM_TRACE("%s(%s) fence %llx:%d, global=%d, current %d\n",
- __func__, engine->name,
- rq->fence.context, rq->fence.seqno,
- rq->global_seqno,
- intel_engine_get_seqno(engine));
-
- GEM_BUG_ON(!i915_request_completed(rq));
-
- local_irq_disable();
-
- spin_lock(>timeline.lock);
- GEM_BUG_ON(!list_is_first(>link, >timeline.requests));
- list_del_init(>link);
- spin_unlock(>timeline.lock);
-
- spin_lock(>lock);
- if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
- dma_fence_signal_locked(>fence);
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
- intel_engine_cancel_signaling(rq);
- if (rq->waitboost) {
- GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters));
- atomic_dec(>i915->gt_pm.rps.num_waiters);
- }
- spin_unlock(>lock);
-
- local_irq_enable();
-
- /*
-* The backing object for the context is done after switching to the
-* *next* context. Therefore we cannot retire the previous context until
-* the next context has already started running. However, since we
-* cannot take the required locks at i915_request_submit() we
-* defer the unpinning of the active context to now, retirement of
-* the subsequent request.
-*/
- if (engine->last_retired_context)
- intel_context_unpin(engine->last_retired_context);
- engine->last_retired_context = rq->hw_context;
-}
-
static void __retire_engine_upto(struct intel_engine_cs *engine,
struct i915_request *rq)
{
@@ -400,8 +356,7 @@ static void __retire_engine_upto(struct intel_engine_cs
*engine,
tmp = list_first_entry(>timeline.requests,
typeof(*tmp), link);
- GEM_BUG_ON(tmp->engine != engine);
- __retire_engine_request(engine, tmp);
+ intel_engine_retire_request(engine, tmp);
} while (tmp != rq);
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 43880bf0f529..cce7234b9071 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1064,6 +1064,60 @@ void intel_engines_reset_default_submission(struct
drm_i915_private *i915)
engine->set_default_submission(engine);
}
+/**
+ * intel_engines_retire_request: drop the request reference from the engine
+ * @engine: the engine
+ * @rq: the request
+ *
+ * This request has been completed and is part of the chain being retired by
+ * the caller, so drop any reference to it from the engine.
+ */
+void intel_engine_retire_request(struct intel_engine_cs *engine,
+struct i915_request *rq)
+{
+ GEM_TRACE("%s(%s) fence %llx:%d, global=%d, current %d\n",
+ __func__, engine->name,
+ rq->fence.context, rq->fence.seqno,
+ rq->global_seqno,
+ intel_engine_get_seqno(engine));
+
+ lockdep_assert_held(>i915->drm.struct_mutex);
+ GEM_BUG_ON(rq->engine != engine);
+ GEM_BUG_ON(!i915_request_completed(rq));
+
+ local_irq_disable();
+
+ spin_lock(>timeline.lock);
+ GEM_BUG_ON(!list_is_first(>link, >timeline.requests));
+ list_del_init(>link);
+ spin_unlock(>timeline.lock);
+
+ spin_lock(>lock);
+ if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+ dma_fence_signal_locked(>fence);
+ if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+ intel_engine_cancel_signaling(rq);
+ if (rq->waitboost) {
+ GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters));
+
[Intel-gfx] [PATCH 01/11] drm/i915: Be irqsafe inside reset
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f5c4ef052001..550fa8288c45 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3142,15 +3142,17 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
*/
request = i915_gem_find_active_request(engine);
if (request) {
+ unsigned long flags;
+
i915_gem_context_mark_innocent(request->gem_context);
dma_fence_set_error(>fence, -EAGAIN);
/* Rewind the engine to replay the incomplete rq */
- spin_lock_irq(>timeline.lock);
+ spin_lock_irqsave(>timeline.lock, flags);
request = list_prev_entry(request, link);
if (>link == >timeline.requests)
request = NULL;
- spin_unlock_irq(>timeline.lock);
+ spin_unlock_irqrestore(>timeline.lock, flags);
}
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ksoftirqd avoidance
This is the same as the last posting, but hopefully now all the ground work is inplace that we get through CI cleanly (gem_eio is the bane of my existence). The goal of the patchset is to eliminate high latencies caused by execlists_submission_tasklet being deferred to ksoftirqd and scheduled as a normal task. This is achieved by writing to the ELSP directly from the process submitting the new work. From irq context, we continue to use the tasklet, so that we don't starve other users of the system, as here we expect to keep the hw supplied with a pair of contexts so that it has a request to work on as we queue the next, a slight delay in our processing of the irq should not result in a GPU stall. The consequence of rearranging the work to be split between different contexts is that we end up with even more under an irqsoff spinlock. To address this raise upon impact on the rest of the system (as well as worrying about contention between ourselves), we first make sure that we eliminate all unnecessary mmio and especially the forcewake. Later we apply some more microoptimisations -- that aren't so micro at the microsecond latency level! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915: Hold request reference for submission until retirement
Currently the async submission backends (guc and execlists) hold a extra
reference to the requests being processed as they are not serialised with
request retirement. If we instead, prevent the request being dropped
from the engine timeline until after submission has finished processing
the request, we can use a single reference held for the entire
submission process (currently, it is held only for the submission
fence).
By doing so we remove a few atomics from inside the irqoff path, on the
order of 200ns as measured by gem_syslatency, bringing the impact of
direct submission into line with the previous tasklet implementation.
The tradeoff is that as we may postpone the retirement, we have to check
for any residual requests after detecting that the engines are idle.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 20 -
drivers/gpu/drm/i915/intel_engine_cs.c | 24 -
drivers/gpu/drm/i915/intel_guc_submission.c | 4 +---
drivers/gpu/drm/i915/intel_lrc.c| 10 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
5 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f91942e4d852..2cfa6f3a2f16 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -347,17 +347,15 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_upto(struct intel_engine_cs *engine,
struct i915_request *rq)
{
+ struct list_head * const requests = >timeline.requests;
struct i915_request *tmp;
if (list_empty(>link))
return;
- do {
- tmp = list_first_entry(>timeline.requests,
- typeof(*tmp), link);
-
- intel_engine_retire_request(engine, tmp);
- } while (tmp != rq);
+ do
+ tmp = list_first_entry(requests, typeof(*tmp), link);
+ while (intel_engine_retire_request(engine, tmp) && tmp != rq);
}
static void i915_request_retire(struct i915_request *request)
@@ -376,6 +374,8 @@ static void i915_request_retire(struct i915_request
*request)
trace_i915_request_retire(request);
+ __retire_engine_upto(request->engine, request);
+
advance_ring(request);
free_capture_list(request);
@@ -414,8 +414,6 @@ static void i915_request_retire(struct i915_request
*request)
atomic_dec_if_positive(>gem_context->ban_score);
intel_context_unpin(request->hw_context);
- __retire_engine_upto(request->engine, request);
-
unreserve_gt(request->i915);
i915_sched_node_fini(request->i915, >sched);
@@ -722,8 +720,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->timeline->fence_context,
timeline_get_seqno(rq->timeline));
- /* We bump the ref for the fence chain */
- i915_sw_fence_init(_request_get(rq)->submit, submit_notify);
+ /* We bump the ref for the fence chain and for the submit backend. */
+ refcount_set(>fence.refcount.refcount, 3);
+
+ i915_sw_fence_init(>submit, submit_notify);
init_waitqueue_head(>execute);
i915_sched_node_init(>sched);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index cce7234b9071..b45d6aa7d29d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1071,8 +1071,10 @@ void intel_engines_reset_default_submission(struct
drm_i915_private *i915)
*
* This request has been completed and is part of the chain being retired by
* the caller, so drop any reference to it from the engine.
+ *
+ * Returns: true if the reference was dropped, false if it was still busy.
*/
-void intel_engine_retire_request(struct intel_engine_cs *engine,
+bool intel_engine_retire_request(struct intel_engine_cs *engine,
struct i915_request *rq)
{
GEM_TRACE("%s(%s) fence %llx:%d, global=%d, current %d\n",
@@ -1085,6 +1087,10 @@ void intel_engine_retire_request(struct intel_engine_cs
*engine,
GEM_BUG_ON(rq->engine != engine);
GEM_BUG_ON(!i915_request_completed(rq));
+ /* Don't drop the final ref until after the backend has finished */
+ if (port_request(engine->execlists.port) == rq)
+ return false;
+
local_irq_disable();
spin_lock(>timeline.lock);
@@ -1116,6 +1122,19 @@ void intel_engine_retire_request(struct intel_engine_cs
*engine,
if (engine->last_retired_context)
intel_context_unpin(engine->last_retired_context);
engine->last_retired_context = rq->hw_context;
+
+ i915_request_put(rq);
+ return true;
+}
+
+static void engine_retire_requests(struct
[Intel-gfx] [PATCH 09/11] drm/i915: Wait for engines to idle before retiring
In the next patch, we will start to defer retiring the request from the
engine list if it is still active on the submission backend. To preserve
the semantics that after wait-for-idle completes the system is idle and
fully retired, we need to therefore wait for the backends to idle before
calling i915_retire_requests().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 550fa8288c45..3e442c3094e7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3768,10 +3768,13 @@ int i915_gem_wait_for_idle(struct drm_i915_private
*i915, unsigned int flags)
if (err)
return err;
}
+
+ err = wait_for_engines(i915);
+ if (err)
+ return err;
+
i915_retire_requests(i915);
GEM_BUG_ON(i915->gt.active_requests);
-
- return wait_for_engines(i915);
} else {
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -3782,9 +3785,9 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915,
unsigned int flags)
if (err)
return err;
}
-
- return 0;
}
+
+ return 0;
}
static void __i915_gem_object_flush_for_display(struct drm_i915_gem_object
*obj)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm/i915/execlists: Reset the CSB head tracking on reset/sanitization
We can avoid the mmio read of the CSB pointers after reset based on the
knowledge that the HW always start writing at entry 0 in the CSB buffer.
We need to reset our CSB head tracking after GPU reset (and on
sanitization after resume) so that we are expecting to read from entry
0.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 517e92c6a70b..e5cf049c18f8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -965,22 +965,19 @@ static void process_csb(struct intel_engine_cs *engine)
>status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
unsigned int head, tail;
- if (unlikely(execlists->csb_use_mmio)) {
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
- execlists->csb_head = -1; /* force mmio read of CSB */
- }
-
/* Clear before reading to catch new interrupts */
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
smp_mb__after_atomic();
- if (unlikely(execlists->csb_head == -1)) { /* after a reset */
+ if (unlikely(execlists->csb_use_mmio)) {
if (!fw) {
intel_uncore_forcewake_get(i915,
execlists->fw_domains);
fw = true;
}
+ buf = (u32 * __force)
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+
head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
@@ -1959,7 +1956,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
spin_unlock(>timeline.lock);
/* Following the reset, we need to reload the CSB read/write pointers */
- engine->execlists.csb_head = -1;
+ engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
local_irq_restore(flags);
@@ -2460,7 +2457,7 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
upper_32_bits(ce->lrc_desc);
}
- engine->execlists.csb_head = -1;
+ engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
return 0;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on average! Deferring our work to a tasklet allowed us to do the
processing with irqs enabled, reducing the impact to an average of about
50us.
We have since eradicated the use of forcewaked mmio from inside the CSB
processing and ELSP submission, bringing the impact down to around 5us
(on Kabylake); an order of magnitude better than our measurements 2
years ago on Broadwell and only about 2x worse on average than the
gem_syslatency on an unladen system.
In this iteration of the tasklet-vs-direct submission debate, we seek a
compromise where by we submit new requests immediately to the HW but
defer processing the CS interrupt onto a tasklet. We gain the advantage
of low-latency and ksoftirqd avoidance when waking up the HW, while
avoiding the system-wide starvation of our CS irq-storms.
Comparing the impact on the maximum latency observed (that is the time stolen
from an RT process) over a 120s interval, repeated several times (using
gem_syslatency, similar to RT's cyclictest) while the system is fully
laden with i915 nops, we see that direct submission an actually improve
the worse case.
Maximum latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 2)
x Always using tasklets (a couple of >1000us outliers removed)
+ Only using tasklets from CS irq, direct submission of requests
++
| + |
| + |
| + |
| + + |
| + + + |
| + + + + x x x |
| +++ + + + x x x x x x |
| +++ + ++ + + *x x x x x x |
| +++ + ++ + * *x x * x x x |
|+ +++ + ++ * * +*xxx * x x xx |
|* +++ + * *x+**xx+ * x x x |
| **x*++**+*x*xx+ * +x xx x x|
|x* **+***++*+***xx* xx*x xxx +x+|
| |__MA___| |
| |__M__A| |
++
N Min MaxMedian AvgStddev
x 11891 186 124 125.28814 16.279137
+ 12092 187 109 112.00833 13.458617
Difference at 95.0% confidence
-13.2798 +/- 3.79219
-10.5994% +/- 3.02677%
(Student's t, pooled s = 14.9237)
However the mean latency is adversely affected:
Mean latency in microseconds of a third party RT thread
(gem_syslatency -t 120 -f 1)
x Always using tasklets
+ Only using tasklets from CS irq, direct submission of requests
++
| xx+ ++ |
| xx+ ++ |
| xx + +++ ++ |
| xxx + ++ |
| xxx + ++ |
| xxx + +++|
| xxx + ++ |
| ++ ++ |
| ++ ++ |
| xx+++ |
| xxxx +++ |
|x x x ++ ++ +|
| |__A__| |
| |A___||
++
N Min MaxMedian AvgStddev
x 120 3.506 3.727 3.631 3.63214170.02773109
+ 120 3.834 4.149 4.039 4.0375167 0.041221676
Difference at 95.0% confidence
0.405375 +/- 0.00888913
11.1608%
[Intel-gfx] [PATCH 04/11] drm/i915/execlists: Pull CSB reset under the timeline.lock
In the following patch, we will process the CSB interrupt under the timeline.lock and not under the tasklet lock. This also means that we will need to protect access to common variables such as execlists->csb_head with the timeline.lock during reset. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index d207a1bf9dc9..ec54c29b610f 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1927,8 +1927,7 @@ static void execlists_reset(struct intel_engine_cs *engine, engine->name, request ? request->global_seqno : 0, intel_engine_get_seqno(engine)); - /* See execlists_cancel_requests() for the irq/spinlock split. */ - local_irq_save(flags); + spin_lock_irqsave(>timeline.lock, flags); /* * Catch up with any missed context-switch interrupts. @@ -1943,14 +1942,12 @@ static void execlists_reset(struct intel_engine_cs *engine, reset_irq(engine); /* Push back any incomplete requests for replay after the reset. */ - spin_lock(>timeline.lock); __unwind_incomplete_requests(engine); - spin_unlock(>timeline.lock); /* Following the reset, we need to reload the CSB read/write pointers */ engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1; - local_irq_restore(flags); + spin_unlock_irqrestore(>timeline.lock, flags); /* * If the request was innocent, we leave the request in the ELSP -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] drm/i915/execlists: Process one CSB interrupt at a time
In the next patch, we will process the CSB events directly from the CS
interrupt handler, being called for each interrupt. Hence, we will no
longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 274 +++
1 file changed, 135 insertions(+), 139 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ec54c29b610f..df2b7005df65 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -954,166 +954,162 @@ static void process_csb(struct intel_engine_cs *engine)
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port *port = execlists->port;
struct drm_i915_private *i915 = engine->i915;
+
+ /* The HWSP contains a (cacheable) mirror of the CSB */
+ const u32 *buf =
+ >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
+ unsigned int head, tail;
bool fw = false;
- do {
- /* The HWSP contains a (cacheable) mirror of the CSB */
- const u32 *buf =
- >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
- unsigned int head, tail;
+ /* Clear before reading to catch new interrupts */
+ clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+ smp_mb__after_atomic();
- /* Clear before reading to catch new interrupts */
- clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
- smp_mb__after_atomic();
+ if (unlikely(execlists->csb_use_mmio)) {
+ intel_uncore_forcewake_get(i915, execlists->fw_domains);
+ fw = true;
- if (unlikely(execlists->csb_use_mmio)) {
- if (!fw) {
- intel_uncore_forcewake_get(i915,
execlists->fw_domains);
- fw = true;
- }
+ buf = (u32 * __force)
+ (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
- buf = (u32 * __force)
- (i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+ head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+ tail = GEN8_CSB_WRITE_PTR(head);
+ head = GEN8_CSB_READ_PTR(head);
+ execlists->csb_head = head;
+ } else {
+ const int write_idx =
+ intel_hws_csb_write_index(i915) -
+ I915_HWS_CSB_BUF0_INDEX;
- head = readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
- tail = GEN8_CSB_WRITE_PTR(head);
- head = GEN8_CSB_READ_PTR(head);
- execlists->csb_head = head;
- } else {
- const int write_idx =
- intel_hws_csb_write_index(i915) -
- I915_HWS_CSB_BUF0_INDEX;
+ head = execlists->csb_head;
+ tail = READ_ONCE(buf[write_idx]);
+ rmb(); /* Hopefully paired with a wmb() in HW */
+ }
+ GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
+ engine->name,
+ head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
- head = execlists->csb_head;
- tail = READ_ONCE(buf[write_idx]);
- rmb(); /* Hopefully paired with a wmb() in HW */
- }
- GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
- engine->name,
- head, GEN8_CSB_READ_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
- tail, GEN8_CSB_WRITE_PTR(readl(i915->regs +
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
+ while (head != tail) {
+ struct i915_request *rq;
+ unsigned int status;
+ unsigned int count;
- while (head != tail) {
- struct i915_request *rq;
- unsigned int status;
- unsigned int count;
+ if (++head == GEN8_CSB_ENTRIES)
+ head = 0;
- if (++head == GEN8_CSB_ENTRIES)
- head = 0;
+ /*
+* We are flying near dragons again.
+*
+* We hold a reference to the
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Switch to kernel context before idling at runtime
Quoting Patchwork (2018-05-31 11:04:13) > igt@gem_eio@suspend: > shard-snb: PASS -> INCOMPLETE (fdo#105411) +1 I was concerned by this since gem_eio targets the code being changed. In particular, I was concerned that this was bringing back the snb gem_eio nightmare (where we would take out the machine). However, running locally and looking at the previous CI results doesn't show that this is a persistent problem, so I think this failure was a fluke. That isn't to say that there isn't something weird happening on snb, but I don't think it's any weirder than normal. Thank you all for the reviews, let's just hope we don't have to stare at suspend again for a few weeks^W days. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
Quoting Chris Wilson (2018-05-31 19:13:32) > Quoting Michal Wajdeczko (2018-05-28 18:16:18) > > SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and > > those events are now handled by intel_guc_to_host_event_handler_mmio(). > > > > We should not try to read it on MMIO action error as 1) we may be using > > different set of registers for GuC MMIO communication, and 2) GuC may > > use CTB mechanism for sending events to host. > > > > While here, upgrade error message to DRM_ERROR. > > > > Signed-off-by: Michal Wajdeczko > > Cc: Michel Thierry > > Cc: Joonas Lahtinen > > Cc: Chris Wilson > > I'm still not totally sold on having the DRM_ERROR here improves > debugging; it doesn't do anything to improve error handling, but > > Reviewed-by: Chris Wilson > > nevertheless. And pushed. Thank you for the patch, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
Quoting Michal Wajdeczko (2018-05-28 18:16:18) > SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and > those events are now handled by intel_guc_to_host_event_handler_mmio(). > > We should not try to read it on MMIO action error as 1) we may be using > different set of registers for GuC MMIO communication, and 2) GuC may > use CTB mechanism for sending events to host. > > While here, upgrade error message to DRM_ERROR. > > Signed-off-by: Michal Wajdeczko > Cc: Michel Thierry > Cc: Joonas Lahtinen > Cc: Chris Wilson I'm still not totally sold on having the DRM_ERROR here improves debugging; it doesn't do anything to improve error handling, but Reviewed-by: Chris Wilson nevertheless. -Chris ___ 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 [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
== Series Details == Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems URL : https://patchwork.freedesktop.org/series/44023/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4265_full -> Patchwork_9158_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9158_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9158_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44023/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9158_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP +1 igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_9158_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_flip@2x-plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: INCOMPLETE (fdo#103665) -> PASS shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> PASS igt@gem_tiled_blits@interruptible: shard-glk: FAIL -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 igt@kms_flip@2x-modeset-vs-vblank-race: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt: shard-glk: FAIL (fdo#104724, fdo#103167) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4265 -> Patchwork_9158 CI_DRM_4265: 1bef5a8b1f02a5a612ac38bc6d7950becc2a9aa8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4502: 63f0bf3d50b70f011b9d600a1a4bc1a1c7720654 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9158: c90e187ee0ec334c3b084706abe2d2dcd4eefb89 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9158/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/gem_tiled_blits: Show more errors
glk is failing gem_tiled_blits which is very odd as it doesn't use
fencing and so the tiling is all internal to the GPU. From the small
number of examples seen so far, it looks like just a single bit is being
flipped. Let's dump some values to see if it there is a larger pattern
here.
Furthermore since gem_linear_blits is also showing bitflips on glk, we
can rule out the impact of tiling altogether! It just becomes a question
of which piece of hw is broken...
References: https://bugs.freedesktop.org/show_bug.cgi?id=106608
Signed-off-by: Chris Wilson
---
tests/gem_linear_blits.c | 11 +++
tests/gem_tiled_blits.c | 14 --
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/tests/gem_linear_blits.c b/tests/gem_linear_blits.c
index 7d05fa865..8a8d2a6cc 100644
--- a/tests/gem_linear_blits.c
+++ b/tests/gem_linear_blits.c
@@ -141,16 +141,19 @@ create_bo(int fd, uint32_t val)
static void
check_bo(int fd, uint32_t handle, uint32_t val)
{
+ int num_errors;
int i;
gem_read(fd, handle, 0, linear, sizeof(linear));
+
+ num_errors = 0;
for (i = 0; i < WIDTH*HEIGHT; i++) {
- igt_assert_f(linear[i] == val,
-"Expected 0x%08x, found 0x%08x "
-"at offset 0x%08x\n",
-val, linear[i], i * 4);
+ if (linear[i] != val && num_errors++ < 32)
+ igt_warn("[%08x] Expected 0x%08x, found 0x%08x
(difference 0x%08x)\n",
+i * 4, val, linear[i], val ^ linear[i]);
val++;
}
+ igt_assert_eq(num_errors, 0);
}
static void run_test(int fd, int count)
diff --git a/tests/gem_tiled_blits.c b/tests/gem_tiled_blits.c
index 0d472e3a1..26cd900b7 100644
--- a/tests/gem_tiled_blits.c
+++ b/tests/gem_tiled_blits.c
@@ -90,10 +90,11 @@ create_bo(uint32_t start_val)
}
static void
-check_bo(drm_intel_bo *bo, uint32_t start_val)
+check_bo(drm_intel_bo *bo, uint32_t val)
{
drm_intel_bo *linear_bo;
uint32_t *linear;
+ int num_errors;
int i;
linear_bo = drm_intel_bo_alloc(bufmgr, "linear dst", 1024 * 1024, 4096);
@@ -103,13 +104,14 @@ check_bo(drm_intel_bo *bo, uint32_t start_val)
do_or_die(drm_intel_bo_map(linear_bo, 0));
linear = linear_bo->virtual;
+ num_errors = 0;
for (i = 0; i < 1024 * 1024 / 4; i++) {
- igt_assert_f(linear[i] == start_val,
-"Expected 0x%08x, found 0x%08x "
-"at offset 0x%08x\n",
-start_val, linear[i], i * 4);
- start_val++;
+ if (linear[i] != val && num_errors++ < 32)
+ igt_warn("[%08x] Expected 0x%08x, found 0x%08x
(difference 0x%08x)\n",
+i * 4, val, linear[i], val ^ linear[i]);
+ val++;
}
+ igt_assert_eq(num_errors, 0);
drm_intel_bo_unmap(linear_bo);
drm_intel_bo_unreference(linear_bo);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/3] lib: Double check ring measurement
Quoting Antonio Argenziano (2018-05-30 18:42:28) > > > On 30/05/18 03:33, Chris Wilson wrote: > > Check twice for the signal interrupting the execbuf, because the real > > world is messy. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=106695 > > Signed-off-by: Chris Wilson > > Cc: Antonio Argenziano > > LGTM. > > Reviewed-by: Antonio Argenziano Picked up to sweep the bug under the carpet hopefully never to be heard off again. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: fix PCH_NOP setting for non-PCH platforms
On Thu, May 31, 2018 at 02:56:24PM +0300, Jani Nikula wrote:
> Setting PCH type to PCH_NOP before checking whether we actually have a
> PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
> platforms. Fix this by using PCH_NOP only for platforms that actually
> have a PCH.
>
> Cc: Ville Syrjala
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1842a067a604..5deee698881b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -246,14 +246,6 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> {
> struct pci_dev *pch = NULL;
>
> - /* In all current cases, num_pipes is equivalent to the PCH_NOP setting
> - * (which really amounts to a PCH but no South Display).
> - */
> - if (INTEL_INFO(dev_priv)->num_pipes == 0) {
> - dev_priv->pch_type = PCH_NOP;
> - return;
> - }
> -
> /*
>* The reason to probe ISA bridge instead of Dev31:Fun0 is to
>* make graphics device passthrough work easy for VMM, that only
> @@ -293,6 +285,17 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> break;
> }
> }
> +
> + /*
> + * Use PCH_NOP (PCH but no South Display) for PCH platforms without
Like I said on patch 1 I'd rather document in the enum what it is and
here just a "Use PCH_NOP for PCH platforms without display"
Lucas De Marchi
> + * display.
> + */
> + if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
> + DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
> + dev_priv->pch_type = PCH_NOP;
> + dev_priv->pch_id = 0;
> + }
> +
> if (!pch)
> DRM_DEBUG_KMS("No PCH found.\n");
>
> --
> 2.11.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] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems (rev2)
== Series Details == Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems (rev2) URL : https://patchwork.freedesktop.org/series/44023/ State : failure == Summary == Applying: drm/i915: fix guest virtual PCH detection on non-PCH systems Applying: drm/i915: clean up virtual PCH special case handling error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_drv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.c Patch failed at 0002 drm/i915: clean up virtual PCH special case handling The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote:
> Virtualized non-PCH systems such as Broxton or Geminilake should use
> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
> specific case to indicate a PCH system without south display.
Then let's go ahead and document it?
-
Subject: [PATCH] drm/i915: document PCH_NOP
There's a difference between PCH_NONE and PCH_NOP: the former means we
don't have a PCH while in the latter we do, but it doesn't have the
south display.
Cc: Jani Nikula
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72150f89f200..aa395a898258 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -631,7 +631,7 @@ enum intel_pch {
PCH_KBP,/* Kaby Lake PCH */
PCH_CNP,/* Cannon Lake PCH */
PCH_ICP,/* Ice Lake PCH */
- PCH_NOP,
+ PCH_NOP,/* PCH without south display */
};
enum intel_sbi_destination {
--
Feel free to squash something like that if you agree.
Lucas De Marchi
>
> Reported-by: Colin Xu
> Cc: Colin Xu
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8f002ae22e62..c42e389a27f3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -287,7 +287,7 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> if (WARN_ON(pch_type == PCH_NONE))
> pch_type = PCH_NOP;
> } else {
> - pch_type = PCH_NOP;
> + pch_type = PCH_NONE;
> }
> dev_priv->pch_type = pch_type;
> dev_priv->pch_id = id;
> --
> 2.11.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] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
== Series Details == Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems URL : https://patchwork.freedesktop.org/series/44023/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4265 -> Patchwork_9158 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9158 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9158, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44023/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9158: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9158 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-skl-6700k2: PASS -> FAIL (fdo#103191, fdo#104724) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_mmap_gtt@basic-read-write-distinct: fi-glk-j4005: DMESG-WARN (fdo#106745, fdo#106000) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106745 https://bugs.freedesktop.org/show_bug.cgi?id=106745 == Participating hosts (43 -> 40) == Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4265 -> Patchwork_9158 CI_DRM_4265: 1bef5a8b1f02a5a612ac38bc6d7950becc2a9aa8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4502: 63f0bf3d50b70f011b9d600a1a4bc1a1c7720654 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9158: c90e187ee0ec334c3b084706abe2d2dcd4eefb89 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c90e187ee0ec drm/i915: fix PCH_NOP setting for non-PCH platforms 43bae6f1935e drm/i915: be more strict about HAS_PCH_NOP() usage 46ccb38e6b56 drm/i915: clean up virtual PCH special case handling 42d7eee0bf47 drm/i915: fix guest virtual PCH detection on non-PCH systems == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9158/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Only sanitize GEM from late suspend
On 31/05/2018 09:22, Chris Wilson wrote:
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume cycle, we have to assume the device has
been reset to its defaults. A simple way around this is to skip the
sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 22 +-
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8f002ae22e62..0d9b8cc0436d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -636,6 +636,8 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static void i915_gem_fini(struct drm_i915_private *dev_priv)
{
+ i915_gem_suspend_late(dev_priv);
+
/* Flush any outstanding unpin_work. */
i915_gem_drain_workqueue(dev_priv);
@@ -1611,7 +1613,6 @@ static int i915_drm_suspend(struct drm_device *dev)
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
intel_opregion_notify_adapter(dev_priv, opregion_target_state);
- intel_uncore_suspend(dev_priv);
intel_opregion_unregister(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
@@ -1633,7 +1634,10 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
disable_rpm_wakeref_asserts(dev_priv);
+ i915_gem_suspend_late(dev_priv);
+
intel_display_set_init_power(dev_priv, false);
+ intel_uncore_suspend(dev_priv);
/*
* In case of firmware assisted context save/restore don't manually
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 32a65de7222d..38157df6ff5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3169,6 +3169,7 @@ void i915_gem_cleanup_engines(struct drm_i915_private
*dev_priv);
int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
unsigned int flags);
int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
+void i915_gem_suspend_late(struct drm_i915_private *dev_priv);
void i915_gem_resume(struct drm_i915_private *dev_priv);
int i915_gem_fault(struct vm_fault *vmf);
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9b8fa1866cc9..f5c4ef052001 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5055,6 +5055,17 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
if (WARN_ON(!intel_engines_are_idle(dev_priv)))
i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
+ intel_runtime_pm_put(dev_priv);
+ return 0;
+
+err_unlock:
+ mutex_unlock(>struct_mutex);
+ intel_runtime_pm_put(dev_priv);
+ return ret;
+}
+
+void i915_gem_suspend_late(struct drm_i915_private *i915)
+{
/*
* Neither the BIOS, ourselves or any other kernel
* expects the system to be in execlists mode on startup,
@@ -5074,16 +5085,9 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
* machines is a good idea, we don't - just in case it leaves the
* machine in an unusable condition.
*/
- intel_uc_sanitize(dev_priv);
- i915_gem_sanitize(dev_priv);
- intel_runtime_pm_put(dev_priv);
- return 0;
-
-err_unlock:
- mutex_unlock(>struct_mutex);
- intel_runtime_pm_put(dev_priv);
- return ret;
+ intel_uc_sanitize(i915);
+ i915_gem_sanitize(i915);
}
void i915_gem_resume(struct drm_i915_private *i915)
It's hackery for PM core not suspending devices fully in device test
mode, but I have no better ideas, nor can I figure out why PM core does
it like that:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
Quoting Matthew Auld (2018-05-31 15:43:14) > On 31 May 2018 at 12:35, Chris Wilson wrote: > > From: Jon Bloomfield > > > > We can set a bit inside the ppGTT PTE to indicate a page is read-only; > > writes from the GPU will be discarded. We can use this to protect pages > > and in particular support read-only userptr mappings (necessary for > > importing PROT_READ vma). > > > > Signed-off-by: Jon Bloomfield > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Cc: Matthew Auld > > Reviewed-by: Joonas Lahtinen > > fwiw I didn't see any surprises with ro 2M/64K PTEs when testing locally. > > For the series: > Reviewed-by: Matthew Auld I think I'd like to see a selftest also exercising the ro nature before pushing. Thanks for the review, stick around there'll be another patch to come :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/3] lib: Align ring measurement to timer
Quoting Antonio Argenziano (2018-05-31 15:42:03) > > > On 30/05/18 12:52, Chris Wilson wrote: > > Quoting Antonio Argenziano (2018-05-30 18:30:36) > >> > >> > >> On 30/05/18 03:33, Chris Wilson wrote: > >>> After hitting the SIGINT from execbuf, wait until the next timer signal > >>> before trying again. This aligns the start of the ioctl to the timer, > >>> hopefully maximising the amount of time we have for processing before > >>> the next signal -- trying to prevent the case where we are scheduled out > >>> in the middle of processing and so hit the timer signal too early. > >>> > >>> References: https://bugs.freedesktop.org/show_bug.cgi?id=106695 > >>> Signed-off-by: Chris Wilson > >> > >> Not sure I understand what is the sequence of events, is the problem we > >> get a signal in the middle of a 'good' execbuf and exit the while loop > >> prematurely? If so maybe we can also think of making the timer 'VIRTUAL' > >> so that it would decrement only when the process is executing. > > > > If it's VIRTUAL it'll never fire when we wait for space (as being asleep > > no user/sys time is consumed). > > > > The only way I can explain 106695 would be with some very strange > > scheduler behaviour, but even then it requires us to hit a path where we > > actually check for a pending signal -- which should only happen when we > > run out of ring space for this setup. Not even the device being wedged > > (which it wasn't) would cause the ring to drain. Possibly going over 10s > > and the cork being unplugged? Very stange. > > Just a bit concerned that we might be covering up some weird corner case > where we are sleeping where we shouldn't. The bugs are exactly the opposite, where there's a signal pending and we ignore it ;) And ignore them we do. If one day someone cares signal latency, we have a lot of explaining to do... It's just worrying because the only signal_pending() check we expect to hit is in wait-for-space (i915_request_wait to be precise); and that should be consistent between calls to execbuf. However, it's not meant to be a defining test of user behaviour, just exploiting the limitation of the implementation to report said limitation. All that we must do is to be sure that we don't over-report or else the callers will hang during their setup and fail. Under reporting is a nuisance, but not a huge issue. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
On 31 May 2018 at 12:35, Chris Wilson wrote: > From: Jon Bloomfield > > We can set a bit inside the ppGTT PTE to indicate a page is read-only; > writes from the GPU will be discarded. We can use this to protect pages > and in particular support read-only userptr mappings (necessary for > importing PROT_READ vma). > > Signed-off-by: Jon Bloomfield > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Matthew Auld > Reviewed-by: Joonas Lahtinen fwiw I didn't see any surprises with ro 2M/64K PTEs when testing locally. For the series: Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/3] lib: Align ring measurement to timer
On 30/05/18 12:52, Chris Wilson wrote: Quoting Antonio Argenziano (2018-05-30 18:30:36) On 30/05/18 03:33, Chris Wilson wrote: After hitting the SIGINT from execbuf, wait until the next timer signal before trying again. This aligns the start of the ioctl to the timer, hopefully maximising the amount of time we have for processing before the next signal -- trying to prevent the case where we are scheduled out in the middle of processing and so hit the timer signal too early. References: https://bugs.freedesktop.org/show_bug.cgi?id=106695 Signed-off-by: Chris Wilson Not sure I understand what is the sequence of events, is the problem we get a signal in the middle of a 'good' execbuf and exit the while loop prematurely? If so maybe we can also think of making the timer 'VIRTUAL' so that it would decrement only when the process is executing. If it's VIRTUAL it'll never fire when we wait for space (as being asleep no user/sys time is consumed). The only way I can explain 106695 would be with some very strange scheduler behaviour, but even then it requires us to hit a path where we actually check for a pending signal -- which should only happen when we run out of ring space for this setup. Not even the device being wedged (which it wasn't) would cause the ring to drain. Possibly going over 10s and the cork being unplugged? Very stange. Just a bit concerned that we might be covering up some weird corner case where we are sleeping where we shouldn't. But the patch does what advertised and seems sensible so: Acked-by: Antonio Argenziano --- lib/i915/gem_ring.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/i915/gem_ring.c b/lib/i915/gem_ring.c index 7d64165eb..0c061000c 100644 --- a/lib/i915/gem_ring.c +++ b/lib/i915/gem_ring.c @@ -96,6 +96,8 @@ __gem_measure_ring_inflight(int fd, unsigned int engine, enum measure_ring_flags if (last == count) break; + /* sleep until the next timer interrupt (woken on signal) */ + pause(); Does it cause any (sensible) slowdown? Adds at most one timer interval, 10us. Ok, at a push 2 timer intervals if it takes longer than first to setup the sleep. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: After reset on sanitization, reset the engine backends
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-20180530]
[cannot apply to v4.17-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Remove-stale-asserts-from-i915_gem_find_active_request/20180531-202540
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x006-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu//drm/i915/i915_gem.c:28:
drivers/gpu//drm/i915/i915_gem.c: In function 'i915_gem_sanitize':
drivers/gpu//drm/i915/i915_gem.c:5035:15: error: 'struct intel_engine_cs'
has no member named 'reset'; did you mean 'reset_hw'?
if (engine->reset.reset)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/i915/i915_gem.c:5035:3: note: in expansion of macro 'if'
if (engine->reset.reset)
^~
drivers/gpu//drm/i915/i915_gem.c:5035:15: error: 'struct intel_engine_cs'
has no member named 'reset'; did you mean 'reset_hw'?
if (engine->reset.reset)
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/i915/i915_gem.c:5035:3: note: in expansion of macro 'if'
if (engine->reset.reset)
^~
drivers/gpu//drm/i915/i915_gem.c:5035:15: error: 'struct intel_engine_cs'
has no member named 'reset'; did you mean 'reset_hw'?
if (engine->reset.reset)
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
>> drivers/gpu//drm/i915/i915_gem.c:5035:3: note: in expansion of macro 'if'
if (engine->reset.reset)
^~
drivers/gpu//drm/i915/i915_gem.c:5036:12: error: 'struct intel_engine_cs'
has no member named 'reset'; did you mean 'reset_hw'?
engine->reset.reset(engine, NULL);
^
reset_hw
vim +/if +5035 drivers/gpu//drm/i915/i915_gem.c
5000
5001 void i915_gem_sanitize(struct drm_i915_private *i915)
5002 {
5003 struct intel_engine_cs *engine;
5004 enum intel_engine_id id;
5005
5006 GEM_TRACE("\n");
5007
5008 mutex_lock(>drm.struct_mutex);
5009
5010 intel_runtime_pm_get(i915);
5011 intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
5012
5013 /*
5014 * As we have just resumed the machine and woken the device up
from
5015 * deep PCI sleep (presumably D3_cold), assume the HW has been
reset
5016 * back to defaults, recovering from whatever wedged state we
left it
5017 * in and so worth trying to use the device once more.
5018 */
5019 if (i915_terminally_wedged(>gpu_error))
5020 i915_gem_unset_wedged(i915);
5021
5022 /*
5023 * If we inherit context state from the BIOS or earlier
occupants
5024 * of the GPU, the GPU may be in an inconsistent state when we
5025 * try to take over. The only way to remove the earlier state
5026 * is by resetting. However, resetting on earlier gen is tricky
as
5027 * it may impact the display and we are uncertain about the
stability
5028 * of the reset, so this could be applied to even earlier gen.
5029 */
5030 if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
5031 WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
5032
5033 /* Reset the submission backend after resume as well as the GPU
reset */
5034 for_each_engine(engine, i915, id) {
> 5035 if (engine->reset.reset)
5036 engine->reset.reset(engine, NULL);
5037 }
5038
5039 intel_uncore_forcewake_put(i915, FORCEWAKE_ALL);
5040 intel_runtime_pm_put(i915);
5041
5042 i915_gem_contexts_lost(i915);
5043 mutex_unlock(>drm.struct_mutex);
5044 }
5045
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.o
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 31/05/2018 01:26, Rodrigo Vivi wrote:
> On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
>> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>>> This patchs adds the cec_notifier feature to the intel_hdmi part
>>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>>> between each HDMI ports.
>>> The changes will allow the i915 HDMI code to notify EDID and HPD changes
>>> to an eventual CEC adapter.
>>>
>>> Signed-off-by: Neil Armstrong
>>> Reviewed-by: Hans Verkuil
>>> ---
>>> drivers/gpu/drm/i915/Kconfig | 1 +
>>> drivers/gpu/drm/i915/intel_display.h | 20
>>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>>> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>>> 4 files changed, 36 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>>> index dfd9588..2d65d56 100644
>>> --- a/drivers/gpu/drm/i915/Kconfig
>>> +++ b/drivers/gpu/drm/i915/Kconfig
>>> @@ -23,6 +23,7 @@ config DRM_I915
>>> select SYNC_FILE
>>> select IOSF_MBI
>>> select CRC32
>>> + select CEC_CORE if CEC_NOTIFIER
>>> help
>>> Choose this option if you have a system that has "Intel Graphics
>>> Media Accelerator" or "HD Graphics" integrated graphics,
>>> diff --git a/drivers/gpu/drm/i915/intel_display.h
>>> b/drivers/gpu/drm/i915/intel_display.h
>>> index 4e7418b..c68d1c8 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.h
>>> +++ b/drivers/gpu/drm/i915/intel_display.h
>>> @@ -126,6 +126,26 @@ enum port {
>>>
>>> #define port_name(p) ((p) + 'A')
>>>
>>> +static inline const char *port_identifier(enum port port)
>>> +{
>>> + switch (port) {
>>> + case PORT_A:
>>> + return "Port A";
>>> + case PORT_B:
>>> + return "Port B";
>>> + case PORT_C:
>>> + return "Port C";
>>> + case PORT_D:
>>> + return "Port D";
>>> + case PORT_E:
>>> + return "Port E";
>>> + case PORT_F:
>>> + return "Port F";
>>> + default:
>>> + return "";
>>> + }
>>> +}
>>
>> Could use a comment to make it clear that this identifier is
>> expected to remain stable since it's referenced from other drivers.
>>
>>> +
>>> enum dpio_channel {
>>> DPIO_CH0,
>>> DPIO_CH1
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index d436858..b50e51b 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -39,6 +39,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> /**
>>> * __wait_for - magic wait macro
>>> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>>> bool has_audio;
>>> bool rgb_quant_range_selectable;
>>> struct intel_connector *attached_connector;
>>> + struct cec_notifier *notifier;
>>
>> "notifier" seems a bit too generic a name. "cec_notifier" would be
>> better.
>>
>> Apart from that this seems OK to me
>> Reviewed-by: Ville Syrjälä
>
> It seems that you will need to push this to other trees right?
> Feel free to use:
>
> Acked-by: Rodrigo Vivi
You are right, it will useful, thanks !
Neil
>
>>
>>> };
>>>
>>> struct intel_dp_mst_encoder;
>>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>>> b/drivers/gpu/drm/i915/intel_hdmi.c
>>> index 1baef4a..d522b5b 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>>> connected = true;
>>> }
>>>
>>> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
>>> +
>>> return connected;
>>> }
>>>
>>> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector,
>>> bool force)
>>> {
>>> enum drm_connector_status status;
>>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>>> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>>>
>>> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>> connector->base.id, connector->name);
>>> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector,
>>> bool force)
>>>
>>> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>>>
>>> + if (status != connector_status_connected)
>>> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
>>> +
>>> return status;
>>> }
>>>
>>> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
>>> *encoder,
>>>
>>> static void intel_hdmi_destroy(struct drm_connector *connector)
>>> {
>>> + if (intel_attached_hdmi(connector)->notifier)
>>> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>>> kfree(to_intel_connector(connector)->detect_edid);
>>> drm_connector_cleanup(connector);
>>> kfree(connector);
>>> @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
>>> intel_digital_port *intel_dig_port,
>>> u32 temp =
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 30/05/2018 17:29, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>> This patchs adds the cec_notifier feature to the intel_hdmi part
>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>> between each HDMI ports.
>> The changes will allow the i915 HDMI code to notify EDID and HPD changes
>> to an eventual CEC adapter.
>>
>> Signed-off-by: Neil Armstrong
>> Reviewed-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/i915/Kconfig | 1 +
>> drivers/gpu/drm/i915/intel_display.h | 20
>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>> 4 files changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index dfd9588..2d65d56 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -23,6 +23,7 @@ config DRM_I915
>> select SYNC_FILE
>> select IOSF_MBI
>> select CRC32
>> +select CEC_CORE if CEC_NOTIFIER
>> help
>>Choose this option if you have a system that has "Intel Graphics
>>Media Accelerator" or "HD Graphics" integrated graphics,
>> diff --git a/drivers/gpu/drm/i915/intel_display.h
>> b/drivers/gpu/drm/i915/intel_display.h
>> index 4e7418b..c68d1c8 100644
>> --- a/drivers/gpu/drm/i915/intel_display.h
>> +++ b/drivers/gpu/drm/i915/intel_display.h
>> @@ -126,6 +126,26 @@ enum port {
>>
>> #define port_name(p) ((p) + 'A')
>>
>> +static inline const char *port_identifier(enum port port)
>> +{
>> +switch (port) {
>> +case PORT_A:
>> +return "Port A";
>> +case PORT_B:
>> +return "Port B";
>> +case PORT_C:
>> +return "Port C";
>> +case PORT_D:
>> +return "Port D";
>> +case PORT_E:
>> +return "Port E";
>> +case PORT_F:
>> +return "Port F";
>> +default:
>> +return "";
>> +}
>> +}
>
> Could use a comment to make it clear that this identifier is
> expected to remain stable since it's referenced from other drivers.
>
>> +
>> enum dpio_channel {
>> DPIO_CH0,
>> DPIO_CH1
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index d436858..b50e51b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -39,6 +39,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /**
>> * __wait_for - magic wait macro
>> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>> bool has_audio;
>> bool rgb_quant_range_selectable;
>> struct intel_connector *attached_connector;
>> +struct cec_notifier *notifier;
>
> "notifier" seems a bit too generic a name. "cec_notifier" would be
> better.
OK
>
> Apart from that this seems OK to me
> Reviewed-by: Ville Syrjälä
Thanks for the review !
Neil
>
>> };
>>
>> struct intel_dp_mst_encoder;
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 1baef4a..d522b5b 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>> connected = true;
>> }
>>
>> +cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
>> +
>> return connected;
>> }
>>
>> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector,
>> bool force)
>> {
>> enum drm_connector_status status;
>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> +struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>>
>> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>connector->base.id, connector->name);
>> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector,
>> bool force)
>>
>> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>>
>> +if (status != connector_status_connected)
>> +cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
>> +
>> return status;
>> }
>>
>> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
>> *encoder,
>>
>> static void intel_hdmi_destroy(struct drm_connector *connector)
>> {
>> +if (intel_attached_hdmi(connector)->notifier)
>> +cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>> kfree(to_intel_connector(connector)->detect_edid);
>> drm_connector_cleanup(connector);
>> kfree(connector);
>> @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
>> intel_digital_port *intel_dig_port,
>> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>> }
>> +
>> +intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
>> + port_identifier(port));
>> +if (!intel_hdmi->notifier)
>> +
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
== Series Details == Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems URL : https://patchwork.freedesktop.org/series/44023/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4264 -> Patchwork_9157 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9157 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9157, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44023/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9157: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-kbl-r: PASS -> DMESG-WARN Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9157 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: DMESG-WARN (fdo#106725, fdo#106248) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: FAIL (fdo#103481) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 == Participating hosts (43 -> 40) == Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4264 -> Patchwork_9157 CI_DRM_4264: e267b381ac5a28004f13ed2dbbbab9e9230a264c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4502: 63f0bf3d50b70f011b9d600a1a4bc1a1c7720654 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9157: 1c143950174ee16778b4f5cbad002b18bb852526 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1c143950174e drm/i915: fix PCH_NOP setting for non-PCH platforms 92691863d185 drm/i915: be more strict about HAS_PCH_NOP() usage 1e1c684fabb9 drm/i915: clean up virtual PCH special case handling ff8c1be37217 drm/i915: fix guest virtual PCH detection on non-PCH systems == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9157/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: After reset on sanitization, reset the engine backends
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180530]
[cannot apply to v4.17-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Remove-stale-asserts-from-i915_gem_find_active_request/20180531-202540
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x019-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_sanitize':
>> drivers/gpu/drm/i915/i915_gem.c:5035:15: error: 'struct intel_engine_cs' has
>> no member named 'reset'; did you mean 'reset_hw'?
if (engine->reset.reset)
^
reset_hw
drivers/gpu/drm/i915/i915_gem.c:5036:12: error: 'struct intel_engine_cs' has
no member named 'reset'; did you mean 'reset_hw'?
engine->reset.reset(engine, NULL);
^
reset_hw
vim +5035 drivers/gpu/drm/i915/i915_gem.c
5000
5001 void i915_gem_sanitize(struct drm_i915_private *i915)
5002 {
5003 struct intel_engine_cs *engine;
5004 enum intel_engine_id id;
5005
5006 GEM_TRACE("\n");
5007
5008 mutex_lock(>drm.struct_mutex);
5009
5010 intel_runtime_pm_get(i915);
5011 intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
5012
5013 /*
5014 * As we have just resumed the machine and woken the device up
from
5015 * deep PCI sleep (presumably D3_cold), assume the HW has been
reset
5016 * back to defaults, recovering from whatever wedged state we
left it
5017 * in and so worth trying to use the device once more.
5018 */
5019 if (i915_terminally_wedged(>gpu_error))
5020 i915_gem_unset_wedged(i915);
5021
5022 /*
5023 * If we inherit context state from the BIOS or earlier
occupants
5024 * of the GPU, the GPU may be in an inconsistent state when we
5025 * try to take over. The only way to remove the earlier state
5026 * is by resetting. However, resetting on earlier gen is tricky
as
5027 * it may impact the display and we are uncertain about the
stability
5028 * of the reset, so this could be applied to even earlier gen.
5029 */
5030 if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
5031 WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
5032
5033 /* Reset the submission backend after resume as well as the GPU
reset */
5034 for_each_engine(engine, i915, id) {
> 5035 if (engine->reset.reset)
5036 engine->reset.reset(engine, NULL);
5037 }
5038
5039 intel_uncore_forcewake_put(i915, FORCEWAKE_ALL);
5040 intel_runtime_pm_put(i915);
5041
5042 i915_gem_contexts_lost(i915);
5043 mutex_unlock(>drm.struct_mutex);
5044 }
5045
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
== Series Details == Series: series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode URL : https://patchwork.freedesktop.org/series/44022/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4264 -> Patchwork_9156 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9156 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9156, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44022/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9156: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-kbl-r: PASS -> DMESG-WARN fi-skl-6600u: PASS -> DMESG-WARN Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9156 that come from known issues: === IGT changes === Issues hit igt@kms_busy@basic-flip-c: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: DMESG-WARN (fdo#106248, fdo#106725) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: FAIL (fdo#103481) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 == Participating hosts (43 -> 40) == Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4264 -> Patchwork_9156 CI_DRM_4264: e267b381ac5a28004f13ed2dbbbab9e9230a264c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4502: 63f0bf3d50b70f011b9d600a1a4bc1a1c7720654 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9156: 5d752b79043859f0b484c6d1629801351b33fb90 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5d752b790438 drm/i915/userptr: Enable read-only support on gen8+ 541b6690dd24 drm/i915: Reject attempted pwrites into a read-only object 34af85d4bc45 drm/i915: Prevent writing into a read-only object via a GGTT mmap 7573e440233e drm/i915/gtt: Read-only pages for insert_entries on bdw+ 401a4686bb18 drm/i915/gtt: Add read only pages to gen8_pte_encode == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9156/issues.html ___ 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/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
== Series Details == Series: series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode URL : https://patchwork.freedesktop.org/series/44022/ State : warning == Summary == $ dim checkpatch origin/drm-tip 401a4686bb18 drm/i915/gtt: Add read only pages to gen8_pte_encode 7573e440233e drm/i915/gtt: Read-only pages for insert_entries on bdw+ -:184: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #184: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:314: + bool pt_kmap_wc:1; -:187: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #187: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:317: + bool has_read_only:1; total: 0 errors, 2 warnings, 0 checks, 180 lines checked 34af85d4bc45 drm/i915: Prevent writing into a read-only object via a GGTT mmap 541b6690dd24 drm/i915: Reject attempted pwrites into a read-only object 5d752b790438 drm/i915/userptr: Enable read-only support on gen8+ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/gtt: Add read only pages to gen8_pte_encode
== Series Details == Series: series starting with [1/3] drm/i915/gtt: Add read only pages to gen8_pte_encode URL : https://patchwork.freedesktop.org/series/44008/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4263_full -> Patchwork_9155_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9155_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9155_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44008/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9155_full: === IGT changes === Possible regressions igt@gem_mmap_gtt@medium-copy-xy: shard-glk: PASS -> FAIL +1 igt@gem_userptr_blits@usage-restrictions: shard-kbl: PASS -> FAIL shard-apl: PASS -> FAIL Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +1 igt@kms_atomic@plane_overlay_legacy: shard-snb: SKIP -> PASS +3 igt@pm_rc6_residency@rc6-accuracy: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9155_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560) igt@gem_exec_parallel@render-fds: shard-snb: PASS -> INCOMPLETE (fdo#105411) igt@gem_linear_blits@normal: shard-glk: PASS -> FAIL (fdo#106608) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) +1 igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_exec_big: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_flip@wf_vblank-ts-check: shard-glk: FAIL (fdo#100368) -> PASS +2 igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS +1 igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS igt@perf_pmu@rc6-runtime-pm: shard-kbl: FAIL (fdo#105010) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106608 https://bugs.freedesktop.org/show_bug.cgi?id=106608 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4263 -> Patchwork_9155 CI_DRM_4263: 39699bf819b30b093c584b81d59480d769389d3d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9155: 38c4f40a8ce6f2cd565ec6094aa9ac56de69ecd1 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9155/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: clean up virtual PCH special case handling
Use intel_pch_type() also for mapping the no PCH case (PCH id 0) to
PCH_NONE to simplify code.
Also make sure that intel_pch_type() knows all the PCH ids returned by
intel_virt_detect_pch(). Loudly fail if this isn't the case; this
shouldn't happen anyway.
Cc: Colin Xu
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c42e389a27f3..1842a067a604 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -282,13 +282,12 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
} else if (intel_is_virt_pch(id, pch->subsystem_vendor,
pch->subsystem_device)) {
id = intel_virt_detect_pch(dev_priv);
- if (id) {
- pch_type = intel_pch_type(dev_priv, id);
- if (WARN_ON(pch_type == PCH_NONE))
- pch_type = PCH_NOP;
- } else {
- pch_type = PCH_NONE;
- }
+ pch_type = intel_pch_type(dev_priv, id);
+
+ /* Sanity check virtual PCH id */
+ if (WARN_ON(id && pch_type == PCH_NONE))
+ id = 0;
+
dev_priv->pch_type = pch_type;
dev_priv->pch_id = id;
break;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: be more strict about HAS_PCH_NOP() usage
HAS_PCH_NOP() implies a PCH platform without south display, not generic
disabled display. Prefer num_pipes == 0 for PCH independent checks.
Cc: Ville Syrjala
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_i2c.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1cf073b6ac8a..94428633a9d3 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1700,7 +1700,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
const struct bdb_header *bdb;
u8 __iomem *bios = NULL;
- if (HAS_PCH_NOP(dev_priv)) {
+ if (INTEL_INFO(dev_priv)->num_pipes == 0) {
DRM_DEBUG_KMS("Skipping VBT init due to disabled display.\n");
return;
}
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e6875509bcd9..61729bf84e08 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -771,7 +771,7 @@ int intel_setup_gmbus(struct drm_i915_private *dev_priv)
unsigned int pin;
int ret;
- if (HAS_PCH_NOP(dev_priv))
+ if (INTEL_INFO(dev_priv)->num_pipes == 0)
return 0;
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: fix PCH_NOP setting for non-PCH platforms
Setting PCH type to PCH_NOP before checking whether we actually have a
PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
platforms. Fix this by using PCH_NOP only for platforms that actually
have a PCH.
Cc: Ville Syrjala
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1842a067a604..5deee698881b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -246,14 +246,6 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
{
struct pci_dev *pch = NULL;
- /* In all current cases, num_pipes is equivalent to the PCH_NOP setting
-* (which really amounts to a PCH but no South Display).
-*/
- if (INTEL_INFO(dev_priv)->num_pipes == 0) {
- dev_priv->pch_type = PCH_NOP;
- return;
- }
-
/*
* The reason to probe ISA bridge instead of Dev31:Fun0 is to
* make graphics device passthrough work easy for VMM, that only
@@ -293,6 +285,17 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
break;
}
}
+
+ /*
+* Use PCH_NOP (PCH but no South Display) for PCH platforms without
+* display.
+*/
+ if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
+ DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
+ dev_priv->pch_type = PCH_NOP;
+ dev_priv->pch_id = 0;
+ }
+
if (!pch)
DRM_DEBUG_KMS("No PCH found.\n");
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
Virtualized non-PCH systems such as Broxton or Geminilake should use
PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
specific case to indicate a PCH system without south display.
Reported-by: Colin Xu
Cc: Colin Xu
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8f002ae22e62..c42e389a27f3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -287,7 +287,7 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
if (WARN_ON(pch_type == PCH_NONE))
pch_type = PCH_NOP;
} else {
- pch_type = PCH_NOP;
+ pch_type = PCH_NONE;
}
dev_priv->pch_type = pch_type;
dev_priv->pch_id = id;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: virtual PCH and PCH_NOP fixes
Just a resend of [1] with patch 4 dropped. BR, Jani. [1] 20180531055524.21855-1-jani.nikula@intel.com">http://mid.mail-archive.com/20180531055524.21855-1-jani.nikula@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: fix PCH_NOP setting for non-PCH platforms
On Thu, May 31, 2018 at 08:55:24AM +0300, Jani Nikula wrote:
> Setting PCH type to PCH_NOP before checking whether we actually have a
> PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
> platforms. Fix this by using PCH_NOP only for platforms that actually
> have a PCH.
>
> Cc: Ville Syrjala
> Signed-off-by: Jani Nikula
Apart from patch 4 the series looks good to me.
Reviewed-by: Ville Syrjälä
>
> ---
>
> Should we log this with "Found No Point PCH"? ;)
> ---
> drivers/gpu/drm/i915/i915_drv.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1842a067a604..5deee698881b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -246,14 +246,6 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> {
> struct pci_dev *pch = NULL;
>
> - /* In all current cases, num_pipes is equivalent to the PCH_NOP setting
> - * (which really amounts to a PCH but no South Display).
> - */
> - if (INTEL_INFO(dev_priv)->num_pipes == 0) {
> - dev_priv->pch_type = PCH_NOP;
> - return;
> - }
> -
> /*
>* The reason to probe ISA bridge instead of Dev31:Fun0 is to
>* make graphics device passthrough work easy for VMM, that only
> @@ -293,6 +285,17 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> break;
> }
> }
> +
> + /*
> + * Use PCH_NOP (PCH but no South Display) for PCH platforms without
> + * display.
> + */
> + if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
> + DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
> + dev_priv->pch_type = PCH_NOP;
> + dev_priv->pch_id = 0;
> + }
> +
> if (!pch)
> DRM_DEBUG_KMS("No PCH found.\n");
>
> --
> 2.11.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
Testcase: igt/gem_userptr_blits/readonly*
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 854bd51b9478..d4ee8fa4c379 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -789,10 +789,12 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -EFAULT;
if (args->flags & I915_USERPTR_READ_ONLY) {
- /* On almost all of the current hw, we cannot tell the GPU that
a
-* page is readonly, so this is just a placeholder in the uAPI.
+ /*
+* On almost all of the older hw, we cannot tell the GPU that
+* a page is readonly.
*/
- return -ENODEV;
+ if (INTEL_GEN(dev_priv) < 8 || !USES_PPGTT(dev_priv))
+ return -ENODEV;
}
obj = i915_gem_object_alloc(dev_priv);
@@ -806,7 +808,10 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
obj->userptr.ptr = args->user_ptr;
- obj->userptr.read_only = !!(args->flags & I915_USERPTR_READ_ONLY);
+ if (args->flags & I915_USERPTR_READ_ONLY) {
+ obj->userptr.read_only = true;
+ obj->gt_ro = true;
+ }
/* And keep a pointer to the current->mm for resolving the user pages
* at binding. This means that we need to hook into the mmu_notifier
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/gtt: Read-only pages for insert_entries on bdw+
From: Jon Bloomfield
Hook up the flags to allow read-only ppGTT mappings for gen8+
Signed-off-by: Jon Bloomfield
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 45 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 7 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 --
3 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5936f0bfdd19..1ac626cacc8d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -204,7 +204,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
return ret;
}
- /* Currently applicable only to VLV */
+ /* Applicable to VLV, and gen8+ */
pte_flags = 0;
if (vma->obj->gt_ro)
pte_flags |= PTE_READ_ONLY;
@@ -1008,10 +1008,11 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt
*ppgtt,
struct i915_page_directory_pointer *pdp,
struct sgt_dma *iter,
struct gen8_insert_pte *idx,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
gen8_pte_t *vaddr;
bool ret;
@@ -1062,14 +1063,14 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt
*ppgtt,
static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
gen8_ppgtt_insert_pte_entries(ppgtt, >pdp, , ,
- cache_level);
+ cache_level, flags);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
}
@@ -1077,9 +1078,10 @@ static void gen8_ppgtt_insert_3lvl(struct
i915_address_space *vm,
static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
struct i915_page_directory_pointer
**pdps,
struct sgt_dma *iter,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1195,19 +1197,21 @@ static void gen8_ppgtt_insert_huge_entries(struct
i915_vma *vma,
static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
if (vma->page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge_entries(vma, pdps, , cache_level);
+ gen8_ppgtt_insert_huge_entries(vma, pdps, , cache_level,
+ flags);
} else {
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++],
-, , cache_level))
+, , cache_level,
+flags))
GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
@@ -1614,6 +1618,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
1ULL << 48 :
1ULL << 32;
+ /* From bdw, there is support for read-only pages in the PPGTT */
+ ppgtt->base.has_read_only = true;
+
/* There are only few exceptions for gen >=6. chv and bxt.
* And we are not sure about the latter so play safe for now.
*/
@@ -2430,7 +2437,7 @@ static void gen8_ggtt_insert_page(struct
i915_address_space *vm,
static void
[Intel-gfx] [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
From: Jon Bloomfield
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f4def556f40..5936f0bfdd19 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -244,10 +244,13 @@ static void clear_pages(struct i915_vma *vma)
}
static gen8_pte_t gen8_pte_encode(dma_addr_t addr,
- enum i915_cache_level level)
+ enum i915_cache_level level,
+ u32 flags)
{
- gen8_pte_t pte = _PAGE_PRESENT | _PAGE_RW;
- pte |= addr;
+ gen8_pte_t pte = addr | _PAGE_PRESENT | _PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~_PAGE_RW;
switch (level) {
case I915_CACHE_NONE:
@@ -637,7 +640,7 @@ static void gen8_initialize_pt(struct i915_address_space
*vm,
struct i915_page_table *pt)
{
fill_px(vm, pt,
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC));
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0));
}
static void gen6_initialize_pt(struct i915_address_space *vm,
@@ -833,7 +836,7 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space
*vm,
unsigned int pte = gen8_pte_index(start);
unsigned int pte_end = pte + num_entries;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t *vaddr;
GEM_BUG_ON(num_entries > pt->used_ptes);
@@ -1008,7 +1011,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
enum i915_cache_level cache_level)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
gen8_pte_t *vaddr;
bool ret;
@@ -1076,7 +1079,7 @@ static void gen8_ppgtt_insert_huge_entries(struct
i915_vma *vma,
struct sgt_dma *iter,
enum i915_cache_level cache_level)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1542,7 +1545,7 @@ static void gen8_dump_ppgtt(struct i915_hw_ppgtt *ppgtt,
struct seq_file *m)
{
struct i915_address_space *vm = >base;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
u64 start = 0, length = ppgtt->base.total;
if (use_4lvl(vm)) {
@@ -2419,7 +2422,7 @@ static void gen8_ggtt_insert_page(struct
i915_address_space *vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)ggtt->gsm + (offset >> PAGE_SHIFT);
- gen8_set_pte(pte, gen8_pte_encode(addr, level));
+ gen8_set_pte(pte, gen8_pte_encode(addr, level, 0));
ggtt->invalidate(vm->i915);
}
@@ -2432,7 +2435,7 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
gen8_pte_t __iomem *gtt_entries;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
@@ -2500,7 +2503,7 @@ static void gen8_ggtt_clear_range(struct
i915_address_space *vm,
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t __iomem *gtt_base =
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
const int max_entries = ggtt_total_entries(ggtt) - first_entry;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only object
If the user created a read-only object, they should not be allowed to
circumvent the write protection using the pwrite ioctl.
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e55278fadf9c..f359ee507eb5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1619,6 +1619,12 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
goto err;
}
+ /* Writes not allowed into this read-only object */
+ if (obj->gt_ro) {
+ ret = -EINVAL;
+ goto err;
+ }
+
trace_i915_gem_object_pwrite(obj, args->offset, args->size);
ret = -ENODEV;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least reject in the call to create the mmap with backup in the
fault handler. This is a little draconian as we could blatantly ignore
the write protection on the pages, but it is far simply to keep the
readonly object pure. (It is easier to lift a restriction than to impose
it later!)
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 530d6d0109b4..e55278fadf9c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2005,6 +2005,10 @@ int i915_gem_fault(struct vm_fault *vmf)
unsigned int flags;
int ret;
+ /* Sanity check that we allow writing into this object */
+ if (obj->gt_ro && (write || !ggtt->base.has_read_only))
+ return VM_FAULT_SIGBUS;
+
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
@@ -2291,10 +2295,17 @@ i915_gem_mmap_gtt(struct drm_file *file,
if (!obj)
return -ENOENT;
+ /* If we will not be able to create the GGTT vma, reject it early. */
+ if (obj->gt_ro && !to_i915(dev)->ggtt.base.has_read_only) {
+ ret = -ENODEV;
+ goto out;
+ }
+
ret = i915_gem_object_create_mmap_offset(obj);
if (ret == 0)
*offset = drm_vma_node_offset_addr(>base.vma_node);
+out:
i915_gem_object_put(obj);
return ret;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/gem: be more strict about HAS_PCH_NOP() usage
On Thu, May 31, 2018 at 08:55:23AM +0300, Jani Nikula wrote:
> HAS_PCH_NOP() implies a PCH platform without south display, not generic
> disabled display. Prefer num_pipes == 0 for PCH independent checks.
>
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Signed-off-by: Jani Nikula
>
> ---
>
> I'm actually not sure about this. What should VLV, CHV, BXT and GLK do
> in this branch if display gets disabled? See next patch.
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 530d6d0109b4..d6be1a08848d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5137,7 +5137,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
> I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
> LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
>
> - if (HAS_PCH_NOP(dev_priv)) {
> + if (INTEL_INFO(dev_priv)->num_pipes == 0) {
So we're specifically trying to disable the PCH display reset handshake.
That would only seem applicaple for platforms with a PCH. So PCH_NOP
seems like the correct thing to check here.
However since we're just clearing the bits I think it should actually
be safe to do this on non-PCH platforms as well. But with the current
code I think we'd end up poking at the wrong register on VLV. It should
probably use the IVB register instead of the HSW+ register.
> if (IS_IVYBRIDGE(dev_priv)) {
> u32 temp = I915_READ(GEN7_MSG_CTL);
> temp &= ~(WAIT_FOR_PCH_FLR_ACK |
> WAIT_FOR_PCH_RESET_ACK);
> --
> 2.11.0
--
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 2/3] drm/i915/gtt: Read-only pages for insert_entries on bdw+
On Thu, 2018-05-31 at 10:19 +0100, Chris Wilson wrote: > From: Jon Bloomfield > > Hook up the flags to allow read-only ppGTT mappings for gen8+ > > Signed-off-by: Jon Bloomfield > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Matthew Auld Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gtt: Add read only pages to gen8_pte_encode
On Thu, 2018-05-31 at 10:19 +0100, Chris Wilson wrote: > From: Jon Bloomfield > > We can set a bit inside the ppGTT PTE to indicate a page is read-only; > writes from the GPU will be discarded. We can use this to protect pages > and in particular support read-only userptr mappings (necessary for > importing PROT_READ vma). > > Signed-off-by: Jon Bloomfield > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Matthew Auld Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Graphics Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] perf_pmu: Stop skipping hotplug test on Broxton
From: Tvrtko Ursulin There is a chance new kernel or new firmware fixed the CPU0 hotplug hang issue. Remove the skip to check if that's true. Signed-off-by: Tvrtko Ursulin --- tests/perf_pmu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c index 9af192dd8232..4570f926d7fe 100644 --- a/tests/perf_pmu.c +++ b/tests/perf_pmu.c @@ -1037,7 +1037,6 @@ static void cpu_hotplug(int gem_fd) int cur = 0; char buf; - igt_skip_on(IS_BROXTON(intel_get_drm_devid(gem_fd))); igt_require(cpu0_hotplug_support()); fd = open_pmu(I915_PMU_ENGINE_BUSY(I915_ENGINE_CLASS_RENDER, 0)); -- 2.17.0 ___ 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 [1/4] drm/i915: Switch to kernel context before idling at runtime
== Series Details == Series: series starting with [1/4] drm/i915: Switch to kernel context before idling at runtime URL : https://patchwork.freedesktop.org/series/44004/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4262_full -> Patchwork_9154_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9154_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9154_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44004/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9154_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP +1 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +1 igt@kms_atomic@plane_primary_legacy: shard-snb: SKIP -> PASS +1 igt@pm_rc6_residency@rc6-accuracy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9154_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) igt@gem_eio@suspend: shard-snb: PASS -> INCOMPLETE (fdo#105411) +1 igt@gem_exec_big: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363, fdo#102887) igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: shard-snb: SKIP -> FAIL (fdo#104724, fdo#103167) Possible fixes igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-plain-flip-ts-check: shard-hsw: FAIL (fdo#100368) -> PASS +1 igt@kms_flip@modeset-vs-vblank-race: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS +1 igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4262 -> Patchwork_9154 CI_DRM_4262: 867e60e3df29db24c84b4b1613f0a1366769aa20 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9154: 36a5fe4833fa6ba0dec81f2d8909689f5fb86d2b @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9154/shards.html ___ 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/userptr: Enable read-only support on gen8+
Quoting Chris Wilson (2018-05-31 10:19:23) > On gen8 and onwards, we can mark GPU accesses through the ppGTT as being > read-only, that is cause any GPU write onto that page to be discarded > (not triggering a fault). This is all that we need to finally support > the read-only flag for userptr! For full disclosure, I should say I have some caveats about ro support around the API: I think both pwrite and GGTT mmap should reject bogus writes. Hmm, indeed in this case, GGTT mmap will explode. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/gtt: Add read only pages to gen8_pte_encode
== Series Details == Series: series starting with [1/3] drm/i915/gtt: Add read only pages to gen8_pte_encode URL : https://patchwork.freedesktop.org/series/44008/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4263 -> Patchwork_9155 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9155 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9155, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44008/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9155: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9155 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) Possible fixes igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (44 -> 39) == Additional (1): fi-byt-j1900 Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-skl-6700hq == Build changes == * Linux: CI_DRM_4263 -> Patchwork_9155 CI_DRM_4263: 39699bf819b30b093c584b81d59480d769389d3d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9155: 38c4f40a8ce6f2cd565ec6094aa9ac56de69ecd1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 38c4f40a8ce6 drm/i915/userptr: Enable read-only support on gen8+ f509064f7a29 drm/i915/gtt: Read-only pages for insert_entries on bdw+ 15543653a61b drm/i915/gtt: Add read only pages to gen8_pte_encode == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9155/issues.html ___ 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/3] drm/i915/gtt: Add read only pages to gen8_pte_encode
== Series Details == Series: series starting with [1/3] drm/i915/gtt: Add read only pages to gen8_pte_encode URL : https://patchwork.freedesktop.org/series/44008/ State : warning == Summary == $ dim checkpatch origin/drm-tip 15543653a61b drm/i915/gtt: Add read only pages to gen8_pte_encode f509064f7a29 drm/i915/gtt: Read-only pages for insert_entries on bdw+ -:183: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #183: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:314: + bool pt_kmap_wc:1; -:186: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #186: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:317: + bool has_read_only:1; total: 0 errors, 2 warnings, 0 checks, 180 lines checked 38c4f40a8ce6 drm/i915/userptr: Enable read-only support on gen8+ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel 8/8] sna/video/sprite: Try disabling plane before giving up on colorkey
Quoting Ville Syrjala (2018-05-29 19:33:15) > From: Ville Syrjälä > > When we're trying to reinstate the colorkey we might fail on account of > the plane still being enable with a configuration that prevent the > use of colorkey. This happens easily with NV12 since the plane scaler > required by even unscaled NV12 is not compatible with colorkey. > > To work around the problem let's try disabling the plane first, then > re-enable the colorkey, and finally we will try to re-enable the plane. > The plane re-enable may fail, in which case we'll head to the GPU > scaling fallback path. The cost is a flash of the colorkey when the > plane blink off and then back on. > > Help me atomic ioctl, you're my only hope! > > Signed-off-by: Ville Syrjälä Though I glazed over at the asm patches, I concur that merely adding further crud is the easiest way to add colorspace encoding support. The rest of the patches looked fine, so the series is Reviewed-by: Chris Wilson Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/userptr: Enable read-only support on gen8+
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
Testcase: igt/gem_userptr_blits/readonly*
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 854bd51b9478..d4ee8fa4c379 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -789,10 +789,12 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -EFAULT;
if (args->flags & I915_USERPTR_READ_ONLY) {
- /* On almost all of the current hw, we cannot tell the GPU that
a
-* page is readonly, so this is just a placeholder in the uAPI.
+ /*
+* On almost all of the older hw, we cannot tell the GPU that
+* a page is readonly.
*/
- return -ENODEV;
+ if (INTEL_GEN(dev_priv) < 8 || !USES_PPGTT(dev_priv))
+ return -ENODEV;
}
obj = i915_gem_object_alloc(dev_priv);
@@ -806,7 +808,10 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
obj->userptr.ptr = args->user_ptr;
- obj->userptr.read_only = !!(args->flags & I915_USERPTR_READ_ONLY);
+ if (args->flags & I915_USERPTR_READ_ONLY) {
+ obj->userptr.read_only = true;
+ obj->gt_ro = true;
+ }
/* And keep a pointer to the current->mm for resolving the user pages
* at binding. This means that we need to hook into the mmu_notifier
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/gtt: Add read only pages to gen8_pte_encode
From: Jon Bloomfield
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f4def556f40..5936f0bfdd19 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -244,10 +244,13 @@ static void clear_pages(struct i915_vma *vma)
}
static gen8_pte_t gen8_pte_encode(dma_addr_t addr,
- enum i915_cache_level level)
+ enum i915_cache_level level,
+ u32 flags)
{
- gen8_pte_t pte = _PAGE_PRESENT | _PAGE_RW;
- pte |= addr;
+ gen8_pte_t pte = addr | _PAGE_PRESENT | _PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~_PAGE_RW;
switch (level) {
case I915_CACHE_NONE:
@@ -637,7 +640,7 @@ static void gen8_initialize_pt(struct i915_address_space
*vm,
struct i915_page_table *pt)
{
fill_px(vm, pt,
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC));
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0));
}
static void gen6_initialize_pt(struct i915_address_space *vm,
@@ -833,7 +836,7 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space
*vm,
unsigned int pte = gen8_pte_index(start);
unsigned int pte_end = pte + num_entries;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t *vaddr;
GEM_BUG_ON(num_entries > pt->used_ptes);
@@ -1008,7 +1011,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
enum i915_cache_level cache_level)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
gen8_pte_t *vaddr;
bool ret;
@@ -1076,7 +1079,7 @@ static void gen8_ppgtt_insert_huge_entries(struct
i915_vma *vma,
struct sgt_dma *iter,
enum i915_cache_level cache_level)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1542,7 +1545,7 @@ static void gen8_dump_ppgtt(struct i915_hw_ppgtt *ppgtt,
struct seq_file *m)
{
struct i915_address_space *vm = >base;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
u64 start = 0, length = ppgtt->base.total;
if (use_4lvl(vm)) {
@@ -2419,7 +2422,7 @@ static void gen8_ggtt_insert_page(struct
i915_address_space *vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)ggtt->gsm + (offset >> PAGE_SHIFT);
- gen8_set_pte(pte, gen8_pte_encode(addr, level));
+ gen8_set_pte(pte, gen8_pte_encode(addr, level, 0));
ggtt->invalidate(vm->i915);
}
@@ -2432,7 +2435,7 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
gen8_pte_t __iomem *gtt_entries;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
@@ -2500,7 +2503,7 @@ static void gen8_ggtt_clear_range(struct
i915_address_space *vm,
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t __iomem *gtt_base =
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
const int max_entries = ggtt_total_entries(ggtt) - first_entry;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/gtt: Read-only pages for insert_entries on bdw+
From: Jon Bloomfield
Hook up the flags to allow read-only ppGTT mappings for gen8+
Signed-off-by: Jon Bloomfield
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 45 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 7 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 --
3 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5936f0bfdd19..1ac626cacc8d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -204,7 +204,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
return ret;
}
- /* Currently applicable only to VLV */
+ /* Applicable to VLV, and gen8+ */
pte_flags = 0;
if (vma->obj->gt_ro)
pte_flags |= PTE_READ_ONLY;
@@ -1008,10 +1008,11 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt
*ppgtt,
struct i915_page_directory_pointer *pdp,
struct sgt_dma *iter,
struct gen8_insert_pte *idx,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
gen8_pte_t *vaddr;
bool ret;
@@ -1062,14 +1063,14 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt
*ppgtt,
static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
gen8_ppgtt_insert_pte_entries(ppgtt, >pdp, , ,
- cache_level);
+ cache_level, flags);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
}
@@ -1077,9 +1078,10 @@ static void gen8_ppgtt_insert_3lvl(struct
i915_address_space *vm,
static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
struct i915_page_directory_pointer
**pdps,
struct sgt_dma *iter,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1195,19 +1197,21 @@ static void gen8_ppgtt_insert_huge_entries(struct
i915_vma *vma,
static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
if (vma->page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge_entries(vma, pdps, , cache_level);
+ gen8_ppgtt_insert_huge_entries(vma, pdps, , cache_level,
+ flags);
} else {
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++],
-, , cache_level))
+, , cache_level,
+flags))
GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
@@ -1614,6 +1618,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
1ULL << 48 :
1ULL << 32;
+ /* From bdw, there is support for read-only pages in the PPGTT */
+ ppgtt->base.has_read_only = true;
+
/* There are only few exceptions for gen >=6. chv and bxt.
* And we are not sure about the latter so play safe for now.
*/
@@ -2430,7 +2437,7 @@ static void gen8_ggtt_insert_page(struct
i915_address_space *vm,
static void gen8_ggtt_insert_entries(struct
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Switch to kernel context before idling at runtime
== Series Details == Series: series starting with [1/4] drm/i915: Switch to kernel context before idling at runtime URL : https://patchwork.freedesktop.org/series/44004/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4262 -> Patchwork_9154 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44004/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9154 that come from known issues: === IGT changes === Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#106607) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: FAIL (fdo#103481) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-y3: DMESG-WARN (fdo#104951) -> PASS fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#106607 https://bugs.freedesktop.org/show_bug.cgi?id=106607 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4262 -> Patchwork_9154 CI_DRM_4262: 867e60e3df29db24c84b4b1613f0a1366769aa20 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9154: 36a5fe4833fa6ba0dec81f2d8909689f5fb86d2b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 36a5fe4833fa drm/i915: Only sanitize GEM from late suspend 6cb6754cc4e5 drm/i915: After reset on sanitization, reset the engine backends d7121e35592c drm/i915: "Race-to-idle" after switching to the kernel context ba2022d8ffd4 drm/i915: Switch to kernel context before idling at runtime == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9154/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: Switch to kernel context before idling at runtime
== Series Details == Series: series starting with [1/4] drm/i915: Switch to kernel context before idling at runtime URL : https://patchwork.freedesktop.org/series/44004/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Switch to kernel context before idling at runtime Okay! Commit: drm/i915: "Race-to-idle" after switching to the kernel context Okay! Commit: drm/i915: After reset on sanitization, reset the engine backends Okay! Commit: drm/i915: Only sanitize GEM from late suspend -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3665:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Only sanitize GEM from late suspend
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume cycle, we have to assume the device has
been reset to its defaults. A simple way around this is to skip the
sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 22 +-
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8f002ae22e62..0d9b8cc0436d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -636,6 +636,8 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static void i915_gem_fini(struct drm_i915_private *dev_priv)
{
+ i915_gem_suspend_late(dev_priv);
+
/* Flush any outstanding unpin_work. */
i915_gem_drain_workqueue(dev_priv);
@@ -1611,7 +1613,6 @@ static int i915_drm_suspend(struct drm_device *dev)
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
intel_opregion_notify_adapter(dev_priv, opregion_target_state);
- intel_uncore_suspend(dev_priv);
intel_opregion_unregister(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
@@ -1633,7 +1634,10 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
disable_rpm_wakeref_asserts(dev_priv);
+ i915_gem_suspend_late(dev_priv);
+
intel_display_set_init_power(dev_priv, false);
+ intel_uncore_suspend(dev_priv);
/*
* In case of firmware assisted context save/restore don't manually
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 32a65de7222d..38157df6ff5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3169,6 +3169,7 @@ void i915_gem_cleanup_engines(struct drm_i915_private
*dev_priv);
int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
unsigned int flags);
int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
+void i915_gem_suspend_late(struct drm_i915_private *dev_priv);
void i915_gem_resume(struct drm_i915_private *dev_priv);
int i915_gem_fault(struct vm_fault *vmf);
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9b8fa1866cc9..f5c4ef052001 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5055,6 +5055,17 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
if (WARN_ON(!intel_engines_are_idle(dev_priv)))
i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
+ intel_runtime_pm_put(dev_priv);
+ return 0;
+
+err_unlock:
+ mutex_unlock(>struct_mutex);
+ intel_runtime_pm_put(dev_priv);
+ return ret;
+}
+
+void i915_gem_suspend_late(struct drm_i915_private *i915)
+{
/*
* Neither the BIOS, ourselves or any other kernel
* expects the system to be in execlists mode on startup,
@@ -5074,16 +5085,9 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
* machines is a good idea, we don't - just in case it leaves the
* machine in an unusable condition.
*/
- intel_uc_sanitize(dev_priv);
- i915_gem_sanitize(dev_priv);
- intel_runtime_pm_put(dev_priv);
- return 0;
-
-err_unlock:
- mutex_unlock(>struct_mutex);
- intel_runtime_pm_put(dev_priv);
- return ret;
+ intel_uc_sanitize(i915);
+ i915_gem_sanitize(i915);
}
void i915_gem_resume(struct drm_i915_private *i915)
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Switch to kernel context before idling at runtime
We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through the slow and irregular retire work handler.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +--
drivers/gpu/drm/i915/i915_gem.c | 36 +
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a8e7761cdc7d..15e86d34a81c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4226,8 +4226,13 @@ i915_drop_caches_set(void *data, u64 val)
i915_gem_shrink_all(dev_priv);
fs_reclaim_release(GFP_KERNEL);
- if (val & DROP_IDLE)
- drain_delayed_work(_priv->gt.idle_work);
+ if (val & DROP_IDLE) {
+ do {
+ if (READ_ONCE(dev_priv->gt.active_requests))
+ flush_delayed_work(_priv->gt.retire_work);
+ drain_delayed_work(_priv->gt.idle_work);
+ } while (READ_ONCE(dev_priv->gt.awake));
+ }
if (val & DROP_FREED)
i915_gem_drain_freed_objects(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 530d6d0109b4..173d1e4ad963 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -139,6 +139,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
static u32 __i915_gem_park(struct drm_i915_private *i915)
{
+ GEM_TRACE("\n");
+
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
GEM_BUG_ON(!list_empty(>gt.active_rings));
@@ -181,6 +183,8 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
void i915_gem_park(struct drm_i915_private *i915)
{
+ GEM_TRACE("\n");
+
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
@@ -193,6 +197,8 @@ void i915_gem_park(struct drm_i915_private *i915)
void i915_gem_unpark(struct drm_i915_private *i915)
{
+ GEM_TRACE("\n");
+
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(!i915->gt.active_requests);
@@ -3503,6 +3509,24 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (!READ_ONCE(dev_priv->gt.awake))
return;
+ if (READ_ONCE(dev_priv->gt.active_requests))
+ return;
+
+ /*
+* Flush out the last user context, leaving only the pinned
+* kernel context resident. When we are idling on the kernel_context,
+* no more new requests (with a context switch) are emitted and we
+* can finally rest. A consequence is that the idle work handler is
+* always called at least twice before idling (and if the system is
+* idle that implies a round trip through the retire worker).
+*/
+ mutex_lock(_priv->drm.struct_mutex);
+ i915_gem_switch_to_kernel_context(dev_priv);
+ mutex_unlock(_priv->drm.struct_mutex);
+
+ GEM_TRACE("active_requests=%d (after switch-to-kernel-context)\n",
+ READ_ONCE(dev_priv->gt.active_requests));
+
/*
* Wait for last execlists context complete, but bail out in case a
* new request is submitted. As we don't trust the hardware, we
@@ -4913,11 +4937,9 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
void i915_gem_sanitize(struct drm_i915_private *i915)
{
- if (i915_terminally_wedged(>gpu_error)) {
- mutex_lock(>drm.struct_mutex);
+ mutex_lock(>drm.struct_mutex);
+ if (i915_terminally_wedged(>gpu_error))
i915_gem_unset_wedged(i915);
- mutex_unlock(>drm.struct_mutex);
- }
/*
* If we inherit context state from the BIOS or earlier occupants
@@ -4929,6 +4951,9 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
*/
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+
+ i915_gem_contexts_lost(i915);
+ mutex_unlock(>drm.struct_mutex);
}
int i915_gem_suspend(struct drm_i915_private *dev_priv)
@@ -4964,7 +4989,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
assert_kernel_context_is_current(dev_priv);
}
- i915_gem_contexts_lost(dev_priv);
mutex_unlock(>struct_mutex);
intel_uc_suspend(dev_priv);
@@ -5017,6 +5041,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
void i915_gem_resume(struct drm_i915_private *i915)
{
+ GEM_TRACE("\n");
+
[Intel-gfx] [PATCH 2/4] drm/i915: "Race-to-idle" after switching to the kernel context
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling is also used to enforce
a barrier before changing OA properties, and when evicting active
rendering from the global GTT. All cases where we do want to
race-to-idle.
v2: Limit the boosting to only the switch before suspend.
v3: Limit it to the wait-for-idle on suspend.
Signed-off-by: Chris Wilson
Cc: David Weinehall
Cc: Mika Kuoppala
Tested-by: David Weinehall #v1
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 27 +--
drivers/gpu/drm/i915/i915_request.h | 1 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 173d1e4ad963..b312ac006d24 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3708,7 +3708,29 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
static int wait_for_timeline(struct i915_timeline *tl, unsigned int flags)
{
- return i915_gem_active_wait(>last_request, flags);
+ struct i915_request *rq;
+ long ret;
+
+ rq = i915_gem_active_get_unlocked(>last_request);
+ if (!rq)
+ return 0;
+
+ /*
+* "Race-to-idle".
+*
+* Switching to the kernel context is often used a synchronous
+* step prior to idling, e.g. in suspend for flushing all
+* current operations to memory before sleeping. These we
+* want to complete as quickly as possible to avoid prolonged
+* stalls, so allow the gpu to boost to maximum clocks.
+*/
+ if (flags & I915_WAIT_FOR_IDLE_BOOST)
+ gen6_rps_boost(rq, NULL);
+
+ ret = i915_request_wait(rq, flags, MAX_SCHEDULE_TIMEOUT);
+ i915_request_put(rq);
+
+ return ret < 0 ? ret : 0;
}
static int wait_for_engines(struct drm_i915_private *i915)
@@ -4983,7 +5005,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
ret = i915_gem_wait_for_idle(dev_priv,
I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
+I915_WAIT_LOCKED |
+I915_WAIT_FOR_IDLE_BOOST);
if (ret && ret != -EIO)
goto err_unlock;
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 17a9fa03..491ff81d0fea 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -267,6 +267,7 @@ long i915_request_wait(struct i915_request *rq,
#define I915_WAIT_INTERRUPTIBLEBIT(0)
#define I915_WAIT_LOCKED BIT(1) /* struct_mutex held, handle GPU reset */
#define I915_WAIT_ALL BIT(2) /* used by i915_gem_object_wait() */
+#define I915_WAIT_FOR_IDLE_BOOST BIT(3)
static inline u32 intel_engine_get_seqno(struct intel_engine_cs *engine);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: After reset on sanitization, reset the engine backends
As we reset the GPU on suspend/resume, we also do need to reset the
engine state tracking so call into the engine backends. This is
especially important so that we can also sanitize the state tracking
across resume.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106702
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 24
drivers/gpu/drm/i915/intel_lrc.c | 8 +---
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b312ac006d24..9b8fa1866cc9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4959,7 +4959,22 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
void i915_gem_sanitize(struct drm_i915_private *i915)
{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ GEM_TRACE("\n");
+
mutex_lock(>drm.struct_mutex);
+
+ intel_runtime_pm_get(i915);
+ intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
+
+ /*
+* As we have just resumed the machine and woken the device up from
+* deep PCI sleep (presumably D3_cold), assume the HW has been reset
+* back to defaults, recovering from whatever wedged state we left it
+* in and so worth trying to use the device once more.
+*/
if (i915_terminally_wedged(>gpu_error))
i915_gem_unset_wedged(i915);
@@ -4974,6 +4989,15 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+ /* Reset the submission backend after resume as well as the GPU reset */
+ for_each_engine(engine, i915, id) {
+ if (engine->reset.reset)
+ engine->reset.reset(engine, NULL);
+ }
+
+ intel_uncore_forcewake_put(i915, FORCEWAKE_ALL);
+ intel_runtime_pm_put(i915);
+
i915_gem_contexts_lost(i915);
mutex_unlock(>drm.struct_mutex);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8a6058b4102f..517e92c6a70b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1787,9 +1787,6 @@ static void enable_execlists(struct intel_engine_cs
*engine)
I915_WRITE(RING_HWS_PGA(engine->mmio_base),
engine->status_page.ggtt_offset);
POSTING_READ(RING_HWS_PGA(engine->mmio_base));
-
- /* Following the reset, we need to reload the CSB read/write pointers */
- engine->execlists.csb_head = -1;
}
static bool unexpected_starting_state(struct intel_engine_cs *engine)
@@ -1961,6 +1958,9 @@ static void execlists_reset(struct intel_engine_cs
*engine,
__unwind_incomplete_requests(engine);
spin_unlock(>timeline.lock);
+ /* Following the reset, we need to reload the CSB read/write pointers */
+ engine->execlists.csb_head = -1;
+
local_irq_restore(flags);
/*
@@ -2460,6 +2460,8 @@ static int logical_ring_init(struct intel_engine_cs
*engine)
upper_32_bits(ce->lrc_desc);
}
+ engine->execlists.csb_head = -1;
+
return 0;
error:
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, Finally got my send-mail script sorted out. A few bugfixes for drm-next. drm-misc-next-fixes-2018-05-31: drm-misc-next-fixes for v4.18: Driver changes: - Plug small memory leak in vc4. (anholt) - Depend on MMU in v3d. (arnd) The following changes since commit 2045b22461c07a88dc3d2bab3cbfc6dc0c602fd4: Merge tag 'drm-misc-next-2018-05-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-05-15 19:25:07 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-05-31 for you to fetch changes up to fbecef131676c1d18e8e6b42c04e10dc49725e96: drm/v3d: add CONFIG_MMU dependency (2018-05-30 12:15:18 -0700) drm-misc-next-fixes for v4.18: Driver changes: - Plug small memory leak in vc4. (anholt) - Depend on MMU in v3d. (arnd) Arnd Bergmann (1): drm/v3d: add CONFIG_MMU dependency Eric Anholt (1): drm/vc4: Fix leak of the file_priv that stored the perfmon. drivers/gpu/drm/v3d/Kconfig | 1 + drivers/gpu/drm/vc4/vc4_drv.c | 1 + 2 files changed, 2 insertions(+) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 39/41] drm/i915: Implement the HDCP2.2 support for HDMI
On Mon, May 21, 2018 at 06:23:58PM +0530, Ramalingam C wrote:
> Implements the HDMI adaptation specific HDCP2.2 operations.
>
> Basically these are DDC read and write for authenticating through
> HDCP2.2 messages.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> No more special handling of Gmbus burst read for AKE_SEND_CERT.
> Style fixed with few naming. [Uma]
> %s/PARING/PAIRING
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 186
> ++
> 1 file changed, 186 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index a5cc73101acb..042205e57e42 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1106,6 +1107,186 @@ bool intel_hdmi_hdcp_check_link(struct
> intel_digital_port *intel_dig_port)
> return true;
> }
>
> +static
> +int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port
> *intel_dig_port,
> + uint8_t *rx_status)
> +{
> + return intel_hdmi_hdcp_read(intel_dig_port,
> + HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
> + rx_status,
> + HDCP_2_2_HDMI_RXSTATUS_LEN);
> +}
> +
> +static inline
> +int intel_hdmi_hdcp2_timeout_for_msg(uint8_t msg_id, bool is_paired)
So at a glance this is the same timeout stuff as for dp. I think this
should be moved out of the low-level callbacks into commont code. Maybe
wrap the low-level callbacks for read/write into small helper functions,
which then also do the timeout handling?
And I think the timeouts and availability checks should be done in the
hdcp flow directly, instead of far away from where the register read/write
is issue. Just to keep the entire register i/o closely together.
-Daniel
> +{
> + int timeout;
> +
> + switch (msg_id) {
> + case HDCP_2_2_AKE_SEND_CERT:
> + timeout = HDCP_2_2_CERT_TIMEOUT;
> + break;
> + case HDCP_2_2_AKE_SEND_HPRIME:
> + if (is_paired)
> + timeout = HDCP_2_2_HPRIME_PAIRED_TIMEOUT;
> + else
> + timeout = HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT;
> + break;
> + case HDCP_2_2_AKE_SEND_PAIRING_INFO:
> + timeout = HDCP_2_2_PAIRING_TIMEOUT;
> + break;
> + case HDCP_2_2_LC_SEND_LPRIME:
> + timeout = HDCP_2_2_HDMI_LPRIME_TIMEOUT;
> + break;
> + case HDCP_2_2_REP_SEND_RECVID_LIST:
> + timeout = HDCP_2_2_RECVID_LIST_TIMEOUT;
> + break;
> + case HDCP_2_2_REP_STREAM_READY:
> + timeout = HDCP_2_2_STREAM_READY_TIMEOUT;
> + break;
> + default:
> + timeout = -EINVAL;
> + DRM_ERROR("Unsupported msg_id: %d\n", (int)msg_id);
> + }
> +
> + return timeout;
> +}
> +
> +static inline
> +int hdcp2_detect_msg_availability(struct intel_digital_port
> *intel_digital_port,
> + uint8_t msg_id, bool *msg_ready,
> + ssize_t *msg_sz)
> +{
> + uint8_t rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
> + int ret;
> +
> + ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
> + if (ret < 0) {
> + DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
> + return ret;
> + }
> +
> + *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
> + rx_status[0]);
> +
> + if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
> + *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
> + *msg_sz);
> + else
> + *msg_ready = *msg_sz;
> +
> + return 0;
> +}
> +
> +static ssize_t
> +intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
> + uint8_t msg_id, bool paired)
> +{
> + bool msg_ready = false;
> + int timeout, ret;
> + ssize_t msg_sz;
> +
> + timeout = intel_hdmi_hdcp2_timeout_for_msg(msg_id, paired);
> + if (timeout < 0)
> + return timeout;
> +
> + ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
> + msg_id, _ready, _sz),
> + !ret && msg_ready && msg_sz, timeout * 1000,
> + 1000, 5 * 1000);
> + if (ret)
> + DRM_ERROR("msg_id: %d, ret: %d, timeout: %d\n",
> + msg_id, ret, timeout);
> +
> + return ret ? ret : msg_sz;
> +}
> +
> +static
> +int intel_hdmi_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
> +void *buf, size_t size)
> +{
> + unsigned int offset;
> +
> + offset = HDCP_2_2_HDMI_REG_WR_MSG_OFFSET;
> + return intel_hdmi_hdcp_write(intel_dig_port,
Re: [Intel-gfx] [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
> than completions concept. WIP to understand and implement that,
> if needed. Just to unblock the review of other changes, v2 still
> continues with completions.
>
> v2:
> wait for cp_irq is merged with this patch. Rebased.
> v3:
> wait_queue is used for wait for cp_irq [Chris Wilson]
> v4:
> Style fixed.
> %s/PARING/PAIRING
> Few style fixes [Uma]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 358
> ++
> drivers/gpu/drm/i915/intel_drv.h | 7 +
> drivers/gpu/drm/i915/intel_hdcp.c | 5 +
> 3 files changed, 370 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 528407d608c8..ee71a26ec23f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -5057,6 +5058,28 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> pps_unlock(intel_dp);
> }
>
> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> + int timeout)
> +{
> + long ret;
> +
> + /* Reinit */
> + atomic_set(>cp_irq_recved, 0);
> +
> +#define C (atomic_read(>cp_irq_recved) > 0)
> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> +msecs_to_jiffies(timeout));
> +
> + if (ret > 0) {
> + atomic_set(>cp_irq_recved, 0);
> + return 0;
> + } else if (!ret) {
> + return -ETIMEDOUT;
> + }
> + return (int)ret;
> +}
> +
> +
> static
> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> u8 *an)
> @@ -5275,6 +5298,335 @@ int intel_dp_hdcp_capable(struct intel_digital_port
> *intel_dig_port,
> return 0;
> }
>
> +static
> +int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int *offset)
Ugh, this is annoying that we have to map things around like that. But
looking at the numbers the standards really don't seem to match at all.
Instead of open-coding this I suggested you use a table with a struct
like:
const static struct hdcp_dp {
int hdcp_msg;
int dpcd_offset;
int timeout;
/* whatever else you might need */
} hdcp_2_dp_table[] = {
{ HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
...
};
Then just search that table in the code instead of the huge switch table
below.
> +{
> + switch (byte) {
> + case HDCP_2_2_AKE_INIT:
> + *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
> + break;
> + case HDCP_2_2_AKE_SEND_CERT:
> + *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
> + break;
> + case HDCP_2_2_AKE_NO_STORED_KM:
> + *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
> + break;
> + case HDCP_2_2_AKE_STORED_KM:
> + *offset = DP_HDCP_2_2_AKE_STORED_KM_OFFSET;
> + break;
> + case HDCP_2_2_AKE_SEND_HPRIME:
> + *offset = DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET;
> + break;
> + case HDCP_2_2_AKE_SEND_PAIRING_INFO:
> + *offset = DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET;
> + break;
> + case HDCP_2_2_LC_INIT:
> + *offset = DP_HDCP_2_2_LC_INIT_OFFSET;
> + break;
> + case HDCP_2_2_LC_SEND_LPRIME:
> + *offset = DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET;
> + break;
> + case HDCP_2_2_SKE_SEND_EKS:
> + *offset = DP_HDCP_2_2_SKE_SEND_EKS_OFFSET;
> + break;
> + case HDCP_2_2_REP_SEND_RECVID_LIST:
> + *offset = DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET;
> + break;
> + case HDCP_2_2_REP_SEND_ACK:
> + *offset = DP_HDCP_2_2_REP_SEND_ACK_OFFSET;
> + break;
> + case HDCP_2_2_REP_STREAM_MANAGE:
> + *offset = DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET;
> + break;
> + case HDCP_2_2_REP_STREAM_READY:
> + *offset = DP_HDCP_2_2_REP_STREAM_READY_OFFSET;
> + break;
> + case HDCP_2_2_ERRATA_DP_STREAM_TYPE:
> + *offset = DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET;
> + break;
> + default:
> + DRM_ERROR("Unrecognized Msg ID\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static inline
> +int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
> + uint8_t *rx_status)
> +{
> + ssize_t ret;
> +
> + ret =
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm/i915: fix guest virtual PCH detection on non-PCH systems
== Series Details == Series: series starting with [1/5] drm/i915: fix guest virtual PCH detection on non-PCH systems URL : https://patchwork.freedesktop.org/series/43986/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4261_full -> Patchwork_9153_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9153_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9153_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43986/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9153_full: === IGT changes === Possible regressions igt@perf_pmu@multi-client-vcs0: shard-snb: PASS -> FAIL Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9153_full that come from known issues: === IGT changes === Issues hit igt@drm_read@fault-buffer: shard-glk: PASS -> DMESG-WARN (fdo#106247) +2 igt@gem_exec_parallel@render-fds: shard-snb: PASS -> INCOMPLETE (fdo#105411) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_flip@wf_vblank-ts-check: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) +1 igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_vblank@pipe-b-wait-busy: shard-apl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +10 Possible fixes igt@drv_selftest@live_gtt: shard-apl: FAIL (fdo#105347) -> PASS igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#106509, fdo#105454) -> PASS igt@kms_rotation_crc@cursor-rotation-180: shard-hsw: FAIL (fdo#104724, fdo#103925) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106247 https://bugs.freedesktop.org/show_bug.cgi?id=106247 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4261 -> Patchwork_9153 CI_DRM_4261: 505628b3d930ed326287c244afdd3c2f8fe274b7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9153: 901fca0ad70c0df783f85d70a90fc26c1be7b6f0 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9153/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 25/41] drm/i915: Enable and Disable HDCP2.2 port encryption
On Mon, May 21, 2018 at 06:23:44PM +0530, Ramalingam C wrote:
> Implements the enable and disable functions for HDCP2.2 encryption
> of the PORT.
>
> v2:
> intel_wait_for_register is used instead of wait_for. [Chris Wilson]
> v3:
> No Changes.
> v4:
> Debug msg is added for timeout at Disable of Encryption [Uma]
> %s/HDCP2_CTL/HDCP2_CTL
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 57
> +++
> 1 file changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index bd0bfcfd5b8f..0386a67c3e32 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -19,6 +19,7 @@
>(enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES 5
> #define HDCP2_LC_RETRY_CNT 3
> +#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
> @@ -1397,3 +1398,59 @@ static int hdcp2_authenticate_sink(struct
> intel_connector *connector)
>
> return ret;
> }
> +
> +static int hdcp2_enable_encryption(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = >hdcp;
> + enum port port = connector->encoder->port;
> + int ret;
> +
> + if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)
> + return 0;
Relying on hw status for state decisions is in my experience bad - it
papers over bugs in our state handling. We should know what the expected
state of the hardware is.
If you want to write a bit more robust code, then keep these checks, but
wrap them in a WARN_ON. That way we'll know if there's a regression in the
code (e.g. unbalanced enable/disable) right away, instead of these checks
silently papering over them.
> +
> + if (hdcp->hdcp_shim->toggle_signalling)
> + hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
> +
> + if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
Same for this check here. In general control flow that depends upon
register values which can change at runtime is very suspect from a design
robustness point of view.
-Daniel
> +
> + /* Link is Authenticated. Now set for Encryption */
> + I915_WRITE(HDCP2_CTL_DDI(port),
> +I915_READ(HDCP2_CTL_DDI(port)) |
> +CTL_LINK_ENCRYPTION_REQ);
> + }
> +
> + ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
> + LINK_ENCRYPTION_STATUS,
> + LINK_ENCRYPTION_STATUS,
> + TIME_FOR_ENCRYPT_STATUS_CHANGE);
> +
> + return ret;
> +}
> +
> +static int hdcp2_disable_encryption(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = >hdcp;
> + enum port port = connector->encoder->port;
> + int ret;
> +
> + if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS))
> + return 0;
> +
> + I915_WRITE(HDCP2_CTL_DDI(port),
> +I915_READ(HDCP2_CTL_DDI(port)) & ~CTL_LINK_ENCRYPTION_REQ);
> +
> + ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
> + LINK_ENCRYPTION_STATUS, 0x0,
> + TIME_FOR_ENCRYPT_STATUS_CHANGE);
> + if (ret == -ETIMEDOUT)
> + DRM_DEBUG_KMS("Disable Encryption Timedout");
> +
> + if (hdcp->hdcp_shim->toggle_signalling)
> + hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
> +
> + return ret;
> +}
> --
> 2.7.4
>
--
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 v4 22/41] drm/i915: Wrappers for mei HDCP2.2 services
On Mon, May 21, 2018 at 06:23:41PM +0530, Ramalingam C wrote:
> Adds the wrapper for all mei hdcp2.2 service functions.
>
> v2:
> Rebased.
> v3:
> cldev is moved from mei_hdcp_data to hdcp.
> v4:
> %s/hdcp2_store_paring_info/hdcp2_store_pairing_info
>
> Signed-off-by: Ramalingam C
This is a bit a style nit, but I'm not convinced of the value of these
wrappers. They just do basic sanity checking (and with the component
stuff, cldev should never be NULL before we get here), and those checks
that are still needed could be done just once when we start a hdcp2
operation.
Personally I'd drop these all and directly call the mei_ functions in the
later patches (plus put just 1 set of the sanity checks at the beginning
of a hdcp flow). More direct code is generally easier to read later on.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 194
> ++
> 1 file changed, 194 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index c7d0fa319c01..57c380c91cd0 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -10,10 +10,13 @@
> #include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
>
> +#define GET_MEI_DDI_INDEX(port) (((port) == PORT_A) ? DDI_A : \
> + (enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES 5
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> @@ -896,3 +899,194 @@ int intel_hdcp_check_link(struct intel_connector
> *connector)
> mutex_unlock(>hdcp_mutex);
> return ret;
> }
> +
> +static int
> +hdcp2_prepare_ake_init(struct intel_hdcp *hdcp, struct hdcp2_ake_init
> *ake_data)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + struct intel_connector *connector = container_of(hdcp,
> + struct intel_connector,
> + hdcp);
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + if (data->port == INVALID_PORT && connector->encoder)
> + data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
> +
> + /* Clear ME FW instance for the port, just incase */
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return mei_initiate_hdcp2_session(hdcp->cldev, data, ake_data);
> +}
> +
> +static int hdcp2_close_mei_session(struct intel_hdcp *hdcp)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> +
> + if (!hdcp->cldev || data->port == INVALID_PORT)
> + return -EINVAL;
> +
> + return mei_close_hdcp_session(hdcp->cldev, data);
> +}
> +
> +static int
> +hdcp2_verify_rx_cert_prepare_km(struct intel_hdcp *hdcp,
> + struct hdcp2_ake_send_cert *rx_cert,
> + bool *paired,
> + struct hdcp2_ake_no_stored_km *ek_pub_km,
> + size_t *msg_sz)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_verify_receiver_cert_prepare_km(hdcp->cldev, data, rx_cert,
> + paired, ek_pub_km, msg_sz);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int hdcp2_verify_hprime(struct intel_hdcp *hdcp,
> +struct hdcp2_ake_send_hprime *rx_hprime)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_verify_hprime(hdcp->cldev, data, rx_hprime);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int
> +hdcp2_store_pairing_info(struct intel_hdcp *hdcp,
> + struct hdcp2_ake_send_pairing_info *pairing_info)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_store_pairing_info(hdcp->cldev, data, pairing_info);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int
> +hdcp2_prepare_lc_init(struct intel_hdcp *hdcp, struct hdcp2_lc_init *lc_init)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_initiate_locality_check(hdcp->cldev, data, lc_init);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int
> +hdcp2_verify_lprime(struct intel_hdcp *hdcp,
> + struct hdcp2_lc_send_lprime *rx_lprime)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> +
