[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaRsUseTimeoutMode

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaRsUseTimeoutMode
URL   : https://patchwork.freedesktop.org/series/29185/
State : success

== Summary ==

Series 29185v1 drm/i915/cnl: WaRsUseTimeoutMode
https://patchwork.freedesktop.org/api/1.0/series/29185/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:453s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:443s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:557s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:254s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:528s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:526s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:436s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:612s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:443s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:429s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:503s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:498s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:598s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:598s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:531s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:468s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:483s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:504s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:550s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

489147dfdcc735baf773a6ec3698cf85a01d7008 drm-tip: 2017y-08m-22d-18h-44m-32s UTC 
integration manifest
ee788addbad5 drm/i915/cnl: WaRsUseTimeoutMode

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5471/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cnl: WaRsUseTimeoutMode

[Rodrigo Vivi]

Apparently RC6 residency is lower than expected
with EI mode for most of the cases on CNL A0, B0 and C0.

This Wa doesn't solve our lower residency, but I
believe it is better to have it since EI is not
expected to work by HW engineers anyways.

Cc: David Weinehall 
Cc: Mika Kuoppala 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 11 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7587ef53026b..cb017b7d8ccb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2967,6 +2967,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 
 #define CNL_REVID_A0   0x0
 #define CNL_REVID_B0   0x1
+#define CNL_REVID_C0   0x2
 
 #define IS_CNL_REVID(p, since, until) \
(IS_CANNONLAKE(p) && IS_REVID(p, since, until))
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d5ff0b9f999f..8c6d74d94799 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6456,7 +6456,7 @@ static void gen9_enable_rc6(struct drm_i915_private 
*dev_priv)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
-   uint32_t rc6_mask = 0;
+   u32 rc6_mode, rc6_mask = 0;
 
/* 1a: Software RC state - RC0 */
I915_WRITE(GEN6_RC_STATE, 0);
@@ -6494,8 +6494,15 @@ static void gen9_enable_rc6(struct drm_i915_private 
*dev_priv)
rc6_mask = GEN6_RC_CTL_RC6_ENABLE;
DRM_INFO("RC6 %s\n", onoff(rc6_mask & GEN6_RC_CTL_RC6_ENABLE));
I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
+
+   /* WaRsUseTimeoutMode:cnl (pre-prod) */
+   if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_C0))
+   rc6_mode = GEN7_RC_CTL_TO_MODE;
+   else
+   rc6_mode = GEN6_RC_CTL_EI_MODE(1);
+
I915_WRITE(GEN6_RC_CONTROL,
-  GEN6_RC_CTL_HW_ENABLE | GEN6_RC_CTL_EI_MODE(1) | rc6_mask);
+  GEN6_RC_CTL_HW_ENABLE | rc6_mode | rc6_mask);
 
/*
 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
-- 
2.13.2

___
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/cnl: WaForceContextSaveRestoreNonCoherent

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaForceContextSaveRestoreNonCoherent
URL   : https://patchwork.freedesktop.org/series/29184/
State : success

== Summary ==

Series 29184v1 drm/i915/cnl: WaForceContextSaveRestoreNonCoherent
https://patchwork.freedesktop.org/api/1.0/series/29184/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:451s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:433s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:355s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:554s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:525s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:525s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:432s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:614s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:449s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:483s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:495s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:597s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:603s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:529s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:467s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:485s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:443s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:491s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:546s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:405s

489147dfdcc735baf773a6ec3698cf85a01d7008 drm-tip: 2017y-08m-22d-18h-44m-32s UTC 
integration manifest
81dc69b366f2 drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5470/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

[Rodrigo Vivi]

To avoid a potential hang condition with TLB invalidation
we need to enable masked bit 5 of MMIO 0xE5F0 at boot.

Same workaround was in place for previous platforms,
but the change for CNL is more on the register offset.
But also BSpec doesn't mention the bit 15 as set on gen9
platforms and mark bit as reserved on CNL.

Cc: Mika Kuoppala 
Cc: Oscar Mateo 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h| 1 +
 drivers/gpu/drm/i915/intel_engine_cs.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d4ecb1905ad8..f31fab2651fb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7024,6 +7024,7 @@ enum {
 
 /* GEN8 chicken */
 #define HDC_CHICKEN0   _MMIO(0x7300)
+#define CNL_HDC_CHICKEN0   _MMIO(0xE5F0)
 #define  HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE(1<<15)
 #define  HDC_FENCE_DEST_SLM_DISABLE(1<<14)
 #define  HDC_DONOT_FETCH_MEM_WHEN_MASKED   (1<<11)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d23f18874309..26c35ce5f240 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1070,6 +1070,10 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
 
+   /* WaForceContextSaveRestoreNonCoherent:cnl */
+   WA_SET_BIT_MASKED(CNL_HDC_CHICKEN0,
+ HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT);
+
/* WaDisableReplayBufferBankArbitrationOptimization:cnl */
WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
  GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
-- 
2.13.2

___
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: Wire up shrinkctl->nr_scanned

[Andrew Morton]

On Tue, 22 Aug 2017 14:53:25 +0100 Chris Wilson  
wrote:

> shrink_slab() allows us to report back the number of objects we
> successfully scanned (out of the target shrinkctl->nr_to_scan). As
> report the number of pages owned by each GEM object as a separate item
> to the shrinker, we cannot precisely control the number of shrinker
> objects we scan on each pass; and indeed may free more than requested.
> If we fail to tell the shrinker about the number of objects we process,
> it will continue to hold a grudge against us as any objects left
> unscanned are added to the next reclaim -- and so we will keep on
> "unfairly" shrinking our own slab in comparison to other slabs.

It's unclear which tree this is against but I think I got it all fixed
up.  Please check the changes to i915_gem_shrink().

From: Chris Wilson 
Subject: drm/i915: wire up shrinkctl->nr_scanned

shrink_slab() allows us to report back the number of objects we
successfully scanned (out of the target shrinkctl->nr_to_scan).  As report
the number of pages owned by each GEM object as a separate item to the
shrinker, we cannot precisely control the number of shrinker objects we
scan on each pass; and indeed may free more than requested.  If we fail to
tell the shrinker about the number of objects we process, it will continue
to hold a grudge against us as any objects left unscanned are added to the
next reclaim -- and so we will keep on "unfairly" shrinking our own slab
in comparison to other slabs.

Link: http://lkml.kernel.org/r/20170822135325.9191-2-ch...@chris-wilson.co.uk
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Hillf Danton 
Cc: Minchan Kim 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Shaohua Li 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Joonsoo Kim 
Cc: Pekka Enberg 
Signed-off-by: Andrew Morton 
---

 drivers/gpu/drm/i915/i915_debugfs.c  |4 +--
 drivers/gpu/drm/i915/i915_drv.h  |1 
 drivers/gpu/drm/i915/i915_gem.c  |4 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c  |2 -
 drivers/gpu/drm/i915/i915_gem_shrinker.c |   24 +++--
 5 files changed, 24 insertions(+), 11 deletions(-)

diff -puN 
drivers/gpu/drm/i915/i915_debugfs.c~drm-i915-wire-up-shrinkctl-nr_scanned 
drivers/gpu/drm/i915/i915_debugfs.c
--- a/drivers/gpu/drm/i915/i915_debugfs.c~drm-i915-wire-up-shrinkctl-nr_scanned
+++ a/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4333,10 +4333,10 @@ i915_drop_caches_set(void *data, u64 val
 
lockdep_set_current_reclaim_state(GFP_KERNEL);
if (val & DROP_BOUND)
-   i915_gem_shrink(dev_priv, LONG_MAX, I915_SHRINK_BOUND);
+   i915_gem_shrink(dev_priv, LONG_MAX, NULL, I915_SHRINK_BOUND);
 
if (val & DROP_UNBOUND)
-   i915_gem_shrink(dev_priv, LONG_MAX, I915_SHRINK_UNBOUND);
+   i915_gem_shrink(dev_priv, LONG_MAX, NULL, I915_SHRINK_UNBOUND);
 
if (val & DROP_SHRINK_ALL)
i915_gem_shrink_all(dev_priv);
diff -puN drivers/gpu/drm/i915/i915_drv.h~drm-i915-wire-up-shrinkctl-nr_scanned 
drivers/gpu/drm/i915/i915_drv.h
--- a/drivers/gpu/drm/i915/i915_drv.h~drm-i915-wire-up-shrinkctl-nr_scanned
+++ a/drivers/gpu/drm/i915/i915_drv.h
@@ -3628,6 +3628,7 @@ i915_gem_object_create_internal(struct d
 /* i915_gem_shrinker.c */
 unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
  unsigned long target,
+ unsigned long *nr_scanned,
  unsigned flags);
 #define I915_SHRINK_PURGEABLE 0x1
 #define I915_SHRINK_UNBOUND 0x2
diff -puN drivers/gpu/drm/i915/i915_gem.c~drm-i915-wire-up-shrinkctl-nr_scanned 
drivers/gpu/drm/i915/i915_gem.c
--- a/drivers/gpu/drm/i915/i915_gem.c~drm-i915-wire-up-shrinkctl-nr_scanned
+++ a/drivers/gpu/drm/i915/i915_gem.c
@@ -2408,7 +2408,7 @@ rebuild_st:
goto err_sg;
}
 
-   i915_gem_shrink(dev_priv, 2 * page_count, *s++);
+   i915_gem_shrink(dev_priv, 2 * page_count, NULL, *s++);
cond_resched();
 
/* We've tried hard to allocate the memory by reaping
@@ -5012,7 +5012,7 @@ int i915_gem_freeze_late(struct drm_i915
 * the objects as well, see i915_gem_freeze()
 */
 
-   i915_gem_shrink(dev_priv, -1UL, I915_SHRINK_UNBOUND);
+   i915_gem_shrink(dev_priv, -1UL, NULL, I915_SHRINK_UNBOUND);
i915_gem_drain_freed_objects(dev_priv);
 
mutex_lock(_priv->drm.struct_mutex);
diff -puN 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaPushConstantDereferenceHoldDisable

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaPushConstantDereferenceHoldDisable
URL   : https://patchwork.freedesktop.org/series/29182/
State : success

== Summary ==

Series 29182v1 drm/i915/cnl: WaPushConstantDereferenceHoldDisable
https://patchwork.freedesktop.org/api/1.0/series/29182/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:448s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:436s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:363s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:551s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:253s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:521s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:521s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:439s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:616s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:444s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:425s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:426s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:509s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:505s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:594s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:603s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:467s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:483s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:492s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:445s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:484s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:413s
fi-byt-n2820 failed to connect after reboot

489147dfdcc735baf773a6ec3698cf85a01d7008 drm-tip: 2017y-08m-22d-18h-44m-32s UTC 
integration manifest
96f1cda1bb74 drm/i915/cnl: WaPushConstantDereferenceHoldDisable

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5469/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaPushConstantDereferenceHoldDisable

[Vivi, Rodrigo]

On Tue, 2017-08-22 at 15:15 -0700, Oscar Mateo wrote:
> Disable deref enhancement logic.

Could we add a bit more of info here?

like that fixes some CS hangs on 3D Push Constant dispatches?

with a bit more info feel free to add

Reviewed-by: Rodrigo Vivi 

I checked the spec and chicken reg. Also this Wa was on my todo list
here to try it out.

> 
> Cc: Rodrigo Vivi 
> Cc: Mika Kuoppala 
> Signed-off-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/i915_reg.h| 1 +
>  drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d4ecb19..d9b0249 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8055,6 +8055,7 @@ enum {
>  #define GEN7_ROW_CHICKEN2_MMIO(0xe4f4)
>  #define GEN7_ROW_CHICKEN2_GT2_MMIO(0xf4f4)
>  #define   DOP_CLOCK_GATING_DISABLE   (1<<0)
> +#define   PUSH_CONSTANT_DEREF_DISABLE(1<<8)
>  
>  #define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
>  #define  HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index d23f188..d7e1ccf 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1083,6 +1083,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
> *engine)
>   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
>  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
>  
> + /* WaPushConstantDereferenceHoldDisable:cnl */
> + WA_SET_BIT(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
> +
>   /* WaEnablePreemptionGranularityControlByUMD:cnl */
>   ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
>   if (ret)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cnl: WaPushConstantDereferenceHoldDisable

[Oscar Mateo]

Disable deref enhancement logic.

Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h| 1 +
 drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d4ecb19..d9b0249 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8055,6 +8055,7 @@ enum {
 #define GEN7_ROW_CHICKEN2  _MMIO(0xe4f4)
 #define GEN7_ROW_CHICKEN2_GT2  _MMIO(0xf4f4)
 #define   DOP_CLOCK_GATING_DISABLE (1<<0)
+#define   PUSH_CONSTANT_DEREF_DISABLE  (1<<8)
 
 #define HSW_ROW_CHICKEN3   _MMIO(0xe49c)
 #define  HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d23f188..d7e1ccf 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1083,6 +1083,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
 
+   /* WaPushConstantDereferenceHoldDisable:cnl */
+   WA_SET_BIT(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
+
/* WaEnablePreemptionGranularityControlByUMD:cnl */
ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
if (ret)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI] drm/i915: Keep a small stash of preallocated WC pages

[Chris Wilson]

Quoting Chris Wilson (2017-08-22 18:38:28)
> We use WC pages for coherent writes into the ppGTT on !llc
> architectures. However, to create a WC page requires a stop_machine(),
> i.e. is very slow. To compensate we currently keep a per-vm cache of
> recently freed pages, but we still see the slow startup of new contexts.
> We can amoritize that cost slightly by allocating WC pages in small
> batches (PAGEVEC_SIZE == 14) and since creating a WC page implies a
> stop_machine() there is no penalty for keeping that stash global.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Matthew Auld 

And pushed. I didn't split out the new dependency on struct_mutex to a
different mutex in the end, a task for later!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce private PAT management

[Patchwork]

== Series Details ==

Series: Introduce private PAT management
URL   : https://patchwork.freedesktop.org/series/29166/
State : success

== Summary ==

Series 29166v1 Introduce private PAT management
https://patchwork.freedesktop.org/api/1.0/series/29166/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:453s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:435s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:362s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:549s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:254s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:527s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:524s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:435s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:607s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:446s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:505s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:500s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:599s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:597s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:529s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:467s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:485s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:444s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:503s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

017fec5c2e57672a8c2a350376070e6c6a5ae950 drm-tip: 2017y-08m-22d-16h-23m-11s UTC 
integration manifest
0ca14817aed4 drm/i915: Introduce per-platform PPAT configurations
38930735de13 drm/i915: Introduce private PAT management
5fdbd0c4d588 drm/i915: Factor out setup_private_pat()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5468/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv2 2/3] drm/i915: Introduce private PAT management

[Wang, Zhi A]

How about I don't export "reserve" APIs in the next version? The "reserve" 
stuff is totally for init and keeping current logic unchanged. I'm scared of 
regression. :(

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Tuesday, August 22, 2017 9:08 PM
To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org; 
intel-gvt-...@lists.freedesktop.org
Cc: joonas.lahti...@linux.intel.com; zhen...@linux.intel.com; Wang, Zhi A 

Subject: Re: [RFCv2 2/3] drm/i915: Introduce private PAT management

Quoting Chris Wilson (2017-08-22 19:01:11)
> Quoting Zhi Wang (2017-08-23 02:44:12)
> > The private PAT management is to support both static and dynamic 
> > PPAT entry manipulation. During the initialization, the PPAT indexes 
> > with specific PPAT values could be reserved and set by intel_ppat_reserve.
> > The unused PPAT entries can be allocated/freed later at runtime. Two 
> > APIs are introduced for dynamically managing PPAT entries: 
> > intel_ppat_get and intel_ppat_set.
> 
> What's the use case for reserved? Once assigned, a new allocation 
> doesn't evict, so reservation is just another form of assignment.

Or rather, I can see the differentiation you want for init, but I can't see why 
you want to export it (since it ignores the ppat controller) or why you need to 
have a reserved bit, since you can just elevate the refcount.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cfl: Coffe Lake works on Kaby Lake PCH.

[Rodrigo Vivi]

On Mon, Aug 21, 2017 at 5:09 PM, Pandiyan, Dhinakaran
 wrote:
> On Mon, 2017-08-21 at 16:50 -0700, Rodrigo Vivi wrote:
>> Coffe Lake CPU on Kaby Lake PCH is possible.
>
> Typo ^

fixed when merging on dinq.

>
>> It does exist, and it does work.
>>
>> The only missed case was this warning here noticed
>> by Wendy who could get one system with this configuration
>> and reported the issue for us:
>>
>> Hardware Configuration
>> Board ID KBL S DDR4 UDIMM EV CRB
>> ProcessorIntel® Processor code named Coffee Lake S, (6+2), 6 cores 12 
>> threads, GT2, A0 (Internal) (QNJ4)
>>
>> [ 3.220585] WARNING: CPU: 10 PID: 206 at drivers/gpu/drm/i915/i915_drv.c:340 
>> i915_driver_load+0x1210/0x1660 [i915]
>> [ 3.221312] Modules linked in: hid_generic usbhid i915 i2c_algo_bit 
>> drm_kms_helper e1000e syscopyarea sysfillrect sysimgblt nvme fb_sys_fops ptp 
>> ahci i2c_hid drm pps_core nvme_core libahci wmi hid video
>> [ 3.222050] CPU: 10 PID: 206 Comm: systemd-udevd Not tainted 
>> 4.13.0-rc5-intel-next+ #1
>> [ 3.222706] Hardware name: Intel Corporation Kabylake Client platform/KBL S 
>> DDR4 UDIMM EV CRB, BIOS KBLSE2R1.R00.X089.P00.1705051000 05/05/2017
>>
>> Cc: Wendy Wang 
>> Cc: Dhinakaran Pandiyan 
>
> Reviewed-by: Dhinakaran Pandiyan 

thanks

>
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 43100229613c..f10a078e3a55 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -239,7 +239,8 @@ static void intel_detect_pch(struct drm_i915_private 
>> *dev_priv)
>>   dev_priv->pch_type = PCH_KBP;
>>   DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
>>   WARN_ON(!IS_SKYLAKE(dev_priv) &&
>> - !IS_KABYLAKE(dev_priv));
>> + !IS_KABYLAKE(dev_priv) &&
>> + !IS_COFFEELAKE(dev_priv));
>>   } else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
>>   dev_priv->pch_type = PCH_CNP;
>>   DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
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: Keep a small stash of preallocated WC pages (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Keep a small stash of preallocated WC pages (rev2)
URL   : https://patchwork.freedesktop.org/series/27622/
State : success

== Summary ==

Series 27622v2 drm/i915: Keep a small stash of preallocated WC pages
https://patchwork.freedesktop.org/api/1.0/series/27622/revisions/2/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-kbl-7260u) fdo#102295

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#102295 https://bugs.freedesktop.org/show_bug.cgi?id=102295

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:455s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:362s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:553s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:517s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:513s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:435s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:618s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:442s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:426s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:509s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7260u total:279  pass:267  dwarn:2   dfail:0   fail:0   skip:10  
time:502s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:598s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:602s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:527s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:468s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:481s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:482s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:449s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:492s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:558s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:403s
fi-bdw-gvtdvm failed to connect after reboot

017fec5c2e57672a8c2a350376070e6c6a5ae950 drm-tip: 2017y-08m-22d-16h-23m-11s UTC 
integration manifest
e4a2be8f7a5c drm/i915: Keep a small stash of preallocated WC pages

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5467/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv2 2/3] drm/i915: Introduce private PAT management

[Wang, Zhi A]

The "reserved" PPAT indexes is for keeping current i915 logics unchanged since 
I don't want to cause regression. I can remove "reserved" PPAT indexes actually.

-Original Message-
From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On 
Behalf Of Chris Wilson
Sent: Tuesday, August 22, 2017 9:01 PM
To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org; 
intel-gvt-...@lists.freedesktop.org
Cc: joonas.lahti...@linux.intel.com; Wang, Zhi A ; 
zhen...@linux.intel.com
Subject: Re: [RFCv2 2/3] drm/i915: Introduce private PAT management

Quoting Zhi Wang (2017-08-23 02:44:12)
> The private PAT management is to support both static and dynamic PPAT 
> entry manipulation. During the initialization, the PPAT indexes with 
> specific PPAT values could be reserved and set by intel_ppat_reserve.
> The unused PPAT entries can be allocated/freed later at runtime. Two 
> APIs are introduced for dynamically managing PPAT entries: 
> intel_ppat_get and intel_ppat_set.

What's the use case for reserved? Once assigned, a new allocation doesn't 
evict, so reservation is just another form of assignment.
-Chris
___
intel-gvt-dev mailing list
intel-gvt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

[Peter Zijlstra]

On Sat, Aug 12, 2017 at 02:15:13AM +, Rogozhkin, Dmitry V wrote:
> $ perf stat -e instructions,i915/rcs0-busy/ workload.sh
> <... wrokload.sh output...>
> 
> Performance counter stats for 'workload.sh':
>  1,204,616,268  instructions
>  0  i915/rcs0-busy/
> 
>1.869169153 seconds time elapsed
> 
> As you can see instructions event works pretty well, i915/rcs0-busy/
> doesn't.
> 
> I afraid that our current understanding of how PMU should work is not
> fully correct.

Can we start off by explaining to me how this i915 stuff works. Because
all I have is ~750 lines of patch without comments. Which sort of leaves
me confused.

The above command tries to add an event 'i915/rcs0-busy/' to a task. How
are i915 resource associated to any one particular task?

Is there a unique i915 resource for each task? If not, I don't see how
per-task event can ever work as expected.

> I think so, because the way PMU entry points init(),
> add(), del(), start(), stop(), read() are implemented do not correlate
> with how many times they are called. I have counted them and here is the
> result:
> init()=19, add()=44310, del()=43900, start()=44534, stop()=0, read()=0
> 
> Which means that we are regularly attempt to start/stop timer and/or
> busy stats calculations. Another thing which pay attention is that
> read() was not called at all. How perf supposes to get counter value?

Both stop() and del() are supposed to update event->count. Only if we do
sys_read() while the event is active (something perf-stat never does
IIRC) will it issue pmu::read() to get an up-to-date number.

> Yet another thing, where we are supposed to initialize our internal
> staff: numbers above are from single run and even init is called
> multiple times? Where we are supposed to de-init our staff: each time on
> del() - this hardly makes sense?

init happens in pmu::event_init(), that can set an optional
event->destroy() function for de-init.

init() is called once for each event created, the above creates an
inherited per-task event (I think, I lost track of what perf tool does)
and 19 seems to suggest you did some 18 fork()/clone() calls after that,
resulting in your 1 parent event with 18 children.

> I should note that if perf will be issued with -I 10 option, then read()
> is being called: init_c()=265, add_c()=132726, del_c()=131482,
> start_c()=133412, stop()=0, read()=71. However, i915 counter is still 0.
> I have tried to print counter values from within read() and these values
> are non 0. Actually read() returns sequence of , 0, 0, 0, ...,
>  because with our add(), del() code we regularly start/stop our
> counter and execution in read() follows different branches.
> 
> Thus, I think that right now we do not implement PMU correctly and do
> not meet perf expectations from the PMU. Unfortunately, right now I have
> no idea what are these expectations.

Please as to clarify how i915 works, I have no idea where to go.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] qf: Introduce subcommand and aliases

[Rodrigo Vivi]

Let's start refreshing qf a bit by introducing
subcommand and aliases like dim.

The goal is to have an standardized qf and dim
where both have same style, documentation and
also that is in a format that we can easily
introduce to make check.

Actually all new code here is a simple copy
from dim directly with s/dim/qf.

This patch also introduce qf_usage,
qf_list_commands qf_list_aliases and already
 move qf_help from the case parse $1 to a
subcommand.

v2: Keep default behaviour as git command executed on
quilt patches directory instead of qf_usage.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Signed-off-by: Rodrigo Vivi 
---
 Makefile |   5 +++
 qf   | 109 +--
 qf.rst   |  16 +-
 3 files changed, 99 insertions(+), 31 deletions(-)

diff --git a/Makefile b/Makefile
index adf26126e27c..7cb22d2b1e06 100644
--- a/Makefile
+++ b/Makefile
@@ -51,6 +51,11 @@ mancheck:
echo "$@: $$cmd not documented"; \
fi \
done
+   @for cmd in $$(./qf list-commands); do \
+   if ! grep -q "^$$cmd" qf.rst; then \
+   echo "$@: $$cmd not documented"; \
+   fi \
+   done
rst2man --strict --no-raw dim.rst >/dev/null
rst2man --strict --no-raw qf.rst >/dev/null
 
diff --git a/qf b/qf
index 1f056f90ef70..8e7d8c26e68f 100755
--- a/qf
+++ b/qf
@@ -169,28 +169,6 @@ function quilt_clean_check
fi
 }
 
-function qf_help
-{
-   manpage=$DIM_PREFIX/maintainer-tools/qf.rst
-   if [ ! -e "$manpage" ]; then
-   manpage=$(dirname $(readlink -f $0))/qf.rst
-   if [ ! -e "$manpage" ]; then
-   echo "Can't find the man page."
-   exit 1
-   fi
-   fi
-
-   if hash rst2man 2>/dev/null; then
-   renderer=rst2man
-   pager="man -l -"
-   else
-   renderer=cat
-   pager=${PAGER:-cat}
-   fi
-
-   $renderer < $manpage | $pager
-}
-
 case "$1" in
setup)
cd `git rev-parse --show-toplevel`
@@ -480,12 +458,83 @@ case "$1" in
shift
gitk "$@"
;;
-   help)
-   qf_help
-   ;;
-   *)
-   cd_toplevel
-   cd patches
-   git "$@"
-   ;;
 esac
