[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Add psr1 live status (rev2)
== Series Details == Series: drm/i915/psr: Add psr1 live status (rev2) URL : https://patchwork.freedesktop.org/series/45143/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9392 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45143/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9392 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (43 -> 37) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4368 -> Patchwork_9392 CI_DRM_4368: f9f621dc095a8bfd2157fba018ddb542260d8daa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9392: 717c5cfed95ac3cf27eebdf934d00cf179523c5b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 717c5cfed95a drm/i915/psr: Add psr1 live status == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9392/issues.html ___ 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: Use I915_MAP_WC for execlists context buffer on the platforms without LLC
== Series Details == Series: drm/i915: Use I915_MAP_WC for execlists context buffer on the platforms without LLC URL : https://patchwork.freedesktop.org/series/45213/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9391 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9391 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9391, 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/45213/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9391: === IGT changes === Possible regressions igt@gem_close_race@basic-threads: fi-bsw-n3050: PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_9391 that come from known issues: === IGT changes === Issues hit igt@gem_close_race@basic-threads: fi-glk-j4005: PASS -> INCOMPLETE (k.org#198133, fdo#103359) fi-bxt-j4205: PASS -> INCOMPLETE (fdo#103927) fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (43 -> 37) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4368 -> Patchwork_9391 CI_DRM_4368: f9f621dc095a8bfd2157fba018ddb542260d8daa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9391: e5a2098da0c4b8d365abd17df2991ddf598917de @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e5a2098da0c4 drm/i915: Use I915_MAP_WC for execlists context buffer on the platforms without LLC == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9391/issues.html ___ 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/ddi: Get AUX power domain for DP main link too (rev2)
== Series Details == Series: drm/i915/ddi: Get AUX power domain for DP main link too (rev2) URL : https://patchwork.freedesktop.org/series/45188/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4363_full -> Patchwork_9388_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9388_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9388_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9388_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS igt@perf_pmu@rc6: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9388_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-apl: PASS -> FAIL (fdo#106886) igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106023) igt@gem_workarounds@suspend-resume-context: shard-apl: PASS -> FAIL (fdo#103375) +1 igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_sysfs_edid_timing: shard-glk: NOTRUN -> WARN (fdo#100047) igt@perf_pmu@busy-idle-check-all-rcs0: shard-snb: PASS -> INCOMPLETE (fdo#105411) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@drv_selftest@live_hangcheck: shard-kbl: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS shard-apl: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105189) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS +1 igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 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#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 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_4363 -> Patchwork_9388 CI_DRM_4363: 9e52e63f91e95af0f7475ccce206d4bdfca8933a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9388: 6df9a07560c7c1343343e5d9332972e84a4c27bb @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9388/shards.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: Use I915_MAP_WC for execlists context buffer on the platforms without LLC
== Series Details == Series: drm/i915: Use I915_MAP_WC for execlists context buffer on the platforms without LLC URL : https://patchwork.freedesktop.org/series/45213/ State : warning == Summary == $ dim checkpatch origin/drm-tip e5a2098da0c4 drm/i915: Use I915_MAP_WC for execlists context buffer on the platforms without LLC -:12: WARNING:TYPO_SPELLING: 'writting' may be misspelled - perhaps 'writing'? #12: before writting the ELSP port, it has no explicit cache flsuh.Maybe it is total: 0 errors, 1 warnings, 0 checks, 38 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Add psr1 live status
From: Vathsala Nagaraju
Prints live state of psr1.Extending the existing
PSR2 live state function to cover psr1.
Tested on KBL with psr2 and psr1 panel.
v2: rebase
v3: DK
Rename psr2_live_status to psr_source_status.
v4: DK
Move EDP_PSR_STATUS_STATE_SHIFT below EDP_PSR_STATUS_STATE_MASK.
Pass seq to psr_source_status, handle source status prints in
psr_source_status.
v5: Fixed CI warning messages
v6:
Remove extra space in the title before the colon.(DK)
Rebase. (Jani)
v7: use tabs for indenting the values.(Jani)
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_debugfs.c | 72 -
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 49 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c400f42..3941d85 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2597,27 +2597,55 @@ static int i915_guc_log_relay_release(struct inode
*inode, struct file *file)
.release = i915_guc_log_relay_release,
};
-static const char *psr2_live_status(u32 val)
-{
- static const char * const live_status[] = {
- "IDLE",
- "CAPTURE",
- "CAPTURE_FS",
- "SLEEP",
- "BUFON_FW",
- "ML_UP",
- "SU_STANDBY",
- "FAST_SLEEP",
- "DEEP_SLEEP",
- "BUF_ON",
- "TG_ON"
- };
+static void
+psr_source_status(struct drm_i915_private *dev_priv, struct seq_file *m)
+{
+ u32 val, psr_status = 0;
- val = (val & EDP_PSR2_STATUS_STATE_MASK) >> EDP_PSR2_STATUS_STATE_SHIFT;
- if (val < ARRAY_SIZE(live_status))
- return live_status[val];
+ if (dev_priv->psr.psr2_enabled) {
+ static const char * const live_status[] = {
+ "IDLE",
+ "CAPTURE",
+ "CAPTURE_FS",
+ "SLEEP",
+ "BUFON_FW",
+ "ML_UP",
+ "SU_STANDBY",
+ "FAST_SLEEP",
+ "DEEP_SLEEP",
+ "BUF_ON",
+ "TG_ON"
+ };
+ psr_status = I915_READ(EDP_PSR2_STATUS);
+ val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
+ EDP_PSR2_STATUS_STATE_SHIFT;
+ if (val < ARRAY_SIZE(live_status)) {
+ seq_printf(m, "Source PSR status: %x[%s]\n", psr_status,
+ live_status[val]);
+ return;
+ }
+ } else {
+ static const char * const live_status[] = {
+ "IDLE",
+ "SRDONACK",
+ "SRDENT",
+ "BUFOFF",
+ "BUFON",
+ "AUXACK",
+ "SRDOFFACK",
+ "SRDENT_ON",
+ };
+ psr_status = I915_READ(EDP_PSR_STATUS);
+ val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
+ EDP_PSR_STATUS_STATE_SHIFT;
+ if (val < ARRAY_SIZE(live_status)) {
+ seq_printf(m, "Source PSR status: %x[%s]\n", psr_status,
+ live_status[val]);
+ return;
+ }
+ }
- return "unknown";
+ seq_printf(m, "Source psr status: %x[%s]\n", psr_status, "unknown");
}
static const char *psr_sink_status(u8 val)
@@ -2681,12 +2709,8 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
- if (dev_priv->psr.psr2_enabled) {
- u32 psr2 = I915_READ(EDP_PSR2_STATUS);
- seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
- psr2, psr2_live_status(psr2));
- }
+ psr_source_status(dev_priv, m);
if (dev_priv->psr.enabled) {
struct drm_dp_aux *aux = _priv->psr.enabled->aux;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index caad19f..4efad4d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4072,6 +4072,7 @@ enum {
#define EDP_PSR_STATUS _MMIO(dev_priv->psr_mmio_base +
0x40)
#define EDP_PSR_STATUS_STATE_MASK(7 << 29)
+#define EDP_PSR_STATUS_STATE_SHIFT 29
#define EDP_PSR_STATUS_STATE_IDLE(0 << 29)
#define EDP_PSR_STATUS_STATE_SRDONACK(1 << 29)
#define EDP_PSR_STATUS_STATE_SRDENT (2 << 29)
--
1.9.1
___
Intel-gfx mailing list
[Intel-gfx] [PATCH] drm/i915: Use I915_MAP_WC for execlists context buffer on the platforms without LLC
Under execlists mode the context buffer is allocated in global Gtt region.
The I915_MAP_WB type is used to map the buffer so that the driver can
initialize the context buffer.(Ring reg, Context Ctrl reg and so on).
And then __context_pin is called to flush back corresponding contents.
In fact as it also tries to update context buffer (Ring Tail offset)
before writting the ELSP port, it has no explicit cache flsuh.Maybe it is
handled by HW. But this is quite confusing as BXT has no LLC. So the WC
is used to map the context buffer on the platform without LLC and the
update of context buffer is writen into phys page directly. It will
be safer.
Signed-off-by: Zhao Yakui
CC: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 10deebe..a76ea83 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1386,6 +1386,7 @@ __execlists_context_pin(struct intel_engine_cs *engine,
{
void *vaddr;
int ret;
+ enum i915_map_type map = HAS_LLC(ctx->i915) ? I915_MAP_WB : I915_MAP_WC;
ret = execlists_context_deferred_alloc(ctx, engine, ce);
if (ret)
@@ -1396,7 +1397,7 @@ __execlists_context_pin(struct intel_engine_cs *engine,
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(ce->state->obj, map);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto unpin_vma;
@@ -2728,6 +2729,7 @@ populate_lr_context(struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_ring *ring)
{
+ enum i915_map_type map = HAS_LLC(ctx->i915) ? I915_MAP_WB : I915_MAP_WC;
void *vaddr;
u32 *regs;
int ret;
@@ -2738,7 +2740,7 @@ populate_lr_context(struct i915_gem_context *ctx,
return ret;
}
- vaddr = i915_gem_object_pin_map(ctx_obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(ctx_obj, map);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
DRM_DEBUG_DRIVER("Could not map object pages! (%d)\n", ret);
@@ -2756,7 +2758,7 @@ populate_lr_context(struct i915_gem_context *ctx,
void *defaults;
defaults = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ map);
if (IS_ERR(defaults)) {
ret = PTR_ERR(defaults);
goto err_unpin_ctx;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Wait for PSR exit before checking for vblank evasion
Hi Tarun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.18-rc1 next-20180621]
[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/Tarun-Vyas/drm-i915-Wait-for-PSR-exit-before-checking-for-vblank-evasion/20180622-090643
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x011-201824 (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/intel_sprite.c: In function 'intel_pipe_update_start':
>> drivers/gpu/drm/i915/intel_sprite.c:116:2: error: implicit declaration of
>> function 'psr_wait_for_idle_lockless'; did you mean 'wait_on_page_locked'?
>> [-Werror=implicit-function-declaration]
psr_wait_for_idle_lockless(dev_priv);
^~
wait_on_page_locked
cc1: some warnings being treated as errors
vim +116 drivers/gpu/drm/i915/intel_sprite.c
76
77 /**
78 * intel_pipe_update_start() - start update of a set of display
registers
79 * @new_crtc_state: the new crtc state
80 *
81 * Mark the start of an update to pipe registers that should be updated
82 * atomically regarding vblank. If the next vblank will happens within
83 * the next 100 us, this function waits until the vblank passes.
84 *
85 * After a successful call to this function, interrupts will be disabled
86 * until a subsequent call to intel_pipe_update_end(). That is done to
87 * avoid random delays.
88 */
89 void intel_pipe_update_start(const struct intel_crtc_state
*new_crtc_state)
90 {
91 struct intel_crtc *crtc =
to_intel_crtc(new_crtc_state->base.crtc);
92 struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
93 const struct drm_display_mode *adjusted_mode =
_crtc_state->base.adjusted_mode;
94 long timeout = msecs_to_jiffies_timeout(1);
95 int scanline, min, max, vblank_start;
96 wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
97 bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) ||
IS_CHERRYVIEW(dev_priv)) &&
98 intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
99 DEFINE_WAIT(wait);
100
101 vblank_start = adjusted_mode->crtc_vblank_start;
102 if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
103 vblank_start = DIV_ROUND_UP(vblank_start, 2);
104
105 /* FIXME needs to be calibrated sensibly */
106 min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
107
VBLANK_EVASION_TIME_US);
108 max = vblank_start - 1;
109
110 if (min <= 0 || max <= 0)
111 return;
112
113 if (WARN_ON(drm_crtc_vblank_get(>base)))
114 return;
115
> 116 psr_wait_for_idle_lockless(dev_priv);
117
118 local_irq_disable();
119
120 crtc->debug.min_vbl = min;
121 crtc->debug.max_vbl = max;
122 trace_i915_pipe_update_start(crtc);
123
124 for (;;) {
125 /*
126 * prepare_to_wait() has a memory barrier, which
guarantees
127 * other CPUs can see the task state update by the time
we
128 * read the scanline.
129 */
130 prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
131
132 scanline = intel_get_crtc_scanline(crtc);
133 if (scanline < min || scanline > max)
134 break;
135
136 if (!timeout) {
137 DRM_ERROR("Potential atomic update failure on
pipe %c\n",
138pipe_name(crtc->pipe));
139 break;
140 }
141
142 local_irq_enable();
143
144 timeout = schedule_timeout(timeout);
145
146 local_irq_disable();
147 }
148
149 finish_wait(wq, );
150
151 drm_crtc_vblank_put(>base);
152
153 /*
154 * On VLV/CHV DSI the scanline counter would appear to
155 * increment approx. 1/3 of a scanline before start of vblank.
156 * The registers still get latched at start of vblank however.
157 * This means we must not write any registers
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove pointless if-else from sdvo code
== Series Details == Series: drm/i915: Remove pointless if-else from sdvo code URL : https://patchwork.freedesktop.org/series/45189/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4362_full -> Patchwork_9387_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9387_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9387_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9387_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_9387_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) shard-apl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@gem_workarounds@suspend-resume-context: shard-apl: PASS -> FAIL (fdo#103375) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) Possible fixes igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> PASS igt@kms_flip@dpms-vs-vblank-race: shard-kbl: FAIL (fdo#103060) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 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_4362 -> Patchwork_9387 CI_DRM_4362: 7159c27349b070831dfb3512ca055c8dbcf9e1fc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9387: 4f50b56b76e1d57ecedeb6325f6cf3cbdb98ea46 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9387/shards.html ___ 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/psr: Lockless version of psr_wait_for_idle (rev2)
== Series Details == Series: drm/i915/psr: Lockless version of psr_wait_for_idle (rev2) URL : https://patchwork.freedesktop.org/series/45209/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_sprite.o drivers/gpu/drm/i915/intel_sprite.c: In function ‘intel_pipe_update_start’: drivers/gpu/drm/i915/intel_sprite.c:116:2: error: implicit declaration of function ‘psr_wait_for_idle_lockless’; did you mean ‘wait_on_page_locked’? [-Werror=implicit-function-declaration] psr_wait_for_idle_lockless(dev_priv); ^~ wait_on_page_locked cc1: all warnings being treated as errors scripts/Makefile.build:317: recipe for target 'drivers/gpu/drm/i915/intel_sprite.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_sprite.o] Error 1 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1034: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Wait for PSR exit before checking for vblank evasion
On Thu, 2018-06-21 at 18:03 -0700, Tarun Vyas wrote: > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then > the pipe_update_start call schedules itself out to check back later. > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but > lags w.r.t core kernel code, hot plugging an external display > triggers > tons of "potential atomic update errors" in the dmesg, on *pipe A*. A > closer analysis reveals that we try to read the scanline 3 times and > eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL > stuck @ 1599. This issue is not seen on upstream kernels, b/c for > *some* > reason we loop inside intel_pipe_update start for ~2+ msec which in > this > case is more than enough to exit PSR fully, hence an *unstuck* > PIPEDSL > counter, hence no error. On the other hand, the ChromeOS kernel > spends > ~1.1 msec looping inside intel_pipe_update_start and hence errors out > b/c the source is still in PSR. > > Regardless, we should wait for PSR exit (if PSR is disabled, we incur > a ~1-2 usec penalty) before reading the PIPEDSL, b/c if we haven't > fully exited PSR, then checking for vblank evasion isn't actually > applicable. > > Signed-off-by: Tarun Vyas > --- > drivers/gpu/drm/i915/intel_sprite.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > b/drivers/gpu/drm/i915/intel_sprite.c > index 344c0e709b19..34754771d7a7 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -107,14 +107,16 @@ void intel_pipe_update_start(const struct > intel_crtc_state *new_crtc_state) > VBLANK_EVASION > _TIME_US); > max = vblank_start - 1; > > - local_irq_disable(); > - > if (min <= 0 || max <= 0) > return; > > if (WARN_ON(drm_crtc_vblank_get(>base))) > return; > > + psr_wait_for_idle_lockless(dev_priv); Document the implicit requirement that we enable vblank interrupts before waiting for PSR idle. Looks good to me, I'll wait for others to chime in. The hope is https://bugs.freedesktop.org/show_bug.cgi?id=106678 gets fixed with this patch. > + > + local_irq_disable(); > + > crtc->debug.min_vbl = min; > crtc->debug.max_vbl = max; > trace_i915_pipe_update_start(crtc); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Lockless version of psr_wait_for_idle
On Thu, 2018-06-21 at 18:03 -0700, Tarun Vyas wrote:
> This is a lockless version of the exisiting psr_wait_for_idle().
> We want to wait for PSR to idle out inside intel_pipe_update_start.
> At the time of a pipe update, we should never race with any psr
> enable or disable code, which is a part of crtc enable/disable. So,
> we can live w/o taking any psr locks at all.
> The follow up patch will use this lockless wait inside pipe_update_
> start to wait for PSR to idle out before checking for vblank evasion.
>
> Even if psr is never enabled, psr2_enabled will be false and this
> function will wait for PSR1 to idle out, which should just return
> immediately, so a very short (~1-2 usec) wait for cases where PSR
> is disabled.
>
> Signed-off-by: Tarun Vyas
> ---
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 19 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 578346b8d7e2..a48aad0f99bf 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1920,6 +1920,7 @@ void intel_psr_compute_config(struct intel_dp
> *intel_dp,
> struct intel_crtc_state *crtc_state);
> void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool
> debug);
> void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32
> psr_iir);
> +void psr_wait_for_idle_lockless(struct drm_i915_private *dev_priv);
>
> /* intel_runtime_pm.c */
> int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index aea81ace854b..425147444f69 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -757,6 +757,25 @@ void intel_psr_disable(struct intel_dp
> *intel_dp,
> cancel_work_sync(_priv->psr.work);
> }
>
> +void psr_wait_for_idle_lockless(struct drm_i915_private *dev_priv)
> +{
> + i915_reg_t reg;
> + u32 mask;
> + int err;
> +
> + if (dev_priv->psr.psr2_enabled) {
> + reg = EDP_PSR2_STATUS;
> + mask = EDP_PSR2_STATUS_STATE_MASK;
> + } else {
> + reg = EDP_PSR_STATUS;
> + mask = EDP_PSR_STATUS_STATE_MASK;
> + }
> +
> + err = intel_wait_for_register(dev_priv, reg, mask,
> EDP_PSR_STATUS_STATE_IDLE, 25);
A comment explaining the rationale for 25 ms is necessary here.
> + if (err)
> + DRM_ERROR("Timed out waiting for PSR Idle for pipe
> update\n");
> +}
> +
> static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
> {
> struct intel_dp *intel_dp;
___
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/2] drm/i915/ddi: Get AUX power domain for DP main link too
== Series Details == Series: series starting with [1/2] drm/i915/ddi: Get AUX power domain for DP main link too URL : https://patchwork.freedesktop.org/series/45181/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4362_full -> Patchwork_9385_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9385_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9385_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9385_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_9385_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@gem_workarounds@suspend-resume-context: shard-apl: PASS -> FAIL (fdo#103375) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105189) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_flip@dpms-vs-vblank-race: shard-kbl: FAIL (fdo#103060) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 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#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 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_4362 -> Patchwork_9385 CI_DRM_4362: 7159c27349b070831dfb3512ca055c8dbcf9e1fc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9385: f1178ae6d5f0ad56370f2557d746cf5fc09c0923 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9385/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Wait for PSR exit before checking for vblank evasion
The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then the pipe_update_start call schedules itself out to check back later. On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but lags w.r.t core kernel code, hot plugging an external display triggers tons of "potential atomic update errors" in the dmesg, on *pipe A*. A closer analysis reveals that we try to read the scanline 3 times and eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL stuck @ 1599. This issue is not seen on upstream kernels, b/c for *some* reason we loop inside intel_pipe_update start for ~2+ msec which in this case is more than enough to exit PSR fully, hence an *unstuck* PIPEDSL counter, hence no error. On the other hand, the ChromeOS kernel spends ~1.1 msec looping inside intel_pipe_update_start and hence errors out b/c the source is still in PSR. Regardless, we should wait for PSR exit (if PSR is disabled, we incur a ~1-2 usec penalty) before reading the PIPEDSL, b/c if we haven't fully exited PSR, then checking for vblank evasion isn't actually applicable. Signed-off-by: Tarun Vyas --- drivers/gpu/drm/i915/intel_sprite.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 344c0e709b19..34754771d7a7 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -107,14 +107,16 @@ void intel_pipe_update_start(const struct intel_crtc_state *new_crtc_state) VBLANK_EVASION_TIME_US); max = vblank_start - 1; - local_irq_disable(); - if (min <= 0 || max <= 0) return; if (WARN_ON(drm_crtc_vblank_get(>base))) return; + psr_wait_for_idle_lockless(dev_priv); + + local_irq_disable(); + crtc->debug.min_vbl = min; crtc->debug.max_vbl = max; trace_i915_pipe_update_start(crtc); -- 2.13.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Lockless version of psr_wait_for_idle
This is a lockless version of the exisiting psr_wait_for_idle().
We want to wait for PSR to idle out inside intel_pipe_update_start.
At the time of a pipe update, we should never race with any psr
enable or disable code, which is a part of crtc enable/disable. So,
we can live w/o taking any psr locks at all.
The follow up patch will use this lockless wait inside pipe_update_
start to wait for PSR to idle out before checking for vblank evasion.
Even if psr is never enabled, psr2_enabled will be false and this
function will wait for PSR1 to idle out, which should just return
immediately, so a very short (~1-2 usec) wait for cases where PSR
is disabled.
Signed-off-by: Tarun Vyas
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 19 +++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 578346b8d7e2..a48aad0f99bf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1920,6 +1920,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state);
void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug);
void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir);
+void psr_wait_for_idle_lockless(struct drm_i915_private *dev_priv);
/* intel_runtime_pm.c */
int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index aea81ace854b..425147444f69 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -757,6 +757,25 @@ void intel_psr_disable(struct intel_dp *intel_dp,
cancel_work_sync(_priv->psr.work);
}
+void psr_wait_for_idle_lockless(struct drm_i915_private *dev_priv)
+{
+ i915_reg_t reg;
+ u32 mask;
+ int err;
+
+ if (dev_priv->psr.psr2_enabled) {
+ reg = EDP_PSR2_STATUS;
+ mask = EDP_PSR2_STATUS_STATE_MASK;
+ } else {
+ reg = EDP_PSR_STATUS;
+ mask = EDP_PSR_STATUS_STATE_MASK;
+ }
+
+ err = intel_wait_for_register(dev_priv, reg, mask,
EDP_PSR_STATUS_STATE_IDLE, 25);
+ if (err)
+ DRM_ERROR("Timed out waiting for PSR Idle for pipe update\n");
+}
+
static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
{
struct intel_dp *intel_dp;
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/14] drm/i915: Populate possible_crtcs correctly
On Fri, 2018-06-15 at 19:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Don't advertize non-exisiting crtcs in the encoder possible_crtcs
> bitmask.
>
How do we end up advertising non-existing CRTCs? encoder->crtc_mask
seems to be populated in the encoder init functions based on possible
pipes. Do you mean pipe and crtc->index can potentially differ?
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b095899d68a9..3fa9da714403 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13959,6 +13959,20 @@ static int intel_encoder_clones(struct
> intel_encoder *encoder)
> return index_mask;
> }
>
> +static int intel_encoder_crtcs(struct intel_encoder *encoder)
> +{
> + struct drm_device *dev = encoder->base.dev;
> + struct intel_crtc *crtc;
> + int index_mask = 0;
> +
> + for_each_intel_crtc(dev, crtc) {
> + if (encoder->crtc_mask & BIT(crtc->pipe))
> + index_mask |= drm_crtc_mask(>base);
> + }
> +
> + return index_mask;
> +}
> +
> static bool has_edp_a(struct drm_i915_private *dev_priv)
> {
> if (!IS_MOBILE(dev_priv))
> @@ -14211,7 +14225,8 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> intel_psr_init(dev_priv);
>
> for_each_intel_encoder(_priv->drm, encoder) {
> - encoder->base.possible_crtcs = encoder->crtc_mask;
> + encoder->base.possible_crtcs =
> + intel_encoder_crtcs(encoder);
> encoder->base.possible_clones =
> intel_encoder_clones(encoder);
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fix DP-MST crtc_mask
On Fri, 2018-06-15 at 21:43 +0300, Ville Syrjälä wrote: > On Fri, Jun 15, 2018 at 11:33:01AM -0700, Dhinakaran Pandiyan wrote: > > > > On Fri, 2018-06-15 at 19:49 +0300, Ville Syrjala wrote: > > > > > > From: Ville Syrjälä > > > > > > Each fake MST encoder is tied to a specific pipe. Fix the > > > encoder's > > > crtc_mask to reflect that fact. > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c > > > b/drivers/gpu/drm/i915/intel_dp_mst.c > > > index 5890500a3a8b..8e30765402b4 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c > > > @@ -565,7 +565,7 @@ intel_dp_create_fake_mst_encoder(struct > > > intel_digital_port *intel_dig_port, enum > > > intel_encoder->type = INTEL_OUTPUT_DP_MST; > > > intel_encoder->power_domain = intel_dig_port- > > > > > > > > base.power_domain; > > > intel_encoder->port = intel_dig_port->base.port; > > > - intel_encoder->crtc_mask = 0x7; > > > + intel_encoder->crtc_mask = BIT(pipe); > > How did this not cause any problems? Does this mean this field > > was/is > > unused? > This is a hint to userspace. So userspace would pick the connector > and crtc based on the hints, and then the kernel gets to pick the > actual encoder. In this case the bogus hint was good enough to tell > userspace that it can pick any crtc for any MST connector. > > Hmm. Why on earth do we have .atomic_best_encoder() and > .best_encoder() > for MST? The fb_helper appears to want to use the non-atomic one for > some reason... On boy, I guess I'll need to do something about that. > As is this patch would probably break it :( > So we end up picking crtc-0 for all MST connectors with the same primary. Since this patch does the right thing and assuming https://patchwork.freedesktop.org/patch/229905/ gets merged before this Reviewed-by: Dhinakaran Pandiyan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/24] drm/i915/icl: Update FIA supported lane count for hpd.
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Paulo Zanoni
>Sent: Monday, May 21, 2018 5:26 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Zanoni, Paulo R
>Subject: [Intel-gfx] [PATCH 22/24] drm/i915/icl: Update FIA supported lane
>count
>for hpd.
>
>From: Animesh Manna
>
>In ICL, Flexible IO Adapter (FIA) muxes data and clocks of USB 3.1, tbt and
>display
>controller. In DP alt mode FIA configure the number of lanes and will be used
>apart from DPCD read to calculate max available lanes for DP enablement.
>
>Signed-off-by: Animesh Manna
>[Paulo: significant rewrite of the patch.]
>Signed-off-by: Paulo Zanoni
Looks good.
Reviewed-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_dp.c |
>33 -
> 2 files changed, 37 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index 42cbace4c61e..2a501e7590bf 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -10033,4 +10033,9 @@ enum skl_power_gate {
> #define PORT_TX_DFLEXDPCSSS _MMIO(0x163894)
> #define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)(1 << (tc_port))
>
>+#define PORT_TX_DFLEXDPSP _MMIO(0x1638A0)
>+#define DP_LANE_ASSIGNMENT_SHIFT(tc_port) ((tc_port) * 8)
>+#define DP_LANE_ASSIGNMENT_MASK(tc_port)(0xf << ((tc_port) * 8))
>+#define DP_LANE_ASSIGNMENT(tc_port, x) ((x) << ((tc_port) * 8))
>+
> #endif /* _I915_REG_H_ */
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index f25f871e7c22..a883a3264e56 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -176,14 +176,45 @@ static int intel_dp_max_common_rate(struct intel_dp
>*intel_dp)
> return intel_dp->common_rates[intel_dp->num_common_rates - 1]; }
>
>+static int intel_dp_get_fia_supported_lane_count(struct intel_dp
>+*intel_dp) {
>+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>+ struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>+ enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
>+ u32 lane_info;
>+
>+ if (tc_port == PORT_TC_NONE || dig_port->tc_type != TC_PORT_TYPEC)
>+ return 4;
>+
>+ lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
>+ DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
>+ DP_LANE_ASSIGNMENT_SHIFT(tc_port);
>+
>+ switch (lane_info) {
>+ default:
>+ MISSING_CASE(lane_info);
>+ case 1:
>+ case 2:
>+ case 4:
>+ case 8:
>+ return 1;
>+ case 3:
>+ case 12:
>+ return 2;
>+ case 15:
>+ return 4;
>+ }
>+}
>+
> /* Theoretical max between source and sink */ static int
>intel_dp_max_common_lane_count(struct intel_dp *intel_dp) {
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> int source_max = intel_dig_port->max_lanes;
> int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
>+ int fia_max = intel_dp_get_fia_supported_lane_count(intel_dp);
>
>- return min(source_max, sink_max);
>+ return min3(source_max, sink_max, fia_max);
> }
>
> int intel_dp_max_lane_count(struct intel_dp *intel_dp)
>--
>2.14.3
>
>___
>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 v2] drm/i915: Wait for PSR exit before checking for vblank evasion
On Tue, Jun 19, 2018 at 02:59:54PM -0700, Tarun Vyas wrote: > On Tue, Jun 19, 2018 at 02:54:07PM -0700, Dhinakaran Pandiyan wrote: > > On Tue, 2018-06-19 at 14:27 -0700, Dhinakaran Pandiyan wrote: > > > On Mon, 2018-05-14 at 13:49 -0700, Tarun Vyas wrote: > > > > > > > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, > > > > then > > > > the pipe_update_start call schedules itself out to check back > > > > later. > > > > > > > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 > > > > but > > > > lags w.r.t core kernel code, hot plugging an external display > > > > triggers > > > > tons of "potential atomic update errors" in the dmesg, on *pipe A*. > > > > A > > > > closer analysis reveals that we try to read the scanline 3 times > > > > and > > > > eventually timeout, b/c PSR hasn't exited fully leading to a > > > > PIPEDSL > > > > stuck @ 1599. This issue is not seen on upstream kernels, b/c for > > > > *some* > > > > reason we loop inside intel_pipe_update start for ~2+ msec which in > > > > this > > > > case is more than enough to exit PSR fully, hence an *unstuck* > > > > PIPEDSL > > > > counter, hence no error. On the other hand, the ChromeOS kernel > > > > spends > > > > ~1.1 msec looping inside intel_pipe_update_start and hence errors > > > > out > > > > b/c the source is still in PSR. > > > > > > > > Regardless, we should wait for PSR exit (if PSR is supported and > > > > active > > > > on the current pipe) before reading the PIPEDSL, b/c if we haven't > > > > fully exited PSR, then checking for vblank evasion isn't actually > > > > applicable. > > > > > > > > This scenario applies to a configuration with an additional pipe, > > > > as of now > > > > > > > > Signed-off-by: Tarun Vyas > > > > --- > > > > drivers/gpu/drm/i915/intel_sprite.c | 7 +-- > > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > > > b/drivers/gpu/drm/i915/intel_sprite.c > > > > index ee23613f9fd4..481d310e5c3b 100644 > > > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > > > @@ -107,14 +107,17 @@ void intel_pipe_update_start(const struct > > > > intel_crtc_state *new_crtc_state) > > > > VBLANK_EVASI > > > > ON > > > > _TIME_US); > > > > max = vblank_start - 1; > > > > > > > > - local_irq_disable(); > > > > - > > > > if (min <= 0 || max <= 0) > > > > return; > > > > > > > > if (WARN_ON(drm_crtc_vblank_get(>base))) > > > > return; > > > > > > > > + if(new_crtc_state->has_psr && dev_priv->psr.active) > > > > + psr_wait_for_idle(dev_priv); > > > How about just waiting for PSR_STATUS to idle without grabbing any > > > locks or checking whether PSR is active? > > > > > > Status should be idle if PSR was disabled or on it's way to becoming > > > idle if it was enabled. Even if PSR did get enabled while we are in > > > pipe_update_start(), it will not be active as long as VBIs are > > > enabled. > > > > Right, if we are OK with some duplication (of psr_wait_for_idle) inside > intel_psr.c, then we can duplicate the PSR2 vs. PSR check that's being done > in psr_wait_for_idle and then just wait without grabbing any locks, so > essentially a lockless version of psr_wait_for_idle() > > Correct me if this was already considered, why not wait until the > > scanline counter starts moving? I see we have a > > intel_wait_for_pipe_scanline_moving(crtc) that's used when the > > pipe is enabled. > > > > -DK > > Didn't consider this before, but, pipe_scanline_is_moving waits for a minimum > of 5 msec. Are we OK with a min wait of 5 msec inside pipe_update_start ? > Heuristically, waiting for PSR idle has almost always returned within < 2 > msec. Occasionally it takes upto 1 full frame. As per some preliminary measurements Approach 1: Wait *unconditionally* (so no need to check for PSR enabled/disabled and hence no locks) for PSR_STATUS to IDLE out. This takes ~7msec when PSR is active and ~2 usec when PSR is inactive/disabled. Approach 2: Use intel_wait_for_pipe_scanline_moving to wait for PIPEDSL to start moving after PSR exit. Currently, this ends up waiting for a minimum of 5 msec but I changed this to accept a caller defined value for the delay. After the above changes, this approach takes ~7msec when PSR is active and ~25-40 usec with PSR disabled, b/c we still need to check for at least 10+ usec and see if PIPEDSL moved, if it did, we wait for longer, otherwise we move on. ___ 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: Enable hw workaround to bypass alpha (rev2)
== Series Details == Series: drm/i915: Enable hw workaround to bypass alpha (rev2) URL : https://patchwork.freedesktop.org/series/45173/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359_full -> Patchwork_9384_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9384_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: PASS -> FAIL (fdo#105347) igt@drv_selftest@live_hangcheck: shard-kbl: NOTRUN -> DMESG-FAIL (fdo#106560, fdo#106947) shard-apl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-kbl: PASS -> FAIL (fdo#105363, fdo#102887) igt@kms_flip@plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) +1 igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) +1 igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@drv_selftest@live_hugepages: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS 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#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 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 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 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_4359 -> Patchwork_9384 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9384: d054ad3f8cdffbdfdc964839b966b1304a761439 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9384/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/24] drm/i915/icl: implement the tc/legacy HPD {dis, }connect flow for DP
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Paulo Zanoni
>Sent: Monday, May 21, 2018 5:26 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Zanoni, Paulo R
>Subject: [Intel-gfx] [PATCH 20/24] drm/i915/icl: implement the tc/legacy HPD
>{dis, }connect flow for DP
>
>Implement the DFLEXDPPMS/DFLEXDPCSSS dance for DisplayPort. These
>functions need to be called during HPD assert/deassert, but due to how our
>driver
>works it's much simpler if we always call them when
>icl_digital_port_connected() is called, which means we won't call them exactly
>once per HPD event. This should also cover the connected boot case, whatever
>the BIOS does.
>
>We're still missing the HDMI case, which should be implemented in the next
>patch.
>
>Also notice that, today, the BSpec pages for the DFLEXDPPMS and DFLEXDPCSSS
>registers are wrong, so you should only trust the flows described by the "Gen11
>TypeC Programming" page in our spec.
>
>Cc: Animesh Manna
>Signed-off-by: Paulo Zanoni
>---
> drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_dp.c |
>57 -
> 2 files changed, 62 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index 24308d4435f5..42cbace4c61e 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -10027,4 +10027,10 @@ enum skl_power_gate {
>_ICL_PHY_MISC_B)
> #define ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN (1 << 23)
>
>+#define PORT_TX_DFLEXDPPMS
> _MMIO(0x163890)
>+#define DP_PHY_MODE_STATUS_COMPLETED(tc_port) (1 <<
>(tc_port))
>+
>+#define PORT_TX_DFLEXDPCSSS
> _MMIO(0x163894)
>+#define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)(1 << (tc_port))
>+
> #endif /* _I915_REG_H_ */
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index f3d5b9eed625..f25f871e7c22 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -4762,6 +4762,56 @@ static void icl_update_tc_port_type(struct
>drm_i915_private *dev_priv,
> type_str);
> }
>
>+static bool icl_tc_phy_mode_status_connect(struct drm_i915_private *dev_priv,
>+ struct intel_digital_port *dig_port)
>{
>+ enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
>+ u32 val;
>+
>+ if (dig_port->tc_type != TC_PORT_LEGACY &&
>+ dig_port->tc_type != TC_PORT_TYPEC)
>+ return true;
Shouldn’t this return false?
>+ val = I915_READ(PORT_TX_DFLEXDPPMS);
>+ if (!(val & DP_PHY_MODE_STATUS_COMPLETED(tc_port))) {
>+ DRM_ERROR("DP PHY for TC port %d not ready\n", tc_port);
>+ return false;
>+ }
>+
>+ /*
>+ * This function may be called many times in a row without an HPD event
>+ * in between, so try to avoid the write when we can.
>+ */
>+ val = I915_READ(PORT_TX_DFLEXDPCSSS);
>+ if (!(val & DP_PHY_MODE_STATUS_NOT_SAFE(tc_port))) {
>+ val |= DP_PHY_MODE_STATUS_NOT_SAFE(tc_port);
>+ I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
>+ }
>+
>+ return true;
>+}
>+
>+static void icl_tc_phy_mode_status_disconnect(struct drm_i915_private
>*dev_priv,
>+struct intel_digital_port
>*dig_port) {
>+ enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
>+ u32 val;
>+
>+ if (dig_port->tc_type != TC_PORT_LEGACY &&
>+ dig_port->tc_type != TC_PORT_TYPEC)
>+ return;
>+
>+ /*
>+ * This function may be called many times in a row without an HPD event
>+ * in between, so try to avoid the write when we can.
>+ */
So, in the sequences to enable, it does tell that enabling suitable aux power
domains is optional. But in the disable sequence, disable AUX_PWR is mentioned
as a non-optional step.
In which case it has to be before we set DFLEXDPCSSS register to 0.
Is it being addressed in another patch?
The rest of the patch looks good.
Anusha
>+ val = I915_READ(PORT_TX_DFLEXDPCSSS);
>+ if (val & DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)) {
>+ val &= ~DP_PHY_MODE_STATUS_NOT_SAFE(tc_port);
>+ I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
>+ }
>+}
>+
> static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
> struct intel_digital_port *intel_dig_port) {
> @@
>-4782,12 +4832,17 @@ static bool icl_tc_port_connected(struct
>drm_i915_private *dev_priv,
> if (cpu_isr & tbt_bit)
> is_tbt = true;
>
>- if (!is_legacy && !is_typec && !is_tbt)
>+ if (!is_legacy && !is_typec && !is_tbt) {
>+ icl_tc_phy_mode_status_disconnect(dev_priv, intel_dig_port);
> return false;
>+ }
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/5] drm/i915/psr: Remove intel_crtc_state parameter from disable()
== Series Details == Series: series starting with [v6,1/5] drm/i915/psr: Remove intel_crtc_state parameter from disable() URL : https://patchwork.freedesktop.org/series/45200/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4365 -> Patchwork_9389 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45200/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9389 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-cfl-guc: PASS -> DMESG-WARN (fdo#106954) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-glk-j4005: NOTRUN -> FAIL (fdo#103481) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@debugfs_test@read_all_entries: 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#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106954 https://bugs.freedesktop.org/show_bug.cgi?id=106954 == Participating hosts (42 -> 37) == Additional (1): fi-glk-j4005 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4365 -> Patchwork_9389 CI_DRM_4365: 1502cd264cf44201245175984fb4c03c89299bfc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9389: b4b015f9cc4723f318567798d9156af58f05c479 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b4b015f9cc47 drm/i915/psr: Enable CRC check in the static frame on the sink side 65bca4ff6837 drm/i915/psr: Avoid PSR exit max time timeout 1e62f85f16b1 drm/i915/psr: Handle PSR errors d4d8483bbead drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink 89a674d64c8a drm/i915/psr: Remove intel_crtc_state parameter from disable() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9389/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 [v6,1/5] drm/i915/psr: Remove intel_crtc_state parameter from disable()
== Series Details == Series: series starting with [v6,1/5] drm/i915/psr: Remove intel_crtc_state parameter from disable() URL : https://patchwork.freedesktop.org/series/45200/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/psr: Remove intel_crtc_state parameter from disable() -drivers/gpu/drm/i915/selftests/../i915_drv.h:3680:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3679:16: warning: expression using sizeof(void) Commit: drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink Okay! Commit: drm/i915/psr: Handle PSR errors Okay! Commit: drm/i915/psr: Avoid PSR exit max time timeout Okay! Commit: drm/i915/psr: Enable CRC check in the static frame on the sink side Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 5/5] drm/i915/psr: Enable CRC check in the static frame on the sink side
Sink can be configured to calculate the CRC over the static frame and
compare with the CRC calculated and transmited in the VSC SDP by
source, if there is a mismatch sink will do a short pulse in HPD
and set DP_PSR_LINK_CRC_ERROR in DP_PSR_ERROR_STATUS.
Spec: 7723
v6:
andling DP_PSR_LINK_CRC_ERROR here and remove "bdw+" from commit
message
v4:
patch moved to after 'drm/i915/psr: Avoid PSR exit max time timeout'
to avoid touch in 2 patches EDP_PSR_DEBUG.
v3:
disabling PSR instead of exiting on error
Reviewed-by: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index caad19f5f557..43db91c19f52 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4044,6 +4044,7 @@ enum {
#define EDP_PSR_SKIP_AUX_EXIT(1 << 12)
#define EDP_PSR_TP1_TP2_SEL (0 << 11)
#define EDP_PSR_TP1_TP3_SEL (1 << 11)
+#define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */
#define EDP_PSR_TP2_TP3_TIME_500us (0 << 8)
#define EDP_PSR_TP2_TP3_TIME_100us (1 << 8)
#define EDP_PSR_TP2_TP3_TIME_2500us (2 << 8)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 11d728770196..bdb644268edb 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -360,6 +360,8 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
if (dev_priv->psr.link_standby)
dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
+ if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8)
+ dpcd_val |= DP_PSR_CRC_VERIFICATION;
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
@@ -415,6 +417,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
else
val |= EDP_PSR_TP1_TP2_SEL;
+ if (INTEL_GEN(dev_priv) >= 8)
+ val |= EDP_PSR_CRC_ENABLE;
+
val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK;
I915_WRITE(EDP_PSR_CTL, val);
}
@@ -1012,7 +1017,8 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
struct i915_psr *psr = _priv->psr;
u8 val;
const u8 errors = DP_PSR_RFB_STORAGE_ERROR |
- DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR;
+ DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
+ DP_PSR_LINK_CRC_ERROR;
if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
return;
@@ -1041,6 +1047,8 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("PSR RFB storage error, disabling PSR\n");
if (val & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
DRM_DEBUG_KMS("PSR VSC SDP uncorrectable error, disabling
PSR\n");
+ if (val & DP_PSR_LINK_CRC_ERROR)
+ DRM_ERROR("PSR Link CRC error, disabling PSR\n");
if (val & ~errors)
DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/5] drm/i915/psr: Remove intel_crtc_state parameter from disable()
It was only used in VLV/CHV so after the removal of the PSR support
for those platforms it is not necessary any more.
Reviewed-by: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/intel_psr.c | 5 ++---
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6f08ab310118..abda7500584f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -634,8 +634,7 @@ struct i915_psr {
void (*enable_source)(struct intel_dp *,
const struct intel_crtc_state *);
- void (*disable_source)(struct intel_dp *,
- const struct intel_crtc_state *);
+ void (*disable_source)(struct intel_dp *intel_dp);
void (*enable_sink)(struct intel_dp *);
void (*activate)(struct intel_dp *);
void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index aea81ace854b..0148d915b476 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -677,8 +677,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
mutex_unlock(_priv->psr.lock);
}
-static void hsw_psr_disable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *old_crtc_state)
+static void hsw_psr_disable(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
@@ -747,7 +746,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
return;
}
- dev_priv->psr.disable_source(intel_dp, old_crtc_state);
+ dev_priv->psr.disable_source(intel_dp);
/* Disable PSR on Sink */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/5] drm/i915/psr: Handle PSR errors
Sink will interrupt source when it have any PSR error.
DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR is a PSR2 but already
handling it here.
The only missing error to be handled is DP_PSR_LINK_CRC_ERROR that
will be taken in care in a futher patch.
v6:
not handling DP_PSR_LINK_CRC_ERROR here
v5:
handling all PSR errors here, so the commit message and
comment have changed
v3:
disabling PSR instead of exiting on error
Cc: Rodrigo Vivi
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 458e5305fd0a..7755365e955d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1010,6 +1010,8 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_psr *psr = _priv->psr;
u8 val;
+ const u8 errors = DP_PSR_RFB_STORAGE_ERROR |
+ DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR;
if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
return;
@@ -1029,7 +1031,25 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
intel_psr_disable_locked(intel_dp);
}
- /* TODO: handle other PSR/PSR2 errors */
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_ERROR_STATUS, ) != 1) {
+ DRM_ERROR("PSR_ERROR_STATUS dpcd read failed\n");
+ goto exit;
+ }
+
+ if (val & DP_PSR_RFB_STORAGE_ERROR)
+ DRM_DEBUG_KMS("PSR RFB storage error, disabling PSR\n");
+ if (val & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
+ DRM_DEBUG_KMS("PSR VSC SDP uncorrectable error, disabling
PSR\n");
+
+ if (val & ~errors)
+ DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
+ val & ~errors);
+ if (val & errors)
+ intel_psr_disable_locked(intel_dp);
+ /* clear status register */
+ drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
+
+ /* TODO: handle PSR2 errors */
exit:
mutex_unlock(>lock);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/5] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
eDP spec states that sink device will do a short pulse in HPD
line when there is a PSR/PSR2 error that needs to be handled by
source, this is handling the first and most simples error:
DP_PSR_SINK_INTERNAL_ERROR.
Here taking the safest approach and disabling PSR(at least until
the next modeset), to avoid multiple rendering issues due to
bad pannels.
v5:
added lockdep_assert in psr_disable and renamed psr_disable()
to intel_psr_disable_locked()
v4:
Using CAN_PSR instead of HAS_PSR in intel_psr_short_pulse
v3:
disabling PSR instead of exiting on error
Reviewed-by: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 62 ++--
3 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c1b2f00f324b..5be07e1d816d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4491,6 +4491,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
if (intel_dp_needs_link_retrain(intel_dp))
return false;
+ intel_psr_short_pulse(intel_dp);
+
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
/* Send a Hotplug Uevent to userspace to start modeset */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 578346b8d7e2..9d6a3b081d7b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1920,6 +1920,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state);
void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug);
void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir);
+void intel_psr_short_pulse(struct intel_dp *intel_dp);
/* intel_runtime_pm.c */
int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 0148d915b476..458e5305fd0a 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -720,6 +720,25 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
psr_aux_io_power_put(intel_dp);
}
+static void intel_psr_disable_locked(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ lockdep_assert_held(_priv->psr.lock);
+
+ if (!dev_priv->psr.enabled)
+ return;
+
+ dev_priv->psr.disable_source(intel_dp);
+
+ /* Disable PSR on Sink */
+ drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
+
+ dev_priv->psr.enabled = NULL;
+}
+
/**
* intel_psr_disable - Disable PSR
* @intel_dp: Intel DP
@@ -741,17 +760,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
return;
mutex_lock(_priv->psr.lock);
- if (!dev_priv->psr.enabled) {
- mutex_unlock(_priv->psr.lock);
- return;
- }
-
- dev_priv->psr.disable_source(intel_dp);
-
- /* Disable PSR on Sink */
- drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
-
- dev_priv->psr.enabled = NULL;
+ intel_psr_disable_locked(intel_dp);
mutex_unlock(_priv->psr.lock);
cancel_work_sync(_priv->psr.work);
}
@@ -993,3 +1002,34 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
dev_priv->psr.setup_vsc = hsw_psr_setup_vsc;
}
+
+void intel_psr_short_pulse(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct i915_psr *psr = _priv->psr;
+ u8 val;
+
+ if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
+ return;
+
+ mutex_lock(>lock);
+
+ if (psr->enabled != intel_dp)
+ goto exit;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, ) != 1) {
+ DRM_ERROR("PSR_STATUS dpcd read failed\n");
+ goto exit;
+ }
+
+ if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) {
+ DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
+ intel_psr_disable_locked(intel_dp);
+ }
+
+ /* TODO: handle other PSR/PSR2 errors */
+exit:
+ mutex_unlock(>lock);
+}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 4/5] drm/i915/psr: Avoid PSR exit max time timeout
Specification requires that max time should be masked from bdw and forward but it can be also safely enabled to hsw. This will make PSR exits more deterministic and only when really needed. If this was used to fix a issue in some panel than can only self-refresh for a few seconds, that panel will interrupt and assert one of the PSR errors handled in: 'drm/i915/psr: Handle PSR RFB storage error' and 'drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink' Spec: 21664 v4: patch moved to before 'drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side' to avoid touch in 2 patches EDP_PSR_DEBUG. Cc: Rodrigo Vivi Reviewed-by: Dhinakaran Pandiyan Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/intel_psr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 7755365e955d..11d728770196 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -632,7 +632,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp, EDP_PSR_DEBUG_MASK_MEMUP | EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP | - EDP_PSR_DEBUG_MASK_DISP_REG_WRITE); + EDP_PSR_DEBUG_MASK_DISP_REG_WRITE | + EDP_PSR_DEBUG_MASK_MAX_SLEEP); } } -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2] drm/i915: Enable hw workaround to bypass alpha
On Thu, Jun 21, 2018 at 08:43:56PM +0530, Vandita Kulkarni wrote:
> Alpha blending with alpha 0 and 0xff passes through
> alpha math and rounding logic causing differences
> compared to fully transparent or opaque plane,resulting
> in CRC mismatch.
> This WA on icl and above enables hardware to bypass alpha
> math and rounding for per pixel alpha values of 00 and 0xff
>
> v2: Fix patchwork checkpatch warnings.
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8
> drivers/gpu/drm/i915/intel_display.c | 12
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4bfd7a9..b66ec9b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7366,6 +7366,14 @@ enum {
> #define BDW_SCRATCH1 _MMIO(0xb11c)
> #define GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
>
> +/*GEN11 chicken */
> +#define _PIPEA_CHICKEN 0x70038
> +#define _PIPEB_CHICKEN 0x71038
> +#define _PIPEC_CHICKEN 0x72038
> +#define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
> +#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
> +_PIPEB_CHICKEN)
> +
> /* PCH */
>
> /* south display engine interrupt: IBX */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2c8fef3..3d849ec 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5632,6 +5632,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> struct intel_atomic_state *old_intel_state =
> to_intel_atomic_state(old_state);
> bool psl_clkgate_wa;
> + u32 pipe_chicken;
>
> if (WARN_ON(intel_crtc->active))
> return;
> @@ -5691,6 +5692,17 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
>*/
> intel_color_load_luts(_config->base);
>
> + /*
> + * Display WA #1153: enable hardware to bypass the alpha math
> + * and rounding for per-pixel values 00 and 0xff
> + */
> + if (INTEL_GEN(dev_priv) >= 11) {
> + pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
> + if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
> + I915_WRITE_FW(PIPE_CHICKEN(pipe),
> + pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN);
> + }
This would enable the wa by default for gen > 11. Would this impact for non 00,
0xff alpha cases?
In other words, should we enable the wa only when alpha is 00/0xff and not
enable for other values?
Thanks,
Radhakrishna(RK) Sripada
> +
> intel_ddi_set_pipe_settings(pipe_config);
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_ddi_enable_transcoder_func(pipe_config);
> --
> 1.9.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 v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
On 6/21/2018 11:43 AM, Kumar, Abhay wrote:
+ Wenkai
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Abhay Kumar
Sent: Tuesday, June 19, 2018 3:01 PM
To: intel-gfx@lists.freedesktop.org; Syrjala, Ville
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when
audio power is enabled
From: Ville Syrjälä
CDCLK has to be at least twice the BLCK regardless of audio. Audio driver has
to probe using this hook and increase the clock even in absence of any display.
v2: Use atomic refcount for get_power, put_power so that we can
call each once(Abhay).
v3: Reset power well 2 to avoid any transaction on iDisp link
during cdclk change(Abhay).
v4: Remove Power well 2 reset workaround(Ville).
v5: Remove unwanted Power well 2 register defined in v4(Abhay).
Signed-off-by: Ville Syrjälä
Signed-off-by: Abhay Kumar
Tested-by: Wenkai Du
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/intel_audio.c | 67 +---
drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
drivers/gpu/drm/i915/intel_display.c | 7 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
5 files changed, 83 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6104d7115054..a4a386a5db69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1702,6 +1702,7 @@ struct drm_i915_private {
unsigned int hpll_freq;
unsigned int fdi_pll_freq;
unsigned int czclk_freq;
+ u32 get_put_refcount;
struct {
/*
@@ -1719,6 +1720,8 @@ struct drm_i915_private {
struct intel_cdclk_state actual;
/* The current hardware cdclk state */
struct intel_cdclk_state hw;
+
+ int force_min_cdclk;
} cdclk;
/**
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 3ea566f99450..ca8f04c7cbb3 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
if (!connector->eld[0])
return;
-
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id,
connector->name,
@@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
*dev_priv)
}
}
+static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
+ bool enable)
+{
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_atomic_state *state;
+ int ret;
+
+ drm_modeset_acquire_init(, 0);
+ state = drm_atomic_state_alloc(_priv->drm);
+ if (WARN_ON(!state))
+ return;
+
+ state->acquire_ctx =
+
+retry:
+ to_intel_atomic_state(state)->modeset = true;
+ to_intel_atomic_state(state)->cdclk.force_min_cdclk =
+ enable ? 2 * 96000 : 0;
+
+ /*
+* Protects dev_priv->cdclk.force_min_cdclk
+* Need to lock this here in case we have no active pipes
+* and thus wouldn't lock it during the commit otherwise.
+*/
+ ret = drm_modeset_lock(_priv->drm.mode_config.connection_mutex,
);
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ drm_modeset_backoff();
+ goto retry;
+ }
+
+ WARN_ON(ret);
+
+ drm_atomic_state_put(state);
+
+ drm_modeset_drop_locks();
+ drm_modeset_acquire_fini();
+}
+
static void i915_audio_component_get_power(struct device *kdev) {
- intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount++;
+
+ /* Force cdclk to 2*BCLK during first time get power call */
+ if (dev_priv->get_put_refcount == 1)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, true);
+
+ intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
}
static void i915_audio_component_put_power(struct device *kdev) {
- intel_display_power_put(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount--;
+
+ /* Force required cdclk during last time put power call */
+ if (dev_priv->get_put_refcount == 0)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, false);
+
+ intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
}
static void i915_audio_component_codec_wake_override(struct device
Re: [Intel-gfx] [PATCH v3] drm/i915/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 01:28:40PM -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-06-21 at 22:54 +0300, Imre Deak wrote:
> > On Thu, Jun 21, 2018 at 01:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Thu, 2018-06-21 at 21:44 +0300, Imre Deak wrote:
> > > >
> > > > So far we got an AUX power domain reference only for the duration
> > > > of
> > > > DP
> > > > AUX transfers. However, the following suggests that we also need
> > > > these
> > > > for main link functionality:
> > > > - The specification doesn't state whether it's needed or not for
> > > > main
> > > > link functionality, but suggests that these power wells need to
> > > > be
> > > > enabled already during display core initialization (Sequences
> > > > to
> > > > Initialize Display).
> > > Hmm. The sequence also says "If an Aux channel will not be used, it
> > > does not need to be powered up."
> > Well, I consider that hints at not using the port at all for DP,
> > since
> > for DP you will need AUX.
> >
>
> I also see an instruction to "set PORT_CL_DW12_ Lane
> Enable Aux to 1b" for aux channels on combo ports. A quick check shows
> the register is not defined in the driver. My concern is we might be
> missing a step for combo ports.
It is added in the ICL power well enabling patch (see internal branch),
and is something I tested the above scenario with.
>
>
> > >
> > >
> > > >
> > > > - For PSR we need to keep the AUX power well enabled.
> > > > - On ICL combo PHY ports (non-TC) the AUX power well is needed
> > > > for
> > > > link training too: while the port is enabled with a DP link
> > > > training
> > > I don't see this in the spec, is this something you observed?
> > Yes.
> >
> > >
> > >
> > > >
> > > > test pattern trying to toggle the AUX power well will time out.
> > > Can we enable AUX power well before link training starts and
> > > disable
> > > after we are done training? Is that enough?
> > That was my first idea too, but given the rest of the points I
> > consider
> > it a safer option to enable it for main link functionality.
> >
> > >
> > >
> > > >
> > > > - On ICL MG PHY ports (TC) the AUX power well is needed also for
> > > > main
> > > > link functionality (both in DP and HDMI modes).
> > > > - Windows enables these power wells both for main and AUX lane
> > > > functionality.
> > > >
> > > > Based on the above take an AUX power reference for main link
> > > > functionality too. This makes a difference only on GEN10+ (GLK+)
> > > > platforms, where we have separate port specific AUX power wells.
> > > >
> > > > For PSR we still need to distinguish between port A and the other
> > > > ports, since on port A DC states must stay enabled for main link
> > > > functionality, but DC states must be disabled for driver
> > > > initiated
> > > > AUX transfers. So re-use the corresponding helper from
> > > > intel_psr.c.
> > > >
> > > > Since we take now a reference for main link functionality on all
> > > > DP
> > > > ports we can forgo taking the separate power ref for PSR
> > > > functionality.
> > > >
> > > > v2:
> > > > - Make sure DC states stay enabled when taking the ref on port A.
> > > > (Ville)
> > > >
> > > > v3: (Ville)
> > > > - Fix comment about logic for encoders without a crtc state and
> > > > add FIXME note for a simplification to avoid calling
> > > > get_power_domains
> > > > in such cases.
> > > > - Use intel_crtc_has_dp_encoder() instead
> > > > !intel_crtc_has_type(HDMI).
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Paulo Zanoni
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ddi.c| 54
> > > > ++---
> > > > drivers/gpu/drm/i915/intel_display.c| 12 +++-
> > > > drivers/gpu/drm/i915/intel_drv.h| 3 +-
> > > > drivers/gpu/drm/i915/intel_psr.c| 41 -
> > > >
> > > >
> > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
> > > > 5 files changed, 64 insertions(+), 47 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 044fe1fb9872..0319825b725b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -1983,15 +1983,55 @@ bool intel_ddi_get_hw_state(struct
> > > > intel_encoder *encoder,
> > > > return ret;
> > > > }
> > > >
> > > > -static u64 intel_ddi_get_power_domains(struct intel_encoder
> > > > *encoder)
> > > > +static inline enum intel_display_power_domain
> > > > +intel_ddi_main_link_aux_domain(struct intel_dp *intel_dp)
> > > > +{
> > > > + /* CNL HW requires corresponding AUX IOs to be powered
> > > > up
> > > > for PSR with
> > > > + * DC states enabled at the same time, while for driver
> > > > initiated AUX
> > > > + * transfers we need the same AUX IOs to be powered but
> > > > with
> > > > DC states
> > > > + *
Re: [Intel-gfx] [PATCH v3] drm/i915/ddi: Get AUX power domain for DP main link too
On Thu, 2018-06-21 at 22:54 +0300, Imre Deak wrote:
> On Thu, Jun 21, 2018 at 01:14:30PM -0700, Dhinakaran Pandiyan wrote:
> >
> > On Thu, 2018-06-21 at 21:44 +0300, Imre Deak wrote:
> > >
> > > So far we got an AUX power domain reference only for the duration
> > > of
> > > DP
> > > AUX transfers. However, the following suggests that we also need
> > > these
> > > for main link functionality:
> > > - The specification doesn't state whether it's needed or not for
> > > main
> > > link functionality, but suggests that these power wells need to
> > > be
> > > enabled already during display core initialization (Sequences
> > > to
> > > Initialize Display).
> > Hmm. The sequence also says "If an Aux channel will not be used, it
> > does not need to be powered up."
> Well, I consider that hints at not using the port at all for DP,
> since
> for DP you will need AUX.
>
I also see an instruction to "set PORT_CL_DW12_ Lane
Enable Aux to 1b" for aux channels on combo ports. A quick check shows
the register is not defined in the driver. My concern is we might be
missing a step for combo ports.
> >
> >
> > >
> > > - For PSR we need to keep the AUX power well enabled.
> > > - On ICL combo PHY ports (non-TC) the AUX power well is needed
> > > for
> > > link training too: while the port is enabled with a DP link
> > > training
> > I don't see this in the spec, is this something you observed?
> Yes.
>
> >
> >
> > >
> > > test pattern trying to toggle the AUX power well will time out.
> > Can we enable AUX power well before link training starts and
> > disable
> > after we are done training? Is that enough?
> That was my first idea too, but given the rest of the points I
> consider
> it a safer option to enable it for main link functionality.
>
> >
> >
> > >
> > > - On ICL MG PHY ports (TC) the AUX power well is needed also for
> > > main
> > > link functionality (both in DP and HDMI modes).
> > > - Windows enables these power wells both for main and AUX lane
> > > functionality.
> > >
> > > Based on the above take an AUX power reference for main link
> > > functionality too. This makes a difference only on GEN10+ (GLK+)
> > > platforms, where we have separate port specific AUX power wells.
> > >
> > > For PSR we still need to distinguish between port A and the other
> > > ports, since on port A DC states must stay enabled for main link
> > > functionality, but DC states must be disabled for driver
> > > initiated
> > > AUX transfers. So re-use the corresponding helper from
> > > intel_psr.c.
> > >
> > > Since we take now a reference for main link functionality on all
> > > DP
> > > ports we can forgo taking the separate power ref for PSR
> > > functionality.
> > >
> > > v2:
> > > - Make sure DC states stay enabled when taking the ref on port A.
> > > (Ville)
> > >
> > > v3: (Ville)
> > > - Fix comment about logic for encoders without a crtc state and
> > > add FIXME note for a simplification to avoid calling
> > > get_power_domains
> > > in such cases.
> > > - Use intel_crtc_has_dp_encoder() instead
> > > !intel_crtc_has_type(HDMI).
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Paulo Zanoni
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c| 54
> > > ++---
> > > drivers/gpu/drm/i915/intel_display.c| 12 +++-
> > > drivers/gpu/drm/i915/intel_drv.h| 3 +-
> > > drivers/gpu/drm/i915/intel_psr.c| 41 -
> > >
> > >
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
> > > 5 files changed, 64 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 044fe1fb9872..0319825b725b 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1983,15 +1983,55 @@ bool intel_ddi_get_hw_state(struct
> > > intel_encoder *encoder,
> > > return ret;
> > > }
> > >
> > > -static u64 intel_ddi_get_power_domains(struct intel_encoder
> > > *encoder)
> > > +static inline enum intel_display_power_domain
> > > +intel_ddi_main_link_aux_domain(struct intel_dp *intel_dp)
> > > +{
> > > + /* CNL HW requires corresponding AUX IOs to be powered
> > > up
> > > for PSR with
> > > + * DC states enabled at the same time, while for driver
> > > initiated AUX
> > > + * transfers we need the same AUX IOs to be powered but
> > > with
> > > DC states
> > > + * disabled. Accordingly use the AUX power domain here
> > > which
> > > leaves DC
> > > + * states enabled.
> > > + * However, for non-A AUX ports the corresponding non-
> > > EDP
> > > transcoders
> > > + * would have already enabled power well 2 and DC_OFF.
> > > This
> > > means we can
> > > + * acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference
> > > instead of a
> > > + * specific AUX_IO reference without powering up any
> > > extra
> > > wells.
> > > + * Note that PSR
Re: [Intel-gfx] [PATCH v3] drm/i915/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 01:14:30PM -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-06-21 at 21:44 +0300, Imre Deak wrote:
> > So far we got an AUX power domain reference only for the duration of
> > DP
> > AUX transfers. However, the following suggests that we also need
> > these
> > for main link functionality:
> > - The specification doesn't state whether it's needed or not for main
> > link functionality, but suggests that these power wells need to be
> > enabled already during display core initialization (Sequences to
> > Initialize Display).
> Hmm. The sequence also says "If an Aux channel will not be used, it
> does not need to be powered up."
Well, I consider that hints at not using the port at all for DP, since
for DP you will need AUX.
>
> > - For PSR we need to keep the AUX power well enabled.
> > - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> > link training too: while the port is enabled with a DP link
> > training
> I don't see this in the spec, is this something you observed?
Yes.
>
> > test pattern trying to toggle the AUX power well will time out.
>
> Can we enable AUX power well before link training starts and disable
> after we are done training? Is that enough?
That was my first idea too, but given the rest of the points I consider
it a safer option to enable it for main link functionality.
>
> > - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> > link functionality (both in DP and HDMI modes).
> > - Windows enables these power wells both for main and AUX lane
> > functionality.
> >
> > Based on the above take an AUX power reference for main link
> > functionality too. This makes a difference only on GEN10+ (GLK+)
> > platforms, where we have separate port specific AUX power wells.
> >
> > For PSR we still need to distinguish between port A and the other
> > ports, since on port A DC states must stay enabled for main link
> > functionality, but DC states must be disabled for driver initiated
> > AUX transfers. So re-use the corresponding helper from intel_psr.c.
> >
> > Since we take now a reference for main link functionality on all DP
> > ports we can forgo taking the separate power ref for PSR
> > functionality.
> >
> > v2:
> > - Make sure DC states stay enabled when taking the ref on port A.
> > (Ville)
> >
> > v3: (Ville)
> > - Fix comment about logic for encoders without a crtc state and
> > add FIXME note for a simplification to avoid calling
> > get_power_domains
> > in such cases.
> > - Use intel_crtc_has_dp_encoder() instead !intel_crtc_has_type(HDMI).
> >
> > Cc: Ville Syrjälä
> > Cc: Dhinakaran Pandiyan
> > Cc: Paulo Zanoni
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c| 54
> > ++---
> > drivers/gpu/drm/i915/intel_display.c| 12 +++-
> > drivers/gpu/drm/i915/intel_drv.h| 3 +-
> > drivers/gpu/drm/i915/intel_psr.c| 41 -
> >
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
> > 5 files changed, 64 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 044fe1fb9872..0319825b725b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1983,15 +1983,55 @@ bool intel_ddi_get_hw_state(struct
> > intel_encoder *encoder,
> > return ret;
> > }
> >
> > -static u64 intel_ddi_get_power_domains(struct intel_encoder
> > *encoder)
> > +static inline enum intel_display_power_domain
> > +intel_ddi_main_link_aux_domain(struct intel_dp *intel_dp)
> > +{
> > + /* CNL HW requires corresponding AUX IOs to be powered up
> > for PSR with
> > + * DC states enabled at the same time, while for driver
> > initiated AUX
> > + * transfers we need the same AUX IOs to be powered but with
> > DC states
> > + * disabled. Accordingly use the AUX power domain here which
> > leaves DC
> > + * states enabled.
> > + * However, for non-A AUX ports the corresponding non-EDP
> > transcoders
> > + * would have already enabled power well 2 and DC_OFF. This
> > means we can
> > + * acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference
> > instead of a
> > + * specific AUX_IO reference without powering up any extra
> > wells.
> > + * Note that PSR is enabled only on Port A even though this
> > function
> > + * returns the correct domain for other ports too.
> > + */
> > + return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A
> > :
> > + intel_dp-
> > >aux_power_domain;
> > +}
> > +
> > +static u64 intel_ddi_get_power_domains(struct intel_encoder
> > *encoder,
> > + struct intel_crtc_state
> > *crtc_state)
> > {
> > struct intel_digital_port *dig_port =
> > enc_to_dig_port(>base);
> > enum pipe pipe;
> > + u64 domains;
> >
> > - if (intel_ddi_get_hw_state(encoder,
Re: [Intel-gfx] [PATCH] drm/i915: Remove pointless if-else from sdvo code
Quoting Ville Syrjala (2018-06-21 18:46:58) > From: Ville Syrjälä > > The return value is a bool so we can just return the result of > the biwise AND. The compiler will take care of the rest. > > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/ddi: Get AUX power domain for DP main link too
On Thu, 2018-06-21 at 21:44 +0300, Imre Deak wrote:
> So far we got an AUX power domain reference only for the duration of
> DP
> AUX transfers. However, the following suggests that we also need
> these
> for main link functionality:
> - The specification doesn't state whether it's needed or not for main
> link functionality, but suggests that these power wells need to be
> enabled already during display core initialization (Sequences to
> Initialize Display).
Hmm. The sequence also says "If an Aux channel will not be used, it
does not need to be powered up."
> - For PSR we need to keep the AUX power well enabled.
> - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> link training too: while the port is enabled with a DP link
> training
I don't see this in the spec, is this something you observed?
> test pattern trying to toggle the AUX power well will time out.
Can we enable AUX power well before link training starts and disable
after we are done training? Is that enough?
> - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> link functionality (both in DP and HDMI modes).
> - Windows enables these power wells both for main and AUX lane
> functionality.
>
> Based on the above take an AUX power reference for main link
> functionality too. This makes a difference only on GEN10+ (GLK+)
> platforms, where we have separate port specific AUX power wells.
>
> For PSR we still need to distinguish between port A and the other
> ports, since on port A DC states must stay enabled for main link
> functionality, but DC states must be disabled for driver initiated
> AUX transfers. So re-use the corresponding helper from intel_psr.c.
>
> Since we take now a reference for main link functionality on all DP
> ports we can forgo taking the separate power ref for PSR
> functionality.
>
> v2:
> - Make sure DC states stay enabled when taking the ref on port A.
> (Ville)
>
> v3: (Ville)
> - Fix comment about logic for encoders without a crtc state and
> add FIXME note for a simplification to avoid calling
> get_power_domains
> in such cases.
> - Use intel_crtc_has_dp_encoder() instead !intel_crtc_has_type(HDMI).
>
> Cc: Ville Syrjälä
> Cc: Dhinakaran Pandiyan
> Cc: Paulo Zanoni
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_ddi.c| 54
> ++---
> drivers/gpu/drm/i915/intel_display.c| 12 +++-
> drivers/gpu/drm/i915/intel_drv.h| 3 +-
> drivers/gpu/drm/i915/intel_psr.c| 41 -
>
> drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
> 5 files changed, 64 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 044fe1fb9872..0319825b725b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1983,15 +1983,55 @@ bool intel_ddi_get_hw_state(struct
> intel_encoder *encoder,
> return ret;
> }
>
> -static u64 intel_ddi_get_power_domains(struct intel_encoder
> *encoder)
> +static inline enum intel_display_power_domain
> +intel_ddi_main_link_aux_domain(struct intel_dp *intel_dp)
> +{
> + /* CNL HW requires corresponding AUX IOs to be powered up
> for PSR with
> + * DC states enabled at the same time, while for driver
> initiated AUX
> + * transfers we need the same AUX IOs to be powered but with
> DC states
> + * disabled. Accordingly use the AUX power domain here which
> leaves DC
> + * states enabled.
> + * However, for non-A AUX ports the corresponding non-EDP
> transcoders
> + * would have already enabled power well 2 and DC_OFF. This
> means we can
> + * acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference
> instead of a
> + * specific AUX_IO reference without powering up any extra
> wells.
> + * Note that PSR is enabled only on Port A even though this
> function
> + * returns the correct domain for other ports too.
> + */
> + return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A
> :
> + intel_dp-
> >aux_power_domain;
> +}
> +
> +static u64 intel_ddi_get_power_domains(struct intel_encoder
> *encoder,
> + struct intel_crtc_state
> *crtc_state)
> {
> struct intel_digital_port *dig_port =
> enc_to_dig_port(>base);
> enum pipe pipe;
> + u64 domains;
>
> - if (intel_ddi_get_hw_state(encoder, ))
> - return BIT_ULL(dig_port->ddi_io_power_domain);
> + if (!intel_ddi_get_hw_state(encoder, ))
> + return 0;
>
> - return 0;
> + domains = BIT_ULL(dig_port->ddi_io_power_domain);
> + if (!crtc_state)
> + return domains;
> +
> + /*
> + * TODO: Add support for MST encoders. Atm, the following
> should never
> + * happen since this function will be called only for the
> primary
> + * encoder which doesn't have its own
Re: [Intel-gfx] [PATCH] drm/i915: Enable hw workaround to bypass alpha
On Thu, Jun 21, 2018 at 07:00:15PM +0530, Vandita Kulkarni wrote:
> Alpha blending with alpha 0 and 0xff passes through
> alpha math and rounding logic causing differences
> compared to fully transparent or opaque plane,resulting
> in CRC mismatch.
> This WA on icl and above enables hardware to bypass alpha
> math and rounding for per pixel alpha values of 00 and 0xff
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8
> drivers/gpu/drm/i915/intel_display.c | 12
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4bfd7a9..6e59bfe 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7366,6 +7366,14 @@ enum {
> #define BDW_SCRATCH1 _MMIO(0xb11c)
> #define GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
>
> +/*GEN11 chicken */
> +#define _PIPEA_CHICKEN 0x70038
> +#define _PIPEB_CHICKEN 0x71038
> +#define _PIPEC_CHICKEN 0x72038
> +#define PER_PIXEL_ALPHA_BYPASS_EN (1<<7)
> +#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
> +_PIPEB_CHICKEN)
> +
> /* PCH */
>
> /* south display engine interrupt: IBX */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2c8fef3..ca5882c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5632,6 +5632,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> struct intel_atomic_state *old_intel_state =
> to_intel_atomic_state(old_state);
> bool psl_clkgate_wa;
> + u32 pipe_chicken;
>
> if (WARN_ON(intel_crtc->active))
> return;
> @@ -5691,6 +5692,17 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
>*/
> intel_color_load_luts(_config->base);
>
> + /*
> + * Display WA #1153: enable hardware to bypass the alpha math
> + * and rounding for per-pixel values 00 and 0xff
> + */
This is an odd place for a register write. Why here instead of
init_clock_gating()?
> + if (INTEL_GEN(dev_priv) >= 11) {
> + pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
> + if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
> + I915_WRITE_FW(PIPE_CHICKEN(pipe),
> + pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN);
That check for the bit already being set is quite pointless.
> + }
> +
> intel_ddi_set_pipe_settings(pipe_config);
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_ddi_enable_transcoder_func(pipe_config);
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 v2] drm/i915: remove check for aux irq
On Thu, 2018-06-21 at 10:04 -0700, Lucas De Marchi wrote:
> On Tue, Jun 19, 2018 at 01:17:10PM -0700, Dhinakaran Pandiyan wrote:
> >
> > On Tue, 2018-06-19 at 08:24 -0700, Lucas De Marchi wrote:
> > >
> > > On Tue, Jun 19, 2018 at 7:06 AM Ville Syrjälä
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi
> > > > wrote:
> > > > >
> > > > >
> > > > > On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > This became dead code with commit 309bd8ed464f
> > > > > > > ("drm/i915:
> > > > > > > Reinstate
> > > > > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > > > >
> > > > > > > v2: Move comment about HW behavior to where decision is
> > > > > > > made
> > > > > > > to enable
> > > > > > > MSI (Ville).
> > > > > > >
> > > > > > > Cc: Ville Syrjälä
> > > > > > > Signed-off-by: Lucas De Marchi
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > > > > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > > > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > > > >
> > > > > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > > > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > > index 9c449b8d8eab..a1461de20472 100644
> > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > > @@ -1189,6 +1189,12 @@ static int
> > > > > > > i915_driver_init_hw(struct
> > > > > > > drm_i915_private *dev_priv)
> > > > > > > * get lost on g4x as well, and interrupt delivery
> > > > > > > seems to
> > > > > > > stay
> > > > > > > * properly dead afterwards. So we'll just disable them
> > > > > > > for
> > > > > > > all
> > > > > > > * pre-gen5 chipsets.
> > > > > > > + *
> > > > > > > + * dp aux and gmbus irq on gen4 seems to be able to
> > > > > > > generate legacy
> > > > > > > + * interrupts even when in MSI mode. This results in
> > > > > > > spurious
> > > > > > > + * interrupt warnings if the legacy irq no. is shared
> > > > > > > with
> > > > > > > another
> > > > > > > + * device. The kernel then disables that interrupt
> > > > > > > source
> > > > > > > and so
> > > > > > > + * prevents the other device from working properly.
> > > > > > > */
> > > > > > > if (INTEL_GEN(dev_priv) >= 5) {
> > > > > > > if (pci_enable_msi(pdev) < 0)
> > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > index b86ed6401120..c5e1f648c47c 100644
> > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > @@ -2558,16 +2558,6 @@ intel_info(const struct
> > > > > > > drm_i915_private *dev_priv)
> > > > > > > (IS_CANNONLAKE(dev_priv) || \
> > > > > > > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > > > > >
> > > > > > > -/*
> > > > > > > - * dp aux and gmbus irq on gen4 seems to be able to
> > > > > > > generate
> > > > > > > legacy interrupts
> > > > > > > - * even when in MSI mode. This results in spurious
> > > > > > > interrupt
> > > > > > > warnings if the
> > > > > > > - * legacy irq no. is shared with another device. The
> > > > > > > kernel
> > > > > > > then disables that
> > > > > > > - * interrupt source and so prevents the other device
> > > > > > > from
> > > > > > > working properly.
> > > > > > > - *
> > > > > > > - * Since we don't enable MSI anymore on gen4, we can
> > > > > > > always
> > > > > > > use GMBUS/AUX
> > > > > > > - * interrupts.
> > > > > > > - */
> > > > > > > -#define HAS_AUX_IRQ(dev_priv) true
> > > > > > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >=
> > > > > > > 4)
> > > > > > >
> > > > > > > /* With the 945 and later, Y tiling got adjusted so that
> > > > > > > it
> > > > > > > was 32 128-byte
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > index ce07bd794aed..1dab40056df7 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp
> > > > > > > *intel_dp)
> > > > > > > }
> > > > > > >
> > > > > > > static uint32_t
> > > > > > > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool
> > > > > > > has_aux_irq)
> > > > > > > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > > > > > > {
> > > > > > > struct drm_i915_private *dev_priv =
> > > > > > > to_i915(intel_dp_to_dev(intel_dp));
> > > > > > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > > > > > @@ -944,14 +944,10 @@
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ddi: Get AUX power domain for DP main link too (rev2)
== Series Details == Series: drm/i915/ddi: Get AUX power domain for DP main link too (rev2) URL : https://patchwork.freedesktop.org/series/45188/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4363 -> Patchwork_9388 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45188/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9388 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-FAIL (fdo#102614, fdo#106103) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (43 -> 37) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4363 -> Patchwork_9388 CI_DRM_4363: 9e52e63f91e95af0f7475ccce206d4bdfca8933a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9388: 6df9a07560c7c1343343e5d9332972e84a4c27bb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6df9a07560c7 drm/i915/ddi: Get AUX power domain for DP main link too == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9388/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/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 11:54:55AM -0700, Manasi Navare wrote:
> On Thu, Jun 21, 2018 at 09:18:55PM +0300, Imre Deak wrote:
> > On Thu, Jun 21, 2018 at 08:37:15PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 21, 2018 at 06:58:29PM +0300, Imre Deak wrote:
> > > > So far we got an AUX power domain reference only for the duration of DP
> > > > AUX transfers. However, the followings suggest that we also need these
> > > > for main link functionality:
> > > > - The specification doesn't state whether it's needed or not for main
> > > > link functionality, but suggests that these power wells need to be
> > > > enabled already during display core initialization (Sequences to
> > > > Initialize Display).
> > > > - For PSR we need to keep the AUX power well enabled.
> > > > - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> > > > link training too: while the port is enabled with a DP link training
> > > > test pattern trying to toggle the AUX power well will time out.
> > > > - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> > > > link functionality (both in DP and HDMI modes).
> > > > - Windows enables these power wells both for main and AUX lane
> > > > functionality.
> > > >
> > > > Based on the above take an AUX power reference for main link
> > > > functionality too. This makes a difference only on GEN10+ (GLK+)
> > > > platforms, where we have separate port specific AUX power well
>
> Currently I get AUX timeouts and unable to start link training on DP
> without disable_power_well=0 option set. I think the reason was that
> we were not getting the power domain for the AUX. So hopefully this
> patch should fix it.
Yes, that's because during link training - where the port is enabled
with a training pattern set - we can't enable the AUX power well, it'll
time out. B/c of that AUX transfers will time out too. After disabling
the training pattern and enabling the port for real video signals, AUX
enabling starts to work again..
--Imre
>
> Manasi
>
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Paulo Zanoni
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ddi.c | 33
> > > > +
> > > > drivers/gpu/drm/i915/intel_display.c | 12 +++-
> > > > drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> > > > 3 files changed, 42 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 044fe1fb9872..b09cb6969bbb 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -1983,15 +1983,36 @@ bool intel_ddi_get_hw_state(struct
> > > > intel_encoder *encoder,
> > > > return ret;
> > > > }
> > > >
> > > > -static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> > > > +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
> > > > + struct intel_crtc_state
> > > > *crtc_state)
> > > > {
> > > > struct intel_digital_port *dig_port =
> > > > enc_to_dig_port(>base);
> > > > enum pipe pipe;
> > > > + u64 domains;
> > > >
> > > > - if (intel_ddi_get_hw_state(encoder, ))
> > > > - return BIT_ULL(dig_port->ddi_io_power_domain);
> > > > + if (!intel_ddi_get_hw_state(encoder, ))
> > > > + return 0;
> > > >
> > > > - return 0;
> > > > + domains = BIT_ULL(dig_port->ddi_io_power_domain);
> > > > + if (!crtc_state)
> > > > + return domains;
> > > > +
> > > > + /*
> > > > +* TODO: Add support for MST encoders. Atm, the following
> > > > should never
> > > > +* happen since this function will be called only for the
> > > > primary
> > > > +* encoder which doesn't have its own pipe/crtc_state.
> > > > +*/
> > > > + if (WARN_ON(intel_crtc_has_type(crtc_state,
> > > > INTEL_OUTPUT_DP_MST)))
> > > > + return domains;
> > > > +
> > > > + /* AUX power is only needed for (e)DP mode, not for HDMI. */
> > > > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> > > > + struct intel_dp *intel_dp = _port->dp;
> > > > +
> > > > + domains |= BIT_ULL(intel_dp->aux_power_domain);
> > > > + }
> > > > +
> > > > + return domains;
> > > > }
> > > >
> > > > void intel_ddi_enable_pipe_clock(const struct intel_crtc_state
> > > > *crtc_state)
> > > > @@ -2631,6 +2652,8 @@ static void intel_ddi_pre_enable_dp(struct
> > > > intel_encoder *encoder,
> > > >
> > > > WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
> > > >
> > > > + intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
> > > > +
> > > > intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> > > >
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 09:18:55PM +0300, Imre Deak wrote:
> On Thu, Jun 21, 2018 at 08:37:15PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 21, 2018 at 06:58:29PM +0300, Imre Deak wrote:
> > > So far we got an AUX power domain reference only for the duration of DP
> > > AUX transfers. However, the followings suggest that we also need these
> > > for main link functionality:
> > > - The specification doesn't state whether it's needed or not for main
> > > link functionality, but suggests that these power wells need to be
> > > enabled already during display core initialization (Sequences to
> > > Initialize Display).
> > > - For PSR we need to keep the AUX power well enabled.
> > > - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> > > link training too: while the port is enabled with a DP link training
> > > test pattern trying to toggle the AUX power well will time out.
> > > - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> > > link functionality (both in DP and HDMI modes).
> > > - Windows enables these power wells both for main and AUX lane
> > > functionality.
> > >
> > > Based on the above take an AUX power reference for main link
> > > functionality too. This makes a difference only on GEN10+ (GLK+)
> > > platforms, where we have separate port specific AUX power well
Currently I get AUX timeouts and unable to start link training
on DP without disable_power_well=0 option set.
I think the reason was that we were not getting the power domain for the AUX.
So hopefully this patch should fix it.
Manasi
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Paulo Zanoni
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c | 33
> > > +
> > > drivers/gpu/drm/i915/intel_display.c | 12 +++-
> > > drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> > > 3 files changed, 42 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 044fe1fb9872..b09cb6969bbb 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1983,15 +1983,36 @@ bool intel_ddi_get_hw_state(struct intel_encoder
> > > *encoder,
> > > return ret;
> > > }
> > >
> > > -static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> > > +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
> > > +struct intel_crtc_state *crtc_state)
> > > {
> > > struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> > > enum pipe pipe;
> > > + u64 domains;
> > >
> > > - if (intel_ddi_get_hw_state(encoder, ))
> > > - return BIT_ULL(dig_port->ddi_io_power_domain);
> > > + if (!intel_ddi_get_hw_state(encoder, ))
> > > + return 0;
> > >
> > > - return 0;
> > > + domains = BIT_ULL(dig_port->ddi_io_power_domain);
> > > + if (!crtc_state)
> > > + return domains;
> > > +
> > > + /*
> > > + * TODO: Add support for MST encoders. Atm, the following should never
> > > + * happen since this function will be called only for the primary
> > > + * encoder which doesn't have its own pipe/crtc_state.
> > > + */
> > > + if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
> > > + return domains;
> > > +
> > > + /* AUX power is only needed for (e)DP mode, not for HDMI. */
> > > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> > > + struct intel_dp *intel_dp = _port->dp;
> > > +
> > > + domains |= BIT_ULL(intel_dp->aux_power_domain);
> > > + }
> > > +
> > > + return domains;
> > > }
> > >
> > > void intel_ddi_enable_pipe_clock(const struct intel_crtc_state
> > > *crtc_state)
> > > @@ -2631,6 +2652,8 @@ static void intel_ddi_pre_enable_dp(struct
> > > intel_encoder *encoder,
> > >
> > > WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
> > >
> > > + intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
> > > +
> > > intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> > >crtc_state->lane_count, is_mst);
> > >
> > > @@ -2775,6 +2798,8 @@ static void intel_ddi_post_disable_dp(struct
> > > intel_encoder *encoder,
> > > intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
> > >
> > > intel_ddi_clk_disable(encoder);
> > > +
> > > + intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
> > > }
> > >
> > > static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 2c8fef3ede54..d9fefcec4b1a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -15676,11 +15676,21 @@ get_encoder_power_domains(struct
> > > drm_i915_private *dev_priv)
> > > for_each_intel_encoder(_priv->drm,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Enable hw workaround to bypass alpha
== Series Details == Series: drm/i915: Enable hw workaround to bypass alpha URL : https://patchwork.freedesktop.org/series/45173/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359_full -> Patchwork_9383_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9383_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-apl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) shard-glk: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@gem_ctx_switch@basic-all-light: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) +1 igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@drv_selftest@live_hugepages: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 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#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 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_4359 -> Patchwork_9383 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9383: 1c10ad664cb90e427538aa0b5c248ff1e28626c5 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9383/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/ddi: Get AUX power domain for DP main link too
So far we got an AUX power domain reference only for the duration of DP
AUX transfers. However, the following suggests that we also need these
for main link functionality:
- The specification doesn't state whether it's needed or not for main
link functionality, but suggests that these power wells need to be
enabled already during display core initialization (Sequences to
Initialize Display).
- For PSR we need to keep the AUX power well enabled.
- On ICL combo PHY ports (non-TC) the AUX power well is needed for
link training too: while the port is enabled with a DP link training
test pattern trying to toggle the AUX power well will time out.
- On ICL MG PHY ports (TC) the AUX power well is needed also for main
link functionality (both in DP and HDMI modes).
- Windows enables these power wells both for main and AUX lane
functionality.
Based on the above take an AUX power reference for main link
functionality too. This makes a difference only on GEN10+ (GLK+)
platforms, where we have separate port specific AUX power wells.
For PSR we still need to distinguish between port A and the other
ports, since on port A DC states must stay enabled for main link
functionality, but DC states must be disabled for driver initiated
AUX transfers. So re-use the corresponding helper from intel_psr.c.
Since we take now a reference for main link functionality on all DP
ports we can forgo taking the separate power ref for PSR functionality.
v2:
- Make sure DC states stay enabled when taking the ref on port A.
(Ville)
v3: (Ville)
- Fix comment about logic for encoders without a crtc state and
add FIXME note for a simplification to avoid calling get_power_domains
in such cases.
- Use intel_crtc_has_dp_encoder() instead !intel_crtc_has_type(HDMI).
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Paulo Zanoni
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c| 54 ++---
drivers/gpu/drm/i915/intel_display.c| 12 +++-
drivers/gpu/drm/i915/intel_drv.h| 3 +-
drivers/gpu/drm/i915/intel_psr.c| 41 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
5 files changed, 64 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 044fe1fb9872..0319825b725b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1983,15 +1983,55 @@ bool intel_ddi_get_hw_state(struct intel_encoder
*encoder,
return ret;
}
-static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
+static inline enum intel_display_power_domain
+intel_ddi_main_link_aux_domain(struct intel_dp *intel_dp)
+{
+ /* CNL HW requires corresponding AUX IOs to be powered up for PSR with
+* DC states enabled at the same time, while for driver initiated AUX
+* transfers we need the same AUX IOs to be powered but with DC states
+* disabled. Accordingly use the AUX power domain here which leaves DC
+* states enabled.
+* However, for non-A AUX ports the corresponding non-EDP transcoders
+* would have already enabled power well 2 and DC_OFF. This means we can
+* acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
+* specific AUX_IO reference without powering up any extra wells.
+* Note that PSR is enabled only on Port A even though this function
+* returns the correct domain for other ports too.
+*/
+ return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
+ intel_dp->aux_power_domain;
+}
+
+static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state)
{
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
enum pipe pipe;
+ u64 domains;
- if (intel_ddi_get_hw_state(encoder, ))
- return BIT_ULL(dig_port->ddi_io_power_domain);
+ if (!intel_ddi_get_hw_state(encoder, ))
+ return 0;
- return 0;
+ domains = BIT_ULL(dig_port->ddi_io_power_domain);
+ if (!crtc_state)
+ return domains;
+
+ /*
+* TODO: Add support for MST encoders. Atm, the following should never
+* happen since this function will be called only for the primary
+* encoder which doesn't have its own pipe/crtc_state.
+*/
+ if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
+ return domains;
+
+ /* AUX power is only needed for (e)DP mode, not for HDMI. */
+ if (intel_crtc_has_dp_encoder(crtc_state)) {
+ struct intel_dp *intel_dp = _port->dp;
+
+ domains |= BIT_ULL(intel_ddi_main_link_aux_domain(intel_dp));
+ }
+
+ return domains;
}
void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
@@ -2631,6 +2671,9 @@
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
+ Wenkai
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Abhay Kumar
Sent: Tuesday, June 19, 2018 3:01 PM
To: intel-gfx@lists.freedesktop.org; Syrjala, Ville
Cc: Nikula, Jani
Subject: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when
audio power is enabled
From: Ville Syrjälä
CDCLK has to be at least twice the BLCK regardless of audio. Audio driver has
to probe using this hook and increase the clock even in absence of any display.
v2: Use atomic refcount for get_power, put_power so that we can
call each once(Abhay).
v3: Reset power well 2 to avoid any transaction on iDisp link
during cdclk change(Abhay).
v4: Remove Power well 2 reset workaround(Ville).
v5: Remove unwanted Power well 2 register defined in v4(Abhay).
Signed-off-by: Ville Syrjälä
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/intel_audio.c | 67 +---
drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
drivers/gpu/drm/i915/intel_display.c | 7 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
5 files changed, 83 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6104d7115054..a4a386a5db69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1702,6 +1702,7 @@ struct drm_i915_private {
unsigned int hpll_freq;
unsigned int fdi_pll_freq;
unsigned int czclk_freq;
+ u32 get_put_refcount;
struct {
/*
@@ -1719,6 +1720,8 @@ struct drm_i915_private {
struct intel_cdclk_state actual;
/* The current hardware cdclk state */
struct intel_cdclk_state hw;
+
+ int force_min_cdclk;
} cdclk;
/**
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 3ea566f99450..ca8f04c7cbb3 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
if (!connector->eld[0])
return;
-
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id,
connector->name,
@@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
*dev_priv)
}
}
+static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
+ bool enable)
+{
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_atomic_state *state;
+ int ret;
+
+ drm_modeset_acquire_init(, 0);
+ state = drm_atomic_state_alloc(_priv->drm);
+ if (WARN_ON(!state))
+ return;
+
+ state->acquire_ctx =
+
+retry:
+ to_intel_atomic_state(state)->modeset = true;
+ to_intel_atomic_state(state)->cdclk.force_min_cdclk =
+ enable ? 2 * 96000 : 0;
+
+ /*
+* Protects dev_priv->cdclk.force_min_cdclk
+* Need to lock this here in case we have no active pipes
+* and thus wouldn't lock it during the commit otherwise.
+*/
+ ret = drm_modeset_lock(_priv->drm.mode_config.connection_mutex,
);
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ drm_modeset_backoff();
+ goto retry;
+ }
+
+ WARN_ON(ret);
+
+ drm_atomic_state_put(state);
+
+ drm_modeset_drop_locks();
+ drm_modeset_acquire_fini();
+}
+
static void i915_audio_component_get_power(struct device *kdev) {
- intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount++;
+
+ /* Force cdclk to 2*BCLK during first time get power call */
+ if (dev_priv->get_put_refcount == 1)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, true);
+
+ intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
}
static void i915_audio_component_put_power(struct device *kdev) {
- intel_display_power_put(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount--;
+
+ /* Force required cdclk during last time put power call */
+ if (dev_priv->get_put_refcount == 0)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, false);
+
+ intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
}
static void i915_audio_component_codec_wake_override(struct device *kdev, @@
-959,7 +1018,7 @@ void i915_audio_component_init(struct drm_i915_private
Re: [Intel-gfx] [PATCH] drm/i915: Enable hw workaround to bypass alpha
tor 2018-06-21 klockan 19:00 +0530 skrev Vandita Kulkarni:
> Alpha blending with alpha 0 and 0xff passes through
> alpha math and rounding logic causing differences
> compared to fully transparent or opaque plane,resulting
> in CRC mismatch.
> This WA on icl and above enables hardware to bypass alpha
> math and rounding for per pixel alpha values of 00 and 0xff
>
> Signed-off-by: Vandita Kulkarni
> ---
Thanks, pushed with my r-b. :)
> drivers/gpu/drm/i915/i915_reg.h | 8
> drivers/gpu/drm/i915/intel_display.c | 12
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 4bfd7a9..6e59bfe 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7366,6 +7366,14 @@ enum {
> #define BDW_SCRATCH1 _MMIO(0x
> b11c)
> #define GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
>
> +/*GEN11 chicken */
> +#define _PIPEA_CHICKEN 0x70038
> +#define _PIPEB_CHICKEN 0x71038
> +#define _PIPEC_CHICKEN 0x72038
> +#define PER_PIXEL_ALPHA_BYPASS_EN (1<<7)
> +#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe,
> _PIPEA_CHICKEN,\
> +_PIPEB_CHICKEN)
> +
> /* PCH */
>
> /* south display engine interrupt: IBX */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2c8fef3..ca5882c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5632,6 +5632,7 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
> struct intel_atomic_state *old_intel_state =
> to_intel_atomic_state(old_state);
> bool psl_clkgate_wa;
> + u32 pipe_chicken;
>
> if (WARN_ON(intel_crtc->active))
> return;
> @@ -5691,6 +5692,17 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
>*/
> intel_color_load_luts(_config->base);
>
> + /*
> + * Display WA #1153: enable hardware to bypass the alpha
> math
> + * and rounding for per-pixel values 00 and 0xff
> + */
> + if (INTEL_GEN(dev_priv) >= 11) {
> + pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
> + if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
> + I915_WRITE_FW(PIPE_CHICKEN(pipe),
> + pipe_chicken |
> PER_PIXEL_ALPHA_BYPASS_EN);
> + }
> +
> intel_ddi_set_pipe_settings(pipe_config);
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_ddi_enable_transcoder_func(pipe_config);
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove pointless if-else from sdvo code
== Series Details == Series: drm/i915: Remove pointless if-else from sdvo code URL : https://patchwork.freedesktop.org/series/45189/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4362 -> Patchwork_9387 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45189/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9387 that come from known issues: === IGT changes === Issues hit igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) Possible fixes igt@gem_ctx_create@basic-files: fi-skl-6700k2: INCOMPLETE (fdo#106988) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 37) == Additional (1): fi-bxt-dsi Missing(6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4362 -> Patchwork_9387 CI_DRM_4362: 7159c27349b070831dfb3512ca055c8dbcf9e1fc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9387: 4f50b56b76e1d57ecedeb6325f6cf3cbdb98ea46 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4f50b56b76e1 drm/i915: Remove pointless if-else from sdvo code == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9387/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/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 08:40:45PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 21, 2018 at 06:58:29PM +0300, Imre Deak wrote:
> > So far we got an AUX power domain reference only for the duration of DP
> > AUX transfers. However, the followings suggest that we also need these
> > for main link functionality:
> > - The specification doesn't state whether it's needed or not for main
> > link functionality, but suggests that these power wells need to be
> > enabled already during display core initialization (Sequences to
> > Initialize Display).
> > - For PSR we need to keep the AUX power well enabled.
> > - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> > link training too: while the port is enabled with a DP link training
> > test pattern trying to toggle the AUX power well will time out.
> > - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> > link functionality (both in DP and HDMI modes).
> > - Windows enables these power wells both for main and AUX lane
> > functionality.
> >
> > Based on the above take an AUX power reference for main link
> > functionality too. This makes a difference only on GEN10+ (GLK+)
> > platforms, where we have separate port specific AUX power wells.
> >
> > Cc: Ville Syrjälä
> > Cc: Dhinakaran Pandiyan
> > Cc: Paulo Zanoni
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 33 +
> > drivers/gpu/drm/i915/intel_display.c | 12 +++-
> > drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> > 3 files changed, 42 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 044fe1fb9872..b09cb6969bbb 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1983,15 +1983,36 @@ bool intel_ddi_get_hw_state(struct intel_encoder
> > *encoder,
> > return ret;
> > }
> >
> > -static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> > +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
> > + struct intel_crtc_state *crtc_state)
> > {
> > struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> > enum pipe pipe;
> > + u64 domains;
> >
> > - if (intel_ddi_get_hw_state(encoder, ))
> > - return BIT_ULL(dig_port->ddi_io_power_domain);
> > + if (!intel_ddi_get_hw_state(encoder, ))
> > + return 0;
> >
> > - return 0;
> > + domains = BIT_ULL(dig_port->ddi_io_power_domain);
> > + if (!crtc_state)
> > + return domains;
> > +
> > + /*
> > +* TODO: Add support for MST encoders. Atm, the following should never
> > +* happen since this function will be called only for the primary
> > +* encoder which doesn't have its own pipe/crtc_state.
> > +*/
> > + if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
> > + return domains;
> > +
> > + /* AUX power is only needed for (e)DP mode, not for HDMI. */
> > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
>
> I would use intel_crtc_has_dp_encoder() here so that one doesn't
> have to think "what is not HDMI?".
Ok, makes sense.
>
> > + struct intel_dp *intel_dp = _port->dp;
> > +
> > + domains |= BIT_ULL(intel_dp->aux_power_domain);
> > + }
> > +
> > + return domains;
> > }
> >
> > void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
> > @@ -2631,6 +2652,8 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> >
> > WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
> >
> > + intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
> > +
> > intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> > crtc_state->lane_count, is_mst);
> >
> > @@ -2775,6 +2798,8 @@ static void intel_ddi_post_disable_dp(struct
> > intel_encoder *encoder,
> > intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
> >
> > intel_ddi_clk_disable(encoder);
> > +
> > + intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
> > }
> >
> > static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 2c8fef3ede54..d9fefcec4b1a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15676,11 +15676,21 @@ get_encoder_power_domains(struct drm_i915_private
> > *dev_priv)
> > for_each_intel_encoder(_priv->drm, encoder) {
> > u64 get_domains;
> > enum intel_display_power_domain domain;
> > + struct intel_crtc_state *crtc_state;
> >
> > if (!encoder->get_power_domains)
> > continue;
> >
> > - get_domains = encoder->get_power_domains(encoder);
> > +
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 08:37:15PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 21, 2018 at 06:58:29PM +0300, Imre Deak wrote:
> > So far we got an AUX power domain reference only for the duration of DP
> > AUX transfers. However, the followings suggest that we also need these
> > for main link functionality:
> > - The specification doesn't state whether it's needed or not for main
> > link functionality, but suggests that these power wells need to be
> > enabled already during display core initialization (Sequences to
> > Initialize Display).
> > - For PSR we need to keep the AUX power well enabled.
> > - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> > link training too: while the port is enabled with a DP link training
> > test pattern trying to toggle the AUX power well will time out.
> > - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> > link functionality (both in DP and HDMI modes).
> > - Windows enables these power wells both for main and AUX lane
> > functionality.
> >
> > Based on the above take an AUX power reference for main link
> > functionality too. This makes a difference only on GEN10+ (GLK+)
> > platforms, where we have separate port specific AUX power wells.
> >
> > Cc: Ville Syrjälä
> > Cc: Dhinakaran Pandiyan
> > Cc: Paulo Zanoni
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 33 +
> > drivers/gpu/drm/i915/intel_display.c | 12 +++-
> > drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> > 3 files changed, 42 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 044fe1fb9872..b09cb6969bbb 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1983,15 +1983,36 @@ bool intel_ddi_get_hw_state(struct intel_encoder
> > *encoder,
> > return ret;
> > }
> >
> > -static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> > +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
> > + struct intel_crtc_state *crtc_state)
> > {
> > struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> > enum pipe pipe;
> > + u64 domains;
> >
> > - if (intel_ddi_get_hw_state(encoder, ))
> > - return BIT_ULL(dig_port->ddi_io_power_domain);
> > + if (!intel_ddi_get_hw_state(encoder, ))
> > + return 0;
> >
> > - return 0;
> > + domains = BIT_ULL(dig_port->ddi_io_power_domain);
> > + if (!crtc_state)
> > + return domains;
> > +
> > + /*
> > +* TODO: Add support for MST encoders. Atm, the following should never
> > +* happen since this function will be called only for the primary
> > +* encoder which doesn't have its own pipe/crtc_state.
> > +*/
> > + if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
> > + return domains;
> > +
> > + /* AUX power is only needed for (e)DP mode, not for HDMI. */
> > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> > + struct intel_dp *intel_dp = _port->dp;
> > +
> > + domains |= BIT_ULL(intel_dp->aux_power_domain);
> > + }
> > +
> > + return domains;
> > }
> >
> > void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
> > @@ -2631,6 +2652,8 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> >
> > WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
> >
> > + intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
> > +
> > intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> > crtc_state->lane_count, is_mst);
> >
> > @@ -2775,6 +2798,8 @@ static void intel_ddi_post_disable_dp(struct
> > intel_encoder *encoder,
> > intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
> >
> > intel_ddi_clk_disable(encoder);
> > +
> > + intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
> > }
> >
> > static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 2c8fef3ede54..d9fefcec4b1a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15676,11 +15676,21 @@ get_encoder_power_domains(struct drm_i915_private
> > *dev_priv)
> > for_each_intel_encoder(_priv->drm, encoder) {
> > u64 get_domains;
> > enum intel_display_power_domain domain;
> > + struct intel_crtc_state *crtc_state;
> >
> > if (!encoder->get_power_domains)
> > continue;
> >
> > - get_domains = encoder->get_power_domains(encoder);
> > + /*
> > +* In case of a dangling encoder without a crtc we still need
> > +* to get power domain
[Intel-gfx] [PATCH] drm/i915: Remove pointless if-else from sdvo code
From: Ville Syrjälä The return value is a bool so we can just return the result of the biwise AND. The compiler will take care of the rest. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sdvo.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index e6a64b3ecd91..c7f95c958660 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1400,10 +1400,7 @@ static bool intel_sdvo_connector_get_hw_state(struct intel_connector *connector) intel_sdvo_get_active_outputs(intel_sdvo, _outputs); - if (active_outputs & intel_sdvo_connector->output_flag) - return true; - else - return false; + return active_outputs & intel_sdvo_connector->output_flag; } bool intel_sdvo_port_enabled(struct drm_i915_private *dev_priv, -- 2.16.4 ___ 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/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 06:58:29PM +0300, Imre Deak wrote:
> So far we got an AUX power domain reference only for the duration of DP
> AUX transfers. However, the followings suggest that we also need these
> for main link functionality:
> - The specification doesn't state whether it's needed or not for main
> link functionality, but suggests that these power wells need to be
> enabled already during display core initialization (Sequences to
> Initialize Display).
> - For PSR we need to keep the AUX power well enabled.
> - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> link training too: while the port is enabled with a DP link training
> test pattern trying to toggle the AUX power well will time out.
> - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> link functionality (both in DP and HDMI modes).
> - Windows enables these power wells both for main and AUX lane
> functionality.
>
> Based on the above take an AUX power reference for main link
> functionality too. This makes a difference only on GEN10+ (GLK+)
> platforms, where we have separate port specific AUX power wells.
>
> Cc: Ville Syrjälä
> Cc: Dhinakaran Pandiyan
> Cc: Paulo Zanoni
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 33 +
> drivers/gpu/drm/i915/intel_display.c | 12 +++-
> drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> 3 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 044fe1fb9872..b09cb6969bbb 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1983,15 +1983,36 @@ bool intel_ddi_get_hw_state(struct intel_encoder
> *encoder,
> return ret;
> }
>
> -static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
> +struct intel_crtc_state *crtc_state)
> {
> struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> enum pipe pipe;
> + u64 domains;
>
> - if (intel_ddi_get_hw_state(encoder, ))
> - return BIT_ULL(dig_port->ddi_io_power_domain);
> + if (!intel_ddi_get_hw_state(encoder, ))
> + return 0;
>
> - return 0;
> + domains = BIT_ULL(dig_port->ddi_io_power_domain);
> + if (!crtc_state)
> + return domains;
> +
> + /*
> + * TODO: Add support for MST encoders. Atm, the following should never
> + * happen since this function will be called only for the primary
> + * encoder which doesn't have its own pipe/crtc_state.
> + */
> + if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
> + return domains;
> +
> + /* AUX power is only needed for (e)DP mode, not for HDMI. */
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
I would use intel_crtc_has_dp_encoder() here so that one doesn't
have to think "what is not HDMI?".
> + struct intel_dp *intel_dp = _port->dp;
> +
> + domains |= BIT_ULL(intel_dp->aux_power_domain);
> + }
> +
> + return domains;
> }
>
> void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
> @@ -2631,6 +2652,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>
> WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
>
> + intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
> +
> intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
>crtc_state->lane_count, is_mst);
>
> @@ -2775,6 +2798,8 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
> intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
>
> intel_ddi_clk_disable(encoder);
> +
> + intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
> }
>
> static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2c8fef3ede54..d9fefcec4b1a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15676,11 +15676,21 @@ get_encoder_power_domains(struct drm_i915_private
> *dev_priv)
> for_each_intel_encoder(_priv->drm, encoder) {
> u64 get_domains;
> enum intel_display_power_domain domain;
> + struct intel_crtc_state *crtc_state;
>
> if (!encoder->get_power_domains)
> continue;
>
> - get_domains = encoder->get_power_domains(encoder);
> + /*
> + * In case of a dangling encoder without a crtc we still need
> + * to get power domain refs. Such encoders will be disabled
> + * dropping these references.
> + */
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ddi: Get AUX power domain for DP main link too
== Series Details == Series: drm/i915/ddi: Get AUX power domain for DP main link too URL : https://patchwork.freedesktop.org/series/45188/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4362 -> Patchwork_9386 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45188/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9386 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-skl-guc: PASS -> DMESG-WARN (fdo#106954) Possible fixes igt@gem_ctx_create@basic-files: fi-skl-6700k2: INCOMPLETE (fdo#106988) -> PASS fdo#106954 https://bugs.freedesktop.org/show_bug.cgi?id=106954 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 37) == Additional (1): fi-bxt-dsi Missing(6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4362 -> Patchwork_9386 CI_DRM_4362: 7159c27349b070831dfb3512ca055c8dbcf9e1fc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9386: e686fff14a1c09cd8625de6fe968c0feea20f97c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e686fff14a1c drm/i915/ddi: Get AUX power domain for DP main link too == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9386/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/ddi: Get AUX power domain for DP main link too
On Thu, Jun 21, 2018 at 06:58:29PM +0300, Imre Deak wrote:
> So far we got an AUX power domain reference only for the duration of DP
> AUX transfers. However, the followings suggest that we also need these
> for main link functionality:
> - The specification doesn't state whether it's needed or not for main
> link functionality, but suggests that these power wells need to be
> enabled already during display core initialization (Sequences to
> Initialize Display).
> - For PSR we need to keep the AUX power well enabled.
> - On ICL combo PHY ports (non-TC) the AUX power well is needed for
> link training too: while the port is enabled with a DP link training
> test pattern trying to toggle the AUX power well will time out.
> - On ICL MG PHY ports (TC) the AUX power well is needed also for main
> link functionality (both in DP and HDMI modes).
> - Windows enables these power wells both for main and AUX lane
> functionality.
>
> Based on the above take an AUX power reference for main link
> functionality too. This makes a difference only on GEN10+ (GLK+)
> platforms, where we have separate port specific AUX power wells.
>
> Cc: Ville Syrjälä
> Cc: Dhinakaran Pandiyan
> Cc: Paulo Zanoni
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 33 +
> drivers/gpu/drm/i915/intel_display.c | 12 +++-
> drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> 3 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 044fe1fb9872..b09cb6969bbb 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1983,15 +1983,36 @@ bool intel_ddi_get_hw_state(struct intel_encoder
> *encoder,
> return ret;
> }
>
> -static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
> +struct intel_crtc_state *crtc_state)
> {
> struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> enum pipe pipe;
> + u64 domains;
>
> - if (intel_ddi_get_hw_state(encoder, ))
> - return BIT_ULL(dig_port->ddi_io_power_domain);
> + if (!intel_ddi_get_hw_state(encoder, ))
> + return 0;
>
> - return 0;
> + domains = BIT_ULL(dig_port->ddi_io_power_domain);
> + if (!crtc_state)
> + return domains;
> +
> + /*
> + * TODO: Add support for MST encoders. Atm, the following should never
> + * happen since this function will be called only for the primary
> + * encoder which doesn't have its own pipe/crtc_state.
> + */
> + if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
> + return domains;
> +
> + /* AUX power is only needed for (e)DP mode, not for HDMI. */
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> + struct intel_dp *intel_dp = _port->dp;
> +
> + domains |= BIT_ULL(intel_dp->aux_power_domain);
> + }
> +
> + return domains;
> }
>
> void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
> @@ -2631,6 +2652,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>
> WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
>
> + intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
> +
> intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
>crtc_state->lane_count, is_mst);
>
> @@ -2775,6 +2798,8 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
> intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
>
> intel_ddi_clk_disable(encoder);
> +
> + intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
> }
>
> static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2c8fef3ede54..d9fefcec4b1a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15676,11 +15676,21 @@ get_encoder_power_domains(struct drm_i915_private
> *dev_priv)
> for_each_intel_encoder(_priv->drm, encoder) {
> u64 get_domains;
> enum intel_display_power_domain domain;
> + struct intel_crtc_state *crtc_state;
>
> if (!encoder->get_power_domains)
> continue;
>
> - get_domains = encoder->get_power_domains(encoder);
> + /*
> + * In case of a dangling encoder without a crtc we still need
> + * to get power domain refs. Such encoders will be disabled
> + * dropping these references.
> + */
> + crtc_state = encoder->base.crtc ?
> +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/ddi: Get AUX power domain for DP main link too
== Series Details == Series: drm/i915/ddi: Get AUX power domain for DP main link too URL : https://patchwork.freedesktop.org/series/45188/ State : warning == Summary == $ dim checkpatch origin/drm-tip e686fff14a1c drm/i915/ddi: Get AUX power domain for DP main link too -:35: WARNING:TYPO_SPELLING: 'seperate' may be misspelled - perhaps 'separate'? #35: ports we can forgo taking the seperate power ref for PSR functionality. total: 0 errors, 1 warnings, 0 checks, 174 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation
Den 21.06.2018 09.14, skrev Daniel Vetter:
On Wed, Jun 20, 2018 at 05:28:10PM +0200, Noralf Trønnes wrote:
Den 20.06.2018 15.52, skrev Noralf Trønnes:
Den 20.06.2018 11.34, skrev Daniel Vetter:
On Mon, Jun 18, 2018 at 04:17:27PM +0200, Noralf Trønnes wrote:
This patchset adds generic fbdev emulation for drivers that
supports GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.
Notable changes since version 1:
- Rework client unregister code. I've used reference counting to manage
the fact that both the client itself and the driver through
drm_dev_unregister() can release the client. The client is
now released
using drm_client_put() instead of drm_client_free().
I started reviewing the reworked client register/unregister stuff,
and it
looks good, except this kref stuff here for clients. I don't understand
why you need this - as long as removal from dev->clientlist is properly
protected by the mutex, I don't see how both the client and the
device can
release the client at the same time. Of course this means that both the
device-trigger unregister and the client-triggered unregister must first
grab the mutex, remove the client from the list, and only if that
was done
succesfully, clean up the client. If the client is already removed from
the list (i.e. list_empty() is true) then you need to bail out to avoid
double-freeing.
I just suck at this :/
Use case:
Unloading client module at the same time as the device is unplugged.
Do we really want to be able to unload client modules? Atm you can't
unload the drm fbdev emulation either while a driver is still using it.
Dropping that requirement would make things even simpler (you'd just need
to add an owner field to drm_client and a try_module_get when registering
it, bailing out if that fails).
What's the use-case you have in mind that requires that you can unload a
client driver module? Does that even work with the shuffling we've done on
the register side of things?
When I first started on this client API, the client could unload itself
and I had a sysfs file that would remove clients for a particular
drm_device. This would mean that unloading a driver would require clients
to be removed first by writing to the sysfs file.
Then I started to look at the possibility that the driver could remove
clients automatically on driver unload. I have wrecked my brain trying to
make it race free, but it gets very complicated as you have shown in your
example. So I think we'll just avoid this complexity altogether.
So, now the question is, who gets to remove clients. The client or the
driver?
The common pattern is that clients can come and go on their own choosing.
It's what I would expect, that the client can be unloaded.
The reason I looked into auto unloading when the driver where going away,
was so developers shouldn't have to do the extra step to unload the driver.
Now I see a third case, and that's plug/unplug USB devices. If the driver
can't remove the client, we can end up with lots hanging drm_device and
drm_client_dev instances that have to be removed manually, which is
really not an option.
So I think we remove clients on driver/device removal. This means that to
unload a client, the driver(s) would have to be unloaded first.
I'll add an owner field to drm_client_funcs as you suggested and work out
the details.
Thanks for helping me get this as simple and straightforward as possible.
Noralf.
The client module calls drm_client_release():
void drm_client_release(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
Not sure (without reading your patches again) why we have drm_client_close
here and ->unregister/drm_client_release below. But the trick is roughly
to do
client = NULL;
mutex_lock();
client = find_it();
if (client)
list_del();
mute_unlock();
if (!client)
continue; /* or early return, whatever makes sense */
drm_client_unregister(client);
This way if you race there's:
- only one thread will win, since the removal from the list is locked
- no deadlocks, because the actual cleanup is done outside of the locks
The problem is applying this trick to each situation, since you need to
make sure that you get them all. Since you want to be able to unregister
from 2 different lists, with each their own locks, you need to nest the
above pattern in clever ways. In the client unregister function:
mutex_lock(fbdev_clients_lock);
client = list_first(fbdev_clients_list);
if (client)
list_del();
mutex_lock(client->dev);
if (!list_empty(client->dev_list))
list_del();
else
/* someone else raced us, give up */
client = NULL;
mutex_unlock(client->dev);
mutex_unlock(fbdev_clients_lock);
if (!client)
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/ddi: Get AUX power domain for DP main link too
== Series Details == Series: series starting with [1/2] drm/i915/ddi: Get AUX power domain for DP main link too URL : https://patchwork.freedesktop.org/series/45181/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4362 -> Patchwork_9385 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45181/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9385 that come from known issues: === IGT changes === Issues hit igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) Possible fixes igt@gem_ctx_create@basic-files: fi-skl-6700k2: INCOMPLETE (fdo#106988) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 37) == Additional (1): fi-bxt-dsi Missing(6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4362 -> Patchwork_9385 CI_DRM_4362: 7159c27349b070831dfb3512ca055c8dbcf9e1fc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9385: f1178ae6d5f0ad56370f2557d746cf5fc09c0923 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f1178ae6d5f0 drm/i915/cnl: Don't get separate AUX power domain ref for DP PSR 2fcf2866905b drm/i915/ddi: Get AUX power domain for DP main link too == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9385/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/ddi: Get AUX power domain for DP main link too
So far we got an AUX power domain reference only for the duration of DP
AUX transfers. However, the following suggests that we also need these
for main link functionality:
- The specification doesn't state whether it's needed or not for main
link functionality, but suggests that these power wells need to be
enabled already during display core initialization (Sequences to
Initialize Display).
- For PSR we need to keep the AUX power well enabled.
- On ICL combo PHY ports (non-TC) the AUX power well is needed for
link training too: while the port is enabled with a DP link training
test pattern trying to toggle the AUX power well will time out.
- On ICL MG PHY ports (TC) the AUX power well is needed also for main
link functionality (both in DP and HDMI modes).
- Windows enables these power wells both for main and AUX lane
functionality.
Based on the above take an AUX power reference for main link
functionality too. This makes a difference only on GEN10+ (GLK+)
platforms, where we have separate port specific AUX power wells.
For PSR we still need to distinguish between port A and the other
ports, since on port A DC states must stay enabled for main link
functionality, but DC states must be disabled for driver initiated
AUX transfers. So re-use the corresponding helper from intel_psr.c.
Since we take now a rereference for main link functionality on all DP
ports we can forgo taking the seperate power ref for PSR functionality.
v2:
- Make sure DC states stay enabled when taking the ref on port A.
(Ville)
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Paulo Zanoni
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c| 54 ++---
drivers/gpu/drm/i915/intel_display.c| 12 +++-
drivers/gpu/drm/i915/intel_drv.h| 3 +-
drivers/gpu/drm/i915/intel_psr.c| 41 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
5 files changed, 64 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 044fe1fb9872..146a9daa6564 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1983,15 +1983,55 @@ bool intel_ddi_get_hw_state(struct intel_encoder
*encoder,
return ret;
}
-static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
+static inline enum intel_display_power_domain
+intel_ddi_main_link_aux_domain(struct intel_dp *intel_dp)
+{
+ /* CNL HW requires corresponding AUX IOs to be powered up for PSR with
+* DC states enabled at the same time, while for driver initiated AUX
+* transfers we need the same AUX IOs to be powered but with DC states
+* disabled. Accordingly use the AUX power domain here which leaves DC
+* states enabled.
+* However, for non-A AUX ports the corresponding non-EDP transcoders
+* would have already enabled power well 2 and DC_OFF. This means we can
+* acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
+* specific AUX_IO reference without powering up any extra wells.
+* Note that PSR is enabled only on Port A even though this function
+* returns the correct domain for other ports too.
+*/
+ return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
+ intel_dp->aux_power_domain;
+}
+
+static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state)
{
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
enum pipe pipe;
+ u64 domains;
- if (intel_ddi_get_hw_state(encoder, ))
- return BIT_ULL(dig_port->ddi_io_power_domain);
+ if (!intel_ddi_get_hw_state(encoder, ))
+ return 0;
- return 0;
+ domains = BIT_ULL(dig_port->ddi_io_power_domain);
+ if (!crtc_state)
+ return domains;
+
+ /*
+* TODO: Add support for MST encoders. Atm, the following should never
+* happen since this function will be called only for the primary
+* encoder which doesn't have its own pipe/crtc_state.
+*/
+ if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
+ return domains;
+
+ /* AUX power is only needed for (e)DP mode, not for HDMI. */
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+ struct intel_dp *intel_dp = _port->dp;
+
+ domains |= BIT_ULL(intel_ddi_main_link_aux_domain(intel_dp));
+ }
+
+ return domains;
}
void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
@@ -2631,6 +2671,9 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
+ intel_display_power_get(dev_priv,
+
Re: [Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
On Tue, Jun 19, 2018 at 01:17:10PM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-06-19 at 08:24 -0700, Lucas De Marchi wrote:
> > On Tue, Jun 19, 2018 at 7:06 AM Ville Syrjälä
> > wrote:
> > >
> > >
> > > On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi wrote:
> > > >
> > > > On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> > > > >
> > > > > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi
> > > > > wrote:
> > > > > >
> > > > > > This became dead code with commit 309bd8ed464f ("drm/i915:
> > > > > > Reinstate
> > > > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > > >
> > > > > > v2: Move comment about HW behavior to where decision is made
> > > > > > to enable
> > > > > > MSI (Ville).
> > > > > >
> > > > > > Cc: Ville Syrjälä
> > > > > > Signed-off-by: Lucas De Marchi
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > > > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > index 9c449b8d8eab..a1461de20472 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > > > > > drm_i915_private *dev_priv)
> > > > > > * get lost on g4x as well, and interrupt delivery seems to
> > > > > > stay
> > > > > > * properly dead afterwards. So we'll just disable them for
> > > > > > all
> > > > > > * pre-gen5 chipsets.
> > > > > > + *
> > > > > > + * dp aux and gmbus irq on gen4 seems to be able to
> > > > > > generate legacy
> > > > > > + * interrupts even when in MSI mode. This results in
> > > > > > spurious
> > > > > > + * interrupt warnings if the legacy irq no. is shared with
> > > > > > another
> > > > > > + * device. The kernel then disables that interrupt source
> > > > > > and so
> > > > > > + * prevents the other device from working properly.
> > > > > > */
> > > > > > if (INTEL_GEN(dev_priv) >= 5) {
> > > > > > if (pci_enable_msi(pdev) < 0)
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > index b86ed6401120..c5e1f648c47c 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > @@ -2558,16 +2558,6 @@ intel_info(const struct
> > > > > > drm_i915_private *dev_priv)
> > > > > > (IS_CANNONLAKE(dev_priv) || \
> > > > > > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > > > >
> > > > > > -/*
> > > > > > - * dp aux and gmbus irq on gen4 seems to be able to generate
> > > > > > legacy interrupts
> > > > > > - * even when in MSI mode. This results in spurious interrupt
> > > > > > warnings if the
> > > > > > - * legacy irq no. is shared with another device. The kernel
> > > > > > then disables that
> > > > > > - * interrupt source and so prevents the other device from
> > > > > > working properly.
> > > > > > - *
> > > > > > - * Since we don't enable MSI anymore on gen4, we can always
> > > > > > use GMBUS/AUX
> > > > > > - * interrupts.
> > > > > > - */
> > > > > > -#define HAS_AUX_IRQ(dev_priv) true
> > > > > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> > > > > >
> > > > > > /* With the 945 and later, Y tiling got adjusted so that it
> > > > > > was 32 128-byte
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index ce07bd794aed..1dab40056df7 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp
> > > > > > *intel_dp)
> > > > > > }
> > > > > >
> > > > > > static uint32_t
> > > > > > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool
> > > > > > has_aux_irq)
> > > > > > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > > > > > {
> > > > > > struct drm_i915_private *dev_priv =
> > > > > > to_i915(intel_dp_to_dev(intel_dp));
> > > > > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > > > > @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp
> > > > > > *intel_dp, bool has_aux_irq)
> > > > > > bool done;
> > > > > >
> > > > > > #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> > > > > > DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > > > > > - if (has_aux_irq)
> > > > > > - done = wait_event_timeout(dev_priv-
> > > > > > >gmbus_wait_queue, C,
> > > > > > - msecs_to_jiffies_timeout(
> > > > > > 10));
> > > > > > - else
> > > > > > - done = wait_for(C, 10) == 0;
> > > > > > + done =
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/ddi: Get AUX power domain for DP main link too
== Series Details == Series: series starting with [1/2] drm/i915/ddi: Get AUX power domain for DP main link too URL : https://patchwork.freedesktop.org/series/45181/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2fcf2866905b drm/i915/ddi: Get AUX power domain for DP main link too -:10: WARNING:TYPO_SPELLING: 'followings' may be misspelled - perhaps 'following'? #10: AUX transfers. However, the followings suggest that we also need these total: 0 errors, 1 warnings, 0 checks, 87 lines checked f1178ae6d5f0 drm/i915/cnl: Don't get separate AUX power domain ref for DP PSR ___ 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: read EU powergating status from command streamer
== Series Details == Series: drm/i915: read EU powergating status from command streamer URL : https://patchwork.freedesktop.org/series/45161/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359_full -> Patchwork_9381_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9381_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-glk: PASS -> DMESG-FAIL (fdo#106947, fdo#106560) igt@drv_suspend@shrink: shard-glk: PASS -> FAIL (fdo#106886) igt@kms_flip@2x-flip-vs-blocking-wf-vblank: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@perf@polling: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@drv_selftest@live_hugepages: shard-kbl: INCOMPLETE (fdo#103665) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 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#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4359 -> Patchwork_9381 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9381: ce6bc683714cbb21f445396851decdc3236323de @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9381/shards.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/cnl: Don't get separate AUX power domain ref for DP PSR
On Thu, Jun 21, 2018 at 07:13:51PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 21, 2018 at 06:58:30PM +0300, Imre Deak wrote:
> > After the previous patch we don't need to get an explicit AUX power
> > reference for PSR functionality, since we hold now an AUX reference
> > whenever the main link is active on any DP ports.
> >
> > Cc: Ville Syrjälä
> > Cc: Dhinakaran Pandiyan
> > Cc: Paulo Zanoni
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_display.h| 1 -
> > drivers/gpu/drm/i915/intel_psr.c| 41
> > -
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ---
> > 3 files changed, 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index dfb02da73ac8..29501bf368b2 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -198,7 +198,6 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_AUX_D,
> > POWER_DOMAIN_AUX_E,
> > POWER_DOMAIN_AUX_F,
> > - POWER_DOMAIN_AUX_IO_A,
> > POWER_DOMAIN_GMBUS,
> > POWER_DOMAIN_MODESET,
> > POWER_DOMAIN_GT_IRQ,
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index d4cd19fea148..eecdd8b5b5e0 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -56,43 +56,6 @@
> > #include "intel_drv.h"
> > #include "i915_drv.h"
> >
> > -static inline enum intel_display_power_domain
> > -psr_aux_domain(struct intel_dp *intel_dp)
> > -{
> > - /* CNL HW requires corresponding AUX IOs to be powered up for PSR.
> > -* However, for non-A AUX ports the corresponding non-EDP transcoders
> > -* would have already enabled power well 2 and DC_OFF. This means we can
> > -* acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
> > -* specific AUX_IO reference without powering up any extra wells.
> > -* Note that PSR is enabled only on Port A even though this function
> > -* returns the correct domain for other ports too.
> > -*/
> > - return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
> > - intel_dp->aux_power_domain;
>
> Hmm. Isn't this going to prevent DC5 during PSR?
Yep, it would. So we still need a separate AUX_IO domain which we would
take during encoder enabling, whereas the AUX domain - which prevents DC
states - would be used only for AUX transfers.
>
> > -}
> > -
> > -static void psr_aux_io_power_get(struct intel_dp *intel_dp)
> > -{
> > - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > - struct drm_i915_private *dev_priv =
> > to_i915(intel_dig_port->base.base.dev);
> > -
> > - if (INTEL_GEN(dev_priv) < 10)
> > - return;
> > -
> > - intel_display_power_get(dev_priv, psr_aux_domain(intel_dp));
> > -}
> > -
> > -static void psr_aux_io_power_put(struct intel_dp *intel_dp)
> > -{
> > - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > - struct drm_i915_private *dev_priv =
> > to_i915(intel_dig_port->base.base.dev);
> > -
> > - if (INTEL_GEN(dev_priv) < 10)
> > - return;
> > -
> > - intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
> > -}
> > -
> > void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug)
> > {
> > u32 debug_mask, mask;
> > @@ -595,8 +558,6 @@ static void hsw_psr_enable_source(struct intel_dp
> > *intel_dp,
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> >
> > - psr_aux_io_power_get(intel_dp);
> > -
> > /* Only HSW and BDW have PSR AUX registers that need to be setup. SKL+
> > * use hardcoded values PSR AUX transactions
> > */
> > @@ -717,8 +678,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
> > else
> > WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> > }
> > -
> > - psr_aux_io_power_put(intel_dp);
> > }
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index de3a81034f77..58a8f07eafa4 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -132,8 +132,6 @@ intel_display_power_domain_str(enum
> > intel_display_power_domain domain)
> > return "AUX_E";
> > case POWER_DOMAIN_AUX_F:
> > return "AUX_F";
> > - case POWER_DOMAIN_AUX_IO_A:
> > - return "AUX_IO_A";
> > case POWER_DOMAIN_GMBUS:
> > return "GMBUS";
> > case POWER_DOMAIN_INIT:
> > @@ -1872,7 +1870,6 @@ void intel_display_power_put(struct drm_i915_private
> > *dev_priv,
> > BIT_ULL(POWER_DOMAIN_INIT))
> > #define CNL_DISPLAY_AUX_A_POWER_DOMAINS ( \
> > BIT_ULL(POWER_DOMAIN_AUX_A) | \
> > - BIT_ULL(POWER_DOMAIN_AUX_IO_A) |
[Intel-gfx] ✓ Fi.CI.IGT: success for kernel: Show panic string after panic-notifiers
== Series Details == Series: kernel: Show panic string after panic-notifiers URL : https://patchwork.freedesktop.org/series/45160/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359_full -> Patchwork_9380_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9380_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@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: PASS -> DMESG-WARN (fdo#106538, fdo#105763) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@drv_selftest@live_hugepages: shard-kbl: INCOMPLETE (fdo#103665) -> PASS 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#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 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_4359 -> Patchwork_9380 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9380: 390deb98237f4e94557da64035c0364cba6100bb @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9380/shards.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/cnl: Don't get separate AUX power domain ref for DP PSR
On Thu, Jun 21, 2018 at 06:58:30PM +0300, Imre Deak wrote:
> After the previous patch we don't need to get an explicit AUX power
> reference for PSR functionality, since we hold now an AUX reference
> whenever the main link is active on any DP ports.
>
> Cc: Ville Syrjälä
> Cc: Dhinakaran Pandiyan
> Cc: Paulo Zanoni
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.h| 1 -
> drivers/gpu/drm/i915/intel_psr.c| 41
> -
> drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ---
> 3 files changed, 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index dfb02da73ac8..29501bf368b2 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -198,7 +198,6 @@ enum intel_display_power_domain {
> POWER_DOMAIN_AUX_D,
> POWER_DOMAIN_AUX_E,
> POWER_DOMAIN_AUX_F,
> - POWER_DOMAIN_AUX_IO_A,
> POWER_DOMAIN_GMBUS,
> POWER_DOMAIN_MODESET,
> POWER_DOMAIN_GT_IRQ,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index d4cd19fea148..eecdd8b5b5e0 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -56,43 +56,6 @@
> #include "intel_drv.h"
> #include "i915_drv.h"
>
> -static inline enum intel_display_power_domain
> -psr_aux_domain(struct intel_dp *intel_dp)
> -{
> - /* CNL HW requires corresponding AUX IOs to be powered up for PSR.
> - * However, for non-A AUX ports the corresponding non-EDP transcoders
> - * would have already enabled power well 2 and DC_OFF. This means we can
> - * acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
> - * specific AUX_IO reference without powering up any extra wells.
> - * Note that PSR is enabled only on Port A even though this function
> - * returns the correct domain for other ports too.
> - */
> - return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
> - intel_dp->aux_power_domain;
Hmm. Isn't this going to prevent DC5 during PSR?
> -}
> -
> -static void psr_aux_io_power_get(struct intel_dp *intel_dp)
> -{
> - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv =
> to_i915(intel_dig_port->base.base.dev);
> -
> - if (INTEL_GEN(dev_priv) < 10)
> - return;
> -
> - intel_display_power_get(dev_priv, psr_aux_domain(intel_dp));
> -}
> -
> -static void psr_aux_io_power_put(struct intel_dp *intel_dp)
> -{
> - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv =
> to_i915(intel_dig_port->base.base.dev);
> -
> - if (INTEL_GEN(dev_priv) < 10)
> - return;
> -
> - intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
> -}
> -
> void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug)
> {
> u32 debug_mask, mask;
> @@ -595,8 +558,6 @@ static void hsw_psr_enable_source(struct intel_dp
> *intel_dp,
> struct drm_i915_private *dev_priv = to_i915(dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>
> - psr_aux_io_power_get(intel_dp);
> -
> /* Only HSW and BDW have PSR AUX registers that need to be setup. SKL+
>* use hardcoded values PSR AUX transactions
>*/
> @@ -717,8 +678,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
> else
> WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> }
> -
> - psr_aux_io_power_put(intel_dp);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index de3a81034f77..58a8f07eafa4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -132,8 +132,6 @@ intel_display_power_domain_str(enum
> intel_display_power_domain domain)
> return "AUX_E";
> case POWER_DOMAIN_AUX_F:
> return "AUX_F";
> - case POWER_DOMAIN_AUX_IO_A:
> - return "AUX_IO_A";
> case POWER_DOMAIN_GMBUS:
> return "GMBUS";
> case POWER_DOMAIN_INIT:
> @@ -1872,7 +1870,6 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> BIT_ULL(POWER_DOMAIN_INIT))
> #define CNL_DISPLAY_AUX_A_POWER_DOMAINS (\
> BIT_ULL(POWER_DOMAIN_AUX_A) | \
> - BIT_ULL(POWER_DOMAIN_AUX_IO_A) |\
> BIT_ULL(POWER_DOMAIN_INIT))
> #define CNL_DISPLAY_AUX_B_POWER_DOMAINS (\
> BIT_ULL(POWER_DOMAIN_AUX_B) | \
> --
> 2.13.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz (rev3)
On Tue, Jun 19, 2018 at 05:13:26PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915/icl: Fix MG PLL setup when refclk > is 38.4MHz (rev3) > URL : https://patchwork.freedesktop.org/series/44836/ > State : failure Thanks for the reviews pushed both patches to -dinq. See below for the explanation on failure. > > == Summary == > > = CI Bug Log - changes from CI_DRM_4343 -> Patchwork_9360 = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_9360 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_9360, 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/44836/revisions/3/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_9360: > > === IGT changes === > > Possible regressions > > igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: > fi-glk-j4005: PASS -> FAIL These changes are ICL specific, so should not affect GLK. > > > == Known issues == > > Here are the changes found in Patchwork_9360 that come from known issues: > > === IGT changes === > > Issues hit > > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: > fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) > > > Possible fixes > > igt@kms_flip@basic-plain-flip: > fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS > > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: > fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS > > > fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 > fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 > fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 > > > == Participating hosts (42 -> 38) == > > Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u > > > == Build changes == > > * Linux: CI_DRM_4343 -> Patchwork_9360 > > CI_DRM_4343: 93475d62c73031c5b4625eaa64b5c0f4079b2f3f @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_9360: 01529685e7fbbd57d3f7de473799a45bcd0783e0 @ > git://anongit.freedesktop.org/gfx-ci/linux > > > == Linux commits == > > 01529685e7fb drm/i915/icl: Do read-modify-write as needed during MG PLL > programming > e89ce575e104 drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9360/issues.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: Enable hw workaround to bypass alpha (rev2)
== Series Details == Series: drm/i915: Enable hw workaround to bypass alpha (rev2) URL : https://patchwork.freedesktop.org/series/45173/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359 -> Patchwork_9384 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45173/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9384 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: INCOMPLETE (fdo#105600, fdo#106988) -> PASS fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 37) == Missing(5): fi-byt-squawks fi-kbl-x1275 fi-ilk-m540 fi-glk-dsi fi-hsw-4200u == Build changes == * Linux: CI_DRM_4359 -> Patchwork_9384 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9384: d054ad3f8cdffbdfdc964839b966b1304a761439 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d054ad3f8cdf drm/i915: Enable hw workaround to bypass alpha == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9384/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
On Tue, Jun 19, 2018 at 08:24:33AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 19, 2018 at 7:06 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi wrote:
> > > On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> > > > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi wrote:
> > > > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > >
> > > > > v2: Move comment about HW behavior to where decision is made to enable
> > > > > MSI (Ville).
> > > > >
> > > > > Cc: Ville Syrjälä
> > > > > Signed-off-by: Lucas De Marchi
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > index 9c449b8d8eab..a1461de20472 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > > > > drm_i915_private *dev_priv)
> > > > >* get lost on g4x as well, and interrupt delivery seems to stay
> > > > >* properly dead afterwards. So we'll just disable them for all
> > > > >* pre-gen5 chipsets.
> > > > > + *
> > > > > + * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > > > + * interrupts even when in MSI mode. This results in spurious
> > > > > + * interrupt warnings if the legacy irq no. is shared with another
> > > > > + * device. The kernel then disables that interrupt source and so
> > > > > + * prevents the other device from working properly.
> > > > >*/
> > > > > if (INTEL_GEN(dev_priv) >= 5) {
> > > > > if (pci_enable_msi(pdev) < 0)
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index b86ed6401120..c5e1f648c47c 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -2558,16 +2558,6 @@ intel_info(const struct drm_i915_private
> > > > > *dev_priv)
> > > > > (IS_CANNONLAKE(dev_priv) || \
> > > > >IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > > >
> > > > > -/*
> > > > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > > > interrupts
> > > > > - * even when in MSI mode. This results in spurious interrupt
> > > > > warnings if the
> > > > > - * legacy irq no. is shared with another device. The kernel then
> > > > > disables that
> > > > > - * interrupt source and so prevents the other device from working
> > > > > properly.
> > > > > - *
> > > > > - * Since we don't enable MSI anymore on gen4, we can always use
> > > > > GMBUS/AUX
> > > > > - * interrupts.
> > > > > - */
> > > > > -#define HAS_AUX_IRQ(dev_priv) true
> > > > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> > > > >
> > > > > /* With the 945 and later, Y tiling got adjusted so that it was 32
> > > > > 128-byte
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index ce07bd794aed..1dab40056df7 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
> > > > > }
> > > > >
> > > > > static uint32_t
> > > > > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> > > > > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > > > > {
> > > > > struct drm_i915_private *dev_priv =
> > > > > to_i915(intel_dp_to_dev(intel_dp));
> > > > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > > > @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp
> > > > > *intel_dp, bool has_aux_irq)
> > > > > bool done;
> > > > >
> > > > > #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> > > > > DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > > > > - if (has_aux_irq)
> > > > > - done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > > > > - msecs_to_jiffies_timeout(10));
> > > > > - else
> > > > > - done = wait_for(C, 10) == 0;
> > > > > + done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > > > > + msecs_to_jiffies_timeout(10));
> > > > > if (!done)
> > > > > - DRM_ERROR("dp aux hw did not signal timeout (has irq:
> > > > > %i)!\n",
> > > > > - has_aux_irq);
> > > > > + DRM_ERROR("dp aux hw did not signal timeout!\n");
> > > > > #undef C
> > > > >
> > > > > return status;
> > > > > @@ -1016,7 +1012,6 @@ static uint32_t
> > > > >
[Intel-gfx] [PATCH 2/2] drm/i915/cnl: Don't get separate AUX power domain ref for DP PSR
After the previous patch we don't need to get an explicit AUX power
reference for PSR functionality, since we hold now an AUX reference
whenever the main link is active on any DP ports.
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Paulo Zanoni
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.h| 1 -
drivers/gpu/drm/i915/intel_psr.c| 41 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ---
3 files changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index dfb02da73ac8..29501bf368b2 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -198,7 +198,6 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_D,
POWER_DOMAIN_AUX_E,
POWER_DOMAIN_AUX_F,
- POWER_DOMAIN_AUX_IO_A,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
POWER_DOMAIN_GT_IRQ,
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d4cd19fea148..eecdd8b5b5e0 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -56,43 +56,6 @@
#include "intel_drv.h"
#include "i915_drv.h"
-static inline enum intel_display_power_domain
-psr_aux_domain(struct intel_dp *intel_dp)
-{
- /* CNL HW requires corresponding AUX IOs to be powered up for PSR.
-* However, for non-A AUX ports the corresponding non-EDP transcoders
-* would have already enabled power well 2 and DC_OFF. This means we can
-* acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
-* specific AUX_IO reference without powering up any extra wells.
-* Note that PSR is enabled only on Port A even though this function
-* returns the correct domain for other ports too.
-*/
- return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
- intel_dp->aux_power_domain;
-}
-
-static void psr_aux_io_power_get(struct intel_dp *intel_dp)
-{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
-
- if (INTEL_GEN(dev_priv) < 10)
- return;
-
- intel_display_power_get(dev_priv, psr_aux_domain(intel_dp));
-}
-
-static void psr_aux_io_power_put(struct intel_dp *intel_dp)
-{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
-
- if (INTEL_GEN(dev_priv) < 10)
- return;
-
- intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
-}
-
void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug)
{
u32 debug_mask, mask;
@@ -595,8 +558,6 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = to_i915(dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
- psr_aux_io_power_get(intel_dp);
-
/* Only HSW and BDW have PSR AUX registers that need to be setup. SKL+
* use hardcoded values PSR AUX transactions
*/
@@ -717,8 +678,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
else
WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
}
-
- psr_aux_io_power_put(intel_dp);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index de3a81034f77..58a8f07eafa4 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -132,8 +132,6 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "AUX_E";
case POWER_DOMAIN_AUX_F:
return "AUX_F";
- case POWER_DOMAIN_AUX_IO_A:
- return "AUX_IO_A";
case POWER_DOMAIN_GMBUS:
return "GMBUS";
case POWER_DOMAIN_INIT:
@@ -1872,7 +1870,6 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_INIT))
#define CNL_DISPLAY_AUX_A_POWER_DOMAINS ( \
BIT_ULL(POWER_DOMAIN_AUX_A) | \
- BIT_ULL(POWER_DOMAIN_AUX_IO_A) |\
BIT_ULL(POWER_DOMAIN_INIT))
#define CNL_DISPLAY_AUX_B_POWER_DOMAINS ( \
BIT_ULL(POWER_DOMAIN_AUX_B) | \
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/ddi: Get AUX power domain for DP main link too
So far we got an AUX power domain reference only for the duration of DP
AUX transfers. However, the followings suggest that we also need these
for main link functionality:
- The specification doesn't state whether it's needed or not for main
link functionality, but suggests that these power wells need to be
enabled already during display core initialization (Sequences to
Initialize Display).
- For PSR we need to keep the AUX power well enabled.
- On ICL combo PHY ports (non-TC) the AUX power well is needed for
link training too: while the port is enabled with a DP link training
test pattern trying to toggle the AUX power well will time out.
- On ICL MG PHY ports (TC) the AUX power well is needed also for main
link functionality (both in DP and HDMI modes).
- Windows enables these power wells both for main and AUX lane
functionality.
Based on the above take an AUX power reference for main link
functionality too. This makes a difference only on GEN10+ (GLK+)
platforms, where we have separate port specific AUX power wells.
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Paulo Zanoni
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 33 +
drivers/gpu/drm/i915/intel_display.c | 12 +++-
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 044fe1fb9872..b09cb6969bbb 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1983,15 +1983,36 @@ bool intel_ddi_get_hw_state(struct intel_encoder
*encoder,
return ret;
}
-static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
+static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state)
{
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
enum pipe pipe;
+ u64 domains;
- if (intel_ddi_get_hw_state(encoder, ))
- return BIT_ULL(dig_port->ddi_io_power_domain);
+ if (!intel_ddi_get_hw_state(encoder, ))
+ return 0;
- return 0;
+ domains = BIT_ULL(dig_port->ddi_io_power_domain);
+ if (!crtc_state)
+ return domains;
+
+ /*
+* TODO: Add support for MST encoders. Atm, the following should never
+* happen since this function will be called only for the primary
+* encoder which doesn't have its own pipe/crtc_state.
+*/
+ if (WARN_ON(intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)))
+ return domains;
+
+ /* AUX power is only needed for (e)DP mode, not for HDMI. */
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+ struct intel_dp *intel_dp = _port->dp;
+
+ domains |= BIT_ULL(intel_dp->aux_power_domain);
+ }
+
+ return domains;
}
void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state)
@@ -2631,6 +2652,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
WARN_ON(is_mst && (port == PORT_A || port == PORT_E));
+ intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
+
intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
crtc_state->lane_count, is_mst);
@@ -2775,6 +2798,8 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
intel_ddi_clk_disable(encoder);
+
+ intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
}
static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2c8fef3ede54..d9fefcec4b1a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15676,11 +15676,21 @@ get_encoder_power_domains(struct drm_i915_private
*dev_priv)
for_each_intel_encoder(_priv->drm, encoder) {
u64 get_domains;
enum intel_display_power_domain domain;
+ struct intel_crtc_state *crtc_state;
if (!encoder->get_power_domains)
continue;
- get_domains = encoder->get_power_domains(encoder);
+ /*
+* In case of a dangling encoder without a crtc we still need
+* to get power domain refs. Such encoders will be disabled
+* dropping these references.
+*/
+ crtc_state = encoder->base.crtc ?
+to_intel_crtc_state(encoder->base.crtc->state) :
+NULL;
+
+ get_domains = encoder->get_power_domains(encoder, crtc_state);
for_each_power_domain(domain, get_domains)
Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning on bootup with external display
On Thu, Jun 21, 2018 at 01:00:48AM +, Shaikh, Azhar wrote: > > > >-Original Message- > >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >Sent: Tuesday, June 19, 2018 5:00 AM > >To: Shaikh, Azhar > >Cc: Jani Nikula ; > >intel-gfx@lists.freedesktop.org > >Subject: Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning on bootup > >with external display > > > >On Mon, Jun 18, 2018 at 09:40:38PM +, Shaikh, Azhar wrote: > >> > >> > >> >-Original Message- > >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> >Sent: Monday, June 18, 2018 4:57 AM > >> >To: Jani Nikula > >> >Cc: Shaikh, Azhar ; > >> >intel-gfx@lists.freedesktop.org > >> >Subject: Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning > >> >on bootup with external display > >> > > >> >On Mon, Jun 18, 2018 at 11:18:52AM +0300, Jani Nikula wrote: > >> >> On Sun, 17 Jun 2018, Azhar Shaikh wrote: > >> >> > On KBL, WHL RVPs, booting up with an external display connected, > >> >> > triggers below warning. This warning is not seen during hotplug. > >> >> > > >> >> > [3.615226] [ cut here ] > >> >> > [3.619829] plane 1A assertion failure (expected on, current off) > >> >> > [3.632039] WARNING: CPU: 2 PID: 354 at > >> >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb > >> >> > [3.633920] iwlwifi :00:14.3: loaded firmware version > >38.c0e03d94.0 > >> >op_mode iwlmvm > >> >> > [3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm > >btintel > >> >bluetooth ecdh_generic > >> >> > [3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted 4.17.0-rc7- > >50176- > >> >g655af12d39c2 #3 > >> >> > [3.647165] Hardware name: Intel Corporation CoffeeLake Client > >> >Platform/WhiskeyLake U DDR4 ERB, BIOS > >> >CNLSFWR1.R00.X140.B00.1804040304 04/04/2018 > >> >> > [3.684509] RIP: 0010:assert_plane+0x71/0xbb > >> >> > [3.764451] Call Trace: > >> >> > [3.766888] intel_atomic_commit_tail+0xa97/0xb77 > >> >> > [3.771569] intel_atomic_commit+0x26a/0x279 > >> >> > [3.771572] drm_atomic_helper_set_config+0x5c/0x76 > >> >> > [3.780670] __drm_mode_set_config_internal+0x66/0x109 > >> >> > [3.780672] drm_mode_setcrtc+0x4c9/0x5cc > >> >> > [3.780674] ? drm_mode_getcrtc+0x162/0x162 > >> >> > [3.789774] ? drm_mode_getcrtc+0x162/0x162 > >> >> > [3.798108] drm_ioctl_kernel+0x8d/0xe4 > >> >> > [3.801926] drm_ioctl+0x27d/0x368 > >> >> > [3.805311] ? drm_mode_getcrtc+0x162/0x162 > >> >> > [3.805314] ? selinux_file_ioctl+0x14e/0x199 > >> >> > [3.805317] vfs_ioctl+0x21/0x2f > >> >> > [3.813812] do_vfs_ioctl+0x491/0x4b4 > >> >> > [3.813813] ? security_file_ioctl+0x37/0x4b > >> >> > [3.813816] ksys_ioctl+0x55/0x75 > >> >> > [3.820672] __x64_sys_ioctl+0x1a/0x1e > >> >> > [3.820674] do_syscall_64+0x51/0x5f > >> >> > [3.820678] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> >> > [3.828221] RIP: 0033:0x7b5e04953967 > >> >> > [3.835504] RSP: 002b:7fff2eafb6f8 EFLAGS: 0246 ORIG_RAX: > >> >0010 > >> >> > [3.835505] RAX: ffda RBX: 0002 RCX: > >> >7b5e04953967 > >> >> > [3.835505] RDX: 7fff2eafb730 RSI: c06864a2 RDI: > >> >000f > >> >> > [3.835506] RBP: 7fff2eafb720 R08: R09: > >> > > >> >> > [3.835507] R10: 0070 R11: 0246 R12: > >> >000f > >> >> > [3.879988] R13: 56bc9dd7d210 R14: 7fff2eafb730 R15: > >> >c06864a2 > >> >> > [3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be > >> >> > 48 89 > >f9 48 > >> >0f 44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff > >> ><0f> 0b eb 2b > >> >48 c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48 > >> >> > [3.905845] WARNING: CPU: 2 PID: 354 at > >> >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb > >> >> > [3.920964] ---[ end trace dac692f4ac46391a ]--- > >> >> > > >> >> > The warning is seen when mode_setcrtc() is called for pipeB > >> >> > during bootup and before we get a mode_setcrtc() for pipeA, while > >> >> > doing > >> >> > update_crtcs() in intel_atomic_commit_tail(). > >> >> > Now since, plane1A is still active after commit, update_crtcs() > >> >> > is done for pipeA and eventually update_plane() for plane1A. > >> >> > > >> >> > intel_plane_state->ctl for plane1A is not updated since > >> >> > set_modecrtc() is called for pipeB. So intel_plane_state->ctl for > >> >> > plane 1A > >> >will be 0x0. > >> >> > So doing an update_plane() for plane1A, will result in clearing > >> >> > PLANE_CTL_ENABLE bit, and hence the warning. > >> >> > > >> >> > To fix this warning, prior to updating the PLANE_CTL register > >> >> > with intel_plane_state->ctl value, read PLANE_CTL register, OR it > >> >> > with intel_plane_state->ctl and then write it to PLANE_CTL > >> >> > register instead of
[Intel-gfx] [v2] drm/i915: Enable hw workaround to bypass alpha
Alpha blending with alpha 0 and 0xff passes through
alpha math and rounding logic causing differences
compared to fully transparent or opaque plane,resulting
in CRC mismatch.
This WA on icl and above enables hardware to bypass alpha
math and rounding for per pixel alpha values of 00 and 0xff
v2: Fix patchwork checkpatch warnings.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4bfd7a9..b66ec9b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7366,6 +7366,14 @@ enum {
#define BDW_SCRATCH1 _MMIO(0xb11c)
#define GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
+/*GEN11 chicken */
+#define _PIPEA_CHICKEN 0x70038
+#define _PIPEB_CHICKEN 0x71038
+#define _PIPEC_CHICKEN 0x72038
+#define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
+#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
+ _PIPEB_CHICKEN)
+
/* PCH */
/* south display engine interrupt: IBX */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2c8fef3..3d849ec 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5632,6 +5632,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
struct intel_atomic_state *old_intel_state =
to_intel_atomic_state(old_state);
bool psl_clkgate_wa;
+ u32 pipe_chicken;
if (WARN_ON(intel_crtc->active))
return;
@@ -5691,6 +5692,17 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
*/
intel_color_load_luts(_config->base);
+ /*
+* Display WA #1153: enable hardware to bypass the alpha math
+* and rounding for per-pixel values 00 and 0xff
+*/
+ if (INTEL_GEN(dev_priv) >= 11) {
+ pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
+ if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
+ I915_WRITE_FW(PIPE_CHICKEN(pipe),
+ pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN);
+ }
+
intel_ddi_set_pipe_settings(pipe_config);
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_transcoder_func(pipe_config);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915/guc: New interface files for GuC starting in Gen11
On Thu, Jun 14, 2018 at 10:48:01PM +, Srivatsa, Anusha wrote:
Overall I don't see any biggest issue with this file and I agree with
most of Michal's comments, specially with the nameless bitfields.
Well, maybe the nameless is a big issue if it breaks compilers out there.
But I'm responding here to some comments and questions that was pending
and hopefully put this thread back to top of people's inboxes ;)
more inline below:
>
>
> >-Original Message-
> >From: Mateo Lozano, Oscar
> >Sent: Wednesday, June 13, 2018 3:08 PM
> >To: Wajdeczko, Michal ; intel-
> >g...@lists.freedesktop.org
> >Cc: Joonas Lahtinen ; Rogovin, Kevin
> >; Spotswood, John A ;
> >Srivatsa, Anusha ; Ceraolo Spurio, Daniele
> >; Thierry, Michel
> >;
> >Chris Wilson ; Winiarski, Michal
> >; Lis, Tomasz ; Ewins, Jon
> >; Sundaresan, Sujaritha
> >; Patel, Jalpa ; Li,
> >Yaodong
> >Subject: Re: [RFC PATCH] drm/i915/guc: New interface files for GuC starting
> >in
> >Gen11
> >
> >
> >
> >On 5/29/2018 7:59 AM, Michal Wajdeczko wrote:
> >> Hi,
> >>
> >> On Fri, 25 May 2018 23:59:35 +0200, Oscar Mateo
> >> wrote:
> >>
> >>> GuC interface has been redesigned (or cleaned up, rather) starting
> >>> with Gen11, as a stepping stone towards a new branching strategy
> >>> that helps maintain backwards compatibility with previous Gens, as
> >>> well as sideward compatibility with other OSes.
> >>>
> >>> The interface is split in two header files: one for the KMD and one
> >>> for clients of the GuC (which, in our case, happens to be the KMD
> >>> as well). SLPC interface files will come at a later date.
> >>>
> >>> Could we get eyes on the new interface header files, to make sure the
> >>> GuC team is moving in the right direction?
> >>>
> >>> Signed-off-by: Oscar Mateo
> >>> Cc: Joonas Lahtinen
> >>> Cc: Kevin Rogovin
> >>> Cc: John A Spotswood
> >>> Cc: Anusha Srivatsa
> >>> Cc: Daniele Ceraolo Spurio
> >>> Cc: Michal Wajdeczko
> >>> Cc: Michel Thierry
> >>> Cc: Chris Wilson
> >>> Cc: Michał Winiarski
> >>> Cc: Tomasz Lis
> >>> Cc: Jon Ewins
> >>> Cc: Sujaritha Sundaresan
> >>> Cc: Jalpa Patel
> >>> Cc: Jackie Li
> >>> ---
> >>> drivers/gpu/drm/i915/intel_guc_client_interface.h | 255 +++
> >>> drivers/gpu/drm/i915/intel_guc_kmd_interface.h | 847
> >>> ++
> >>> 2 files changed, 1102 insertions(+)
> >>> create mode 100644 drivers/gpu/drm/i915/intel_guc_client_interface.h
> >>> create mode 100644 drivers/gpu/drm/i915/intel_guc_kmd_interface.h
> >>
> >> can we name these files as:
> >>
> >> drivers/gpu/drm/i915/intel_guc_interface.h
> >> drivers/gpu/drm/i915/intel_guc_interface_client.h
> >> or
> >> drivers/gpu/drm/i915/intel_guc_defs.h
> >> drivers/gpu/drm/i915/intel_guc_defs_client.h
> >> or
> >> drivers/gpu/drm/i915/guc/guc.h
> >> drivers/gpu/drm/i915/guc/guc_client.h
> >
> >I'm fine with any of these names.
> >
> >>
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_guc_client_interface.h
> >>> b/drivers/gpu/drm/i915/intel_guc_client_interface.h
> >>> new file mode 100644
> >>> index 000..1ef91a7
> >>> --- /dev/null
> >>> +++ b/drivers/gpu/drm/i915/intel_guc_client_interface.h
> >>> @@ -0,0 +1,255 @@
> >>> +/*
> >>> + * SPDX-License-Identifier: MIT
> >>> + *
> >>> + * Copyright © 2018 Intel Corporation
> >>> + */
> >>> +
> >>> +#ifndef _INTEL_GUC_CLIENT_INTERFACE_H_
> >>> +#define _INTEL_GUC_CLIENT_INTERFACE_H_
> >>> +
> >>
> >> need to include types.h for u32
> >
> >Will do.
> >
> >>
> >>> +#pragma pack(1)
> >>> +
> >>>
> >+/
> >*
> >>>
> >>> + ** Engines
> >>> **
> >>> +
> >>>
> >**
> >***/
> >>
> >> no fancy markups, please
> >>
> >
> >Ok.
> >
> >>> +
> >>> +#define GUC_MAX_ENGINE_INSTANCE_PER_CLASS 4
> >>> +#define GUC_MAX_SCHEDULABLE_ENGINE_CLASS 5
> >>> +#define GUC_MAX_ENGINE_CLASS_COUNT 6
> >>> +#define GUC_ENGINE_INVALID 6
> >>
> >> hmm, why not 7 or 127 ?
> >> maybe if we need value for INVALID we should use 0 or -1 (~0)
> >
> >I'll pass this comment to the GuC team.
Any response from them on this and other raised items?
> >
> >>
> >>> +
> >>> +/* Engine Class that uKernel can schedule on. This is just a SW
> >>> enumeration.
> >>> + * HW configuration will depend on the Platform and SKU
> >>> + */
> >>> +enum uk_engine_class {
> >>
> >> why there is new prefix "uk" ?
> >
> >uk stands for uKernel. In this case, I'm guessing it is used to
> >differentiate between the engine class defined by hardware vs. the one
> >defined by the uKernel.
> >>
> >>> + UK_RENDER_ENGINE_CLASS = 0,
> >>> + UK_VDECENC_ENGINE_CLASS = 1,
> >>> + UK_VE_ENGINE_CLASS = 2,
> >>> + UK_BLT_COPY_ENGINE_CLASS = 3,
> >>> + UK_RESERVED_ENGINE_CLASS = 4,
> >>> + UK_OTHER_ENGINE_CLASS = 5,
> >>
> >> either use valid names or drop
[Intel-gfx] [PATCH i-g-t] lib: Report file cache as available system memory
sysinfo() doesn't include all reclaimable memory. In particular it
excludes the majority of global_node_page_state(NR_FILE_PAGES),
reclaimable pages that are a copy of on-disk files It seems the only way
to obtain this counter is by parsing /proc/meminfo. For comparison,
check vm_enough_memory() which includes NR_FILE_PAGES as available
(sadly there's no way to call vm_enough_memory() directly either!)
v2: Pay attention to what one writes.
Signed-off-by: Chris Wilson
---
lib/intel_os.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/lib/intel_os.c b/lib/intel_os.c
index 885ffdcec..5bd18fc52 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -84,6 +84,18 @@ intel_get_total_ram_mb(void)
return retval / (1024*1024);
}
+static uint64_t get_meminfo(const char *info, const char *tag)
+{
+ const char *str;
+ unsigned long val;
+
+ str = strstr(info, tag);
+ if (str && sscanf(str + strlen(tag), " %lu", ) == 1)
+ return (uint64_t)val << 10;
+
+ return 0;
+}
+
/**
* intel_get_avail_ram_mb:
*
@@ -96,17 +108,31 @@ intel_get_avail_ram_mb(void)
uint64_t retval;
#ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */
- struct sysinfo sysinf;
+ char *info;
int fd;
fd = drm_open_driver(DRIVER_INTEL);
intel_purge_vm_caches(fd);
close(fd);
- igt_assert(sysinfo() == 0);
- retval = sysinf.freeram;
- retval += min(sysinf.freeswap, sysinf.bufferram);
- retval *= sysinf.mem_unit;
+ fd = open("/proc", O_RDONLY);
+ info = igt_sysfs_get(fd, "meminfo");
+ close(fd);
+
+ if (info) {
+ retval = get_meminfo(info, "MemAvailable: ");
+ retval += get_meminfo(info, "Buffers: ");
+ retval += get_meminfo(info, "Cached: ");
+ retval += get_meminfo(info, "SwapCached: ");
+ free(info);
+ } else {
+ struct sysinfo sysinf;
+
+ igt_assert(sysinfo() == 0);
+ retval = sysinf.freeram;
+ retval += min(sysinf.freeswap, sysinf.bufferram);
+ retval *= sysinf.mem_unit;
+ }
#elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */
long pagesize, npages;
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Report file cache as available system memory
sysinfo() doesn't include all reclaimable memory. In particular it
excludes the majority of global_node_page_state(NR_FILE_PAGES),
reclaimable pages that are a copy of on-disk files It seems the only way
to obtain this counter is by parsing /proc/meminfo. For comparison,
check vm_enough_memory() which includes NR_FILE_PAGES as available
(sadly there's no way to call vm_enough_memory() directly either!)
Signed-off-by: Chris Wilson
---
lib/intel_os.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/lib/intel_os.c b/lib/intel_os.c
index 885ffdcec..a44f153d3 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -96,17 +96,41 @@ intel_get_avail_ram_mb(void)
uint64_t retval;
#ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */
- struct sysinfo sysinf;
+ char *info;
int fd;
fd = drm_open_driver(DRIVER_INTEL);
intel_purge_vm_caches(fd);
close(fd);
- igt_assert(sysinfo() == 0);
- retval = sysinf.freeram;
- retval += min(sysinf.freeswap, sysinf.bufferram);
- retval *= sysinf.mem_unit;
+ fd = open("/proc", O_RDONLY);
+ info = igt_sysfs_get(fd, "meminfo");
+ close(fd);
+
+ if (info) {
+ long val;
+
+ sscanf("MemAvailable: %lu", );
+ retval = val << 10;
+
+ sscanf("Buffers: %lu", );
+ retval += val << 10;
+
+ sscanf("Cached: %lu", );
+ retval += val << 10;
+
+ sscanf("SwapCached: %lu", );
+ retval += val << 10;
+
+ free(info);
+ } else {
+ struct sysinfo sysinf;
+
+ igt_assert(sysinfo() == 0);
+ retval = sysinf.freeram;
+ retval += min(sysinf.freeswap, sysinf.bufferram);
+ retval *= sysinf.mem_unit;
+ }
#elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */
long pagesize, npages;
--
2.18.0.rc2
___
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: Enable hw workaround to bypass alpha
== Series Details == Series: drm/i915: Enable hw workaround to bypass alpha URL : https://patchwork.freedesktop.org/series/45173/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359 -> Patchwork_9383 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9383 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9383, 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/45173/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9383: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9383 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: INCOMPLETE (fdo#106988, fdo#105600) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 37) == Missing(5): fi-byt-squawks fi-kbl-x1275 fi-ilk-m540 fi-glk-dsi fi-hsw-4200u == Build changes == * Linux: CI_DRM_4359 -> Patchwork_9383 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9383: 1c10ad664cb90e427538aa0b5c248ff1e28626c5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1c10ad664cb9 drm/i915: Enable hw workaround to bypass alpha == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9383/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
drm-misc-fixes-2018-06-21: Fixes for v4.18-rc2: - A reversion of a commit in drm/sun4i to fix a run-time fault. - Various fixes to the sii8620 bridge. - Small bugfix to correctly check stride in atmel-hlcdc. The following changes since commit c32048d9e93a5ab925d745396c63e7b912147f0a: drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense (2018-05-30 13:42:39 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-06-21 for you to fetch changes up to e8b92efa629dac0e70ea4145c5e70616de5f89c8: drm/bridge/sii8620: fix display of packed pixel modes in MHL2 (2018-06-21 10:16:24 +0200) Fixes for v4.18-rc2: - A reversion of a commit in drm/sun4i to fix a run-time fault. - Various fixes to the sii8620 bridge. - Small bugfix to correctly check stride in atmel-hlcdc. Andrzej Hajda (2): drm/bridge/sii8620: simplify hardware reset procedure drm/bridge/sii8620: fix loops in EDID fetch logic Maciej Purski (6): drm/bridge/sii8620: fix display modes validation drm/bridge/sii8620: fix potential buffer overflow drm/bridge/sii8620: start MHL transmission after HDMI signal detection drm/bridge/sii8620: remove HSIC initialization drm/bridge/sii8620: fix HDMI cable connection to dongle drm/bridge/sii8620: fix display of packed pixel modes in MHL2 Paul Kocialkowski (1): Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE" Stefan Agner (1): drm/atmel-hlcdc: check stride values in the first plane drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +- drivers/gpu/drm/bridge/sil-sii8620.c| 309 +--- drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -- 3 files changed, 118 insertions(+), 218 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/crt: make intel_crt_reset() static again
On Thu, Jun 21, 2018 at 04:03:30PM +0300, Jani Nikula wrote:
> Commit 9504a8924759 ("drm/i915/vlv: Reset the ADPA in
> vlv_display_power_well_init()") started calling intel_crt_reset()
> directly, while we could just as well use the hooks and keep the
> function static.
>
> Cc: Lyude
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_crt.c| 2 +-
> drivers/gpu/drm/i915/intel_drv.h| 1 -
> drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
> 3 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 0c6bf82bb059..c2cb3b7a255b 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -881,7 +881,7 @@ static int intel_crt_get_modes(struct drm_connector
> *connector)
> return ret;
> }
>
> -void intel_crt_reset(struct drm_encoder *encoder)
> +static void intel_crt_reset(struct drm_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0c3ac0eafde0..b2002fee1b58 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1373,7 +1373,6 @@ void gen9_disable_guc_interrupts(struct
> drm_i915_private *dev_priv);
> bool intel_crt_port_enabled(struct drm_i915_private *dev_priv,
> i915_reg_t adpa_reg, enum pipe *pipe);
> void intel_crt_init(struct drm_i915_private *dev_priv);
> -void intel_crt_reset(struct drm_encoder *encoder);
>
> /* intel_ddi.c */
> void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index de3a81034f77..0b3da5818383 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -972,7 +972,7 @@ static void vlv_display_power_well_init(struct
> drm_i915_private *dev_priv)
> /* Re-enable the ADPA, if we have one */
> for_each_intel_encoder(_priv->drm, encoder) {
> if (encoder->type == INTEL_OUTPUT_ANALOG)
> - intel_crt_reset(>base);
> + encoder->base.funcs->reset(>base);
I have a feeling I requested the direct call to make it less annoying to
figure out what it's actually calling. But if people prefer the function
pointer version I can live with that too.
Reviewed-by: Ville Syrjälä
> }
>
> i915_redisable_vga_power_on(dev_priv);
> --
> 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] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Enable hw workaround to bypass alpha
== Series Details == Series: drm/i915: Enable hw workaround to bypass alpha URL : https://patchwork.freedesktop.org/series/45173/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1c10ad664cb9 drm/i915: Enable hw workaround to bypass alpha -:27: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #27: FILE: drivers/gpu/drm/i915/i915_reg.h:7373: +#define PER_PIXEL_ALPHA_BYPASS_EN (1<<7) ^ -:58: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #58: FILE: drivers/gpu/drm/i915/intel_display.c:5703: + I915_WRITE_FW(PIPE_CHICKEN(pipe), + pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN); total: 0 errors, 0 warnings, 2 checks, 38 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Add IOCTL Param to control data port coherency.
On 2018-06-21 08:39, Joonas Lahtinen wrote: Changelog would be much appreciated. And this is not the first version of the series. It helps to remind the reviewer that original implementation was changed into IOCTl based on feedback. Please see the git log in i915 for some examples. Will add. I considered this a separate series, as it is a different implementation. Quoting Tomasz Lis (2018-06-20 18:03:07) The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is called, a command to switch data port coherency state is added to the ordered list. All prior requests are executed on old coherency settings, and all exec requests after the IOCTL will use new settings. Rationale: The OpenCL driver develpers requested a functionality to control cache coherency at data port level. Keeping the coherency at that level is disabled by default due to its performance costs. OpenCL driver is planning to enable it for a small subset of submissions, when such functionality is required. Below are answers to basic question explaining background of the functionality and reasoning for the proposed implementation: 1. Why do we need a coherency enable/disable switch for memory that is shared between CPU and GEN (GPU)? Memory coherency between CPU and GEN, while being a great feature that enables CL_MEM_SVM_FINE_GRAIN_BUFFER OCL capability on Intel GEN architecture, adds overhead related to tracking (snooping) memory inside different cache units (L1$, L2$, L3$, LLC$, etc.). At the same time, minority of modern OCL applications actually use CL_MEM_SVM_FINE_GRAIN_BUFFER (and hence require memory coherency between CPU and GPU). The goal of coherency enable/disable switch is to remove overhead of memory coherency when memory coherency is not needed. 2. Why do we need a global coherency switch? In order to support I/O commands from within EUs (Execution Units), Intel GEN ISA (GEN Instruction Set Assembly) contains dedicated "send" instructions. These send instructions provide several addressing models. One of these addressing models (named "stateless") provides most flexible I/O using plain virtual addresses (as opposed to buffer_handle+offset models). This "stateless" model is similar to regular memory load/store operations available on typical CPUs. Since this model provides I/O using arbitrary virtual addresses, it enables algorithmic designs that are based on pointer-to-pointer (e.g. buffer of pointers) concepts. For instance, it allows creating tree-like data structures such as: | NODE1 | | uint64_t data | +| | NODE* | NODE*| ++---+ / \ /\ | NODE2 || NODE3 | | uint64_t data || uint64_t data | +|+| | NODE* | NODE*|| NODE* | NODE*| ++---+++---+ Please note that pointers inside such structures can point to memory locations in different OCL allocations - e.g. NODE1 and NODE2 can reside in one OCL allocation while NODE3 resides in a completely separate OCL allocation. Additionally, such pointers can be shared with CPU (i.e. using SVM - Shared Virtual Memory feature). Using pointers from different allocations doesn't affect the stateless addressing model which even allows scattered reading from different allocations at the same time (i.e. by utilizing SIMD-nature of send instructions). When it comes to coherency programming, send instructions in stateless model can be encoded (at ISA level) to either use or disable coherency. However, for generic OCL applications (such as example with tree-like data structure), OCL compiler is not able to determine origin of memory pointed to by an arbitrary pointer - i.e. is not able to track given pointer back to a specific allocation. As such, it's not able to decide whether coherency is needed or not for specific pointer (or for specific I/O instruction). As a result, compiler encodes all stateless sends as coherent (doing otherwise would lead to functional issues resulting from data corruption). Please note that it would be possible to workaround this (e.g. based on allocations map and pointer bounds checking prior to each I/O instruction) but the performance cost of such workaround would be many times greater than the cost of keeping coherency always enabled. As such, enabling/disabling memory coherency at GEN ISA level is not feasible and alternative method is needed. Such alternative solution is to have a global coherency switch that allows disabling coherency for single (though entire) GPU submission. This is beneficial because this way we: * can enable (and pay for) coherency only in
Re: [Intel-gfx] [PATCH v1] drm/i915: Add IOCTL Param to control data port coherency.
On 2018-06-21 09:05, Chris Wilson wrote:
Quoting Tomasz Lis (2018-06-20 16:03:07)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 33bc914..c69dc26 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -258,6 +258,57 @@ intel_lr_context_descriptor_update(struct i915_gem_context
*ctx,
ce->lrc_desc = desc;
}
+static int emit_set_data_port_coherency(struct i915_request *req, bool enable)
+{
+ u32 *cs;
+ i915_reg_t reg;
+
+ GEM_BUG_ON(req->engine->class != RENDER_CLASS);
+ GEM_BUG_ON(INTEL_GEN(req->i915) < 9);
+
+ cs = intel_ring_begin(req, 4);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ if (INTEL_GEN(req->i915) >= 10)
+ reg = CNL_HDC_CHICKEN0;
+ else
+ reg = HDC_CHICKEN0;
+
+ /* FIXME: this feature may be unuseable on CNL; If this checks to be
+* true, we should enodev for CNL. */
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(reg);
+ /* Enabling coherency means disabling the bit which forces it off */
+ if (enable)
+ *cs++ = _MASKED_BIT_DISABLE(HDC_FORCE_NON_COHERENT);
+ else
+ *cs++ = _MASKED_BIT_ENABLE(HDC_FORCE_NON_COHERENT);
+ *cs++ = MI_NOOP;
+
+ intel_ring_advance(req, cs);
+
+ return 0;
+}
There's nothing specific to the logical ringbuffer context here afaics.
It could have just been done inside the single
i915_gem_context_set_data_port_coherency(). Also makes it clearer that
i915_gem_context_set_data_port_coherency needs struct_mutex.
cmd = HDC_FORCE_NON_COHERENT << 16;
if (!coherent)
cmd |= HDC_FORCE_NON_COHERENT;
*cs++ = cmd;
Does that read any clearer?
Sorry, I don't think I follow.
Should I move the code out of logical ringbuffer context (intel_lrc.c)?
Should I merge the emit_set_data_port_coherency() with
intel_lr_context_modify_data_port_coherency()?
Should I lock a mutex while adding the request?
-Tomasz
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 1593194..214e291 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -104,4 +104,8 @@ struct i915_gem_context;
void intel_lr_context_resume(struct drm_i915_private *dev_priv);
+int
+intel_lr_context_modify_data_port_coherency(struct i915_gem_context *ctx,
+bool enable);
+
#endif /* _INTEL_LRC_H_ */
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 7f5634c..fab072f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1453,6 +1453,7 @@ struct drm_i915_gem_context_param {
#define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE0x4
#define I915_CONTEXT_PARAM_BANNABLE0x5
#define I915_CONTEXT_PARAM_PRIORITY0x6
+#define I915_CONTEXT_PARAM_COHERENCY 0x7
DATAPORT_COHERENCY
There are many different caches.
There should be some commentary around here telling userspace what the
contract is.
Will do.
#define I915_CONTEXT_MAX_USER_PRIORITY 1023 /* inclusive */
#define I915_CONTEXT_DEFAULT_PRIORITY0
#define I915_CONTEXT_MIN_USER_PRIORITY -1023 /* inclusive */
COHERENCY has MAX/MIN_USER_PRIORITY, interesting. I thought it was just
a boolean.
-Chris
I did not noticed the structure of defines here; will move the new define.
-Tomasz
___
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/crt: make intel_crt_reset() static again
== Series Details == Series: drm/i915/crt: make intel_crt_reset() static again URL : https://patchwork.freedesktop.org/series/45167/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4359 -> Patchwork_9382 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9382 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9382, 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/45167/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9382: === IGT changes === Possible regressions igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-kbl-7560u: PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_9382 that come from known issues: === IGT changes === Warnings igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: INCOMPLETE (fdo#106988, fdo#105600) -> DMESG-WARN (fdo#106954) fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106954 https://bugs.freedesktop.org/show_bug.cgi?id=106954 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 37) == Missing(5): fi-byt-squawks fi-kbl-x1275 fi-ilk-m540 fi-glk-dsi fi-hsw-4200u == Build changes == * Linux: CI_DRM_4359 -> Patchwork_9382 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9382: caeefc8eeaf8ad18927a9bd623d3bfe35b0570f2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == caeefc8eeaf8 drm/i915/crt: make intel_crt_reset() static again == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9382/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Enable hw workaround to bypass alpha
Alpha blending with alpha 0 and 0xff passes through
alpha math and rounding logic causing differences
compared to fully transparent or opaque plane,resulting
in CRC mismatch.
This WA on icl and above enables hardware to bypass alpha
math and rounding for per pixel alpha values of 00 and 0xff
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4bfd7a9..6e59bfe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7366,6 +7366,14 @@ enum {
#define BDW_SCRATCH1 _MMIO(0xb11c)
#define GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
+/*GEN11 chicken */
+#define _PIPEA_CHICKEN 0x70038
+#define _PIPEB_CHICKEN 0x71038
+#define _PIPEC_CHICKEN 0x72038
+#define PER_PIXEL_ALPHA_BYPASS_EN (1<<7)
+#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
+ _PIPEB_CHICKEN)
+
/* PCH */
/* south display engine interrupt: IBX */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2c8fef3..ca5882c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5632,6 +5632,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
struct intel_atomic_state *old_intel_state =
to_intel_atomic_state(old_state);
bool psl_clkgate_wa;
+ u32 pipe_chicken;
if (WARN_ON(intel_crtc->active))
return;
@@ -5691,6 +5692,17 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
*/
intel_color_load_luts(_config->base);
+ /*
+* Display WA #1153: enable hardware to bypass the alpha math
+* and rounding for per-pixel values 00 and 0xff
+*/
+ if (INTEL_GEN(dev_priv) >= 11) {
+ pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
+ if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
+ I915_WRITE_FW(PIPE_CHICKEN(pipe),
+ pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN);
+ }
+
intel_ddi_set_pipe_settings(pipe_config);
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_transcoder_func(pipe_config);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: read EU powergating status from command streamer
Quoting Lionel Landwerlin (2018-06-21 14:14:52) > On 21/06/18 12:54, Chris Wilson wrote: > > Other than questioning your sanity here at doing this rather than just > > deleting the debugfs, there's nothing inherently broken. I would do it > > for gen8 as well, no point leaving the odd one out. > > We have an igt tests checking these values and because you haven't > brought up deleting the test before, I assumed we still wanted it fixed. > But now that you brought it up, I'm equally fine deleting this debugfs > code and removing the igt test. I presume as it exists someone found it useful. If not, wave goodbye :) Checking over the bug again, it has only been ourselves discussing it, no one else has noticed the bug so one presumes it is only igt that cares. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: read EU powergating status from command streamer
On 21/06/18 12:54, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-06-21 12:27:12)
Powergating of the EU array is configured as part of the context
image. This seems to imply we need a context to have run before we can
read the slice/subslice/EU powergating status.
This change captures the values of the powergating status registers
from the command streamer to ensure a valid we get valid values. This
is currently used only on gen9+ but someone could rightfully argue to
go as far as gen8.
Signed-off-by: Lionel Landwerlin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103484
---
drivers/gpu/drm/i915/i915_debugfs.c | 177
1 file changed, 155 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c400f42a54ec..0da8ce8acbcb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4310,14 +4310,120 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
#undef SS_MAX
}
-static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
-struct sseu_dev_info *sseu)
+static struct drm_i915_gem_object *
+gen9_read_registers(struct drm_i915_private *i915,
+ u32 *register_offsets,
+ u32 n_registers)
unsigned int n_register (or even unsigned long for total pedantry). I
don't see why you want to specify a bitwidth.
Sure.
+{
+ struct drm_i915_gem_object *bo;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ u32 *cs, bo_size = PAGE_SIZE * DIV_ROUND_UP(n_registers * 4, PAGE_SIZE);
+ int ret, r;
+
+ ret = i915_mutex_lock_interruptible(>drm);
+ if (ret)
+ return ERR_PTR(ret);
+
+ bo = i915_gem_object_create(i915, bo_size);
create_internal() (just be sure you don't read back uninitialised data)
bo_size = PAGE_ALIGN(sizeof(u32) * n_registers);
Thanks.
+ if (IS_ERR(bo)) {
+ ret = PTR_ERR(bo);
+ goto unlock;
+ }
+
+ ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
+ if (ret)
+ goto put_bo;
+
+
+ vma = i915_vma_instance(bo,
+ >kernel_context->ppgtt->vm,
+ NULL);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto put_bo;
+ }
+
+ ret = i915_vma_pin(vma, 0, GEN8_LR_CONTEXT_ALIGN, PIN_USER);
CONTEXT_ALIGN?
Dammit... copy-paste...
+ if (ret)
+ goto vma_unpin;
+
+
+ rq = i915_request_alloc(i915->engine[RCS], i915->kernel_context);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ goto vma_unpin;
+ }
+
+ cs = intel_ring_begin(rq, n_registers * 4);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ ret = PTR_ERR(cs);
+ goto vma_unpin;
+ }
+
+ for (r = 0; r < n_registers; r++) {
+ u64 offset = vma->node.start + r * 4;
+
+ *cs++ = MI_STORE_REGISTER_MEM_GEN8;
+ *cs++ = register_offsets[r];
+ *cs++ = lower_32_bits(offset);
+ *cs++ = upper_32_bits(offset);
+ }
I think you should i915_vma_move_to_active() for safety and give it
an active reference.
Indeed.
+ intel_ring_advance(rq, cs);
+
+ i915_request_add(rq);
+
+ mutex_unlock(>drm.struct_mutex);
+
+ i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
For sanity, check for an error. (Hence why using vma_move_to_active
becomes relevant.)
Thanks!
+ return bo;
+
+vma_unpin:
+ i915_vma_unpin(vma);
+put_bo:
+ i915_gem_object_put(bo);
+unlock:
+ mutex_unlock(>drm.struct_mutex);
+ return bo;
Report the ERR_PTR(ret) (otherwise, a neat use-after-free).
Oops my bad.
+}
+
+
+static int gen10_sseu_device_status(struct drm_i915_private *dev_priv,
+ struct sseu_dev_info *sseu)
{
#define SS_MAX 6
const struct intel_device_info *info = INTEL_INFO(dev_priv);
- u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
+ struct drm_i915_gem_object *bo;
+ struct {
+ u32 s_reg[SS_MAX];
+ u32 eu_reg[2 * SS_MAX];
+ } reg_offsets, *reg_data;
+ u32 eu_mask[2];
int s, ss;
+ for (s = 0; s < info->sseu.max_slices; s++) {
+ reg_offsets.s_reg[s] =
+ i915_mmio_reg_offset(GEN10_SLICE_PGCTL_ACK(s));
+ reg_offsets.eu_reg[2 * s] =
+ i915_mmio_reg_offset(GEN10_SS01_EU_PGCTL_ACK(s));
+ reg_offsets.eu_reg[2 * s] =
+ i915_mmio_reg_offset(GEN10_SS23_EU_PGCTL_ACK(s));
I started by wishing you used i915_mmio_t, but I can appreciate the
logic of having offset/data tied together in the same layout.
+ }
+
+
[Intel-gfx] [PATCH] drm/i915/crt: make intel_crt_reset() static again
Commit 9504a8924759 ("drm/i915/vlv: Reset the ADPA in
vlv_display_power_well_init()") started calling intel_crt_reset()
directly, while we could just as well use the hooks and keep the
function static.
Cc: Lyude
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_crt.c| 2 +-
drivers/gpu/drm/i915/intel_drv.h| 1 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0c6bf82bb059..c2cb3b7a255b 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -881,7 +881,7 @@ static int intel_crt_get_modes(struct drm_connector
*connector)
return ret;
}
-void intel_crt_reset(struct drm_encoder *encoder)
+static void intel_crt_reset(struct drm_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0c3ac0eafde0..b2002fee1b58 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1373,7 +1373,6 @@ void gen9_disable_guc_interrupts(struct drm_i915_private
*dev_priv);
bool intel_crt_port_enabled(struct drm_i915_private *dev_priv,
i915_reg_t adpa_reg, enum pipe *pipe);
void intel_crt_init(struct drm_i915_private *dev_priv);
-void intel_crt_reset(struct drm_encoder *encoder);
/* intel_ddi.c */
void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index de3a81034f77..0b3da5818383 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -972,7 +972,7 @@ static void vlv_display_power_well_init(struct
drm_i915_private *dev_priv)
/* Re-enable the ADPA, if we have one */
for_each_intel_encoder(_priv->drm, encoder) {
if (encoder->type == INTEL_OUTPUT_ANALOG)
- intel_crt_reset(>base);
+ encoder->base.funcs->reset(>base);
}
i915_redisable_vga_power_on(dev_priv);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: read EU powergating status from command streamer
== Series Details == Series: drm/i915: read EU powergating status from command streamer URL : https://patchwork.freedesktop.org/series/45161/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359 -> Patchwork_9381 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9381 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9381, 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/45161/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9381: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9381 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-no-display: fi-cnl-psr: NOTRUN -> DMESG-WARN (fdo#105395) +2 Possible fixes igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: INCOMPLETE (fdo#106988, fdo#105600) -> PASS fdo#105395 https://bugs.freedesktop.org/show_bug.cgi?id=105395 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 37) == Additional (1): fi-cnl-psr Missing(6): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4359 -> Patchwork_9381 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9381: ce6bc683714cbb21f445396851decdc3236323de @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ce6bc683714c drm/i915: read EU powergating status from command streamer == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9381/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, i915 fixes, nothing out of the ordinary. drm-intel-fixes-2018-06-21: drm/i915 fixes for v4.18-rc2: - Mostly cc: stable display fixes, including a DBLSCAN regression fix - GEM fixes for this merge window BR, Jani. The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-06-21 for you to fetch changes up to 7a3727f385dc64773db1c144f6b15c1e9d4735bb: drm/i915: Enable provoking vertex fix on Gen9 systems. (2018-06-19 15:48:24 +0300) drm/i915 fixes for v4.18-rc2: - Mostly cc: stable display fixes, including a DBLSCAN regression fix - GEM fixes for this merge window Chris Wilson (2): drm/i915: Apply batch location restrictions before pinning drm/i915/execlists: Avoid putting the error pointer Kenneth Graunke (1): drm/i915: Enable provoking vertex fix on Gen9 systems. Mika Kuoppala (1): drm/i915: Fix context ban and hang accounting for client Ville Syrjälä (4): drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI drm/i915: Fix PIPESTAT irq ack on i965/g4x drm/i915: Disallow interlaced modes on g4x DP outputs drm/i915: Turn off g4x DP port in .post_disable() drivers/gpu/drm/i915/i915_drv.h| 21 +++ drivers/gpu/drm/i915/i915_gem.c| 57 +- drivers/gpu/drm/i915/i915_gem_context.c| 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 49 + drivers/gpu/drm/i915/i915_irq.c| 12 +-- drivers/gpu/drm/i915/i915_reg.h| 5 +++ drivers/gpu/drm/i915/intel_crt.c | 20 +++ drivers/gpu/drm/i915/intel_display.c | 16 +++-- drivers/gpu/drm/i915/intel_dp.c| 34 +- drivers/gpu/drm/i915/intel_dp_mst.c| 6 drivers/gpu/drm/i915/intel_dsi.c | 6 drivers/gpu/drm/i915/intel_dvo.c | 6 drivers/gpu/drm/i915/intel_hdmi.c | 6 drivers/gpu/drm/i915/intel_lrc.c | 18 +++--- drivers/gpu/drm/i915/intel_lvds.c | 5 +++ drivers/gpu/drm/i915/intel_sdvo.c | 6 drivers/gpu/drm/i915/intel_tv.c| 12 +-- 17 files changed, 204 insertions(+), 77 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ 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: read EU powergating status from command streamer
== Series Details == Series: drm/i915: read EU powergating status from command streamer URL : https://patchwork.freedesktop.org/series/45161/ State : warning == Summary == $ dim checkpatch origin/drm-tip ce6bc683714c drm/i915: read EU powergating status from command streamer -:53: CHECK:LINE_SPACING: Please don't use multiple blank lines #53: FILE: drivers/gpu/drm/i915/i915_debugfs.c:4338: + + -:66: CHECK:LINE_SPACING: Please don't use multiple blank lines #66: FILE: drivers/gpu/drm/i915/i915_debugfs.c:4351: + + -:108: CHECK:LINE_SPACING: Please don't use multiple blank lines #108: FILE: drivers/gpu/drm/i915/i915_debugfs.c:4393: + + -:214: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #214: FILE: drivers/gpu/drm/i915/i915_debugfs.c:4493: + reg_offsets.eu_reg[2*s] = ^ -:216: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #216: FILE: drivers/gpu/drm/i915/i915_debugfs.c:4495: + reg_offsets.eu_reg[2*s + 1] = ^ -:254: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #254: FILE: drivers/gpu/drm/i915/i915_debugfs.c:4541: + eu_cnt = 2 * hweight32(reg_data->eu_reg[2*s + ss/2] & ^ -:254: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV) #254: FILE: drivers/gpu/drm/i915/i915_debugfs.c:4541: + eu_cnt = 2 * hweight32(reg_data->eu_reg[2*s + ss/2] & ^ total: 0 errors, 0 warnings, 7 checks, 266 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: read EU powergating status from command streamer
== Series Details == Series: drm/i915: read EU powergating status from command streamer URL : https://patchwork.freedesktop.org/series/45161/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: read EU powergating status from command streamer -O:drivers/gpu/drm/i915/i915_debugfs.c:4361:49: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_debugfs.c:4361:49: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_debugfs.c:4417:49: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_debugfs.c:4417:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4464:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4464:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4544:49: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_debugfs.c:4544:49: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: read EU powergating status from command streamer
Quoting Lionel Landwerlin (2018-06-21 12:27:12)
> Powergating of the EU array is configured as part of the context
> image. This seems to imply we need a context to have run before we can
> read the slice/subslice/EU powergating status.
>
> This change captures the values of the powergating status registers
> from the command streamer to ensure a valid we get valid values. This
> is currently used only on gen9+ but someone could rightfully argue to
> go as far as gen8.
>
> Signed-off-by: Lionel Landwerlin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103484
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 177
> 1 file changed, 155 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c400f42a54ec..0da8ce8acbcb 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4310,14 +4310,120 @@ static void cherryview_sseu_device_status(struct
> drm_i915_private *dev_priv,
> #undef SS_MAX
> }
>
> -static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
> -struct sseu_dev_info *sseu)
> +static struct drm_i915_gem_object *
> +gen9_read_registers(struct drm_i915_private *i915,
> + u32 *register_offsets,
> + u32 n_registers)
unsigned int n_register (or even unsigned long for total pedantry). I
don't see why you want to specify a bitwidth.
> +{
> + struct drm_i915_gem_object *bo;
> + struct i915_request *rq;
> + struct i915_vma *vma;
> + u32 *cs, bo_size = PAGE_SIZE * DIV_ROUND_UP(n_registers * 4,
> PAGE_SIZE);
> + int ret, r;
> +
> + ret = i915_mutex_lock_interruptible(>drm);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + bo = i915_gem_object_create(i915, bo_size);
create_internal() (just be sure you don't read back uninitialised data)
bo_size = PAGE_ALIGN(sizeof(u32) * n_registers);
> + if (IS_ERR(bo)) {
> + ret = PTR_ERR(bo);
> + goto unlock;
> + }
> +
> + ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> + if (ret)
> + goto put_bo;
> +
> +
> + vma = i915_vma_instance(bo,
> + >kernel_context->ppgtt->vm,
> + NULL);
> + if (IS_ERR(vma)) {
> + ret = PTR_ERR(vma);
> + goto put_bo;
> + }
> +
> + ret = i915_vma_pin(vma, 0, GEN8_LR_CONTEXT_ALIGN, PIN_USER);
CONTEXT_ALIGN?
> + if (ret)
> + goto vma_unpin;
> +
> +
> + rq = i915_request_alloc(i915->engine[RCS], i915->kernel_context);
> + if (IS_ERR(rq)) {
> + ret = PTR_ERR(rq);
> + goto vma_unpin;
> + }
> +
> + cs = intel_ring_begin(rq, n_registers * 4);
> + if (IS_ERR(cs)) {
> + i915_request_add(rq);
> + ret = PTR_ERR(cs);
> + goto vma_unpin;
> + }
> +
> + for (r = 0; r < n_registers; r++) {
> + u64 offset = vma->node.start + r * 4;
> +
> + *cs++ = MI_STORE_REGISTER_MEM_GEN8;
> + *cs++ = register_offsets[r];
> + *cs++ = lower_32_bits(offset);
> + *cs++ = upper_32_bits(offset);
> + }
I think you should i915_vma_move_to_active() for safety and give it
an active reference.
> + intel_ring_advance(rq, cs);
> +
> + i915_request_add(rq);
> +
> + mutex_unlock(>drm.struct_mutex);
> +
> + i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
For sanity, check for an error. (Hence why using vma_move_to_active
becomes relevant.)
> + return bo;
> +
> +vma_unpin:
> + i915_vma_unpin(vma);
> +put_bo:
> + i915_gem_object_put(bo);
> +unlock:
> + mutex_unlock(>drm.struct_mutex);
> + return bo;
Report the ERR_PTR(ret) (otherwise, a neat use-after-free).
> +}
> +
> +
> +static int gen10_sseu_device_status(struct drm_i915_private *dev_priv,
> + struct sseu_dev_info *sseu)
> {
> #define SS_MAX 6
> const struct intel_device_info *info = INTEL_INFO(dev_priv);
> - u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
> + struct drm_i915_gem_object *bo;
> + struct {
> + u32 s_reg[SS_MAX];
> + u32 eu_reg[2 * SS_MAX];
> + } reg_offsets, *reg_data;
> + u32 eu_mask[2];
> int s, ss;
>
> + for (s = 0; s < info->sseu.max_slices; s++) {
> + reg_offsets.s_reg[s] =
> + i915_mmio_reg_offset(GEN10_SLICE_PGCTL_ACK(s));
> + reg_offsets.eu_reg[2 * s] =
> + i915_mmio_reg_offset(GEN10_SS01_EU_PGCTL_ACK(s));
> + reg_offsets.eu_reg[2 * s] =
> + i915_mmio_reg_offset(GEN10_SS23_EU_PGCTL_ACK(s));
I started by wishing you used i915_mmio_t,
[Intel-gfx] ✓ Fi.CI.BAT: success for kernel: Show panic string after panic-notifiers
== Series Details == Series: kernel: Show panic string after panic-notifiers URL : https://patchwork.freedesktop.org/series/45160/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4359 -> Patchwork_9380 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45160/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9380 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-no-display: fi-cnl-psr: NOTRUN -> DMESG-WARN (fdo#105395) +2 igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) Possible fixes igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: INCOMPLETE (fdo#106988, fdo#105600) -> PASS fdo#105395 https://bugs.freedesktop.org/show_bug.cgi?id=105395 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 fdo#106988 https://bugs.freedesktop.org/show_bug.cgi?id=106988 == Participating hosts (42 -> 38) == Additional (1): fi-cnl-psr Missing(5): fi-byt-squawks fi-kbl-x1275 fi-ilk-m540 fi-glk-dsi fi-hsw-4200u == Build changes == * Linux: CI_DRM_4359 -> Patchwork_9380 CI_DRM_4359: fe0300c16bff0f9c82050e56cdbc3880f87e39bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9380: 390deb98237f4e94557da64035c0364cba6100bb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 390deb98237f kernel: Show panic string after panic-notifiers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9380/issues.html ___ 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/psr: Add psr1 live status
== Series Details == Series: drm/i915/psr: Add psr1 live status URL : https://patchwork.freedesktop.org/series/45143/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4356_full -> Patchwork_9379_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9379_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9379_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9379_full: === IGT changes === Warnings igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9379_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) igt@drv_selftest@live_hugepages: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@drv_selftest@live_gtt: shard-apl: FAIL (fdo#105347) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 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_4356 -> Patchwork_9379 CI_DRM_4356: a4e89d32048de56cde61e40efec9a0a697c238b6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9379: 0ecff7d6fbd47e524c0c66a8133355b3a5ac1f9e @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9379/shards.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 kernel: Show panic string after panic-notifiers
== Series Details ==
Series: kernel: Show panic string after panic-notifiers
URL : https://patchwork.freedesktop.org/series/45160/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
390deb98237f kernel: Show panic string after panic-notifiers
-:36: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using
'panic', this function's name, in a string
#36: FILE: kernel/panic.c:219:
+ pr_emerg("Kernel panic - not syncing: %s\n", buf);
total: 0 errors, 1 warnings, 0 checks, 21 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: read EU powergating status from command streamer
Powergating of the EU array is configured as part of the context
image. This seems to imply we need a context to have run before we can
read the slice/subslice/EU powergating status.
This change captures the values of the powergating status registers
from the command streamer to ensure a valid we get valid values. This
is currently used only on gen9+ but someone could rightfully argue to
go as far as gen8.
Signed-off-by: Lionel Landwerlin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103484
---
drivers/gpu/drm/i915/i915_debugfs.c | 177
1 file changed, 155 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c400f42a54ec..0da8ce8acbcb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4310,14 +4310,120 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
#undef SS_MAX
}
-static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
-struct sseu_dev_info *sseu)
+static struct drm_i915_gem_object *
+gen9_read_registers(struct drm_i915_private *i915,
+ u32 *register_offsets,
+ u32 n_registers)
+{
+ struct drm_i915_gem_object *bo;
+ struct i915_request *rq;
+ struct i915_vma *vma;
+ u32 *cs, bo_size = PAGE_SIZE * DIV_ROUND_UP(n_registers * 4, PAGE_SIZE);
+ int ret, r;
+
+ ret = i915_mutex_lock_interruptible(>drm);
+ if (ret)
+ return ERR_PTR(ret);
+
+ bo = i915_gem_object_create(i915, bo_size);
+ if (IS_ERR(bo)) {
+ ret = PTR_ERR(bo);
+ goto unlock;
+ }
+
+ ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
+ if (ret)
+ goto put_bo;
+
+
+ vma = i915_vma_instance(bo,
+ >kernel_context->ppgtt->vm,
+ NULL);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto put_bo;
+ }
+
+ ret = i915_vma_pin(vma, 0, GEN8_LR_CONTEXT_ALIGN, PIN_USER);
+ if (ret)
+ goto vma_unpin;
+
+
+ rq = i915_request_alloc(i915->engine[RCS], i915->kernel_context);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ goto vma_unpin;
+ }
+
+ cs = intel_ring_begin(rq, n_registers * 4);
+ if (IS_ERR(cs)) {
+ i915_request_add(rq);
+ ret = PTR_ERR(cs);
+ goto vma_unpin;
+ }
+
+ for (r = 0; r < n_registers; r++) {
+ u64 offset = vma->node.start + r * 4;
+
+ *cs++ = MI_STORE_REGISTER_MEM_GEN8;
+ *cs++ = register_offsets[r];
+ *cs++ = lower_32_bits(offset);
+ *cs++ = upper_32_bits(offset);
+ }
+
+ intel_ring_advance(rq, cs);
+
+ i915_request_add(rq);
+
+ mutex_unlock(>drm.struct_mutex);
+
+ i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
+
+ return bo;
+
+vma_unpin:
+ i915_vma_unpin(vma);
+put_bo:
+ i915_gem_object_put(bo);
+unlock:
+ mutex_unlock(>drm.struct_mutex);
+ return bo;
+}
+
+
+static int gen10_sseu_device_status(struct drm_i915_private *dev_priv,
+ struct sseu_dev_info *sseu)
{
#define SS_MAX 6
const struct intel_device_info *info = INTEL_INFO(dev_priv);
- u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
+ struct drm_i915_gem_object *bo;
+ struct {
+ u32 s_reg[SS_MAX];
+ u32 eu_reg[2 * SS_MAX];
+ } reg_offsets, *reg_data;
+ u32 eu_mask[2];
int s, ss;
+ for (s = 0; s < info->sseu.max_slices; s++) {
+ reg_offsets.s_reg[s] =
+ i915_mmio_reg_offset(GEN10_SLICE_PGCTL_ACK(s));
+ reg_offsets.eu_reg[2 * s] =
+ i915_mmio_reg_offset(GEN10_SS01_EU_PGCTL_ACK(s));
+ reg_offsets.eu_reg[2 * s] =
+ i915_mmio_reg_offset(GEN10_SS23_EU_PGCTL_ACK(s));
+ }
+
+ bo = gen9_read_registers(dev_priv, reg_offsets.s_reg,
+sizeof(reg_offsets) / sizeof(u32));
+ if (IS_ERR(bo))
+ return PTR_ERR(bo);
+
+ reg_data = i915_gem_object_pin_map(bo, I915_MAP_WB);
+ if (IS_ERR(reg_data)) {
+ i915_gem_object_put(bo);
+ return PTR_ERR(reg_data);
+ }
+
for (s = 0; s < info->sseu.max_slices; s++) {
/*
* FIXME: Valid SS Mask respects the spec and read
@@ -4325,10 +4431,7 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
* although this seems wrong because it would leave many
* subslices without ACK.
*/
- s_reg[s] = I915_READ(GEN10_SLICE_PGCTL_ACK(s)) &
-
[Intel-gfx] [PATCH] kernel: Show panic string after panic-notifiers
A problem we encounter with using ftrace-dump-on-oops is that our
tracing overflows the pstore, losing the vital information of what
caused the panic. Let's print that information after the traces instead
of before so it should end up in the pstore for post-mortem.
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
kernel/panic.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 9f35f1e31d06..3d8cfadeb098 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -172,10 +172,6 @@ void panic(const char *fmt, ...)
console_verbose();
bust_spinlocks(1);
- va_start(args, fmt);
- vsnprintf(buf, sizeof(buf), fmt, args);
- va_end(args);
- pr_emerg("Kernel panic - not syncing: %s\n", buf);
#ifdef CONFIG_DEBUG_BUGVERBOSE
/*
* Avoid nested stack-dumping if a panic occurs during oops processing
@@ -217,6 +213,11 @@ void panic(const char *fmt, ...)
*/
atomic_notifier_call_chain(_notifier_list, 0, buf);
+ va_start(args, fmt);
+ vsnprintf(buf, sizeof(buf), fmt, args);
+ va_end(args);
+ pr_emerg("Kernel panic - not syncing: %s\n", buf);
+
/* Call flush even twice. It tries harder with a single online CPU */
printk_safe_flush_on_panic();
kmsg_dump(KMSG_DUMP_PANIC);
--
2.18.0.rc2
___
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: Redefine EINVAL for debugging
== Series Details == Series: drm/i915: Redefine EINVAL for debugging URL : https://patchwork.freedesktop.org/series/45142/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4356_full -> Patchwork_9378_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9378_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9378_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9378_full: === IGT changes === Warnings igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: shard-snb: SKIP -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-render: shard-hsw: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9378_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106947, fdo#106560) shard-apl: PASS -> DMESG-FAIL (fdo#106947, fdo#106560) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) Possible fixes igt@drv_selftest@live_gtt: shard-apl: FAIL (fdo#105347) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 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#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 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_4356 -> Patchwork_9378 CI_DRM_4356: a4e89d32048de56cde61e40efec9a0a697c238b6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9378: 2c63268cc448d5d5e6435f0e21c27916588a8c08 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9378/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
drm-misc-next-2018-06-21: drm-misc-next for 4.19: Cross-subsystem Changes: - fix compile breakage on ION due to the dma-buf cleanups (Christian König) The following changes since commit daf0678c2036c918f01e4aa6035629d2debc2f30: Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-06-15 11:32:29 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-06-21 for you to fetch changes up to c612ae0503af753c062594dcd14aecea121fa414: staging: android: ion: fix ion_dma_buf_attach signatur (2018-06-21 11:46:47 +0200) drm-misc-next for 4.19: UAPI Changes: - Add writeback connector (Brian Starkey/Liviu Dudau) - Add "content type" property to HDMI connectors (Stanislav Lisovskiy) Cross-subsystem Changes: - some devicetree Docs update - fix compile breakage on ION due to the dma-buf cleanups (Christian König) Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) Driver Changes: - Fixes for the otm8009a panel driver (Philippe Cornu) - Add Innolux TV123WAM panel driver support (Sandeep Panda) - Move GEM BO to drm_framebuffer in few drivers (Daniel Stone) - i915 pinning improvements (Chris Wilson) - Stop consulting plane->fb/crtc in a few drivers (Ville Syrjälä) Alexandru Gheorghe (1): drm/atomic: Set current atomic state in drm_private_state Arnd Bergmann (1): drm/sun4i: mark PM functions as __maybe_unused Brian Starkey (2): drm: Add writeback connector type drm: writeback: Add out-fences for writeback connectors Chris Wilson (5): drm/mm: Reject over-sized allocation requests early drm/mm: Add a search-by-address variant to only inspect a single hole drm/i915: Limit searching for PIN_HIGH drm/i915: Pin the ring high drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build Christian König (3): dma_buf: remove device parameter from attach callback v2 dma-buf: remove kmap_atomic interface staging: android: ion: fix ion_dma_buf_attach signatur Colin Ian King (1): drm/xen-front: fix spelling mistake: "conector" -> "connector" Dan Carpenter (1): drm/v3d: Checking for NULL vs IS_ERR() Daniel Stone (14): drm/cirrus: Place GEM BOs in drm_framebuffer drm/cirrus: cirrus_framebuffer -> drm_framebuffer drm/virtio: Place GEM BOs in drm_framebuffer drm/armada: Move GEM BO to drm_framebuffer drm/gma500: Move GEM BO to drm_framebuffer drm/msm: Move GEM BOs to drm_framebuffer drm/mtk: Remove impossible internal error drm/mtk: Move GEM BO to drm_framebuffer drm/mtk: mtk_drm_fb -> drm_framebuffer drm/rockchip: Place GEM BOs in drm_framebuffer drm/rockchip: rockchip_drm_fb -> drm_framebuffer drm/omap: Move GEM BO to drm_framebuffer drm/omap: Move buffer pitch/offset to drm_framebuffer drm/gma500: Fix Medfield for drm_framebuffer move Daniel Vetter (3): drm/fb-helper: Fix typo on kerneldoc drm/gem-fb-helper: Always do implicit sync drm/vc4: Always obey implicit sync Dave Stevenson (1): drm/vc4: Add support for SAND modifier. Eric Anholt (2): drm: Trust format_mod_supported() when it OKs a plane modifier. drm/vc4: Add missing formats to vc4_format_mod_supported(). Gerd Hoffmann (1): dma-buf: make map_atomic and map function pointers optional Gustavo Padovan (1): Merge drm-upstream/drm-next into drm-misc-next Haneen Mohammed (1): drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers Heiko Stuebner (1): drm/rockchip: vop: split out core clock enablement into separate functions Inki Dae (1): drm/bridge: sil_sii8620: do not have a dependency of RC_CORE Julia Lawall (1): drm/rockchip: lvds: add missing of_node_put Jyri Sarha (2): drm/panel: Remove drm_panel_detach() calls from all panel drivers drm/panel: Add device_link from panel device to DRM device Laura Abbott (2): drm/gma500: Remove VLA drm/i2c: tda998x: Remove VLA usage Lin Huang (1): drm/rockchip: cnd-dp: adjust spdif register setting Liviu Dudau (1): drm: writeback: Add client capability for exposing writeback connectors Lubosz Sarnecki (1): drm/edid: Quirk Vive Pro VR headset non-desktop. Lucas Stach (1): drm/panel: simple: AUO P320HVN03 uses SPWG data ordering Lukasz Majewski (1): display: panel: Add AUO g070vvn01 display support (800x480) Maxime Ripard (1): drm/vc4: plane: Expand the lower bits by repeating the higher bits Oleksandr Andrushchenko (1): drm/xen-front: fix pointer casts Peter Rosin (1): drm/rockchip: lvds: avoid duplicating drm_bridge_attach Philippe
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Ignore applying the self-relocation BIAS if no relocations
Quoting Patchwork (2018-06-21 08:51:28) > Possible fixes > > igt@gem_exec_gttfill@basic: > fi-byt-n2820: FAIL (fdo#106744) -> PASS Flipper be gone, thanks for the kind review, -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 drm/i915: Ignore applying the self-relocation BIAS if no relocations
== Series Details == Series: drm/i915: Ignore applying the self-relocation BIAS if no relocations URL : https://patchwork.freedesktop.org/series/45140/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4356_full -> Patchwork_9377_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9377_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9377_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9377_full: === IGT changes === Warnings igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9377_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-apl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) Possible fixes igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 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_4356 -> Patchwork_9377 CI_DRM_4356: a4e89d32048de56cde61e40efec9a0a697c238b6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9377: 672b5cbffdae483f720c0412567b62ba1ff7ef2f @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9377/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-next
Hi Gustavo, Am 21.06.2018 um 02:58 schrieb Gustavo Padovan: Hi Dave, our first pull for 4.19, over 90 patches here, probably the most important ones are for the writeback connector support. Then we have a bunch of fixes to drivers, some interesting core cleanups and new panel drivers. This contains a backmerge of drm-next due to conflicts in drm_atomic.c Please pull, Gustavo drm-misc-next-2018-06-20-1: drm-misc-next for 4.19: UAPI Changes: - Add writeback connector (Brian Starkey/Liviu Dudau) - Add "content type" property to HDMI connectors (Stanislav Lisovskiy) Cross-subsystem Changes: - some devicetree Docs update Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) My dma-buf cleanups unfortunately caused a build breakage in ION which I just pushed a fix for into drm-misc-next. Could you resend this pull request? Thanks in advance and sorry for the noise, Christian. Driver Changes: - Fixes for the otm8009a panel driver (Philippe Cornu) - Add Innolux TV123WAM panel driver support (Sandeep Panda) - Move GEM BO to drm_framebuffer in few drivers (Daniel Stone) - i915 pinning improvements (Chris Wilson) - Stop consulting plane->fb/crtc in a few drivers (Ville Syrjälä) The following changes since commit daf0678c2036c918f01e4aa6035629d2debc2f30: Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-06-15 11:32:29 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-06-20-1 for you to fetch changes up to f55786faa156370374c358d186eabf2f6e32e93f: drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build (2018-06-20 17:48:24 +0100) drm-misc-next for 4.19: UAPI Changes: - Add writeback connector (Brian Starkey/Liviu Dudau) - Add "content type" property to HDMI connectors (Stanislav Lisovskiy) Cross-subsystem Changes: - some devicetree Docs update Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) Driver Changes: - Fixes for the otm8009a panel driver (Philippe Cornu) - Add Innolux TV123WAM panel driver support (Sandeep Panda) - Move GEM BO to drm_framebuffer in few drivers (Daniel Stone) - i915 pinning improvements (Chris Wilson) - Stop consulting plane->fb/crtc in a few drivers (Ville Syrjälä) Alexandru Gheorghe (1): drm/atomic: Set current atomic state in drm_private_state Arnd Bergmann (1): drm/sun4i: mark PM functions as __maybe_unused Brian Starkey (2): drm: Add writeback connector type drm: writeback: Add out-fences for writeback connectors Chris Wilson (5): drm/mm: Reject over-sized allocation requests early drm/mm: Add a search-by-address variant to only inspect a single hole drm/i915: Limit searching for PIN_HIGH drm/i915: Pin the ring high drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build Christian König (2): dma_buf: remove device parameter from attach callback v2 dma-buf: remove kmap_atomic interface Colin Ian King (1): drm/xen-front: fix spelling mistake: "conector" -> "connector" Dan Carpenter (1): drm/v3d: Checking for NULL vs IS_ERR() Daniel Stone (14): drm/cirrus: Place GEM BOs in drm_framebuffer drm/cirrus: cirrus_framebuffer -> drm_framebuffer drm/virtio: Place GEM BOs in drm_framebuffer drm/armada: Move GEM BO to drm_framebuffer drm/gma500: Move GEM BO to drm_framebuffer drm/msm: Move GEM BOs to drm_framebuffer drm/mtk: Remove impossible internal error drm/mtk: Move GEM BO to drm_framebuffer drm/mtk: mtk_drm_fb -> drm_framebuffer drm/rockchip: Place GEM BOs in drm_framebuffer drm/rockchip: rockchip_drm_fb -> drm_framebuffer drm/omap: Move GEM BO to drm_framebuffer drm/omap: Move buffer pitch/offset to drm_framebuffer drm/gma500: Fix Medfield for drm_framebuffer move Daniel Vetter (3): drm/fb-helper: Fix typo on kerneldoc drm/gem-fb-helper: Always do implicit sync drm/vc4: Always obey implicit sync Dave Stevenson (1): drm/vc4: Add support for SAND modifier. Eric Anholt (2): drm: Trust format_mod_supported() when it OKs a plane modifier. drm/vc4: Add missing formats to vc4_format_mod_supported(). Gerd Hoffmann (1): dma-buf: make map_atomic and map function pointers optional Gustavo Padovan (1): Merge drm-upstream/drm-next into drm-misc-next Haneen Mohammed (1): drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers Heiko Stuebner (1): drm/rockchip: vop: split out core clock
Re: [Intel-gfx] [PATCH] drm/i915: Redefine EINVAL for debugging
Quoting Joonas Lahtinen (2018-06-21 09:53:20) > Quoting Chris Wilson (2018-06-21 11:01:50) > > To aide debugging spurious EINVALs, include a debug message every time > > we emit one from execbuf. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=106744 > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > That's special kind of evil. But should do the job. > > Reviewed-by: Joonas Lahtinen > > You might be able to get away from hardcoding the 22 with first > calling the macro __EINVAL and then doing some trickery. Not sure what trickery. I tried the usual #define __concat(x, y) x##y indirection, but my CPP magic needs more power. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Add psr1 live status
On Thu, 21 Jun 2018, vathsala nagaraju wrote:
> From: Vathsala Nagaraju
>
> Prints live state of psr1.Extending the existing
> PSR2 live state function to cover psr1.
>
> Tested on KBL with psr2 and psr1 panel.
>
> v2: rebase
> v3: DK
> Rename psr2_live_status to psr_source_status.
> v4: DK
> Move EDP_PSR_STATUS_STATE_SHIFT below EDP_PSR_STATUS_STATE_MASK.
> Pass seq to psr_source_status, handle source status prints in
> psr_source_status.
> v5: Fixed CI warning messages
> v6:
> Remove extra space in the title before the colon.(DK)
> Rebase. (Jani)
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
>
> Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: Vathsala Nagaraju
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 72
> -
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 49 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c400f42..3941d85 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2597,27 +2597,55 @@ static int i915_guc_log_relay_release(struct inode
> *inode, struct file *file)
> .release = i915_guc_log_relay_release,
> };
>
> -static const char *psr2_live_status(u32 val)
> -{
> - static const char * const live_status[] = {
> - "IDLE",
> - "CAPTURE",
> - "CAPTURE_FS",
> - "SLEEP",
> - "BUFON_FW",
> - "ML_UP",
> - "SU_STANDBY",
> - "FAST_SLEEP",
> - "DEEP_SLEEP",
> - "BUF_ON",
> - "TG_ON"
> - };
> +static void
> +psr_source_status(struct drm_i915_private *dev_priv, struct seq_file *m)
> +{
> + u32 val, psr_status = 0;
>
> - val = (val & EDP_PSR2_STATUS_STATE_MASK) >> EDP_PSR2_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status))
> - return live_status[val];
> + if (dev_priv->psr.psr2_enabled) {
> + static const char * const live_status[] = {
> + "IDLE",
> + "CAPTURE",
> + "CAPTURE_FS",
> + "SLEEP",
> + "BUFON_FW",
> + "ML_UP",
> + "SU_STANDBY",
> + "FAST_SLEEP",
> + "DEEP_SLEEP",
> + "BUF_ON",
> + "TG_ON"
> + };
> + psr_status = I915_READ(EDP_PSR2_STATUS);
> + val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
> + EDP_PSR2_STATUS_STATE_SHIFT;
> + if (val < ARRAY_SIZE(live_status)) {
> + seq_printf(m, "Source PSR status: %x[%s]\n", psr_status,
> +live_status[val]);
> + return;
> + }
> + } else {
> + static const char * const live_status[] = {
> + "IDLE",
> + "SRDONACK",
> + "SRDENT",
> + "BUFOFF",
> + "BUFON",
> + "AUXACK",
> + "SRDOFFACK",
> + "SRDENT_ON",
> + };
> + psr_status = I915_READ(EDP_PSR_STATUS);
> + val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
> + EDP_PSR_STATUS_STATE_SHIFT;
> + if (val < ARRAY_SIZE(live_status)) {
> + seq_printf(m, "Source PSR status: %x[%s]\n", psr_status,
> +live_status[val]);
> + return;
> + }
> + }
>
> - return "unknown";
> + seq_printf(m, "Source psr status: %x[%s]\n", psr_status, "unknown");
> }
>
> static const char *psr_sink_status(u8 val)
> @@ -2681,12 +2709,8 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
>
> seq_printf(m, "Performance_Counter: %u\n", psrperf);
> }
> - if (dev_priv->psr.psr2_enabled) {
> - u32 psr2 = I915_READ(EDP_PSR2_STATUS);
>
> - seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> -psr2, psr2_live_status(psr2));
> - }
> + psr_source_status(dev_priv, m);
>
> if (dev_priv->psr.enabled) {
> struct drm_dp_aux *aux = _priv->psr.enabled->aux;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4bfd7a9..f026492 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4072,6 +4072,7 @@ enum {
>
> #define EDP_PSR_STATUS
> _MMIO(dev_priv->psr_mmio_base + 0x40)
> #define EDP_PSR_STATUS_STATE_MASK (7 << 29)
> +#define EDP_PSR_STATUS_STATE_SHIFT29
Please use tabs for indenting the values.
BR,
Jani.
> #define EDP_PSR_STATUS_STATE_IDLE (0 << 29)
> #define
Re: [Intel-gfx] [PATCH] drm/i915: Ignore applying the self-relocation BIAS if no relocations
Quoting Chris Wilson (2018-06-21 10:32:05)
> We only need to apply the BIAS for self-relocations into the batchbuffer
> iff the execobject has any relocations.
>
> This suppresses some warnings we may get with a full gtt (so the batch
> object has wound up at 0 from a previous invocation), but doesn't fix
> the underlying problem of how we tried to move a pinned batch vma (how
> we have a pinned user vma outside of execbuf, I do not know, though this
> being on an aliasing ppgtt means it could be a spurious pinning via the
> global gtt). One step at a time...
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=106744#c1
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Long commit message short; don't need to bias the batch buffer if it
doesn't reference itself via an address...
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 60dc2a865f5f..437441f4af41 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -534,7 +534,8 @@ eb_add_vma(struct i915_execbuffer *eb,
> * paranoia do it everywhere.
> */
> if (i == batch_idx) {
> - if (!(eb->flags[i] & EXEC_OBJECT_PINNED))
> + if (entry->relocation_count &&
> + !(eb->flags[i] & EXEC_OBJECT_PINNED))
> eb->flags[i] |= __EXEC_OBJECT_NEEDS_BIAS;
> if (eb->reloc_cache.has_fence)
> eb->flags[i] |= EXEC_OBJECT_NEEDS_FENCE;
> --
> 2.18.0.rc2
>
___
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/fbc/cnl: Add GLK and CNL+ hardware tracking size
On Wed, 20 Jun 2018, José Roberto de Souza wrote:
Please add a commit message, always.
Please make the subject prefix just "drm/i915/fbc" because cnl is
misleading there.
BR,
Jani.
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index b431b6733cc1..eb0f95390968 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -714,7 +714,10 @@ static bool intel_fbc_hw_tracking_covers_screen(struct
> intel_crtc *crtc)
> struct intel_fbc *fbc = _priv->fbc;
> unsigned int effective_w, effective_h, max_w, max_h;
>
> - if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> + max_w = 5120;
> + max_h = 4096;
> + } else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) {
> max_w = 4096;
> max_h = 4096;
> } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
