[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/1] drm/i915: Move i915_gem_restore_fences to i915_gem_resume

[Patchwork]

== Series Details ==

Series: series starting with [1/1] drm/i915: Move i915_gem_restore_fences to 
i915_gem_resume
URL   : https://patchwork.freedesktop.org/series/31118/
State : warning

== Summary ==

Series 31118v1 series starting with [1/1] drm/i915: Move 
i915_gem_restore_fences to i915_gem_resume
https://patchwork.freedesktop.org/api/1.0/series/31118/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_busy:
Subgroup basic-flip-c:
pass   -> DMESG-WARN (fi-bxt-dsi)
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-glk-1) fdo#102777 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:472s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:413s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:513s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:289  pass:258  dwarn:1   dfail:0   fail:0   skip:30  
time:492s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:493s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:481s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:571s
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:635s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:418s
fi-glk-1 total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
time:566s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:424s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:406s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:428s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:464s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:574s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:548s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:757s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:479s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:561s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:417s

0369ecdbb55495dd4671ad33d375f37d0707b629 drm-tip: 2017y-09m-28d-20h-01m-55s UTC 
integration manifest
c4a93dd537c3 drm/i915: Move i915_gem_restore_fences to i915_gem_resume

== Logs ==

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

[Intel-gfx] [PATCH 1/1] drm/i915: Move i915_gem_restore_fences to i915_gem_resume

[Sagar Arun Kamble]

i915_gem_restore_fences is GEM resumption task hence it is moved to
i915_gem_resume from i915_restore_state.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 1 +
 drivers/gpu/drm/i915/i915_suspend.c | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73eeb6b..ab8c694 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4595,6 +4595,7 @@ void i915_gem_resume(struct drm_i915_private *dev_priv)
 
mutex_lock(>struct_mutex);
i915_gem_restore_gtt_mappings(dev_priv);
+   i915_gem_restore_fences(dev_priv);
 
/* As we didn't flush the kernel context before suspend, we cannot
 * guarantee that the context image is complete. So let's just reset
diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 5c86925a..8f3aa4d 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -108,8 +108,6 @@ int i915_restore_state(struct drm_i915_private *dev_priv)
 
mutex_lock(_priv->drm.struct_mutex);
 
-   i915_gem_restore_fences(dev_priv);
-
if (IS_GEN4(dev_priv))
pci_write_config_word(pdev, GCDGMBUS,
  dev_priv->regfile.saveGCDGMBUS);
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Transform whitelisting WAs into a simple reg write

[Patchwork]

== Series Details ==

Series: drm/i915: Transform whitelisting WAs into a simple reg write
URL   : https://patchwork.freedesktop.org/series/31099/
State : success

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2429 pass:1330 dwarn:5   dfail:0   fail:11  skip:1083 
time:9966s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: Do not prune the preferred mode on the panel

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Do not prune the preferred mode on the panel
URL   : https://patchwork.freedesktop.org/series/31102/
State : warning

== Summary ==

Series 31102v1 drm/i915/dp: Do not prune the preferred mode on the panel
https://patchwork.freedesktop.org/api/1.0/series/31102/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Subgroup hdmi-hpd-fast:
skip   -> FAIL   (fi-kbl-7500u) fdo#102672
Subgroup hdmi-crc-fast:
pass   -> DMESG-WARN (fi-skl-6700k) fdo#103019
Test gem_ringfill:
Subgroup basic-default:
pass   -> SKIP   (fi-bsw-n3050)
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (fi-glk-1) fdo#102777

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
fdo#103019 https://bugs.freedesktop.org/show_bug.cgi?id=103019
fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:479s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:428s
fi-bsw-n3050 total:289  pass:242  dwarn:0   dfail:0   fail:0   skip:47  
time:524s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:501s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:487s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:546s
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:635s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:564s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:427s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:406s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:434s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:491s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:467s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:1   skip:23  
time:475s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:548s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6700k total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:751s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:479s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:568s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:414s

0369ecdbb55495dd4671ad33d375f37d0707b629 drm-tip: 2017y-09m-28d-20h-01m-55s UTC 
integration manifest
325c6d40aef8 drm/i915/dp: Do not prune the preferred mode on the panel

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce DVFS.

[Patchwork]

== Series Details ==

Series: Introduce DVFS.
URL   : https://patchwork.freedesktop.org/series/30922/
State : failure

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test gem_exec_schedule:
Subgroup preempt-self-vebox:
skip   -> INCOMPLETE (shard-hsw)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2429 pass:1311 dwarn:4   dfail:0   fail:10  skip:1055 
time:9896s

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/dp: Do not prune the preferred mode on the panel

[Manasi Navare]

During the mode validation, we should never prune the
preferred mode that is the native mode of the eDP panel.
This can result into no modes being available for the eDP
connector.

Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Daniel Vetter 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90e756c..621eb4d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -405,6 +405,9 @@ intel_dp_mode_valid(struct drm_connector *connector,
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
 
+   if (intel_dp_is_edp(intel_dp) && (mode->type & DRM_MODE_TYPE_PREFERRED))
+   return MODE_OK;
+
if (mode_rate > max_rate || target_clock > max_dotclk)
return MODE_CLOCK_HIGH;
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Transform whitelisting WAs into a simple reg write

[Michel Thierry]

On 28/09/17 15:40, Oscar Mateo wrote:

RING_FORCE_TO_NONPRIV registers do not live in the logical context. They are 
simply
global privileged MMIO registers that happen to be powercontext saved and 
restored
(meaning only they can survive RC6). Therefore, there is absolutely no need to 
save
them so that they can be restored everytime we create a new logical context.

Suggested-by: Chris Wilson 
Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a28e2a8..a75f5e8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -845,8 +845,8 @@ static int wa_ring_whitelist_reg(struct intel_engine_cs 
*engine,
 if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
 return -EINVAL;

-   WA_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
-i915_mmio_reg_offset(reg));
+   I915_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
+  i915_mmio_reg_offset(reg));
 wa->hw_whitelist_count[engine->id]++;

 return 0;
--
1.9.1



I see RCS_FORCE_TO_NONPRIV in "Render Engine *Power* Context" and not in 
the "Register State Context", so


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

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/guc : Removing enable_guc_loading module

[Sujaritha]

On 09/28/2017 03:36 PM, Srivatsa, Anusha wrote:



-Original Message-
From: Sundaresan, Sujaritha
Sent: Thursday, September 21, 2017 11:38 AM
To: intel-gfx@lists.freedesktop.org
Cc: Sundaresan, Sujaritha ; Wajdeczko, Michal
; Srivatsa, Anusha ;
Mateo Lozano, Oscar ; Ceraolo Spurio, Daniele

Subject: [PATCH v4 1/2] drm/i915/guc : Removing enable_guc_loading module

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission".
Whenever we need i915.enable_guc_submission=1, we also need
enable_guc_loading=1.
We also need enable_guc_loading=1 when we want to verify the HuC, which is
every time we have a HuC (but all platforms with HuC have a GuC and viceversa).

v2: Clarifying the commit message (Anusha)
v3: Unify seq_puts messages, correcting inconsistencies (Michal)
v4: Rebased

Cc: Michal Wajdeczko 
Cc: Anusha Srivatsa 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 

Signed-off-by: Sujaritha Sundaresan 
---
drivers/gpu/drm/i915/i915_debugfs.c | 22 +
drivers/gpu/drm/i915/i915_drv.h | 11 +++--
drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
drivers/gpu/drm/i915/i915_irq.c |  2 +-
drivers/gpu/drm/i915/i915_params.c  |  5 --
drivers/gpu/drm/i915/i915_params.h  |  1 -
drivers/gpu/drm/i915/intel_guc_loader.c |  6 ++-
drivers/gpu/drm/i915/intel_uc.c | 83 ++---
9 files changed, 73 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ca6fa6d..063fbe3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1616,7 +1616,7 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
struct drm_i915_private *dev_priv = node_to_i915(m->private);

if (!HAS_FBC(dev_priv)) {
-   seq_puts(m, "FBC unsupported on this chipset\n");
+   seq_puts(m, "not supported\n");
return 0;
}

@@ -1783,7 +1783,7 @@ static int i915_ring_freq_table(struct seq_file *m, void
*unused)
unsigned int max_gpu_freq, min_gpu_freq;

if (!HAS_LLC(dev_priv)) {
-   seq_puts(m, "unsupported on this chipset\n");
+   seq_puts(m, "not supported\n");
return 0;
}

@@ -2336,8 +2336,11 @@ static int i915_huc_load_status_info(struct seq_file
*m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_uc_fw *huc_fw = _priv->huc.fw;

-   if (!HAS_HUC_UCODE(dev_priv))
+   if (!HAS_GUC(dev_priv)){
+   seq_puts(m, "not supported\n");
return 0;
+   }
+

seq_puts(m, "HuC firmware status:\n");
seq_printf(m, "\tpath: %s\n", huc_fw->path); @@ -2369,8 +2372,11 @@
static int i915_guc_load_status_info(struct seq_file *m, void *data)
struct intel_uc_fw *guc_fw = _priv->guc.fw;
u32 tmp, i;

-   if (!HAS_GUC_UCODE(dev_priv))
+   if (!HAS_GUC(dev_priv)){
+   seq_puts(m, "not supported\n");
return 0;
+   }
+

seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
@@ -2465,7 +2471,7 @@ static bool check_guc_submission(struct seq_file *m)

if (!guc->execbuf_client) {
seq_printf(m, "GuC submission %s\n",
-  HAS_GUC_SCHED(dev_priv) ?
+  HAS_GUC(dev_priv) ?
   "disabled" :
   "not supported");
return false;
@@ -2654,7 +2660,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
bool enabled = false;

if (!HAS_PSR(dev_priv)) {
-   seq_puts(m, "PSR not supported\n");
+   seq_puts(m, "not supported\n");
return 0;
}

@@ -2807,7 +2813,7 @@ static int i915_runtime_pm_status(struct seq_file *m,
void *unused)
struct pci_dev *pdev = dev_priv->drm.pdev;

if (!HAS_RUNTIME_PM(dev_priv))
-   seq_puts(m, "Runtime power management not supported\n");
+   seq_puts(m, "not supported\n");

seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
seq_printf(m, "IRQs disabled: %s\n",
@@ -3683,7 +3689,7 @@ static void drrs_status_per_crtc(struct seq_file *m,
mutex_unlock(>mutex);
} else {
/* DRRS not supported. Print the VBT parameter*/
-   seq_puts(m, "\tDRRS Supported : No");
+   seq_puts(m, "not supported\n");
}
seq_puts(m, "\n");
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h 

Re: [Intel-gfx] [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation

[Zhang, Tina]

Thanks for the patch. Actually, I did the same thing in my local repo and also, 
I have a patch for the local Qemu repo to test it. I will send them out later.

The reason why I want to propose the close IOCTL is because that the current 
lock (fb_obj_list_lock), cannot sync the intel_vgpu_fb_info releasing and 
reusing.
You see, the intel_vgpu_fb_info reusing and releasing are in different threads. 
There is a case that intel_vgpu_find_dmabuf can return a intel_vgpu_fb_obj, 
while the intel_vgpu_fb_obj
is on the way to be released. That's the problem.

The invoker of the close IOCTL is only Qemu. So, if the Qemu crashes, the whole 
vGPU's resource is going to be released. We can handle our dmabuf_obj to be 
released there.

Thanks.

BR,
Tina

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Wednesday, September 27, 2017 6:11 PM
> To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi
> A ; Tian, Kevin 
> Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org;
> intel-gvt-...@lists.freedesktop.org; Alex Williamson
> ; Lv, Zhiyuan 
> Subject: Re: [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation
> 
>   Hi,
> 
> > So, there is a problem about the releasing cached dmabuf_obj. We
> > cannot rely on the drm_i915_gem_object_ops.release() to release the
> > cached dmabuf_obj, as this release operation is running in another
> > thread, which leads to a racing condition and tricky to be solved
> > without touching other modules.
> 
> PLANE_INFO just creates a intel_vgpu_dmabuf_obj.
> 
> GET_DMABUF creates a fresh proxy gem object and dmabuf.
> 
> proxy gem object references intel_vgpu_dmabuf_obj but not the other way
> around.  Then you can simply refcount intel_vgpu_dmabuf_obj and be done
> with it.
> 
> https://www.kraxel.org/cgit/linux/commit/?h=gvt-dmabuf-v14=350a0e834
> 971e6f53d7235d8b6167bed4dccf074
> 
> Note: Patch renamed intel_vgpu_dmabuf_obj to intel_vgpu_fb_obj, because it
> doesn't refer to dmabufs any more.  It basically carries the guest
> plane/framebuffer information and the ID associated with it.
> 
> > So, in order to solve that kind of problem, I’d like to add one more
> > ioctl, which is used for user mode to close the dmabuf_obj.
> 
> Depending on userspace notifying the kernel for that kind of cleanups is a bad
> idea.  What happens in case userspace crashes?  Do you leak dmabufs then?
> 
> cheers,
>   Gerd
> 
> ___
> 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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/glk, cnl: Implement WaDisableScalarClockGating

[Patchwork]

== Series Details ==

Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating
URL   : https://patchwork.freedesktop.org/series/31094/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2429 pass:1332 dwarn:5   dfail:0   fail:9   skip:1083 
time:9943s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Transform whitelisting WAs into a simple reg write

[Patchwork]

== Series Details ==

Series: drm/i915: Transform whitelisting WAs into a simple reg write
URL   : https://patchwork.freedesktop.org/series/31099/
State : success

== Summary ==

Series 31099v1 drm/i915: Transform whitelisting WAs into a simple reg write
https://patchwork.freedesktop.org/api/1.0/series/31099/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (fi-glk-1) fdo#102777

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:475s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:416s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:508s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:495s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:495s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:487s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:547s
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:633s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:565s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:429s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:404s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:467s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:545s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:761s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:477s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:564s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:415s

0369ecdbb55495dd4671ad33d375f37d0707b629 drm-tip: 2017y-09m-28d-20h-01m-55s UTC 
integration manifest
34540f12b1bc drm/i915: Transform whitelisting WAs into a simple reg write

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Transform whitelisting WAs into a simple reg write

[Oscar Mateo]

RING_FORCE_TO_NONPRIV registers do not live in the logical context. They are 
simply
global privileged MMIO registers that happen to be powercontext saved and 
restored
(meaning only they can survive RC6). Therefore, there is absolutely no need to 
save
them so that they can be restored everytime we create a new logical context.

Suggested-by: Chris Wilson 
Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a28e2a8..a75f5e8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -845,8 +845,8 @@ static int wa_ring_whitelist_reg(struct intel_engine_cs 
*engine,
if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
return -EINVAL;
 
-   WA_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
-i915_mmio_reg_offset(reg));
+   I915_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
+  i915_mmio_reg_offset(reg));
wa->hw_whitelist_count[engine->id]++;
 
return 0;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/guc : Removing enable_guc_loading module

[Srivatsa, Anusha]

>-Original Message-
>From: Sundaresan, Sujaritha
>Sent: Thursday, September 21, 2017 11:38 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Sundaresan, Sujaritha ; Wajdeczko, Michal
>; Srivatsa, Anusha ;
>Mateo Lozano, Oscar ; Ceraolo Spurio, Daniele
>
>Subject: [PATCH v4 1/2] drm/i915/guc : Removing enable_guc_loading module
>
>We currently have two module parameters that control GuC:
>"enable_guc_loading" and "enable_guc_submission".
>Whenever we need i915.enable_guc_submission=1, we also need
>enable_guc_loading=1.
>We also need enable_guc_loading=1 when we want to verify the HuC, which is
>every time we have a HuC (but all platforms with HuC have a GuC and viceversa).
>
>v2: Clarifying the commit message (Anusha)
>v3: Unify seq_puts messages, correcting inconsistencies (Michal)
>v4: Rebased
>
>Cc: Michal Wajdeczko 
>Cc: Anusha Srivatsa 
>Cc: Oscar Mateo 
>Cc: Daniele Ceraolo Spurio 
>
>Signed-off-by: Sujaritha Sundaresan 
>---
> drivers/gpu/drm/i915/i915_debugfs.c | 22 +
> drivers/gpu/drm/i915/i915_drv.h | 11 +++--
> drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
> drivers/gpu/drm/i915/i915_irq.c |  2 +-
> drivers/gpu/drm/i915/i915_params.c  |  5 --
> drivers/gpu/drm/i915/i915_params.h  |  1 -
> drivers/gpu/drm/i915/intel_guc_loader.c |  6 ++-
> drivers/gpu/drm/i915/intel_uc.c | 83 ++---
> 9 files changed, 73 insertions(+), 61 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>b/drivers/gpu/drm/i915/i915_debugfs.c
>index ca6fa6d..063fbe3 100644
>--- a/drivers/gpu/drm/i915/i915_debugfs.c
>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
>@@ -1616,7 +1616,7 @@ static int i915_fbc_status(struct seq_file *m, void
>*unused)
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
>
>   if (!HAS_FBC(dev_priv)) {
>-  seq_puts(m, "FBC unsupported on this chipset\n");
>+  seq_puts(m, "not supported\n");
>   return 0;
>   }
>
>@@ -1783,7 +1783,7 @@ static int i915_ring_freq_table(struct seq_file *m, void
>*unused)
>   unsigned int max_gpu_freq, min_gpu_freq;
>
>   if (!HAS_LLC(dev_priv)) {
>-  seq_puts(m, "unsupported on this chipset\n");
>+  seq_puts(m, "not supported\n");
>   return 0;
>   }
>
>@@ -2336,8 +2336,11 @@ static int i915_huc_load_status_info(struct seq_file
>*m, void *data)
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
>   struct intel_uc_fw *huc_fw = _priv->huc.fw;
>
>-  if (!HAS_HUC_UCODE(dev_priv))
>+  if (!HAS_GUC(dev_priv)){
>+  seq_puts(m, "not supported\n");
>   return 0;
>+  }
>+
>
>   seq_puts(m, "HuC firmware status:\n");
>   seq_printf(m, "\tpath: %s\n", huc_fw->path); @@ -2369,8 +2372,11 @@
>static int i915_guc_load_status_info(struct seq_file *m, void *data)
>   struct intel_uc_fw *guc_fw = _priv->guc.fw;
>   u32 tmp, i;
>
>-  if (!HAS_GUC_UCODE(dev_priv))
>+  if (!HAS_GUC(dev_priv)){
>+  seq_puts(m, "not supported\n");
>   return 0;
>+  }
>+
>
>   seq_printf(m, "GuC firmware status:\n");
>   seq_printf(m, "\tpath: %s\n",
>@@ -2465,7 +2471,7 @@ static bool check_guc_submission(struct seq_file *m)
>
>   if (!guc->execbuf_client) {
>   seq_printf(m, "GuC submission %s\n",
>- HAS_GUC_SCHED(dev_priv) ?
>+ HAS_GUC(dev_priv) ?
>  "disabled" :
>  "not supported");
>   return false;
>@@ -2654,7 +2660,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
>*data)
>   bool enabled = false;
>
>   if (!HAS_PSR(dev_priv)) {
>-  seq_puts(m, "PSR not supported\n");
>+  seq_puts(m, "not supported\n");
>   return 0;
>   }
>
>@@ -2807,7 +2813,7 @@ static int i915_runtime_pm_status(struct seq_file *m,
>void *unused)
>   struct pci_dev *pdev = dev_priv->drm.pdev;
>
>   if (!HAS_RUNTIME_PM(dev_priv))
>-  seq_puts(m, "Runtime power management not supported\n");
>+  seq_puts(m, "not supported\n");
>
>   seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
>   seq_printf(m, "IRQs disabled: %s\n",
>@@ -3683,7 +3689,7 @@ static void drrs_status_per_crtc(struct seq_file *m,
>   mutex_unlock(>mutex);
>   } else {
>   /* DRRS not supported. Print the VBT parameter*/
>-  seq_puts(m, "\tDRRS Supported : No");
>+  seq_puts(m, "not supported\n");
>   }
>   seq_puts(m, "\n");
> }
>diff --git 

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

[Oscar Mateo]

On 09/28/2017 08:00 AM, Mika Kuoppala wrote:

We have no means to check write only registers as
this would need access through context image. For now we
know that cnl has a one such register, 0xe5f0 which is used
to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting
the context image without and with workaround applied:

0xa840: 0xe5f0 0x0800
0xa840: 0xe5f0 0x0820

we can conclude that the workaround setup is working right
in this particular case.

Add a write only list and add register 0xe5f0 into this list.
This is a temporary solution until a more capable context image
checker emerges.

v2: add code comment about adhocness (Petri)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102943
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Petri Latvala 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---


Acked-by: Oscar Mateo 


  tests/gem_workarounds.c | 38 +-
  1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
index d6641bd5..5e30a7b8 100644
--- a/tests/gem_workarounds.c
+++ b/tests/gem_workarounds.c
@@ -29,6 +29,8 @@
  
  #include 
  
+static int gen;

+
  enum operation {
GPU_RESET,
SUSPEND_RESUME,
@@ -41,6 +43,21 @@ struct intel_wa_reg {
uint32_t mask;
  };
  
+static struct write_only_list {

+   unsigned int gen;
+   uint32_t addr;
+} wo_list[] = {
+   { 10, 0xE5F0 } /* WaForceContextSaveRestoreNonCoherent:cnl */
+
+   /*
+* FIXME: If you are contemplating adding stuff here
+* consider this as a temporary solution. You need to
+* manually check from context image that your workaround
+* is having an effect. Consider creating a context image
+* validator to act as a superior solution.
+*/
+};
+
  static struct intel_wa_reg *wa_regs;
  static int num_wa_regs;
  
@@ -64,6 +81,21 @@ static void test_suspend_resume(void)

igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
  }
  
+static bool write_only(const uint32_t addr)

+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(wo_list); i++) {
+   if (gen == wo_list[i].gen &&
+   addr == wo_list[i].addr) {
+   igt_info("Skipping check for 0x%x due to write only\n", 
addr);
+   return true;
+   }
+   }
+
+   return false;
+}
+
  static int workaround_fail_count(void)
  {
int i, fail_count = 0;
@@ -85,6 +117,9 @@ static int workaround_fail_count(void)
  wa_regs[i].addr, wa_regs[i].value, wa_regs[i].mask,
  val, ok ? "OK" : "FAIL");
  