+
+qf=$(basename $0)
+
+# first positional argument is the subcommand
+if [ -n "$HELP" ] || [ "$#" = "0" ]; then
+subcommand="usage"
+else
+subcommand="$1"
+shift
+fi
+
+function qf_help
+{
+   manpage=$DIM_PREFIX/maintainer-tools/qf.rst
+   if [ ! -e "$manpage" ]; then
+   manpage=$(dirname $(readlink -f $0))/qf.rst
+   if [ ! -e "$manpage" ]; then
+   echo "Can't find the man page."
+   exit 1
+   fi
+   fi
+
+   if hash rst2man 2>/dev/null; then
+   renderer=rst2man
+   pager="man -l -"
+   else
+   renderer=cat
+   pager=${PAGER:-cat}
+   fi
+
+   $renderer < $manpage | $pager
+}
+
+function qf_list_commands
+{
+   declare -F | grep -o " qf_[a-zA-Z_]*" | sed 's/^ qf_//;s/_/-/g'
+}
+
+function qf_list_aliases
+{
+   # use posix mode to omit functions in set output
+   ( set -o posix; set ) | grep "^qf_alias_[a-zA-Z0-9_]*=" |\
+   sed 's/^qf_alias_//;s/=/\t/;s/_/-/g'
+}
+
+function qf_usage
+{
+   echo "usage: $qf SUBCOMMAND [ARGUMENTS]"
+   echo
+   echo "The available subcommands are:"
+   if hash column 2>/dev/null; then
+   qf_list_commands | column -c 72 | sed 's/^/\t/'
+   else
+   qf_list_commands | sed 's/^/\t/'
+   fi
+   echo
+   echo "See '$qf help' for more information."
+}
+
+# qf subcommand aliases (with bash 4.3+)
+if ! declare -n subcmd=qf_alias_${subcommand//-/_} &> /dev/null || \
+   test -z "${subcmd:-}"; then
+   subcmd="$subcommand"
+fi
+
+# look up the function by the subcommand name
+subcmd_func=qf_${subcmd//-/_}
+if ! declare -f $subcmd_func >/dev/null; then
+   echo "Using qf as git command on quilt patches directory."
+   cd_toplevel
+   cd patches
+   git "$@"
+   exit $?
+fi
+
+# throw away to not confuse list-aliases
+unset subcmd
+
+$subcmd_func "$@"
diff --git a/qf.rst b/qf.rst
index 902b0d377f41..10447dded391 100644
--- a/qf.rst
+++ b/qf.rst
@@ -95,6 +95,16 @@ $ qf git bisect new|old
 COMMANDS
 
 
+list-aliases
+
+List all aliases for the subcommand names.
+
+See \$qf_alias_ under ENVIRONMENT below on how to define aliases.
+
+list-commands
+-
+List all subcommand names, including aliases.
+
 setup [*branch-name*]
 -
 Sets up a git repository for this quilt 

Re: [Intel-gfx] [maintainer-tools PATCH 30/30] qf: Use .dimrc to config and extend qf.

[Rodrigo Vivi]

On Tue, Aug 22, 2017 at 12:33 AM, Jani Nikula  wrote:
> On Mon, 21 Aug 2017, Rodrigo Vivi  wrote:
>> Soon we will need to extend qf for very specific
>> usages of our internal maintenance and rebase bot.
>>
>> So instead of creating yet another config file
>> let's use the existent one.
>
> I think I'd prefer a separate config file for qf.

hm.. I was here accepting this suggestion, but then I noticed our qf_help
already referrence $DIM_PREFIX

so, if we change to .qfrc we will have to redefine this prefix while re-using
dimrc we don't need any duplication.

what do you think?

>
> BR,
> Jani.
>
>>
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Joonas Lahtinen 
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  dimrc.sample |  9 -
>>  qf   | 18 +++---
>>  2 files changed, 23 insertions(+), 4 deletions(-)
>>
>> diff --git a/dimrc.sample b/dimrc.sample
>> index be7b99cb6b76..bbddecabd519 100644
>> --- a/dimrc.sample
>> +++ b/dimrc.sample
>> @@ -1,4 +1,4 @@
>> -# Sample configuration file for dim. Place this at $HOME/.dimrc or point
>> +# Sample configuration file for dim and qf. Place this at $HOME/.dimrc or 
>> point
>>  # DIM_CONFIG environment variable to it.
>>  #
>>  # Defaults are in the comments below.
>> @@ -20,3 +20,10 @@
>>
>>  # Command to run after dim apply
>>  #DIM_POST_APPLY_ACTION=
>> +
>> +#
>> +# qf
>> +#
>> +
>> +# Quilt branch prefix
>> +#QUILT_PREFIX=
>> \ No newline at end of file
>> diff --git a/qf b/qf
>> index be234e72fa15..befdb2c15b5f 100755
>> --- a/qf
>> +++ b/qf
>> @@ -26,12 +26,24 @@
>>
>>  # quilt git flow script
>>
>> -# config
>> -QUILT_PREFIX=quilt/
>> -
>>  # fail on any goof-up
>>  set -e
>>
>> +#
>> +# User configuration. Set in environment or configuration file. See
>> +# dimrc.sample for an example.
>> +#
>> +
>> +# dim configuration file
>> +DIM_CONFIG=${DIM_CONFIG:-$HOME/.dimrc}
>> +if [ -r $DIM_CONFIG ]; then
>> + # shellcheck source=/dev/null
>> + . $DIM_CONFIG
>> +fi
>> +
>> +# prefix for quilt branch
>> +QUILT_PREFIX=${QUILT_PREFIX:-quilt/}
>> +
>>  function cd_toplevel
>>  {
>>   cd $(git rev-parse --show-toplevel)
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/lrc: Clarify the format of the context image

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915/lrc: Clarify the format of the 
context image
URL   : https://patchwork.freedesktop.org/series/29163/
State : success

== Summary ==

Series 29163v1 series starting with [1/6] drm/i915/lrc: Clarify the format of 
the context image
https://patchwork.freedesktop.org/api/1.0/series/29163/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:456s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:439s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:364s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:556s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:256s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:529s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:523s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:435s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:614s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:446s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:427s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:422s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:514s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:502s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:600s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:600s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:469s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:479s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:551s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:408s
fi-pnv-d510 failed to connect after reboot

017fec5c2e57672a8c2a350376070e6c6a5ae950 drm-tip: 2017y-08m-22d-16h-23m-11s UTC 
integration manifest
f51f64c1744e drm/i915/execlists: Read the context-status HEAD from the HWSP
2cf7f3d89365 drm/i915/execlists: Read the context-status buffer from the HWSP
2a36b5b91fc8 drm/i915: Allow HW status page to be bound high
7bb86df30d7e drm/i915/lrc: allocate separate page for HWSP
b56d158bde57 drm/i915/guc: Don't make assumptions while getting the lrca offset
908dcc1d71ba drm/i915/lrc: Clarify the format of the context image

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5465/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv2 2/3] drm/i915: Introduce private PAT management

[Chris Wilson]

Quoting Chris Wilson (2017-08-22 19:01:11)
> Quoting Zhi Wang (2017-08-23 02:44:12)
> > The private PAT management is to support both static and dynamic PPAT
> > entry manipulation. During the initialization, the PPAT indexes with
> > specific PPAT values could be reserved and set by intel_ppat_reserve.
> > The unused PPAT entries can be allocated/freed later at runtime. Two
> > APIs are introduced for dynamically managing PPAT entries: intel_ppat_get
> > and intel_ppat_set.
> 
> What's the use case for reserved? Once assigned, a new allocation
> doesn't evict, so reservation is just another form of assignment.

Or rather, I can see the differentiation you want for init, but I can't
see why you want to export it (since it ignores the ppat controller) or
why you need to have a reserved bit, since you can just elevate the
refcount.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv2 2/3] drm/i915: Introduce private PAT management

[Chris Wilson]

Quoting Zhi Wang (2017-08-23 02:44:12)
> The private PAT management is to support both static and dynamic PPAT
> entry manipulation. During the initialization, the PPAT indexes with
> specific PPAT values could be reserved and set by intel_ppat_reserve.
> The unused PPAT entries can be allocated/freed later at runtime. Two
> APIs are introduced for dynamically managing PPAT entries: intel_ppat_get
> and intel_ppat_set.

What's the use case for reserved? Once assigned, a new allocation
doesn't evict, so reservation is just another form of assignment.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 01/30] qf: Deprecate the use of qf without any subcommand.

[Rodrigo Vivi]

On Tue, Aug 22, 2017 at 12:36 AM, Daniel Vetter  wrote:
> On Tue, Aug 22, 2017 at 08:55:33AM +0200, Daniel Vetter wrote:
>> On Mon, Aug 21, 2017 at 01:10:51PM -0700, Rodrigo Vivi wrote:
>> > These sequences here are already covered by `qf git` subcommand.
>> > I double checked and confirmed that our continuously rebasing
>> > bot does not use this qf directly here and I'm not aware
>> > of anyone else using it. So let's remove it so we can start
>> > handling everything with subcommands (dim style).
>>
>> I do. It's super handy if you look around at the source code, but want to
>> manipulate the qf history. This is similar to how git tools by default
>> work anywhere in the working tree. It's not perfect (e.g. qf git blame
>> doesn't do what you want it to do), but in many cases just adding a qf to
>> whatever git command you though of Just Works (e.g. qf log).
>>
>> If it annoys you too much I guess we could do qf run for cmds in general
>> and qf git for git stuff, but would be really nice to keep this in some
>> form.

it doesn't annoy me...
I just considered it to be more in sync with dim, but if we have users
for that I don't want to break it ;)

>
> Otoh my opinion doesn't matter all that much anymore, so if others think

of course it matters!

> it's ok I can live with qf git log :-)

well, if was/is just the log I believe we could do an alias on .qfrc..

But I imagine qfrc can increase a lot and get messy if we start adding
all git subcommands to our .qfrc

>
> Ack on the series, but I haven't really checked all the details, I think
> Jani's the better person for that.

Thanks!

But I will still do few changes like keep this default behaviour and
use .qfrc instead of .dimrc as Jani prefers.

Later I will play with bash_completion for qf as well... Thanks for
the suggestion.

Thanks,
Rodrigo.

> -Daniel
>
>> -Daniel
>>
>> >
>> > Cc: Paulo Zanoni 
>> > Cc: Imre Deak 
>> > Cc: Joonas Lahtinen 
>> > Cc: Jani Nikula 
>> > Cc: Daniel Vetter 
>> > Signed-off-by: Rodrigo Vivi 
>> > ---
>> >  qf | 7 +--
>> >  qf.rst | 7 ---
>> >  2 files changed, 1 insertion(+), 13 deletions(-)
>> >
>> > diff --git a/qf b/qf
>> > index 1f056f90ef70..d1c331023230 100755
>> > --- a/qf
>> > +++ b/qf
>> > @@ -480,12 +480,7 @@ case "$1" in
>> > shift
>> > gitk "$@"
>> > ;;
>> > -   help)
>> > -   qf_help
>> > -   ;;
>> > *)
>> > -   cd_toplevel
>> > -   cd patches
>> > -   git "$@"
>> > +   qf_help
>> > ;;
>> >  esac
>> > diff --git a/qf.rst b/qf.rst
>> > index 902b0d377f41..f0019d76c53d 100644
>> > --- a/qf.rst
>> > +++ b/qf.rst
>> > @@ -233,13 +233,6 @@ help
>> >  
>> >  This help text here
>> >
>> > -all other subcommands - IMPORTANT
>> > --
>> > -Any other subcommands are executed directly in the quilt patches
>> > -directory as git commans. When using quilt flow in scripts it is
>> > -import to use the explicit forwarding to avoid clashes with
>> > -furture extensions.
>> > -
>> >  CONTRIBUTING
>> >  
>> >
>> > --
>> > 2.13.2
>> >
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFCv2 RESEND 2/3] drm/i915: Introduce private PAT management

[Zhi Wang]

The private PAT management is to support both static and dynamic PPAT
entry manipulation. During the initialization, the PPAT indexes with
specific PPAT values could be reserved and set by intel_ppat_reserve.
The unused PPAT entries can be allocated/freed later at runtime. Two
APIs are introduced for dynamically managing PPAT entries: intel_ppat_get
and intel_ppat_set.

intel_ppat_get will search for an existing PPAT entry which perfectly
matches the required PPAT value. If not, it will try to allocate or
return a partially matched PPAT entry if there is any available PPAT
indexes or not.

intel_ppat_put will put back the PPAT entry which comes from
intel_ppat_get. If it's dynamically allocated, the reference count will
be decreased. If the reference count turns into zero, the PPAT index is
freed again.

Besides, another two callbacks are introduced to support the private PAT
management framework. One is ppat->update(), which writes the PPAT
configurations in ppat->entries into HW. Another one is ppat->match, which
will return a score to show how two PPAT values match with each other.

Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |   2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 129 
 drivers/gpu/drm/i915/i915_gem_gtt.h |  36 ++
 3 files changed, 167 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60267e3..97b46f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2307,6 +2307,8 @@ struct drm_i915_private {
DECLARE_HASHTABLE(mm_structs, 7);
struct mutex mm_lock;
 
+   struct intel_ppat ppat;
+
/* Kernel Modesetting */
 
struct intel_crtc *plane_to_crtc_mapping[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 09d1d48..2a521b6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2742,6 +2742,121 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, 
u64 size)
return 0;
 }
 
+/**
+ * intel_ppat_reserve - reserve a PPAT index and set the PPAT value
+ * @ppat: i915 PPAT instance
+ * @index: the PPAT index needs to be reserved
+ * @value: the PPAT value needs to be set
+ *
+ * A PPAT entry sits on the reserved PPAT index will not be modified by PPAT
+ * management.
+ */
+void intel_ppat_reserve(struct intel_ppat *ppat, unsigned int index, u8 value)
+{
+   GEM_BUG_ON(index >= ppat->max_entries);
+   GEM_BUG_ON(test_bit(index, ppat->reserved));
+
+   ppat->entries[index].value = value;
+   set_bit(index, ppat->reserved);
+   set_bit(index, ppat->used);
+}
+
+/**
+ * intel_ppat_get - dynamically get a usable PPAT entry
+ * @dev_priv: i915 device instance
+ * @value: the PPAT value required by the caller
+ *
+ * The function tries to search if there is an existing PPAT entry which
+ * matches with the required value. If perfectly matched, the existing PPAT
+ * entry will be used. If only partially matched, it will try to check if
+ * there is any available PPAT index. If yes, it will allocate a new PPAT
+ * index for the required entry and update the HW. If not, the partially
+ * matched entry will be used.
+ */
+struct intel_ppat_entry *intel_ppat_get(struct drm_i915_private *dev_priv,
+   u8 value)
+{
+   struct intel_ppat *ppat = _priv->ppat;
+   struct intel_ppat_entry *entry;
+   int i, used;
+   unsigned int score, best_score;
+
+   score = best_score = 0;
+   used = 0;
+
+   /* First, find a suitable value from available entries */
+   for_each_set_bit(i, ppat->used, ppat->max_entries) {
+   score = ppat->match(ppat->entries[i].value, value);
+   /* Perfect match */
+   if (score == ~0) {
+   entry = >entries[i];
+   kref_get(>ref_count);
+   return entry;
+   }
+
+   if (score > best_score) {
+   entry = >entries[i];
+   best_score = score;
+   }
+   used++;
+   }
+
+   /* No matched entry and we can't allocate a new entry. */
+   if (!best_score && used == ppat->max_entries) {
+   DRM_ERROR("Fail to get PPAT entry\n");
+   return ERR_PTR(-ENOSPC);
+   }
+
+   /*
+* Found a matched entry which is not perfect,
+* and we can't allocate a new entry.
+*/
+   if (best_score && used == ppat->max_entries) {
+   kref_get(>ref_count);
+   return entry;
+   }
+
+   /* Allocate a new entry */
+   i = find_first_zero_bit(ppat->used, ppat->max_entries);
+   set_bit(i, ppat->used);
+
+   entry = >entries[i];
+   entry->value = value;
+   kref_init(>ref_count);
+
+   ppat->update(dev_priv);
+   return entry;

[Intel-gfx] [RFCv2 0/3] Introduce private PAT management

[Zhi Wang]

This patchset introduces private PPAT managment which enables dynamically
configuring PPAT at runtime. The previous static PPAT configuration is
kept unchanged.

More background of this patchset can be found at:
https://lists.freedesktop.org/archives/intel-gfx/2017-August/135415.html

v2:
- Rewrite the i915 parts after discussing with Chris. Now PPAT management
sits in i915.

Zhi Wang (3):
  drm/i915: Factor out setup_private_pat()
  drm/i915: Introduce private PAT management
  drm/i915: Introduce per-platform PPAT configurations

 drivers/gpu/drm/i915/i915_drv.h |   2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 288 +---
 drivers/gpu/drm/i915/i915_gem_gtt.h |  36 +
 3 files changed, 272 insertions(+), 54 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFCv3 3/3] drm/i915: Introduce per-platform PPAT configurations

[Zhi Wang]

The previous static PPAT configuration for each platform is kept unchanged
and now configured through intel_ppat_reserve(). Also the PPAT feature of
each platform is described in intel PPAT instance during the initialization
and related callbacks which supports the PPAT management framework will be
hooked.

Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 145 
 1 file changed, 96 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2a521b6..d103ea4 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2857,41 +2857,92 @@ void intel_ppat_put(struct intel_ppat_entry *entry)
kref_put(>ref_count, put_ppat);
 }
 
-static void cnl_setup_private_ppat(struct drm_i915_private *dev_priv)
+static void cnl_private_pat_update(struct drm_i915_private *dev_priv)
 {
+   struct intel_ppat *ppat = _priv->ppat;
+   int i;
+
+   for (i = 0; i < ppat->max_entries; i++)
+   I915_WRITE(GEN10_PAT_INDEX(i), ppat->entries[i].value);
+}
+
+static void bdw_private_pat_update(struct drm_i915_private *dev_priv)
+{
+   struct intel_ppat *ppat = _priv->ppat;
+   u64 pat = 0;
+   int i;
+
+   for (i = 0; i < ppat->max_entries; i++)
+   pat |= GEN8_PPAT(i, ppat->entries[i].value);
+
+   I915_WRITE(GEN8_PRIVATE_PAT_LO, pat);
+   I915_WRITE(GEN8_PRIVATE_PAT_HI, pat >> 32);
+}
+
+#define gen8_pat_ca(v) ((v) & 0x3)
+#define gen8_pat_tc(v) (((v) >> 2) & 0x3)
+#define gen8_pat_age(v) (((v) >> 4) & 0x3)
+
+static unsigned int bdw_private_pat_match(u8 src, u8 dst)
+{
+   unsigned int score = 0;
+
+   /* Cache attribute has to be matched. */
+   if (gen8_pat_ca(src) != gen8_pat_ca(dst))
+   return 0;
+
+   if (gen8_pat_age(src) == gen8_pat_age(dst))
+   score += 1;
+
+   if (gen8_pat_tc(src) == gen8_pat_tc(dst))
+   score += 2;
+
+   if (score == 3)
+   return ~0;
+
+   return score;
+}
+
+#define chv_get_snoop(v) (((v) >> 6) & 0x1)
+
+static unsigned int chv_private_pat_match(u8 src, u8 dst)
+{
+   if (chv_get_snoop(src) == chv_get_snoop(dst))
+   return ~0;
+
+   return 0;
+}
+
+static void cnl_setup_private_ppat(struct intel_ppat *ppat)
+{
+   ppat->max_entries = 8;
+   ppat->update = cnl_private_pat_update;
+   ppat->match = bdw_private_pat_match;
+   ppat->dummy_value = GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3);
+
/* XXX: spec is unclear if this is still needed for CNL+ */
if (!USES_PPGTT(dev_priv)) {
-   I915_WRITE(GEN10_PAT_INDEX(0), GEN8_PPAT_UC);
+   intel_ppat_reserve(ppat, 0, GEN8_PPAT_UC);
return;
}
 
-   I915_WRITE(GEN10_PAT_INDEX(0), GEN8_PPAT_WB | GEN8_PPAT_LLC);
-   I915_WRITE(GEN10_PAT_INDEX(1), GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
-   I915_WRITE(GEN10_PAT_INDEX(2), GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
-   I915_WRITE(GEN10_PAT_INDEX(3), GEN8_PPAT_UC);
-   I915_WRITE(GEN10_PAT_INDEX(4), GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
-   I915_WRITE(GEN10_PAT_INDEX(5), GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
-   I915_WRITE(GEN10_PAT_INDEX(6), GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2));
-   I915_WRITE(GEN10_PAT_INDEX(7), GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3));
+   intel_ppat_reserve(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);
+   intel_ppat_reserve(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
+   intel_ppat_reserve(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
+   intel_ppat_reserve(ppat, 3, GEN8_PPAT_UC);
 }
 
 /* The GGTT and PPGTT need a private PPAT setup in order to handle cacheability
  * bits. When using advanced contexts each context stores its own PAT, but
  * writing this data shouldn't be harmful even in those cases. */
-static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv)
+static void bdw_setup_private_ppat(struct intel_ppat *ppat)
 {
-   u64 pat;
+   ppat->max_entries = 8;
+   ppat->update = bdw_private_pat_update;
+   ppat->match = bdw_private_pat_match;
+   ppat->dummy_value = GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3);
 
-   pat = GEN8_PPAT(0, GEN8_PPAT_WB | GEN8_PPAT_LLC) | /* for normal 
objects, no eLLC */
- GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) | /* for something 
pointing to ptes? */
- GEN8_PPAT(2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC) | /* for scanout 
with eLLC */
- GEN8_PPAT(3, GEN8_PPAT_UC) | /* Uncached 
objects, mostly for scanout */
- GEN8_PPAT(4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0)) 
|
- GEN8_PPAT(5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1)) 
|
- GEN8_PPAT(6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2)) 
|
- GEN8_PPAT(7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3));
-
-   

[Intel-gfx] [RFCv2 1/3] drm/i915: Factor out setup_private_pat()

[Zhi Wang]

Factor out setup_private_pat() for introducing the following patches.

Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0f73998..09d1d48 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2841,6 +2841,16 @@ static void gen6_gmch_remove(struct i915_address_space 
*vm)
cleanup_scratch_page(vm);
 }
 
+static void setup_private_pat(struct drm_i915_private *dev_priv)
+{
+   if (INTEL_GEN(dev_priv) >= 10)
+   cnl_setup_private_ppat(dev_priv);
+   else if (IS_CHERRYVIEW(dev_priv) || IS_GEN9_LP(dev_priv))
+   chv_setup_private_ppat(dev_priv);
+   else
+   bdw_setup_private_ppat(dev_priv);
+}
+
 static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 {
struct drm_i915_private *dev_priv = ggtt->base.i915;
@@ -2873,14 +2883,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
}
 
ggtt->base.total = (size / sizeof(gen8_pte_t)) << PAGE_SHIFT;
-
-   if (INTEL_GEN(dev_priv) >= 10)
-   cnl_setup_private_ppat(dev_priv);
-   else if (IS_CHERRYVIEW(dev_priv) || IS_GEN9_LP(dev_priv))
-   chv_setup_private_ppat(dev_priv);
-   else
-   bdw_setup_private_ppat(dev_priv);
-
ggtt->base.cleanup = gen6_gmch_remove;
ggtt->base.bind_vma = ggtt_bind_vma;
ggtt->base.unbind_vma = ggtt_unbind_vma;
@@ -2901,6 +2903,8 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 
ggtt->invalidate = gen6_ggtt_invalidate;
 
+   setup_private_pat(dev_priv);
+
return ggtt_probe_common(ggtt, size);
 }
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFCv2 2/3] drm/i915: Introduce private PAT management

[Zhi Wang]

The private PAT management is to support both static and dynamic PPAT
entry manipulation. During the initialization, the PPAT indexes with
specific PPAT values could be reserved and set by intel_ppat_reserve.
The unused PPAT entries can be allocated/freed later at runtime. Two
APIs are introduced for dynamically managing PPAT entries: intel_ppat_get
and intel_ppat_set.

intel_ppat_get will search for an existing PPAT entry which perfectly
matches the required PPAT value. If not, it will try to allocate or
return a partially matched PPAT entry if there is any available PPAT
indexes or not.

intel_ppat_put will put back the PPAT entry which comes from
intel_ppat_get. If it's dynamically allocated, the reference count will
be decreased. If the reference count turns into zero, the PPAT index is
freed again.

Besides, another two callbacks are introduced to support the private PAT
management framework. One is ppat->update(), which writes the PPAT
configurations in ppat->entries into HW. Another one is ppat->match, which
will return a score to show how two PPAT values match with each other.

Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |   2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 129 
 drivers/gpu/drm/i915/i915_gem_gtt.h |  36 ++
 3 files changed, 167 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60267e3..97b46f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2307,6 +2307,8 @@ struct drm_i915_private {
DECLARE_HASHTABLE(mm_structs, 7);
struct mutex mm_lock;
 
+   struct intel_ppat ppat;
+
/* Kernel Modesetting */
 
struct intel_crtc *plane_to_crtc_mapping[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 09d1d48..2a521b6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2742,6 +2742,121 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, 
u64 size)
return 0;
 }
 