+		if (write_only(wa_regs[i].addr))

+   continue;
+
if (!ok) {
igt_warn("0x%05X\t0x%08X\t0x%08X\t0x%08X\t%s\n",
 wa_regs[i].addr, wa_regs[i].value,
@@ -124,7 +159,6 @@ igt_main
  {
igt_fixture {
int device = drm_open_driver_master(DRIVER_INTEL);
-   const int gen = intel_gen(intel_get_drm_devid(device));
struct pci_device *pci_dev;
FILE *file;
char *line = NULL;
@@ -133,6 +167,8 @@ igt_main
  
  		igt_require_gem(device);
  
+		gen = intel_gen(intel_get_drm_devid(device));

+
pci_dev = intel_get_pci_device();
igt_require(pci_dev);
  


___
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 DVFS.

[Patchwork]

== Series Details ==

Series: Introduce DVFS.
URL   : https://patchwork.freedesktop.org/series/30922/
State : success

== Summary ==

Series 30922v1 Introduce DVFS.
https://patchwork.freedesktop.org/api/1.0/series/30922/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-glk-1) fdo#102777 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:473s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:416s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:513s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:500s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:491s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:486s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:566s
fi-cnl-y total:289  pass:210  dwarn:12  dfail:31  fail:2   skip:33  
time:624s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-glk-1 total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
time:568s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:426s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:403s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:471s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:544s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:754s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:474s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:561s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:418s

0369ecdbb55495dd4671ad33d375f37d0707b629 drm-tip: 2017y-09m-28d-20h-01m-55s UTC 
integration manifest
ac06c12d8d06 drm/i915: Extend DVFS function back to Skylake.
451034bed2be drm/i915/cnl: DVFS for PLL disabling
6446bda2c77d drm/i915/cnl: DVFS for PLL enabling
2484dcc7c187 drm/i915/cnl: Expose DVFS change functions
07076582a9a9 drm/i915/cnl: extract cnl_dvfs_{pre, post}_change

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add has_psr-flag to gen9lp

[Patchwork]

== Series Details ==

Series: drm/i915: Add has_psr-flag to gen9lp
URL   : https://patchwork.freedesktop.org/series/28488/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252 +1

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

shard-hswtotal:2429 pass:1332 dwarn:5   dfail:0   fail:9   skip:1083 
time:9908s

== Logs ==

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

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

[Oscar Mateo]

On 09/28/2017 01:56 PM, Oscar Mateo wrote:



On 09/28/2017 02:46 AM, Chris Wilson wrote:

Stealing the thread for another gem_workarounds conundrum.

After a reset, we lose the RING_FORCE_TO_NONPRIV registers. If they
where in the context image as we presumed, the values would be retained
and they can be read back from before reset, so it's not the case of
write-only register!

So are they the mythical powercontext but require an LRI after reset to
restore the settings for all logical contexts? Or can we make those into
regular MMIO?
-Chris


I cannot see these in any the context image formats, no matter the 
GEN, so I suspect they are regular (but privileged) MMIO registers. I 
think by "These are global registers and power context save/restored" 
they simply mean that they survive RC6.


And, sure enough, these registers do appear in the "Render Engine Power 
Context" (save/restored by PM), not to be confused with the "Register 
State Context" (the usual HW context)

___
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/glk, cnl: Implement WaDisableScalarClockGating

[Patchwork]

== Series Details ==

Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating
URL   : https://patchwork.freedesktop.org/series/31094/
State : success

== Summary ==

Series 31094v1 drm/i915/glk, cnl: Implement WaDisableScalarClockGating
https://patchwork.freedesktop.org/api/1.0/series/31094/revisions/1/mbox/

Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (fi-glk-1) fdo#102777

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:473s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:420s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:517s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:490s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:484s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:556s
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:623s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:426s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:566s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:425s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:405s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:493s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:466s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:461s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:581s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:597s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:542s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:752s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:481s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:580s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:420s

0369ecdbb55495dd4671ad33d375f37d0707b629 drm-tip: 2017y-09m-28d-20h-01m-55s UTC 
integration manifest
c31be1a11e6f drm/i915/glk, cnl: Implement WaDisableScalarClockGating

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,01/13] drm/i915: Inherit Kabylake platform features from Skylake

[Patchwork]

== Series Details ==

Series: series starting with [v3,01/13] drm/i915: Inherit Kabylake platform 
features from Skylake
URL   : https://patchwork.freedesktop.org/series/31092/
State : failure

== Summary ==

Series 31092v1 series starting with [v3,01/13] drm/i915: Inherit Kabylake 
platform features from Skylake
https://patchwork.freedesktop.org/api/1.0/series/31092/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-FAIL (fi-kbl-7560u)
Subgroup basic-s4-devices:
pass   -> DMESG-FAIL (fi-kbl-7560u)
Test gem_flink_basic:
Subgroup bad-flink:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup bad-open:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup double-flink:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup flink-lifetime:
pass   -> DMESG-WARN (fi-kbl-7560u)
Test gem_linear_blits:
Subgroup basic:
pass   -> INCOMPLETE (fi-kbl-7560u)
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> PASS   (fi-glk-1) fdo#102777

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:418s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:513s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:492s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:490s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:554s
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:635s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:567s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:426s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:402s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:491s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:468s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7560u total:125  pass:105  dwarn:5   dfail:2   fail:0   skip:12 
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:592s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:547s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:750s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:480s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:566s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:414s

0369ecdbb55495dd4671ad33d375f37d0707b629 drm-tip: 2017y-09m-28d-20h-01m-55s UTC 
integration manifest
3e277553d4d8 drm/i915/scheduler: Support user-defined priorities
a5030d913ab3 drm/i915/execlists: Preemption!
63ffd55487c7 drm/i915: Expand I915_PARAM_HAS_SCHEDULER into a capability bitmask
a31c4b4f571f drm/i915/execlists: Keep request->priority for its lifetime
82888bf7da72 drm/i915/execlists: Move bdw GPGPU w/a to emit_bb
7de95eec2d8f drm/i915: Introduce a preempt context
ae3190509e53 drm/i915/execlists: Distinguish the incomplete context notifies
4709aab0ba2c drm/i915/preempt: Default to disabled mid-command preemption levels
d7167e0c76f1 drm/i915/preempt: Fix WaEnablePreemptionGranularityControlByUMD
6bc58077f28c drm/i915/execlists: Cache the last priolist lookup
a1ecbabad013 drm/i915: Give the invalid priority a magic name
cd27e7c63660 drm/i915/execlists: Move request unwinding to a separate function
a08eebaf7b68 drm/i915: Inherit Kabylake platform features from Skylake

== Logs ==

For more details see: 

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Allow 2 pixel per clock on Cannonlake.

[Paulo Zanoni]

Em Ter, 2017-09-26 às 12:43 -0700, Rodrigo Vivi escreveu:
> This is heavily based on a initial patch provided by Ville
> plus all changes provided later by Ander.
> 
> As Geminilake, Cannonlake also supports 2 pixels per clock.
> 
> Different from Geminilake we are not implementing the 99% Wa.
> But we can revisit that decision later if we find out
> any limitation on later CNL SKUs.
> 
> v2: Rebase on top of commit 'd305e0614601 ("drm/i915: Track
> minimum acceptable cdclk instead of "minimum dotclock")'

Reviewed-by: Paulo Zanoni 

> 
> Cc: Paulo Zanoni 
> Cc: Ville Syrjälä 
> Cc: Dhinakaran Pandiyan 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c   | 7 +--
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 3 ++-
>  3 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index d6befabd6ed5..eabaf57b83ef 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1995,12 +1995,7 @@ static int intel_compute_max_dotclk(struct
> drm_i915_private *dev_priv)
>   int max_cdclk_freq = dev_priv->max_cdclk_freq;
>  
>   if (INTEL_GEN(dev_priv) >= 10)
> - /*
> -  * FIXME: Allow '2 * max_cdclk_freq'
> -  * once DDI clock voltage requirements are
> -  * handled correctly.
> -  */
> - return max_cdclk_freq;
> + return 2 * max_cdclk_freq;
>   else if (IS_GEMINILAKE(dev_priv))
>   /*
>    * FIXME: Limiting to 99% as a temporary workaround.
> See
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 026fa5460fe5..487b43ba3139 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12801,7 +12801,7 @@ skl_max_scale(struct intel_crtc *intel_crtc,
> struct intel_crtc_state *crtc_state
>   crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
>   max_dotclk = to_intel_atomic_state(crtc_state->base.state)-
> >cdclk.logical.cdclk;
>  
> - if (IS_GEMINILAKE(dev_priv))
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
>   max_dotclk *= 2;
>  
>   if (WARN_ON_ONCE(!crtc_clock || max_dotclk < crtc_clock))
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index c66af09e27a7..52c4c194aa51 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3932,6 +3932,7 @@ skl_pipe_downscale_amount(const struct
> intel_crtc_state *crtc_state)
>  int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
>     struct intel_crtc_state *cstate)
>  {
> + struct drm_i915_private *dev_priv = to_i915(intel_crtc-
> >base.dev);
>   struct drm_crtc_state *crtc_state = >base;
>   struct drm_atomic_state *state = crtc_state->state;
>   struct drm_plane *plane;
> @@ -3974,7 +3975,7 @@ int skl_check_pipe_max_pixel_rate(struct
> intel_crtc *intel_crtc,
>   crtc_clock = crtc_state->adjusted_mode.crtc_clock;
>   dotclk = to_intel_atomic_state(state)->cdclk.logical.cdclk;
>  
> - if (IS_GEMINILAKE(to_i915(intel_crtc->base.dev)))
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
>   dotclk *= 2;
>  
>   pipe_max_pixel_rate = div_round_up_u32_fixed16(dotclk,
> pipe_downscale);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Oscar Mateo]

On 09/28/2017 02:46 AM, Chris Wilson wrote:

Stealing the thread for another gem_workarounds conundrum.

After a reset, we lose the RING_FORCE_TO_NONPRIV registers. If they
where in the context image as we presumed, the values would be retained
and they can be read back from before reset, so it's not the case of
write-only register!

So are they the mythical powercontext but require an LRI after reset to
restore the settings for all logical contexts? Or can we make those into
regular MMIO?
-Chris


I cannot see these in any the context image formats, no matter the GEN, 
so I suspect they are regular (but privileged) MMIO registers. I think 
by "These are global registers and power context save/restored" they 
simply mean that they survive RC6.

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for 2-in-1: Organize feature inheritance and disable IPC.

[Patchwork]

== Series Details ==

Series: 2-in-1: Organize feature inheritance and disable IPC.
URL   : https://patchwork.freedesktop.org/series/31090/
State : failure

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test gem_tiled_pread_pwrite:
pass   -> INCOMPLETE (shard-hsw)

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

shard-hswtotal:2382 pass:1304 dwarn:5   dfail:0   fail:10  skip:1062 
time:9683s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add has_psr-flag to gen9lp

[Patchwork]

== Series Details ==

Series: drm/i915: Add has_psr-flag to gen9lp
URL   : https://patchwork.freedesktop.org/series/28488/
State : success

== Summary ==

Series 28488v1 drm/i915: Add has_psr-flag to gen9lp
https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/

Test kms_psr_sink_crc:
Subgroup psr_basic:
skip   -> PASS   (fi-glk-1)
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> INCOMPLETE (fi-cfl-s) k.org#196765

k.org#196765 https://bugzilla.kernel.org/show_bug.cgi?id=196765

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:451s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:480s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:418s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:519s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:502s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:485s
fi-cfl-s total:288  pass:255  dwarn:1   dfail:0   fail:0   skip:31 
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:635s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:570s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:429s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:403s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:435s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:494s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:462s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:584s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:589s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:542s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:752s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:473s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:559s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:413s

7ae90fb62375c44b198bdffe51c4dee432d4 drm-tip: 2017y-09m-28d-16h-52m-04s UTC 
integration manifest
ce253b356368 drm/i915: Add has_psr-flag to gen9lp

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/glk, cnl: Implement WaDisableScalarClockGating

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 07:54:36PM +, Imre Deak wrote:
> On GLK and CNL enabling a pipe with its pipe scaler enabled will result
> in a FIFO underrun. This happens only once after driver loading or
> system/runtime resume, more specifically after power well 1 gets
> enabled; subsequent modesets seem to be free of underruns. The BSpec
> workaround for this is to disable the pipe scaler clock gating for the
> duration of modeset. Based on my tests disabling clock gating must be
> done before enabling pipe scaling and we can re-enable it after the pipe
> is enabled and one vblank has passed.

Oh! Great!
I had this Wa in my list here, but I was without access to HDSES
and was postponing it...

But now that you mention the bits it was easy to find on BSpec as well.

> 
> For consistency I also checked if plane scaling would cause the same
> problem, but that doesn't seem to trigger this problem.
> 
> The patch is based on an earlier version from Ander.
> 
> Cc: Ander Conselvan de Oliveira 
> Cc: Rodrigo Vivi 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100302
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  8 
>  drivers/gpu/drm/i915/intel_display.c | 25 +
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 82f36dd0cd94..40a3c045d9d0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3811,6 +3811,14 @@ enum {
>  #define   PWM2_GATING_DIS(1 << 14)
>  #define   PWM1_GATING_DIS(1 << 13)
>  
> +#define _CLKGATE_DIS_PSL_A   0x46520
> +#define _CLKGATE_DIS_PSL_B   0x46524
> +#define _CLKGATE_DIS_PSL_C   0x46528
> +#define   DPF_GATING_DIS (1 << 10)

On BSpec they also tells us to disable bits 8 and 9:

"To disable Scaler clock gating, set bits 8, 9, and 10 of 0x46520 (Pipe A), 
0x46524 (Pipe B), or 0x46528 (Pipe C)"

> +
> +#define CLKGATE_DIS_PSL(pipe) \
> + _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B)
> +
>  /*
>   * GEN10 clock gating regs
>   */
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 026fa5460fe5..9d0b5a5596a5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5459,6 +5459,19 @@ static bool hsw_crtc_supports_ips(struct intel_crtc 
> *crtc)
>   return HAS_IPS(to_i915(crtc->base.dev)) && crtc->pipe == PIPE_A;
>  }
>  
> +static void glk_pipe_scaler_clock_gating_wa(struct drm_i915_private 
> *dev_priv,
> + enum pipe pipe, bool apply)
> +{
> + u32 tmp = I915_READ(CLKGATE_DIS_PSL(pipe));
> +
> + if (apply)
> + tmp |= DPF_GATING_DIS;
> + else
> + tmp &= ~DPF_GATING_DIS;
> +
> + I915_WRITE(CLKGATE_DIS_PSL(pipe), tmp);
> +}
> +
>  static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
>   struct drm_atomic_state *old_state)
>  {
> @@ -5469,6 +5482,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
>   struct intel_atomic_state *old_intel_state =
>   to_intel_atomic_state(old_state);
> + bool psl_clkgate_wa;
>  
>   if (WARN_ON(intel_crtc->active))
>   return;
> @@ -5522,6 +5536,12 @@ static void haswell_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   if (!transcoder_is_dsi(cpu_transcoder))
>   intel_ddi_enable_pipe_clock(pipe_config);
>  
> + /* WaDisableScalarClockGating: glk, cnl */

Please also add the BSpec reference Display WA #1180.


> + psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> +  intel_crtc->config->pch_pfit.enabled;
> + if (psl_clkgate_wa)
> + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
> +

Is this place enough? Wouldn't be better to start that on atomic commit before 
we set cdclock
and mainly before we do a pre plane update?

Also on spec they say:
"
Chance of underflows when the Pipe Scaler is enabled during a mode-set while 
the Planes are disabled.
Workaround: Disable the Scaler clock gating when entering a mode-set routine.
The Scaler clock gating should be re-enabled at the end of the mode-set 
sequence.
"

So I wonder if here is not already too late to disable the clock gatings.

>   if (INTEL_GEN(dev_priv) >= 9)
>   skylake_pfit_enable(intel_crtc);
>   else
> @@ -,6 +5575,11 @@ static void haswell_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>  
>   intel_encoders_enable(crtc, pipe_config, old_state);
>  
> + if (psl_clkgate_wa) {
> + intel_wait_for_vblank(dev_priv, pipe);
> + glk_pipe_scaler_clock_gating_wa(dev_priv, 

Re: [Intel-gfx] [PATCH v3 01/13] drm/i915: Inherit Kabylake platform features from Skylake

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-28 20:58:31)
> On Thu, Sep 28, 2017 at 07:38:58PM +, Chris Wilson wrote:
> > I recently tried to update the gen9 feature matrix and to my unpleasant
> > surprise found that Kabylake still acted like Broadwell and didn't
> > enable the feature. This is because kbl/cfl are inheriting their
> > defaults from Broadwell and not Skylake.
> 
> Oh, if this is blocking all this series here we can move with this
> and I do the re-org on top of this later since that one depends on
> that has_ipc discussion...

You have a few hours to get the "2-in-1" ready :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Use memset64() to prefill the GTT page

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-09-26 11:30:50)
> 
> On 26/09/2017 10:53, Chris Wilson wrote:
> > Take advantage of optimised memset64() instead of open coding it to
> > prefill the GTT pages.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> > Needs backmerge from 4.14-rc1, but it's tantalisingly close.
> > ---
> >   drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 0477949805e1..74062897d331 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -486,10 +486,8 @@ static void fill_page_dma(struct i915_address_space 
> > *vm,
> > const u64 val)
> >   {
> >   u64 * const vaddr = kmap_atomic(p->page);
> > - int i;
> >   
> > - for (i = 0; i < 512; i++)
> > - vaddr[i] = val;
> > + memset64(vaddr, val, PAGE_SIZE / sizeof(val));
> >   
> >   kunmap_atomic(vaddr);
> >   }
> > 
> 
> Reviewed-by: Tvrtko Ursulin 

Back merge landed, so pushed. Thanks for the review.
-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 2-in-1: Organize feature inheritance and disable IPC.

[Patchwork]

== Series Details ==

Series: 2-in-1: Organize feature inheritance and disable IPC.
URL   : https://patchwork.freedesktop.org/series/31090/
State : success

== Summary ==

Series 31090v1 2-in-1: Organize feature inheritance and disable IPC.
https://patchwork.freedesktop.org/api/1.0/series/31090/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-kbl-7560u) fdo#102846
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-glk-1) fdo#102777

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:472s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:417s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:514s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:487s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:488s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:568s
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:620s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:420s
fi-glk-1 total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
time:567s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:424s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:402s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:428s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:494s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:461s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:472s
fi-kbl-7560u total:247  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:590s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:540s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:753s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:477s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:567s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:416s

7ae90fb62375c44b198bdffe51c4dee432d4 drm-tip: 2017y-09m-28d-16h-52m-04s UTC 
integration manifest
c699d2def182 drm/i915: Extend WaDisableIPC to all platforms.
c515074dfeaa drm/i915: Organize GLK_COLORS.
92d0768575ef drm/i915: Organize GEN features inheritance.
a8ec02db11f8 drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC.

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 01/13] drm/i915: Inherit Kabylake platform features from Skylake

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 07:38:58PM +, Chris Wilson wrote:
> I recently tried to update the gen9 feature matrix and to my unpleasant
> surprise found that Kabylake still acted like Broadwell and didn't
> enable the feature. This is because kbl/cfl are inheriting their
> defaults from Broadwell and not Skylake.

Oh, if this is blocking all this series here we can move with this
and I do the re-org on top of this later since that one depends on
that has_ipc discussion...

only 1 nip-tick below..