+/**
+ * intel_ppat_reserve - reserve a PPAT index and set the PPAT value
+ * @ppat: i915 PPAT instance
+ * @index: the PPAT index needs to be reserved
+ * @value: the PPAT value needs to be set
+ *
+ * A PPAT entry sits on the reserved PPAT index will not be modified by PPAT
+ * management.
+ */
+void intel_ppat_reserve(struct intel_ppat *ppat, unsigned int index, u8 value)
+{
+   GEM_BUG_ON(index >= ppat->max_entries);
+   GEM_BUG_ON(test_bit(index, ppat->reserved));
+
+   ppat->entries[index].value = value;
+   set_bit(index, ppat->reserved);
+   set_bit(index, ppat->used);
+}
+
+/**
+ * intel_ppat_get - dynamically get a usable PPAT entry
+ * @dev_priv: i915 device instance
+ * @value: the PPAT value required by the caller
+ *
+ * The function tries to search if there is an existing PPAT entry which
+ * matches with the required value. If perfectly matched, the existing PPAT
+ * entry will be used. If only partially matched, it will try to check if
+ * there is any available PPAT index. If yes, it will allocate a new PPAT
+ * index for the required entry and update the HW. If not, the partially
+ * matched entry will be used.
+ */
+struct intel_ppat_entry *intel_ppat_get(struct drm_i915_private *dev_priv,
+   u8 value)
+{
+   struct intel_ppat *ppat = _priv->ppat;
+   struct intel_ppat_entry *entry;
+   int i, used;
+   unsigned int score, best_score;
+
+   score = best_score = 0;
+   used = 0;
+
+   /* First, find a suitable value from available entries */
+   for_each_clear_bit(i, ppat->used, ppat->max_entries) {
+   score = ppat->match(ppat->entries[i].value, value);
+   /* Perfect match */
+   if (score == ~0) {
+   entry = >entries[i];
+   kref_get(>ref_count);
+   return entry;
+   }
+
+   if (score > best_score) {
+   entry = >entries[i];
+   best_score = score;
+   }
+   used++;
+   }
+
+   /* No matched entry and we can't allocate a new entry. */
+   if (!best_score && used == ppat->max_entries) {
+   DRM_ERROR("Fail to get PPAT entry\n");
+   return ERR_PTR(-ENOSPC);
+   }
+
+   /*
+* Found a matched entry which is not perfect,
+* and we can't allocate a new entry.
+*/
+   if (best_score && used == ppat->max_entries) {
+   kref_get(>ref_count);
+   return entry;
+   }
+
+   /* Allocate a new entry */
+   i = find_first_zero_bit(ppat->used, ppat->max_entries);
+   set_bit(i, ppat->used);
+
+   entry = >entries[i];
+   entry->value = value;
+   kref_init(>ref_count);
+
+   ppat->update(dev_priv);
+   return entry;

[Intel-gfx] [CI 2/2] drm/i915: Keep a small stash of preallocated WC pages

[Chris Wilson]

We use WC pages for coherent writes into the ppGTT on !llc
architectures. However, to create a WC page requires a stop_machine(),
i.e. is very slow. To compensate we currently keep a per-vm cache of
recently freed pages, but we still see the slow startup of new contexts.
We can amoritize that cost slightly by allocating WC pages in small
batches (PAGEVEC_SIZE == 14) and since creating a WC page implies a
stop_machine() there is no penalty for keeping that stash global.

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h |   5 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c | 122 +---
 2 files changed, 103 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60267e375e88..7587ef53026b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1465,6 +1465,11 @@ struct i915_gem_mm {
struct llist_head free_list;
struct work_struct free_work;
 
+   /**
+* Small stash of WC pages
+*/
+   struct pagevec wc_stash;
+
/** Usable portion of the GTT for GEM */
dma_addr_t stolen_base; /* limited to low memory (32-bit) */
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0f7399801398..708b95cd8c30 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -356,39 +356,86 @@ static gen6_pte_t iris_pte_encode(dma_addr_t addr,
 
 static struct page *vm_alloc_page(struct i915_address_space *vm, gfp_t gfp)
 {
-   struct page *page;
+   struct pagevec *pvec = >free_pages;
 
if (I915_SELFTEST_ONLY(should_fail(>fault_attr, 1)))
i915_gem_shrink_all(vm->i915);
 
-   if (vm->free_pages.nr)
-   return vm->free_pages.pages[--vm->free_pages.nr];
+   if (likely(pvec->nr))
+   return pvec->pages[--pvec->nr];
+
+   if (!vm->pt_kmap_wc)
+   return alloc_page(gfp);
+
+   /* A placeholder for a specific mutex to guard the WC stash */
+   lockdep_assert_held(>i915->drm.struct_mutex);
+
+   /* Look in our global stash of WC pages... */
+   pvec = >i915->mm.wc_stash;
+   if (likely(pvec->nr))
+   return pvec->pages[--pvec->nr];
 
-   page = alloc_page(gfp);
-   if (!page)
+   /* Otherwise batch allocate pages to amoritize cost of set_pages_wc. */
+   do {
+   struct page *page;
+
+   page = alloc_page(gfp);
+   if (unlikely(!page))
+   break;
+
+   pvec->pages[pvec->nr++] = page;
+   } while (pagevec_space(pvec));
+
+   if (unlikely(!pvec->nr))
return NULL;
 
-   if (vm->pt_kmap_wc)
-   set_pages_array_wc(, 1);
+   set_pages_array_wc(pvec->pages, pvec->nr);
 
-   return page;
+   return pvec->pages[--pvec->nr];
 }
 
-static void vm_free_pages_release(struct i915_address_space *vm)
+static void vm_free_pages_release(struct i915_address_space *vm,
+ bool immediate)
 {
-   GEM_BUG_ON(!pagevec_count(>free_pages));
+   struct pagevec *pvec = >free_pages;
+
+   GEM_BUG_ON(!pagevec_count(pvec));
+
+   if (vm->pt_kmap_wc) {
+   struct pagevec *stash = >i915->mm.wc_stash;
 
-   if (vm->pt_kmap_wc)
-   set_pages_array_wb(vm->free_pages.pages,
-  pagevec_count(>free_pages));
+   /* When we use WC, first fill up the global stash and then
+* only if full immediately free the overflow.
+*/
+
+   lockdep_assert_held(>i915->drm.struct_mutex);
+   if (pagevec_space(stash)) {
+   do {
+   stash->pages[stash->nr++] =
+   pvec->pages[--pvec->nr];
+   if (!pvec->nr)
+   return;
+   } while (pagevec_space(stash));
+
+   /* As we have made some room in the VM's free_pages,
+* we can wait for it to fill again. Unless we are
+* inside i915_address_space_fini() and must
+* immediately release the pages!
+*/
+   if (!immediate)
+   return;
+   }
+
+   set_pages_array_wb(pvec->pages, pvec->nr);
+   }
 
-   __pagevec_release(>free_pages);
+   __pagevec_release(pvec);
 }
 
 static void vm_free_page(struct i915_address_space *vm, struct page *page)
 {
if (!pagevec_add(>free_pages, page))
-   vm_free_pages_release(vm);
+   vm_free_pages_release(vm, false);
 }
 
 static int __setup_page_dma(struct i915_address_space *vm,

[Intel-gfx] [CI] drm/i915: Keep a small stash of preallocated WC pages

[Chris Wilson]

We use WC pages for coherent writes into the ppGTT on !llc
architectures. However, to create a WC page requires a stop_machine(),
i.e. is very slow. To compensate we currently keep a per-vm cache of
recently freed pages, but we still see the slow startup of new contexts.
We can amoritize that cost slightly by allocating WC pages in small
batches (PAGEVEC_SIZE == 14) and since creating a WC page implies a
stop_machine() there is no penalty for keeping that stash global.

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h |   5 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c | 122 +---
 2 files changed, 103 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60267e375e88..7587ef53026b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1465,6 +1465,11 @@ struct i915_gem_mm {
struct llist_head free_list;
struct work_struct free_work;
 
+   /**
+* Small stash of WC pages
+*/
+   struct pagevec wc_stash;
+
/** Usable portion of the GTT for GEM */
dma_addr_t stolen_base; /* limited to low memory (32-bit) */
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0f7399801398..708b95cd8c30 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -356,39 +356,86 @@ static gen6_pte_t iris_pte_encode(dma_addr_t addr,
 
 static struct page *vm_alloc_page(struct i915_address_space *vm, gfp_t gfp)
 {
-   struct page *page;
+   struct pagevec *pvec = >free_pages;
 
if (I915_SELFTEST_ONLY(should_fail(>fault_attr, 1)))
i915_gem_shrink_all(vm->i915);
 
-   if (vm->free_pages.nr)
-   return vm->free_pages.pages[--vm->free_pages.nr];
+   if (likely(pvec->nr))
+   return pvec->pages[--pvec->nr];
+
+   if (!vm->pt_kmap_wc)
+   return alloc_page(gfp);
+
+   /* A placeholder for a specific mutex to guard the WC stash */
+   lockdep_assert_held(>i915->drm.struct_mutex);
+
+   /* Look in our global stash of WC pages... */
+   pvec = >i915->mm.wc_stash;
+   if (likely(pvec->nr))
+   return pvec->pages[--pvec->nr];
 
-   page = alloc_page(gfp);
-   if (!page)
+   /* Otherwise batch allocate pages to amoritize cost of set_pages_wc. */
+   do {
+   struct page *page;
+
+   page = alloc_page(gfp);
+   if (unlikely(!page))
+   break;
+
+   pvec->pages[pvec->nr++] = page;
+   } while (pagevec_space(pvec));
+
+   if (unlikely(!pvec->nr))
return NULL;
 
-   if (vm->pt_kmap_wc)
-   set_pages_array_wc(, 1);
+   set_pages_array_wc(pvec->pages, pvec->nr);
 
-   return page;
+   return pvec->pages[--pvec->nr];
 }
 
-static void vm_free_pages_release(struct i915_address_space *vm)
+static void vm_free_pages_release(struct i915_address_space *vm,
+ bool immediate)
 {
-   GEM_BUG_ON(!pagevec_count(>free_pages));
+   struct pagevec *pvec = >free_pages;
+
+   GEM_BUG_ON(!pagevec_count(pvec));
+
+   if (vm->pt_kmap_wc) {
+   struct pagevec *stash = >i915->mm.wc_stash;
 
-   if (vm->pt_kmap_wc)
-   set_pages_array_wb(vm->free_pages.pages,
-  pagevec_count(>free_pages));
+   /* When we use WC, first fill up the global stash and then
+* only if full immediately free the overflow.
+*/
+
+   lockdep_assert_held(>i915->drm.struct_mutex);
+   if (pagevec_space(stash)) {
+   do {
+   stash->pages[stash->nr++] =
+   pvec->pages[--pvec->nr];
+   if (!pvec->nr)
+   return;
+   } while (pagevec_space(stash));
+
+   /* As we have made some room in the VM's free_pages,
+* we can wait for it to fill again. Unless we are
+* inside i915_address_space_fini() and must
+* immediately release the pages!
+*/
+   if (!immediate)
+   return;
+   }
+
+   set_pages_array_wb(pvec->pages, pvec->nr);
+   }
 
-   __pagevec_release(>free_pages);
+   __pagevec_release(pvec);
 }
 
 static void vm_free_page(struct i915_address_space *vm, struct page *page)
 {
if (!pagevec_add(>free_pages, page))
-   vm_free_pages_release(vm);
+   vm_free_pages_release(vm, false);
 }
 
 static int __setup_page_dma(struct i915_address_space *vm,

[Intel-gfx] [CI 1/2] drm-tip: 2017y-08m-22d-16h-09m-30s UTC integration manifest

[Chris Wilson]

---
 integration-manifest | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 integration-manifest

diff --git a/integration-manifest b/integration-manifest
new file mode 100644
index ..7bc477a0f3da
--- /dev/null
+++ b/integration-manifest
@@ -0,0 +1,22 @@
+drm-intel drm-intel-fixes 31c1a7b8f966470ce136710a95afcf5822fecef8
+   drm/i915/cnl: Fix LSPCON support.
+drm-upstream drm-fixes b313f780ded9ead1f72df9c8b45f7ea00585a2e5
+   Merge tag 'drm-misc-fixes-2017-08-18' of 
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
+drm-intel drm-intel-next-fixes 04941829b0049d2446c7042ab9686dd057d809a6
+   drm/i915: Hold RPM wakelock while initializing OA buffer
+drm-intel drm-intel-next-queued 74d290f845d0736bf6b9dd22cd28dd87b270c65f
+   drm/i915: Boost GPU clocks if we miss the pageflip's vblank
+drm-upstream drm-next 6b9dfb5991a3fda1ced9062f6c86d8798416ea31
+   Merge tag 'imx-drm-next-2017-07-18' of 
git://git.pengutronix.de/git/pza/linux into drm-next
+sound-upstream for-next e8a91ae18bdc0bcedd2a07e42e66ca09dc2105d2
+   ALSA: ice1712: Add support for STAudio ADCIII
+sound-upstream for-linus 88c54cdf61f508ebcf8da2d819f5dfc03e954d1d
+   ALSA: core: Fix unexpected error at replacing user TLV
+drm-intel topic/core-for-CI 01cbe29aa8f8d7ffca23cf6e147a17529fae680e
+   e1000e: fix buffer overrun while the I219 is processing DMA transactions
+drm-misc drm-misc-next 25a8ef26fd47e4b60cfae094a43ad9bfc49e676b
+   drm/dp: Add defines for DP SDP types
+drm-misc drm-misc-next-fixes 0e8841ec7ee5b1ffe416c3be7743985b1896ec00
+   Merge airlied/drm-next into drm-misc-next
+drm-misc drm-misc-fixes fe4600a548f2763dec91b3b27a1245c370ceee2a
+   drm: Release driver tracking before making the object available again
-- 
2.14.1

___
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/edp: Be less aggressive about changing link config on eDP (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP 
(rev3)
URL   : https://patchwork.freedesktop.org/series/28588/
State : success

== Summary ==

Series 28588v3 drm/i915/edp: Be less aggressive about changing link config on 
eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/3/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-kbl-7260u) fdo#102295

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#102295 https://bugs.freedesktop.org/show_bug.cgi?id=102295

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:454s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:435s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:363s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:548s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:253s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:523s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:522s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:519s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:437s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:607s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:445s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:420s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:424s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:507s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7260u total:279  pass:267  dwarn:2   dfail:0   fail:0   skip:10  
time:500s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:587s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:599s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:526s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:473s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:444s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:482s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:407s

017fec5c2e57672a8c2a350376070e6c6a5ae950 drm-tip: 2017y-08m-22d-16h-23m-11s UTC 
integration manifest
c688185ea6b2 drm/i915/edp: Be less aggressive about changing link config on eDP

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5464/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/Makefile.am: Wrap audio test with dedicated conditional

[Lyude Paul]

r-b'd and pushed, thanks!

On Tue, 2017-08-22 at 11:26 +0300, Paul Kocialkowski wrote:
> This uses the dedicated HAVE_AUDIO conditional, that depends on both
> ALSA and GSL, for wrapping the audio test. This makes the wrapping
> consistent with what is done for the chamelium test.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  tests/Makefile.am | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 471f3818..726e2b27 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -20,13 +20,11 @@ TESTS_progs += \
>   $(NULL)
>  endif
>  
> -if HAVE_ALSA
> -if HAVE_GSL
> +if HAVE_AUDIO
>  TESTS_progs += \
>   audio \
>   $(NULL)
>  endif
> -endif
>  
>  
>  if BUILD_TESTS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915/execlists: Read the context-status HEAD from the HWSP

[Chris Wilson]

The engine also provides a mirror of the CSB write pointer in the HWSP,
but not of our read pointer. To take advantage of this we need to
remember where we read up to on the last interrupt and continue off from
there. This poses a problem following a reset, as we don't know where
the hw will start writing from, and due to the use of power contexts we
cannot perform that query during the reset itself. So we continue the
current modus operandi of delaying the first read of the context-status
read/write pointers until after the first interrupt. With this we should
now have eliminated all uncached mmio reads in handling the
context-status interrupt, though we still have the uncached mmio writes
for submitting new work, and many uncached mmio reads in the global
interrupt handler itself. Still a step in the right direction towards
reducing our resubmit latency, although it appears lost in the noise!

v2: Cannonlake moved the CSB write index
v3: Include the sw/hwsp state in debugfs/i915_engine_info
v4: Also revert to using CSB mmio for GVT-g
v5: Prevent the compiler reloading tail (Mika)

Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Acked-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 --
 drivers/gpu/drm/i915/i915_drv.h |  8 
 drivers/gpu/drm/i915/intel_lrc.c| 27 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 +++
 4 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 92aa7465e950..2d8de3a32acd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3323,8 +3323,10 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
read = GEN8_CSB_READ_PTR(ptr);
write = GEN8_CSB_WRITE_PTR(ptr);
-   seq_printf(m, "\tExeclist CSB read %d, write %d, 
interrupt posted? %s\n",
-  read, write,
+   seq_printf(m, "\tExeclist CSB read %d [%d cached], 
write %d [%d from hws], interrupt posted? %s\n",
+  read, engine->csb_head,
+  write,
+  intel_read_status_page(engine, 
intel_hws_csb_write_index(engine->i915)),
   yesno(test_bit(ENGINE_IRQ_EXECLIST,
  >irq_posted)));
if (read >= GEN8_CSB_ENTRIES)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60267e375e88..77781f3e92be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4336,4 +4336,12 @@ intel_engine_can_store_dword(struct intel_engine_cs 
*engine)
  engine->class);
 }
 
+static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
+{
+   if (INTEL_GEN(i915) >= 10)
+   return CNL_HWS_CSB_WRITE_INDEX;
+   else
+   return I915_HWS_CSB_WRITE_INDEX;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e889b57ec676..2c1017d9ed29 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -545,8 +545,6 @@ static void intel_lrc_irq_handler(unsigned long data)
 * new request (outside of the context-switch interrupt).
 */
while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
-   u32 __iomem *csb_mmio =
-   dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
/* The HWSP contains a (cacheable) mirror of the CSB */
const u32 *buf =
>status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
@@ -556,6 +554,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (unlikely(engine->csb_use_mmio)) {
buf = (u32 * __force)
(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+   engine->csb_head = -1; /* force mmio read of CSB ptrs */
}
 
/* The write will be ordered by the uncached read (itself
@@ -569,9 +568,19 @@ static void intel_lrc_irq_handler(unsigned long data)
 * is set and we do a new loop.
 */
__clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
-   head = readl(csb_mmio);
-   tail = GEN8_CSB_WRITE_PTR(head);
-   

[Intel-gfx] [PATCH 5/6] drm/i915/execlists: Read the context-status buffer from the HWSP

[Chris Wilson]

The engine provides a mirror of the CSB in the HWSP. If we use the
cacheable reads from the HWSP, we can shave off a few mmio reads per
context-switch interrupt (which are quite frequent!). Just removing a
couple of mmio is not enough to actually reduce any latency, but a small
reduction in overall cpu usage.

Much appreciation for Ben dropping the bombshell that the CSB was in the
HWSP and for Michel in digging out the details.

v2: Don't be lazy, add the defines for the indices.
v3: Include the HWSP in debugfs/i915_engine_info
v4: Check for GVT-g, it currently depends on intercepting CSB mmio
v5: Fixup GVT-g mmio path

Suggested-by: Ben Widawsky 
Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Acked-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 +--
 drivers/gpu/drm/i915/intel_lrc.c| 19 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 +++
 3 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 48572b157222..92aa7465e950 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3312,6 +3312,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
   upper_32_bits(addr), lower_32_bits(addr));
 
if (i915.enable_execlists) {
+   const u32 *hws = 
>status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
u32 ptr, read, write;
unsigned int idx;
 
@@ -3334,10 +3335,12 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
write += GEN8_CSB_ENTRIES;
while (read < write) {
idx = ++read % GEN8_CSB_ENTRIES;
-   seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, 
context: %d\n",
+   seq_printf(m, "\tExeclist CSB[%d]: 0x%08x 
[0x%08x in hwsp], context: %d [%d in hwsp]\n",
   idx,
   
I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
-  
I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
+  hws[idx * 2],
+  
I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
+  hws[idx * 2 + 1]);
}
 
rcu_read_lock();
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index aa5534213190..e889b57ec676 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -547,10 +547,17 @@ static void intel_lrc_irq_handler(unsigned long data)
while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
u32 __iomem *csb_mmio =
dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
-   u32 __iomem *buf =
-   dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
+   /* The HWSP contains a (cacheable) mirror of the CSB */
+   const u32 *buf =
+   >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
unsigned int head, tail;
 
+   /* However GVT emulation depends upon intercepting CSB mmio */
+   if (unlikely(engine->csb_use_mmio)) {
+   buf = (u32 * __force)
+   (dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+   }
+
/* The write will be ordered by the uncached read (itself
 * a memory barrier), so we do not need another in the form
 * of a locked instruction. The race between the interrupt
@@ -590,13 +597,12 @@ static void intel_lrc_irq_handler(unsigned long data)
 * status notifier.
 */
 
-   status = readl(buf + 2 * head);
+   status = buf[2 * head];
if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
continue;
 
/* Check the context/desc id for this event matches */
-   GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
-port->context_id);
+   GEM_DEBUG_BUG_ON(buf[2 * head + 1] != port->context_id);
 
rq = port_unpack(port, );

[Intel-gfx] [PATCH 4/6] drm/i915: Allow HW status page to be bound high

[Chris Wilson]

At the time of commit 1f767e02d69f ("drm/i915: HWS must be in the
mappable region for g33"), drm_mm insertion would often default to
placing a new object high in the zone forcing us to specify that certain
HWSP must be bound within the low mappable region. Since then, drm_mm
has gained more finesse over its placement and exposes that to the
caller, commit 4e64e5539d15 ("drm: Improve drm_mm search (and fix
topdown allocation) with rbtrees"). As such where possible we want the
HWSP to be outside of the mappable aperture and so need to specify that
can be pinned high.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 43eddf491c0d..24c3b4e4732d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -508,6 +508,8 @@ static int init_status_page(struct intel_engine_cs *engine)
 * actually map it).
 */
flags |= PIN_MAPPABLE;
+   else
+   flags |= PIN_HIGH;
ret = i915_vma_pin(vma, 0, 4096, flags);
if (ret)
goto err;
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915/lrc: allocate separate page for HWSP

[Chris Wilson]

From: Daniele Ceraolo Spurio 

On gen8+ we're currently using the PPHWSP of the kernel ctx as the
global HWSP. However, when the kernel ctx gets submitted (e.g. from
__intel_autoenable_gt_powersave) the HW will use that page as both
HWSP and PPHWSP. This causes a conflict in the register arena of the
HWSP, i.e. dword indices below 0x30. We don't current utilize this arena,
but in the following patches we will take advantage of the cached
register state for handling execlist's context status interrupt.

To avoid the conflict, instead of re-using the PPHWSP of the kernel
ctx we can allocate a separate page for the HWSP like what happens for
pre-execlists platform.

v2: Add a use-case for the register arena of the HWSP.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1499357440-34688-1-git-send-email-daniele.ceraolospu...@intel.com
Signed-off-by: Chris Wilson 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 126 +++-
 drivers/gpu/drm/i915/intel_lrc.c|  34 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 125 +--
 3 files changed, 127 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d23f18874309..43eddf491c0d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -442,6 +442,114 @@ static void intel_engine_cleanup_scratch(struct 
intel_engine_cs *engine)
i915_vma_unpin_and_release(>scratch);
 }
 
+static void cleanup_phys_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   if (!dev_priv->status_page_dmah)
+   return;
+
+   drm_pci_free(_priv->drm, dev_priv->status_page_dmah);
+   engine->status_page.page_addr = NULL;
+}
+
+static void cleanup_status_page(struct intel_engine_cs *engine)
+{
+   struct i915_vma *vma;
+   struct drm_i915_gem_object *obj;
+
+   vma = fetch_and_zero(>status_page.vma);
+   if (!vma)
+   return;
+
+   obj = vma->obj;
+
+   i915_vma_unpin(vma);
+   i915_vma_close(vma);
+
+   i915_gem_object_unpin_map(obj);
+   __i915_gem_object_release_unless_active(obj);
+}
+
+static int init_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   unsigned int flags;
+   void *vaddr;
+   int ret;
+
+   obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+   if (IS_ERR(obj)) {
+   DRM_ERROR("Failed to allocate status page\n");
+   return PTR_ERR(obj);
+   }
+
+   ret = i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);
+   if (ret)
+   goto err;
+
+   vma = i915_vma_instance(obj, >i915->ggtt.base, NULL);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
+   goto err;
+   }
+
+   flags = PIN_GLOBAL;
+   if (!HAS_LLC(engine->i915))
+   /* On g33, we cannot place HWS above 256MiB, so
+* restrict its pinning to the low mappable arena.
+* Though this restriction is not documented for
+* gen4, gen5, or byt, they also behave similarly
+* and hang if the HWS is placed at the top of the
+* GTT. To generalise, it appears that all !llc
+* platforms have issues with us placing the HWS
+* above the mappable region (even though we never
+* actually map it).
+*/
+   flags |= PIN_MAPPABLE;
+   ret = i915_vma_pin(vma, 0, 4096, flags);
+   if (ret)
+   goto err;
+
+   vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+   if (IS_ERR(vaddr)) {
+   ret = PTR_ERR(vaddr);
+   goto err_unpin;
+   }
+
+   engine->status_page.vma = vma;
+   engine->status_page.ggtt_offset = i915_ggtt_offset(vma);
+   engine->status_page.page_addr = memset(vaddr, 0, PAGE_SIZE);
+
+   DRM_DEBUG_DRIVER("%s hws offset: 0x%08x\n",
+engine->name, i915_ggtt_offset(vma));
+   return 0;
+
+err_unpin:
+   i915_vma_unpin(vma);
+err:
+   i915_gem_object_put(obj);
+   return ret;
+}
+
+static int init_phys_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   GEM_BUG_ON(engine->id != RCS);
+
+   dev_priv->status_page_dmah =
+   drm_pci_alloc(_priv->drm, PAGE_SIZE, PAGE_SIZE);
+   if (!dev_priv->status_page_dmah)
+   return -ENOMEM;
+
+   engine->status_page.page_addr = dev_priv->status_page_dmah->vaddr;
+   

[Intel-gfx] [PATCH 2/6] drm/i915/guc: Don't make assumptions while getting the lrca offset

[Chris Wilson]

From: Michel Thierry 

Using the HWSP ggtt_offset to get the lrca offset is only correct if the
HWSP happens to be before it (when we reuse the PPHWSP of the kernel
context as the engine HWSP). Instead of making this assumption, get the
lrca offset from the kernel_context engine state.

And while looking at this part of the GuC interaction, it was also
noticed that the firmware expects the size of only the engine context
(context minus the execlist part, i.e. don't include the first 80
dwords), so pass the right size.

v2: Use the new macros to prevent abusive overuse of the old ones (Chris).

Reported-by: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-2-michel.thie...@intel.com
Reviewed-by: Chris Wilson 
Acked-by: Daniele Ceraolo Spurio 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b7ca13860677..8b96935cf96a 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1018,6 +1018,12 @@ static void guc_policies_init(struct guc_policies 
*policies)
policies->is_valid = 1;
 }
 
+/*
+ * The first 80 dwords of the register state context, containing the
+ * execlists and ppgtt registers.
+ */
+#define LR_HW_CONTEXT_SIZE (80 * sizeof(u32))
+
 static int guc_ads_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -1032,6 +1038,8 @@ static int guc_ads_create(struct intel_guc *guc)
} __packed *blob;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+   const u32 skipped_offset = LRC_HEADER_PAGES * PAGE_SIZE;
+   const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
u32 base;
 
GEM_BUG_ON(guc->ads_vma);
@@ -1062,13 +1070,20 @@ static int guc_ads_create(struct intel_guc *guc)
 * engines after a reset. Here we use the Render ring default
 * context, which must already exist and be pinned in the GGTT,
 * so its address won't change after we've told the GuC where
-* to find it.
+* to find it. Note that we have to skip our header (1 page),
+* because our GuC shared data is there.
 */
blob->ads.golden_context_lrca =
-   dev_priv->engine[RCS]->status_page.ggtt_offset;
+   guc_ggtt_offset(dev_priv->kernel_context->engine[RCS].state) + 
skipped_offset;
 
+   /*
+* The GuC expects us to exclude the portion of the context image that
+* it skips from the size it is to read. It starts reading from after
+* the execlist context (so skipping the first page [PPHWSP] and 80
+* dwords). Weird guc is weird.
+*/
for_each_engine(engine, dev_priv, id)
-   blob->ads.eng_state_size[engine->guc_id] = engine->context_size;
+   blob->ads.eng_state_size[engine->guc_id] = engine->context_size 
- skipped_size;
 
base = guc_ggtt_offset(vma);
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] HWSP execlists for kbl-shards

[Chris Wilson]

Just sending so I can see if the farm's kbl (or other execlist boxes)
have any of the same symptoms as Mika.
-Chris

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/6] drm/i915/lrc: Clarify the format of the context image

[Chris Wilson]

From: Michel Thierry 

Not only the context image consist of two parts (the PPHWSP, and the
logical context state), but we also allocate a header at the start of
for sharing data with GuC. Thus every lrc looks like this:

  | [guc]  | [hwsp] [logical state] |
  |<- our header ->|<- context image  ->|

So far, we have oversimplified whenever we use each of these parts of the
context, just because the GuC header happens to be in page 0, and the
(PP)HWSP is in page 1. But this had led to using the same define for more
than one meaning (as a page index in the lrc and as 1 page).

This patch adds defines for the GuC shared page, the PPHWSP page and the
start of the logical state. It also updated the places where the old
define was being used. Since we are not changing the size (or format) of
the context, there are no functional changes.

v2: Use PPHWSP index for hws again.

Suggested-by: Chris Wilson 
Signed-off-by: Michel Thierry 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: intel-gvt-...@lists.freedesktop.org
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-1-michel.thie...@intel.com
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  4 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c |  4 ++--
 drivers/gpu/drm/i915/intel_lrc.c   |  9 ++---
 drivers/gpu/drm/i915/intel_lrc.h   | 25 ++---
 4 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 391800d2067b..cf396325d8e4 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -87,7 +87,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
return -EINVAL;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_PPHWSP_PN + i);
+   page = i915_gem_object_get_page(ctx_obj, LRC_HEADER_PAGES + i);
dst = kmap(page);
intel_gvt_hypervisor_read_gpa(vgpu, context_gpa, dst,
GTT_PAGE_SIZE);
@@ -408,7 +408,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
return;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_PPHWSP_PN + i);
+   page = i915_gem_object_get_page(ctx_obj, LRC_HEADER_PAGES + i);
src = kmap(page);
intel_gvt_hypervisor_write_gpa(vgpu, context_gpa, src,
GTT_PAGE_SIZE);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 48a1e9349a2c..b7ca13860677 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1310,7 +1310,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
/* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -1336,7 +1336,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
/* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d89e1b8e1cc5..0c19aa7016bc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -279,7 +279,7 @@ intel_lr_context_descriptor_update(struct i915_gem_context 
*ctx,
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1<desc_template;  /* bits  0-11 */
-   desc |= i915_ggtt_offset(ce->state) + LRC_PPHWSP_PN * PAGE_SIZE;
+   desc |= i915_ggtt_offset(ce->state) + LRC_HEADER_PAGES * PAGE_SIZE;
/* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52 */
 
@@ -2054,8 +2054,11 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
 
context_size = round_up(engine->context_size, I915_GTT_PAGE_SIZE);
 
-   /* One extra page as the sharing data between driver and GuC */
-   

[Intel-gfx] ✓ Fi.CI.BAT: success for Add retries for dp dual mode reads

[Patchwork]

== Series Details ==

Series: Add retries for dp dual mode reads
URL   : https://patchwork.freedesktop.org/series/29155/
State : success

== Summary ==

Series 29155v1 Add retries for dp dual mode reads
https://patchwork.freedesktop.org/api/1.0/series/29155/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7260u) fdo#102294
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781

fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:459s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:447s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:360s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:559s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:532s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:524s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:439s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:618s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:448s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:427s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:556s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:523s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:605s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:628s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:526s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:474s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:488s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:493s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:451s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:490s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:555s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:417s

017fec5c2e57672a8c2a350376070e6c6a5ae950 drm-tip: 2017y-08m-22d-16h-23m-11s UTC 
integration manifest
78c3d541a917 drm/i915: Don't give up waiting on INVALID_MODE
fffb553d68b6 drm: Add retries for dp dual mode read

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5463/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

[Chris Wilson]

Quoting Ville Syrjälä (2017-08-22 18:02:04)
> On Mon, Aug 21, 2017 at 04:54:21PM +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-08-17 13:37:06)
> > > If we miss the current vblank because the gpu was busy, that may cause a
> > > jitter as the frame rate temporarily drops. We try to limit the impact
> > > of this by then boosting the GPU clock to deliver the frame as quickly
> > > as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
> > > frequency if we detect outstanding pageflips") but was never forward
> > > ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
> > > Rip out legacy page_flip completion/irq handling").
> > > 
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=102199
> > > Signed-off-by: Chris Wilson 
> > > Cc: Maarten Lankhorst 
> > > Cc: Ville Syrjälä 
> > > Cc: Daniel Vetter 
> > 
> > Either of you like to ack the return of this code to the display
> > subsystem? It's still reactionary and will one day be replace by a pony,
> > or perhaps supplemented by one.
> 
> It looks reasonable enough to me.
> 
> For the pony part I was wondering if a blind donkey would be enough.
> Something like "boost to rpe as soon as a flip is queued" is what
> I was thinking. But I suppose it ought to be likely that we're
> already >= rpe if we have something running on the gpu. So maybe
> rpe just isn't fast enough for these cases?

The counterpoint is that even byt can decode a 1080p mp4 and show it at
near minimal clocks. So I feel any arbitrary boosting will run afoul of
power efficient hw (or at least fixed purpose doing just that). For the
interactivity detection, Ray was suggesting we listen to input events,
but at least we should push that coupling to userspace. My current
favourite remains granting boost privileges to a context so that when
such an interactive workload comes in, we boost (or we generalize that
with "desired clocks" on a context). We are not far then from having a
budget + deadline and the building blocks of a singing and dancing pony.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

[Ville Syrjälä]

On Mon, Aug 21, 2017 at 04:54:21PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-08-17 13:37:06)
> > If we miss the current vblank because the gpu was busy, that may cause a
> > jitter as the frame rate temporarily drops. We try to limit the impact
> > of this by then boosting the GPU clock to deliver the frame as quickly
> > as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
> > frequency if we detect outstanding pageflips") but was never forward
> > ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
> > Rip out legacy page_flip completion/irq handling").
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=102199
> > Signed-off-by: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> 
> Either of you like to ack the return of this code to the display
> subsystem? It's still reactionary and will one day be replace by a pony,
> or perhaps supplemented by one.

It looks reasonable enough to me.

For the pony part I was wondering if a blind donkey would be enough.
Something like "boost to rpe as soon as a flip is queued" is what
I was thinking. But I suppose it ought to be likely that we're
already >= rpe if we have something running on the gpu. So maybe
rpe just isn't fast enough for these cases?

> -Chris
> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 59 
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  1 -
> >  drivers/gpu/drm/i915/intel_pm.c  | 42 ++---
> >  3 files changed, 62 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 0e93ec201fe3..7d5b19553637 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12636,6 +12636,55 @@ static const struct drm_crtc_funcs 
> > intel_crtc_funcs = {
> > .set_crc_source = intel_crtc_set_crc_source,
> >  };
> >  
> > +struct wait_rps_boost {
> > +   struct wait_queue_entry wait;
> > +
> > +   struct drm_crtc *crtc;
> > +   struct drm_i915_gem_request *request;
> > +};
> > +
> > +static int do_rps_boost(struct wait_queue_entry *_wait,
> > +   unsigned mode, int sync, void *key)
> > +{
> > +   struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), 
> > wait);
> > +   struct drm_i915_gem_request *rq = wait->request;
> > +
> > +   gen6_rps_boost(rq, NULL);
> > +   i915_gem_request_put(rq);
> > +
> > +   drm_crtc_vblank_put(wait->crtc);
> > +
> > +   list_del(>wait.entry);
> > +   kfree(wait);
> > +   return 1;
> > +}
> > +
> > +static void add_rps_boost_after_vblank(struct drm_crtc *crtc,
> > +  struct dma_fence *fence)
> > +{
> > +   struct wait_rps_boost *wait;
> > +
> > +   if (!dma_fence_is_i915(fence))
> > +   return;
> > +
> > +   if (drm_crtc_vblank_get(crtc))
> > +   return;
> > +
> > +   wait = kmalloc(sizeof(*wait), GFP_KERNEL);
> > +   if (!wait) {
> > +   drm_crtc_vblank_put(crtc);
> > +   return;
> > +   }
> > +
> > +   wait->request = to_request(dma_fence_get(fence));
> > +   wait->crtc = crtc;
> > +
> > +   wait->wait.func = do_rps_boost;
> > +   wait->wait.flags = 0;
> > +
> > +   add_wait_queue(drm_crtc_vblank_waitqueue(crtc), >wait);
> > +}
> > +
> >  /**
> >   * intel_prepare_plane_fb - Prepare fb for usage on plane
> >   * @plane: drm plane to prepare for
> > @@ -12733,12 +12782,22 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> > return ret;
> >  
> > if (!new_state->fence) { /* implicit fencing */
> > +   struct dma_fence *fence;
> > +
> > ret = 
> > i915_sw_fence_await_reservation(_state->commit_ready,
> >   obj->resv, NULL,
> >   false, 
> > I915_FENCE_TIMEOUT,
> >   GFP_KERNEL);
> > if (ret < 0)
> > return ret;
> > +
> > +   fence = reservation_object_get_excl_rcu(obj->resv);
> > +   if (fence) {
> > +   add_rps_boost_after_vblank(new_state->crtc, fence);
> > +   dma_fence_put(fence);
> > +   }
> > +   } else {
> > +   add_rps_boost_after_vblank(new_state->crtc, 
> > new_state->fence);
> > }
> >  
> > return 0;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index fa47285918f4..e092354b4d63 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1844,7 +1844,6 @@ void 

Re: [Intel-gfx] [PATCH] dim: Properly handle series on apply_branch

[Rodrigo Vivi]

On Tue, Aug 22, 2017 at 12:22 AM, Jani Nikula  wrote:
> On Mon, 21 Aug 2017, Rodrigo Vivi  wrote:
>> So far we could use *dim* to apply a whole series
>> in a mbox, but only the very last patch was receiving
>> all the checks and patchwork link.
>>
>> So this patch remove this limitation by using git mailsplit
>> to split the mbox and than use git am and checks individually
>> on each patch.
>>
>> v2: a. Don't loop with `ls $dir` nor use ls. Shellcheck recommends
>>globs instead. Reference: SC2045
>> c. Split the apply patch in a separated function as suggested
>>by Jani.
>> b. Use -b on git mailsplit so it will automatically it is not
>>an mbox file and parse it assuming a single mail message.
>>This fixes the issue Jani notice with input directly from
>>MUA: "corrupt mailbox".
>>
>> Cc: Jani Nikula 
>> Cc: Daniel Vetter 
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  dim | 65 ++---
>>  1 file changed, 38 insertions(+), 27 deletions(-)
>>
>> diff --git a/dim b/dim
>> index 11aa675cc3bc..866563624eb5 100755
>> --- a/dim
>> +++ b/dim
>> @@ -756,49 +756,60 @@ function dim_push
>>   dim_push_branch $(git_current_branch) "$@"
>>  }
>>
>> +function apply_patch #patch_file
>> +{
>> + local patch message_id committer_email patch_from sob rv
>> +
>> + patch="$1"
>
> shift here
>
>> + message_id=$(message_get_id $patch)
>> + committer_email=$(git_committer_email)
>> +
>> + patch_from=$(grep "From:" "$patch" | head -1)
>> + if [[ "$patch_from" != *"$committer_email"* ]] ; then
>> + sob=-s
>> + fi
>> +
>> + git am --scissors -3 $sob "$@" $patch
>
> The "$@" no longer gets passed all the way here.
>
>> +
>> + if [ -n "$message_id" ]; then
>> + dim_commit_add_tag "Link: 
>> https://patchwork.freedesktop.org/patch/msgid/$message_id;
>> + else
>> + echoerr "WARNING: No message-id found in the patch file."
>> + rv=1
>> + fi
>> +
>> + if ! checkpatch_commit HEAD; then
>> + rv=1
>> + fi
>> + if ! check_maintainer $branch HEAD; then
>> + rv=1
>> + fi
>> +
>> + eval $DRY $DIM_POST_APPLY_ACTION
>
> return $rv.
>
>> +}
>> +
>>  # ensure we're on branch $1, and apply patches. the rest of the arguments 
>> are
>>  # passed to git am.
>>  dim_alias_ab=apply-branch
>>  dim_alias_sob=apply-branch
>>  function dim_apply_branch
>>  {
>> - local branch file message_id committer_email patch_from sob rv
>> + local branch file
>>
>>   branch=${1:?$usage}
>>   shift
>>   file=$(mktemp)
>> + dir=$(mktemp -d)
>>
>>   assert_branch $branch
>>   assert_repo_clean
>>
>>   cat > $file
>> + git mailsplit -b -o$dir $file > /dev/null
>
> Nitpick, git mailsplit could consume the file directly from stdin, so we
> no longer have a need for the temp $file.

I had considered and tried this here, but didn't worked as I expected...
maybe in a separate patch later after playing a bit and test more?

>
>>
>> - message_id=$(message_get_id $file)
>> -
>> - committer_email=$(git_committer_email)
>> -
>> - patch_from=$(grep "From:" "$file" | head -1)
>> - if [[ "$patch_from" != *"$committer_email"* ]] ; then
>> - sob=-s
>> - fi
>> -
>> - git am --scissors -3 $sob "$@" $file
>> -
>> - if [ -n "$message_id" ]; then
>> - dim_commit_add_tag "Link: 
>> https://patchwork.freedesktop.org/patch/msgid/$message_id;
>> - else
>> - echoerr "WARNING: No message-id found in the patch file."
>> - rv=1
>> - fi
>> -
>> - if ! checkpatch_commit HEAD; then
>> - rv=1
>> - fi
>> - if ! check_maintainer $branch HEAD; then
>> - rv=1
>> - fi
>> -
>> - eval $DRY $DIM_POST_APPLY_ACTION
>> + for patch in $dir/*; do
>> + apply_patch $patch
>
> Need to pass "$@" to apply_patch.
>
> Need to handle the return value from apply_patch, and I presume we don't
> want checkpatch warnings in a single patch to stop applying the rest of
> the mbox (set -e would abort on errors otherwise). But we want to return
> non-zero exit status in that case.
>
> BR,
> Jani.
>
>
>> + done
>>
>>   return $rv
>>  }
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH] dim: Properly handle series on apply_branch

[Rodrigo Vivi]

So far we could use *dim* to apply a whole series
in a mbox, but only the very last patch was receiving
all the checks and patchwork link.

So this patch remove this limitation by using git mailsplit
to split the mbox and than use git am and checks individually
on each patch.

v2: a. Don't loop with `ls $dir` nor use ls. Shellcheck recommends
   globs instead. Reference: SC2045
c. Split the apply patch in a separated function as suggested
   by Jani.
b. Use -b on git mailsplit so it will automatically it is not
   an mbox file and parse it assuming a single mail message.
   This fixes the issue Jani notice with input directly from
   MUA: "corrupt mailbox".
v3: Pass $@ to apply_patch function and properly handle the shift.
Handle returns. If any patch in the series had some kind of goof
return 1.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
---
 dim | 52 ++--
 1 file changed, 34 insertions(+), 18 deletions(-)

diff --git a/dim b/dim
index 11aa675cc3bc..80ad23a1cd31 100755
--- a/dim
+++ b/dim
@@ -756,33 +756,21 @@ function dim_push
dim_push_branch $(git_current_branch) "$@"
 }
 
-# ensure we're on branch $1, and apply patches. the rest of the arguments are
-# passed to git am.
-dim_alias_ab=apply-branch
-dim_alias_sob=apply-branch
-function dim_apply_branch
+function apply_patch #patch_file
 {
-   local branch file message_id committer_email patch_from sob rv
+   local patch message_id committer_email patch_from sob rv
 
-   branch=${1:?$usage}
+   patch="$1"
shift
-   file=$(mktemp)
-
-   assert_branch $branch
-   assert_repo_clean
-
-   cat > $file
-
-   message_id=$(message_get_id $file)
-
+   message_id=$(message_get_id $patch)
committer_email=$(git_committer_email)
 
-   patch_from=$(grep "From:" "$file" | head -1)
+   patch_from=$(grep "From:" "$patch" | head -1)
if [[ "$patch_from" != *"$committer_email"* ]] ; then
sob=-s
fi
 
-   git am --scissors -3 $sob "$@" $file
+   git am --scissors -3 $sob "$@" $patch
 
if [ -n "$message_id" ]; then
dim_commit_add_tag "Link: 
https://patchwork.freedesktop.org/patch/msgid/$message_id;
@@ -799,6 +787,34 @@ function dim_apply_branch
fi
 
eval $DRY $DIM_POST_APPLY_ACTION
+   return $rv
+}
+
+# ensure we're on branch $1, and apply patches. the rest of the arguments are
+# passed to git am.
+dim_alias_ab=apply-branch
+dim_alias_sob=apply-branch
+function dim_apply_branch
+{
+   local branch file rv
+
+   branch=${1:?$usage}
+   shift
+   file=$(mktemp)
+   dir=$(mktemp -d)
+
+   assert_branch $branch
+   assert_repo_clean
+
+   cat > $file
+   git mailsplit -b -o$dir $file > /dev/null
+
+   for patch in $dir/*; do
+   apply_patch $patch $@
+   if [[ $? -eq "1" ]] ; then
+   rv=1
+   fi
+   done
 
return $rv
 }
-- 
2.13.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/1] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

Hi All,

When I last send this patch not everyone was enthusiastic about this
patch. As already mentioned in the v2 discussion, solving this in userspace
is not really feasible since there is no single place to fix it there, it
will need fixing in at least 6 different places from the top of my head
(basically any app/server/"driver" talking directly to kms needs fixing)
Also fixing it in userspace will be quite complicated even in a single
consumer of the kms API.

It has been 3 months since my last version and no other solution has
materialized, so I would like to move forward with this patch.

The only technical objection against my previous version was that it
did not fix the subpixel order reported to userspace, that has been
fixed in this version and it has been rebased on top of the latest
drm-intel-next-queued.

Regards,

Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

On some (Bay Trail) devices the LCD panel is mounted upside-down.

This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville Syrjala's
"drm/fb-helper: Inherit rotation wip" patch and when re-using the
initial fb it stores that in intel_crtc.initial_rotation.

It adds an intel_plane_get_rotation helper which combines this
initial_rotation with any rotation requested by userspace and
uses this in all places which look at a planes rotation, thus
transparently dealing with upside-down LCD panels without requiring
any user-space or fbcon changes.

This fixes the kernel boot messages switching from being shown the right
way up in efifb to being shown upside down as soon as a native kms driver
loads, as well as any graphics displayed by userspace being upside-down.

Note this only deals with upside-down LCD panels / 180 degrees
rotation as the hardware in question only supports 180 degrees
rotation in hardware. The one model known which has a panel mounted
with 90/270 degrees rotation will need to be fully dealt with in
userspace, even the firmware boot screen / menus are rotated 90 degrees
on this one and there simply is nothing the kernel can do about this.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Cc: Ville Syrjala 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Fix brown paperbag bug s/val & mask/val & ~mask/ to clear old rotation bits
Changes in v3:
-Rebase on current (2017 aug. 22) drm-intel-next-queued
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  7 ++-
 drivers/gpu/drm/i915/intel_display.c  | 91 +--
 drivers/gpu/drm/i915/intel_drv.h  | 32 +++
 drivers/gpu/drm/i915/intel_fbc.c  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c   |  6 +-
 drivers/gpu/drm/i915/intel_sprite.c   | 14 ++---
 6 files changed, 121 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index ee76fab7bb6f..824aaba5112b 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -116,6 +116,7 @@ int intel_plane_atomic_check_with_state(struct 
intel_crtc_state *crtc_state,
struct intel_plane *intel_plane = to_intel_plane(plane);
const struct drm_display_mode *adjusted_mode =
_state->base.adjusted_mode;
+   unsigned int rotation = intel_plane_get_rotation(state);
int ret;
 
/*
@@ -135,7 +136,7 @@ int intel_plane_atomic_check_with_state(struct 
intel_crtc_state *crtc_state,
intel_state->clip.y2 =
crtc_state->base.enable ? crtc_state->pipe_src_h : 0;
 
-   if (state->fb && drm_rotation_90_or_270(state->rotation)) {
+   if (state->fb && drm_rotation_90_or_270(rotation)) {
struct drm_format_name_buf format_name;
 
if (state->fb->modifier != I915_FORMAT_MOD_Y_TILED &&
@@ -164,8 +165,8 @@ int intel_plane_atomic_check_with_state(struct 
intel_crtc_state *crtc_state,
 
/* CHV ignores the mirror bit when the rotate bit is set :( */
if (IS_CHERRYVIEW(dev_priv) &&
-   state->rotation & DRM_MODE_ROTATE_180 &&
-   state->rotation & DRM_MODE_REFLECT_X) {
+   rotation & DRM_MODE_ROTATE_180 &&
+   rotation & DRM_MODE_REFLECT_X) {
DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3b95cf953335..c3d9c27248d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2277,7 +2277,7 @@ void intel_add_fb_offsets(int *x, int *y,
 
 {
const struct intel_framebuffer *intel_fb = 
to_intel_framebuffer(state->base.fb);
-   unsigned int rotation = state->base.rotation;
+   unsigned int rotation = intel_plane_get_rotation(>base);
 
if (drm_rotation_90_or_270(rotation)) {
*x += intel_fb->rotated[plane].x;
@@ -2330,7 +2330,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
const struct drm_i915_private *dev_priv = 
to_i915(state->base.plane->dev);
const struct drm_framebuffer *fb = state->base.fb;
unsigned int cpp = fb->format->cpp[plane];
-   unsigned int rotation = state->base.rotation;
+   unsigned int rotation = intel_plane_get_rotation(>base);
unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
 
WARN_ON(new_offset > old_offset);
@@ -2434,7 +2434,7 @@ u32 intel_compute_tile_offset(int *x, int *y,
struct intel_plane *intel_plane = to_intel_plane(state->base.plane);
struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
const struct drm_framebuffer *fb = state->base.fb;
-   unsigned int rotation = state->base.rotation;
+   unsigned int 

[Intel-gfx] [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP

[Jim Bride]

This set of changes has some history to them.  There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec.  These changes were:

commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")

which were eventually hand-reverted by:

commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
 feature")

in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915.  There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation.  The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes.  This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place.  None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.

v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
  reading. (Chris)
* Rebase
v5: * Checkpatch cleanup
* Rebase
v6: * is_edp() => intel_dp_is_edp()
* rebase
v7: * Remove extraneous is_edp() prototype (Rodrigo)

Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Cc: Manasi D Navare 
Cc: Mika Kahola 
Cc: Jani Nikula 
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_dp.c   |  2 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++-
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e385658..38bc7e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
 
intel_dp->reset_link_params = false;
+   intel_dp->train_set_valid = false;
}
 
intel_dp_print_rates(intel_dp);
@@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_dp_set_source_rates(intel_dp);
 
intel_dp->reset_link_params = true;
+   intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..79fe369 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
 {
-   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+   if (!intel_dp->train_set_valid)
+   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
 }
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
   DP_TRAINING_PATTERN_1 |
   DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+   intel_dp->train_set_valid = false;
return false;
}
 
+   /*
+* The initial set of link parameters are set by this point, so go
+* ahead and set intel_dp->train_set_valid to false in case any of
+* the succeeding steps fail.  It will be set back to true if we were
+* able to achieve clock recovery in the specified configuration.
+*/
+   intel_dp->train_set_valid = false;
+
voltage_tries = 1;
max_vswing_tries = 0;
for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
 
if (drm_dp_clock_recovery_ok(link_status, 
intel_dp->lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
+   

Re: [Intel-gfx] [PATCH v6] drm/i915/edp: Be less aggressive about changing link config on eDP

[Jim Bride]

On Mon, Aug 21, 2017 at 11:27:37PM +, Vivi, Rodrigo wrote:
> On Mon, 2017-08-21 at 14:03 -0700, Jim Bride wrote:
> > This set of changes has some history to them.  There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec.  These changes were:
> > 
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > 
> > which were eventually hand-reverted by:
> > 
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> >  feature")
> > 
> > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915.  There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation.  The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place.  None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> > 
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> >   reading. (Chris)
> > * Rebase
> > v5: * Checkpatch cleanup
> > * Rebase
> > v6: * is_edp() => intel_dp_is_edp()
> > * rebase
> > 
> > Cc: Chris Wilson 
> > Cc: Rodrigo Vivi 
> > Cc: Paulo Zanoni 
> > Cc: Manasi D Navare 
> > Cc: Mika Kahola 
> > Cc: Jani Nikula 
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c   |  2 ++
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
> >  3 files changed, 18 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index e385658..38bc7e0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector 
> > *intel_connector)
> > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >  
> > intel_dp->reset_link_params = false;
> > +   intel_dp->train_set_valid = false;
> > }
> >  
> > intel_dp_print_rates(intel_dp);
> > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port 
> > *intel_dig_port,
> > intel_dp_set_source_rates(intel_dp);
> >  
> > intel_dp->reset_link_params = true;
> > +   intel_dp->train_set_valid = false;
> > intel_dp->pps_pipe = INVALID_PIPE;
> > intel_dp->active_pipe = INVALID_PIPE;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..79fe369 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > uint8_t dp_train_pat)
> >  {
> > -   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > +   if (!intel_dp->train_set_valid)
> > +   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > intel_dp_set_signal_levels(intel_dp);
> > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> >  }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
> > *intel_dp)
> >DP_TRAINING_PATTERN_1 |
> >DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to enable link training\n");
> > +   intel_dp->train_set_valid = false;
> > return false;
> > }
> >  
> > +   /*
> > +* The initial set of link parameters are set by this point, so go
> > +* ahead and set intel_dp->train_set_valid to false in case any of
> > +* the succeeding steps fail.  It will be set back to true if we were
> > +* able to achieve clock recovery in the specified configuration.
> > +*/
> > +   

[Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.

[Rodrigo Vivi]

On my own workflow I was missing a way to download mboxes
directly from patchwork with the patchwork id. So my first
reflex was to modify dim to fulfil my needs. However that
was increasing dim in complexity and dependencies and leaving
that messy.

That was when Jani suggested me the dimrc extension with the
example that is now part of this spec.

That was clean and simple enough to understand, so Daniel
suggested me to add it to the spec.

For record let's put my final local solution that lays now on
my own ~/.dimrc

dim_pwaq()
{
if [ -n "$1" ]; then
curl https://patchwork.freedesktop.org/patch/$1/mbox/ | 
dim_apply_queued
else
echo "Give me a patchwork id"
fi
}

v2: Use code-block directive. Get's cleaner and make check happy.
v3: Use a generic block instead of sphinx directive otherwise
rst2man can get confused on pur man generation.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
---
 dim.rst | 16 
 1 file changed, 16 insertions(+)

diff --git a/dim.rst b/dim.rst
index 802c776e03f9..00e4511a1fce 100644
--- a/dim.rst
+++ b/dim.rst
@@ -441,6 +441,22 @@ usage
 Short form usage help listing all subcommands. Run by default or if an unknown
 subcommand was passed on the cmdline.
 
+ALIASES
+===
+
+Extending **dim** functionalities
+-
+
+It is possible to create your own dim helper and aliases by adding them to 
\$HOME/.dimrc::
+
+   dim_my_fancy_list_aliases()
+   {
+   echo "Hello world!":
+   dim_list_aliases:
+   }
+
+   dim_alias_list_aliases=my-fancy-list-aliases
+
 ENVIRONMENT
 ===
 
-- 
2.13.2

___
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/cnl: simplify cnl_procmon_values handling

[Rodrigo Vivi]

merged to dinq. thanks for the patches and review

On Tue, Aug 22, 2017 at 7:44 AM, Ville Syrjälä
 wrote:
> On Mon, Aug 21, 2017 at 05:03:55PM -0700, Rodrigo Vivi wrote:
>> From: Paulo Zanoni 
>>
>> Make it a little less magical and a little simpler and more hardcoded
>> so we don't end up with an array that's composed mostly of empty
>> entries.
>>
>> v2: Add an enum for the voltage+register values (Ville).
>>
>> Signed-off-by: Paulo Zanoni 
>> Signed-off-by: Rodrigo Vivi 
>
> For the series
> Reviewed-by: Ville Syrjälä 
>
>> ---
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 58 
>> +
>>  1 file changed, 37 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index b66d8e136aa3..b7f4fbe7ae0d 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -2707,24 +2707,27 @@ void bxt_display_core_uninit(struct drm_i915_private 
>> *dev_priv)
>>   usleep_range(10, 30);   /* 10 us delay per Bspec */
>>  }
>>
>> -#define CNL_PROCMON_IDX(val) \
>> - (((val) & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) >> 
>> VOLTAGE_INFO_SHIFT)
>> -#define NUM_CNL_PROCMON \
>> - (CNL_PROCMON_IDX(VOLTAGE_INFO_MASK | PROCESS_INFO_MASK) + 1)
>> +enum {
>> + PROCMON_0_85V_DOT_0,
>> + PROCMON_0_95V_DOT_0,
>> + PROCMON_0_95V_DOT_1,
>> + PROCMON_1_05V_DOT_0,
>> + PROCMON_1_05V_DOT_1,
>> +};
>>
>>  static const struct cnl_procmon {
>>   u32 dw1, dw9, dw10;
>> -} cnl_procmon_values[NUM_CNL_PROCMON] = {
>> - [CNL_PROCMON_IDX(VOLTAGE_INFO_0_85V | PROCESS_INFO_DOT_0)] =
>> - { .dw1 = 0x00 << 16, .dw9 = 0x62AB67BB, .dw10 = 0x51914F96, },
>> - [CNL_PROCMON_IDX(VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_0)] =
>> - { .dw1 = 0x00 << 16, .dw9 = 0x86E172C7, .dw10 = 0x77CA5EAB, },
>> - [CNL_PROCMON_IDX(VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_1)] =
>> - { .dw1 = 0x00 << 16, .dw9 = 0x93F87FE1, .dw10 = 0x8AE871C5, },
>> - [CNL_PROCMON_IDX(VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_0)] =
>> - { .dw1 = 0x00 << 16, .dw9 = 0x98FA82DD, .dw10 = 0x89E46DC1, },
>> - [CNL_PROCMON_IDX(VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_1)] =
>> - { .dw1 = 0x44 << 16, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
>> +} cnl_procmon_values[] = {
>> + [PROCMON_0_85V_DOT_0] =
>> + { .dw1 = 0x, .dw9 = 0x62AB67BB, .dw10 = 0x51914F96, },
>> + [PROCMON_0_95V_DOT_0] =
>> + { .dw1 = 0x, .dw9 = 0x86E172C7, .dw10 = 0x77CA5EAB, },
>> + [PROCMON_0_95V_DOT_1] =
>> + { .dw1 = 0x, .dw9 = 0x93F87FE1, .dw10 = 0x8AE871C5, },
>> + [PROCMON_1_05V_DOT_0] =
>> + { .dw1 = 0x, .dw9 = 0x98FA82DD, .dw10 = 0x89E46DC1, },
>> + [PROCMON_1_05V_DOT_1] =
>> + { .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
>>  };
>>
>>  static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool 
>> resume)
>> @@ -2747,9 +2750,25 @@ static void cnl_display_core_init(struct 
>> drm_i915_private *dev_priv, bool resume
>>   I915_WRITE(CHICKEN_MISC_2, val);
>>
>>   val = I915_READ(CNL_PORT_COMP_DW3);
>> - procmon = _procmon_values[CNL_PROCMON_IDX(val)];
>> -
>> - WARN_ON(procmon->dw10 == 0);
>> + switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
>> + default:
>> + MISSING_CASE(val);
>> + case VOLTAGE_INFO_0_85V | PROCESS_INFO_DOT_0:
>> + procmon = _procmon_values[PROCMON_0_85V_DOT_0];
>> + break;
>> + case VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_0:
>> + procmon = _procmon_values[PROCMON_0_95V_DOT_0];
>> + break;
>> + case VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_1:
>> + procmon = _procmon_values[PROCMON_0_95V_DOT_1];
>> + break;
>> + case VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_0:
>> + procmon = _procmon_values[PROCMON_1_05V_DOT_0];
>> + break;
>> + case VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_1:
>> + procmon = _procmon_values[PROCMON_1_05V_DOT_1];
>> + break;
>> + }
>>
>>   val = I915_READ(CNL_PORT_COMP_DW1);
>>   val &= ~((0xff << 16) | 0xff);
>> @@ -2784,9 +2803,6 @@ static void cnl_display_core_init(struct 
>> drm_i915_private *dev_priv, bool resume
>>   gen9_dbuf_enable(dev_priv);
>>  }
>>
>> -#undef CNL_PROCMON_IDX
>> -#undef NUM_CNL_PROCMON
>> -
>>  static void cnl_display_core_uninit(struct drm_i915_private *dev_priv)
>>  {
>>   struct i915_power_domains *power_domains = _priv->power_domains;
>> --
>> 2.13.2
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> 

Re: [Intel-gfx] [PATCH i-g-t 05/11] tests/perf: rework oa-exponent test

[Matthew Auld]

On 22 August 2017 at 15:56, Lionel Landwerlin
 wrote:
> On 10/08/17 14:15, Matthew Auld wrote:
>
> On 4 August 2017 at 12:20, Lionel Landwerlin
>  wrote:
>
> New issues that were discovered while making the tests work on Gen8+ :
>
>  - we need to measure timings between periodic reports and discard all
>other kind of reports
>
>  - it seems periodicity of the reports can be affected outside of RC6
>(frequency change), we can detect this by looking at the amount of
>clock cycles per timestamp deltas
>
> I think this would be easier to review if we split this into two patches...
>
> Also, somewhat worrying is that I've yet to see the oa-exponents test
> pass on my BDW machine.
>
> See here:
> https://paste.fedoraproject.org/paste/SmOw7eHEGOTjrLsvPVcZOw/raw
>
> Was your screen off?

I don't think so, same result with it on/off though. I'm guessing that
is passes for you then?

Here's the pastebin again, since the other one is now toast:
https://paste.fedoraproject.org/paste/tjSb4jPZ87sWjhj7qAD~UA/raw
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

[Chris Wilson]

Quoting Szwichtenberg, Radoslaw (2017-08-18 09:50:35)
> On Fri, 2017-08-18 at 08:54 +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-08-17 13:37:06)
> > > If we miss the current vblank because the gpu was busy, that may cause a
> > > jitter as the frame rate temporarily drops. We try to limit the impact
> > > of this by then boosting the GPU clock to deliver the frame as quickly
> > > as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
> > > frequency if we detect outstanding pageflips") but was never forward
> > > ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
> > > Rip out legacy page_flip completion/irq handling").
> > 
> >  
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=102199
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199
> > > Signed-off-by: Chris Wilson 
> > > Cc: Maarten Lankhorst 
> > > Cc: Ville Syrjälä 
> > > Cc: Daniel Vetter 
> > 
> > Tested-by: Lyude Paul 
> Reviewed-by: Radoslaw Szwichtenberg 

Added the blurb to explain itself better and pushed to paper over the
miserable UX performance.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Don't give up waiting on INVALID_MODE

[Shashank Sharma]

Our current logic to read LSPCON's current mode, stops retries and
breaks wait-loop, if it gets LSPCON_MODE_INVALID as return from the
core function. This doesn't allow us to try reading the mode again.

This patch removes this condition and allows retries reading
the currnt mode until timeout.

This also fixes/prevents some of the noise in form of debug messages
while running IGT CI test cases.

V2: rebase, added r-b
V2: changed some debug message levels from debug->error and
error->debug in lspcon_get_current_mode function.

Cc: Imre Deak 
Cc: Daniel Vetter 

Reviewed-by: Imre Deak 
Signed-off-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_lspcon.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 8413a4c..0a61c0d 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -106,7 +106,7 @@ static enum drm_lspcon_mode lspcon_get_current_mode(struct 
intel_lspcon *lspcon)
struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
 
if (drm_lspcon_get_mode(adapter, _mode)) {
-   DRM_ERROR("Error reading LSPCON mode\n");
+   DRM_DEBUG_KMS("Error reading LSPCON mode\n");
return DRM_LSPCON_MODE_INVALID;
}
return current_mode;
@@ -118,16 +118,15 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct 
intel_lspcon *lspcon,
enum drm_lspcon_mode current_mode;
 
current_mode = lspcon_get_current_mode(lspcon);
-   if (current_mode == mode || current_mode == DRM_LSPCON_MODE_INVALID)
+   if (current_mode == mode)
goto out;
 
DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
  lspcon_mode_name(mode));
 
-   wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode ||
-current_mode == DRM_LSPCON_MODE_INVALID, 100);
+   wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
if (current_mode != mode)
-   DRM_DEBUG_KMS("LSPCON mode hasn't settled\n");
+   DRM_ERROR("LSPCON mode hasn't settled\n");
 
 out:
DRM_DEBUG_KMS("Current LSPCON mode %s\n",
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm: Add retries for dp dual mode read

[Shashank Sharma]

From the CI builds, its been observed that during a driver
reload/insert, dp dual mode read function sometimes fails to
read from dual mode devices (like LSPCON) over i2c-over-aux
channel.

This patch:
- adds some delay and few retries, allowing a scope for these
  devices to settle down and respond.
- changes one error log's level from ERROR->DEBUG as we want
  to call it an error only after all the retries are exhausted.

Cc: Ville Syrjala 
Cc: Imre Deak 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 80e62f6..13f67a36 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -75,8 +75,15 @@ ssize_t drm_dp_dual_mode_read(struct i2c_adapter *adapter,
},
};
int ret;
+   int retry;
+
+   for (retry = 5; ; ) {
+   ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
+   if (ret > 0 || !retry--)
+   break;
+   usleep_range(500, 1000);
+   }
 
-   ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
if (ret < 0)
return ret;
if (ret != ARRAY_SIZE(msgs))
@@ -420,7 +427,7 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
, sizeof(data));
if (ret < 0) {
-   DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+   DRM_DEBUG_KMS("LSPCON read(0x80, 0x41) failed\n");
return -EFAULT;
}
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/2] Add retries for dp dual mode reads