> 
> Signed-off-by: Chris Wilson 
> Cc: Rodrigo Vivi 
> Cc: Paulo Zanoni 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 21 +
>  1 file changed, 5 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index da60866b6628..01d4b569b2cc 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -495,13 +495,9 @@ static const struct intel_device_info 
> intel_geminilake_info __initconst = {
>  };
>  
>  #define KBL_PLATFORM \
> - BDW_FEATURES, \
> - .gen = 9, \
> + SKL_PLATFORM, \
>   .platform = INTEL_KABYLAKE, \
> - .has_csr = 1, \
> - .has_guc = 1, \
> - .has_ipc = 1, \
> - .ddb_size = 896
> + .has_ipc = 1
>  
>  static const struct intel_device_info intel_kabylake_gt1_info __initconst = {
>   KBL_PLATFORM,
> @@ -520,13 +516,8 @@ static const struct intel_device_info 
> intel_kabylake_gt3_info __initconst = {
>  };
>  
>  #define CFL_PLATFORM \
> - BDW_FEATURES, \
> - .gen = 9, \
> - .platform = INTEL_COFFEELAKE, \
> - .has_csr = 1, \
> - .has_guc = 1, \
> - .has_ipc = 1, \
> - .ddb_size = 896
> + KBL_PLATFORM, \
> + .platform = INTEL_COFFEELAKE
>  
>  static const struct intel_device_info intel_coffeelake_gt1_info __initconst 
> = {
>   CFL_PLATFORM,
> @@ -545,14 +536,12 @@ static const struct intel_device_info 
> intel_coffeelake_gt3_info __initconst = {
>  };
>  
>  static const struct intel_device_info intel_cannonlake_gt2_info __initconst 
> = {
> - BDW_FEATURES,
> + SKL_PLATFORM,

KBL_PLATFORM or we end up removing has_ipc from cnl...
(CFL_PLATFORM also works)

>   .is_alpha_support = 1,
>   .platform = INTEL_CANNONLAKE,
>   .gen = 10,
>   .gt = 2,
>   .ddb_size = 1024,
> - .has_csr = 1,
> - .has_ipc = 1,
>   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
>  };
>  
> -- 
> 2.14.2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/glk, cnl: Implement WaDisableScalarClockGating

[Imre Deak]

On GLK and CNL enabling a pipe with its pipe scaler enabled will result
in a FIFO underrun. This happens only once after driver loading or
system/runtime resume, more specifically after power well 1 gets
enabled; subsequent modesets seem to be free of underruns. The BSpec
workaround for this is to disable the pipe scaler clock gating for the
duration of modeset. Based on my tests disabling clock gating must be
done before enabling pipe scaling and we can re-enable it after the pipe
is enabled and one vblank has passed.

For consistency I also checked if plane scaling would cause the same
problem, but that doesn't seem to trigger this problem.

The patch is based on an earlier version from Ander.

Cc: Ander Conselvan de Oliveira 
Cc: Rodrigo Vivi 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100302
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h  |  8 
 drivers/gpu/drm/i915/intel_display.c | 25 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 82f36dd0cd94..40a3c045d9d0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3811,6 +3811,14 @@ enum {
 #define   PWM2_GATING_DIS  (1 << 14)
 #define   PWM1_GATING_DIS  (1 << 13)
 
+#define _CLKGATE_DIS_PSL_A 0x46520
+#define _CLKGATE_DIS_PSL_B 0x46524
+#define _CLKGATE_DIS_PSL_C 0x46528
+#define   DPF_GATING_DIS   (1 << 10)
+
+#define CLKGATE_DIS_PSL(pipe) \
+   _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B)
+
 /*
  * GEN10 clock gating regs
  */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 026fa5460fe5..9d0b5a5596a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5459,6 +5459,19 @@ static bool hsw_crtc_supports_ips(struct intel_crtc 
*crtc)
return HAS_IPS(to_i915(crtc->base.dev)) && crtc->pipe == PIPE_A;
 }
 
+static void glk_pipe_scaler_clock_gating_wa(struct drm_i915_private *dev_priv,
+   enum pipe pipe, bool apply)
+{
+   u32 tmp = I915_READ(CLKGATE_DIS_PSL(pipe));
+
+   if (apply)
+   tmp |= DPF_GATING_DIS;
+   else
+   tmp &= ~DPF_GATING_DIS;
+
+   I915_WRITE(CLKGATE_DIS_PSL(pipe), tmp);
+}
+
 static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
struct drm_atomic_state *old_state)
 {
@@ -5469,6 +5482,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
struct intel_atomic_state *old_intel_state =
to_intel_atomic_state(old_state);
+   bool psl_clkgate_wa;
 
if (WARN_ON(intel_crtc->active))
return;
@@ -5522,6 +5536,12 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_pipe_clock(pipe_config);
 
+   /* WaDisableScalarClockGating: glk, cnl */
+   psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
+intel_crtc->config->pch_pfit.enabled;
+   if (psl_clkgate_wa)
+   glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
+
if (INTEL_GEN(dev_priv) >= 9)
skylake_pfit_enable(intel_crtc);
else
@@ -,6 +5575,11 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
 
intel_encoders_enable(crtc, pipe_config, old_state);
 
+   if (psl_clkgate_wa) {
+   intel_wait_for_vblank(dev_priv, pipe);
+   glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false);
+   }
+
if (intel_crtc->config->has_pch_encoder) {
intel_wait_for_vblank(dev_priv, pipe);
intel_wait_for_vblank(dev_priv, pipe);
-- 
2.13.2

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

[Intel-gfx] [PATCH v3 11/13] drm/i915: Expand I915_PARAM_HAS_SCHEDULER into a capability bitmask

[Chris Wilson]

In the next few patches, we wish to enable different features for the
scheduler, some which may subtlety change ABI (e.g. allow requests to be
reordered under different circumstances). So we need to make sure
userspace is cognizant of the changes (if they care), by which we employ
the usual method of a GETPARAM. We already have an
I915_PARAM_HAS_SCHEDULER (which notes the existing ability to reorder
requests to avoid bubbles), and now we wish to extend that to be a
bitmask to describe the different capabilities implemented.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 +++--
 include/uapi/drm/i915_drm.h | 9 -
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59ac9199b35d..c5070f859c66 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -367,8 +367,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = i915_gem_mmap_gtt_version();
break;
case I915_PARAM_HAS_SCHEDULER:
-   value = dev_priv->engine[RCS] &&
-   dev_priv->engine[RCS]->schedule;
+   value = 0;
+   if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule)
+   value |= I915_SCHEDULER_CAP_ENABLED;
break;
case I915_PARAM_MMAP_VERSION:
/* Remember to bump this if the version changes! */
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index fe25a01c81f2..aa4a3b20ef6b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -397,10 +397,17 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
 
-/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
+/*
+ * Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
+ * The param returns a capability bitmask, nonzero implies that the scheduler
+ * is enabled, with different features present according to the mask.
  */
 #define I915_PARAM_HAS_SCHEDULER41
+#define   I915_SCHEDULER_CAP_ENABLED   (1ul << 0)
+#define   I915_SCHEDULER_CAP_PRIORITY  (1ul << 1)
+#define   I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
+
 #define I915_PARAM_HUC_STATUS   42
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 03/13] drm/i915: Give the invalid priority a magic name

[Chris Wilson]

We use INT_MIN to denote the priority of a request that has not been
submitted to the scheduler; we treat INT_MIN as an invalid priority and
initialise the request to it. Give the value a name so it stands out.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_request.h | 1 +
 drivers/gpu/drm/i915/intel_lrc.c| 4 +++-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 4eb1a76731b2..14956d899911 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -186,7 +186,7 @@ i915_priotree_init(struct i915_priotree *pt)
INIT_LIST_HEAD(>signalers_list);
INIT_LIST_HEAD(>waiters_list);
INIT_LIST_HEAD(>link);
-   pt->priority = INT_MIN;
+   pt->priority = I915_PRIORITY_INVALID;
 }
 
 static int reset_all_global_seqno(struct drm_i915_private *i915, u32 seqno)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 96eb52471dad..6b9e992d01de 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -72,6 +72,7 @@ struct i915_priotree {
 #define I915_PRIORITY_MAX 1024
 #define I915_PRIORITY_NORMAL 0
 #define I915_PRIORITY_MIN (-I915_PRIORITY_MAX)
+#define I915_PRIORITY_INVALID INT_MIN
 };
 
 struct i915_gem_capture_list {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cbac2fff8e4d..303bb2c0b3ce 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -863,6 +863,8 @@ static void execlists_schedule(struct drm_i915_gem_request 
*request, int prio)
struct i915_dependency stack;
LIST_HEAD(dfs);
 
+   GEM_BUG_ON(prio == I915_PRIORITY_INVALID);
+
if (prio <= READ_ONCE(request->priotree.priority))
return;
 
@@ -911,7 +913,7 @@ static void execlists_schedule(struct drm_i915_gem_request 
*request, int prio)
 * execlists_submit_request()), we can set our own priority and skip
 * acquiring the engine locks.
 */
-   if (request->priotree.priority == INT_MIN) {
+   if (request->priotree.priority == I915_PRIORITY_INVALID) {
GEM_BUG_ON(!list_empty(>priotree.link));
request->priotree.priority = prio;
if (stack.dfs_link.next == stack.dfs_link.prev)
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 01/13] drm/i915: Inherit Kabylake platform features from Skylake

[Chris Wilson]

I recently tried to update the gen9 feature matrix and to my unpleasant
surprise found that Kabylake still acted like Broadwell and didn't
enable the feature. This is because kbl/cfl are inheriting their
defaults from Broadwell and not Skylake.

Signed-off-by: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_pci.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index da60866b6628..01d4b569b2cc 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -495,13 +495,9 @@ static const struct intel_device_info 
intel_geminilake_info __initconst = {
 };
 
 #define KBL_PLATFORM \
-   BDW_FEATURES, \
-   .gen = 9, \
+   SKL_PLATFORM, \
.platform = INTEL_KABYLAKE, \
-   .has_csr = 1, \
-   .has_guc = 1, \
-   .has_ipc = 1, \
-   .ddb_size = 896
+   .has_ipc = 1
 
 static const struct intel_device_info intel_kabylake_gt1_info __initconst = {
KBL_PLATFORM,
@@ -520,13 +516,8 @@ static const struct intel_device_info 
intel_kabylake_gt3_info __initconst = {
 };
 
 #define CFL_PLATFORM \
-   BDW_FEATURES, \
-   .gen = 9, \
-   .platform = INTEL_COFFEELAKE, \
-   .has_csr = 1, \
-   .has_guc = 1, \
-   .has_ipc = 1, \
-   .ddb_size = 896
+   KBL_PLATFORM, \
+   .platform = INTEL_COFFEELAKE
 
 static const struct intel_device_info intel_coffeelake_gt1_info __initconst = {
CFL_PLATFORM,
@@ -545,14 +536,12 @@ static const struct intel_device_info 
intel_coffeelake_gt3_info __initconst = {
 };
 
 static const struct intel_device_info intel_cannonlake_gt2_info __initconst = {
-   BDW_FEATURES,
+   SKL_PLATFORM,
.is_alpha_support = 1,
.platform = INTEL_CANNONLAKE,
.gen = 10,
.gt = 2,
.ddb_size = 1024,
-   .has_csr = 1,
-   .has_ipc = 1,
.color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
 };
 
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 10/13] drm/i915/execlists: Keep request->priority for its lifetime

[Chris Wilson]

With preemption, we will want to "unsubmit" a request, taking it back
from the hw and returning it to the priority sorted execution list. In
order to know where to insert it into that list, we need to remember
its adjust priority (which may change even as it was being executed).

This also affects reset for execlists as we are now unsubmitting the
requests following the reset (rather than directly writing the ELSP for
the inflight contexts). This turns reset into an accidental preemption
point, as after the reset we may choose a different pair of contexts to
submit to hw.

GuC is not updated as this series doesn't add preemption to the GuC
submission, and so it can keep benefiting from the early pruning of the
DFS inside execlists_schedule() for a little longer. We also need to
find a way of reducing the cost of that DFS...

v2: Include priority in error-state

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Reviewed-by: Michał Winiarski 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++
 drivers/gpu/drm/i915/intel_lrc.c  | 14 ++
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b08114116654..85c5b3c707c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -982,6 +982,7 @@ struct i915_gpu_state {
pid_t pid;
u32 handle;
u32 hw_id;
+   int priority;
int ban_score;
int active;
int guilty;
@@ -1004,6 +1005,7 @@ struct i915_gpu_state {
long jiffies;
pid_t pid;
u32 context;
+   int priority;
int ban_score;
u32 seqno;
u32 head;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index c14552ab270b..dc91b32d699e 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -377,9 +377,9 @@ static void error_print_request(struct 
drm_i915_error_state_buf *m,
if (!erq->seqno)
return;
 
-   err_printf(m, "%s pid %d, ban score %d, seqno %8x:%08x, emitted %dms 
ago, head %08x, tail %08x\n",
+   err_printf(m, "%s pid %d, ban score %d, seqno %8x:%08x, prio %d, 
emitted %dms ago, head %08x, tail %08x\n",
   prefix, erq->pid, erq->ban_score,
-  erq->context, erq->seqno,
+  erq->context, erq->seqno, erq->priority,
   jiffies_to_msecs(jiffies - erq->jiffies),
   erq->head, erq->tail);
 }
@@ -388,9 +388,9 @@ static void error_print_context(struct 
drm_i915_error_state_buf *m,
const char *header,
const struct drm_i915_error_context *ctx)
 {
-   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, ban score %d guilty %d 
active %d\n",
+   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, prio %d, ban score %d 
guilty %d active %d\n",
   header, ctx->comm, ctx->pid, ctx->handle, ctx->hw_id,
-  ctx->ban_score, ctx->guilty, ctx->active);
+  ctx->priority, ctx->ban_score, ctx->guilty, ctx->active);
 }
 
 static void error_print_engine(struct drm_i915_error_state_buf *m,
@@ -1271,6 +1271,7 @@ static void record_request(struct drm_i915_gem_request 
*request,
   struct drm_i915_error_request *erq)
 {
erq->context = request->ctx->hw_id;
+   erq->priority = request->priotree.priority;
erq->ban_score = atomic_read(>ctx->ban_score);
erq->seqno = request->global_seqno;
erq->jiffies = request->emitted_jiffies;
@@ -1364,6 +1365,7 @@ static void record_context(struct drm_i915_error_context 
*e,
 
e->handle = ctx->user_handle;
e->hw_id = ctx->hw_id;
+   e->priority = ctx->priority;
e->ban_score = atomic_read(>ban_score);
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e5b470ce43e8..02ea1e4e098b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -585,8 +585,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
}
 
INIT_LIST_HEAD(>priotree.link);
-   rq->priotree.priority = INT_MAX;
-
__i915_gem_request_submit(rq);
trace_i915_gem_request_in(rq, port_index(port, 
execlists));
last = rq;

[Intel-gfx] [PATCH v3 06/13] drm/i915/preempt: Default to disabled mid-command preemption levels

[Chris Wilson]

From: Michał Winiarski 

Supporting fine-granularity preemption levels may require changes in
userspace batch buffer programming. Therefore, we need to fallback to
safe default values, rather that use hardware defaults. Userspace is
still able to enable fine-granularity, since we're whitelisting the
register controlling it in WaEnablePreemptionGranularityControlByUMD.

v2: Extend w/a to cover Cannonlake

Signed-off-by: Michał Winiarski 
Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_reg.h|  6 ++
 drivers/gpu/drm/i915/intel_engine_cs.c | 25 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee0d4f14ac98..70465320a0ed 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6993,6 +6993,12 @@ enum {
 #define GEN9_CS_DEBUG_MODE1_MMIO(0x20ec)
 #define GEN9_CTX_PREEMPT_REG   _MMIO(0x2248)
 #define GEN8_CS_CHICKEN1   _MMIO(0x2580)
+#define GEN9_PREEMPT_3D_OBJECT_LEVEL   (1<<0)
+#define GEN9_PREEMPT_GPGPU_LEVEL(hi, lo)   (((hi) << 2) | ((lo) << 1))
+#define GEN9_PREEMPT_GPGPU_MID_THREAD_LEVELGEN9_PREEMPT_GPGPU_LEVEL(0, 0)
+#define GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL  GEN9_PREEMPT_GPGPU_LEVEL(0, 1)
+#define GEN9_PREEMPT_GPGPU_COMMAND_LEVEL   GEN9_PREEMPT_GPGPU_LEVEL(1, 0)
+#define GEN9_PREEMPT_GPGPU_LEVEL_MASK  GEN9_PREEMPT_GPGPU_LEVEL(1, 1)
 
 /* GEN7 chicken */
 #define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 040c85e496fa..2460d78581b4 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1071,6 +1071,24 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
GEN8_LQSC_FLUSH_COHERENT_LINES));
 
+   /*
+* Supporting preemption with fine-granularity requires changes in the
+* batch buffer programming. Since we can't break old userspace, we
+* need to set our default preemption level to safe value. Userspace is
+* still able to use more fine-grained preemption levels, since in
+* WaEnablePreemptionGranularityControlByUMD we're whitelisting the
+* per-ctx register. As such, WaDisableMidCmdPreemption is not a real
+* HW workaround, but merely a way to start using preemption while
+* maintaining old contract with userspace.
+*/
+
+   /* WaDisable3DMidCmdPreemption:skl,bxt,glk,cfl,[cnl] */
+   WA_CLR_BIT_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_3D_OBJECT_LEVEL);
+
+   /* WaDisableGPGPUMidCmdPreemption:skl,bxt,blk,cfl,[cnl] */
+   WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
+   GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
+
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
if (ret)
@@ -1272,6 +1290,13 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
/* FtrEnableFastAnisoL1BankingFix: cnl */
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3, CNL_FAST_ANISO_L1_BANKING_FIX);
 
+   /* WaDisable3DMidCmdPreemption:cnl */
+   WA_CLR_BIT_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_3D_OBJECT_LEVEL);
+
+   /* WaDisableGPGPUMidCmdPreemption:cnl */
+   WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
+   GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
+
/* WaEnablePreemptionGranularityControlByUMD:cnl */
I915_WRITE(GEN7_FF_SLICE_CS_CHICKEN1,
   _MASKED_BIT_ENABLE(GEN9_FFSC_PERCTX_PREEMPT_CTRL));
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 12/13] drm/i915/execlists: Preemption!

[Chris Wilson]

When we write to ELSP, it triggers a context preemption at the earliest
arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
operations and the explicit MI_ARB_CHECK). If this is to the same
context, it triggers a LITE_RESTORE where the RING_TAIL is merely
updated (used currently to chain requests from the same context
together, avoiding bubbles). However, if it is to a different context, a
full context-switch is performed and it will start to execute the new
context saving the image of the old for later execution.

Previously we avoided preemption by only submitting a new context when
the old was idle. But now we wish embrace it, and if the new request has
a higher priority than the currently executing request, we write to the
ELSP regardless, thus triggering preemption, but we tell the GPU to
switch to our special preemption context (not the target). In the
context-switch interrupt handler, we know that the previous contexts
have finished execution and so can unwind all the incomplete requests
and compute the new highest priority request to execute.

It would be feasible to avoid the switch-to-idle intermediate by
programming the ELSP with the target context. The difficulty is in
tracking which request that should be whilst maintaining the dependency
change, the error comes in with coalesced requests. As we only track the
most recent request and its priority, we may run into the issue of being
tricked in preempting a high priority request that was followed by a
low priority request from the same context (e.g. for PI); worse still
that earlier request may be our own dependency and the order then broken
by preemption. By injecting the switch-to-idle and then recomputing the
priority queue, we avoid the issue with tracking in-flight coalesced
requests. Having tried the preempt-to-busy approach, and failed to find
a way around the coalesced priority issue, Michal's original proposal to
inject an idle context (based on handling GuC preemption) succeeds.

The current heuristic for deciding when to preempt are only if the new
request is of higher priority, and has the privileged priority of
greater than 0. Note that the scheduler remains unfair!

v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
Since, the feature is now conditional and not always available when we
have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
capability mask).
v3: Stylistic tweaks.

Suggested-by: Michal Winiarski 
Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Tvrtko Ursulin 
Cc: Arkadiusz Hiler 
Cc: Mika Kuoppala 
Cc: Ben Widawsky 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.c |   9 ++-
 drivers/gpu/drm/i915/i915_irq.c |   6 +-
 drivers/gpu/drm/i915/i915_pci.c |   1 +
 drivers/gpu/drm/i915/intel_lrc.c| 137 
 drivers/gpu/drm/i915/intel_ringbuffer.h |   2 +
 5 files changed, 119 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c5070f859c66..a3bb352a581b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -368,9 +368,16 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
break;
case I915_PARAM_HAS_SCHEDULER:
value = 0;
-   if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule)
+   if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule) {
value |= I915_SCHEDULER_CAP_ENABLED;
+
+   if (INTEL_INFO(dev_priv)->has_logical_ring_preemption &&
+   i915_modparams.enable_execlists &&
+   !i915_modparams.enable_guc_submission)
+   value |= I915_SCHEDULER_CAP_PREEMPTION;
+   }
break;
+
case I915_PARAM_MMAP_VERSION:
/* Remember to bump this if the version changes! */
case I915_PARAM_HAS_GEM:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index efd7827ff181..8620fbd22c55 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1382,10 +1382,8 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
bool tasklet = false;
 
if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
-   if (port_count(>port[0])) {
-   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
-   tasklet = true;
-   }
+   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   tasklet = true;
}
 
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
diff 

[Intel-gfx] [PATCH v3 13/13] drm/i915/scheduler: Support user-defined priorities

[Chris Wilson]

Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.

Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).

Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.

Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.

This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.

For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt

EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."

so we can map

PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023

They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).

v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.

Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.c |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
 drivers/gpu/drm/i915/i915_gem_request.h | 14 ++
 include/uapi/drm/i915_drm.h |  7 +++
 4 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a3bb352a581b..147d9fa91d1b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -370,6 +370,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = 0;