[Shashank Sharma]

Some of the DP dual mode devices (like LSPCON) need some time
to settle down, on specific platfomrs. Its been observed during
IGT CI runs that some of the KBL boards show some i2c-over-aux
failures when driver module is re-inserted or re-loaded.

This patch series adds some retries at various dp_dual_mode
helper functions, to allow these specofic devices to settle
down, and adjusts debug levels for failure messages.

Shashank Sharma (2):
  drm: Add retries for dp dual mode read
  drm/i915: Don't give up waiting on INVALID_MODE

 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
 drivers/gpu/drm/i915/intel_lspcon.c   |  9 -
 2 files changed, 15 insertions(+), 8 deletions(-)

-- 
2.7.4

___
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: Boost GPU clocks if we miss the pageflip's vblank (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Boost GPU clocks if we miss the pageflip's vblank (rev2)
URL   : https://patchwork.freedesktop.org/series/28921/
State : success

== Summary ==

Series 28921v2 drm/i915: Boost GPU clocks if we miss the pageflip's vblank
https://patchwork.freedesktop.org/api/1.0/series/28921/revisions/2/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:461s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:437s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:366s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:555s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:253s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:520s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:519s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:435s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:609s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:448s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:508s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:499s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:485s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:596s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:602s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:528s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:466s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:484s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:445s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:502s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:552s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:407s

3b36d5588ab5d02f450a598f807df0b9a19e1590 drm-tip: 2017y-08m-22d-15h-04m-54s UTC 
integration manifest
0190e3ff30c3 drm/i915: Boost GPU clocks if we miss the pageflip's vblank

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5462/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Add retries for lspcon status check

[Sharma, Shashank]

Regards

Shashank


On 8/22/2017 8:57 PM, Jani Nikula wrote:

On Tue, 22 Aug 2017, Shashank Sharma  wrote:

It's an observation during some CI tests that few LSPCON chips
respond slow while system is under load, and need some delay
while reading current mode status using i2c-over-aux channel.

This patch:
- Adds few retries and delays before declaring a read
   failure from LSPCON hardware.
- Changes the debug level of the print from ERROR->DEBUG
   whereas another patch in I915 will add an ERROR message
   from the caller when we have timed out all our limits.

V2: addressed review comments from Imre, and added r-b
 - use int instead of u8 for counter
 - use for loop instead of do...while();
V3: Rebase

Cc: Ville Syrjala 
Cc: Imre Deak 

Reviewed-by: Imre Deak 
Signed-off-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 80e62f6..fc8c7ac 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -409,6 +409,7 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
enum drm_lspcon_mode *mode)
  {
u8 data;
+   int retry;
int ret = 0;
  
  	if (!mode) {

@@ -417,10 +418,17 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
}
  
  	/* Read Status: i2c over aux */

-   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
-   , sizeof(data));
+   for (retry = 5; ; retry--) {
+   ret = drm_dp_dual_mode_read(adapter,
+   DP_DUAL_MODE_LSPCON_CURRENT_MODE,
+   , sizeof(data));
+   if (!ret || !retry)
+   break;
+   usleep_range(500, 1000);
+   }

Sorry, but that looks like a programming quiz to me. At most how many
time does drm_dp_dual_mode_read() get called?
Yes, you are correct, the loop gets called 6 times, in the initial 
version of this code, I had the condition
to be if (!ret || !--retry) break; which was serving the purpose of 6 
calls to drm_dp_dual_mode_read()

but only 5 delays. But later I moved some code, and messed with the logic.

I will modify this.


With this, for example, the C programmer's spine tells you "six times"
for the paradigm for loop before you even really stop to think about it:

for (try = 0; try < 6; try++) {
if (try)
usleep_range(500, 1000);
 ret = drm_dp_dual_mode_read();
 if (!ret)
break;
 }

BR,
Jani.


PS. I'm left wondering if "retry = 5" was there to emphasize that
there's one try and five *retries*.
Actually, the aim was to do 6 call to drm_dp_dual_mode_read() but add 
only 5 delays, as I wanted
the first read also in the loop. But as you rightly mention, the latest 
loop was not good enough.


- Shashank




+
if (ret < 0) {
-   DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+   DRM_DEBUG_KMS("LSPCON read(0x80, 0x41) failed\n");
return -EFAULT;
}


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

[Chris Wilson]

If we miss the current vblank because the gpu was busy, that may cause a
jitter as the frame rate temporarily drops. We try to limit the impact
of this by then boosting the GPU clock to deliver the frame as quickly
as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
frequency if we detect outstanding pageflips") but was never forward
ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
Rip out legacy page_flip completion/irq handling").

One of the most typical use-cases for this is a mostly idle desktop.
Rendering one frame of the desktop's frontbuffer can easily be
accomplished by the GPU running at low frequency, but often exceeds
the time budget of the desktop compositor. The result is that animations
such as opening the menu, doing a fullscreen switch, or even just trying
to move a window around are slow and jerky. We need to respond within a
frame to give the best impression of a smooth UX, as a compromise we
instead respond if that first frame misses its goal. The result should
be a near-imperceivable initial delay and a smooth animation even
starting from idle. The cost, as ever, is that we spend more power than
is strictly necessary as we overestimate the required GPU frequency and
then try to ramp down.

This of course is reactionary, too little, too late; nevertheless it is
surprisingly effective.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199
Signed-off-by: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20170817123706.6777-1-ch...@chris-wilson.co.uk
Tested-by: Lyude Paul 
Reviewed-by: Radoslaw Szwichtenberg 
---
 drivers/gpu/drm/i915/intel_display.c | 62 
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 drivers/gpu/drm/i915/intel_pm.c  | 42 ++--
 3 files changed, 65 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3b95cf953335..ad74d1d11dbe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12636,6 +12636,58 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.set_crc_source = intel_crtc_set_crc_source,
 };
 
+struct wait_rps_boost {
+   struct wait_queue_entry wait;
+
+   struct drm_crtc *crtc;
+   struct drm_i915_gem_request *request;
+};
+
+static int do_rps_boost(struct wait_queue_entry *_wait,
+   unsigned mode, int sync, void *key)
+{
+   struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait);
+   struct drm_i915_gem_request *rq = wait->request;
+
+   gen6_rps_boost(rq, NULL);
+   i915_gem_request_put(rq);
+
+   drm_crtc_vblank_put(wait->crtc);
+
+   list_del(>wait.entry);
+   kfree(wait);
+   return 1;
+}
+
+static void add_rps_boost_after_vblank(struct drm_crtc *crtc,
+  struct dma_fence *fence)
+{
+   struct wait_rps_boost *wait;
+
+   if (!dma_fence_is_i915(fence))
+   return;
+
+   if (INTEL_GEN(to_i915(crtc->dev)) < 6)
+   return;
+
+   if (drm_crtc_vblank_get(crtc))
+   return;
+
+   wait = kmalloc(sizeof(*wait), GFP_KERNEL);
+   if (!wait) {
+   drm_crtc_vblank_put(crtc);
+   return;
+   }
+
+   wait->request = to_request(dma_fence_get(fence));
+   wait->crtc = crtc;
+
+   wait->wait.func = do_rps_boost;
+   wait->wait.flags = 0;
+
+   add_wait_queue(drm_crtc_vblank_waitqueue(crtc), >wait);
+}
+
 /**
  * intel_prepare_plane_fb - Prepare fb for usage on plane
  * @plane: drm plane to prepare for
@@ -12733,12 +12785,22 @@ intel_prepare_plane_fb(struct drm_plane *plane,
return ret;
 
if (!new_state->fence) { /* implicit fencing */
+   struct dma_fence *fence;
+
ret = 
i915_sw_fence_await_reservation(_state->commit_ready,
  obj->resv, NULL,
  false, I915_FENCE_TIMEOUT,
  GFP_KERNEL);
if (ret < 0)
return ret;
+
+   fence = reservation_object_get_excl_rcu(obj->resv);
+   if (fence) {
+   add_rps_boost_after_vblank(new_state->crtc, fence);
+   dma_fence_put(fence);
+   }
+   } else {
+   add_rps_boost_after_vblank(new_state->crtc, new_state->fence);
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2940d393ecfd..34b5fc190411 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ 

Re: [Intel-gfx] [PATCH 1/3] drm: Add retries for lspcon status check

[Jani Nikula]

On Tue, 22 Aug 2017, Shashank Sharma  wrote:
> It's an observation during some CI tests that few LSPCON chips
> respond slow while system is under load, and need some delay
> while reading current mode status using i2c-over-aux channel.
>
> This patch:
> - Adds few retries and delays before declaring a read
>   failure from LSPCON hardware.
> - Changes the debug level of the print from ERROR->DEBUG
>   whereas another patch in I915 will add an ERROR message
>   from the caller when we have timed out all our limits.
>
> V2: addressed review comments from Imre, and added r-b
> - use int instead of u8 for counter
> - use for loop instead of do...while();
> V3: Rebase
>
> Cc: Ville Syrjala 
> Cc: Imre Deak 
>
> Reviewed-by: Imre Deak 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 80e62f6..fc8c7ac 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -409,6 +409,7 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>   enum drm_lspcon_mode *mode)
>  {
>   u8 data;
> + int retry;
>   int ret = 0;
>  
>   if (!mode) {
> @@ -417,10 +418,17 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>   }
>  
>   /* Read Status: i2c over aux */
> - ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
> - , sizeof(data));
> + for (retry = 5; ; retry--) {
> + ret = drm_dp_dual_mode_read(adapter,
> + DP_DUAL_MODE_LSPCON_CURRENT_MODE,
> + , sizeof(data));
> + if (!ret || !retry)
> + break;
> + usleep_range(500, 1000);
> + }

Sorry, but that looks like a programming quiz to me. At most how many
time does drm_dp_dual_mode_read() get called?

With this, for example, the C programmer's spine tells you "six times"
for the paradigm for loop before you even really stop to think about it:

for (try = 0; try < 6; try++) {
if (try)
usleep_range(500, 1000);
ret = drm_dp_dual_mode_read();
if (!ret)
break;
}

BR,
Jani.


PS. I'm left wondering if "retry = 5" was there to emphasize that
there's one try and five *retries*.



> +
>   if (ret < 0) {
> - DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
> + DRM_DEBUG_KMS("LSPCON read(0x80, 0x41) failed\n");
>   return -EFAULT;
>   }

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/23] huge gtt pages

[Matthew Auld]

On 22 August 2017 at 15:23, Chris Wilson  wrote:
> Quoting Chris Wilson (2017-08-22 15:21:10)
>> Quoting Matthew Auld (2017-08-21 19:34:40)
>> > Some more improvements as per Chris' comments.
>> >
>> > Matthew Auld (23):
>> >   mm/shmem: introduce shmem_file_setup_with_mnt
>> >   drm/i915: introduce simple gemfs
>> >   drm/i915/gemfs: enable THP
>> >   drm/i915: introduce page_size_mask to dev_info
>> >   drm/i915: push set_pages down to the callers
>> >   drm/i915: introduce page_size members
>> >   drm/i915: introduce vm set_pages/clear_pages
>> >   drm/i915: align the vma start to the largest gtt page size
>> >   drm/i915: align 64K objects to 2M
>> >   drm/i915: enable IPS bit for 64K pages
>> >   drm/i915: disable GTT cache for 2M/1G pages
>> >   drm/i915: support 1G pages for the 48b PPGTT
>> >   drm/i915: support 2M pages for the 48b PPGTT
>> >   drm/i915: add support for 64K scratch page
>> >   drm/i915: support 64K pages for the 48b PPGTT
>> >   drm/i915: accurate page size tracking for the ppgtt
>> >   drm/i915/debugfs: include some gtt page size metrics
>> >   drm/i915/selftests: huge page tests
>> >   drm/i915/selftests: mix huge pages
>> >   drm/i915: disable platform support for vGPU huge gtt pages
>> >   drm/i915: enable platform support for 64K pages
>> >   drm/i915: enable platform support for 2M pages
>> >   drm/i915: enable platform support for 1G pages
>>
>> Ok, looking good. I keep pushing off the selftest review, sorry. I did
>> start going through it and felt that it could do with a lot more
>> permutations of pages sizes within an object to try and exercise the
>> different boundaries and levels.

Fair enough, I'll try to come up with something better.

> And the other pencilled in suggestion I have is that you grab the
> THP/memfd work and put together a userptr igt that can allocate and
> utilize huge pages. For that we will need a I915_PARAM to report the
> supported pages sizes (and then have to mask that against the THP
> supported pages sizes).

Yup, on my TODO.

> -Chris
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Add retries for DP dual mode devices

[Patchwork]

== Series Details ==

Series: Add retries for DP dual mode devices
URL   : https://patchwork.freedesktop.org/series/29146/
State : success

== Summary ==

Series 29146v1 Add retries for DP dual mode devices
https://patchwork.freedesktop.org/api/1.0/series/29146/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-kbl-7260u) fdo#102359
Test gem_sync:
Subgroup basic-store-all:
incomplete -> PASS   (fi-kbl-7260u) fdo#102360

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#102359 https://bugs.freedesktop.org/show_bug.cgi?id=102359
fdo#102360 https://bugs.freedesktop.org/show_bug.cgi?id=102360

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:454s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:445s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:555s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:524s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:517s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:446s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:610s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:452s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:425s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:562s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:524s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:607s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:627s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:525s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:471s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:496s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:445s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:513s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:551s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:411s

b9294399405b59609f76fe52af2d3e61f53e9f68 drm-tip: 2017y-08m-22d-13h-44m-53s UTC 
integration manifest
f07a7b9a2e43 drm: Add retries for dp dual mode read
718a10c7d844 drm/i915: Don't give up waiting on INVALID_MODE
198105976bb9 drm: Add retries for lspcon status check

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5461/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/8] drm/i915: Make infoframe code available to (e)DP ports

[Ville Syrjälä]

On Fri, Aug 18, 2017 at 04:49:50PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> A rebased reposting of the dig_port infoframe series.
> 
> Notable changes since last time:
> * Dealt with the new intel_sdvo_connector_state
> * Annotated the SDP types with the DP spec version information
> * Fixed the kernel docs for the PSR enable/disable funcs
> 
> Ville Syrjälä (8):
>   drm/dp: Add defines for DP SDP types

Pushed this one to to drm-misc-next

>   drm/i915: Check has_infoframes when enabling infoframes
>   drm/i915: Disable infoframes when shutting down DDI HDMI
>   drm/i915: Move infoframe vfuncs into intel_digital_port
>   drm/i915: Init infoframe vfuncs for DP encoders as well
>   drm/i915: Plumb crtc_state to PSR enable/disable
>   drm/i915: Constify states passed to enable/disable/etc. encoder hooks

and these to dinq. Thanks for the reviews.

>   drm/i915: Remove mostly duplicated video DIP handling from PSR code

This one needs to wait for a drm-misc backmerge.

> 
>  drivers/gpu/drm/i915/intel_crt.c|  22 ++---
>  drivers/gpu/drm/i915/intel_ddi.c|  70 --
>  drivers/gpu/drm/i915/intel_dp.c |  71 +++---
>  drivers/gpu/drm/i915/intel_dp_mst.c |  16 ++--
>  drivers/gpu/drm/i915/intel_drv.h|  60 ++--
>  drivers/gpu/drm/i915/intel_dsi.c|  22 ++---
>  drivers/gpu/drm/i915/intel_dvo.c|  12 +--
>  drivers/gpu/drm/i915/intel_hdmi.c   | 183 
> 
>  drivers/gpu/drm/i915/intel_lvds.c   |  24 ++---
>  drivers/gpu/drm/i915/intel_psr.c| 118 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c   |  40 
>  drivers/gpu/drm/i915/intel_tv.c |  14 +--
>  include/drm/drm_dp_helper.h |  12 +++
>  13 files changed, 343 insertions(+), 321 deletions(-)
> 
> -- 
> 2.13.0

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Add retries for lspcon status check

[Sharma, Shashank]

Regards

Shashank


On 8/22/2017 8:24 PM, Imre Deak wrote:

On Tue, Aug 22, 2017 at 08:23:49PM +0530, Shashank Sharma wrote:

It's an observation during some CI tests that few LSPCON chips
respond slow while system is under load, and need some delay
while reading current mode status using i2c-over-aux channel.

This patch:
- Adds few retries and delays before declaring a read
   failure from LSPCON hardware.
- Changes the debug level of the print from ERROR->DEBUG
   whereas another patch in I915 will add an ERROR message
   from the caller when we have timed out all our limits.

V2: addressed review comments from Imre, and added r-b
 - use int instead of u8 for counter
 - use for loop instead of do...while();
V3: Rebase

Cc: Ville Syrjala 
Cc: Imre Deak 

Reviewed-by: Imre Deak 
Signed-off-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 80e62f6..fc8c7ac 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -409,6 +409,7 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
enum drm_lspcon_mode *mode)
  {
u8 data;
+   int retry;
int ret = 0;
  
  	if (!mode) {

@@ -417,10 +418,17 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
}
  
  	/* Read Status: i2c over aux */

-   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
-   , sizeof(data));
+   for (retry = 5; ; retry--) {
+   ret = drm_dp_dual_mode_read(adapter,
+   DP_DUAL_MODE_LSPCON_CURRENT_MODE,
+   , sizeof(data));

Why do we still need the retry here with patch 3/3?
The only reason I can think of would be I am paranoid :) ? I was 
thinking of going with this one first and see
the CI results, and then later remove and optimize. But I guess you are 
right, this would be too many retries

here, and I should do it other way around.

- Shashank

+   if (!ret || !retry)
+   break;
+   usleep_range(500, 1000);
+   }
+
if (ret < 0) {
-   DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+   DRM_DEBUG_KMS("LSPCON read(0x80, 0x41) failed\n");
return -EFAULT;
}
  
--

2.7.4



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 05/11] tests/perf: rework oa-exponent test

[Lionel Landwerlin]

On 10/08/17 14:15, Matthew Auld wrote:

On 4 August 2017 at 12:20, Lionel Landwerlin
  wrote:

New issues that were discovered while making the tests work on Gen8+ :

  - we need to measure timings between periodic reports and discard all
other kind of reports

  - it seems periodicity of the reports can be affected outside of RC6
(frequency change), we can detect this by looking at the amount of
clock cycles per timestamp deltas

I think this would be easier to review if we split this into two patches...

Also, somewhat worrying is that I've yet to see the oa-exponents test
pass on my BDW machine.

See here:
https://paste.fedoraproject.org/paste/SmOw7eHEGOTjrLsvPVcZOw/raw


Was your screen off?

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Add retries for lspcon status check

[Imre Deak]

On Tue, Aug 22, 2017 at 08:23:49PM +0530, Shashank Sharma wrote:
> It's an observation during some CI tests that few LSPCON chips
> respond slow while system is under load, and need some delay
> while reading current mode status using i2c-over-aux channel.
> 
> This patch:
> - Adds few retries and delays before declaring a read
>   failure from LSPCON hardware.
> - Changes the debug level of the print from ERROR->DEBUG
>   whereas another patch in I915 will add an ERROR message
>   from the caller when we have timed out all our limits.
> 
> V2: addressed review comments from Imre, and added r-b
> - use int instead of u8 for counter
> - use for loop instead of do...while();
> V3: Rebase
> 
> Cc: Ville Syrjala 
> Cc: Imre Deak 
> 
> Reviewed-by: Imre Deak 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 80e62f6..fc8c7ac 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -409,6 +409,7 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>   enum drm_lspcon_mode *mode)
>  {
>   u8 data;
> + int retry;
>   int ret = 0;
>  
>   if (!mode) {
> @@ -417,10 +418,17 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>   }
>  
>   /* Read Status: i2c over aux */
> - ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
> - , sizeof(data));
> + for (retry = 5; ; retry--) {
> + ret = drm_dp_dual_mode_read(adapter,
> + DP_DUAL_MODE_LSPCON_CURRENT_MODE,
> + , sizeof(data));

Why do we still need the retry here with patch 3/3?

> + if (!ret || !retry)
> + break;
> + usleep_range(500, 1000);
> + }
> +
>   if (ret < 0) {
> - DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
> + DRM_DEBUG_KMS("LSPCON read(0x80, 0x41) failed\n");
>   return -EFAULT;
>   }
>  
> -- 
> 2.7.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/3] Add retries for DP dual mode devices

[Shashank Sharma]

Some of the DP dual mode devices (like LSPCON) need some time
to settle down, on specific platfomrs. Its been observed during
IGT CI runs that some of the KBL boards show some i2c-over-aux
failures when driver module is re-inserted or re-loaded.

This patch series adds some retries at various dp_dual_mode
helper functions, to allow these specofic devices to settle
down.

First two patches were separately reviewed here:
https://patchwork.freedesktop.org/series/28684/

Re-publishing them here to make this series with
an agenda :)

Shashank Sharma (3):
  drm: Add retries for lspcon status check
  drm/i915: Don't give up waiting on INVALID_MODE
  drm: Add retries for dp dual mode read

 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 23 +++
 drivers/gpu/drm/i915/intel_lspcon.c   |  5 ++---
 2 files changed, 21 insertions(+), 7 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm: Add retries for lspcon status check

[Shashank Sharma]

It's an observation during some CI tests that few LSPCON chips
respond slow while system is under load, and need some delay
while reading current mode status using i2c-over-aux channel.

This patch:
- Adds few retries and delays before declaring a read
  failure from LSPCON hardware.
- Changes the debug level of the print from ERROR->DEBUG
  whereas another patch in I915 will add an ERROR message
  from the caller when we have timed out all our limits.

V2: addressed review comments from Imre, and added r-b
- use int instead of u8 for counter
- use for loop instead of do...while();
V3: Rebase

Cc: Ville Syrjala 
Cc: Imre Deak 

Reviewed-by: Imre Deak 
Signed-off-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 80e62f6..fc8c7ac 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -409,6 +409,7 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
enum drm_lspcon_mode *mode)
 {
u8 data;
+   int retry;
int ret = 0;
 
if (!mode) {
@@ -417,10 +418,17 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
}
 
/* Read Status: i2c over aux */
-   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
-   , sizeof(data));
+   for (retry = 5; ; retry--) {
+   ret = drm_dp_dual_mode_read(adapter,
+   DP_DUAL_MODE_LSPCON_CURRENT_MODE,
+   , sizeof(data));
+   if (!ret || !retry)
+   break;
+   usleep_range(500, 1000);
+   }
+
if (ret < 0) {
-   DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+   DRM_DEBUG_KMS("LSPCON read(0x80, 0x41) failed\n");
return -EFAULT;
}
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: Don't give up waiting on INVALID_MODE

[Shashank Sharma]

Our current logic to read LSPCON's current mode, stops retries and
breaks wait-loop, if it gets LSPCON_MODE_INVALID as return from the
core function. This doesn't allow us to try reading the mode again.

This patch removes this condition and allows retries reading
the currnt mode until timeout.

This also fixes/prevents some of the noise in form of debug messages
while running IGT CI test cases.

V2: rebase, added r-b
V2: changed some debug message levels from debug->error and
error->debug in lspcon_get_current_mode function.

Cc: Imre Deak 
Cc: Daniel Vetter 

Reviewed-by: Imre Deak 
Signed-off-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_lspcon.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 8413a4c..0a61c0d 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -106,7 +106,7 @@ static enum drm_lspcon_mode lspcon_get_current_mode(struct 
intel_lspcon *lspcon)
struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
 
if (drm_lspcon_get_mode(adapter, _mode)) {
-   DRM_ERROR("Error reading LSPCON mode\n");
+   DRM_DEBUG_KMS("Error reading LSPCON mode\n");
return DRM_LSPCON_MODE_INVALID;
}
return current_mode;
@@ -118,16 +118,15 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct 
intel_lspcon *lspcon,
enum drm_lspcon_mode current_mode;
 
current_mode = lspcon_get_current_mode(lspcon);
-   if (current_mode == mode || current_mode == DRM_LSPCON_MODE_INVALID)
+   if (current_mode == mode)
goto out;
 
DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
  lspcon_mode_name(mode));
 
-   wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode ||
-current_mode == DRM_LSPCON_MODE_INVALID, 100);
+   wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
if (current_mode != mode)
-   DRM_DEBUG_KMS("LSPCON mode hasn't settled\n");
+   DRM_ERROR("LSPCON mode hasn't settled\n");
 
 out:
DRM_DEBUG_KMS("Current LSPCON mode %s\n",
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm: Add retries for dp dual mode read

[Shashank Sharma]

From the CI builds, its been observed that during a driver
reload/insert, dp dual mode read function sometimes fails to
read from dual mode devices (like LSPCON) over i2c-over-aux
channel. This patch adds some delay and few retries, allowing
a scope for these devices to settle down.

V3: Introduced this patch

Cc: Ville Syrjala 
Cc: Imre Deak 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index fc8c7ac..bb34ff8 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -75,8 +75,15 @@ ssize_t drm_dp_dual_mode_read(struct i2c_adapter *adapter,
},
};
int ret;
+   int retry;
+
+   for (retry = 5; ; retry--) {
+   ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
+   if (ret > 0 || !retry)
+   break;
+   usleep_range(500, 1000);
+   }
 
-   ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
if (ret < 0)
return ret;
if (ret != ARRAY_SIZE(msgs))
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make infoframe code available to (e)DP ports (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Make infoframe code available to (e)DP ports (rev4)
URL   : https://patchwork.freedesktop.org/series/8183/
State : success

== Summary ==

Series 8183v4 drm/i915: Make infoframe code available to (e)DP ports
https://patchwork.freedesktop.org/api/1.0/series/8183/revisions/4/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-kbl-7260u) fdo#102359
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7260u) fdo#102294
Test gem_sync:
Subgroup basic-store-all:
incomplete -> PASS   (fi-kbl-7260u)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l) fdo#101781
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#102359 https://bugs.freedesktop.org/show_bug.cgi?id=102359
fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:458s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:445s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:360s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:550s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:253s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:522s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:523s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:435s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:613s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:441s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:429s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:508s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:496s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:598s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:597s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:528s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:465s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:484s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:407s

b9294399405b59609f76fe52af2d3e61f53e9f68 drm-tip: 2017y-08m-22d-13h-44m-53s UTC 
integration manifest
b06660de54c3 drm/i915: Constify states passed to enable/disable/etc. encoder 
hooks
0e12378a555d drm/i915: Remove mostly duplicated video DIP handling from PSR code
602bdc151324 drm/i915: Plumb crtc_state to PSR enable/disable
734b56419361 drm/i915: Init infoframe vfuncs for DP encoders as well
5b5f004c8b4d drm/i915: Move infoframe vfuncs into intel_digital_port
1957a3ab6f08 drm/i915: Disable infoframes when shutting down DDI HDMI
c65c33650348 drm/i915: Check has_infoframes when enabling infoframes

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5460/
___
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/cnl: simplify cnl_procmon_values handling

[Ville Syrjälä]

On Mon, Aug 21, 2017 at 05:03:55PM -0700, Rodrigo Vivi wrote:
> From: Paulo Zanoni 
> 
> Make it a little less magical and a little simpler and more hardcoded
> so we don't end up with an array that's composed mostly of empty
> entries.
> 
> v2: Add an enum for the voltage+register values (Ville).
> 
> Signed-off-by: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 

For the series
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 58 
> +
>  1 file changed, 37 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index b66d8e136aa3..b7f4fbe7ae0d 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2707,24 +2707,27 @@ void bxt_display_core_uninit(struct drm_i915_private 
> *dev_priv)
>   usleep_range(10, 30);   /* 10 us delay per Bspec */
>  }
>  
> -#define CNL_PROCMON_IDX(val) \
> - (((val) & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) >> 
> VOLTAGE_INFO_SHIFT)
> -#define NUM_CNL_PROCMON \
> - (CNL_PROCMON_IDX(VOLTAGE_INFO_MASK | PROCESS_INFO_MASK) + 1)
> +enum {
> + PROCMON_0_85V_DOT_0,
> + PROCMON_0_95V_DOT_0,
> + PROCMON_0_95V_DOT_1,
> + PROCMON_1_05V_DOT_0,
> + PROCMON_1_05V_DOT_1,
> +};
>  
>  static const struct cnl_procmon {
>   u32 dw1, dw9, dw10;
> -} cnl_procmon_values[NUM_CNL_PROCMON] = {
> - [CNL_PROCMON_IDX(VOLTAGE_INFO_0_85V | PROCESS_INFO_DOT_0)] =
> - { .dw1 = 0x00 << 16, .dw9 = 0x62AB67BB, .dw10 = 0x51914F96, },
> - [CNL_PROCMON_IDX(VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_0)] =
> - { .dw1 = 0x00 << 16, .dw9 = 0x86E172C7, .dw10 = 0x77CA5EAB, },
> - [CNL_PROCMON_IDX(VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_1)] =
> - { .dw1 = 0x00 << 16, .dw9 = 0x93F87FE1, .dw10 = 0x8AE871C5, },
> - [CNL_PROCMON_IDX(VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_0)] =
> - { .dw1 = 0x00 << 16, .dw9 = 0x98FA82DD, .dw10 = 0x89E46DC1, },
> - [CNL_PROCMON_IDX(VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_1)] =
> - { .dw1 = 0x44 << 16, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
> +} cnl_procmon_values[] = {
> + [PROCMON_0_85V_DOT_0] =
> + { .dw1 = 0x, .dw9 = 0x62AB67BB, .dw10 = 0x51914F96, },
> + [PROCMON_0_95V_DOT_0] =
> + { .dw1 = 0x, .dw9 = 0x86E172C7, .dw10 = 0x77CA5EAB, },
> + [PROCMON_0_95V_DOT_1] =
> + { .dw1 = 0x, .dw9 = 0x93F87FE1, .dw10 = 0x8AE871C5, },
> + [PROCMON_1_05V_DOT_0] =
> + { .dw1 = 0x, .dw9 = 0x98FA82DD, .dw10 = 0x89E46DC1, },
> + [PROCMON_1_05V_DOT_1] =
> + { .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
>  };
>  
>  static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool 
> resume)
> @@ -2747,9 +2750,25 @@ static void cnl_display_core_init(struct 
> drm_i915_private *dev_priv, bool resume
>   I915_WRITE(CHICKEN_MISC_2, val);
>  
>   val = I915_READ(CNL_PORT_COMP_DW3);
> - procmon = _procmon_values[CNL_PROCMON_IDX(val)];
> -
> - WARN_ON(procmon->dw10 == 0);
> + switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
> + default:
> + MISSING_CASE(val);
> + case VOLTAGE_INFO_0_85V | PROCESS_INFO_DOT_0:
> + procmon = _procmon_values[PROCMON_0_85V_DOT_0];
> + break;
> + case VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_0:
> + procmon = _procmon_values[PROCMON_0_95V_DOT_0];
> + break;
> + case VOLTAGE_INFO_0_95V | PROCESS_INFO_DOT_1:
> + procmon = _procmon_values[PROCMON_0_95V_DOT_1];
> + break;
> + case VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_0:
> + procmon = _procmon_values[PROCMON_1_05V_DOT_0];
> + break;
> + case VOLTAGE_INFO_1_05V | PROCESS_INFO_DOT_1:
> + procmon = _procmon_values[PROCMON_1_05V_DOT_1];
> + break;
> + }
>  
>   val = I915_READ(CNL_PORT_COMP_DW1);
>   val &= ~((0xff << 16) | 0xff);
> @@ -2784,9 +2803,6 @@ static void cnl_display_core_init(struct 
> drm_i915_private *dev_priv, bool resume
>   gen9_dbuf_enable(dev_priv);
>  }
>  
> -#undef CNL_PROCMON_IDX
> -#undef NUM_CNL_PROCMON
> -
>  static void cnl_display_core_uninit(struct drm_i915_private *dev_priv)
>  {
>   struct i915_power_domains *power_domains = _priv->power_domains;
> -- 
> 2.13.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/23] huge gtt pages

[Chris Wilson]

Quoting Chris Wilson (2017-08-22 15:21:10)
> Quoting Matthew Auld (2017-08-21 19:34:40)
> > Some more improvements as per Chris' comments.
> > 
> > Matthew Auld (23):
> >   mm/shmem: introduce shmem_file_setup_with_mnt
> >   drm/i915: introduce simple gemfs
> >   drm/i915/gemfs: enable THP
> >   drm/i915: introduce page_size_mask to dev_info
> >   drm/i915: push set_pages down to the callers
> >   drm/i915: introduce page_size members
> >   drm/i915: introduce vm set_pages/clear_pages
> >   drm/i915: align the vma start to the largest gtt page size
> >   drm/i915: align 64K objects to 2M
> >   drm/i915: enable IPS bit for 64K pages
> >   drm/i915: disable GTT cache for 2M/1G pages
> >   drm/i915: support 1G pages for the 48b PPGTT
> >   drm/i915: support 2M pages for the 48b PPGTT
> >   drm/i915: add support for 64K scratch page
> >   drm/i915: support 64K pages for the 48b PPGTT
> >   drm/i915: accurate page size tracking for the ppgtt
> >   drm/i915/debugfs: include some gtt page size metrics
> >   drm/i915/selftests: huge page tests
> >   drm/i915/selftests: mix huge pages
> >   drm/i915: disable platform support for vGPU huge gtt pages
> >   drm/i915: enable platform support for 64K pages
> >   drm/i915: enable platform support for 2M pages
> >   drm/i915: enable platform support for 1G pages
> 
> Ok, looking good. I keep pushing off the selftest review, sorry. I did
> start going through it and felt that it could do with a lot more
> permutations of pages sizes within an object to try and exercise the
> different boundaries and levels. Everything else looks excellent, I just
> haven't yet put together my list of questions for the st...

And the other pencilled in suggestion I have is that you grab the
THP/memfd work and put together a userptr igt that can allocate and
utilize huge pages. For that we will need a I915_PARAM to report the
supported pages sizes (and then have to mask that against the THP
supported pages sizes).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/23] huge gtt pages

[Chris Wilson]

Quoting Matthew Auld (2017-08-21 19:34:40)
> Some more improvements as per Chris' comments.
> 
> Matthew Auld (23):
>   mm/shmem: introduce shmem_file_setup_with_mnt
>   drm/i915: introduce simple gemfs
>   drm/i915/gemfs: enable THP
>   drm/i915: introduce page_size_mask to dev_info
>   drm/i915: push set_pages down to the callers
>   drm/i915: introduce page_size members
>   drm/i915: introduce vm set_pages/clear_pages
>   drm/i915: align the vma start to the largest gtt page size
>   drm/i915: align 64K objects to 2M
>   drm/i915: enable IPS bit for 64K pages
>   drm/i915: disable GTT cache for 2M/1G pages
>   drm/i915: support 1G pages for the 48b PPGTT
>   drm/i915: support 2M pages for the 48b PPGTT
>   drm/i915: add support for 64K scratch page
>   drm/i915: support 64K pages for the 48b PPGTT
>   drm/i915: accurate page size tracking for the ppgtt
>   drm/i915/debugfs: include some gtt page size metrics
>   drm/i915/selftests: huge page tests
>   drm/i915/selftests: mix huge pages
>   drm/i915: disable platform support for vGPU huge gtt pages
>   drm/i915: enable platform support for 64K pages
>   drm/i915: enable platform support for 2M pages
>   drm/i915: enable platform support for 1G pages

Ok, looking good. I keep pushing off the selftest review, sorry. I did
start going through it and felt that it could do with a lot more
permutations of pages sizes within an object to try and exercise the
different boundaries and levels. Everything else looks excellent, I just
haven't yet put together my list of questions for the st...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/8] drm/i915: Disable infoframes when shutting down DDI HDMI

[ville . syrjala]

From: Ville Syrjälä 

Disabling the video DIP when shutting the port down seems like a good
idea.

Bspec says:
"When disabling both the DIP port and DIP transmission,
 first disable the port and then disable DIP."
and
"Restriction : GCP is only supported with HDMI when the bits per color is
 not equal to 8. GCP must be enabled prior to enabling TRANS_DDI_FUNC_CTL
 for HDMI with bits per color not equal to 8 and disabled after disabling
 TRANS_DDI_FUNC_CTL"

So let's do it in the .post_disable() hook.

v2: Remove double "dpms off" caused by rebase fail

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_ddi.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 07ced1044001..b0ff9cf3191c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2211,7 +2211,6 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
enum port port = intel_ddi_get_encoder_port(intel_encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
-   struct intel_dp *intel_dp = NULL;
int type = intel_encoder->type;
uint32_t val;
bool wait = false;
@@ -2219,7 +2218,8 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder,
/* old_crtc_state and old_conn_state are NULL when called from DP_MST */
 
if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
-   intel_dp = enc_to_intel_dp(encoder);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
}
 
@@ -2238,7 +2238,16 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder,
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
 
-   if (intel_dp) {
+   if (type == INTEL_OUTPUT_HDMI) {
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+
+   intel_hdmi->set_infoframes(encoder, false,
+  old_crtc_state, old_conn_state);
+   }
+
+   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
}
-- 
2.13.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 igt/pm_rpm: Use libc 'ftw' rather than opencoding our own filetree walk

[Patchwork]

== Series Details ==

Series: igt/pm_rpm: Use libc 'ftw' rather than opencoding our own filetree walk
URL   : https://patchwork.freedesktop.org/series/29141/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4524a8951348a31ae5dabfc4c69f2a835034ec3e tests: Introduce audio tests, starting 
with HDMI signal integrity

with latest DRM-Tip kernel build CI_DRM_2988
253e48c86352 drm-tip: 2017y-08m-22d-13h-04m-35s UTC integration manifest

Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-kbl-7260u) fdo#102295

fdo#102295 https://bugs.freedesktop.org/show_bug.cgi?id=102295

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:460s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:438s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:362s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:563s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:253s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:531s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:526s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:437s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:611s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:446s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:424s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:509s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7260u total:279  pass:267  dwarn:2   dfail:0   fail:0   skip:10  
time:495s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:483s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:598s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:601s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:524s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:445s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:507s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:552s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:406s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_84/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+

[Chris Wilson]

Quoting Lionel Landwerlin (2017-08-22 14:48:12)
> On 22/08/17 14:28, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2017-08-22 14:11:07)
> >> On 22/08/17 12:59, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2017-08-22 12:45:47)
>  On 08/08/17 15:21, Matthew Auld wrote:
> > On 4 August 2017 at 12:20, Lionel Landwerlin
> >  wrote:
> >> static void
> >> @@ -1336,6 +1504,66 @@ print_reports(uint32_t *oa_report0, uint32_t 
> >> *oa_report1, int fmt)
> >> }
> >>
> >> static void
> >> +print_report(uint32_t *report, int fmt)
> >> +{
> > I get an unused warning for this...
>  Useful for really precise debugging. Putting under ifdef
> >>> Does it interfere that much with normal testing, or you could dump extra
> >>> details on unexpected events? If it is useful at some point, you will be
> >>> wishing you had the details from CI. The beauty of igt_debug() (at least
> >>> when --debug is not used by defaul!) is that it does give us the
> >>> portmortem output of the last N lines (where N is ~256?) without
> >>> flooding ourselves with irrelevant messages.
> >>> -Chris
> >> The problem is that we get loads of reports.
> >> Most of the time you want to look at the deltas between them (which is
> >> what most igt_debug() are about), only occasionally the actual values
> >> (which is what this function dumps).
> > If you can't identify the right one to dump when you find the error, how
> > much is the cost of recording all the traces for a subtest and dumping
> > them compressed+encoded to the output? If we are only talking a few megs
> > of raw data and hope it compresses down to a few 100k, that's not too
> > unwieldy to include on stderr/whatever. All depends on how difficult it
> > will be to reproduce the eventual bug. Just my crystal ball is saying
> > that if you find print_report() useful, you will find it useful again in
> > the future where you may not even have access to the system.
> > -Chris
> >
> 
> My debugging experience has been the following :
> 
> - I have no idea what's wrong, put traces in different places and hope 
> to notice something fishy
> - There are now too many traces and taking too long to figure anything 
> from the logs
> 
> print_report is just a remaining utility function. I'm happy to drop it 
> from the patch if that's too contentious.

Oh definitely keep it, just thinking aloud about how hard it is to get
the right information from the CI farm, and that if you have already
found one particular bit of info useful my experience says to wire that
up and have it available for when the igt_assert fires.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] mm: Track actual nr_scanned during shrink_slab()

[Chris Wilson]

Some shrinkers may only be able to free a bunch of objects at a time, and
so free more than the requested nr_to_scan in one pass. Whilst other
shrinkers may find themselves even unable to scan as many objects as
they counted, and so underreport. Account for the extra freed/scanned
objects against the total number of objects we intend to scan, otherwise
we may end up penalising the slab far more than intended. Similarly,
we want to add the underperforming scan to the deferred pass so that we
try harder and harder in future passes.

v2: Andrew's shrinkctl->nr_scanned

Signed-off-by: Chris Wilson 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Hillf Danton 
Cc: Minchan Kim 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Shaohua Li 
Cc: linux...@kvack.org
---
 include/linux/shrinker.h | 7 +++
 mm/vmscan.c  | 7 ---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 4fcacd915d45..51d189615bda 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -18,6 +18,13 @@ struct shrink_control {
 */
unsigned long nr_to_scan;
 
+   /*
+* How many objects did scan_objects process?
+* This defaults to nr_to_scan before every call, but the callee
+* should track its actual progress.
+*/
+   unsigned long nr_scanned;
+
/* current node being shrunk (for NUMA aware shrinkers) */
int nid;
 
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a1af041930a6..339b8fc95fc9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -393,14 +393,15 @@ static unsigned long do_shrink_slab(struct shrink_control 
*shrinkctl,
unsigned long nr_to_scan = min(batch_size, total_scan);
 
shrinkctl->nr_to_scan = nr_to_scan;
+   shrinkctl->nr_scanned = nr_to_scan;
ret = shrinker->scan_objects(shrinker, shrinkctl);
if (ret == SHRINK_STOP)
break;
freed += ret;
 
-   count_vm_events(SLABS_SCANNED, nr_to_scan);
-   total_scan -= nr_to_scan;
-   scanned += nr_to_scan;
+   count_vm_events(SLABS_SCANNED, shrinkctl->nr_scanned);
+   total_scan -= shrinkctl->nr_scanned;
+   scanned += shrinkctl->nr_scanned;
 
cond_resched();
}
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Wire up shrinkctl->nr_scanned

[Chris Wilson]

shrink_slab() allows us to report back the number of objects we
successfully scanned (out of the target shrinkctl->nr_to_scan). As
report the number of pages owned by each GEM object as a separate item
to the shrinker, we cannot precisely control the number of shrinker
objects we scan on each pass; and indeed may free more than requested.
If we fail to tell the shrinker about the number of objects we process,
it will continue to hold a grudge against us as any objects left
unscanned are added to the next reclaim -- and so we will keep on
"unfairly" shrinking our own slab in comparison to other slabs.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Hillf Danton 
Cc: Minchan Kim 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Shaohua Li 
Cc: linux...@kvack.org
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem.c  |  4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 24 ++--
 5 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6bad53f89738..ed979cc6fb5d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4338,10 +4338,10 @@ i915_drop_caches_set(void *data, u64 val)
 
lockdep_set_current_reclaim_state(GFP_KERNEL);
if (val & DROP_BOUND)
-   i915_gem_shrink(dev_priv, LONG_MAX, I915_SHRINK_BOUND);
+   i915_gem_shrink(dev_priv, LONG_MAX, NULL, I915_SHRINK_BOUND);
 
if (val & DROP_UNBOUND)
-   i915_gem_shrink(dev_priv, LONG_MAX, I915_SHRINK_UNBOUND);
+   i915_gem_shrink(dev_priv, LONG_MAX, NULL, I915_SHRINK_UNBOUND);
 
if (val & DROP_SHRINK_ALL)
i915_gem_shrink_all(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b78605a9f1b5..c3299eaac1af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3752,6 +3752,7 @@ i915_gem_object_create_internal(struct drm_i915_private 
*dev_priv,
 /* i915_gem_shrinker.c */
 unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
  unsigned long target,
+ unsigned long *nr_scanned,
  unsigned flags);
 #define I915_SHRINK_PURGEABLE 0x1
 #define I915_SHRINK_UNBOUND 0x2
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2714898ff01..c06091718bb4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2339,7 +2339,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
goto err_sg;
}
 
-   i915_gem_shrink(dev_priv, 2 * page_count, *s++);
+   i915_gem_shrink(dev_priv, 2 * page_count, NULL, *s++);
cond_resched();
 
/* We've tried hard to allocate the memory by reaping
@@ -5037,7 +5037,7 @@ int i915_gem_freeze_late(struct drm_i915_private 
*dev_priv)
 * the objects as well, see i915_gem_freeze()
 */
 
-   i915_gem_shrink(dev_priv, -1UL, I915_SHRINK_UNBOUND);
+   i915_gem_shrink(dev_priv, -1UL, NULL, I915_SHRINK_UNBOUND);
i915_gem_drain_freed_objects(dev_priv);
 
spin_lock(_priv->mm.obj_lock);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b6d5f1c6ef5e..8394fc2a21eb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2062,7 +2062,7 @@ int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object 
*obj,
 */
GEM_BUG_ON(obj->mm.pages == pages);
} while (i915_gem_shrink(to_i915(obj->base.dev),
-obj->base.size >> PAGE_SHIFT,
+obj->base.size >> PAGE_SHIFT, NULL,
 I915_SHRINK_BOUND |
 I915_SHRINK_UNBOUND |
 I915_SHRINK_ACTIVE));
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index ee4df98f009d..c178a1c9ae47 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -198,6 +198,7 @@ static void __start_writeback(struct drm_i915_gem_object 
*obj)
  * i915_gem_shrink - Shrink buffer object caches
  * @dev_priv: i915 device
  * @target: amount of memory to make available, in pages