if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule) {
value |= I915_SCHEDULER_CAP_ENABLED;
+   value |= I915_SCHEDULER_CAP_PRIORITY;
 
if (INTEL_INFO(dev_priv)->has_logical_ring_preemption &&
i915_modparams.enable_execlists &&
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f299b0a7c765..a2ed5fbef351 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1070,6 +1070,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_BANNABLE:
args->value = i915_gem_context_is_bannable(ctx);
break;
+   case I915_CONTEXT_PARAM_PRIORITY:
+   args->value = ctx->priority;
+   break;
default:
ret = -EINVAL;
break;
@@ -1125,6 +1128,26 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
else
i915_gem_context_clear_bannable(ctx);
break;
+
+   case I915_CONTEXT_PARAM_PRIORITY:
+   {
+   int priority = args->value;
+
+   if (args->size)
+   ret = -EINVAL;
+   else if (!to_i915(dev)->engine[RCS]->schedule)
+   ret = -ENODEV;
+   else if (priority > I915_CONTEXT_MAX_USER_PRIORITY ||
+priority < I915_CONTEXT_MIN_USER_PRIORITY)
+   ret = -EINVAL;
+   else if (priority > I915_CONTEXT_DEFAULT_PRIORITY &&
+!capable(CAP_SYS_NICE))
+   ret = -EPERM;
+   else
+   

[Intel-gfx] [PATCH v3 05/13] drm/i915/preempt: Fix WaEnablePreemptionGranularityControlByUMD

[Chris Wilson]

From: Jeff McGee 

The WA applies to all production Gen9 and requires both enabling and
whitelisting of the per-context preemption control register.

v2: Extend to Cannonlake.

Signed-off-by: Jeff McGee 
Signed-off-by: Michał Winiarski 
Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a28e2a864cf1..040c85e496fa 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1076,8 +1076,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
if (ret)
return ret;
 
-   /* WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl */
-   ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
+   /* WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl] */
+   I915_WRITE(GEN7_FF_SLICE_CS_CHICKEN1,
+  _MASKED_BIT_ENABLE(GEN9_FFSC_PERCTX_PREEMPT_CTRL));
+   ret = wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
if (ret)
return ret;
 
@@ -1139,14 +1141,6 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
if (ret)
return ret;
 
-   /*
-* Actual WA is to disable percontext preemption granularity control
-* until D0 which is the default case so this is equivalent to
-* !WaDisablePerCtxtPreemptionGranularityControl:skl
-*/
-   I915_WRITE(GEN7_FF_SLICE_CS_CHICKEN1,
-  _MASKED_BIT_ENABLE(GEN9_FFSC_PERCTX_PREEMPT_CTRL));
-
/* WaEnableGapsTsvCreditFix:skl */
I915_WRITE(GEN8_GARBCNTL, (I915_READ(GEN8_GARBCNTL) |
   GEN9_GAPS_TSV_CREDIT_DISABLE));
@@ -1279,6 +1273,8 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3, CNL_FAST_ANISO_L1_BANKING_FIX);
 
/* WaEnablePreemptionGranularityControlByUMD:cnl */
+   I915_WRITE(GEN7_FF_SLICE_CS_CHICKEN1,
+  _MASKED_BIT_ENABLE(GEN9_FFSC_PERCTX_PREEMPT_CTRL));
ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
if (ret)
return ret;
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 07/13] drm/i915/execlists: Distinguish the incomplete context notifies

[Chris Wilson]

Let the listener know that the context we just scheduled out was not
complete, and will be scheduled back in at a later point.

v2: Handle CONTEXT_STATUS_PREEMPTED in gvt by aliasing it to
CONTEXT_STATUS_OUT for the moment, gvt can expand upon the difference
later.

Signed-off-by: Chris Wilson 
Cc: "Zhenyu Wang" 
Cc: "Wang, Zhi A" 
Cc: Michał Winiarski 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 1 +
 drivers/gpu/drm/i915/intel_lrc.c | 2 +-
 drivers/gpu/drm/i915/intel_lrc.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index d5892d24f0b6..f6ded475bb2c 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -174,6 +174,7 @@ static int shadow_context_status_change(struct 
notifier_block *nb,
atomic_set(>shadow_ctx_active, 1);
break;
case INTEL_CONTEXT_SCHEDULE_OUT:
+   case INTEL_CONTEXT_SCHEDULE_PREEMPTED:
atomic_set(>shadow_ctx_active, 0);
break;
default:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7d6da130b184..0f6c839d65a1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -618,7 +618,7 @@ execlist_cancel_port_requests(struct intel_engine_execlists 
*execlists)
while (num_ports-- && port_isset(port)) {
struct drm_i915_gem_request *rq = port_request(port);
 
-   execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
+   execlists_context_status_change(rq, 
INTEL_CONTEXT_SCHEDULE_PREEMPTED);
i915_gem_request_put(rq);
 
memset(port, 0, sizeof(*port));
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 314adee7127a..689fde1a63a9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -61,6 +61,7 @@
 enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
INTEL_CONTEXT_SCHEDULE_OUT,
+   INTEL_CONTEXT_SCHEDULE_PREEMPTED,
 };
 
 /* Logical Rings */
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 08/13] drm/i915: Introduce a preempt context

[Chris Wilson]

Add another perma-pinned context for using for preemption at any time.
We cannot just reuse the existing kernel context, as first and foremost
we need to ensure that we can preempt the kernel context itself, so
require a distinct context id. Similar to the kernel context, we may
want to interrupt execution and switch to the preempt context at any
time, and so it needs to be permanently pinned and available.

To compensate for yet another permanent allocation, we shrink the
existing context and the new context by reducing their ringbuffer to the
minimum.

v2: Assert that we never allocate a request from the preemption context.
v3: Limit perma-pin to engines that may preempt.
v4: Onion cleanup for early driver death

Signed-off-by: Chris Wilson 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_drv.h |  6 ++-
 drivers/gpu/drm/i915/i915_gem_context.c | 76 -
 drivers/gpu/drm/i915/i915_gem_request.c |  7 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 22 +-
 4 files changed, 87 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8e4280838f14..b08114116654 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -783,6 +783,7 @@ struct intel_csr {
func(has_l3_dpf); \
func(has_llc); \
func(has_logical_ring_contexts); \
+   func(has_logical_ring_preemption); \
func(has_overlay); \
func(has_pipe_cxsr); \
func(has_pooled_eu); \
@@ -2251,8 +2252,11 @@ struct drm_i915_private {
wait_queue_head_t gmbus_wait_queue;
 
struct pci_dev *bridge_dev;
-   struct i915_gem_context *kernel_context;
struct intel_engine_cs *engine[I915_NUM_ENGINES];
+   /* Context used internally to idle the GPU and setup initial state */
+   struct i915_gem_context *kernel_context;
+   /* Context only to be used for injecting preemption commands */
+   struct i915_gem_context *preempt_context;
struct i915_vma *semaphore;
 
struct drm_dma_handle *status_page_dmah;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 921ee369c74d..f299b0a7c765 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -416,14 +416,43 @@ i915_gem_context_create_gvt(struct drm_device *dev)
return ctx;
 }
 
+static struct i915_gem_context *
+create_kernel_context(struct drm_i915_private *i915, int prio)
+{
+   struct i915_gem_context *ctx;
+
+   ctx = i915_gem_create_context(i915, NULL);
+   if (IS_ERR(ctx))
+   return ctx;
+
+   i915_gem_context_clear_bannable(ctx);
+   ctx->priority = prio;
+   ctx->ring_size = PAGE_SIZE;
+
+   GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
+
+   return ctx;
+}
+
+static void
+destroy_kernel_context(struct i915_gem_context **ctxp)
+{
+   struct i915_gem_context *ctx;
+
+   /* Keep the context ref so that we can free it immediately ourselves */
+   ctx = i915_gem_context_get(fetch_and_zero(ctxp));
+   GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
+
+   context_close(ctx);
+   i915_gem_context_free(ctx);
+}
+
 int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
 {
struct i915_gem_context *ctx;
+   int err;
 
-   /* Init should only be called once per module load. Eventually the
-* restriction on the context_disabled check can be loosened. */
-   if (WARN_ON(dev_priv->kernel_context))
-   return 0;
+   GEM_BUG_ON(dev_priv->kernel_context);
 
INIT_LIST_HEAD(_priv->contexts.list);
INIT_WORK(_priv->contexts.free_work, contexts_free_worker);
@@ -441,28 +470,38 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
ida_init(_priv->contexts.hw_ida);
 
-   ctx = i915_gem_create_context(dev_priv, NULL);
+   /* lowest priority; idle task */
+   ctx = create_kernel_context(dev_priv, I915_PRIORITY_MIN);
if (IS_ERR(ctx)) {
-   DRM_ERROR("Failed to create default global context (error 
%ld)\n",
- PTR_ERR(ctx));
-   return PTR_ERR(ctx);
+   DRM_ERROR("Failed to create default global context\n");
+   err = PTR_ERR(ctx);
+   goto err;
}
-
-   /* For easy recognisablity, we want the kernel context to be 0 and then
+   /*
+* For easy recognisablity, we want the kernel context to be 0 and then
 * all user contexts will have non-zero hw_id.
 */
GEM_BUG_ON(ctx->hw_id);
-
-   i915_gem_context_clear_bannable(ctx);
-   ctx->priority = I915_PRIORITY_MIN; /* lowest priority; idle task */
dev_priv->kernel_context = ctx;
 
-   GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
+   

[Intel-gfx] [PATCH v3 04/13] drm/i915/execlists: Cache the last priolist lookup

[Chris Wilson]

From: Michał Winiarski 

Avoid the repeated rbtree lookup for each request as we unwind them by
tracking the last priolist.

v2: Fix up my unhelpful suggestion of using default_priolist.

Signed-off-by: Michał Winiarski 
Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 303bb2c0b3ce..7d6da130b184 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -358,25 +358,31 @@ static void unwind_wa_tail(struct drm_i915_gem_request 
*rq)
 static void unwind_incomplete_requests(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *rq, *rn;
+   struct i915_priolist *uninitialized_var(p);
+   int last_prio = I915_PRIORITY_INVALID;
 
lockdep_assert_held(>timeline->lock);
 
list_for_each_entry_safe_reverse(rq, rn,
 >timeline->requests,
 link) {
-   struct i915_priolist *p;
-
if (i915_gem_request_completed(rq))
return;
 
__i915_gem_request_unsubmit(rq);
unwind_wa_tail(rq);
 
-   p = lookup_priolist(engine,
-   >priotree,
-   rq->priotree.priority);
-   list_add(>priotree.link,
-_mask_bits(p, 1)->requests);
+   GEM_BUG_ON(rq->priotree.priority == I915_PRIORITY_INVALID);
+   if (rq->priotree.priority != last_prio) {
+   p = lookup_priolist(engine,
+   >priotree,
+   rq->priotree.priority);
+   p = ptr_mask_bits(p, 1);
+
+   last_prio = rq->priotree.priority;
+   }
+
+   list_add(>priotree.link, >requests);
}
 }
 
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 09/13] drm/i915/execlists: Move bdw GPGPU w/a to emit_bb

[Chris Wilson]

Move the re-enabling of MI arbitration from a per-bb w/a buffer to the
emission of the batch buffer itself.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0f6c839d65a1..e5b470ce43e8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1159,24 +1159,6 @@ static u32 *gen8_init_indirectctx_bb(struct 
intel_engine_cs *engine, u32 *batch)
return batch;
 }
 
-/*
- *  This batch is started immediately after indirect_ctx batch. Since we ensure
- *  that indirect_ctx ends on a cacheline this batch is aligned automatically.
- *
- *  The number of DWORDS written are returned using this field.
- *
- *  This batch is terminated with MI_BATCH_BUFFER_END and so we need not add 
padding
- *  to align it with cacheline as padding after MI_BATCH_BUFFER_END is 
redundant.
- */
-static u32 *gen8_init_perctx_bb(struct intel_engine_cs *engine, u32 *batch)
-{
-   /* WaDisableCtxRestoreArbitration:bdw,chv */
-   *batch++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
-   *batch++ = MI_BATCH_BUFFER_END;
-
-   return batch;
-}
-
 static u32 *gen9_init_indirectctx_bb(struct intel_engine_cs *engine, u32 
*batch)
 {
/* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt,glk */
@@ -1291,7 +1273,7 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
break;
case 8:
wa_bb_fn[0] = gen8_init_indirectctx_bb;
-   wa_bb_fn[1] = gen8_init_perctx_bb;
+   wa_bb_fn[1] = NULL;
break;
default:
MISSING_CASE(INTEL_GEN(engine->i915));
@@ -1535,13 +1517,15 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
if (IS_ERR(cs))
return PTR_ERR(cs);
 
+   /* WaDisableCtxRestoreArbitration:bdw,chv */
+   *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+
/* FIXME(BDW): Address space and security selectors. */
*cs++ = MI_BATCH_BUFFER_START_GEN8 |
(flags & I915_DISPATCH_SECURE ? 0 : BIT(8)) |
(flags & I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0);
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
-   *cs++ = MI_NOOP;
intel_ring_advance(req, cs);
 
return 0;
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 02/13] drm/i915/execlists: Move request unwinding to a separate function

[Chris Wilson]

In the future, we will want to unwind requests following a preemption
point. This requires the same steps as for unwinding upon a reset, so
extract the existing code to a separate function for later use.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c | 54 +---
 1 file changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 61cac26a8b05..cbac2fff8e4d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -210,6 +210,7 @@
 #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
 
 #define WA_TAIL_DWORDS 2
+#define WA_TAIL_BYTES (sizeof(u32) * WA_TAIL_DWORDS)
 
 static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_engine_cs *engine);
@@ -348,6 +349,37 @@ lookup_priolist(struct intel_engine_cs *engine,
return ptr_pack_bits(p, first, 1);
 }
 
+static void unwind_wa_tail(struct drm_i915_gem_request *rq)
+{
+   rq->tail = intel_ring_wrap(rq->ring, rq->wa_tail - WA_TAIL_BYTES);
+   assert_ring_tail_valid(rq->ring, rq->tail);
+}
+
+static void unwind_incomplete_requests(struct intel_engine_cs *engine)
+{
+   struct drm_i915_gem_request *rq, *rn;
+
+   lockdep_assert_held(>timeline->lock);
+
+   list_for_each_entry_safe_reverse(rq, rn,
+>timeline->requests,
+link) {
+   struct i915_priolist *p;
+
+   if (i915_gem_request_completed(rq))
+   return;
+
+   __i915_gem_request_unsubmit(rq);
+   unwind_wa_tail(rq);
+
+   p = lookup_priolist(engine,
+   >priotree,
+   rq->priotree.priority);
+   list_add(>priotree.link,
+_mask_bits(p, 1)->requests);
+   }
+}
+
 static inline void
 execlists_context_status_change(struct drm_i915_gem_request *rq,
unsigned long status)
@@ -1382,7 +1414,6 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
  struct drm_i915_gem_request *request)
 {
struct intel_engine_execlists * const execlists = >execlists;
-   struct drm_i915_gem_request *rq, *rn;
struct intel_context *ce;
unsigned long flags;
 
@@ -1400,21 +1431,7 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
execlist_cancel_port_requests(execlists);
 
/* Push back any incomplete requests for replay after the reset. */
-   list_for_each_entry_safe_reverse(rq, rn,
->timeline->requests, link) {
-   struct i915_priolist *p;
-
-   if (i915_gem_request_completed(rq))
-   break;
-
-   __i915_gem_request_unsubmit(rq);
-
-   p = lookup_priolist(engine,
-   >priotree,
-   rq->priotree.priority);
-   list_add(>priotree.link,
-_mask_bits(p, 1)->requests);
-   }
+   unwind_incomplete_requests(engine);
 
spin_unlock_irqrestore(>timeline->lock, flags);
 
@@ -1451,10 +1468,7 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
intel_ring_update_space(request->ring);
 
/* Reset WaIdleLiteRestore:bdw,skl as well */
-   request->tail =
-   intel_ring_wrap(request->ring,
-   request->wa_tail - WA_TAIL_DWORDS*sizeof(u32));
-   assert_ring_tail_valid(request->ring, request->tail);
+   unwind_wa_tail(request);
 }
 
 static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
-- 
2.14.2

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-28 20:12:14)
> On Thu, Sep 28, 2017 at 07:02:59PM +, Chris Wilson wrote:
> > Quoting Rodrigo Vivi (2017-09-28 19:51:48)
> > > Although Bspec state this Workaround is only relevant for SKL:All.
> > > 
> > > The wa_database state this is needed for All platforms from SKL to CNL.
> > > 
> > > So let's pick the safest case.
> > > 
> > > Cc: Mahesh Kumar 
> > > Cc: Chris Wilson 
> > > Cc: Maarten Lankhorst 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index ede871b7982e..27f9d5ab2d23 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -5828,8 +5828,8 @@ void intel_enable_ipc(struct drm_i915_private 
> > > *dev_priv)
> > >  {
> > > u32 val;
> > >  
> > > -   /* Display WA #0477 WaDisableIPC: skl */
> > > -   if (IS_SKYLAKE(dev_priv)) {
> > > +   /* Display WA #0477 WaDisableIPC: skl,kbl,bxt,glk,cfl,cnl */
> > > +   if (INTEL_GEN(dev_priv) <= 10) {
> > 
> > But at that point, why not just define has_ipc as a gen10 feature?
> 
> it's already there...
> 
> > You
> > can have a comment before gen9 feature that although IPC was introduced
> > for gen9, it is recommended (w/a) to leave disabled.
> 
> so you mean moving this Wa from here to set has_ipc = 0 to all platforms?
> 
> Anyways I'd like to hear from Manesh about it since this basically revert
> all IPC work for all platforms...

Just the gen9 platforms, gen10+ enables it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for 2-in-1: Organize feature inheritance and disable IPC.

[Patchwork]

== Series Details ==

Series: 2-in-1: Organize feature inheritance and disable IPC.
URL   : https://patchwork.freedesktop.org/series/31090/
State : failure

== Summary ==

Series 31090v1 2-in-1: Organize feature inheritance and disable IPC.
https://patchwork.freedesktop.org/api/1.0/series/31090/revisions/1/mbox/

Test kms_busy:
Subgroup basic-flip-b:
pass   -> INCOMPLETE (fi-bxt-j4205)
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-cfl-s) k.org#196765

k.org#196765 https://bugzilla.kernel.org/show_bug.cgi?id=196765

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:470s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:422s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:512s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:207  pass:185  dwarn:0   dfail:0   fail:0   skip:21 
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:500s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:496s
fi-cfl-s total:289  pass:255  dwarn:2   dfail:0   fail:0   skip:32  
time:561s
fi-cnl-y total:289  pass:260  dwarn:1   dfail:0   fail:1   skip:27  
time:614s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:572s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:425s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:411s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:485s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:459s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:589s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:543s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:756s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:472s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:567s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:415s

7ae90fb62375c44b198bdffe51c4dee432d4 drm-tip: 2017y-09m-28d-16h-52m-04s UTC 
integration manifest
771e51d5ea64 drm/i915: Extend WaDisableIPC to all platforms.
ab5c14ea07d2 drm/i915: Organize GLK_COLORS.
8cf8c22b308c drm/i915: Organize GEN features inheritance.
3109617523c2 drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC.

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 07:02:59PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2017-09-28 19:51:48)
> > Although Bspec state this Workaround is only relevant for SKL:All.
> > 
> > The wa_database state this is needed for All platforms from SKL to CNL.
> > 
> > So let's pick the safest case.
> > 
> > Cc: Mahesh Kumar 
> > Cc: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index ede871b7982e..27f9d5ab2d23 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5828,8 +5828,8 @@ void intel_enable_ipc(struct drm_i915_private 
> > *dev_priv)
> >  {
> > u32 val;
> >  
> > -   /* Display WA #0477 WaDisableIPC: skl */
> > -   if (IS_SKYLAKE(dev_priv)) {
> > +   /* Display WA #0477 WaDisableIPC: skl,kbl,bxt,glk,cfl,cnl */
> > +   if (INTEL_GEN(dev_priv) <= 10) {
> 
> But at that point, why not just define has_ipc as a gen10 feature?

it's already there...

> You
> can have a comment before gen9 feature that although IPC was introduced
> for gen9, it is recommended (w/a) to leave disabled.

so you mean moving this Wa from here to set has_ipc = 0 to all platforms?

Anyways I'd like to hear from Manesh about it since this basically revert
all IPC work for all platforms...

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Organize GEN features inheritance.

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 07:03:36PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2017-09-28 19:51:46)
> > As Chris noticed the current organization is confusing
> > and inheritance is not clear.
> > 
> > So, let's split it in GEN_FEATURES _PLATFORM
> > where new GEN inherit features from previous gens and
> > Platforms only use gen features plus what ever is specific
> > for that platform and shouldn't be passed on.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Rodrigo Vivi 
> 
> Reviewed-by: Chris Wilson 
> 
> One might argue that .gen=9 is a GEN9_FEATURE ;)

I confess I'm always in doubt about that... also
gen 7 is not in sync so whatever we decide needs to be
same for all gens... but this is for later along with gen7_lp
and gen8_lp organization...

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-28 19:51:47)
> Let's organize this in a way that it gets more obvious
> when looking to the platform colors and in a easier
> way to get inherited.
> 
> Signed-off-by: Rodrigo Vivi 

Lgtm,
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Organize GEN features inheritance.

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-28 19:51:46)
> As Chris noticed the current organization is confusing
> and inheritance is not clear.
> 
> So, let's split it in GEN_FEATURES _PLATFORM
> where new GEN inherit features from previous gens and
> Platforms only use gen features plus what ever is specific
> for that platform and shouldn't be passed on.
> 
> Cc: Chris Wilson 
> Signed-off-by: Rodrigo Vivi 

Reviewed-by: Chris Wilson 

One might argue that .gen=9 is a GEN9_FEATURE ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-28 19:51:48)
> Although Bspec state this Workaround is only relevant for SKL:All.
> 
> The wa_database state this is needed for All platforms from SKL to CNL.
> 
> So let's pick the safest case.
> 
> Cc: Mahesh Kumar 
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ede871b7982e..27f9d5ab2d23 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5828,8 +5828,8 @@ void intel_enable_ipc(struct drm_i915_private *dev_priv)
>  {
> u32 val;
>  
> -   /* Display WA #0477 WaDisableIPC: skl */
> -   if (IS_SKYLAKE(dev_priv)) {
> +   /* Display WA #0477 WaDisableIPC: skl,kbl,bxt,glk,cfl,cnl */
> +   if (INTEL_GEN(dev_priv) <= 10) {

But at that point, why not just define has_ipc as a gen10 feature? You
can have a comment before gen9 feature that although IPC was introduced
for gen9, it is recommended (w/a) to leave disabled.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/4] 2-in-1: Organize feature inheritance and disable IPC.

[Rodrigo Vivi]

I had a chicken and egg problem here. Specially because I want CI to test
everything and patches had interdependency.

On the platform/features organization side we can go further and
organize gen7_lp and gen8_lp inheriting g75_features and gen8_features
respectively. But let's at least start this organization with the thing
that is currently impacting developers plus the glk_color that was
easy enough and non-risky.

Thanks,
Rodrigo.

Rodrigo Vivi (4):
  drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC.
  drm/i915: Organize GEN features inheritance.
  drm/i915: Organize GLK_COLORS.
  drm/i915: Extend WaDisableIPC to all platforms.

 drivers/gpu/drm/i915/i915_pci.c | 53 -
 drivers/gpu/drm/i915/intel_pm.c |  6 +
 2 files changed, 32 insertions(+), 27 deletions(-)

-- 
2.13.5

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

[Intel-gfx] [PATCH 2/4] drm/i915: Organize GEN features inheritance.

[Rodrigo Vivi]

As Chris noticed the current organization is confusing
and inheritance is not clear.

So, let's split it in GEN_FEATURES _PLATFORM
where new GEN inherit features from previous gens and
Platforms only use gen features plus what ever is specific
for that platform and shouldn't be passed on.

Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 48 +++--
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index df751a152057..9b54aafa2a0b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -329,7 +329,7 @@ static const struct intel_device_info intel_valleyview_info 
__initconst = {
CURSOR_OFFSETS
 };
 
-#define HSW_FEATURES  \
+#define G75_FEATURES  \
GEN7_FEATURES, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
.has_ddi = 1, \
@@ -341,7 +341,7 @@ static const struct intel_device_info intel_valleyview_info 
__initconst = {
.has_runtime_pm = 1
 
 #define HSW_PLATFORM \
-   HSW_FEATURES, \
+   G75_FEATURES, \
.platform = INTEL_HASWELL, \
.has_l3_dpf = 1
 
@@ -360,8 +360,8 @@ static const struct intel_device_info 
intel_haswell_gt3_info __initconst = {
.gt = 3,
 };
 
-#define BDW_FEATURES \
-   HSW_FEATURES, \
+#define GEN8_FEATURES \
+   G75_FEATURES, \
BDW_COLORS, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
@@ -369,7 +369,7 @@ static const struct intel_device_info 
intel_haswell_gt3_info __initconst = {
.has_reset_engine = 1
 
 #define BDW_PLATFORM \
-   BDW_FEATURES, \
+   GEN8_FEATURES, \
.gen = 8, \
.platform = INTEL_BROADWELL
 
@@ -420,15 +420,18 @@ static const struct intel_device_info 
intel_cherryview_info __initconst = {
CHV_COLORS,
 };
 
-#define SKL_PLATFORM \
-   BDW_FEATURES, \
-   .gen = 9, \
-   .platform = INTEL_SKYLAKE, \
+#define GEN9_FEATURES \
+   GEN8_FEATURES, \
.has_csr = 1, \
.has_guc = 1, \
.has_ipc = 1, \
.ddb_size = 896
 
+#define SKL_PLATFORM \
+   GEN9_FEATURES, \
+   .gen = 9, \
+   .platform = INTEL_SKYLAKE
+
 static const struct intel_device_info intel_skylake_gt1_info __initconst = {
SKL_PLATFORM,
.gt = 1,
@@ -496,13 +499,9 @@ static const struct intel_device_info 
intel_geminilake_info __initconst = {
 };
 
 #define KBL_PLATFORM \
-   BDW_FEATURES, \
+   GEN9_FEATURES, \
.gen = 9, \
-   .platform = INTEL_KABYLAKE, \
-   .has_csr = 1, \
-   .has_guc = 1, \
-   .has_ipc = 1, \
-   .ddb_size = 896
+   .platform = INTEL_KABYLAKE
 
 static const struct intel_device_info intel_kabylake_gt1_info __initconst = {
KBL_PLATFORM,
@@ -521,13 +520,9 @@ static const struct intel_device_info 
intel_kabylake_gt3_info __initconst = {
 };
 
 #define CFL_PLATFORM \
-   BDW_FEATURES, \
+   GEN9_FEATURES, \
.gen = 9, \
-   .platform = INTEL_COFFEELAKE, \
-   .has_csr = 1, \
-   .has_guc = 1, \
-   .has_ipc = 1, \
-   .ddb_size = 896
+   .platform = INTEL_COFFEELAKE
 
 static const struct intel_device_info intel_coffeelake_gt1_info __initconst = {
CFL_PLATFORM,
@@ -545,16 +540,17 @@ static const struct intel_device_info 
intel_coffeelake_gt3_info __initconst = {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
+#define GEN10_FEATURES \
+   GEN9_FEATURES, \
+   .ddb_size = 1024, \
+   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
+
 static const struct intel_device_info intel_cannonlake_gt2_info __initconst = {
-   BDW_FEATURES,
+   GEN10_FEATURES,
.is_alpha_support = 1,
.platform = INTEL_CANNONLAKE,
.gen = 10,
.gt = 2,
-   .ddb_size = 1024,
-   .has_csr = 1,
-   .has_ipc = 1,
-   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
 };
 
 /*
-- 
2.13.5

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

[Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.

[Rodrigo Vivi]

Let's organize this in a way that it gets more obvious
when looking to the platform colors and in a easier
way to get inherited.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 9b54aafa2a0b..10537dcdd9c1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -54,6 +54,8 @@
.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
 #define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
+#define GLK_COLORS \
+   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
 
 /* Keep in gen based order, and chronological order within a gen */
 #define GEN2_FEATURES \
@@ -495,7 +497,7 @@ static const struct intel_device_info intel_geminilake_info 
__initconst = {
GEN9_LP_FEATURES,
.platform = INTEL_GEMINILAKE,
.ddb_size = 1024,
-   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
+   GLK_COLORS
 };
 
 #define KBL_PLATFORM \
@@ -543,7 +545,7 @@ static const struct intel_device_info 
intel_coffeelake_gt3_info __initconst = {
 #define GEN10_FEATURES \
GEN9_FEATURES, \
.ddb_size = 1024, \
-   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
+   GLK_COLORS
 
 static const struct intel_device_info intel_cannonlake_gt2_info __initconst = {
GEN10_FEATURES,
-- 
2.13.5

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

[Intel-gfx] [PATCH 1/4] drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC.

[Rodrigo Vivi]

According to Spec for SKL+: "Isochronous Priority Control.
If enabled, Display sends demoted requests once the transition
watermark is reached. If transition watermark is not enabled,
Display sends demoted requests when the display buffer is full."

The commit 'e57f1c02155f ("drm/i915/gen9+: Add has_ipc flag in
device info structure")' introduced that as gen9+ but missing many
SKL Skus.

I believe the reason for that is Spec also mentions workarounds for
SKL-ALL: "IPC (Isoch Priority Control) may cause underflows
WA: Do not enable IPC in register ARB_CTL2"

It seems lame to add the feature and forever disable it,
but it will avoid a mistake of enabling it when we are reorganizing
the feature definitions on i915_pci.c later.

It will also allow us to probably extend that workaround for
other platforms.

Cc: Mahesh Kumar 
Cc: Maarten Lankhorst 
Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index da60866b6628..df751a152057 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -426,6 +426,7 @@ static const struct intel_device_info intel_cherryview_info 
__initconst = {
.platform = INTEL_SKYLAKE, \
.has_csr = 1, \
.has_guc = 1, \
+   .has_ipc = 1, \
.ddb_size = 896
 
 static const struct intel_device_info intel_skylake_gt1_info __initconst = {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 52c4c194aa51..ede871b7982e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5828,6 +5828,12 @@ void intel_enable_ipc(struct drm_i915_private *dev_priv)
 {
u32 val;
 
+   /* Display WA #0477 WaDisableIPC: skl */
+   if (IS_SKYLAKE(dev_priv)) {
+   dev_priv->ipc_enabled = false;
+   return;
+   }
+
val = I915_READ(DISP_ARB_CTL2);
 
if (dev_priv->ipc_enabled)
-- 
2.13.5

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

[Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

[Rodrigo Vivi]

Although Bspec state this Workaround is only relevant for SKL:All.

The wa_database state this is needed for All platforms from SKL to CNL.

So let's pick the safest case.

Cc: Mahesh Kumar 
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ede871b7982e..27f9d5ab2d23 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5828,8 +5828,8 @@ void intel_enable_ipc(struct drm_i915_private *dev_priv)
 {
u32 val;
 
-   /* Display WA #0477 WaDisableIPC: skl */
-   if (IS_SKYLAKE(dev_priv)) {
+   /* Display WA #0477 WaDisableIPC: skl,kbl,bxt,glk,cfl,cnl */
+   if (INTEL_GEN(dev_priv) <= 10) {
dev_priv->ipc_enabled = false;
return;
}
-- 
2.13.5

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

Re: [Intel-gfx] [PATCH v2 10/11] drm/i915/execlists: Preemption!

[Chris Wilson]

Quoting Joonas Lahtinen (2017-09-28 15:10:03)
> On Wed, 2017-09-27 at 17:44 +0100, Chris Wilson wrote:
> > When we write to ELSP, it triggers a context preemption at the earliest
> > arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
> > operations and the explicit MI_ARB_CHECK). If this is to the same
> > context, it triggers a LITE_RESTORE where the RING_TAIL is merely
> > updated (used currently to chain requests from the same context
> > together, avoiding bubbles). However, if it is to a different context, a
> > full context-switch is performed and it will start to execute the new
> > context saving the image of the old for later execution.
> > 
> > Previously we avoided preemption by only submitting a new context when
> > the old was idle. But now we wish embrace it, and if the new request has
> > a higher priority than the currently executing request, we write to the
> > ELSP regardless, thus triggering preemption, but we tell the GPU to
> > switch to our special preemption context (not the target). In the
> > context-switch interrupt handler, we know that the previous contexts
> > have finished execution and so can unwind all the incomplete requests
> > and compute the new highest priority request to execute.
> > 
> > It would be feasible to avoid the switch-to-idle intermediate by
> > programming the ELSP with the target context. The difficulty is in
> > tracking which request that should be whilst maintaining the dependency
> > change, the error comes in with coalesced requests. As we only track the
> > most recent request and its priority, we may run into the issue of being
> > tricked in preempting a high priority request that was followed by a
> > low priority request from the same context (e.g. for PI);
> 
> "followed" is bit ambiguous here, depending on how you view the
> ordering, wall time or ports.

Not in this case. Same context == same timeline, i.e. fifo. :)
 
> > worse still
> > that earlier request may be our own dependency and the order then broken
> > by preemption. By injecting the switch-to-idle and then recomputing the
> > priority queue, we avoid the issue with tracking in-flight coalesced
> > requests. Having tried the preempt-to-busy approach, and failed to find
> > a way around the coalesced priority issue, Michal's original proposal to
> > inject an idle context (based on handling GuC preemption) succeeds.
> > 
> > The current heuristic for deciding when to preempt are only if the new
> > request is of higher priority, and has the privileged priority of
> > greater than 0. Note that the scheduler remains unfair!
> > 
> > v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
> > Since, the feature is now conditional and not always available when we
> > have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
> > capability mask).
> > 
> > Suggested-by: Michal Winiarski 
> > Signed-off-by: Chris Wilson 
> > Cc: Michal Winiarski 
> > Cc: Tvrtko Ursulin 
> > Cc: Arkadiusz Hiler 
> > Cc: Mika Kuoppala 
> > Cc: Ben Widawsky 
> > Cc: Zhenyu Wang 
> > Cc: Zhi Wang 
> 
> 
> 
> > @@ -489,26 +489,44 @@ static void port_assign(struct execlist_port *port,
> >   port_set(port, port_pack(i915_gem_request_get(rq), port_count(port)));
> >  }
> >  
> > +static void inject_preempt_context(struct intel_engine_cs *engine)
> > +{
> > + struct intel_context *ce =
> > + >i915->preempt_context->engine[engine->id];
> > + u32 __iomem *elsp =
> > + engine->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));
> 
> engine_elsp() helper or so?

No. People doing this should suffer.

> > + unsigned int n;
> > +
> > + GEM_BUG_ON(engine->i915->preempt_context->hw_id != PREEMPT_ID);
> 
> I think this could/should be done way earlier?

This is the earliest point in the sequence. We assert that the value
that we stuff into the upper_32_bits(desc) will match the value we
extract from the upper_32_bits(status).

> > +
> > + memset(ce->ring->vaddr + ce->ring->tail, 0, 8);
> > + ce->ring->tail += 8;
> > + ce->ring->tail &= (ce->ring->size - 1);
> > + ce->lrc_reg_state[CTX_RING_TAIL+1] = ce->ring->tail;
> 
> An awful lot of pre-expectations here, would be shame if somebody
> documented them.

Like which? HW requirement for qword aligned tailed updates, some HW
requirement to ensure HEAD != TAIL. Have you seen the extensive
commentary that preceded this function?

> > @@ -696,7 +746,7 @@ static void intel_lrc_irq_handler(unsigned long data)
> >  {
> >   struct intel_engine_cs * const engine = (struct intel_engine_cs 
> > *)data;
> >   struct intel_engine_execlists * const execlists = >execlists;
> > - struct execlist_port *port = execlists->port;
> > + struct 

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] meson.sh: Invoke meson correctly

[Patchwork]

== Series Details ==

Series: series starting with [1/2] meson.sh: Invoke meson correctly
URL   : https://patchwork.freedesktop.org/series/31082/
State : warning

== Summary ==

Test gem_eio:
Subgroup throttle:
pass   -> DMESG-WARN (shard-hsw) fdo#102886 +3
Test kms_pwrite_crc:
pass   -> DMESG-WARN (shard-hsw)
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_atomic_transition:
Subgroup plane-all-modeset-transition-fencing:
pass   -> DMESG-WARN (shard-hsw) fdo#102614
Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939

fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939

shard-hswtotal:2429 pass:1332 dwarn:5   dfail:0   fail:9   skip:1083 
time:10022s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] igt/gem_sync: Add a preemption test

[Patchwork]

== Series Details ==

Series: series starting with [1/2] igt/gem_sync: Add a preemption test
URL   : https://patchwork.freedesktop.org/series/31088/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
3df22e0d2f8934311c62e4fd84bee24b32addb58 benchmarks/gem_exec_fault: Update for 
tryhard kernels.

with latest DRM-Tip kernel build CI_DRM_3151
7ae90fb62375 drm-tip: 2017y-09m-28d-16h-52m-04s UTC integration manifest

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-cfl-s) fdo#102673

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:473s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:422s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:519s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:506s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:520s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:499s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:496s
fi-cfl-s total:246  pass:214  dwarn:1   dfail:0   fail:0   skip:30 
fi-cnl-y total:289  pass:259  dwarn:0   dfail:0   fail:3   skip:27  
time:664s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:423s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:569s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:432s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:402s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:434s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:492s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:465s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:582s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:551s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:754s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:490s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:475s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:568s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:416s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for tests/gem_workarounds: Skip write only registers (rev2)

[Patchwork]

== Series Details ==

Series: tests/gem_workarounds: Skip write only registers (rev2)
URL   : https://patchwork.freedesktop.org/series/31073/
State : failure

== Summary ==

Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-hsw) fdo#102886 +1
Test gem_sync:
Subgroup basic-each:
pass   -> FAIL   (shard-hsw)

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

shard-hswtotal:2429 pass:1330 dwarn:5   dfail:0   fail:11  skip:1083 
time:10045s

== Logs ==

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

[Intel-gfx] [PATCH igt 1/2] igt/gem_sync: Add a preemption test

[Chris Wilson]

Check and measure how well we can submit a second high priority task
when the engine is already busy with a low priority task and see how
long it takes to complete (and wake up the client).

Signed-off-by: Chris Wilson 
---
 tests/gem_sync.c | 158 +++
 1 file changed, 158 insertions(+)

diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index f9a2ebdf..8ed9760d 100644
--- a/tests/gem_sync.c
+++ b/tests/gem_sync.c
@@ -27,12 +27,22 @@
 #include "igt.h"
 #include "igt_sysfs.h"
 
+#define BIT(x) (1ul << (x))
+
 #define LOCAL_I915_EXEC_NO_RELOC (1<<11)
 #define LOCAL_I915_EXEC_HANDLE_LUT (1<<12)
 
 #define LOCAL_I915_EXEC_BSD_SHIFT  (13)
 #define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
 
+#define LOCAL_PARAM_HAS_SCHEDULER 41
+#define   HAS_SCHEDULERBIT(0)
+#define   HAS_PRIORITY BIT(1)
+#define   HAS_PREEMPTION   BIT(2)
+#define LOCAL_CONTEXT_PARAM_PRIORITY 6
+#define   MAX_PRIO 1023
+#define   MIN_PRIO -1023
+
 #define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
 
 IGT_TEST_DESCRIPTION("Basic check of ring<->ring write synchronisation.");
@@ -684,6 +694,116 @@ store_all(int fd, int num_children, int timeout)
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
 }
 
+static int __ctx_set_priority(int fd, uint32_t ctx, int prio)
+{
+   struct local_i915_gem_context_param param;
+
+   memset(, 0, sizeof(param));
+   param.context = ctx;
+   param.size = 0;
+   param.param = LOCAL_CONTEXT_PARAM_PRIORITY;
+   param.value = prio;
+
+   return __gem_context_set_param(fd, );
+}
+
+static void ctx_set_priority(int fd, uint32_t ctx, int prio)
+{
+   igt_assert_eq(__ctx_set_priority(fd, ctx, prio), 0);
+}
+
+static void
+preempt(int fd, unsigned ring, int num_children, int timeout)
+{
+   unsigned engines[16];
+   const char *names[16];
+   int num_engines = 0;
+   uint32_t ctx[2];
+
+   if (ring == ~0u) {
+   const struct intel_execution_engine *e;
+
+   for (e = intel_execution_engines; e->name; e++) {
+   if (e->exec_id == 0)
+   continue;
+
+   if (!gem_has_ring(fd, e->exec_id | e->flags))
+   continue;
+
+   if (e->exec_id == I915_EXEC_BSD) {
+   int is_bsd2 = e->flags != 0;
+   if (gem_has_bsd2(fd) != is_bsd2)
+   continue;
+   }
+
+   names[num_engines] = e->name;
+   engines[num_engines++] = e->exec_id | e->flags;
+   if (num_engines == ARRAY_SIZE(engines))
+   break;
+   }
+
+   num_children *= num_engines;
+   } else {
+   gem_require_ring(fd, ring);
+   names[num_engines] = NULL;
+   engines[num_engines++] = ring;
+   }
+
+   ctx[0] = gem_context_create(fd);
+   ctx_set_priority(fd, ctx[0], MIN_PRIO);
+
+   ctx[1] = gem_context_create(fd);
+   ctx_set_priority(fd, ctx[1], MAX_PRIO);
+
+   intel_detect_and_clear_missed_interrupts(fd);
+   igt_fork(child, num_children) {
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   struct drm_i915_gem_exec_object2 object;
+   struct drm_i915_gem_execbuffer2 execbuf;
+   double start, elapsed;
+   unsigned long cycles;
+
+   memset(, 0, sizeof(object));
+   object.handle = gem_create(fd, 4096);
+   gem_write(fd, object.handle, 0, , sizeof(bbe));
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer();
+   execbuf.buffer_count = 1;
+   execbuf.flags = engines[child % num_engines];
+   execbuf.rsvd1 = ctx[1];
+   gem_execbuf(fd, );
+
+   start = gettime();
+   cycles = 0;
+   do {
+   igt_spin_t *spin =
+   __igt_spin_batch_new(fd,
+ctx[0],
+execbuf.flags,
+0);
+
+   do {
+   gem_execbuf(fd, );
+   gem_sync(fd, object.handle);
+   } while (++cycles & 1023);
+
+   igt_spin_batch_free(fd, spin);
+   } while ((elapsed = gettime() - start) < timeout);
+   igt_info("%s%sompleted %ld cycles: %.3f us\n",
+names[child % num_engines] ?: "",
+names[child % num_engines] ? " c" : "C",
+cycles, elapsed*1e6/cycles);
+

[Intel-gfx] [PATCH igt 2/2] igt/gem_exec_nop: Measure high-priority throughput over a bg load

[Chris Wilson]

Measure how many high priority batches we can execute whilst running a
bg spinner.

Signed-off-by: Chris Wilson 
---
 tests/gem_exec_nop.c | 118 +++
 1 file changed, 118 insertions(+)

diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index 03335a6d..b582285a 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -45,6 +45,8 @@
 #include 
 #include "drm.h"
 
+#define BIT(x) (1ul << (x))
+
 #define LOCAL_I915_EXEC_NO_RELOC (1<<11)
 #define LOCAL_I915_EXEC_HANDLE_LUT (1<<12)
 
@@ -53,6 +55,14 @@
 
 #define ENGINE_FLAGS  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
 
+#define LOCAL_PARAM_HAS_SCHEDULER 41
+#define   HAS_SCHEDULERBIT(0)
+#define   HAS_PRIORITY BIT(1)
+#define   HAS_PREEMPTION   BIT(2)
+#define LOCAL_CONTEXT_PARAM_PRIORITY 6
+#define   MAX_PRIO 1023
+#define   MIN_PRIO -1023
+
 #define FORKED 1
 #define CHAINED 2
 #define CONTEXT 4
@@ -582,6 +592,79 @@ static void fence_signal(int fd, uint32_t handle,
igt_info("Signal %s: %'lu cycles (%'lu signals): %.3fus\n",
 ring_name, count, signal, elapsed(, ) * 1e6 / count);
 }
+static int __ctx_set_priority(int fd, uint32_t ctx, int prio)
+{
+   struct local_i915_gem_context_param param;
+
+   memset(, 0, sizeof(param));
+   param.context = ctx;
+   param.size = 0;
+   param.param = LOCAL_CONTEXT_PARAM_PRIORITY;
+   param.value = prio;
+
+   return __gem_context_set_param(fd, );
+}
+
+static void ctx_set_priority(int fd, uint32_t ctx, int prio)
+{
+   igt_assert_eq(__ctx_set_priority(fd, ctx, prio), 0);
+}
+
+static void preempt(int fd, uint32_t handle,
+  unsigned ring_id, const char *ring_name)
+{
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 obj;
+   struct timespec start, now;
+   unsigned long count;
+   uint32_t ctx[2];
+
+   gem_require_ring(fd, ring_id);
+
+   ctx[0] = gem_context_create(fd);
+   ctx_set_priority(fd, ctx[0], MIN_PRIO);
+
+   ctx[1] = gem_context_create(fd);
+   ctx_set_priority(fd, ctx[1], MAX_PRIO);
+
+   memset(, 0, sizeof(obj));
+   obj.handle = handle;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer();
+   execbuf.buffer_count = 1;
+   execbuf.flags = ring_id;
+   execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
+   execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
+   if (__gem_execbuf(fd, )) {
+   execbuf.flags = ring_id;
+   gem_execbuf(fd, );
+   }
+   execbuf.rsvd1 = ctx[1];
+   intel_detect_and_clear_missed_interrupts(fd);
+
+   count = 0;
+   clock_gettime(CLOCK_MONOTONIC, );
+   do {
+   igt_spin_t *spin =
+   __igt_spin_batch_new(fd, ctx[0], ring_id, 0);
+
+   for (int loop = 0; loop < 1024; loop++)
+   gem_execbuf(fd, );
+
+   igt_spin_batch_free(fd, spin);
+
+   count += 1024;
+   clock_gettime(CLOCK_MONOTONIC, );
+   } while (elapsed(, ) < 20);
+   igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+
+   gem_context_destroy(fd, ctx[1]);
+   gem_context_destroy(fd, ctx[0]);
+
+   igt_info("%s: %'lu cycles: %.3fus\n",
+ring_name, count, elapsed(, )*1e6 / count);
+}
 
 static void print_welcome(int fd)
 {
@@ -612,9 +695,31 @@ out:
close(dir);
 }
 
+static unsigned int has_scheduler(int fd)
+{
+   drm_i915_getparam_t gp;
+   unsigned int caps = 0;
+
+   gp.param = LOCAL_PARAM_HAS_SCHEDULER;
+   gp.value = (int *)
+   drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+
+   if (!caps)
+   return 0;
+
+   igt_info("Has kernel scheduler\n");
+   if (caps & HAS_PRIORITY)
+   igt_info(" - With priority sorting\n");
+   if (caps & HAS_PREEMPTION)
+   igt_info(" - With preemption enabled\n");
+
+   return caps;
+}
+
 igt_main
 {
const struct intel_execution_engine *e;
+   unsigned int sched_caps = 0;
uint32_t handle = 0;
int device = -1;
 
@@ -624,6 +729,7 @@ igt_main
device = drm_open_driver(DRIVER_INTEL);
igt_require_gem(device);
print_welcome(device);
+   sched_caps = has_scheduler(device);
 
handle = gem_create(device, 4096);
gem_write(device, handle, 0, , sizeof(bbe));
@@ -668,6 +774,18 @@ igt_main
igt_subtest("context-sequential")
sequential(device, handle, FORKED | CONTEXT, 150);
 
+   igt_subtest_group {
+   igt_fixture {
+   igt_require(sched_caps & HAS_PRIORITY);
+   igt_require(sched_caps & HAS_PREEMPTION);
+   }
+
+   for (e = intel_execution_engines; e->name; e++) {
+   

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-28 18:13:27)
> On Thu, Sep 28, 2017 at 05:00:53PM +, Chris Wilson wrote:
> > Quoting Rodrigo Vivi (2017-09-28 17:33:48)
> > > On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote:
> > > > I recently tried to update the gen9 feature matrix and to my unpleasant
> > > > surprise found that Kabylake still acted like Broadwell and didn't
> > > > enable the feature. This is because kbl/cfl are inheriting their
> > > > defaults from Broadwell and not Skylake.
> > > 
> > > Hmm... I should've considered this would happen someday sooner than 
> > > later...
> > > My Bad...
> > > 
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Paulo Zanoni 
> > > > Cc: Mika Kuoppala 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_pci.c | 21 +
> > > >  1 file changed, 5 insertions(+), 16 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > > b/drivers/gpu/drm/i915/i915_pci.c
> > > > index da60866b6628..01d4b569b2cc 100644
> > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > @@ -495,13 +495,9 @@ static const struct intel_device_info 
> > > > intel_geminilake_info __initconst = {
> > > >  };
> > > >  
> > > >  #define KBL_PLATFORM \
> > > > - BDW_FEATURES, \
> > > 
> > > Note that BDW has _FEATURES and _PLATFORM.
> > > The idea is that _FEATURES would be he place to get inherited
> > > while platform was for that specific one and shouldn't be imported by a 
> > > different platform.
> > > so we wouldn't need to overwrite any specific value like .platform.
> > > And we would have a placeholder for the specific values and features that 
> > > we want only
> > > on that particular platform and never propagated to newer ones.
> > > 
> > > But yeah... that is lame, fragile, non documented and caused confusion. 
> > > Sorry.
> > 
> > I honestly don't mind, just my expectation was that cfl/kbl == skl +
> > constant so that I could enable a feature in one gen and expect it to
> > forward propagate (and I prefer intel_device_info for its debug/error
> > reporting and opportunity for its fine granularity).
> > 
> > I don't think you want to mix the platform name with features then, i.e.
> > GEN8_FEATURES, GEN8_LP_FEATURES
> > GEN9_FEATURES, GEN9_LP_FEATURES
> > 
> > #define KBL_PLATFORM GEN9_FEATURES, ...
> 
> Good idea.
> Only doubt is how to rename HSW_FEATURES
> GEN7_5_FEATURES ?
> GEN75_FEATURES ?
> or just leave HSW_FEATURES as the exception?

G75_FEATURES, looking back at g33 and g4x where there have been
substantial changes mid-generation. (Makes the notion of generation
quite weak, but it's loose terminology for our convenience anyway
considering the different update cycles for the different blocks).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 05:00:53PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2017-09-28 17:33:48)
> > On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote:
> > > I recently tried to update the gen9 feature matrix and to my unpleasant
> > > surprise found that Kabylake still acted like Broadwell and didn't
> > > enable the feature. This is because kbl/cfl are inheriting their
> > > defaults from Broadwell and not Skylake.
> > 
> > Hmm... I should've considered this would happen someday sooner than later...
> > My Bad...
> > 
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Rodrigo Vivi 
> > > Cc: Paulo Zanoni 
> > > Cc: Mika Kuoppala 
> > > ---
> > >  drivers/gpu/drm/i915/i915_pci.c | 21 +
> > >  1 file changed, 5 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index da60866b6628..01d4b569b2cc 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -495,13 +495,9 @@ static const struct intel_device_info 
> > > intel_geminilake_info __initconst = {
> > >  };
> > >  
> > >  #define KBL_PLATFORM \
> > > - BDW_FEATURES, \
> > 
> > Note that BDW has _FEATURES and _PLATFORM.
> > The idea is that _FEATURES would be he place to get inherited
> > while platform was for that specific one and shouldn't be imported by a 
> > different platform.
> > so we wouldn't need to overwrite any specific value like .platform.
> > And we would have a placeholder for the specific values and features that 
> > we want only
> > on that particular platform and never propagated to newer ones.
> > 
> > But yeah... that is lame, fragile, non documented and caused confusion. 
> > Sorry.
> 
> I honestly don't mind, just my expectation was that cfl/kbl == skl +
> constant so that I could enable a feature in one gen and expect it to
> forward propagate (and I prefer intel_device_info for its debug/error
> reporting and opportunity for its fine granularity).
> 
> I don't think you want to mix the platform name with features then, i.e.
> GEN8_FEATURES, GEN8_LP_FEATURES
> GEN9_FEATURES, GEN9_LP_FEATURES
> 
> #define KBL_PLATFORM GEN9_FEATURES, ...

Good idea.
Only doubt is how to rename HSW_FEATURES
GEN7_5_FEATURES ?
GEN75_FEATURES ?
or just leave HSW_FEATURES as the exception?

> 
> > >  static const struct intel_device_info intel_cannonlake_gt2_info 
> > > __initconst = {
> > > - BDW_FEATURES,
> > > + SKL_PLATFORM,
> > 
> > my OCD doesn't like to read cannonlake as skylake platform...
> 
> We don't appear to support Cannonlake as a whole ;)
> Just a couple of CI devices?
> 
> > So maybe we should just kill "_PLATFORM" and rename everything back to 
> > "FEATURES"
> > and on this case also it would be better for CFL to inherit KBL one and CNL 
> > inherit CFL one and on.
> 
> The FEATURES / PLATFORM split is fine, it can even extend to multiple
> inheritance (for as long as the last-one-wins rule works).
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-28 17:33:48)
> On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote:
> > I recently tried to update the gen9 feature matrix and to my unpleasant
> > surprise found that Kabylake still acted like Broadwell and didn't
> > enable the feature. This is because kbl/cfl are inheriting their
> > defaults from Broadwell and not Skylake.
> 
> Hmm... I should've considered this would happen someday sooner than later...
> My Bad...
> 
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Rodrigo Vivi 
> > Cc: Paulo Zanoni 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 21 +
> >  1 file changed, 5 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index da60866b6628..01d4b569b2cc 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -495,13 +495,9 @@ static const struct intel_device_info 
> > intel_geminilake_info __initconst = {
> >  };
> >  
> >  #define KBL_PLATFORM \
> > - BDW_FEATURES, \
> 
> Note that BDW has _FEATURES and _PLATFORM.
> The idea is that _FEATURES would be he place to get inherited
> while platform was for that specific one and shouldn't be imported by a 
> different platform.
> so we wouldn't need to overwrite any specific value like .platform.
> And we would have a placeholder for the specific values and features that we 
> want only
> on that particular platform and never propagated to newer ones.
> 
> But yeah... that is lame, fragile, non documented and caused confusion. Sorry.

I honestly don't mind, just my expectation was that cfl/kbl == skl +
constant so that I could enable a feature in one gen and expect it to
forward propagate (and I prefer intel_device_info for its debug/error
reporting and opportunity for its fine granularity).

I don't think you want to mix the platform name with features then, i.e.
GEN8_FEATURES, GEN8_LP_FEATURES
GEN9_FEATURES, GEN9_LP_FEATURES

#define KBL_PLATFORM GEN9_FEATURES, ...

> >  static const struct intel_device_info intel_cannonlake_gt2_info 
> > __initconst = {
> > - BDW_FEATURES,
> > + SKL_PLATFORM,
> 
> my OCD doesn't like to read cannonlake as skylake platform...

We don't appear to support Cannonlake as a whole ;)
Just a couple of CI devices?

> So maybe we should just kill "_PLATFORM" and rename everything back to 
> "FEATURES"
> and on this case also it would be better for CFL to inherit KBL one and CNL 
> inherit CFL one and on.

The FEATURES / PLATFORM split is fine, it can even extend to multiple
inheritance (for as long as the last-one-wins rule works).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Also discard second CRC on gen8+ platforms.

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 08:09:43AM +, Mika Kahola wrote:
> This fixes my issue with GLK+MIPI/DSI when running IGT test
> 
> kms_frontbuffer_tracking --r basic
> 
> Tested-by: Mika Kahola 

Thanks for spotting the problem, for reviews and testings.
Patch merged to dinq.

> 
> On Wed, 2017-09-27 at 17:20 -0700, Rodrigo Vivi wrote:
> > One of the differences I spotted for GEN8+ platforms when
> > compared to older platforms is that spec for BDW+ includes
> > this sentence:
> > 
> > "The first CRC done indication after CRC is first enabled is
> > from only a partial frame, so it will not have the expected
> > CRC result."
> > 
> > This is an indication that on BDW+ platforms, by the time
> > we receive the interrupt the CRC is not accurate yet for
> > the full frame. That would be ok, because we are already
> > skipping the first CRC for all platforms. However the comment
> > on the code state that it is for some unknown reason. Also,
> > on CHV (gen8 lp) we were already discarding the second CRC
> > as well to make sure we have a reliable CRC on hand.
> > 
> > So based on all ou tests and bugs it seems that it is not
> > on CHV that needs to discard 2 first CRCs, but all BDW+
> > platforms.
> > 
> > Starting on SKL we have this CRC done bit (24), but the
> > experiments around the use of this bit wasn't that stable
> > as just discarding the second CRC. So, let's for now
> > just move with CHV solution for all gen8+ platforms and
> > make our CI a bit more stable.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102374
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101309
> > Cc: Mika Kahola 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 0b7562135d1c..efd7827ff181 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1647,11 +1647,11 @@ static void
> > display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
> >      * bonkers. So let's just wait for the next vblank
> > and read
> >      * out the buggy result.
> >      *
> > -    * On CHV sometimes the second CRC is bonkers as
> > well, so
> > +    * On GEN8+ sometimes the second CRC is bonkers as
> > well, so
> >      * don't trust that one either.
> >      */
> >     if (pipe_crc->skipped == 0 ||
> > -   (IS_CHERRYVIEW(dev_priv) && pipe_crc->skipped ==
> > 1)) {
> > +   (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped
> > == 1)) {
> >     pipe_crc->skipped++;
> >     spin_unlock(_crc->lock);
> >     return;
> -- 
> Mika Kahola - Intel OTC
> 
___
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/psr: Set frames before SU entry for psr2

[Rodrigo Vivi]

On Fri, Sep 22, 2017 at 03:58:36PM +, vathsala nagaraju wrote:
> Set frames before SU entry value for max resync frame count of
> dpcd register 2009, bit field 0:3.
> 
> v2 :
>  - add macro  EDP_PSR2_FRAME_BEFORE_SU (Rodrigo)
>  - remove EDP_FRAMES_BEFORE_SU_ENTRY (Rodrigo)
>  - add check ==1 for dpcd_read call (ville)
> 
> Cc: Rodrigo Vivi 
> CC: Puthikorn Voravootivat 
> Signed-off-by: Vathsala Nagaraju 

Merged both patches to dinq. Thanks for the patches.

I'm anxiously waiting the PSR2 related workaroud(s)! ;)

Thanks,
Rodrigo.

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  2 +-
>  drivers/gpu/drm/i915/intel_psr.c | 12 ++--
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 82f36dd..89c5249 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -170,6 +170,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>   (mask) << 16 | (value); })
>  #define _MASKED_BIT_ENABLE(a)({ typeof(a) _a = (a); 
> _MASKED_FIELD(_a, _a); })
>  #define _MASKED_BIT_DISABLE(a)   (_MASKED_FIELD((a), 0))
> +#define EDP_PSR2_FRAME_BEFORE_SU(a) ((a) << EDP_PSR2_FRAME_BEFORE_SU_SHIFT)
>  
>  /* Engine ID */
>  
> @@ -4047,7 +4048,6 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
> -#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)
>  
>  #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
>  #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 0a17d1f..e505fa6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -327,6 +327,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>*/
>   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>   uint32_t val;
> + uint8_t sink_latency;
>  
>   val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
> @@ -334,8 +335,15 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
>   val |= EDP_PSR2_ENABLE |
> - EDP_SU_TRACK_ENABLE |
> - EDP_FRAMES_BEFORE_SU_ENTRY;
> + EDP_SU_TRACK_ENABLE;
> +
> + if (drm_dp_dpcd_readb(_dp->aux, DP_SINK_SYNCHRONIZATION_LATENCY,
> + _latency) == 1) {
> + sink_latency = sink_latency & DP_MAX_RESYNC_FRAME_CNT_MASK;
> + } else {
> + sink_latency = 0;
> + }
> + val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency + 1);
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 10:51:42AM +, David Weinehall wrote:
> On Thu, Sep 28, 2017 at 04:20:29AM +, Rodrigo Vivi wrote:
> > On Wed, Sep 27, 2017 at 5:14 AM David Weinehall <
> > david.weineh...@linux.intel.com> wrote:
> > 
> > > On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi wrote:
> > > > a long time ago I had agreed with Daniel that we would only add new
> > > > platforms after it was enabled by default on previous platforms.
> > > > a big reason for that is that we was willing to reduce the platforms
> > > > to validate and do better validation one by one before enabling.
> > > >
> > > > However now I believe it would be beneficial to have that supported
> > > > added so we can get more brave people using in different platforms so
> > > > we could capture more corner cases before we enable it by default.
> > > > Also we can still enable by default one platform at time if needed.
> > > >
> > > > So:
> > > >
> > > > Acked-by: Rodrigo Vivi 
> > > >
> > > > I also checked the spec to see if there was anything else new or
> > > > different for these platforms and didn't find anything so:
> > > >
> > > > Reviewed-by: Rodrigo Vivi 
> > > >
> > > > But let's wait a bit to merge to give Daniel or others a time to nack ;)
> > >
> > > An update: while testing revealed that our BXT-P RVP doesn't work with
> > > PSR, the GLK definitely does. CI would like to do PSR testing on GLK,
> > > which obviously isn't possible if PSR is reported as unsupported on GLK.
> > >
> > > Based on BSpec alone the PSR failure on BXT-P shouldn't be a
> > > Broxton/Apollo Lake issue, but rather an issue with the RVP board
> > > (or the panel), so I'd say that this patch still makes sense.
> > 
> > 
> > It would be very important if we could narrow down the issue on BXT.
> > Panel?! Bios?! Missing Workaround? Different user space?
> 
> Agreed. I haven't been able to find any newer BIOS for that device,
> the user space should be the same.
> 
> Missing workaround might well be the case, and the panel is definitely
> not the same as the one the GLK has. We have several other panels that
> could be tested with though.
> 
> > One of the biggest problem with PSR is that when it works well in all
> > machines we have and we enable it we end up finding someone in the
> > community with a machine that does not work well.
> 
> "Luckily" I own one of those machines :P
> 
> > We have an opportunity to investigate and understand very well what
> > are the issues on this BXT. We shouldn't loose track of it.
> 
> That opportunity is now rapidly fleeing, since the HW in
> question is a BXT B0, for which the "drop workarounds" patch series
> has already been submitted and gotten a R-B.

Agree. But since it was a while ago I was trying to hit CI retest on that,
but I couldn't. So could you please resubmit? I just want to see if that
will cause some noise that will force us to file a bug so CI doesn't start
flip-floping again because of this.

> 
> > And maybe adding that to CI we will be forced to record the bug! ;)
> > 
> > >
> > > After all it only changes gen9lp to report that they *can* support PSR
> > > (thus allowing for testing of PSR on such platforms), it doesn't enable
> > > it by default.
> > >
> > > So I'd like to nudge once more that this patch be merged.
> > 
> > I agree. Let's add it. Also good to enable on CNL as well. If the panel
> > that you have there on CNL that is on CI doesn't support it you are about
> > to recurve some panels that does support PSR2.
> 
> Yeah, enabling on CNL too makes sense and getting systematic PSR2 testing
> would be awesome.

nevermind... on another review I notice cnl is already there imported from 
HSW_FEATURES.

> 
> "recurve" => "receive"?

yeap...
(phone auto-corrector believe recurve is the best option for recieve than 
receive :))

Thanks,
Rodrigo.

> 
> 
> Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Inherit Kabylake platform features from Skylake

[Patchwork]

== Series Details ==

Series: drm/i915: Inherit Kabylake platform features from Skylake
URL   : https://patchwork.freedesktop.org/series/31081/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2429 pass:1332 dwarn:4   dfail:0   fail:10  skip:1083 
time:9979s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

[Rodrigo Vivi]

On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote:
> I recently tried to update the gen9 feature matrix and to my unpleasant
> surprise found that Kabylake still acted like Broadwell and didn't
> enable the feature. This is because kbl/cfl are inheriting their
> defaults from Broadwell and not Skylake.

Hmm... I should've considered this would happen someday sooner than later...
My Bad...

> 
> Signed-off-by: Chris Wilson 
> Cc: Rodrigo Vivi 
> Cc: Paulo Zanoni 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 21 +
>  1 file changed, 5 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index da60866b6628..01d4b569b2cc 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -495,13 +495,9 @@ static const struct intel_device_info 
> intel_geminilake_info __initconst = {
>  };
>  
>  #define KBL_PLATFORM \
> - BDW_FEATURES, \

Note that BDW has _FEATURES and _PLATFORM.
The idea is that _FEATURES would be he place to get inherited
while platform was for that specific one and shouldn't be imported by a 
different platform.
so we wouldn't need to overwrite any specific value like .platform.
And we would have a placeholder for the specific values and features that we 
want only
on that particular platform and never propagated to newer ones.

But yeah... that is lame, fragile, non documented and caused confusion. Sorry.

> - .gen = 9, \
> + SKL_PLATFORM, \
>   .platform = INTEL_KABYLAKE, \
> - .has_csr = 1, \
> - .has_guc = 1, \
> - .has_ipc = 1, \
> - .ddb_size = 896
> + .has_ipc = 1
>  
>  static const struct intel_device_info intel_kabylake_gt1_info __initconst = {
>   KBL_PLATFORM,
> @@ -520,13 +516,8 @@ static const struct intel_device_info 
> intel_kabylake_gt3_info __initconst = {
>  };
>  
>  #define CFL_PLATFORM \
> - BDW_FEATURES, \
> - .gen = 9, \
> - .platform = INTEL_COFFEELAKE, \
> - .has_csr = 1, \
> - .has_guc = 1, \
> - .has_ipc = 1, \
> - .ddb_size = 896
> + KBL_PLATFORM, \
> + .platform = INTEL_COFFEELAKE
>  
>  static const struct intel_device_info intel_coffeelake_gt1_info __initconst 
> = {
>   CFL_PLATFORM,
> @@ -545,14 +536,12 @@ static const struct intel_device_info 
> intel_coffeelake_gt3_info __initconst = {
>  };
>  
>  static const struct intel_device_info intel_cannonlake_gt2_info __initconst 
> = {
> - BDW_FEATURES,
> + SKL_PLATFORM,

my OCD doesn't like to read cannonlake as skylake platform...

So maybe we should just kill "_PLATFORM" and rename everything back to 
"FEATURES"
and on this case also it would be better for CFL to inherit KBL one and CNL 
inherit CFL one and on.

The downside is that we again don't have a place for specific features that we 
don't want to propagate.

Thanks for bringing this up,
Rodrigo.

>   .is_alpha_support = 1,
>   .platform = INTEL_CANNONLAKE,
>   .gen = 10,
>   .gt = 2,
>   .ddb_size = 1024,
> - .has_csr = 1,
> - .has_ipc = 1,
>   .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
>  };
>  
> -- 
> 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 series starting with [1/2] meson.sh: Invoke meson correctly

[Patchwork]

== Series Details ==

Series: series starting with [1/2] meson.sh: Invoke meson correctly
URL   : https://patchwork.freedesktop.org/series/31082/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
3df22e0d2f8934311c62e4fd84bee24b32addb58 benchmarks/gem_exec_fault: Update for 
tryhard kernels.

with latest DRM-Tip kernel build CI_DRM_3150
f4bd0d12dbf2 drm-tip: 2017y-09m-28d-13h-39m-47s UTC integration manifest

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (fi-glk-1) fdo#102777 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:478s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:422s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:531s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:501s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:485s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:563s
fi-cnl-y total:289  pass:258  dwarn:0   dfail:0   fail:4   skip:27  
time:671s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-glk-1 total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
time:565s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:424s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:406s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:434s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:489s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:471s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:548s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:753s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:474s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:569s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:421s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/gem_workarounds: Skip write only registers

[Patchwork]

== Series Details ==

Series: tests/gem_workarounds: Skip write only registers
URL   : https://patchwork.freedesktop.org/series/31073/
State : warning

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test gem_eio:
Subgroup wait:
dmesg-warn -> PASS   (shard-hsw) fdo#102886
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-C-planes:
pass   -> SKIP   (shard-hsw)

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2429 pass:1332 dwarn:3   dfail:0   fail:10  skip:1084 
time:9894s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for igt: Add a testsuite to validate VC4 MADV ioctl

[Patchwork]

== Series Details ==

Series: igt: Add a testsuite to validate VC4 MADV ioctl
URL   : https://patchwork.freedesktop.org/series/30959/
State : failure

== Summary ==

Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939
Test prime_self_import:
Subgroup export-vs-gem_close-race:
pass   -> FAIL   (shard-hsw)
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252
Test gem_eio:
Subgroup throttle:
pass   -> DMESG-WARN (shard-hsw) fdo#102886 +1

fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886

shard-hswtotal:2429 pass:1331 dwarn:4   dfail:0   fail:11  skip:1083 
time:9867s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for benchmarks: Actually build LIBDRM_INTEL_BENCHMARKS

[Patchwork]

== Series Details ==

Series: benchmarks: Actually build LIBDRM_INTEL_BENCHMARKS
URL   : https://patchwork.freedesktop.org/series/30970/
State : failure

== Summary ==

Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw)
Subgroup flip-vs-wf_vblank-interruptible:
dmesg-warn -> PASS   (shard-hsw) fdo#100368
Test gem_eio:
Subgroup wait:
dmesg-warn -> PASS   (shard-hsw) fdo#102886 +2
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252 +1

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2429 pass:1332 dwarn:4   dfail:0   fail:10  skip:1083 
time:10042s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_workarounds: Skip write only registers (rev2)

[Patchwork]

== Series Details ==

Series: tests/gem_workarounds: Skip write only registers (rev2)
URL   : https://patchwork.freedesktop.org/series/31073/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
3df22e0d2f8934311c62e4fd84bee24b32addb58 benchmarks/gem_exec_fault: Update for 
tryhard kernels.

with latest DRM-Tip kernel build CI_DRM_3150
f4bd0d12dbf2 drm-tip: 2017y-09m-28d-13h-39m-47s UTC integration manifest

Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (fi-glk-1) fdo#102777

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:449s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:476s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:421s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:521s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:522s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:500s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:493s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:559s
fi-cnl-y total:289  pass:259  dwarn:0   dfail:0   fail:3   skip:27  
time:670s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:420s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:567s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:427s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:408s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:437s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:468s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:579s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:595s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:543s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:746s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:472s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:573s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:419s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for configure.ac: Install and distribute kabylake registers

[Patchwork]

== Series Details ==

Series: configure.ac: Install and distribute kabylake registers
URL   : https://patchwork.freedesktop.org/series/30973/
State : success

== Summary ==

Test gem_eio:
Subgroup in-flight-external:
dmesg-warn -> PASS   (shard-hsw) fdo#102886 +2
Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
dmesg-warn -> PASS   (shard-hsw) fdo#100368

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

shard-hswtotal:2429 pass:1331 dwarn:4   dfail:0   fail:11  skip:1083 
time:10038s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for lib/igt_kms: Convert properties to be more atomic-like. (rev2)

[Patchwork]

== Series Details ==

Series: lib/igt_kms: Convert properties to be more atomic-like. (rev2)
URL   : https://patchwork.freedesktop.org/series/30903/
State : failure

== Summary ==

Test kms_atomic_interruptible:
Subgroup legacy-cursor:
pass   -> FAIL   (shard-hsw)
Subgroup atomic-setmode:
pass   -> FAIL   (shard-hsw)
Subgroup legacy-pageflip:
pass   -> FAIL   (shard-hsw)
Subgroup legacy-dpms:
pass   -> FAIL   (shard-hsw)
Subgroup legacy-setmode:
pass   -> FAIL   (shard-hsw)
Subgroup universal-setplane-primary:
pass   -> FAIL   (shard-hsw)
Subgroup universal-setplane-cursor:
pass   -> FAIL   (shard-hsw)
Test kms_plane_multiple:
Subgroup atomic-pipe-B-tiling-none:
pass   -> SKIP   (shard-hsw)
Subgroup atomic-pipe-C-tiling-none:
pass   -> SKIP   (shard-hsw)
Subgroup atomic-pipe-B-tiling-x:
pass   -> SKIP   (shard-hsw)
Subgroup atomic-pipe-C-tiling-x:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-B:
pass   -> FAIL   (shard-hsw)
Subgroup extended-pageflip-hang-oldfb-render-C:
pass   -> FAIL   (shard-hsw)
Subgroup extended-pageflip-hang-newfb-render-B:
pass   -> FAIL   (shard-hsw)
Subgroup extended-modeset-hang-oldfb-with-reset-render-C:
pass   -> FAIL   (shard-hsw)
Subgroup extended-pageflip-modeset-hang-oldfb-render-B:
pass   -> FAIL   (shard-hsw)
Subgroup extended-modeset-hang-oldfb-render-C:
pass   -> FAIL   (shard-hsw)
Subgroup extended-modeset-hang-oldfb-with-reset-render-B:
pass   -> FAIL   (shard-hsw) fdo#102249 +1
Subgroup extended-modeset-hang-newfb-with-reset-render-B:
pass   -> FAIL   (shard-hsw)
Subgroup extended-pageflip-hang-newfb-render-C:
pass   -> FAIL   (shard-hsw)
Subgroup extended-modeset-hang-newfb-render-C:
pass   -> FAIL   (shard-hsw)
Subgroup extended-modeset-hang-oldfb-render-B:
pass   -> FAIL   (shard-hsw)
Subgroup extended-modeset-hang-newfb-render-B:
pass   -> FAIL   (shard-hsw)
Subgroup extended-pageflip-modeset-hang-oldfb-render-C:
pass   -> FAIL   (shard-hsw)
Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939
Test kms_plane_lowres:
Subgroup pipe-A-tiling-x:
pass   -> FAIL   (shard-hsw)
Subgroup pipe-A-tiling-none:
pass   -> FAIL   (shard-hsw)
Test gem_eio:
Subgroup wait:
dmesg-warn -> PASS   (shard-hsw) fdo#102886 +1
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test gem_sync:
Subgroup basic-store-all:
pass   -> FAIL   (shard-hsw)
Test kms_rotation_crc:
Subgroup sprite-rotation-180-flip:
fail   -> PASS   (shard-hsw) fdo#102691
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_concurrent:
Subgroup pipe-C:
pass   -> SKIP   (shard-hsw)
Subgroup pipe-B:
pass   -> SKIP   (shard-hsw)
Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368

fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102691 https://bugs.freedesktop.org/show_bug.cgi?id=102691
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-hswtotal:2429 pass:1305 dwarn:3   dfail:0   fail:32  skip:1089 
time:9572s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v4,1/6] tests/kms_ccs: Test pipes other than pipe A

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/6] tests/kms_ccs: Test pipes other than pipe 
A
URL   : https://patchwork.freedesktop.org/series/30991/
State : failure

== Summary ==

Test kms_cursor_legacy:
Subgroup cursorA-vs-flipA-atomic-transitions:
pass   -> FAIL   (shard-hsw) fdo#102723
Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939
Test kms_frontbuffer_tracking:
Subgroup fbc-shrfb-scaledprimary:
skip   -> INCOMPLETE (shard-hsw)
Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-hsw) fdo#102886 +2
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#102723 https://bugs.freedesktop.org/show_bug.cgi?id=102723
fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2447 pass:1309 dwarn:4   dfail:0   fail:11  skip:1074 
time:9797s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] Fix rlim_cur compiler warnings when building on ARM.

[Patchwork]

== Series Details ==

Series: series starting with [1/3] Fix rlim_cur compiler warnings when building 
on ARM.
URL   : https://patchwork.freedesktop.org/series/30992/
State : failure

== Summary ==

Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939
Test gem_eio:
Subgroup throttle:
pass   -> DMESG-WARN (shard-hsw) fdo#102886
Test gem_busy:
Subgroup extended-parallel-vebox:
pass   -> SKIP   (shard-hsw)
Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test prime_self_import:
Subgroup export-vs-gem_close-race:
pass   -> FAIL   (shard-hsw)

fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2429 pass:1328 dwarn:6   dfail:0   fail:11  skip:1084 
time:10325s

== Logs ==

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

Re: [Intel-gfx] [PATCH v10 9/9] drm/i915/guc: Fix GuC cleanup in unload path

[Sagar Arun Kamble]

On 9/28/2017 6:45 PM, Sagar Arun Kamble wrote:



On 9/28/2017 5:25 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-09-27 10:30:39)

-void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
+void intel_uc_cleanup(struct drm_i915_private *dev_priv)
  {
 guc_free_load_err_log(_priv->guc);
   if (!i915_modparams.enable_guc_loading)
 return;
  -   guc_disable_communication(_priv->guc);
-
-   if (i915_modparams.enable_guc_submission) {
-   gen9_disable_guc_interrupts(dev_priv);
-   i915_guc_submission_fini(dev_priv);
-   }
-
-   i915_ggtt_disable_guc(dev_priv);
+   if (i915_modparams.enable_guc_submission)
+   i915_guc_submission_cleanup(dev_priv);

My preference would be for if (!guc->stage_desc_pool) return; inside
i915_guc_submission_cleanup().
-Chris
Yes. I have taken similar input in the latest patch - 
https://patchwork.freedesktop.org/patch/179405/
In i915_guc_submission_cleanup we can cover destroy of stage_ids and 
stage_desc_pool based on check you have suggested.
 guc_ads_destroy is always required data so should we link with 
stage_desc_pool check?
intel_guc_log is optional so destroy need to be made dependent on 
guc->log.vma
Realized that vma need not be checked so the check as you suggested 
looks more subtle here.


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

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION (rev3)

[Patchwork]

== Series Details ==

Series: igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION 
(rev3)
URL   : https://patchwork.freedesktop.org/series/30860/
State : success

== Summary ==

Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS   (shard-hsw) fdo#102886
Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939

fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939

shard-hswtotal:2381 pass:1305 dwarn:3   dfail:0   fail:10  skip:1063 
time:9730s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for Fix compilation on some distros

[Patchwork]

== Series Details ==

Series: Fix compilation on some distros
URL   : https://patchwork.freedesktop.org/series/31012/
State : warning

== Summary ==

Test gem_eio:
Subgroup execbuf:
dmesg-warn -> PASS   (shard-hsw) fdo#102886 +1
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-B:
pass   -> DMESG-WARN (shard-hsw)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-busy-crc-atomic:
pass   -> SKIP   (shard-hsw) fdo#102402
Subgroup short-flip-after-cursor-atomic-transitions:
pass   -> SKIP   (shard-hsw)
Test kms_vblank:
Subgroup query-busy:
pass   -> SKIP   (shard-hsw)
Test kms_plane:
Subgroup plane-panning-bottom-right-pipe-A-planes:
pass   -> SKIP   (shard-hsw)
Test kms_atomic_transition:
Subgroup plane-all-transition:
pass   -> SKIP   (shard-hsw)
Test prime_mmap:
Subgroup test_userptr:
pass   -> DMESG-WARN (shard-hsw) fdo#102939
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252 +1
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-hsw) fdo#100047

fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#102402 https://bugs.freedesktop.org/show_bug.cgi?id=102402
fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-hswtotal:2380 pass:1300 dwarn:6   dfail:0   fail:9   skip:1064 
time:9761s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Inherit Kabylake platform features from Skylake

[Patchwork]

== Series Details ==

Series: drm/i915: Inherit Kabylake platform features from Skylake
URL   : https://patchwork.freedesktop.org/series/31081/
State : success

== Summary ==

Series 31081v1 drm/i915: Inherit Kabylake platform features from Skylake
https://patchwork.freedesktop.org/api/1.0/series/31081/revisions/1/mbox/

Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-glk-1) fdo#102777 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:472s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:422s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:515s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:488s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:555s
fi-cnl-y total:289  pass:259  dwarn:0   dfail:0   fail:3   skip:27  
time:644s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-glk-1 total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
time:558s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:425s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:402s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:432s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:485s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:463s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:589s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:543s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:749s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:472s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:562s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:416s

f4bd0d12dbf2f755c59191bce22363d43be6cf2a drm-tip: 2017y-09m-28d-13h-39m-47s UTC 
integration manifest
9736686a8d5c drm/i915: Inherit Kabylake platform features from Skylake

== Logs ==

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

[Intel-gfx] [PATCH i-g-t 1/2] meson.sh: Invoke meson correctly

[Petri Latvala]

Either source or build directory is required as a command line
parameter.

Also use mkdir -p when creating the build directory to avoid errors
when it already exists.

Signed-off-by: Petri Latvala 
---
 meson.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meson.sh b/meson.sh
index eff86adb..cbf1a932 100755
--- a/meson.sh
+++ b/meson.sh
@@ -6,8 +6,8 @@ cat > Makefile 

Re: [Intel-gfx] [PATCH i-g-t 2/2] meson: Also build kms_atomic_interruptible

[Daniel Vetter]

On Thu, Sep 28, 2017 at 06:10:48PM +0300, Petri Latvala wrote:
> Signed-off-by: Petri Latvala 
> ---
>  tests/meson.build | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/meson.build b/tests/meson.build
> index 1c619179..53d02d13 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -152,6 +152,7 @@ test_progs = [
>   'kms_3d',
>   'kms_addfb_basic',
>   'kms_atomic',
> + 'kms_atomic_interruptible',

Yeah I guess that's a recent addition, the lists did match when I tested
things. On both patches

Reviewed-by: Daniel Vetter 

>   'kms_atomic_transition',
>   'kms_busy',
>   'kms_ccs',
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 2/2] meson: Also build kms_atomic_interruptible

[Petri Latvala]

Signed-off-by: Petri Latvala 
---
 tests/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/meson.build b/tests/meson.build
index 1c619179..53d02d13 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -152,6 +152,7 @@ test_progs = [
'kms_3d',
'kms_addfb_basic',
'kms_atomic',
+   'kms_atomic_interruptible',
'kms_atomic_transition',
'kms_busy',
'kms_ccs',
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

[Petri Latvala]

On Thu, Sep 28, 2017 at 06:00:03PM +0300, Mika Kuoppala wrote:
> We have no means to check write only registers as
> this would need access through context image. For now we
> know that cnl has a one such register, 0xe5f0 which is used
> to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting
> the context image without and with workaround applied:
> 
> 0xa840: 0xe5f0 0x0800
> 0xa840: 0xe5f0 0x0820
> 
> we can conclude that the workaround setup is working right
> in this particular case.
> 
> Add a write only list and add register 0xe5f0 into this list.
> This is a temporary solution until a more capable context image
> checker emerges.
> 
> v2: add code comment about adhocness (Petri)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102943
> Cc: Oscar Mateo 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Cc: Petri Latvala 
> Signed-off-by: Mika Kuoppala 
> Reviewed-by: Chris Wilson 
> ---
>  tests/gem_workarounds.c | 38 +-
>  1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
> index d6641bd5..5e30a7b8 100644
> --- a/tests/gem_workarounds.c
> +++ b/tests/gem_workarounds.c
> @@ -29,6 +29,8 @@
>  
>  #include 
>  
> +static int gen;
> +
>  enum operation {
>   GPU_RESET,
>   SUSPEND_RESUME,
> @@ -41,6 +43,21 @@ struct intel_wa_reg {
>   uint32_t mask;
>  };
>  
> +static struct write_only_list {
> + unsigned int gen;
> + uint32_t addr;
> +} wo_list[] = {
> + { 10, 0xE5F0 } /* WaForceContextSaveRestoreNonCoherent:cnl */
> +
> + /*
> +  * FIXME: If you are contemplating adding stuff here
> +  * consider this as a temporary solution. You need to
> +  * manually check from context image that your workaround
> +  * is having an effect. Consider creating a context image
> +  * validator to act as a superior solution.
> +  */
> +};

Excellent.

Reviewed-by: Petri Latvala 




>  static struct intel_wa_reg *wa_regs;
>  static int num_wa_regs;
>  
> @@ -64,6 +81,21 @@ static void test_suspend_resume(void)
>   igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
>  }
>  
> +static bool write_only(const uint32_t addr)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(wo_list); i++) {
> + if (gen == wo_list[i].gen &&
> + addr == wo_list[i].addr) {
> + igt_info("Skipping check for 0x%x due to write only\n", 
> addr);
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int workaround_fail_count(void)
>  {
>   int i, fail_count = 0;
> @@ -85,6 +117,9 @@ static int workaround_fail_count(void)
> wa_regs[i].addr, wa_regs[i].value, wa_regs[i].mask,
> val, ok ? "OK" : "FAIL");
>  
> + if (write_only(wa_regs[i].addr))
> + continue;
> +
>   if (!ok) {
>   igt_warn("0x%05X\t0x%08X\t0x%08X\t0x%08X\t%s\n",
>wa_regs[i].addr, wa_regs[i].value,
> @@ -124,7 +159,6 @@ igt_main
>  {
>   igt_fixture {
>   int device = drm_open_driver_master(DRIVER_INTEL);
> - const int gen = intel_gen(intel_get_drm_devid(device));
>   struct pci_device *pci_dev;
>   FILE *file;
>   char *line = NULL;
> @@ -133,6 +167,8 @@ igt_main
>  
>   igt_require_gem(device);
>  
> + gen = intel_gen(intel_get_drm_devid(device));
> +
>   pci_dev = intel_get_pci_device();
>   igt_require(pci_dev);
>  
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

[Mika Kuoppala]

We have no means to check write only registers as
this would need access through context image. For now we
know that cnl has a one such register, 0xe5f0 which is used
to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting
the context image without and with workaround applied:

0xa840: 0xe5f0 0x0800
0xa840: 0xe5f0 0x0820

we can conclude that the workaround setup is working right
in this particular case.

Add a write only list and add register 0xe5f0 into this list.
This is a temporary solution until a more capable context image
checker emerges.

v2: add code comment about adhocness (Petri)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102943
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Petri Latvala 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 tests/gem_workarounds.c | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
index d6641bd5..5e30a7b8 100644
--- a/tests/gem_workarounds.c
+++ b/tests/gem_workarounds.c
@@ -29,6 +29,8 @@
 
 #include 
 
+static int gen;
+
 enum operation {
GPU_RESET,
SUSPEND_RESUME,
@@ -41,6 +43,21 @@ struct intel_wa_reg {
uint32_t mask;
 };
 
+static struct write_only_list {
+   unsigned int gen;
+   uint32_t addr;
+} wo_list[] = {
+   { 10, 0xE5F0 } /* WaForceContextSaveRestoreNonCoherent:cnl */
+
+   /*
+* FIXME: If you are contemplating adding stuff here
+* consider this as a temporary solution. You need to
+* manually check from context image that your workaround
+* is having an effect. Consider creating a context image
+* validator to act as a superior solution.
+*/
+};
+
 static struct intel_wa_reg *wa_regs;
 static int num_wa_regs;
 
@@ -64,6 +81,21 @@ static void test_suspend_resume(void)
igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
 }
 
+static bool write_only(const uint32_t addr)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(wo_list); i++) {
+   if (gen == wo_list[i].gen &&
+   addr == wo_list[i].addr) {
+   igt_info("Skipping check for 0x%x due to write only\n", 
addr);
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int workaround_fail_count(void)
 {
int i, fail_count = 0;
@@ -85,6 +117,9 @@ static int workaround_fail_count(void)
  wa_regs[i].addr, wa_regs[i].value, wa_regs[i].mask,
  val, ok ? "OK" : "FAIL");
 
+   if (write_only(wa_regs[i].addr))
+   continue;
+
if (!ok) {
igt_warn("0x%05X\t0x%08X\t0x%08X\t0x%08X\t%s\n",
 wa_regs[i].addr, wa_regs[i].value,
@@ -124,7 +159,6 @@ igt_main
 {
igt_fixture {
int device = drm_open_driver_master(DRIVER_INTEL);
-   const int gen = intel_gen(intel_get_drm_devid(device));
struct pci_device *pci_dev;
FILE *file;
char *line = NULL;
@@ -133,6 +167,8 @@ igt_main
 
igt_require_gem(device);
 
+   gen = intel_gen(intel_get_drm_devid(device));
+
pci_dev = intel_get_pci_device();
igt_require(pci_dev);
 
-- 
2.11.0

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

[Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

[Chris Wilson]

I recently tried to update the gen9 feature matrix and to my unpleasant
surprise found that Kabylake still acted like Broadwell and didn't
enable the feature. This is because kbl/cfl are inheriting their
defaults from Broadwell and not Skylake.

Signed-off-by: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Paulo Zanoni 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_pci.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index da60866b6628..01d4b569b2cc 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -495,13 +495,9 @@ static const struct intel_device_info 
intel_geminilake_info __initconst = {
 };
 
 #define KBL_PLATFORM \
-   BDW_FEATURES, \
-   .gen = 9, \
+   SKL_PLATFORM, \
.platform = INTEL_KABYLAKE, \
-   .has_csr = 1, \
-   .has_guc = 1, \
-   .has_ipc = 1, \
-   .ddb_size = 896
+   .has_ipc = 1
 
 static const struct intel_device_info intel_kabylake_gt1_info __initconst = {
KBL_PLATFORM,
@@ -520,13 +516,8 @@ static const struct intel_device_info 
intel_kabylake_gt3_info __initconst = {
 };
 
 #define CFL_PLATFORM \
-   BDW_FEATURES, \
-   .gen = 9, \
-   .platform = INTEL_COFFEELAKE, \
-   .has_csr = 1, \
-   .has_guc = 1, \
-   .has_ipc = 1, \
-   .ddb_size = 896
+   KBL_PLATFORM, \
+   .platform = INTEL_COFFEELAKE
 
 static const struct intel_device_info intel_coffeelake_gt1_info __initconst = {
CFL_PLATFORM,
@@ -545,14 +536,12 @@ static const struct intel_device_info 
intel_coffeelake_gt3_info __initconst = {
 };
 
 static const struct intel_device_info intel_cannonlake_gt2_info __initconst = {
-   BDW_FEATURES,
+   SKL_PLATFORM,
.is_alpha_support = 1,
.platform = INTEL_CANNONLAKE,
.gen = 10,
.gt = 2,
.ddb_size = 1024,
-   .has_csr = 1,
-   .has_ipc = 1,
.color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
 };
 
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH igt v3] igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION

[Joonas Lahtinen]

On Wed, 2017-09-27 at 19:47 +0100, Chris Wilson wrote:
> Michal wants to limit machines that can do preemption, which means that
> we no longer can assume that if we have a scheduler for execbuf, that
> implies we have preemption.
> 
> v2: Try a capability mask instead
> v3: Pretty print the caps.
> 
> Signed-off-by: Chris Wilson 



> +++ b/tests/gem_exec_schedule.c
> @@ -32,7 +32,12 @@
>  #include "igt_rand.h"
>  #include "igt_sysfs.h"
>  
> +#define BIT(x) (1ul << (x))
> +
>  #define LOCAL_PARAM_HAS_SCHEDULER 41
> +#define   HAS_SCHEDULER  BIT(0)
> +#define   HAS_PRIORITY   BIT(1)
> +#define   HAS_PREEMPTION BIT(2)

This seems to be all spaces?

> +static unsigned int has_scheduler(int fd)
>  {
>   drm_i915_getparam_t gp;
> - int has = -1;
> + unsigned int caps = 0;
> + char buf[200];
> + size_t len = 0;
>  
>   gp.param = LOCAL_PARAM_HAS_SCHEDULER;
> - gp.value = 
> + gp.value = (int *)
>   drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
>  
> - return has > 0;
> + if (!caps)
> + return 0;
> +
> + len = snprintf(buf, sizeof(buf), "Has kernel scheduler");
> + if (caps & HAS_PRIORITY)
> + len += snprintf(buf + len, sizeof(buf) - len,
> + "%s context priorities",
> + caps & (HAS_PRIORITY - 2) ? "," : " with");
> +
> + if (caps & HAS_PREEMPTION)
> + len += snprintf(buf + len, sizeof(buf) - len,
> + "%s batchbuffer preemption",
> + caps & (HAS_PREEMPTION - 2) ? "," : " with");

The output is not going to be published in PEOPLE magazine, maybe we
can do a simpler indented "- with ..." prints :P

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_workarounds: Skip write only registers

[Patchwork]

== Series Details ==

Series: tests/gem_workarounds: Skip write only registers
URL   : https://patchwork.freedesktop.org/series/31073/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
2885b10f99b4beeb046e75af8b8488c229f629d3 igt/gem_exec_schedule: Ignore 
set-priority failures on old kernels

with latest DRM-Tip kernel build CI_DRM_3150
f4bd0d12dbf2 drm-tip: 2017y-09m-28d-13h-39m-47s UTC integration manifest

Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (fi-glk-1) fdo#102777

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:471s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:420s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:524s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:494s
fi-cfl-s total:289  pass:256  dwarn:1   dfail:0   fail:0   skip:32  
time:557s
fi-cnl-y total:289  pass:259  dwarn:0   dfail:0   fail:3   skip:27  
time:667s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:572s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:428s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:406s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:444s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:470s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:579s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:595s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:553s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:753s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:479s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:570s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:416s

== Logs ==

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

Re: [Intel-gfx] [PATCH v1] drm/i915: Enhanced for initialize partially filled pagetables

[Joonas Lahtinen]

On Thu, 2017-09-28 at 10:09 +0800, Xiaolin Zhang wrote:
> if vgpu active, the page table entry should be initialized after
> allocation and then the hypersivor can ping pages succesuffly,
> otherwise hypervisor will ping pages failed and the host will print
> a lot of annoying errors such as “ERROR gvt: guest page write error -22,
> gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 1” when create linux guest.
> 
> Signed-off-by: Xiaolin Zhang 

Why does the hypervisor try to access the entries prior to them being
made valid for hardware?

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 v2 11/11] drm/i915/scheduler: Support user-defined priorities

[Joonas Lahtinen]

On Wed, 2017-09-27 at 17:44 +0100, Chris Wilson wrote:
> Use a priority stored in the context as the initial value when
> submitting a request. This allows us to change the default priority on a
> per-context basis, allowing different contexts to be favoured with GPU
> time at the expense of lower importance work. The user can adjust the
> context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
> values being higher priority (they will be serviced earlier, after their
> dependencies have been resolved). Any prerequisite work for an execbuf
> will have its priority raised to match the new request as required.
> 
> Normal users can specify any value in the range of -1023 to 0 [default],
> i.e. they can reduce the priority of their workloads (and temporarily
> boost it back to normal if so desired).
> 
> Privileged users can specify any value in the range of -1023 to 1023,
> [default is 0], i.e. they can raise their priority above all overs and
> so potentially starve the system.
> 
> Note that the existing schedulers are not fair, nor load balancing, the
> execution is strictly by priority on a first-come, first-served basis,
> and the driver may choose to boost some requests above the range
> available to users.
> 
> This priority was originally based around nice(2), but evolved to allow
> clients to adjust their priority within a small range, and allow for a
> privileged high priority range.
> 
> For example, this can be used to implement EGL_IMG_context_priority
> https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
> 
>   EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
> the context to be created. This attribute is a hint, as an
> implementation may not support multiple contexts at some
> priority levels and system policy may limit access to high
> priority contexts to appropriate system privilege level. The
> default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
> EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
> 
> so we can map
> 
>   PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
>   PRIORITY_MED -> 0 [default]
>   PRIORITY_LOW -> -1023
> 
> They also map onto the priorities used by VkQueue (and a VkQueue is
> essentially a timeline, our i915_gem_context under full-ppgtt).
> 
> v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
> v3: Report min/max user priorities as defines in the uapi, and rebase
> internal priorities on the exposed values.
> 
> Testcase: igt/gem_exec_schedule
> Signed-off-by: Chris Wilson 
> Reviewed-by: Tvrtko Ursulin 

We should be good to go once Mesa is.

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

[Petri Latvala]

On Thu, Sep 28, 2017 at 04:45:06PM +0300, Mika Kuoppala wrote:
> We have no means to check write only registers as
> this would need access through context image. For now we
> know that cnl has a one such register, 0xe5f0 which is used
> to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting
> the context image without and with workaround applied:
> 
> 0xa840: 0xe5f0 0x0800
> 0xa840: 0xe5f0 0x0820
> 
> we can conclude that the workaround setup is working right
> in this particular case.
> 
> Add a write only list and add register 0xe5f0 into this list.
> This is a temporary solution until a more capable context image
> checker emerges.


According to old wisdom, nothing is as permanent as a temporary
solution. I'd like this temporary-ness noted in a comment in the code
as well to ease future generations who finally get to fix this
properly.



-- 
Petri Latvala



> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102943
> Cc: Oscar Mateo 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Signed-off-by: Mika Kuoppala 
> ---
>  tests/gem_workarounds.c | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
> index d6641bd5..03b4dc6c 100644
> --- a/tests/gem_workarounds.c
> +++ b/tests/gem_workarounds.c
> @@ -29,6 +29,8 @@
>  
>  #include 
>  
> +static int gen;
> +
>  enum operation {
>   GPU_RESET,
>   SUSPEND_RESUME,
> @@ -41,6 +43,13 @@ struct intel_wa_reg {
>   uint32_t mask;
>  };
>  
> +static struct write_only_list {
> + unsigned int gen;
> + uint32_t addr;
> +} wo_list[] = {
> + { 10, 0xE5F0 } /* WaForceContextSaveRestoreNonCoherent:cnl */
> +};
> +
>  static struct intel_wa_reg *wa_regs;
>  static int num_wa_regs;
>  
> @@ -64,6 +73,21 @@ static void test_suspend_resume(void)
>   igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
>  }
>  
> +static bool write_only(const uint32_t addr)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(wo_list); i++) {
> + if (gen == wo_list[i].gen &&
> + addr == wo_list[i].addr) {
> + igt_info("Skipping check for 0x%x due to write only\n", 
> addr);
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int workaround_fail_count(void)
>  {
>   int i, fail_count = 0;
> @@ -85,6 +109,9 @@ static int workaround_fail_count(void)
> wa_regs[i].addr, wa_regs[i].value, wa_regs[i].mask,
> val, ok ? "OK" : "FAIL");
>  
> + if (write_only(wa_regs[i].addr))
> + continue;
> +
>   if (!ok) {
>   igt_warn("0x%05X\t0x%08X\t0x%08X\t0x%08X\t%s\n",
>wa_regs[i].addr, wa_regs[i].value,
> @@ -124,7 +151,6 @@ igt_main
>  {
>   igt_fixture {
>   int device = drm_open_driver_master(DRIVER_INTEL);
> - const int gen = intel_gen(intel_get_drm_devid(device));
>   struct pci_device *pci_dev;
>   FILE *file;
>   char *line = NULL;
> @@ -133,6 +159,8 @@ igt_main
>  
>   igt_require_gem(device);
>  
> + gen = intel_gen(intel_get_drm_devid(device));
> +
>   pci_dev = intel_get_pci_device();
>   igt_require(pci_dev);
>  
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 10/11] drm/i915/execlists: Preemption!

[Joonas Lahtinen]

On Wed, 2017-09-27 at 17:44 +0100, Chris Wilson wrote:
> When we write to ELSP, it triggers a context preemption at the earliest
> arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
> operations and the explicit MI_ARB_CHECK). If this is to the same
> context, it triggers a LITE_RESTORE where the RING_TAIL is merely
> updated (used currently to chain requests from the same context
> together, avoiding bubbles). However, if it is to a different context, a
> full context-switch is performed and it will start to execute the new
> context saving the image of the old for later execution.
> 
> Previously we avoided preemption by only submitting a new context when
> the old was idle. But now we wish embrace it, and if the new request has
> a higher priority than the currently executing request, we write to the
> ELSP regardless, thus triggering preemption, but we tell the GPU to
> switch to our special preemption context (not the target). In the
> context-switch interrupt handler, we know that the previous contexts
> have finished execution and so can unwind all the incomplete requests
> and compute the new highest priority request to execute.
> 
> It would be feasible to avoid the switch-to-idle intermediate by
> programming the ELSP with the target context. The difficulty is in
> tracking which request that should be whilst maintaining the dependency
> change, the error comes in with coalesced requests. As we only track the
> most recent request and its priority, we may run into the issue of being
> tricked in preempting a high priority request that was followed by a
> low priority request from the same context (e.g. for PI);

"followed" is bit ambiguous here, depending on how you view the
ordering, wall time or ports.

> worse still
> that earlier request may be our own dependency and the order then broken
> by preemption. By injecting the switch-to-idle and then recomputing the
> priority queue, we avoid the issue with tracking in-flight coalesced
> requests. Having tried the preempt-to-busy approach, and failed to find
> a way around the coalesced priority issue, Michal's original proposal to
> inject an idle context (based on handling GuC preemption) succeeds.
> 
> The current heuristic for deciding when to preempt are only if the new
> request is of higher priority, and has the privileged priority of
> greater than 0. Note that the scheduler remains unfair!
> 
> v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
> Since, the feature is now conditional and not always available when we
> have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
> capability mask).
> 
> Suggested-by: Michal Winiarski 
> Signed-off-by: Chris Wilson 
> Cc: Michal Winiarski 
> Cc: Tvrtko Ursulin 
> Cc: Arkadiusz Hiler 
> Cc: Mika Kuoppala 
> Cc: Ben Widawsky 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 



> @@ -489,26 +489,44 @@ static void port_assign(struct execlist_port *port,
>   port_set(port, port_pack(i915_gem_request_get(rq), port_count(port)));
>  }
>  
> +static void inject_preempt_context(struct intel_engine_cs *engine)
> +{
> + struct intel_context *ce =
> + >i915->preempt_context->engine[engine->id];
> + u32 __iomem *elsp =
> + engine->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));

engine_elsp() helper or so?

> + unsigned int n;
> +
> + GEM_BUG_ON(engine->i915->preempt_context->hw_id != PREEMPT_ID);

I think this could/should be done way earlier?

> +
> + memset(ce->ring->vaddr + ce->ring->tail, 0, 8);
> + ce->ring->tail += 8;
> + ce->ring->tail &= (ce->ring->size - 1);
> + ce->lrc_reg_state[CTX_RING_TAIL+1] = ce->ring->tail;

An awful lot of pre-expectations here, would be shame if somebody
documented them.

> +
> + for (n = execlists_num_ports(>execlists); --n; ) {

This is fine detail compared to the other loop, "<=" vs "<" (or maybe
even <= -1) would make a more clear distinction, but I'm not arguing.

> + writel(0, elsp);
> + writel(0, elsp);
> + }
> + writel(upper_32_bits(ce->lrc_desc), elsp);
> + writel(lower_32_bits(ce->lrc_desc), elsp);

Could also be elsp_write inline helper.

> @@ -696,7 +746,7 @@ static void intel_lrc_irq_handler(unsigned long data)
>  {
>   struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
>   struct intel_engine_execlists * const execlists = >execlists;
> - struct execlist_port *port = execlists->port;
> + struct execlist_port * const port = execlists->port;
>   struct drm_i915_private *dev_priv = engine->i915;
>  
>   /* We can skip acquiring intel_runtime_pm_get() here as it was taken
> @@ -781,6 +831,23 @@ static void intel_lrc_irq_handler(unsigned long data)
>   

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

[Chris Wilson]

Quoting Mika Kuoppala (2017-09-28 14:45:06)
> We have no means to check write only registers as
> this would need access through context image. For now we
> know that cnl has a one such register, 0xe5f0 which is used
> to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting
> the context image without and with workaround applied:
> 
> 0xa840: 0xe5f0 0x0800
> 0xa840: 0xe5f0 0x0820
> 
> we can conclude that the workaround setup is working right
> in this particular case.
> 
> Add a write only list and add register 0xe5f0 into this list.
> This is a temporary solution until a more capable context image
> checker emerges.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102943
> Cc: Oscar Mateo 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Signed-off-by: Mika Kuoppala 

It makes sense given the discovery of the w/o register. I was thinking
of how we could communicate these through the debugfs, but I think any
changes in direction involve pulling this test into the kernel. So, this
appears to be the pragmatic solution.

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

[Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

[Mika Kuoppala]

We have no means to check write only registers as
this would need access through context image. For now we
know that cnl has a one such register, 0xe5f0 which is used
to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting
the context image without and with workaround applied:

0xa840: 0xe5f0 0x0800
0xa840: 0xe5f0 0x0820

we can conclude that the workaround setup is working right
in this particular case.

Add a write only list and add register 0xe5f0 into this list.
This is a temporary solution until a more capable context image
checker emerges.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102943
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Signed-off-by: Mika Kuoppala 
---
 tests/gem_workarounds.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
index d6641bd5..03b4dc6c 100644
--- a/tests/gem_workarounds.c
+++ b/tests/gem_workarounds.c
@@ -29,6 +29,8 @@
 
 #include 
 
+static int gen;
+
 enum operation {
GPU_RESET,
SUSPEND_RESUME,
@@ -41,6 +43,13 @@ struct intel_wa_reg {
uint32_t mask;
 };
 
+static struct write_only_list {
+   unsigned int gen;
+   uint32_t addr;
+} wo_list[] = {
+   { 10, 0xE5F0 } /* WaForceContextSaveRestoreNonCoherent:cnl */
+};
+
 static struct intel_wa_reg *wa_regs;
 static int num_wa_regs;
 
@@ -64,6 +73,21 @@ static void test_suspend_resume(void)
igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
 }
 
+static bool write_only(const uint32_t addr)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(wo_list); i++) {
+   if (gen == wo_list[i].gen &&
+   addr == wo_list[i].addr) {
+   igt_info("Skipping check for 0x%x due to write only\n", 
addr);
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int workaround_fail_count(void)
 {
int i, fail_count = 0;
@@ -85,6 +109,9 @@ static int workaround_fail_count(void)
  wa_regs[i].addr, wa_regs[i].value, wa_regs[i].mask,
  val, ok ? "OK" : "FAIL");
 
+   if (write_only(wa_regs[i].addr))
+   continue;
+
if (!ok) {
igt_warn("0x%05X\t0x%08X\t0x%08X\t0x%08X\t%s\n",
 wa_regs[i].addr, wa_regs[i].value,
@@ -124,7 +151,6 @@ igt_main
 {
igt_fixture {
int device = drm_open_driver_master(DRIVER_INTEL);
-   const int gen = intel_gen(intel_get_drm_devid(device));
struct pci_device *pci_dev;
FILE *file;
char *line = NULL;
@@ -133,6 +159,8 @@ igt_main
 
igt_require_gem(device);
 
+   gen = intel_gen(intel_get_drm_devid(device));
+
pci_dev = intel_get_pci_device();
igt_require(pci_dev);
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v10 1/9] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors

[Sagar Arun Kamble]

On 9/28/2017 5:07 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-09-27 10:30:31)

These changes are preparation to handle GuC suspend/resume. Prepared
helper i915_gem_runtime_resume to reinitialize suspended gem setup.
Returning status from i915_gem_runtime_suspend and i915_gem_resume.
This will be placeholder for handling any errors from uC suspend/resume
in upcoming patches. Restructured the suspend/resume routines w.r.t setup
creation and rollback order.
This also fixes issue of ordering of i915_gem_runtime_resume with
intel_runtime_pm_enable_interrupts.

v2: Fixed return from intel_runtime_resume. (Michał Winiarski)

v3: Not returning status from gem_runtime_resume. (Chris)

Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Imre Deak 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
---
  drivers/gpu/drm/i915/i915_drv.c | 22 +-
  drivers/gpu/drm/i915/i915_drv.h |  5 +++--
  drivers/gpu/drm/i915/i915_gem.c | 18 --
  3 files changed, 32 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7056bb2..d0a710d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1655,6 +1655,7 @@ static int i915_suspend_switcheroo(struct drm_device 
*dev, pm_message_t state)
  static int i915_drm_resume(struct drm_device *dev)
  {
 struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
 int ret;
  
 disable_rpm_wakeref_asserts(dev_priv);

@@ -1666,7 +1667,9 @@ static int i915_drm_resume(struct drm_device *dev)
  
 intel_csr_ucode_resume(dev_priv);
  
-   i915_gem_resume(dev_priv);

+   ret = i915_gem_resume(dev_priv);
+   if (ret)
+   dev_err(>dev, "GEM resume failed\n");

I am still uneasy about this. Later on in the resume we try to reinit
the hw under the assumption that this earlier step succeeded.

Previously we have tried to make sure that if GEM fails, we do not leave
the display in an unusable state. Is that still true?
As part of gem_resume we are resuming GuC and if that fails we are 
declaring gem wedged.
Will that be okay or we ignore the GuC resume failure and go ahead with 
reinit?
  
 i915_restore_state(dev_priv);

 intel_pps_unlock_regs_wa(dev_priv);
@@ -2495,7 +2498,11 @@ static int intel_runtime_suspend(struct device *kdev)
  * We are safe here against re-faults, since the fault handler takes
  * an RPM reference.
  */
-   i915_gem_runtime_suspend(dev_priv);
+   ret = i915_gem_runtime_suspend(dev_priv);
+   if (ret) {
+   enable_rpm_wakeref_asserts(dev_priv);
+   return ret;
+   }
  
 intel_guc_suspend(dev_priv);
  
@@ -2515,6 +2522,8 @@ static int intel_runtime_suspend(struct device *kdev)

 DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
 intel_runtime_pm_enable_interrupts(dev_priv);
  
+   intel_guc_resume(dev_priv);

+   i915_gem_runtime_resume(dev_priv);
 enable_rpm_wakeref_asserts(dev_priv);
  
 return ret;

@@ -2596,13 +2605,6 @@ static int intel_runtime_resume(struct device *kdev)
 ret = vlv_resume_prepare(dev_priv, true);
 }
  
-   /*

-* No point of rolling back things in case of an error, as the best
-* we can do is to hope that things will still work (and disable RPM).
-*/

This comment shouldn't be attached to the following gem init operations
as they cannot fail. If they could, we should be throwing a warning here
as this may result in a change of swizzling/fencing state as seen by
userspace and therefore graphical corruption.
-Chris

Ok. Will remove this comment.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915/execlists: Keep request->priority for its lifetime

[Michał Winiarski]

On Thu, Sep 28, 2017 at 11:09:14AM +, Chris Wilson wrote:
> Quoting Chris Wilson (2017-09-27 17:44:37)
> > With preemption, we will want to "unsubmit" a request, taking it back
> > from the hw and returning it to the priority sorted execution list. In
> > order to know where to insert it into that list, we need to remember
> > its adjust priority (which may change even as it was being executed).
> s/adjust/adjusted/
> 
> "This also affects reset for execlists as we are now unsubmitting the
> requests following the reset (rather than directly writing the ELSP for
> the inflight contexts). This turns reset into an accidental preemption
> point, as after the reset we may choose a different pair of contexts to
> submit to hw.
> 
> GuC is not updated as this series doesn't add preemption to the GuC
> submission, and so it can keep benefiting from the early pruning of the
> DFS inside execlists_schedule() for a little longer. We also need to
> find a way of reducing the cost of that DFS..."
> 

Reviewed-by: Michał Winiarski 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/gem_exec_schedule: Detect too slow setup in deep-*

[Patchwork]

== Series Details ==

Series: igt/gem_exec_schedule: Detect too slow setup in deep-*
URL   : https://patchwork.freedesktop.org/series/31061/
State : success

== Summary ==

Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-hsw) fdo#102886 +2
Test gem_exec_reloc:
Subgroup basic-write-read-noreloc:
incomplete -> PASS   (shard-hsw) fdo#102332
Test kms_flip:
Subgroup plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#102504
Subgroup wf_vblank-vs-modeset:
pass   -> DMESG-WARN (shard-hsw) fdo#102614
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252
Test kms_cursor_legacy:
Subgroup cursorA-vs-flipA-atomic-transitions:
fail   -> PASS   (shard-hsw) fdo#102723
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_atomic_transition:
Subgroup plane-all-transition-nonblocking:
pass   -> FAIL   (shard-hsw) fdo#102671

fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332
fdo#102504 https://bugs.freedesktop.org/show_bug.cgi?id=102504
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102723 https://bugs.freedesktop.org/show_bug.cgi?id=102723
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102671 https://bugs.freedesktop.org/show_bug.cgi?id=102671

shard-hswtotal:2429 pass:1327 dwarn:6   dfail:0   fail:13  skip:1083 
time:9894s

== Logs ==

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

Re: [Intel-gfx] [PATCH v10 2/9] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences

[Sagar Arun Kamble]

On 9/28/2017 5:10 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-09-27 10:30:32)

@@ -4607,13 +4611,14 @@ int i915_gem_resume(struct drm_i915_private *dev_priv)
  
 mutex_lock(>struct_mutex);

 i915_gem_restore_gtt_mappings(dev_priv);
+   i915_gem_restore_fences(dev_priv);

Seconded Michal's suggestion, otherwise it looks very clean.
-Chris
This has been updated in the following patch in the latest revision of 
series:

https://patchwork.freedesktop.org/patch/179403/

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

Re: [Intel-gfx] [PATCH v10 6/9] drm/i915/guc: Check execbuf client to disable submission and don't depend on enable_guc_submission

[Sagar Arun Kamble]

On 9/28/2017 5:17 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-09-27 10:30:36)

We should check dependent state setup by enable path to run disable path
and not depend on the user parameters. i915_guc_submission_disable now
checks if execbuf client is setup and then goes ahead with disabling.

Suggested-by: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Michał Winiarski 

Reviewed-by: Chris Wilson 
-Chris
Thanks for the review Chris. I have this change as part of latest patch 
- https://patchwork.freedesktop.org/patch/179405/

Could you please review this patch.

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