+ * @nr_scanned: optional output for number of pages 

Re: [Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+

[Lionel Landwerlin]

On 22/08/17 14:28, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-08-22 14:11:07)

On 22/08/17 12:59, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-08-22 12:45:47)

On 08/08/17 15:21, Matthew Auld wrote:

On 4 August 2017 at 12:20, Lionel Landwerlin
 wrote:

static void
@@ -1336,6 +1504,66 @@ print_reports(uint32_t *oa_report0, uint32_t 
*oa_report1, int fmt)
}

static void
+print_report(uint32_t *report, int fmt)
+{

I get an unused warning for this...

Useful for really precise debugging. Putting under ifdef

Does it interfere that much with normal testing, or you could dump extra
details on unexpected events? If it is useful at some point, you will be
wishing you had the details from CI. The beauty of igt_debug() (at least
when --debug is not used by defaul!) is that it does give us the
portmortem output of the last N lines (where N is ~256?) without
flooding ourselves with irrelevant messages.
-Chris

The problem is that we get loads of reports.
Most of the time you want to look at the deltas between them (which is
what most igt_debug() are about), only occasionally the actual values
(which is what this function dumps).

If you can't identify the right one to dump when you find the error, how
much is the cost of recording all the traces for a subtest and dumping
them compressed+encoded to the output? If we are only talking a few megs
of raw data and hope it compresses down to a few 100k, that's not too
unwieldy to include on stderr/whatever. All depends on how difficult it
will be to reproduce the eventual bug. Just my crystal ball is saying
that if you find print_report() useful, you will find it useful again in
the future where you may not even have access to the system.
-Chris



My debugging experience has been the following :

- I have no idea what's wrong, put traces in different places and hope 
to notice something fishy
- There are now too many traces and taking too long to figure anything 
from the logs


print_report is just a remaining utility function. I'm happy to drop it 
from the patch if that's too contentious.


-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 01/11] tests/perf: make stream_fd a global variable

[Lionel Landwerlin]

On 04/08/17 12:39, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-08-04 12:20:30)

When debugging unstable tests on new platforms we currently we don't
cleanup everything well in between different tests. Since only a
single OA stream fd can be opened at a time, having the stream_fd as a
global variable helps us cleanup the state between tests.

We don't have constructors/destructors per-se, but we do have
igt_subtest_group which can contain fixtures to alloc/dealloc resources.

A more igt-esque approach would be

igt_subtest_group {
int perf_fd = -1;

igt_fixture {
perf_fd = __perf_open();
}

igt_subtest
... How ever many you want in the one group

igt_fixture {
__perf_close(perf_fd);
}
}

Just my 2c. You can of course join the petition for more igt
infrastructure to make writing robust tests easier... :)
-Chris



Where do I sign? :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+

[Chris Wilson]

Quoting Lionel Landwerlin (2017-08-22 14:11:07)
> On 22/08/17 12:59, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2017-08-22 12:45:47)
> >> On 08/08/17 15:21, Matthew Auld wrote:
> >>> On 4 August 2017 at 12:20, Lionel Landwerlin
> >>>  wrote:
> static void
>  @@ -1336,6 +1504,66 @@ print_reports(uint32_t *oa_report0, uint32_t 
>  *oa_report1, int fmt)
> }
> 
> static void
>  +print_report(uint32_t *report, int fmt)
>  +{
> >>> I get an unused warning for this...
> >> Useful for really precise debugging. Putting under ifdef
> > Does it interfere that much with normal testing, or you could dump extra
> > details on unexpected events? If it is useful at some point, you will be
> > wishing you had the details from CI. The beauty of igt_debug() (at least
> > when --debug is not used by defaul!) is that it does give us the
> > portmortem output of the last N lines (where N is ~256?) without
> > flooding ourselves with irrelevant messages.
> > -Chris
> 
> The problem is that we get loads of reports.
> Most of the time you want to look at the deltas between them (which is 
> what most igt_debug() are about), only occasionally the actual values 
> (which is what this function dumps).

If you can't identify the right one to dump when you find the error, how
much is the cost of recording all the traces for a subtest and dumping
them compressed+encoded to the output? If we are only talking a few megs
of raw data and hope it compresses down to a few 100k, that's not too
unwieldy to include on stderr/whatever. All depends on how difficult it
will be to reproduce the eventual bug. Just my crystal ball is saying
that if you find print_report() useful, you will find it useful again in
the future where you may not even have access to the system.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Release driver tracking before making the object available again

[Joonas Lahtinen]

+ Sean

On Mon, 2017-08-21 at 18:16 +0200, Daniel Vetter wrote:
> On Sat, Aug 19, 2017 at 01:05:58PM +0100, Chris Wilson wrote:
> > This is the same bug as we fixed in commit f6cd7daecff5 ("drm: Release
> > driver references to handle before making it available again"), but now
> > the exposure is via the PRIME lookup tables. If we remove the
> > object/handle from the PRIME lut, then a new request for the same
> > object/fd will generate a new handle, thus for a short window that
> > object is known to userspace by two different handles. Fix this by
> > releasing the driver tracking before PRIME.
> > 
> > Fixes: 0ff926c7d4f0 ("drm/prime: add exported buffers to current fprivs
> > imported buffer list (v2)")
> > Signed-off-by: Chris Wilson 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Rob Clark 
> > Cc: Ville Syrjälä 
> > Cc: Thierry Reding 
> > Cc: sta...@vger.kernel.org
> 
> Do we have an evil igt for this? I guess since the old one didn't have
> one, this new race is also hard to reproduce ...
> 
> Reviewed-by: Daniel Vetter 

Pushed this to drm-misc-fixes (and drm-misc-next for I am a monkey with
a keyboard), thanks for the patch and review.

Sean, you can blame it on me when/if there is trouble caused by the
patch being in both branches. Hopefully next merge will cause less
headache.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] pm_rps: Extended testcases with checking PMINTRMSK register value

[Szwichtenberg, Radoslaw]

On Tue, 2017-08-22 at 13:33 +0100, Chris Wilson wrote:
> Quoting Szwichtenberg, Radoslaw (2017-08-22 12:56:00)
> > On Tue, 2017-08-22 at 01:31 +0300, Arkadiusz Hiler wrote:
> > > On Mon, Aug 21, 2017 at 09:39:24PM +0200, Daniel Vetter wrote:
> > > > On Mon, Aug 21, 2017 at 11:21:49AM +0100, Chris Wilson wrote:
> > > > > Quoting Chris Wilson (2017-08-21 10:53:36)
> > > > > > Quoting Arkadiusz Hiler (2017-08-21 10:42:25)
> > > > > > > On Mon, Aug 21, 2017 at 08:05:58AM +, Dec, Katarzyna wrote:
> > > > > > > > I understand we do not want to check registers in IGT tests.
> > > > > > > > What
> > > > > > > > about reading interrupt masks from debugfs
> > > > > > > > (i915_frequency_info).
> > > > > > > 
> > > > > > > Hey Kasia
> > > > > > > 
> > > > > > > It would be pretty much the same thing, but instead of us reading
> > > > > > > the
> > > > > > > PMINTRMASK directly we would ask the kernel to do that on our
> > > > > > > behalf.
> > > > > > > 
> > > > > > > That would just hide register read, not get rid of it.
> > > > > > > 
> > > > > > > 
> > > > > > > I think you are missing the point. The idea is that we do not want
> > > > > > > to
> > > > > > > test details of in-kernel implementation, not ban the register
> > > > > > > reads
> > > > > > > completely.
> > > > > > > 
> > > > > > > Reading register directly, especially just to make sure that the
> > > > > > > kernel
> > > > > > > set something correctly is a good indicator that we are trying to
> > > > > > > do
> > > > > > > just that - test the internal details.
> > > > > > > 
> > > > > > > > Would that be better approach? You guys suggested to get
> > > > > > > > interested
> > > > > > > > in
> > > > > > > > kselftests for having such checks, but I am afraid that it could
> > > > > > > > be
> > > > > > > > too much job and we have too few hands to work.
> > > > > > > 
> > > > > > > How much of an effort would the kselftest be, since it seems that
> > > > > > > you
> > > > > > > did some
> > > > > > > investigation already?
> > > > > > 
> > > > > > It doesn't even require a whole selftest, just something like
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > index 448e71af4772..e83b67fe0354 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > @@ -7733,7 +7733,8 @@ void intel_suspend_gt_powersave(struct
> > > > > > drm_i915_private *dev_priv)
> > > > > > if (cancel_delayed_work_sync(_priv-
> > > > > > >rps.autoenable_work))
> > > > > > intel_runtime_pm_put(dev_priv);
> > > > > >  
> > > > > > -   /* gen6_rps_idle() will be called later to disable
> > > > > > interrupts */
> > > > > > +   WARN_ON(I915_READ(GEN6_PMINTRMSK) !=
> > > > > > +   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
> > > > > >  }
> > > > > 
> > > > > Wrong spot. We actually need a call from
> > > > > intel_runtime_pm_disable_interrupts.
> > > > 
> > > > Yeah, for consistency checks which are very closely tied to the
> > > > implementation we tend to sprinkle WARN_ON all over the place. In some
> > > > cases those checks are too expensive for production, then we add a
> > > > compile-time-option to hide them (e.g. GEM_BUG_ON).
> > > > 
> > > > I chatted with Radek, and if I understand things correctly, the main
> > > > value
> > > > you derive from these is making sure a frankenstein port to an older
> > > > kernel doesn't miss or miss-apply any critical patches. In-kernel
> > > > consistency checks unfortunately don't really help with that, but we
> > > > heavily rely on these for validation.
> > > 
> > > Having that stated on the mailing list from the beginning (e.g. in the
> > > commit message or as one of the first replies) would help directing the
> > > whole discussion on the right track and make us understand your needs
> > > better.
> > > 
> > > I agree with Daniel's earlier statement that we should be very
> > > (over)verbose about the changes we are making and purpose they are
> > > serving.
> > > 
> > > > There's also examples of this (and again, they're very important)
> > > > outside
> > > > of i915, like kasan, lockdep (and maybe we'll even get kmemleak somehow
> > > > integrated into CI/igt eventually).
> > > > 
> > > > So still no idea what would be the best suggestion here for your team.
> > > 
> > > Kasia and Radek, can you elaborate a little more on the "frankenstein
> > > port" and your use cases for such tests?
> > > 
> > > How is that comparable to backports to stable/LTS kernel branches?
> > > 
> > 
> > This test proposed by Kasia not only was used to find various regressions
> > (including performance ones) that were later fixed on upstream (and example
> > would be patch from Sagar: https://patchwork.kernel.org/patch/9527335/).
> 
> It is a terrible test for that. If you're goal is to validate performance,
> do that. For example, the presumption there is that RPS continues 

Re: [Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+

[Lionel Landwerlin]

On 22/08/17 12:59, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-08-22 12:45:47)

On 08/08/17 15:21, Matthew Auld wrote:

On 4 August 2017 at 12:20, Lionel Landwerlin
 wrote:

   static void
@@ -1336,6 +1504,66 @@ print_reports(uint32_t *oa_report0, uint32_t 
*oa_report1, int fmt)
   }

   static void
+print_report(uint32_t *report, int fmt)
+{

I get an unused warning for this...

Useful for really precise debugging. Putting under ifdef

Does it interfere that much with normal testing, or you could dump extra
details on unexpected events? If it is useful at some point, you will be
wishing you had the details from CI. The beauty of igt_debug() (at least
when --debug is not used by defaul!) is that it does give us the
portmortem output of the last N lines (where N is ~256?) without
flooding ourselves with irrelevant messages.
-Chris


The problem is that we get loads of reports.
Most of the time you want to look at the deltas between them (which is 
what most igt_debug() are about), only occasionally the actual values 
(which is what this function dumps).


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for pm_rps: Changes in waitboost scenario (rev4)

[Patchwork]

== Series Details ==

Series: pm_rps: Changes in waitboost scenario (rev4)
URL   : https://patchwork.freedesktop.org/series/28966/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4524a8951348a31ae5dabfc4c69f2a835034ec3e tests: Introduce audio tests, starting 
with HDMI signal integrity

with latest DRM-Tip kernel build CI_DRM_2986
93365f59a990 drm-tip: 2017y-08m-22d-11h-29m-39s UTC integration manifest

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:451s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:445s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:365s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:560s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:254s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:527s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:518s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:438s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:621s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:447s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:422s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:515s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:498s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:485s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:600s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:598s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:477s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:487s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:442s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:481s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_83/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt/pm_rpm: Use libc 'ftw' rather than opencoding our own filetree walk

[Chris Wilson]

By using ftw, we avoid the issue of having to handle directory recursion
ourselves and can focus on the test of checking the reading a
sysfs/debugfs does not break runtime suspend. In the process, disregard
errors when opening the individual files as they may fail for other
reasons.

Signed-off-by: Chris Wilson 
---
 lib/igt_debugfs.c | 50 +--
 lib/igt_debugfs.h |  1 +
 lib/igt_sysfs.c   | 41 ++---
 lib/igt_sysfs.h   |  1 +
 tests/pm_rpm.c| 90 ---
 5 files changed, 107 insertions(+), 76 deletions(-)

diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index ee1f0f54..84066ab8 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -127,38 +127,38 @@ const char *igt_debugfs_mount(void)
 }
 
 /**
- * igt_debugfs_dir:
+ * igt_debugfs_path:
  * @device: fd of the device
+ * @path: buffer to store path
+ * @pathlen: len of @path buffer.
  *
- * This opens the debugfs directory corresponding to device for use
- * with igt_sysfs_get() and related functions.
+ * This finds the debugfs directory corresponding to @device.
  *
  * Returns:
- * The directory fd, or -1 on failure.
+ * The directory path, or NULL on failure.
  */
-int igt_debugfs_dir(int device)
+char *igt_debugfs_path(int device, char *path, int pathlen)
 {
struct stat st;
const char *debugfs_root;
-   char path[200];
int idx;
 
if (fstat(device, )) {
igt_debug("Couldn't stat FD for DRM device: %s\n", 
strerror(errno));
-   return -1;
+   return NULL;
}
 
if (!S_ISCHR(st.st_mode)) {
igt_debug("FD for DRM device not a char device!\n");
-   return -1;
+   return NULL;
}
 
debugfs_root = igt_debugfs_mount();
 
idx = minor(st.st_rdev);
-   snprintf(path, sizeof(path), "%s/dri/%d/name", debugfs_root, idx);
+   snprintf(path, pathlen, "%s/dri/%d/name", debugfs_root, idx);
if (stat(path, ))
-   return -1;
+   return NULL;
 
if (idx >= 64) {
int file, name_len, cmp_len;
@@ -166,17 +166,17 @@ int igt_debugfs_dir(int device)
 
file = open(path, O_RDONLY);
if (file < 0)
-   return -1;
+   return NULL;
 
name_len = read(file, name, sizeof(name));
close(file);
 
for (idx = 0; idx < 16; idx++) {
-   snprintf(path, sizeof(path), "%s/dri/%d/name",
+   snprintf(path, pathlen, "%s/dri/%d/name",
 debugfs_root, idx);
file = open(path, O_RDONLY);
if (file < 0)
-   return -1;
+   return NULL;
 
cmp_len = read(file, cmp, sizeof(cmp));
close(file);
@@ -186,10 +186,30 @@ int igt_debugfs_dir(int device)
}
 
if (idx == 16)
-   return -1;
+   return NULL;
}
 
-   snprintf(path, sizeof(path), "%s/dri/%d", debugfs_root, idx);
+   snprintf(path, pathlen, "%s/dri/%d", debugfs_root, idx);
+   return path;
+}
+
+/**
+ * igt_debugfs_dir:
+ * @device: fd of the device
+ *
+ * This opens the debugfs directory corresponding to device for use
+ * with igt_sysfs_get() and related functions.
+ *
+ * Returns:
+ * The directory fd, or -1 on failure.
+ */
+int igt_debugfs_dir(int device)
+{
+   char path[200];
+
+   if (!igt_debugfs_path(device, path, sizeof(path)))
+   return -1;
+
igt_debug("Opening debugfs directory '%s'\n", path);
return open(path, O_RDONLY);
 }
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index f1a76406..4fa49d21 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -32,6 +32,7 @@
 enum pipe;
 
 const char *igt_debugfs_mount(void);
+char *igt_debugfs_path(int device, char *path, int pathlen);
 
 int igt_debugfs_dir(int device);
 
diff --git a/lib/igt_sysfs.c b/lib/igt_sysfs.c
index 15ed34be..d412610d 100644
--- a/lib/igt_sysfs.c
+++ b/lib/igt_sysfs.c
@@ -86,26 +86,26 @@ static int writeN(int fd, const char *buf, int len)
 }
 
 /**
- * igt_sysfs_open:
+ * igt_sysfs_path:
  * @device: fd of the device (or -1 to default to Intel)
+ * @path: buffer to fill with the sysfs path to the device
+ * @pathlen: length of @path buffer
  * @idx: optional pointer to store the card index of the opened device
  *
- * This opens the sysfs directory corresponding to device for use
- * with igt_sysfs_set() and igt_sysfs_get().
+ * This finds the sysfs directory corresponding to @device.
  *
  * Returns:
- * The directory fd, or -1 on failure.
+ * The directory path, or NULL on failure.
  */
-int igt_sysfs_open(int device, int *idx)
+char *igt_sysfs_path(int device, char 

Re: [Intel-gfx] [maintainer-tools PATCH 30/30] qf: Use .dimrc to config and extend qf.

[Jani Nikula]

On Tue, 22 Aug 2017, Daniel Vetter  wrote:
> On Tue, Aug 22, 2017 at 09:06:36AM +0200, Daniel Vetter wrote:
>> On Mon, Aug 21, 2017 at 01:11:20PM -0700, Rodrigo Vivi wrote:
>> > Soon we will need to extend qf for very specific
>> > usages of our internal maintenance and rebase bot.
>> > 
>> > So instead of creating yet another config file
>> > let's use the existent one.
>> > 
>> > Cc: Daniel Vetter 
>> > Cc: Jani Nikula 
>> > Cc: Joonas Lahtinen 
>> > Signed-off-by: Rodrigo Vivi 
>> 
>> Now that qf list-aliases/cmds works, can we perhaps also rework the bash
>> completion to use that, like for dim?
>
> Another follow-up task would be to extract the qf help into qf.rst and add
> it to the sphinx build. For even more qf/dim consistency.

That's already done and pushed.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 30/30] qf: Use .dimrc to config and extend qf.

[Daniel Vetter]

On Tue, Aug 22, 2017 at 09:06:36AM +0200, Daniel Vetter wrote:
> On Mon, Aug 21, 2017 at 01:11:20PM -0700, Rodrigo Vivi wrote:
> > Soon we will need to extend qf for very specific
> > usages of our internal maintenance and rebase bot.
> > 
> > So instead of creating yet another config file
> > let's use the existent one.
> > 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Signed-off-by: Rodrigo Vivi 
> 
> Now that qf list-aliases/cmds works, can we perhaps also rework the bash
> completion to use that, like for dim?

Another follow-up task would be to extract the qf help into qf.rst and add
it to the sphinx build. For even more qf/dim consistency.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Remove generic.testlist

[Arkadiusz Hiler]

On Tue, Aug 22, 2017 at 03:08:49PM +0300, Petri Latvala wrote:
> The list has been unmaintained and unused. The set of tests is a
> subset of what CI runs in sharded runs so we are running all of them
> already.
> 
> Signed-off-by: Petri Latvala 
Acked-by: Arkadiusz Hiler 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v3] pm_rps: Changes in waitboost scenario

[Katarzyna Dec]

CI is observing sporadical failures in pm_rps subtests.
There are a couple of reasons. One of them is the fact that
on gen6, gen7 and gen7.5, max frequency (as in the HW limit)
is not set to RP0, but the value obtaind from PCODE (which
may be different from RP0). Thus the test is operating under
wrong assumptions (SOFTMAX == RP0 == BOOST which is simply
not the case). Let's compare current frequency with BOOST
frequency rather than SOFTMAX to get the test behaviour under control.
In boost_freq function I set MAX freq to midium freqency, which ensures
that we for sure reach BOOST frequency. This could help with failures
with boost frequency failing to drop down.

v2: Commit message, simplified waiting for boost to finish, drop
noisy whitespace cleanup.

v3: Removed reading from i915_rps_boost_info debugfs because it not
the same on every kernel. Removed function waiting for boost.
Instead of that I made sure we will reach in boost by setting MAX freq to fmid.

v4: Moved proposal with making test drm master to other patch

Cc: Chris Wilson 
Cc: Jeff Mcgee 
Cc: Radoslaw Szwichtenberg 
Signed-off-by: Katarzyna Dec 
---
 tests/pm_rps.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index f0455e78..e8a051cf 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -50,6 +50,7 @@ enum {
RP0,
RP1,
RPn,
+   BOOST,
NUMFREQ
 };
 
@@ -60,7 +61,7 @@ struct junk {
const char *mode;
FILE *filp;
 } stuff[] = {
-   { "cur", "r", NULL }, { "min", "rb+", NULL }, { "max", "rb+", NULL }, { 
"RP0", "r", NULL }, { "RP1", "r", NULL }, { "RPn", "r", NULL }, { NULL, NULL, 
NULL }
+   { "cur", "r", NULL }, { "min", "rb+", NULL }, { "max", "rb+", NULL }, { 
"RP0", "r", NULL }, { "RP1", "r", NULL }, { "RPn", "r", NULL }, { "boost", 
"rb+", NULL }, { NULL, NULL, NULL }
 };
 
 static int readval(FILE *filp)
@@ -563,18 +564,32 @@ static void reset_gpu(void)
 static void boost_freq(int fd, int *boost_freqs)
 {
int64_t timeout = 1;
-   int ring = -1;
igt_spin_t *load;
+   unsigned int engine;
+   int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
 
-   load = igt_spin_batch_new(fd, ring, 0);
+   fmid = get_hw_rounded_freq(fmid);
+   //set max freq to less then boost freq
+   writeval(stuff[MAX].filp, fmid);
 
+   /* put boost on the same engine as low load */
+   engine = I915_EXEC_RENDER;
+   if (intel_gen(lh.devid) >= 6)
+   engine = I915_EXEC_BLT;
+   load = igt_spin_batch_new(fd, engine, 0);
/* Waiting will grant us a boost to maximum */
gem_wait(fd, load->handle, );
 
read_freqs(boost_freqs);
dump(boost_freqs);
 
+   /* Avoid downlocking till boost request is pending */
+   igt_spin_batch_end(load);
+   gem_sync(fd, load->handle);
igt_spin_batch_free(fd, load);
+
+   //set max freq to original softmax
+   writeval(stuff[MAX].filp, origfreqs[MAX]);
 }
 
 static void waitboost(bool reset)
@@ -582,7 +597,6 @@ static void waitboost(bool reset)
int pre_freqs[NUMFREQ];
int boost_freqs[NUMFREQ];
int post_freqs[NUMFREQ];
-
int fd = drm_open_driver(DRIVER_INTEL);
 
load_helper_run(LOW);
@@ -611,7 +625,7 @@ static void waitboost(bool reset)
idle_check();
 
igt_assert_lt(pre_freqs[CUR], pre_freqs[MAX]);
-   igt_assert_eq(boost_freqs[CUR], boost_freqs[MAX]);
+   igt_assert_eq(boost_freqs[CUR], boost_freqs[BOOST]);
igt_assert_lt(post_freqs[CUR], post_freqs[MAX]);
 
close(fd);
@@ -657,7 +671,7 @@ igt_main
val = readval(junk->filp);
igt_assert(val >= 0);
junk++;
-   } while(junk->name != NULL);
+   } while (junk->name != NULL);
 
read_freqs(origfreqs);
 
-- 
2.13.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for intel-ci: Remove generic.testlist

[Patchwork]

== Series Details ==

Series: intel-ci: Remove generic.testlist
URL   : https://patchwork.freedesktop.org/series/29139/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4524a8951348a31ae5dabfc4c69f2a835034ec3e tests: Introduce audio tests, starting 
with HDMI signal integrity

with latest DRM-Tip kernel build CI_DRM_2986
93365f59a990 drm-tip: 2017y-08m-22d-11h-29m-39s UTC integration manifest

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-kbl-7260u) fdo#102295

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fdo#102295 https://bugs.freedesktop.org/show_bug.cgi?id=102295

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:453s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:444s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:568s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:522s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:531s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:438s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:613s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:447s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:424s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:510s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7260u total:279  pass:267  dwarn:2   dfail:0   fail:0   skip:10  
time:500s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:600s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:594s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:525s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:469s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:484s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:449s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:489s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:408s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_82/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] pm_rps: Extended testcases with checking PMINTRMSK register value

[Chris Wilson]

Quoting Szwichtenberg, Radoslaw (2017-08-22 12:56:00)
> On Tue, 2017-08-22 at 01:31 +0300, Arkadiusz Hiler wrote:
> > On Mon, Aug 21, 2017 at 09:39:24PM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 21, 2017 at 11:21:49AM +0100, Chris Wilson wrote:
> > > > Quoting Chris Wilson (2017-08-21 10:53:36)
> > > > > Quoting Arkadiusz Hiler (2017-08-21 10:42:25)
> > > > > > On Mon, Aug 21, 2017 at 08:05:58AM +, Dec, Katarzyna wrote:
> > > > > > > I understand we do not want to check registers in IGT tests. What
> > > > > > > about reading interrupt masks from debugfs (i915_frequency_info).
> > > > > > 
> > > > > > Hey Kasia
> > > > > > 
> > > > > > It would be pretty much the same thing, but instead of us reading 
> > > > > > the
> > > > > > PMINTRMASK directly we would ask the kernel to do that on our 
> > > > > > behalf.
> > > > > > 
> > > > > > That would just hide register read, not get rid of it.
> > > > > > 
> > > > > > 
> > > > > > I think you are missing the point. The idea is that we do not want 
> > > > > > to
> > > > > > test details of in-kernel implementation, not ban the register reads
> > > > > > completely.
> > > > > > 
> > > > > > Reading register directly, especially just to make sure that the
> > > > > > kernel
> > > > > > set something correctly is a good indicator that we are trying to do
> > > > > > just that - test the internal details.
> > > > > > 
> > > > > > > Would that be better approach? You guys suggested to get 
> > > > > > > interested
> > > > > > > in
> > > > > > > kselftests for having such checks, but I am afraid that it could 
> > > > > > > be
> > > > > > > too much job and we have too few hands to work.
> > > > > > 
> > > > > > How much of an effort would the kselftest be, since it seems that 
> > > > > > you
> > > > > > did some
> > > > > > investigation already?
> > > > > 
> > > > > It doesn't even require a whole selftest, just something like
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > index 448e71af4772..e83b67fe0354 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > @@ -7733,7 +7733,8 @@ void intel_suspend_gt_powersave(struct
> > > > > drm_i915_private *dev_priv)
> > > > > if (cancel_delayed_work_sync(_priv->rps.autoenable_work))
> > > > > intel_runtime_pm_put(dev_priv);
> > > > >  
> > > > > -   /* gen6_rps_idle() will be called later to disable interrupts 
> > > > > */
> > > > > +   WARN_ON(I915_READ(GEN6_PMINTRMSK) !=
> > > > > +   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
> > > > >  }
> > > > 
> > > > Wrong spot. We actually need a call from
> > > > intel_runtime_pm_disable_interrupts.
> > > 
> > > Yeah, for consistency checks which are very closely tied to the
> > > implementation we tend to sprinkle WARN_ON all over the place. In some
> > > cases those checks are too expensive for production, then we add a
> > > compile-time-option to hide them (e.g. GEM_BUG_ON).
> > > 
> > > I chatted with Radek, and if I understand things correctly, the main value
> > > you derive from these is making sure a frankenstein port to an older
> > > kernel doesn't miss or miss-apply any critical patches. In-kernel
> > > consistency checks unfortunately don't really help with that, but we
> > > heavily rely on these for validation.
> > 
> > Having that stated on the mailing list from the beginning (e.g. in the
> > commit message or as one of the first replies) would help directing the
> > whole discussion on the right track and make us understand your needs
> > better.
> > 
> > I agree with Daniel's earlier statement that we should be very
> > (over)verbose about the changes we are making and purpose they are
> > serving.
> > 
> > > There's also examples of this (and again, they're very important) outside
> > > of i915, like kasan, lockdep (and maybe we'll even get kmemleak somehow
> > > integrated into CI/igt eventually).
> > > 
> > > So still no idea what would be the best suggestion here for your team.
> > 
> > Kasia and Radek, can you elaborate a little more on the "frankenstein
> > port" and your use cases for such tests?
> > 
> > How is that comparable to backports to stable/LTS kernel branches?
> > 
> This test proposed by Kasia not only was used to find various regressions
> (including performance ones) that were later fixed on upstream (and example
> would be patch from Sagar: https://patchwork.kernel.org/patch/9527335/).

It is a terrible test for that. If you're goal is to validate performance,
do that. For example, the presumption there is that RPS continues to
respond after a sequence of events (delivering the expected
performance). You can either use the gpu clocks as reported by the
kernel, but you forgo that trust by doing a known workload and
count cycles. The result should be that you get a test that matches
typical patterns and corner cases of userspace, and that you are
delivering the 

[Intel-gfx] ✓ Fi.CI.BAT: success for igt: Add gem_close (rev2)

[Patchwork]

== Series Details ==

Series: igt: Add gem_close (rev2)
URL   : https://patchwork.freedesktop.org/series/29135/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4524a8951348a31ae5dabfc4c69f2a835034ec3e tests: Introduce audio tests, starting 
with HDMI signal integrity

with latest DRM-Tip kernel build CI_DRM_2986
93365f59a990 drm-tip: 2017y-08m-22d-11h-29m-39s UTC integration manifest

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:456s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:444s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:363s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:551s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:521s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:527s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:517s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:438s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:616s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:445s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:425s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:504s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:499s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:481s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:594s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:601s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:532s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:470s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:492s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:439s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:491s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:548s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:410s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_81/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Make own struct for execlist items

[Joonas Lahtinen]

On Tue, 2017-08-22 at 12:37 +0300, Mika Kuoppala wrote:
> Engine's execlist related items have been increasing to
> a point where a separate struct is warranted. Carve execlist
> specific items to a dedicated struct to add clarity.
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Mika Kuoppala 



> +/* Execlists */
> +struct intel_engine_execlist {
> + struct tasklet_struct irq_tasklet;
> + struct i915_priolist default_priolist;
> + bool no_priolist;
> +
> + struct execlist_port {
> + struct drm_i915_gem_request *request_count;
> +#define EXECLIST_COUNT_BITS 2
> +#define port_request(p) ptr_mask_bits((p)->request_count, 
> EXECLIST_COUNT_BITS)
> +#define port_count(p) ptr_unmask_bits((p)->request_count, 
> EXECLIST_COUNT_BITS)
> +#define port_pack(rq, count) ptr_pack_bits(rq, count, EXECLIST_COUNT_BITS)
> +#define port_unpack(p, count) ptr_unpack_bits((p)->request_count, count, 
> EXECLIST_COUNT_BITS)
> +#define port_set(p, packed) ((p)->request_count = (packed))
> +#define port_isset(p) ((p)->request_count)
> +#define port_index(p, e) ((p) - (e)->execlist.port)
> + GEM_DEBUG_DECL(u32 context_id);
> + } port[2];
> +
> + struct rb_root queue;
> + struct rb_node *first;
> +
> + unsigned int fw_domains;
> +};
> +

Please do add a small kerneldoc for each parameter while touching the
code, anyway this is:

Acked-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] intel-ci: Remove generic.testlist

[Petri Latvala]

The list has been unmaintained and unused. The set of tests is a
subset of what CI runs in sharded runs so we are running all of them
already.

Signed-off-by: Petri Latvala 
---
 tests/intel-ci/Makefile.am  |   1 -
 tests/intel-ci/README   |   6 --
 tests/intel-ci/generic.testlist | 125 
 3 files changed, 132 deletions(-)
 delete mode 100644 tests/intel-ci/generic.testlist

diff --git a/tests/intel-ci/Makefile.am b/tests/intel-ci/Makefile.am
index acbbde5..2e9cca7 100644
--- a/tests/intel-ci/Makefile.am
+++ b/tests/intel-ci/Makefile.am
@@ -1,7 +1,6 @@
 EXTRA_DIST = \
fast-feedback.testlist \
fast-feedback-simulation.testlist \
-   generic.testlist \
meta.testlist \
README \
$(NULL)
diff --git a/tests/intel-ci/README b/tests/intel-ci/README
index f8daa32..ad73ebb 100644
--- a/tests/intel-ci/README
+++ b/tests/intel-ci/README
@@ -36,12 +36,6 @@ test per feature.
 The string "basic" in a test name means the test probably belongs in
 this list.
 
-==
-generic.testlist
-==
-
-Generic is the testlist for GPU-agnostic tests.
-
 =
 fast-feedback-simulation.testlist
 =
diff --git a/tests/intel-ci/generic.testlist b/tests/intel-ci/generic.testlist
deleted file mode 100644
index 433acdf..000
--- a/tests/intel-ci/generic.testlist
+++ /dev/null
@@ -1,125 +0,0 @@
-igt@core_auth@many-magics
-igt@core_auth@basic-auth
-igt@core_getclient
-igt@core_get_client_auth@master-drop
-igt@core_get_client_auth@simple
-igt@core_getstats
-igt@core_getversion
-igt@core_prop_blob@invalid-get-prop
-igt@core_prop_blob@blob-prop-lifetime
-igt@core_prop_blob@invalid-set-prop-any
-igt@core_prop_blob@invalid-set-prop
-igt@core_prop_blob@blob-prop-validate
-igt@core_prop_blob@blob-multiple
-igt@core_prop_blob@blob-prop-core
-igt@core_prop_blob@basic
-igt@core_prop_blob@invalid-get-prop-any
-igt@core_setmaster_vs_auth
-igt@drm_read@empty-nonblock
-igt@drm_read@short-buffer-block
-igt@drm_read@empty-block
-igt@drm_read@invalid-buffer
-igt@drm_read@short-buffer-nonblock
-igt@drm_read@fault-buffer
-igt@kms_addfb_basic@no-handle
-igt@kms_addfb_basic@bad-pitch-32
-igt@kms_addfb_basic@bad-pitch-999
-igt@kms_addfb_basic@invalid-set-prop-any
-igt@kms_addfb_basic@bad-pitch-0
-igt@kms_addfb_basic@bad-pitch-1024
-igt@kms_addfb_basic@bad-pitch-256
-igt@kms_addfb_basic@too-wide
-igt@kms_addfb_basic@small-bo
-igt@kms_addfb_basic@invalid-get-prop
-igt@kms_addfb_basic@basic
-igt@kms_addfb_basic@size-max
-igt@kms_addfb_basic@bad-pitch-128
-igt@kms_addfb_basic@invalid-get-prop-any
-igt@kms_addfb_basic@invalid-set-prop
-igt@kms_addfb_basic@bad-pitch-63
-igt@kms_render@direct-render
-igt@kms_setmode@invalid-clone-single-crtc-stealing
-igt@testdisplay
-igt@vgem_basic@mmap
-igt@vgem_basic@dmabuf-mmap
-igt@vgem_basic@dmabuf-fence-before
-igt@vgem_basic@dmabuf-export
-igt@vgem_basic@debugfs
-igt@vgem_basic@dmabuf-fence
-igt@vgem_basic@second-client
-igt@vgem_basic@sysfs
-igt@vgem_basic@unload
-igt@vgem_basic@create
-igt@kms_flip@wf_vblank-interruptible
-igt@kms_flip@flip-vs-dpms-off-vs-modeset
-igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible
-igt@kms_flip@2x-wf_vblank-ts-check
-igt@kms_flip@absolute-wf_vblank
-igt@kms_flip@nonexisting-fb-interruptible
-igt@kms_flip@2x-flip-vs-rmfb-interruptible
-igt@kms_flip@2x-plain-flip-ts-check
-igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible
-igt@kms_flip@modeset-vs-vblank-race
-igt@kms_flip@2x-plain-flip-interruptible
-igt@kms_flip@2x-vblank-vs-dpms-suspend
-igt@kms_flip@nonexisting-fb
-igt@kms_flip@dpms-vs-vblank-race-interruptible
-igt@kms_flip@2x-flip-vs-blocking-wf-vblank
-igt@kms_flip@2x-modeset-vs-vblank-race-interruptible
-igt@kms_flip@2x-plain-flip
-igt@kms_flip@wf_vblank-ts-check
-igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset
-igt@kms_flip@2x-flip-vs-modeset
-igt@kms_flip@2x-absolute-wf_vblank-interruptible
-igt@kms_flip@absolute-wf_vblank-interruptible
-igt@kms_flip@blocking-absolute-wf_vblank
-igt@kms_flip@dpms-off-confusion-interruptible
-igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset
-igt@kms_flip@flip-vs-expired-vblank-interruptible
-igt@kms_flip@2x-wf_vblank
-igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible
-igt@kms_flip@vblank-vs-dpms-suspend-interruptible
-igt@kms_flip@flip-vs-modeset-interruptible
-igt@kms_flip@dpms-vs-vblank-race
-igt@kms_flip@2x-wf_vblank-interruptible
-igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset-interruptible
-igt@kms_flip@basic-flip-vs-wf_vblank
-igt@kms_flip@basic-flip-vs-modeset
-igt@kms_flip@blocking-absolute-wf_vblank-interruptible
-igt@kms_flip@2x-flip-vs-modeset-interruptible
-igt@kms_flip@2x-flip-vs-panning-interruptible
-igt@kms_flip@flip-vs-blocking-wf-vblank
-igt@kms_flip@2x-dpms-vs-vblank-race-interruptible
-igt@kms_flip@flip-vs-panning-interruptible

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Assert the context is not closed on object-close

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Assert the context is not closed 
on object-close
URL   : https://patchwork.freedesktop.org/series/29137/
State : success

== Summary ==

Series 29137v1 series starting with [1/3] drm/i915: Assert the context is not 
closed on object-close
https://patchwork.freedesktop.org/api/1.0/series/29137/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:452s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:438s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:361s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:542s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:523s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:525s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:520s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:433s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:616s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:445s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:428s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:511s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:495s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:600s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:596s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:527s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:470s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:488s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:445s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:481s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:549s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

93365f59a9908f8aa7858bca57338967a20a75b7 drm-tip: 2017y-08m-22d-11h-29m-39s UTC 
integration manifest
4ef2c3816638 drm/i915: Ignore duplicate VMA stored within the per-object handle 
LUT
e43e7ce92969 drm/i915: Assert that the handle->vma lut is empty on object close
a29adf5cbaec drm/i915: Assert the context is not closed on object-close

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5459/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Assert the context is not closed on object-close

[Lofstedt, Marta]

Thanks Chris,
With this series the test pin-pointed in the bug now pass.

Tested-by: Marta Lofstedt 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Tuesday, August 22, 2017 2:05 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/3] drm/i915: Assert the context is not closed on
> object-close
> 
> During the context-close, we should be decoupling all the vma from the
> object so that upon object-closing we shouldn't see any vma from the
> already closed contexts. So include a check upon closing the object that the
> context is still open.
> 
> v2: Eek, the fpriv check is required for shared objects. Double eek, BAT
> passed?

Well, the KBL-shards results actually exposed the regression: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5429/shards-all.html
So, could you remove that comment.

> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c index b9e8e0d6e97b..3ed9fb0921e2
> 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3253,11 +3253,11 @@ void i915_gem_close_object(struct
> drm_gem_object *gem, struct drm_file *file)
>   struct i915_gem_context *ctx = lut->ctx;
>   struct i915_vma *vma;
> 
> + GEM_BUG_ON(ctx->file_priv == ERR_PTR(-
> EBADF));
>   if (ctx->file_priv != fpriv)
>   continue;
> 
>   vma = radix_tree_delete(>handles_vma,
> lut->handle);
> -
>   if (!i915_vma_is_ggtt(vma))
>   i915_vma_close(vma);
> 
> --
> 2.14.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 i-g-t 02/11] tests/perf: add per context filtering test for gen8+

[Chris Wilson]

Quoting Lionel Landwerlin (2017-08-22 12:45:47)
> On 08/08/17 15:21, Matthew Auld wrote:
> > On 4 August 2017 at 12:20, Lionel Landwerlin
> >  wrote:
> >>   static void
> >> @@ -1336,6 +1504,66 @@ print_reports(uint32_t *oa_report0, uint32_t 
> >> *oa_report1, int fmt)
> >>   }
> >>
> >>   static void
> >> +print_report(uint32_t *report, int fmt)
> >> +{
> > I get an unused warning for this...
> 
> Useful for really precise debugging. Putting under ifdef

Does it interfere that much with normal testing, or you could dump extra
details on unexpected events? If it is useful at some point, you will be
wishing you had the details from CI. The beauty of igt_debug() (at least
when --debug is not used by defaul!) is that it does give us the
portmortem output of the last N lines (where N is ~256?) without
flooding ourselves with irrelevant messages.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] pm_rps: Extended testcases with checking PMINTRMSK register value

[Szwichtenberg, Radoslaw]

On Tue, 2017-08-22 at 01:31 +0300, Arkadiusz Hiler wrote:
> On Mon, Aug 21, 2017 at 09:39:24PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 21, 2017 at 11:21:49AM +0100, Chris Wilson wrote:
> > > Quoting Chris Wilson (2017-08-21 10:53:36)
> > > > Quoting Arkadiusz Hiler (2017-08-21 10:42:25)
> > > > > On Mon, Aug 21, 2017 at 08:05:58AM +, Dec, Katarzyna wrote:
> > > > > > I understand we do not want to check registers in IGT tests. What
> > > > > > about reading interrupt masks from debugfs (i915_frequency_info).
> > > > > 
> > > > > Hey Kasia
> > > > > 
> > > > > It would be pretty much the same thing, but instead of us reading the
> > > > > PMINTRMASK directly we would ask the kernel to do that on our behalf.
> > > > > 
> > > > > That would just hide register read, not get rid of it.
> > > > > 
> > > > > 
> > > > > I think you are missing the point. The idea is that we do not want to
> > > > > test details of in-kernel implementation, not ban the register reads
> > > > > completely.
> > > > > 
> > > > > Reading register directly, especially just to make sure that the
> > > > > kernel
> > > > > set something correctly is a good indicator that we are trying to do
> > > > > just that - test the internal details.
> > > > > 
> > > > > > Would that be better approach? You guys suggested to get interested
> > > > > > in
> > > > > > kselftests for having such checks, but I am afraid that it could be
> > > > > > too much job and we have too few hands to work.
> > > > > 
> > > > > How much of an effort would the kselftest be, since it seems that you
> > > > > did some
> > > > > investigation already?
> > > > 
> > > > It doesn't even require a whole selftest, just something like
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 448e71af4772..e83b67fe0354 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -7733,7 +7733,8 @@ void intel_suspend_gt_powersave(struct
> > > > drm_i915_private *dev_priv)
> > > > if (cancel_delayed_work_sync(_priv->rps.autoenable_work))
> > > > intel_runtime_pm_put(dev_priv);
> > > >  
> > > > -   /* gen6_rps_idle() will be called later to disable interrupts */
> > > > +   WARN_ON(I915_READ(GEN6_PMINTRMSK) !=
> > > > +   gen6_sanitize_rps_pm_mask(dev_priv, ~0));
> > > >  }
> > > 
> > > Wrong spot. We actually need a call from
> > > intel_runtime_pm_disable_interrupts.
> > 
> > Yeah, for consistency checks which are very closely tied to the
> > implementation we tend to sprinkle WARN_ON all over the place. In some
> > cases those checks are too expensive for production, then we add a
> > compile-time-option to hide them (e.g. GEM_BUG_ON).
> > 
> > I chatted with Radek, and if I understand things correctly, the main value
> > you derive from these is making sure a frankenstein port to an older
> > kernel doesn't miss or miss-apply any critical patches. In-kernel
> > consistency checks unfortunately don't really help with that, but we
> > heavily rely on these for validation.
> 
> Having that stated on the mailing list from the beginning (e.g. in the
> commit message or as one of the first replies) would help directing the
> whole discussion on the right track and make us understand your needs
> better.
> 
> I agree with Daniel's earlier statement that we should be very
> (over)verbose about the changes we are making and purpose they are
> serving.
> 
> > There's also examples of this (and again, they're very important) outside
> > of i915, like kasan, lockdep (and maybe we'll even get kmemleak somehow
> > integrated into CI/igt eventually).
> > 
> > So still no idea what would be the best suggestion here for your team.
> 
> Kasia and Radek, can you elaborate a little more on the "frankenstein
> port" and your use cases for such tests?
> 
> How is that comparable to backports to stable/LTS kernel branches?
> 
This test proposed by Kasia not only was used to find various regressions
(including performance ones) that were later fixed on upstream (and example
would be patch from Sagar: https://patchwork.kernel.org/patch/9527335/).

Additionally we do sometimes use older releases of kernel for which we do
backport some of the latest changes (on need basis). As this test verifies
whether masking is done as we expect it to be done it allows us to ensure that
during forklift/cherrypicking or any other process any of the required patches
were not missed.

I believe that proposed changes are not introducing any overhead or information
that is not really usefull for developers/test runners. Also providing support
for all previous and future platforms should not be an issue in this case.
Information about masking proved multiple times to be usefull when looking for
root cause of issues with rps we were facing. Fixes for all these issues (if
were still applicable to upstream code) were sent upstream (I think mostly by
Sagar). I think 

Re: [Intel-gfx] [PATCH i-g-t 02/11] tests/perf: add per context filtering test for gen8+

[Lionel Landwerlin]

On 08/08/17 15:21, Matthew Auld wrote:

On 4 August 2017 at 12:20, Lionel Landwerlin
 wrote:

From: Robert Bragg 

Signed-off-by: Robert Bragg 
Signed-off-by: Lionel Landwerlin 
---
  tests/perf.c | 806 ---
  1 file changed, 768 insertions(+), 38 deletions(-)

diff --git a/tests/perf.c b/tests/perf.c
index 26581ce4..279ff0c6 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -48,7 +48,9 @@ IGT_TEST_DESCRIPTION("Test the i915 perf metrics streaming 
interface");
  #define OAREPORT_REASON_MASK   0x3f
  #define OAREPORT_REASON_SHIFT  19
  #define OAREPORT_REASON_TIMER  (1<<0)
+#define OAREPORT_REASON_INTERNAL   (3<<1)
  #define OAREPORT_REASON_CTX_SWITCH (1<<3)
+#define OAREPORT_REASON_GO (1<<4)
  #define OAREPORT_REASON_CLK_RATIO  (1<<5)

  #define GFX_OP_PIPE_CONTROL ((3 << 29) | (3 << 27) | (2 << 24))
@@ -565,6 +567,22 @@ oa_exponent_to_ns(int exponent)
 return 10ULL * (2ULL << exponent) / timestamp_frequency;
  }

+static bool
+oa_report_ctx_is_valid(uint32_t *report)
+{
+   if (IS_HASWELL(devid)) {
+   return false; /* TODO */
+   } else if (IS_GEN8(devid)) {
+   return report[0] & (1ul << 25);
+   } else if (IS_GEN9(devid)) {
+   return report[0] & (1ul << 16);
+   }
+
+   /* Need to update this function for newer Gen. */
+   igt_assert(!"reached");
+}
+
+
  static void
  hsw_sanity_check_render_basic_reports(uint32_t *oa_report0, uint32_t 
*oa_report1,
   enum drm_i915_oa_format fmt)
@@ -669,6 +687,100 @@ gen8_40bit_a_delta(uint64_t value0, uint64_t value1)
 return value1 - value0;
  }

+static void
+accumulate_uint32(size_t offset,
+ uint32_t *report0,
+  uint32_t *report1,
+  uint64_t *delta)
+{
+   uint32_t value0 = *(uint32_t *)(((uint8_t *)report0) + offset);
+   uint32_t value1 = *(uint32_t *)(((uint8_t *)report1) + offset);
+
+   *delta += (uint32_t)(value1 - value0);
+}
+
+static void
+accumulate_uint40(int a_index,
+  uint32_t *report0,
+  uint32_t *report1,
+ enum drm_i915_oa_format format,
+  uint64_t *delta)
+{
+   uint64_t value0 = gen8_read_40bit_a_counter(report0, format, a_index),
+value1 = gen8_read_40bit_a_counter(report1, format, a_index);
+
+   *delta += gen8_40bit_a_delta(value0, value1);
+}
+
+static void
+accumulate_reports(struct accumulator *accumulator,
+  uint32_t *start,
+  uint32_t *end)
+{
+   enum drm_i915_oa_format format = accumulator->format;
+   uint64_t *deltas = accumulator->deltas;
+   int idx = 0;
+
+   if (intel_gen(devid) >= 8) {
+   /* timestamp */
+   accumulate_uint32(4, start, end, deltas + idx++);
+
+   /* clock cycles */
+   accumulate_uint32(12, start, end, deltas + idx++);
+   } else {
+   /* timestamp */
+   accumulate_uint32(4, start, end, deltas + idx++);
+   }
+
+   for (int i = 0; i < oa_formats[format].n_a40; i++)
+   accumulate_uint40(i, start, end, format, deltas + idx++);
+
+   for (int i = 0; i < oa_formats[format].n_a; i++) {
+   accumulate_uint32(oa_formats[format].a_off + 4 * i,
+ start, end, deltas + idx++);
+   }
+
+   for (int i = 0; i < oa_formats[format].n_b; i++) {
+   accumulate_uint32(oa_formats[format].b_off + 4 * i,
+ start, end, deltas + idx++);
+   }
+
+   for (int i = 0; i < oa_formats[format].n_c; i++) {
+   accumulate_uint32(oa_formats[format].c_off + 4 * i,
+ start, end, deltas + idx++);
+   }
+}
+
+static void
+accumulator_print(struct accumulator *accumulator, const char *title)
+{
+   enum drm_i915_oa_format format = accumulator->format;
+   uint64_t *deltas = accumulator->deltas;
+   int idx = 0;
+
+   igt_debug("%s:\n", title);
+   if (intel_gen(devid) >= 8) {
+   igt_debug("\ttime delta = %lu\n", deltas[idx++]);
+   igt_debug("\tclock cycle delta = %lu\n", deltas[idx++]);
+
+   for (int i = 0; i < oa_formats[format].n_a40; i++)
+   igt_debug("\tA%u = %lu\n", i, deltas[idx++]);
+   } else {
+   igt_debug("\ttime delta = %lu\n", deltas[idx++]);
+   }
+
+   for (int i = 0; i < oa_formats[format].n_a; i++) {
+   int a_id = oa_formats[format].first_a + i;
+   igt_debug("\tA%u = %lu\n", a_id, deltas[idx++]);
+   }
+
+   for (int i = 0; i < oa_formats[format].n_a; i++)
+   igt_debug("\tB%u = %lu\n", i, 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add more latency to avoid display flicker

[Patchwork]

== Series Details ==

Series: drm/i915: Add more latency to avoid display flicker
URL   : https://patchwork.freedesktop.org/series/29136/
State : success

== Summary ==

Series 29136v1 drm/i915: Add more latency to avoid display flicker
https://patchwork.freedesktop.org/api/1.0/series/29136/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:457s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:442s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:367s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:564s
fi-bwr-2160  total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  
time:252s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:526s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:527s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:525s
fi-elk-e7500 total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  
time:439s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:615s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:445s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:428s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7260u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:500s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:485s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:600s
fi-kbl-r total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:594s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:527s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:472s
fi-skl-6700k total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:487s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:440s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:484s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:558s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:414s

dbfb2f62576e1c3550d10398b097589959356db3 drm-tip: 2017y-08m-21d-08h-13m-34s UTC 
integration manifest
f10f2264a28e drm/i915: Add more latency to avoid display flicker

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5458/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx