[Intel-gfx] [PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Here goes drm-intel-fixes-2018-03-21:

One fix for DP MST and one fix for GPU reset on hang check.

Thanks,
Rodrigo.

The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f:

  Linux 4.16-rc6 (2018-03-18 17:48:42 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-03-21

for you to fetch changes up to 3a088dd1b72dc0fc2e7ee1fca76e26290c5261a0:

  drm/i915: Specify which engines to reset following semaphore/event lockups 
(2018-03-21 07:59:08 -0700)


One fix for DP MST and one fix for GPU reset on hang check.


Chris Wilson (1):
  drm/i915: Specify which engines to reset following semaphore/event lockups

Dhinakaran Pandiyan (1):
  drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

 drivers/gpu/drm/i915/intel_ddi.c   | 7 ++-
 drivers/gpu/drm/i915/intel_hangcheck.c | 4 ++--
 2 files changed, 4 insertions(+), 7 deletions(-)
___
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: Fix uabi regression by allowing garbage mode->type from userspace

[Patchwork]

== Series Details ==

Series: drm: Fix uabi regression by allowing garbage mode->type from userspace
URL   : https://patchwork.freedesktop.org/series/40416/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#103167
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> FAIL   (shard-hsw) fdo#103481
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912

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

shard-apltotal:3478 pass:1814 dwarn:1   dfail:0   fail:8   skip:1655 
time:13071s
shard-hswtotal:3478 pass:1766 dwarn:1   dfail:0   fail:3   skip:1707 
time:11879s
shard-snbtotal:3478 pass:1357 dwarn:1   dfail:0   fail:3   skip:2117 
time:7296s
Blacklisted hosts:
shard-kbltotal:3478 pass:1940 dwarn:1   dfail:0   fail:9   skip:1528 
time:9928s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8441/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 series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Include the trace as a 
debug aide
URL   : https://patchwork.freedesktop.org/series/40410/
State : warning

== Summary ==

 Possible new issues:

Test kms_atomic_transition:
Subgroup plane-toggle-modeset-transition:
pass   -> DMESG-WARN (shard-hsw)

 Known issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-mmap-wc:
pass   -> FAIL   (shard-apl) fdo#101623
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3478 pass:1813 dwarn:1   dfail:0   fail:8   skip:1655 
time:13175s
shard-hswtotal:3423 pass:1738 dwarn:2   dfail:0   fail:1   skip:1680 
time:11260s
shard-snbtotal:3478 pass:1357 dwarn:1   dfail:0   fail:3   skip:2117 
time:7261s
Blacklisted hosts:
shard-kbltotal:3478 pass:1938 dwarn:1   dfail:1   fail:9   skip:1529 
time:10011s

== Logs ==

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

[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/gvt/scheduler.c

between commit:

  fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")

from Linus' tree and commit:

  b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
index 068126404151,a55b4975c154..
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
pdp_pair[i].val = pdp[7 - i];
  }
  
 +/*
 + * when populating shadow ctx from guest, we should not overrride oa related
 + * registers, so that they will not be overlapped by guest oa configs. Thus
 + * made it possible to capture oa data from host for both host and guests.
 + */
 +static void sr_oa_regs(struct intel_vgpu_workload *workload,
 +  u32 *reg_state, bool save)
 +{
 +  struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
 +  u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
 +  u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
 +  int i = 0;
 +  u32 flex_mmio[] = {
 +  i915_mmio_reg_offset(EU_PERF_CNTL0),
 +  i915_mmio_reg_offset(EU_PERF_CNTL1),
 +  i915_mmio_reg_offset(EU_PERF_CNTL2),
 +  i915_mmio_reg_offset(EU_PERF_CNTL3),
 +  i915_mmio_reg_offset(EU_PERF_CNTL4),
 +  i915_mmio_reg_offset(EU_PERF_CNTL5),
 +  i915_mmio_reg_offset(EU_PERF_CNTL6),
 +  };
 +
 +  if (!workload || !reg_state || workload->ring_id != RCS)
 +  return;
 +
 +  if (save) {
 +  workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
 +
 +  for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
 +  u32 state_offset = ctx_flexeu0 + i * 2;
 +
 +  workload->flex_mmio[i] = reg_state[state_offset + 1];
 +  }
 +  } else {
 +  reg_state[ctx_oactxctrl] =
 +  i915_mmio_reg_offset(GEN8_OACTXCONTROL);
 +  reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
 +
 +  for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
 +  u32 state_offset = ctx_flexeu0 + i * 2;
 +  u32 mmio = flex_mmio[i];
 +
 +  reg_state[state_offset] = mmio;
 +  reg_state[state_offset + 1] = workload->flex_mmio[i];
 +  }
 +  }
 +}
 +
+ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
+ {
+   struct intel_vgpu *vgpu = workload->vgpu;
+   int ring_id = workload->ring_id;
+   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
+   struct drm_i915_gem_object *ctx_obj =
+   shadow_ctx->engine[ring_id].state->obj;
+   struct execlist_ring_context *shadow_ring_context;
+   struct page *page;
+ 
+   if (WARN_ON(!workload->shadow_mm))
+   return;
+ 
+   if (WARN_ON(!atomic_read(>shadow_mm->pincount)))
+   return;
+ 
+   page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
+   shadow_ring_context = kmap(page);
+   set_context_pdp_root_pointer(shadow_ring_context,
+   (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
+   kunmap(page);
+ }
+ 
  static int populate_shadow_context(struct intel_vgpu_workload *workload)
  {
struct intel_vgpu *vgpu = workload->vgpu;


pgpZi8hH9Y9zQ.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use full serialisation around 
engine->irq_posted
URL   : https://patchwork.freedesktop.org/series/40406/
State : warning

== Summary ==

 Possible new issues:

Test gem_eio:
Subgroup execbuf:
pass   -> DMESG-WARN (shard-apl)
Subgroup in-flight:
pass   -> DMESG-WARN (shard-apl)
Subgroup in-flight-contexts:
pass   -> DMESG-WARN (shard-apl)
Subgroup in-flight-external:
pass   -> DMESG-WARN (shard-apl)
Subgroup in-flight-internal:
pass   -> DMESG-WARN (shard-apl)
Subgroup throttle:
pass   -> DMESG-WARN (shard-apl)
Subgroup wait:
pass   -> DMESG-WARN (shard-apl)

 Known issues:

Test gem_eio:
Subgroup hibernate:
pass   -> DMESG-WARN (shard-apl) fdo#103927 +1
Subgroup in-flight-suspend:
pass   -> DMESG-WARN (shard-apl) fdo#103375
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking-fencing:
pass   -> FAIL   (shard-apl) fdo#103207
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
incomplete -> PASS   (shard-hsw) fdo#104874
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060

fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#104874 https://bugs.freedesktop.org/show_bug.cgi?id=104874
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060

shard-apltotal:3478 pass:1803 dwarn:11  dfail:0   fail:8   skip:1655 
time:13113s
shard-hswtotal:3478 pass:1766 dwarn:1   dfail:0   fail:3   skip:1707 
time:11816s
shard-snbtotal:3478 pass:1357 dwarn:1   dfail:0   fail:3   skip:2117 
time:7274s
Blacklisted hosts:
shard-kbltotal:3478 pass:1917 dwarn:22  dfail:0   fail:10  skip:1529 
time:9934s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8439/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: Allow control of PSR at runtime through debugfs.

[Pandiyan, Dhinakaran]

On Thu, 2018-03-15 at 11:28 +0100, Maarten Lankhorst wrote:
> Currently tests modify i915.enable_psr and then do a modeset cycle
> to change PSR. We can write a value to i915_edp_psr_status to force
> a certain value without a modeset.
> 
> To retain compatibility with older userspace, we also still allow
> the override through the module parameter, and add some tracking
> to check whether a debugfs mode is specified.
> 

While this is something we want to be able to do, I am concerned about
adding more complexity to a feature that has barely been tested.

How about doing a modeset before frontbuffer_tracking PSR subtests and
one at the end? I'm assuming all of them are grouped together.

Comments on this patch itself.
1) please split intel_psr_default_link_standby() into a separate patch.
2) how does the user know what values to write without looking at the
code?
3) Can the connector and crtc be stored somewhere to avoid loops?
4) Has this been tested on any platforms with PSR?
5) Do subtests need a finer control of PSR i.e., psr_exit() and
psr_activate() instead of enable and disable

> Changes since v1:
> - Rename dev_priv->psr.enabled to .dp, and .hw_configured to .enabled.
> - Fix i915_psr_debugfs_mode to match the writes to debugfs.
> - Rename __i915_edp_psr_write to intel_psr_set_debugfs_mode, simplify
>   it and move it to intel_psr.c. This keeps all internals in intel_psr.c
> - Perform an interruptible wait for hw completion outside of the psr
>   lock, instead of being forced to trywait and return -EBUSY.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  73 +-
>  drivers/gpu/drm/i915/i915_drv.h |  11 +-
>  drivers/gpu/drm/i915/intel_drv.h|   3 +
>  drivers/gpu/drm/i915/intel_psr.c| 262 
> +++-
>  4 files changed, 281 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 574fcf234007..98e169636f86 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2546,16 +2546,13 @@ static const char *psr2_live_status(u32 val)
>  
>  static int i915_edp_psr_status(struct seq_file *m, void *data)
>  {
> - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> + struct drm_i915_private *dev_priv = m->private;
>   u32 psrperf = 0;
>   u32 stat[3];
>   enum pipe pipe;
>   bool enabled = false;
>   bool sink_support;
>  
> - if (!HAS_PSR(dev_priv))
> - return -ENODEV;
> -
>   sink_support = dev_priv->psr.sink_support;
>   seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
>   if (!sink_support)
> @@ -2564,7 +2561,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
> *data)
>   intel_runtime_pm_get(dev_priv);
>  
>   mutex_lock(_priv->psr.lock);
> - seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> + seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
>   seq_printf(m, "Re-enable work scheduled: %s\n",
> @@ -2631,6 +2628,70 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   return 0;
>  }
>  
> +static ssize_t i915_edp_psr_write(struct file *file, const char __user *ubuf,
> +   size_t len, loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct drm_i915_private *dev_priv = m->private;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret, val;
> +
> + if (!dev_priv->psr.sink_support)
> + return -ENODEV;
> +
> + ret = kstrtoint_from_user(ubuf, len, 10, );
> + if (ret < 0) {
> + bool enable;
> + ret = kstrtobool_from_user(ubuf, len, );
> +
> + if (ret < 0)
> + return ret;
> +
> + val = enable;
> + }
> +
> + if (val < -1 || val > 3)
> + return -EINVAL;
> +
> + intel_runtime_pm_get(dev_priv);
> +
> + drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> +
> +retry:
> + ret = intel_psr_set_debugfs_mode(dev_priv, , val);
> + if (ret == -EBUSY) {
> + ret = drm_modeset_backoff();
> + if (!ret)
> + goto retry;
> + }
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + intel_runtime_pm_put(dev_priv);
> +
> + return ret ?: len;
> +}
> +
> +static int i915_edp_psr_open(struct inode *inode, struct file *file)
> +{
> + struct drm_i915_private *dev_priv = inode->i_private;
> +
> + if (!HAS_PSR(dev_priv))
> + return -ENODEV;
> +
> + return single_open(file, i915_edp_psr_status, dev_priv);
> +}
> +
> +static const struct file_operations i915_edp_psr_ops = {
> + .owner 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use full serialisation around engine->irq_posted

[Patchwork]

== Series Details ==

Series: drm/i915: Use full serialisation around engine->irq_posted
URL   : https://patchwork.freedesktop.org/series/40403/
State : success

== Summary ==

 Known issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
incomplete -> PASS   (shard-hsw) fdo#104874
Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#104874 https://bugs.freedesktop.org/show_bug.cgi?id=104874
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3478 pass:1815 dwarn:1   dfail:0   fail:7   skip:1655 
time:13120s
shard-hswtotal:3478 pass:1767 dwarn:1   dfail:0   fail:2   skip:1707 
time:11786s
shard-snbtotal:3478 pass:1357 dwarn:1   dfail:0   fail:3   skip:2117 
time:7257s
Blacklisted hosts:
shard-kbltotal:3454 pass:1924 dwarn:1   dfail:0   fail:8   skip:1520 
time:9735s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: don't dereference 'workload' before null checking it

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: don't dereference 'workload' before null checking it
URL   : https://patchwork.freedesktop.org/series/40401/
State : success

== Summary ==

 Known issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
incomplete -> PASS   (shard-hsw) fdo#104874
Test kms_flip:
Subgroup 2x-wf_vblank-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368

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

shard-apltotal:3478 pass:1814 dwarn:1   dfail:0   fail:7   skip:1655 
time:13121s
shard-hswtotal:3478 pass:1767 dwarn:1   dfail:0   fail:2   skip:1707 
time:11881s
shard-snbtotal:3478 pass:1357 dwarn:1   dfail:0   fail:3   skip:2117 
time:7269s
Blacklisted hosts:
shard-kbltotal:3478 pass:1898 dwarn:40  dfail:0   fail:10  skip:1530 
time:9934s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8437/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 drm/i915/selftests: Stress resets-vs-request-priority

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Stress resets-vs-request-priority
URL   : https://patchwork.freedesktop.org/series/40397/
State : failure

== Summary ==

 Possible new issues:

Test drv_selftest:
Subgroup live_hangcheck:
pass   -> DMESG-FAIL (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
pass   -> FAIL   (shard-apl)

 Known issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> FAIL   (shard-apl) fdo#103232
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
incomplete -> PASS   (shard-hsw) fdo#104874
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887

fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#104874 https://bugs.freedesktop.org/show_bug.cgi?id=104874
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887

shard-apltotal:3478 pass:1811 dwarn:1   dfail:1   fail:9   skip:1655 
time:12997s
shard-hswtotal:3478 pass:1767 dwarn:1   dfail:0   fail:2   skip:1707 
time:11893s
shard-snbtotal:3478 pass:1357 dwarn:1   dfail:0   fail:3   skip:2117 
time:7303s
Blacklisted hosts:
shard-kbltotal:3460 pass:1908 dwarn:11  dfail:0   fail:10  skip:1530 
time:9737s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 21:29 +0200, Ville Syrjälä wrote:
> On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > > From: Daniel Vetter 
> > > > 
> > > > The definitions for the error register should be valid on bdw/skl too,
> > > > but there we haven't even enabled DE_MISC handling yet.
> > > > 
> > > > Somewhat confusing the the moved register offset on bdw is only for
> > > > the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> > > > on bdw.
> > > > 
> > > > v2: Fixes from Ville.
> > > > 
> > > > v3: From DK
> > > >  * Rebased on drm-tip
> > > >  * Removed BDW IIR bit definition, looks like an unintentional change 
> > > > that
> > > > should be in the following patch.
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Daniel Vetter 
> > > > Signed-off-by: Daniel Vetter 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_irq.c  | 34 
> > > > ++
> > > >  drivers/gpu/drm/i915/i915_reg.h  |  8 
> > > >  drivers/gpu/drm/i915/intel_psr.c |  3 ++-
> > > >  3 files changed, 44 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 44eef355e12c..e94a835b7515 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct 
> > > > drm_i915_private *dev_priv,
> > > > ironlake_rps_change_irq_handler(dev_priv);
> > > >  }
> > > >  
> > > > +static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > > > +{
> > > > +   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > > > +
> > > > +   if (edp_psr_iir & EDP_PSR_ERROR)
> > > > +   DRM_DEBUG_KMS("PSR error\n");
> > > > +
> > > > +   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > > > +   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > > 
> > > I doubt we want to have the entry/exit interrupts generate all this
> > > noise in dmesg all the time. We should probably only enable the
> > > interrupts for testing. The error interrupt I suppose we want always,
> > > might even want DRM_ERROR on it.
> > 
> > I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.
> 
> Right. It's a bit hard to read this with stuff getting
> added/remove/moved more or less randomly.
> 
> > 
> > > 
> > > > +   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > > > +   }
> > > > +
> > > > +   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > > > +   DRM_DEBUG_KMS("PSR exit completed\n");
> > > > +   I915_WRITE(EDP_PSR_IMR, 0);
> > > > +   }
> > > > +
> > > > +   I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > > > +}
> > > > +
> > > >  static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
> > > > u32 de_iir)
> > > >  {
> > > > @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct 
> > > > drm_i915_private *dev_priv,
> > > > if (de_iir & DE_ERR_INT_IVB)
> > > > ivb_err_int_handler(dev_priv);
> > > >  
> > > > +   if (de_iir & DE_EDP_PSR_INT_HSW)
> > > > +   hsw_edp_psr_irq_handler(dev_priv);
> > > > +
> > > > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > > > dp_aux_irq_handler(dev_priv);
> > > >  
> > > > @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct drm_device 
> > > > *dev)
> > > > if (IS_GEN7(dev_priv))
> > > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > >  
> > > > +   if (IS_HASWELL(dev_priv)) {
> > > > +   I915_WRITE(EDP_PSR_IMR, 0x);
> > > > +   I915_WRITE(EDP_PSR_IIR, 0x);
> > > > +   }
> > > > +
> > > > gen5_gt_irq_reset(dev_priv);
> > > >  
> > > > ibx_irq_reset(dev_priv);
> > > > @@ -3663,6 +3691,12 @@ static int ironlake_irq_postinstall(struct 
> > > > drm_device *dev)
> > > >   DE_DP_A_HOTPLUG);
> > > > }
> > > >  
> > > > +   if (IS_HASWELL(dev_priv)) {
> > > > +   gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> > > > +   I915_WRITE(EDP_PSR_IMR, 0);
> > > > +   display_mask |= DE_EDP_PSR_INT_HSW;
> > > > +   }
> > > > +
> > > > dev_priv->irq_mask = ~display_mask;
> > > >  
> > > > ibx_irq_pre_postinstall(dev);
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 1e000f3004cb..3447f03eac3d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ 

Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 21:48 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote:
> > Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
> > PSR entry.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 12 
> >  drivers/gpu/drm/i915/i915_drv.h |  3 +++
> >  drivers/gpu/drm/i915/intel_psr.c| 21 +++--
> >  3 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 669f3d56054a..d28dc4d8388e 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2686,6 +2686,18 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > }
> > mutex_unlock(_priv->psr.lock);
> >  
> > +   if (READ_ONCE(dev_priv->psr.debug)) {
> > +   unsigned int seq;
> > +
> > +   do {
> > +   seq = read_seqbegin(_priv->psr.debug_lock);
> > +   seq_printf(m, "Last attempted entry at: %lld\n",
> > +  dev_priv->psr.last_entry_attempt);
> > +   seq_printf(m, "Last exit at: %lld\n",
> > +  dev_priv->psr.last_exit);
> > +   } while (read_seqretry(_priv->psr.debug_lock, seq));
> 
> What does the seqlock buy us?

Reading debugfs wouldn't block the update inside the irq handler,
compared to using a spinlock. We need to serialize the read and update
parts, don't we? Otherwise tests might end up reading partial updates.

> 
> > +   }
> > +
> > intel_runtime_pm_put(dev_priv);
> > return 0;
> >  }
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 136fa2267a66..b8170882e1ab 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -609,6 +609,9 @@ struct i915_psr {
> > bool alpm;
> > bool has_hw_tracking;
> > bool debug;
> > +   ktime_t last_entry_attempt;
> > +   ktime_t last_exit;
> > +   seqlock_t debug_lock;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 64ecea80438d..a83d95b1b587 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct drm_i915_private 
> > *dev_priv, u32 psr_iir)
> >  {
> > u32 transcoders = BIT(TRANSCODER_EDP);
> > enum transcoder cpu_transcoder;
> > +   ktime_t time_ns =  ktime_get();
> > +   unsigned long flags = 0;
> >  
> > if (INTEL_GEN(dev_priv) >= 8)
> > transcoders |= BIT(TRANSCODER_A) |
> >BIT(TRANSCODER_B) |
> >BIT(TRANSCODER_C);
> >  
> > +   write_seqlock_irqsave(_priv->psr.debug_lock, flags);
> > for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
> > +   bool handled = false;
> > +
> > +   /* PSR supported only on one transcoder currently */
> > +   WARN_ON_ONCE(handled);
> > +
> > /* FIXME: Exit PSR when this happens. */
> > -   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > +   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> > +   handled = true;
> > DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
> >   transcoder_name(cpu_transcoder));
> >  
> > +   }
> > +
> > if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("[transcoder %s] PSR entry in 2 
> > vblanks\n",
> > +   handled = true;
> > +   dev_priv->psr.last_entry_attempt = time_ns;
> > +   DRM_DEBUG_KMS("[transcoder %s] PSR entry attempt in 2 
> > vblanks\n",
> >   transcoder_name(cpu_transcoder));
> > }
> >  
> > if (psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> > +   handled = true;
> > +   dev_priv->psr.last_exit = time_ns;
> > DRM_DEBUG_KMS("[transcoder %s] PSR exit completed\n",
> >   transcoder_name(cpu_transcoder));
> > }
> > }
> > +   write_sequnlock_irqrestore(_priv->psr.debug_lock, flags);
> >  }
> >  
> >  static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> > @@ -1160,6 +1176,7 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> >  
> > INIT_DELAYED_WORK(_priv->psr.work, intel_psr_work);
> > mutex_init(_priv->psr.lock);
> > +   

Re: [Intel-gfx] [PATCH 4/5] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 21:45 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:50PM -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 68 
> > -
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 56 ++
> >  5 files changed, 123 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 964ea1a12357..669f3d56054a 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   if (val < 0  || val > 1)
> > +   return -EINVAL;
> > +
> > +   DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : "Disabling");
> > +   intel_psr_debug_control(dev_priv, val);
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> > +i915_edp_psr_debug_get(void *data, u64 *val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   *val = READ_ONCE(dev_priv->psr.debug);
> > +   return 0;
> > +}
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> > +   i915_edp_psr_debug_get, i915_edp_psr_debug_set,
> > +   "%llu\n");
> > +
> >  static int i915_sink_crc(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -4811,7 +4844,8 @@ static const struct i915_debugfs_files {
> > {"i915_guc_log_relay", _guc_log_relay_fops},
> > {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
> > {"i915_ipc_status", _ipc_status_fops},
> > -   {"i915_drrs_ctl", _drrs_ctl_fops}
> > +   {"i915_drrs_ctl", _drrs_ctl_fops},
> > +   {"i915_edp_psr_debug", _edp_psr_debug_fops}
> >  };
> >  
> >  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e27ba8fb64e6..136fa2267a66 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -608,6 +608,7 @@ struct i915_psr {
> > bool colorimetry_support;
> > bool alpm;
> > bool has_hw_tracking;
> > +   bool debug;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 56228e8ed980..94941b52f1cf 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2392,40 +2392,6 @@ static void ilk_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > -static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > -{
> > -   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > -   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> > -   u32 mask = BIT(TRANSCODER_EDP);
> > -   enum transcoder cpu_transcoder;
> > -
> > -   if (INTEL_GEN(dev_priv) >= 8)
> > -   mask |= BIT(TRANSCODER_A) |
> > -   BIT(TRANSCODER_B) |
> > -   BIT(TRANSCODER_C);
> > -
> > -   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
> > -   if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > -   DRM_DEBUG_KMS("Transcoder %s PSR error\n",
> > - transcoder_name(cpu_transcoder));
> > -
> > -   if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2 
> > vblanks\n",
> > - transcoder_name(cpu_transcoder));
> > -   edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
> > -   }
> > -
> > -   if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("Transcoder %s PSR exit completed\n",
> > - transcoder_name(cpu_transcoder));
> > -   edp_psr_imr &= 

[Intel-gfx] ✓ Fi.CI.BAT: success for cgroup private data and DRM/i915 integration (rev3)

[Patchwork]

== Series Details ==

Series: cgroup private data and DRM/i915 integration (rev3)
URL   : https://patchwork.freedesktop.org/series/40142/
State : success

== Summary ==

Series 40142v3 cgroup private data and DRM/i915 integration
https://patchwork.freedesktop.org/api/1.0/series/40142/revisions/3/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (fi-skl-6770hq) fdo#100368
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:243  pass:216  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:514s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:505s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:511s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:548s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:314s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:408s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:656s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:426s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:589s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:404s

dff9ece60048108782aab6d6123822c1d34b0e5a drm-tip: 2018y-03m-21d-20h-44m-14s UTC 
integration manifest
5b1782be5720 drm/i915: Add context priority & priority offset to debugfs (v2)
5909f05aaca5 drm/i915: Introduce per-cgroup display boost setting
44858a8e8b6f drm/i915: Introduce 'priority offset' for GPU contexts (v4)
8e4b9162691c drm/i915: cgroup integration (v4)
f8a545376030 drm/i915: Adjust internal priority definitions (v2)
b6569483024f cgroup: Introduce cgroup_priv_get_current
95f12a7ecd5d cgroup: Introduce task_get_dfl_cgroup() (v2)
8c23fa59eef7 cgroup: Allow registration and lookup of cgroup private data (v3)

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for cgroup private data and DRM/i915 integration (rev3)

[Patchwork]

== Series Details ==

Series: cgroup private data and DRM/i915 integration (rev3)
URL   : https://patchwork.freedesktop.org/series/40142/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8c23fa59eef7 cgroup: Allow registration and lookup of cgroup private data (v3)
95f12a7ecd5d cgroup: Introduce task_get_dfl_cgroup() (v2)
b6569483024f cgroup: Introduce cgroup_priv_get_current
f8a545376030 drm/i915: Adjust internal priority definitions (v2)
8e4b9162691c drm/i915: cgroup integration (v4)
-:36: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#36: 
new file mode 100644

-:280: WARNING:LONG_LINE: line over 100 characters
#280: FILE: include/uapi/drm/i915_drm.h:381:
+#define DRM_IOCTL_I915_CGROUP_SETPARAM DRM_IOW(DRM_COMMAND_BASE + 
DRM_I915_CGROUP_SETPARAM, struct drm_i915_cgroup_param)

total: 0 errors, 2 warnings, 0 checks, 247 lines checked
44858a8e8b6f drm/i915: Introduce 'priority offset' for GPU contexts (v4)
-:125: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'def' - possible 
side-effects?
#125: FILE: drivers/gpu/drm/i915/i915_cgroup.c:173:
+#define CGROUP_GET(name, field, def) \
+int i915_cgroup_get_current_##name(struct drm_i915_private *dev_priv)  \
+{  \
+   struct kref *ref;   \
+   int val = def;  \
+   if (!dev_priv->cgroup_priv_key) \
+   return def; \
+   ref = cgroup_priv_get_current(dev_priv->cgroup_priv_key);   \
+   if (ref) {  \
+   val = cgrp_ref_to_i915(ref)->field; \
+   kref_put(ref, i915_cgroup_free);\
+   }   \
+   return val; \
+}

total: 0 errors, 0 warnings, 1 checks, 164 lines checked
5909f05aaca5 drm/i915: Introduce per-cgroup display boost setting
-:83: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#83: FILE: drivers/gpu/drm/i915/i915_drv.h:2719:
 }
+static inline int

total: 0 errors, 0 warnings, 1 checks, 89 lines checked
5b1782be5720 drm/i915: Add context priority & priority offset to debugfs (v2)

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

[Intel-gfx] [PATCH v4.5 8/8] drm/i915: Add context priority & priority offset to debugfs (v2)

[Matt Roper]

Update i915_context_status to include priority information.

v2:
 - Clarify that the offset is based on cgroup (Chris)

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7816cd53100a..ac2dad38dee1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1959,6 +1959,9 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
seq_putc(m, '\n');
 
+   seq_printf(m, "Priority %d (cgroup offset = %d)\n",
+  ctx->priority, ctx->priority_offset);
+
for_each_engine(engine, dev_priv, id) {
struct intel_context *ce = >engine[engine->id];
 
-- 
2.14.3

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

[Intel-gfx] [PATCH v4.5 4/8] drm/i915: Adjust internal priority definitions (v2)

[Matt Roper]

In preparation for adding cgroup-based priority adjustments, let's
define the driver's priority values a little more clearly.

v2:
 - checkpatch warning fix (Intel CI)

Cc: Chris Wilson 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem_context.c |  5 +++--
 drivers/gpu/drm/i915/i915_request.h | 13 ++---
 drivers/gpu/drm/i915/intel_display.c|  2 +-
 4 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9c3b2ba6a86..2d7a89fcc0dc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3150,7 +3150,6 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
  unsigned int flags,
  int priority);
-#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
 
 int __must_check
 i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac0255758..4bae1be52294 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -474,7 +474,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
ida_init(_priv->contexts.hw_ida);
 
/* lowest priority; idle task */
-   ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_MIN);
+   ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_IDLE);
if (IS_ERR(ctx)) {
DRM_ERROR("Failed to create default global context\n");
return PTR_ERR(ctx);
@@ -488,7 +488,8 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
 
/* highest priority; preempting task */
if (needs_preempt_context(dev_priv)) {
-   ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX);
+   ctx = i915_gem_context_create_kernel(dev_priv,
+I915_PRIORITY_PREEMPT);
if (!IS_ERR(ctx))
dev_priv->preempt_context = ctx;
else
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 7d6eb82eeb91..72b13fc2b72b 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -78,12 +78,19 @@ struct i915_priotree {
int priority;
 };
 
+/*
+ * Userspace can only assign priority values of [-1023,1023] via context param,
+ * but the effective priority value can fall in a larger range once we add in
+ * a cgroup-provided offset.
+ */
 enum {
-   I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1,
I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY,
-   I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1,
+   I915_PRIORITY_DEFAULT_DISPBOOST = I915_CONTEXT_MAX_USER_PRIORITY + 1,
 
-   I915_PRIORITY_INVALID = INT_MIN
+   /* Special case priority values */
+   I915_PRIORITY_INVALID = INT_MIN,
+   I915_PRIORITY_IDLE = INT_MIN + 1,
+   I915_PRIORITY_PREEMPT = INT_MAX,
 };
 
 struct i915_capture_list {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3e7ab75e1b41..b053a21f682b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12783,7 +12783,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
 
ret = intel_plane_pin_fb(to_intel_plane_state(new_state));
 
-   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
+   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DEFAULT_DISPBOOST);
 
mutex_unlock(_priv->drm.struct_mutex);
i915_gem_object_unpin_pages(obj);
-- 
2.14.3

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

[Intel-gfx] [PATCH v4.5 7/8] drm/i915: Introduce per-cgroup display boost setting

[Matt Roper]

Usually display-boosted contexts get treated as
I915_CONTEXT_MAX_USER_PRIORITY+1, which prioritizes them above regular
GPU contexts.  Now that we allow a much larger range of effective
priority values via per-cgroup priority offsets, a system administrator
may want more detailed control over how much a process should be boosted
by display operations (i.e., can a context from a cgroup with a low
priority offset still be display boosted above contexts from a cgroup
with a much higher priority offset?  or are come cgroups more important
than maintaining display rate?).

Cc: Chris Wilson 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_cgroup.c   | 17 +
 drivers/gpu/drm/i915/i915_drv.h  |  6 ++
 drivers/gpu/drm/i915/i915_request.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  5 +++--
 include/uapi/drm/i915_drm.h  |  1 +
 5 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cgroup.c 
b/drivers/gpu/drm/i915/i915_cgroup.c
index 0921d624f840..2bef8a5cac93 100644
--- a/drivers/gpu/drm/i915/i915_cgroup.c
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -11,6 +11,7 @@
 
 struct i915_cgroup_data {
int priority_offset;
+   int display_boost;
 
struct kref ref;
 };
@@ -75,6 +76,8 @@ get_or_create_cgroup_data(struct drm_i915_private *dev_priv,
goto out;
}
 
+   priv->display_boost = I915_PRIORITY_DEFAULT_DISPBOOST;
+
kref_init(>ref);
cgroup_priv_install(cgrp, dev_priv->cgroup_priv_key,
>ref);
@@ -151,6 +154,19 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev,
}
break;
 
+   case I915_CGROUP_PARAM_DISPBOOST_PRIORITY:
+   if (req->value < I915_PRIORITY_MAX_DISPBOOST &&
+   req->value > I915_PRIORITY_MIN) {
+   DRM_DEBUG_DRIVER("Setting cgroup display boost priority 
to %lld\n",
+req->value);
+   cgrpdata->display_boost = req->value;
+   } else {
+   DRM_DEBUG_DRIVER("Invalid cgroup display boost priority 
%lld\n",
+req->value);
+   ret = -EINVAL;
+   }
+   break;
+
default:
DRM_DEBUG_DRIVER("Invalid cgroup parameter %lld\n", req->param);
ret = -EINVAL;
@@ -186,5 +202,6 @@ int i915_cgroup_get_current_##name(struct drm_i915_private 
*dev_priv)   \
 }
 
 CGROUP_GET(prio_offset, priority_offset, 0)
+CGROUP_GET(dispboost, display_boost, I915_PRIORITY_DEFAULT_DISPBOOST);
 
 #undef CGROUP_GET
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72e6cd7bfbae..bde58327b892 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2694,6 +2694,7 @@ int i915_cgroup_setparam_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file);
 void i915_cgroup_shutdown(struct drm_i915_private *dev_priv);
 int i915_cgroup_get_current_prio_offset(struct drm_i915_private *dev_priv);
+int i915_cgroup_get_current_dispboost(struct drm_i915_private *dev_priv);
 #else
 static inline int
 i915_cgroup_init(struct drm_i915_private *dev_priv)
@@ -2715,6 +2716,11 @@ i915_cgroup_get_current_prio_offset(struct 
drm_i915_private *dev_priv)
 {
return 0;
 }
+static inline int
+i915_cgroup_get_current_dispboost(struct drm_i915_private *dev_priv)
+{
+   return I915_PRIORITY_DEFAULT_DISPBOOST;
+}
 #endif
 
 /* i915_drv.c */
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index cf7a7147daf3..db300d93fd08 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -90,6 +90,7 @@ enum {
/* Range reachable by combining user priority + cgroup offset */
I915_PRIORITY_MAX = 0x7f,
I915_PRIORITY_MIN = -I915_PRIORITY_MAX,
+   I915_PRIORITY_MAX_DISPBOOST = I915_PRIORITY_MAX + 1,
 
/* Special case priority values */
I915_PRIORITY_INVALID = INT_MIN,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b053a21f682b..1d0245e2fd75 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12731,7 +12731,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
struct drm_framebuffer *fb = new_state->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
-   int ret;
+   int boost, ret;
 
if (old_obj) {
struct drm_crtc_state *crtc_state =
@@ -12783,7 +12783,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
 
ret = intel_plane_pin_fb(to_intel_plane_state(new_state));
 
-  

[Intel-gfx] [PATCH v4.5 1/8] cgroup: Allow registration and lookup of cgroup private data (v3)

[Matt Roper]

There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller.  Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.

A kernel system (e.g., a driver) that wishes to register private data
for a cgroup should start by obtaining a unique private data key by
calling cgroup_priv_getkey().  It may then associate private data
with a cgroup by calling cgroup_priv_install(cgrp, key, ref) where 'ref'
is a pointer to a kref field inside the private data structure.  The
private data may later be looked up by calling cgroup_priv_get(cgrp,
key) to obtain a new reference to the private data.  Private data may be
unregistered via cgroup_priv_release(cgrp, key).

If a cgroup is removed, the reference count for all private data objects
will be decremented.

v2:  Significant overhaul suggested by Tejun, Alexei, and Roman
 - Rework interface to make consumers obtain an ida-based key rather
   than supplying their own arbitrary void*
 - Internal implementation now uses per-cgroup radixtrees which should
   allow much faster lookup than the previous hashtable approach
 - Private data is registered via kref, allowing a single private data
   structure to potentially be assigned to multiple cgroups.

v3:
 - Spare warning fixes (kbuild test robot)

Cc: Tejun Heo 
Cc: Alexei Starovoitov 
Cc: Roman Gushchin 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 

fixup! cgroup: Allow registration and lookup of cgroup private data (v2)
---
 include/linux/cgroup-defs.h |  10 +++
 include/linux/cgroup.h  |   7 ++
 kernel/cgroup/cgroup.c  | 183 +++-
 3 files changed, 198 insertions(+), 2 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 9f242b876fde..9086d963cc0a 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -427,6 +427,16 @@ struct cgroup {
/* used to store eBPF programs */
struct cgroup_bpf bpf;
 
+   /*
+* cgroup private data registered by other non-controller parts of the
+* kernel.  Insertions are protected by privdata_lock, lookups by
+* rcu_read_lock().
+*/
+   struct radix_tree_root privdata;
+
+   /* Protect against concurrent insertions/deletions to privdata */
+   spinlock_t privdata_lock;
+
/* ids of the ancestors at each level including self */
int ancestor_ids[];
 };
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 473e0c0abb86..63d22dfa00bd 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -833,4 +833,11 @@ static inline void put_cgroup_ns(struct cgroup_namespace 
*ns)
free_cgroup_ns(ns);
 }
 
+/* cgroup private data handling */
+int cgroup_priv_getkey(void (*free)(struct kref *));
+void cgroup_priv_destroykey(int key);
+int cgroup_priv_install(struct cgroup *cgrp, int key, struct kref *ref);
+struct kref *cgroup_priv_get(struct cgroup *cgrp, int key);
+void cgroup_priv_release(struct cgroup *cgrp, int key);
+
 #endif /* _LINUX_CGROUP_H */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 8cda3bc3ae22..3268a21e8158 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -81,8 +81,15 @@ EXPORT_SYMBOL_GPL(css_set_lock);
 #endif
 
 /*
- * Protects cgroup_idr and css_idr so that IDs can be released without
- * grabbing cgroup_mutex.
+ * ID allocator for cgroup private data keys; the ID's allocated here will
+ * be used to index all per-cgroup radix trees.  The radix tree built into
+ * the IDR itself will store a key-specific function to be passed to kref_put.
+ */
+static DEFINE_IDR(cgroup_priv_idr);
+
+/*
+ * Protects cgroup_idr, css_idr, and cgroup_priv_idr so that IDs can be
+ * released without grabbing cgroup_mutex.
  */
 static DEFINE_SPINLOCK(cgroup_idr_lock);
 
@@ -1839,6 +1846,8 @@ static void init_cgroup_housekeeping(struct cgroup *cgrp)
INIT_LIST_HEAD(>cset_links);
INIT_LIST_HEAD(>pidlists);
mutex_init(>pidlist_mutex);
+   INIT_RADIX_TREE(>privdata, GFP_NOWAIT);
+   spin_lock_init(>privdata_lock);
cgrp->self.cgroup = cgrp;
cgrp->self.flags |= CSS_ONLINE;
cgrp->dom_cgrp = cgrp;
@@ -4578,6 +4587,8 @@ static void css_release_work_fn(struct work_struct *work)
container_of(work, struct cgroup_subsys_state, destroy_work);
struct cgroup_subsys *ss = css->ss;
struct cgroup *cgrp = css->cgroup;
+   struct radix_tree_iter iter;
+   void __rcu **slot;
 
mutex_lock(_mutex);
 
@@ -4617,6 +4628,12 @@ static void css_release_work_fn(struct work_struct *work)
 NULL);
 
cgroup_bpf_put(cgrp);
+
+   /* Drop reference on any private data */
+   rcu_read_lock();
+  

[Intel-gfx] [PATCH v4.5 6/8] drm/i915: Introduce 'priority offset' for GPU contexts (v4)

[Matt Roper]

There are cases where a system integrator may wish to raise/lower the
priority of GPU workloads being submitted by specific OS process(es),
independently of how the software self-classifies its own priority.
Exposing "priority offset" as an i915-specific cgroup parameter will
enable such system-level configuration.

Normally GPU contexts start with a priority value of 0
(I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from
there via other mechanisms.  We'd like to provide a system-level input
to the priority decision that will be taken into consideration, even
when userspace later attempts to set an absolute priority value via
I915_CONTEXT_PARAM_PRIORITY.  The priority offset introduced here
provides a base value that will always be added to (or subtracted from)
the software's self-assigned priority value.

This patch makes priority offset a cgroup-specific value; contexts will
be created with a priority offset based on the cgroup membership of the
process creating the context at the time the context is created.  Note
that priority offset is assigned at context creation time; migrating a
process to a different cgroup or changing the offset associated with a
cgroup will only affect new context creation and will not alter the
behavior of existing contexts previously created by the process.

v2:
 - Rebase onto new cgroup_priv API
 - Use current instead of drm_file->pid to determine which process to
   lookup priority for. (Chris)
 - Don't forget to subtract priority offset in context_getparam ioctl to
   make it match setparam behavior. (Chris)

v3:
 - Rebase again onto new idr/kref-based cgroup_priv API
 - Bound priority offset such that effective priority from settings
   on context + cgroup fall within [-0x7f, 0x7f]. (Chris)

v4:
 - checkpatch warning fixes (Intel CI)

Cc: Chris Wilson 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_cgroup.c  | 54 +++--
 drivers/gpu/drm/i915/i915_drv.h |  7 +
 drivers/gpu/drm/i915/i915_gem_context.c |  7 +++--
 drivers/gpu/drm/i915/i915_gem_context.h |  9 ++
 drivers/gpu/drm/i915/i915_request.h |  4 +++
 include/uapi/drm/i915_drm.h |  1 +
 6 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cgroup.c 
b/drivers/gpu/drm/i915/i915_cgroup.c
index efe76c2a8915..0921d624f840 100644
--- a/drivers/gpu/drm/i915/i915_cgroup.c
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -10,6 +10,8 @@
 #include "i915_drv.h"
 
 struct i915_cgroup_data {
+   int priority_offset;
+
struct kref ref;
 };
 
@@ -54,7 +56,6 @@ i915_cgroup_shutdown(struct drm_i915_private *dev_priv)
  * Return i915 cgroup private data, creating and registering it if one doesn't
  * already exist for this cgroup.
  */
-__maybe_unused
 static struct i915_cgroup_data *
 get_or_create_cgroup_data(struct drm_i915_private *dev_priv,
  struct cgroup *cgrp)
@@ -98,9 +99,11 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev,
   void *data,
   struct drm_file *file)
 {
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_cgroup_param *req = data;
struct cgroup *cgrp;
-   int ret;
+   struct i915_cgroup_data *cgrpdata;
+   int top, bot, ret = 0;
 
/* We don't actually support any flags yet. */
if (req->flags) {
@@ -127,14 +130,61 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev,
goto out;
}
 
+   cgrpdata = get_or_create_cgroup_data(dev_priv, cgrp);
+   if (IS_ERR(cgrpdata)) {
+   ret = PTR_ERR(cgrpdata);
+   goto out;
+   }
+
switch (req->param) {
+   case I915_CGROUP_PARAM_PRIORITY_OFFSET:
+   top = req->value + I915_CONTEXT_MAX_USER_PRIORITY;
+   bot = req->value - I915_CONTEXT_MIN_USER_PRIORITY;
+   if (top <= I915_PRIORITY_MAX && bot >= I915_PRIORITY_MIN) {
+   DRM_DEBUG_DRIVER("Setting cgroup priority offset to 
%lld\n",
+req->value);
+   cgrpdata->priority_offset = req->value;
+   } else {
+   DRM_DEBUG_DRIVER("Invalid cgroup priority offset 
%lld\n",
+req->value);
+   ret = -EINVAL;
+   }
+   break;
+
default:
DRM_DEBUG_DRIVER("Invalid cgroup parameter %lld\n", req->param);
ret = -EINVAL;
}
 
+   kref_put(>ref, i915_cgroup_free);
+
 out:
cgroup_put(cgrp);
 
return ret;
 }
+
+/*
+ * Generator for simple getter functions that look up a cgroup private data
+ * field for the current task's cgroup.  It's safe to call these before
+ * a cgroup private data key has been registered; they'll just return the
+ * default value in that 

[Intel-gfx] [PATCH v4.5 5/8] drm/i915: cgroup integration (v4)

[Matt Roper]

Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow
userspace to set i915-specific parameters for individual cgroups.  i915
cgroup data will be registered and later looked up via the new
cgroup_priv infrastructure.

v2:
 - Large rebase/rewrite for new cgroup_priv interface
v3:
 - Another rebase/rewrite for ida-based keys and kref-based storage
 - Access control no longer follows cgroup filesystem permissions;
   instead we restrict access to either DRM master or
   capable(CAP_SYS_RESOURCE).
v4:
 - Fix checkpatch warnings (Intel CI)

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_cgroup.c | 140 +
 drivers/gpu/drm/i915/i915_drv.c|   8 +++
 drivers/gpu/drm/i915/i915_drv.h|  32 +
 include/uapi/drm/i915_drm.h|  12 
 5 files changed, 193 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 552e43e9663f..26031185cf0e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -48,6 +48,7 @@ i915-y := i915_drv.o \
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
 i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
+i915-$(CONFIG_CGROUPS) += i915_cgroup.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_cgroup.c 
b/drivers/gpu/drm/i915/i915_cgroup.c
new file mode 100644
index ..efe76c2a8915
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -0,0 +1,140 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * i915_cgroup.c - Linux cgroups integration for i915
+ *
+ * Copyright (C) 2018 Intel Corporation
+ */
+
+#include 
+
+#include "i915_drv.h"
+
+struct i915_cgroup_data {
+   struct kref ref;
+};
+
+static inline struct i915_cgroup_data *
+cgrp_ref_to_i915(struct kref *ref)
+{
+   return container_of(ref, struct i915_cgroup_data, ref);
+}
+
+static void
+i915_cgroup_free(struct kref *ref)
+{
+   struct i915_cgroup_data *priv;
+
+   priv = cgrp_ref_to_i915(ref);
+   kfree(priv);
+}
+
+int
+i915_cgroup_init(struct drm_i915_private *dev_priv)
+{
+   int ret = 0;
+
+   dev_priv->cgroup_priv_key = cgroup_priv_getkey(i915_cgroup_free);
+   if (dev_priv->cgroup_priv_key < 0) {
+   DRM_DEBUG_DRIVER("Failed to get a cgroup private data key\n");
+   ret = dev_priv->cgroup_priv_key;
+   }
+
+   mutex_init(_priv->cgroup_lock);
+
+   return ret;
+}
+
+void
+i915_cgroup_shutdown(struct drm_i915_private *dev_priv)
+{
+   cgroup_priv_destroykey(dev_priv->cgroup_priv_key);
+}
+
+/*
+ * Return i915 cgroup private data, creating and registering it if one doesn't
+ * already exist for this cgroup.
+ */
+__maybe_unused
+static struct i915_cgroup_data *
+get_or_create_cgroup_data(struct drm_i915_private *dev_priv,
+ struct cgroup *cgrp)
+{
+   struct kref *ref;
+   struct i915_cgroup_data *priv;
+
+   mutex_lock(_priv->cgroup_lock);
+
+   ref = cgroup_priv_get(cgrp, dev_priv->cgroup_priv_key);
+   if (ref) {
+   priv = cgrp_ref_to_i915(ref);
+   } else {
+   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+   if (!priv) {
+   priv = ERR_PTR(-ENOMEM);
+   goto out;
+   }
+
+   kref_init(>ref);
+   cgroup_priv_install(cgrp, dev_priv->cgroup_priv_key,
+   >ref);
+   }
+
+out:
+   mutex_unlock(_priv->cgroup_lock);
+
+   return priv;
+}
+
+/**
+ * i915_cgroup_setparam_ioctl - ioctl to alter i915 settings for a cgroup
+ * @dev: DRM device
+ * @data: data pointer for the ioctl
+ * @file_priv: DRM file handle for the ioctl call
+ *
+ * Allows i915-specific parameters to be set for a Linux cgroup.
+ */
+int
+i915_cgroup_setparam_ioctl(struct drm_device *dev,
+  void *data,
+  struct drm_file *file)
+{
+   struct drm_i915_cgroup_param *req = data;
+   struct cgroup *cgrp;
+   int ret;
+
+   /* We don't actually support any flags yet. */
+   if (req->flags) {
+   DRM_DEBUG_DRIVER("Invalid flags\n");
+   return -EINVAL;
+   }
+
+   /*
+* Make sure the file descriptor really is a cgroup fd and is on the
+* v2 hierarchy.
+*/
+   cgrp = cgroup_get_from_fd(req->cgroup_fd);
+   if (IS_ERR(cgrp)) {
+   DRM_DEBUG_DRIVER("Invalid cgroup file descriptor\n");
+   return PTR_ERR(cgrp);
+   }
+
+   /*
+* Access control:  For now we grant access via CAP_SYS_RESOURCE _or_
+* DRM master status.
+*/
+   if (!capable(CAP_SYS_RESOURCE) && !drm_is_current_master(file)) {
+   DRM_DEBUG_DRIVER("Insufficient permissions to adjust i915 

[Intel-gfx] [PATCH v4.5 3/8] cgroup: Introduce cgroup_priv_get_current

[Matt Roper]

Getting cgroup private data for the current process' cgroup is such a
common pattern that we should add a convenience wrapper for it.

Signed-off-by: Matt Roper 
---
 include/linux/cgroup.h |  1 +
 kernel/cgroup/cgroup.c | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 74b435f913c1..64d3dc45efd0 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -867,6 +867,7 @@ int cgroup_priv_getkey(void (*free)(struct kref *));
 void cgroup_priv_destroykey(int key);
 int cgroup_priv_install(struct cgroup *cgrp, int key, struct kref *ref);
 struct kref *cgroup_priv_get(struct cgroup *cgrp, int key);
+struct kref *cgroup_priv_get_current(int key);
 void cgroup_priv_release(struct cgroup *cgrp, int key);
 
 #endif /* _LINUX_CGROUP_H */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 3268a21e8158..f1637d9c83d5 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -6079,6 +6079,29 @@ cgroup_priv_get(struct cgroup *cgrp, int key)
 }
 EXPORT_SYMBOL_GPL(cgroup_priv_get);
 
+/**
+ * cgroup_priv_get_current - looks up cgroup private data for current task
+ * @key: key uniquely identifying owner of private data to lookup
+ *
+ * Convenience function that performs cgroup_priv_get() on the cgroup that owns
+ * %current.
+ *
+ * Returns:
+ * A pointer to the private data's kref field, or NULL if no private data has
+ * been registered.
+ */
+struct kref *
+cgroup_priv_get_current(int key)
+{
+   struct cgroup *cgrp = task_get_dfl_cgroup(current);
+   struct kref *ref = cgroup_priv_get(cgrp, key);
+
+   cgroup_put(cgrp);
+
+   return ref;
+}
+EXPORT_SYMBOL_GPL(cgroup_priv_get_current);
+
 /**
  * cgroup_priv_free - free cgroup private data
  * @cgrp: cgroup to release private data for
-- 
2.14.3

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

[Intel-gfx] [PATCH v4.5 0/8] cgroup private data and DRM/i915 integration

[Matt Roper]

This version of the patch series just contains some minor updates to
address checkpatch and sparse warnings.  There are no serious design or
implementation changes since v4.

You can find the previous versions of this series (and more detailed
cover letters) here:
 (v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
 (v2) 
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
 (v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html
 (v4) https://lists.freedesktop.org/archives/intel-gfx/2018-March/159222.html

Matt Roper (8):
  cgroup: Allow registration and lookup of cgroup private data (v3)
  cgroup: Introduce task_get_dfl_cgroup() (v2)
  cgroup: Introduce cgroup_priv_get_current
  drm/i915: Adjust internal priority definitions (v2)
  drm/i915: cgroup integration (v4)
  drm/i915: Introduce 'priority offset' for GPU contexts (v4)
  drm/i915: Introduce per-cgroup display boost setting
  drm/i915: Add context priority & priority offset to debugfs (v2)

 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_cgroup.c  | 207 
 drivers/gpu/drm/i915/i915_debugfs.c |   3 +
 drivers/gpu/drm/i915/i915_drv.c |   8 ++
 drivers/gpu/drm/i915/i915_drv.h |  46 ++-
 drivers/gpu/drm/i915/i915_gem_context.c |  12 +-
 drivers/gpu/drm/i915/i915_gem_context.h |   9 ++
 drivers/gpu/drm/i915/i915_request.h |  18 ++-
 drivers/gpu/drm/i915/intel_display.c|   5 +-
 include/linux/cgroup-defs.h |   8 ++
 include/linux/cgroup.h  |  37 ++
 include/uapi/drm/i915_drm.h |  14 +++
 kernel/cgroup/cgroup.c  | 206 ++-
 13 files changed, 561 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c

-- 
2.14.3

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

[Intel-gfx] [PATCH v4.5 2/8] cgroup: Introduce task_get_dfl_cgroup() (v2)

[Matt Roper]

Wraps task_dfl_cgroup() to also take a reference to the cgroup.

v2:
 - Eliminate cgroup_mutex and make lighter-weight (Tejun)

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/linux/cgroup.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 63d22dfa00bd..74b435f913c1 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -527,6 +527,35 @@ static inline struct cgroup *task_dfl_cgroup(struct 
task_struct *task)
return task_css_set(task)->dfl_cgrp;
 }
 
+/**
+ * task_get_dfl_cgroup() - find and get the cgroup for a task
+ * @task: the target task
+ *
+ * Find the cgroup in the v2 hierarchy that a task belongs to, increment its
+ * reference count, and return it.
+ *
+ * Returns:
+ * The appropriate cgroup from the default hierarchy.
+ */
+static inline struct cgroup *
+task_get_dfl_cgroup(struct task_struct *task)
+{
+   struct cgroup *cgrp;
+
+   rcu_read_lock();
+   while (true) {
+   cgrp = task_dfl_cgroup(task);
+
+   if (likely(cgroup_tryget(cgrp)))
+   break;
+
+   cpu_relax();
+   }
+   rcu_read_unlock();
+
+   return cgrp;
+}
+
 static inline struct cgroup *cgroup_parent(struct cgroup *cgrp)
 {
struct cgroup_subsys_state *parent_css = cgrp->self.parent;
-- 
2.14.3

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

Re: [Intel-gfx] [PATCH v3] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

[Yaodong Li]

Thanks Sagar and Joonas! I probably need reconfigure my email client.

I will add these docs to i915.rst. Since we've already had a GuC chapter 
defined in i915.rst,


so I will include these doc like:

WOPCM

        WOPCM Layout doc

GuC

    

        GuC Address Space doc

Please let me know if I misunderstood anything.

Thanks,

-Jackie

On 03/21/2018 04:53 AM, Sagar Arun Kamble wrote:
Joonas suggests to include these files guc.c and wopcm.c in i915.rst 
with WOPCM being separate section from GuC.

Also ensure make htmldocs generates proper/expected documentation.

Thanks,
Sagar

On 3/15/2018 10:24 PM, Jackie Li wrote:
GuC Address Space and WOPCM Layout diagrams won't be generated 
correctly by

sphinx build if not using proper reST syntax.

This patch uses reST literal blocks to make sure GuC Address Space and
WOPCM Layout diagrams to be generated correctly, and it also corrects 
some

errors in the diagram description.

v2:
  - Fixed errors in diagram description

v3:
  - Updated GuC Address Space kernel-doc based on Michal's suggestion

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/intel_guc.c   | 56 
--

  drivers/gpu/drm/i915/intel_wopcm.c | 44 --
  2 files changed, 52 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 3eb516e..bcbdf15 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -495,35 +495,37 @@ int intel_guc_resume(struct intel_guc *guc)
  /**
   * DOC: GuC Address Space
   *
- * The layout of GuC address space is shown as below:
+ * The layout of GuC address space is shown below:
   *
- *    +==> ++ <== GUC_GGTT_TOP
- *    ^    |    |
- *    |    |    |
- *    |    |    DRAM    |
- *    |    |   Memory   |
- *    |    |    |
- *   GuC   |    |
- * Address  +> ++ <== WOPCM Top
- *  Space   ^  |   HW contexts RSVD |
- *    | |  |    WOPCM   |
- *    | | +==> ++ <== GuC WOPCM Top
- *    |    GuC    ^    |    |
- *    |    GGTT   |    |    |
- *    |    Pin   GuC   |    GuC |
- *    |    Bias WOPCM  |   WOPCM    |
- *    | |    Size  |    |
- *    | | |    |    |
- *    v v v    |    |
- *    +=+=+==> ++ <== GuC WOPCM Base
- * |   Non-GuC WOPCM    |
- * |   (HuC/Reserved)   |
- * ++ <== WOPCM Base
+ * ::
   *
- * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which 
consists of
- * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). 
The value of
- * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM 
size which is

- * set in GUC_WOPCM_SIZE register.
+ * +==> ++ <== GUC_GGTT_TOP
+ * ^    |    |
+ * |    |    |
+ * |    |    DRAM    |
+ * |    |   Memory   |
+ * |    |    |
+ *    GuC   |    |
+ *  Address  +> ++ <== WOPCM Top
+ *   Space   ^  |   HW contexts RSVD |
+ * | |  |    WOPCM   |
+ * | | +==> ++ <== GuC WOPCM Top
+ * |    GuC    ^    |    |
+ * |    GGTT   |    |    |
+ * |    Pin   GuC   |    GuC |
+ * |    Bias WOPCM  |   WOPCM    |
+ * | |    Size  |    |
+ * | | |    |    |
+ * v v v    |    |
+ * +=+=+==> ++ <== GuC WOPCM Base
+ *  |   Non-GuC WOPCM    |
+ *  |   (HuC/Reserved)   |
+ *  ++ <== WOPCM Base
+ *
+ * The lower part of GuC Address Space [0, ggtt_pin_bias) is mapped 
to WOPCM
+ * while upper part of GuC Address Space [ggtt_pin_bias, 
GUC_GGTT_TOP) is mapped
+ * to DRAM. The value of the GuC ggtt_pin_bias is determined by 
WOPCM size and

+ * actual GuC WOPCM size.
   */
    /**
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c

index 4117886..74bf76f 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -11,28 +11,30 @@
   * DOC: WOPCM Layout
   *
   * The layout of the 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix uabi regression by allowing garbage mode->type from userspace

[Patchwork]

== Series Details ==

Series: drm: Fix uabi regression by allowing garbage mode->type from userspace
URL   : https://patchwork.freedesktop.org/series/40416/
State : success

== Summary ==

Series 40416v1 drm: Fix uabi regression by allowing garbage mode->type from 
userspace
https://patchwork.freedesktop.org/api/1.0/series/40416/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (fi-skl-6770hq) fdo#100368

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:430s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:517s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:513s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:508s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:418s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:546s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:422s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:424s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:475s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:514s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:647s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:428s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:575s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:406s

dff9ece60048108782aab6d6123822c1d34b0e5a drm-tip: 2018y-03m-21d-20h-44m-14s UTC 
integration manifest
1ace93ec3e0c drm: Fix uabi regression by allowing garbage mode->type from 
userspace

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Fix uabi regression by allowing garbage mode->type from userspace

[Patchwork]

== Series Details ==

Series: drm: Fix uabi regression by allowing garbage mode->type from userspace
URL   : https://patchwork.freedesktop.org/series/40416/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
1ace93ec3e0c drm: Fix uabi regression by allowing garbage mode->type from 
userspace
-:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#21: 
References: 
https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html

total: 0 errors, 1 warnings, 0 checks, 14 lines checked

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Include the trace as a 
debug aide
URL   : https://patchwork.freedesktop.org/series/40410/
State : success

== Summary ==

Series 40410v1 series starting with [1/2] drm/i915/selftests: Include the trace 
as a debug aide
https://patchwork.freedesktop.org/api/1.0/series/40410/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (fi-skl-6770hq) fdo#100368
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:436s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:516s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:515s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:509s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:522s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:587s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:420s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:285  pass:224  dwarn:0   dfail:0   fail:1   skip:60  
time:424s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:429s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:517s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:648s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:442s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:566s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:397s

dff9ece60048108782aab6d6123822c1d34b0e5a drm-tip: 2018y-03m-21d-20h-44m-14s UTC 
integration manifest
6123bbc2de1c drm/i915/selftests: Stress resets-vs-request-priority
5775fcc92769 drm/i915/selftests: Include the trace as a debug aide

== Logs ==

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

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add definitions for the ICL PLL registers

[Paulo Zanoni]

Em Ter, 2018-02-27 às 14:22 -0800, James Ausmus escreveu:
> On Thu, Feb 22, 2018 at 12:55:03AM -0300, Paulo Zanoni wrote:
> > There's a lot of code for the PLL enabling, so let's first only
> > introduce the register definitions in order to make patch reviewing
> > a
> > little easier.
> > 
> > v2: Coding style (Jani).
> > v3: Preparation for upstreaming.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 149
> > 
> >  1 file changed, 149 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 1412abcb27d4..f62335c4a748 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8783,6 +8783,12 @@ enum skl_power_gate {
> >  #define  PORT_CLK_SEL_NONE (7<<29)
> >  #define  PORT_CLK_SEL_MASK (7<<29)
> >  
> > +/* On ICL+ this is the same as PORT_CLK_SEL, but all bits change.
> > */
> > +#define DDI_CLK_SEL(port)  PORT_CLK_SEL(port)
> > +#define  DDI_CLK_SEL_NONE  (0x0 << 28)
> > +#define  DDI_CLK_SEL_MG(0x8 << 28)
> > +#define  DDI_CLK_SEL_MASK  (0xF << 28)
> > +
> >  /* Transcoder clock selection */
> >  #define _TRANS_CLK_SEL_A   0x46140
> >  #define _TRANS_CLK_SEL_B   0x46144
> > @@ -8913,6 +8919,7 @@ enum skl_power_gate {
> >   * CNL Clocks
> >   */
> >  #define DPCLKA_CFGCR0  _MMIO(0x6C200
> > )
> > +#define DPCLKA_CFGCR0_ICL  _MMIO(0x164280)
> >  #define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port)
> > ==  PORT_F ? 23 : \
> >   (port)+10))
> >  #define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port) ==
> > PORT_F ? 21 : \
> > @@ -8929,10 +8936,141 @@ enum skl_power_gate {
> >  #define  PLL_POWER_STATE   (1 << 26)
> >  #define CNL_DPLL_ENABLE(pll)   _MMIO_PLL(pll, DPLL0_ENABLE,
> > DPLL1_ENABLE)
> >  
> > +#define _MG_PLL1_ENABLE0x46030
> > +#define _MG_PLL2_ENABLE0x46034
> > +#define _MG_PLL3_ENABLE0x46038
> > +#define _MG_PLL4_ENABLE0x4603C
> > +/* Bits are the same as DPLL0_ENABLE */
> > +#define MG_PLL_ENABLE(port)_MMIO_PORT((port) - PORT_C,
> > _MG_PLL1_ENABLE, \
> > +  _MG_PLL2_ENABLE)
> > +
> > +#define _MG_REFCLKIN_CTL_PORT1 0x16
> > 892C
> > +#define _MG_REFCLKIN_CTL_PORT2 0x16
> > 992C
> > +#define _MG_REFCLKIN_CTL_PORT3 0x16
> > A92C
> > +#define _MG_REFCLKIN_CTL_PORT4 0x16
> > B92C
> > +#define   MG_REFCLKIN_CTL_OD_2_MUX(x)  ((x)
> > << 8)
> > +#define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
> > +_MG_REFCLKIN_CTL_PORT1, \
> > +_MG_REFCLKIN_CTL_PORT2)
> > +
> > +#define _MG_CLKTOP2_CORECLKCTL1_PORT1  0x169
> > 0D8
> > +#define _MG_CLKTOP2_CORECLKCTL1_PORT2  0x16B
> > 0D8
> > +#define _MG_CLKTOP2_CORECLKCTL1_PORT3  0x16D
> > 0D8
> > +#define _MG_CLKTOP2_CORECLKCTL1_PORT4  0x16F
> > 0D8
> > +#define   MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO(x) ((x)
> > << 16)
> > +#define   MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x) ((x)
> > << 8)
> > +#define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C, \
> > +   _MG_CLKTOP2_CORECL
> > KCTL1_PORT1, \
> > +   _MG_CLKTOP2_CORECL
> > KCTL1_PORT2)
> 
> BSpec 21736 says this register is unused and pending deletion, but in
> 20845 it also
> says to program this register. Art, can you shed any light here?
> 

21736 is for a different platform. If you filter for ICL the page
becomes blank.


> Hmm, on further study, it looks like the MG_CLKTOP_CORECLKCTL1 group
> (21340) names the port instances as MG_CLKTOP2_CORECLKCTL1_PORTx, so
> it
> looks like *that* is the actual register group you want (and the
> register bit definitions match as well), 

And it's the one that opens when you click it from the icl clocks page
:).

> but, in that case, the
> addresses are wrong - they need to be: 0x1688D8, 0x1698D8, 0x16A8D8,
> and
> 0x16B8D8, respectively.

You're correct, I got this wrong.


> 
> > +
> > +#define _MG_CLKTOP2_HSCLKCTL_PORT1 0x1688D4
> > +#define _MG_CLKTOP2_HSCLKCTL_PORT2 0x1698D4
> > +#define _MG_CLKTOP2_HSCLKCTL_PORT3 0x16A8D4
> > +#define _MG_CLKTOP2_HSCLKCTL_PORT4 0x16B8D4
> > +#define   MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL(x) ((x)
> > << 16)
> > +#define   MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL(x)   ((x) <<
> > 14)
> > +#define   MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO(x)   ((x)
> > << 12)
> > +#define   

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Include the trace as a 
debug aide
URL   : https://patchwork.freedesktop.org/series/40410/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5775fcc92769 drm/i915/selftests: Include the trace as a debug aide
-:36: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#36: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:627:
+   if (i915_request_wait(old, 0, 10*HZ) < 0) {
^

total: 0 errors, 0 warnings, 1 checks, 43 lines checked
6123bbc2de1c drm/i915/selftests: Stress resets-vs-request-priority

___
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: Flush pending interrupt following a GPU reset

[Patchwork]

== Series Details ==

Series: drm/i915: Flush pending interrupt following a GPU reset
URL   : https://patchwork.freedesktop.org/series/40383/
State : success

== Summary ==

 Known issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-indfb-plflip-blt:
fail   -> PASS   (shard-apl) fdo#101623
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-apltotal:3478 pass:1814 dwarn:1   dfail:0   fail:7   skip:1655 
time:13063s
shard-hswtotal:3478 pass:1767 dwarn:1   dfail:0   fail:2   skip:1707 
time:11883s
shard-snbtotal:3478 pass:1357 dwarn:1   dfail:0   fail:3   skip:2117 
time:7236s

== Logs ==

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

[Intel-gfx] [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace

[Ville Syrjala]

From: Ville Syrjälä 

Apparently xf86-video-vmware leaves the mode->type uninitialized
when feeding the mode to the kernel. Thus we have no choice but
to accept the garbage in. We'll just ignore any of the bits we
don't want. The mode type is just a hint anyway, and more
useful for the kernel->userspace direction.

Reported-by: Thomas Hellstrom 
CC: Thomas Hellstrom 
Cc: Adam Jackson 
Cc: Alex Deucher 
Fixes: c6ed6dad5cfb ("drm/uapi: Validate the mode flags/type")
References: 
https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f6b7c0e36a1a..e82b61e08f8c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1611,7 +1611,13 @@ int drm_mode_convert_umode(struct drm_device *dev,
out->vscan = in->vscan;
out->vrefresh = in->vrefresh;
out->flags = in->flags;
-   out->type = in->type;
+   /*
+* Old xf86-video-vmware (possibly others too) used to
+* leave 'type' unititialized. Just ignore any bits we
+* don't like. It's a just hint after all, and more
+* useful for the kernel->userspace direction anyway.
+*/
+   out->type = in->type & DRM_MODE_TYPE_ALL;
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
-- 
2.16.1

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

Re: [Intel-gfx] drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type

[Thomas Hellstrom]

On 03/21/2018 09:51 PM, Ville Syrjälä wrote:

On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote:

Hi, Ville,

On 11/14/2017 07:32 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently userspace is allowed to feed in any king of garbage in the
high bits of the mode flags/type, as are drivers when probing modes.
Reject any mode with bogus flags/type.

Hopefully this won't break any current userspace...

Unfortunately this breaks xf86-video-vmware which currently leaves the
mode->type uninitialized :(.
That code is inherited from the old gallium xorg state tracker. I don't
know whether it has spread elsewhere but the symptoms are that the X
server frequently dies failing to set screen resources, a very
uninformative error.

I'll fix the xf86-video-vmware driver, but I guess we need to back out
the mode->type check.

Dang. So the flags check is fine but type check is not?

Yes, we copy the flags field untranslated from xorg's 
DisplayModePtr::Flags field which seems to be what 
xf86-video-modesetting does as well, so I guess we should be OK there.


/Thomas


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

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Stress resets-vs-request-priority

[Chris Wilson]

Watch what happens if we try to reset with a queue of requests with
varying priorities -- that may need reordering or preemption across the
reset.

v2: Tweak priorities to avoid starving the hanging thread.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 189 +++
 1 file changed, 126 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 1969a65072ca..c5ed4006c319 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -25,6 +25,7 @@
 #include 
 
 #include "../i915_selftest.h"
+#include "i915_random.h"
 
 #include "mock_context.h"
 #include "mock_drm.h"
@@ -486,6 +487,8 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
 
set_bit(I915_RESET_ENGINE + id, >gpu_error.flags);
do {
+   u32 seqno = intel_engine_get_seqno(engine);
+
if (active) {
struct i915_request *rq;
 
@@ -514,12 +517,13 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
break;
}
 
+   GEM_BUG_ON(!rq->global_seqno);
+   seqno = rq->global_seqno - 1;
i915_request_put(rq);
}
 
engine->hangcheck.stalled = true;
-   engine->hangcheck.seqno =
-   intel_engine_get_seqno(engine);
+   engine->hangcheck.seqno = seqno;
 
err = i915_reset_engine(engine, NULL);
if (err) {
@@ -576,11 +580,25 @@ static int igt_reset_active_engine(void *arg)
return __igt_reset_engine(arg, true);
 }
 
+struct active_engine {
+   struct task_struct *task;
+   struct intel_engine_cs *engine;
+   unsigned long resets;
+   unsigned int flags;
+};
+
+#define TEST_ACTIVEBIT(0)
+#define TEST_OTHERSBIT(1)
+#define TEST_SELF  BIT(2)
+#define TEST_PRIORITY  BIT(3)
+
 static int active_engine(void *data)
 {
-   struct intel_engine_cs *engine = data;
-   struct i915_request *rq[2] = {};
-   struct i915_gem_context *ctx[2];
+   I915_RND_STATE(prng);
+   struct active_engine *arg = data;
+   struct intel_engine_cs *engine = arg->engine;
+   struct i915_request *rq[8] = {};
+   struct i915_gem_context *ctx[ARRAY_SIZE(rq)];
struct drm_file *file;
unsigned long count = 0;
int err = 0;
@@ -589,25 +607,20 @@ static int active_engine(void *data)
if (IS_ERR(file))
return PTR_ERR(file);
 
-   mutex_lock(>i915->drm.struct_mutex);
-   ctx[0] = live_context(engine->i915, file);
-   mutex_unlock(>i915->drm.struct_mutex);
-   if (IS_ERR(ctx[0])) {
-   err = PTR_ERR(ctx[0]);
-   goto err_file;
-   }
-
-   mutex_lock(>i915->drm.struct_mutex);
-   ctx[1] = live_context(engine->i915, file);
-   mutex_unlock(>i915->drm.struct_mutex);
-   if (IS_ERR(ctx[1])) {
-   err = PTR_ERR(ctx[1]);
-   i915_gem_context_put(ctx[0]);
-   goto err_file;
+   for (count = 0; count < ARRAY_SIZE(ctx); count++) {
+   mutex_lock(>i915->drm.struct_mutex);
+   ctx[count] = live_context(engine->i915, file);
+   mutex_unlock(>i915->drm.struct_mutex);
+   if (IS_ERR(ctx[count])) {
+   err = PTR_ERR(ctx[count]);
+   while (--count)
+   i915_gem_context_put(ctx[count]);
+   goto err_file;
+   }
}
 
while (!kthread_should_stop()) {
-   unsigned int idx = count++ & 1;
+   unsigned int idx = count++ & (ARRAY_SIZE(rq) - 1);
struct i915_request *old = rq[idx];
struct i915_request *new;
 
@@ -619,6 +632,10 @@ static int active_engine(void *data)
break;
}
 
+   if (arg->flags & TEST_PRIORITY)
+   ctx[idx]->priority =
+   i915_prandom_u32_max_state(512, );
+
rq[idx] = i915_request_get(new);
i915_request_add(new);
mutex_unlock(>i915->drm.struct_mutex);
@@ -647,8 +664,9 @@ static int active_engine(void *data)
return err;
 }
 
-static int __igt_reset_engine_others(struct drm_i915_private *i915,
-bool active)
+static int __igt_reset_engines(struct drm_i915_private *i915,
+  const char *test_name,
+  unsigned int flags)
 {
struct intel_engine_cs 

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Include the trace as a debug aide

[Chris Wilson]

If we fail to reset the GPU in a timely fashion, dump the GEM trace so
that we can see what operations were in flight when the GPU got stuck.

v2: There's more than one timeout that deserves tracing!

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 4372826998aa..1969a65072ca 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -260,8 +260,11 @@ static void wedge_me(struct work_struct *work)
 {
struct wedge_me *w = container_of(work, typeof(*w), work.work);
 
-   pr_err("%pS timed out, cancelling all further testing.\n",
-  w->symbol);
+   pr_err("%pS timed out, cancelling all further testing.\n", w->symbol);
+
+   GEM_TRACE("%pS timed out.\n", w->symbol);
+   GEM_TRACE_DUMP();
+
i915_gem_set_wedged(w->i915);
 }
 
@@ -621,9 +624,19 @@ static int active_engine(void *data)
mutex_unlock(>i915->drm.struct_mutex);
 
if (old) {
-   i915_request_wait(old, 0, MAX_SCHEDULE_TIMEOUT);
+   if (i915_request_wait(old, 0, 10*HZ) < 0) {
+   GEM_TRACE("%s timed out.\n", engine->name);
+   GEM_TRACE_DUMP();
+
+   i915_gem_set_wedged(engine->i915);
+   i915_request_put(old);
+   err = -EIO;
+   break;
+   }
i915_request_put(old);
}
+
+   cond_resched();
}
 
for (count = 0; count < ARRAY_SIZE(rq); count++)
@@ -1126,6 +1139,10 @@ int intel_hangcheck_live_selftests(struct 
drm_i915_private *i915)
 
err = i915_subtests(tests, i915);
 
+   mutex_lock(>drm.struct_mutex);
+   flush_test(i915, I915_WAIT_LOCKED);
+   mutex_unlock(>drm.struct_mutex);
+
i915_modparams.enable_hangcheck = saved_hangcheck;
intel_runtime_pm_put(i915);
 
-- 
2.16.2

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

[Intel-gfx] drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type

[Thomas Hellstrom]

Hi, Ville,

On 11/14/2017 07:32 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently userspace is allowed to feed in any king of garbage in the
high bits of the mode flags/type, as are drivers when probing modes.
Reject any mode with bogus flags/type.

Hopefully this won't break any current userspace...


Unfortunately this breaks xf86-video-vmware which currently leaves the 
mode->type uninitialized :(.
That code is inherited from the old gallium xorg state tracker. I don't 
know whether it has spread elsewhere but the symptoms are that the X 
server frequently dies failing to set screen resources, a very 
uninformative error.


I'll fix the xf86-video-vmware driver, but I guess we need to back out 
the mode->type check.


/Thomas

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

Re: [Intel-gfx] drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type

[Ville Syrjälä]

On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote:
> Hi, Ville,
> 
> On 11/14/2017 07:32 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Currently userspace is allowed to feed in any king of garbage in the
> > high bits of the mode flags/type, as are drivers when probing modes.
> > Reject any mode with bogus flags/type.
> >
> > Hopefully this won't break any current userspace...
> 
> Unfortunately this breaks xf86-video-vmware which currently leaves the 
> mode->type uninitialized :(.
> That code is inherited from the old gallium xorg state tracker. I don't 
> know whether it has spread elsewhere but the symptoms are that the X 
> server frequently dies failing to set screen resources, a very 
> uninformative error.
> 
> I'll fix the xf86-video-vmware driver, but I guess we need to back out 
> the mode->type check.

Dang. So the flags check is fine but type check is not?

-- 
Ville Syrjälä
Intel OTC
___
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] drm/i915: Use full serialisation around engine->irq_posted

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use full serialisation around 
engine->irq_posted
URL   : https://patchwork.freedesktop.org/series/40406/
State : success

== Summary ==

Series 40406v1 series starting with [1/2] drm/i915: Use full serialisation 
around engine->irq_posted
https://patchwork.freedesktop.org/api/1.0/series/40406/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:433s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:517s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:503s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:510s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:509s
fi-cnl-y3total:285  pass:258  dwarn:1   dfail:0   fail:0   skip:26  
time:585s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:319s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:474s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:655s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:427s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:603s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
fi-bxt-dsi failed to collect. IGT log at Patchwork_8439/fi-bxt-dsi/run0.log

d1aafb635a5ff976b7b3164a6aff86f29871d415 drm-tip: 2018y-03m-21d-17h-25m-04s UTC 
integration manifest
bacd41c3f19b drm/i915: Flush pending interrupt following a GPU reset
ffea28ec97fb drm/i915: Use full serialisation around engine->irq_posted

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Remove open-coded PSR AUX transactions for SKL+

[Rodrigo Vivi]

On Tue, Mar 13, 2018 at 08:46:56PM +, Souza, Jose wrote:
> On Mon, 2018-03-12 at 20:46 -0700, Dhinakaran Pandiyan wrote:
> > HSW and BDW have SRD_AUX_{CTL, STATUS} registers that the driver
> > needs to
> > setup for the HW to use whenever exiting PSR. SKL+ hardware use
> > hardcoded
> > values for the same and do not need any registers to be setup. So,
> > use
> > drm_dp_dpcd_writeb() for a one-time write during PSR enable and setup
> > the
> > PSR aux registers on HSW and BDW for later use by HW.
> > 
> > We also end up writing to reserved bits in SRD_AUX_CTL by reusing
> > intel_dp->get_aux_send_ctl() for HSW and BDW, fix this.
> > 
> > Since the AUX register setup is source side programming, move the
> > call
> > to enable_source() from enable_sink().
> > 
> > Cc: José Roberto de Souza 
> 
> Reviewed-by: Jose Roberto de Souza 

pushed to dinq. thanks for patch and review.

> 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  6 +
> >  drivers/gpu/drm/i915/intel_psr.c | 55 
> > 
> >  2 files changed, 28 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index abdc513a9edd..23c0f9bdf591 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4151,6 +4151,12 @@ enum {
> >  #define   EDP_PSR_IDLE_FRAME_SHIFT 0
> >  
> >  #define EDP_PSR_AUX_CTL_MMIO(dev_pri
> > v->psr_mmio_base + 0x10)
> > +#define   EDP_PSR_AUX_CTL_TIME_OUT_MASK(3 << 26)
> > +#define   EDP_PSR_AUX_CTL_MESSAGE_SIZE_MASK(0x1f << 20)
> > +#define   EDP_PSR_AUX_CTL_PRECHARGE_2US_MASK   (0xf << 16)
> > +#define   EDP_PSR_AUX_CTL_ERROR_INTERRUPT  (1 << 11)
> > +#define   EDP_PSR_AUX_CTL_BIT_CLOCK_2X_MASK(0x7ff)
> > +
> >  #define EDP_PSR_AUX_DATA(i)_MMIO(dev_priv-
> > >psr_mmio_base + 0x14 + (i) * 4) /* 5 registers */
> >  
> >  #define EDP_PSR_STATUS _MMIO(dev_priv
> > ->psr_mmio_base + 0x40)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 86d6c19c9ae6..293a987a1bfd 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -228,31 +228,12 @@ static void vlv_psr_enable_sink(struct intel_dp
> > *intel_dp)
> >DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
> >  }
> >  
> > -static i915_reg_t psr_aux_ctl_reg(struct drm_i915_private *dev_priv,
> > -  enum port port)
> > -{
> > -   if (INTEL_GEN(dev_priv) >= 9)
> > -   return DP_AUX_CH_CTL(port);
> > -   else
> > -   return EDP_PSR_AUX_CTL;
> > -}
> > -
> > -static i915_reg_t psr_aux_data_reg(struct drm_i915_private
> > *dev_priv,
> > -   enum port port, int index)
> > -{
> > -   if (INTEL_GEN(dev_priv) >= 9)
> > -   return DP_AUX_CH_DATA(port, index);
> > -   else
> > -   return EDP_PSR_AUX_DATA(index);
> > -}
> > -
> >  static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
> >  {
> > struct intel_digital_port *dig_port =
> > dp_to_dig_port(intel_dp);
> > -   struct drm_device *dev = dig_port->base.base.dev;
> > -   struct drm_i915_private *dev_priv = to_i915(dev);
> > -   uint32_t aux_clock_divider;
> > -   i915_reg_t aux_ctl_reg;
> > +   struct drm_i915_private *dev_priv = to_i915(dig_port-
> > >base.base.dev);
> > +   u32 aux_clock_divider, aux_ctl;
> > +   int i;
> > static const uint8_t aux_msg[] = {
> > [0] = DP_AUX_NATIVE_WRITE << 4,
> > [1] = DP_SET_POWER >> 8,
> > @@ -260,23 +241,25 @@ static void hsw_psr_setup_aux(struct intel_dp
> > *intel_dp)
> > [3] = 1 - 1,
> > [4] = DP_SET_POWER_D0,
> > };
> > -   enum port port = dig_port->base.port;
> > -   u32 aux_ctl;
> > -   int i;
> > +   u32 psr_aux_mask = EDP_PSR_AUX_CTL_TIME_OUT_MASK |
> > +  EDP_PSR_AUX_CTL_MESSAGE_SIZE_MASK |
> > +  EDP_PSR_AUX_CTL_PRECHARGE_2US_MASK |
> > +  EDP_PSR_AUX_CTL_BIT_CLOCK_2X_MASK;
> >  
> > BUILD_BUG_ON(sizeof(aux_msg) > 20);
> > -
> > -   aux_clock_divider = intel_dp-
> > >get_aux_clock_divider(intel_dp, 0);
> > -   aux_ctl_reg = psr_aux_ctl_reg(dev_priv, port);
> > -
> > -   /* Setup AUX registers */
> > for (i = 0; i < sizeof(aux_msg); i += 4)
> > -   I915_WRITE(psr_aux_data_reg(dev_priv, port, i >> 2),
> > +   I915_WRITE(EDP_PSR_AUX_DATA(i >> 2),
> >intel_dp_pack_aux(_msg[i],
> > sizeof(aux_msg) - i));
> >  
> > +   aux_clock_divider = intel_dp-
> > >get_aux_clock_divider(intel_dp, 0);
> > +
> > +   /* Start with bits set for DDI_AUX_CTL register */
> > aux_ctl = 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Use full serialisation around 
engine->irq_posted
URL   : https://patchwork.freedesktop.org/series/40406/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ffea28ec97fb drm/i915: Use full serialisation around engine->irq_posted
bacd41c3f19b drm/i915: Flush pending interrupt following a GPU reset
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#23: 
2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
global_seqno 1060

total: 0 errors, 1 warnings, 0 checks, 30 lines checked

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Move PSR aux setup to it's own function.

[Rodrigo Vivi]

On Mon, Mar 12, 2018 at 08:46:45PM -0700, Dhinakaran Pandiyan wrote:
> Non-functional change useful for the following patch.
> 
> Cc: Rodrigo Vivi 
> Cc: José Roberto de Souza 
> Signed-off-by: Dhinakaran Pandiyan 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_psr.c | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 975ebb51c7af..86d6c19c9ae6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -246,7 +246,7 @@ static i915_reg_t psr_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>   return EDP_PSR_AUX_DATA(index);
>  }
>  
> -static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
> +static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
> @@ -267,6 +267,24 @@ static void hsw_psr_enable_sink(struct intel_dp 
> *intel_dp)
>   BUILD_BUG_ON(sizeof(aux_msg) > 20);
>  
>   aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 0);
> + aux_ctl_reg = psr_aux_ctl_reg(dev_priv, port);
> +
> + /* Setup AUX registers */
> + for (i = 0; i < sizeof(aux_msg); i += 4)
> + I915_WRITE(psr_aux_data_reg(dev_priv, port, i >> 2),
> +intel_dp_pack_aux(_msg[i], sizeof(aux_msg) - i));
> +
> + aux_ctl = intel_dp->get_aux_send_ctl(intel_dp, 0, sizeof(aux_msg),
> +  aux_clock_divider);
> + I915_WRITE(aux_ctl_reg, aux_ctl);
> +}
> +
> +static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
>  
>   /* Enable AUX frame sync at sink */
>   if (dev_priv->psr.aux_frame_sync)
> @@ -285,16 +303,7 @@ static void hsw_psr_enable_sink(struct intel_dp 
> *intel_dp)
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
>  DP_PSR_ENABLE);
>  
> - aux_ctl_reg = psr_aux_ctl_reg(dev_priv, port);
> -
> - /* Setup AUX registers */
> - for (i = 0; i < sizeof(aux_msg); i += 4)
> - I915_WRITE(psr_aux_data_reg(dev_priv, port, i >> 2),
> -intel_dp_pack_aux(_msg[i], sizeof(aux_msg) - i));
> -
> - aux_ctl = intel_dp->get_aux_send_ctl(intel_dp, 0, sizeof(aux_msg),
> -  aux_clock_divider);
> - I915_WRITE(aux_ctl_reg, aux_ctl);
> + hsw_psr_setup_aux(intel_dp);
>  }
>  
>  static void vlv_psr_enable_source(struct intel_dp *intel_dp,
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use full serialisation around engine->irq_posted

[Patchwork]

== Series Details ==

Series: drm/i915: Use full serialisation around engine->irq_posted
URL   : https://patchwork.freedesktop.org/series/40403/
State : success

== Summary ==

Series 40403v1 drm/i915: Use full serialisation around engine->irq_posted
https://patchwork.freedesktop.org/api/1.0/series/40403/revisions/1/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-bxt-dsi)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:437s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:537s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:516s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:503s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:523s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:317s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:436s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:466s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:646s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:427s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:443s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:583s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:401s

d1aafb635a5ff976b7b3164a6aff86f29871d415 drm-tip: 2018y-03m-21d-17h-25m-04s UTC 
integration manifest
9df420873135 drm/i915: Use full serialisation around engine->irq_posted

== Logs ==

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

[Intel-gfx] [PATCH 1/2] drm/i915: Use full serialisation around engine->irq_posted

[Chris Wilson]

Using engine->irq_posted for execlists, we are not always serialised by
the tasklet as we supposed. On the reset paths, the tasklet is disabled
and ignored. Instead, we manipulate the engine->irq_posted directly to
account for the reset, but if an interrupt fired before the reset and so
wrote to engine->irq_posted, that write may not be flushed from the
local CPU's cacheline until much later as the tasklet is already active
and so does not generate a mb(). To correctly serialise the interrupt
with reset, we need serialisation on the set_bit() itself.

And at last Mika can be happy.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fa7310766217..27aee25429b7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1405,10 +1405,9 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir)
bool tasklet = false;
 
if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
-   if (READ_ONCE(engine->execlists.active)) {
-   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
-   tasklet = true;
-   }
+   if (READ_ONCE(engine->execlists.active))
+   tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
+   >irq_posted);
}
 
if (iir & GT_RENDER_USER_INTERRUPT) {
-- 
2.16.2

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

[Intel-gfx] [PATCH 2/2] drm/i915: Flush pending interrupt following a GPU reset

[Chris Wilson]

After resetting the GPU (or subset of engines), call synchronize_irq()
to flush any pending irq before proceeding with the cleanup. For a
device level reset, we disable the interupts around the reset, but when
resetting just one engine, we have to avoid such global disabling. This
leaves us open to an interrupt arriving for the engine as we try to
reset it. We already do try to flush the IIR following the reset, but we
have to ensure that the in-flight interrupt does not land after we start
cleaning up after the reset; enter synchronize_irq().

As it current stands, we very rarely, but fatally, see sequences such as:

2 57964564us : execlists_reset_prepare: rcs0
2 57964613us : execlists_reset: rcs0 seqno=424
0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1
2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
global_seqno 1060
2 57964703us : execlists_reset_finish: rcs0
0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, active=0, 
irq-posted?=1

v2: Move the sync into the execlists reset handler so that we coordinate
the flush with disabling the interrupt handling and canceling the
pending interrupt.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Cc: Michał Winiarski 
Cc: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_lrc.c| 7 ---
 drivers/gpu/drm/i915/intel_uncore.c | 4 +++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 67b6a0f658d6..595d9101a1de 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -805,6 +805,10 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
 
spin_unlock(>timeline->lock);
 
+   /* Mark all CS interrupts as complete */
+   smp_store_mb(execlists->active, 0);
+   synchronize_irq(engine->i915->drm.irq);
+
/*
 * The port is checked prior to scheduling a tasklet, but
 * just in case we have suspended the tasklet to do the
@@ -813,9 +817,6 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
 */
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
 
-   /* Mark all CS interrupts as complete */
-   execlists->active = 0;
-
local_irq_restore(flags);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 4c616d074a97..f37ecfc69e49 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2116,8 +2116,10 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
unsigned engine_mask)
i915_stop_engines(dev_priv, engine_mask);
 
ret = -ENODEV;
-   if (reset)
+   if (reset) {
+   GEM_TRACE("engine_mask=%x\n", engine_mask);
ret = reset(dev_priv, engine_mask);
+   }
if (ret != -ETIMEDOUT)
break;
 
-- 
2.16.2

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: don't dereference 'workload' before null checking it

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: don't dereference 'workload' before null checking it
URL   : https://patchwork.freedesktop.org/series/40401/
State : success

== Summary ==

Series 40401v1 drm/i915/gvt: don't dereference 'workload' before null checking 
it
https://patchwork.freedesktop.org/api/1.0/series/40401/revisions/1/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-bxt-dsi)

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#103191
Subgroup suspend-read-crc-pipe-c:
notrun -> INCOMPLETE (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:446s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:533s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:301s
fi-bxt-dsi   total:243  pass:216  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:516s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:505s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:519s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:585s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:319s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:474s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:655s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:539s
fi-skl-6700k2total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:428s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:580s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s

d1aafb635a5ff976b7b3164a6aff86f29871d415 drm-tip: 2018y-03m-21d-17h-25m-04s UTC 
integration manifest
3d5a04a9e1d2 drm/i915/gvt: don't dereference 'workload' before null checking it

== Logs ==

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.

[Ville Syrjälä]

On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote:
> Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
> PSR entry.
> 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 12 
>  drivers/gpu/drm/i915/i915_drv.h |  3 +++
>  drivers/gpu/drm/i915/intel_psr.c| 21 +++--
>  3 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 669f3d56054a..d28dc4d8388e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2686,6 +2686,18 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   }
>   mutex_unlock(_priv->psr.lock);
>  
> + if (READ_ONCE(dev_priv->psr.debug)) {
> + unsigned int seq;
> +
> + do {
> + seq = read_seqbegin(_priv->psr.debug_lock);
> + seq_printf(m, "Last attempted entry at: %lld\n",
> +dev_priv->psr.last_entry_attempt);
> + seq_printf(m, "Last exit at: %lld\n",
> +dev_priv->psr.last_exit);
> + } while (read_seqretry(_priv->psr.debug_lock, seq));

What does the seqlock buy us?

> + }
> +
>   intel_runtime_pm_put(dev_priv);
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 136fa2267a66..b8170882e1ab 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -609,6 +609,9 @@ struct i915_psr {
>   bool alpm;
>   bool has_hw_tracking;
>   bool debug;
> + ktime_t last_entry_attempt;
> + ktime_t last_exit;
> + seqlock_t debug_lock;
>  
>   void (*enable_source)(struct intel_dp *,
> const struct intel_crtc_state *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 64ecea80438d..a83d95b1b587 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct drm_i915_private 
> *dev_priv, u32 psr_iir)
>  {
>   u32 transcoders = BIT(TRANSCODER_EDP);
>   enum transcoder cpu_transcoder;
> + ktime_t time_ns =  ktime_get();
> + unsigned long flags = 0;
>  
>   if (INTEL_GEN(dev_priv) >= 8)
>   transcoders |= BIT(TRANSCODER_A) |
>  BIT(TRANSCODER_B) |
>  BIT(TRANSCODER_C);
>  
> + write_seqlock_irqsave(_priv->psr.debug_lock, flags);
>   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
> + bool handled = false;
> +
> + /* PSR supported only on one transcoder currently */
> + WARN_ON_ONCE(handled);
> +
>   /* FIXME: Exit PSR when this happens. */
> - if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> + if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> + handled = true;
>   DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
> transcoder_name(cpu_transcoder));
>  
> + }
> +
>   if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> - DRM_DEBUG_KMS("[transcoder %s] PSR entry in 2 
> vblanks\n",
> + handled = true;
> + dev_priv->psr.last_entry_attempt = time_ns;
> + DRM_DEBUG_KMS("[transcoder %s] PSR entry attempt in 2 
> vblanks\n",
> transcoder_name(cpu_transcoder));
>   }
>  
>   if (psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> + handled = true;
> + dev_priv->psr.last_exit = time_ns;
>   DRM_DEBUG_KMS("[transcoder %s] PSR exit completed\n",
> transcoder_name(cpu_transcoder));
>   }
>   }
> + write_sequnlock_irqrestore(_priv->psr.debug_lock, flags);
>  }
>  
>  static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> @@ -1160,6 +1176,7 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
>  
>   INIT_DELAYED_WORK(_priv->psr.work, intel_psr_work);
>   mutex_init(_priv->psr.lock);
> + seqlock_init(_priv->psr.debug_lock);
>  
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   dev_priv->psr.enable_source = vlv_psr_enable_source;
> -- 
> 2.14.1

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/psr: Control PSR interrupts via debugfs

[Ville Syrjälä]

On Tue, Mar 20, 2018 at 03:41:50PM -0700, Dhinakaran Pandiyan wrote:
> Interrupts other than the one for AUX errors are required only for debug,
> so unmask them via debugfs when the user requests debug.
> 
> User can make such a request with
> echo 1 > /dri/0/i915_edp_psr_debug
> 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_irq.c | 68 
> -
>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
>  drivers/gpu/drm/i915/intel_psr.c| 56 ++
>  5 files changed, 123 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 964ea1a12357..669f3d56054a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   return 0;
>  }
>  
> +static int
> +i915_edp_psr_debug_set(void *data, u64 val)
> +{
> + struct drm_i915_private *dev_priv = data;
> +
> + if (!CAN_PSR(dev_priv))
> + return -ENODEV;
> +
> + if (val < 0  || val > 1)
> + return -EINVAL;
> +
> + DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : "Disabling");
> + intel_psr_debug_control(dev_priv, val);
> +
> + return 0;
> +}
> +
> +static int
> +i915_edp_psr_debug_get(void *data, u64 *val)
> +{
> + struct drm_i915_private *dev_priv = data;
> +
> + if (!CAN_PSR(dev_priv))
> + return -ENODEV;
> +
> + *val = READ_ONCE(dev_priv->psr.debug);
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> + i915_edp_psr_debug_get, i915_edp_psr_debug_set,
> + "%llu\n");
> +
>  static int i915_sink_crc(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -4811,7 +4844,8 @@ static const struct i915_debugfs_files {
>   {"i915_guc_log_relay", _guc_log_relay_fops},
>   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
>   {"i915_ipc_status", _ipc_status_fops},
> - {"i915_drrs_ctl", _drrs_ctl_fops}
> + {"i915_drrs_ctl", _drrs_ctl_fops},
> + {"i915_edp_psr_debug", _edp_psr_debug_fops}
>  };
>  
>  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e27ba8fb64e6..136fa2267a66 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -608,6 +608,7 @@ struct i915_psr {
>   bool colorimetry_support;
>   bool alpm;
>   bool has_hw_tracking;
> + bool debug;
>  
>   void (*enable_source)(struct intel_dp *,
> const struct intel_crtc_state *);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 56228e8ed980..94941b52f1cf 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2392,40 +2392,6 @@ static void ilk_display_irq_handler(struct 
> drm_i915_private *dev_priv,
>   ironlake_rps_change_irq_handler(dev_priv);
>  }
>  
> -static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> -{
> - u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> - u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> - u32 mask = BIT(TRANSCODER_EDP);
> - enum transcoder cpu_transcoder;
> -
> - if (INTEL_GEN(dev_priv) >= 8)
> - mask |= BIT(TRANSCODER_A) |
> - BIT(TRANSCODER_B) |
> - BIT(TRANSCODER_C);
> -
> - for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
> - if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> - DRM_DEBUG_KMS("Transcoder %s PSR error\n",
> -   transcoder_name(cpu_transcoder));
> -
> - if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> - DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2 
> vblanks\n",
> -   transcoder_name(cpu_transcoder));
> - edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
> - }
> -
> - if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> - DRM_DEBUG_KMS("Transcoder %s PSR exit completed\n",
> -   transcoder_name(cpu_transcoder));
> - edp_psr_imr &= ~EDP_PSR_PRE_ENTRY(cpu_transcoder);
> - }
> - }
> -
> - I915_WRITE(EDP_PSR_IMR, edp_psr_imr);
> - I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> -}
> -
>  static void ivb_display_irq_handler(struct drm_i915_private 

Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

[Oscar Mateo]

On 3/21/2018 3:16 AM, Chris Wilson wrote:

Quoting Oscar Mateo (2018-03-20 18:43:45)


On 3/19/2018 7:14 AM, Lis, Tomasz wrote:


On 2018-03-19 13:43, Chris Wilson wrote:

Quoting Tomasz Lis (2018-03-19 12:37:35)

The patch adds a parameter to control the data port coherency
functionality
on a per-exec call basis. When data port coherency flag value is
different
than what it was in previous call for the context, a command to
switch data
port coherency state is added before the buffer to be executed.

So this is part of the context? Why do it at exec level?

It is part of the context, stored within HDC chicken bit register.
The exec level was requested by the OCL team, due to concerns about
performance cost of context setparam calls.


   If exec level
is desired, why not whitelist it?
-Chris

If we have no issue in whitelisting the register, I'm sure OCL will
agree to that.
I assumed the whitelisting will be unacceptable because of security
concerns with some options.
The register also changes its position and content between gens, which
makes whitelisting hard to manage.


I think a security analysis of this register was already done, and the
result was that it contains some other bits that could be dangerous. In
CNL those bits were moved out of the way and the HDC_CHICKEN0 register
can be whitelisted (WaAllowUMDToControlCoherency). In ICL the register
should already be non-privileged.

The previous alternative to whitelisting was running through a command
parser for validation. That's a very general mechanism suitable for a
wide range of sins.
-Chris


Are you suggesting that we enable the cmd parser for every Gen < CNL for 
this particular usage only? :P


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

Re: [Intel-gfx] [PATCH] drm/i915: Rework FBC schedule locking

[Paulo Zanoni]

Em Sex, 2018-03-16 às 16:01 +0100, Maarten Lankhorst escreveu:
> Instead of taking fbc->lock inside the worker, don't take any lock
> and cancel the work synchronously to prevent races. Since the worker
> waits for a vblank before activating, wake up all vblank waiters
> after
> signalling the cancel through unsetting work->scheduled_vblank. This
> will make sure that we don't wait too long when cancelling the
> activation.
> 

Ok, so this patch changes stuff and above is a description of what is
changing, but why is this done and how does this solve the bug
referenced? What is the real problem here? Please improve the commit
message: it not only helps future git log readers, but it also helps
reviewers like me understand where you're trying to get. I'm lost here.


> Signed-off-by: Maarten Lankhorst 
> Cc: Paulo Zanoni 
> Cc: Rodrigo Vivi 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103167
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  4 +-
>  drivers/gpu/drm/i915/i915_drv.h |  3 +-
>  drivers/gpu/drm/i915/intel_fbc.c| 76 ---
> --
>  3 files changed, 36 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 98e169636f86..cbf5504de183 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1643,9 +1643,9 @@ static int i915_fbc_status(struct seq_file *m,
> void *unused)
>   else
>   seq_printf(m, "FBC disabled: %s\n", fbc-
> >no_fbc_reason);
>  
> - if (fbc->work.scheduled)
> + if (work_busy(>work.work))
>   seq_printf(m, "FBC worker scheduled on vblank %llu,
> now %llu\n",
> -fbc->work.scheduled_vblank,
> +(u64)atomic64_read(
> >work.scheduled_vblank),
>  drm_crtc_vblank_count(>crtc->base));
>  
>   if (intel_fbc_is_active(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 9262cfb8aac2..a7a1b0453320 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -558,8 +558,7 @@ struct intel_fbc {
>   } params;
>  
>   struct intel_fbc_work {
> - bool scheduled;
> - u64 scheduled_vblank;
> + atomic64_t scheduled_vblank;
>   struct work_struct work;
>   } work;
>  
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 707d49c12638..20d45bcb6b6b 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -357,10 +357,6 @@ static bool intel_fbc_hw_is_active(struct
> drm_i915_private *dev_priv)
>  
>  static void intel_fbc_hw_activate(struct drm_i915_private *dev_priv)
>  {
> - struct intel_fbc *fbc = _priv->fbc;
> -
> - fbc->active = true;
> -
>   if (INTEL_GEN(dev_priv) >= 7)
>   gen7_fbc_activate(dev_priv);
>   else if (INTEL_GEN(dev_priv) >= 5)
> @@ -407,16 +403,13 @@ static void intel_fbc_work_fn(struct
> work_struct *__work)
>   struct intel_fbc_work *work = >work;
>   struct intel_crtc *crtc = fbc->crtc;
>   struct drm_vblank_crtc *vblank = _priv->drm.vblank[crtc-
> >pipe];
> + u64 vbl;
>  
>   if (drm_crtc_vblank_get(>base)) {
>   /* CRTC is now off, leave FBC deactivated */
> - mutex_lock(>lock);
> - work->scheduled = false;
> - mutex_unlock(>lock);
>   return;
>   }
>  
> -retry:
>   /* Delay the actual enabling to let pageflipping cease and
> the
>* display to settle before starting the compression. Note
> that
>* this delay also serves a second purpose: it allows for a
> @@ -425,34 +418,35 @@ static void intel_fbc_work_fn(struct
> work_struct *__work)
>*
>* WaFbcWaitForVBlankBeforeEnable:ilk,snb
>*
> -  * It is also worth mentioning that since work-
> >scheduled_vblank can be
> -  * updated multiple times by the other threads, hitting the
> timeout is
> -  * not an error condition. We'll just end up hitting the
> "goto retry"
> -  * case below.
> +  * This may be killed by unsetting scheduled_vblank, in
> which
> +  * case we return early without activating.
>*/
>   wait_event_timeout(vblank->queue,
> - drm_crtc_vblank_count(>base) != work-
> >scheduled_vblank,
> + !(vbl = atomic64_read(>scheduled_vblank)) ||
> vbl != drm_crtc_vblank_count(>base),
>   msecs_to_jiffies(50));
>  
> - mutex_lock(>lock);
> + if (vbl)
> + intel_fbc_hw_activate(dev_priv);
>  

We can't call this without fbc->lock locked.


> - /* Were we cancelled? */
> - if (!work->scheduled)
> - goto out;
> + drm_crtc_vblank_put(>base);
> +}
>  
> - /* Were we delayed again while this 

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

[Ville Syrjälä]

On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > From: Daniel Vetter 
> > > 
> > > The definitions for the error register should be valid on bdw/skl too,
> > > but there we haven't even enabled DE_MISC handling yet.
> > > 
> > > Somewhat confusing the the moved register offset on bdw is only for
> > > the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> > > on bdw.
> > > 
> > > v2: Fixes from Ville.
> > > 
> > > v3: From DK
> > >  * Rebased on drm-tip
> > >  * Removed BDW IIR bit definition, looks like an unintentional change that
> > > should be in the following patch.
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: Rodrigo Vivi 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Daniel Vetter 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/i915_irq.c  | 34 ++
> > >  drivers/gpu/drm/i915/i915_reg.h  |  8 
> > >  drivers/gpu/drm/i915/intel_psr.c |  3 ++-
> > >  3 files changed, 44 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 44eef355e12c..e94a835b7515 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct 
> > > drm_i915_private *dev_priv,
> > >   ironlake_rps_change_irq_handler(dev_priv);
> > >  }
> > >  
> > > +static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > > +{
> > > + u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > > +
> > > + if (edp_psr_iir & EDP_PSR_ERROR)
> > > + DRM_DEBUG_KMS("PSR error\n");
> > > +
> > > + if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > > + DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > 
> > I doubt we want to have the entry/exit interrupts generate all this
> > noise in dmesg all the time. We should probably only enable the
> > interrupts for testing. The error interrupt I suppose we want always,
> > might even want DRM_ERROR on it.
> 
> I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.

Right. It's a bit hard to read this with stuff getting
added/remove/moved more or less randomly.

> 
> > 
> > > + I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > > + }
> > > +
> > > + if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > > + DRM_DEBUG_KMS("PSR exit completed\n");
> > > + I915_WRITE(EDP_PSR_IMR, 0);
> > > + }
> > > +
> > > + I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > > +}
> > > +
> > >  static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
> > >   u32 de_iir)
> > >  {
> > > @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct 
> > > drm_i915_private *dev_priv,
> > >   if (de_iir & DE_ERR_INT_IVB)
> > >   ivb_err_int_handler(dev_priv);
> > >  
> > > + if (de_iir & DE_EDP_PSR_INT_HSW)
> > > + hsw_edp_psr_irq_handler(dev_priv);
> > > +
> > >   if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > >   dp_aux_irq_handler(dev_priv);
> > >  
> > > @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct drm_device 
> > > *dev)
> > >   if (IS_GEN7(dev_priv))
> > >   I915_WRITE(GEN7_ERR_INT, 0x);
> > >  
> > > + if (IS_HASWELL(dev_priv)) {
> > > + I915_WRITE(EDP_PSR_IMR, 0x);
> > > + I915_WRITE(EDP_PSR_IIR, 0x);
> > > + }
> > > +
> > >   gen5_gt_irq_reset(dev_priv);
> > >  
> > >   ibx_irq_reset(dev_priv);
> > > @@ -3663,6 +3691,12 @@ static int ironlake_irq_postinstall(struct 
> > > drm_device *dev)
> > > DE_DP_A_HOTPLUG);
> > >   }
> > >  
> > > + if (IS_HASWELL(dev_priv)) {
> > > + gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> > > + I915_WRITE(EDP_PSR_IMR, 0);
> > > + display_mask |= DE_EDP_PSR_INT_HSW;
> > > + }
> > > +
> > >   dev_priv->irq_mask = ~display_mask;
> > >  
> > >   ibx_irq_pre_postinstall(dev);
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 1e000f3004cb..3447f03eac3d 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -3828,6 +3828,13 @@ enum {
> > >  #define   EDP_PSR_TP1_TIME_0us   (3<<4)
> > >  #define   EDP_PSR_IDLE_FRAME_SHIFT   0
> > >  
> > > +/* Bspec claims those aren't shifted but stay at 0x64800 */
> > > +#define EDP_PSR_IMR  _MMIO(0x64834)
> > > +#define EDP_PSR_IIR  _MMIO(0x64838)
> > > +#define   EDP_PSR_ERROR  (1<<2)
> > > +#define   EDP_PSR_POST_EXIT  (1<<1)
> > > +#define   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Stress resets-vs-request-priority

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Stress resets-vs-request-priority
URL   : https://patchwork.freedesktop.org/series/40397/
State : success

== Summary ==

Series 40397v1 drm/i915/selftests: Stress resets-vs-request-priority
https://patchwork.freedesktop.org/api/1.0/series/40397/revisions/1/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-bxt-dsi)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:515s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:502s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:523s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:587s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:315s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:533s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:656s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:437s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:512s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:555s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:397s

d1aafb635a5ff976b7b3164a6aff86f29871d415 drm-tip: 2018y-03m-21d-17h-25m-04s UTC 
integration manifest
db8550b31cc9 drm/i915/selftests: Stress resets-vs-request-priority

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

[Colin Ian King]

On 21/03/18 19:23, Chris Wilson wrote:
> Quoting Colin Ian King (2018-03-21 19:18:28)
>> On 21/03/18 19:09, Joe Perches wrote:
>>> On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
 From: Colin Ian King 

 The pointer workload is dereferenced before it is null checked, hence
 there is a potential for a null pointer dereference on workload. Fix
 this by only dereferencing workload after it is null checked.

 Detected by CoverityScan, CID#1466017 ("Dereference before null check")
>>>
>>> Maybe true, but is it possible for workload to be null?
>>> Maybe the null test should be removed instead.
>>
>> From what I understand from the static analysis, there may be a
>> potential for workload to be null, I couldn't rule it out so I went with
>> the more paranoid stance of keeping the null check in.
> 
> Not sr_oa_regs() problem if workload is NULL, that's the callers. I
> reviewed the identical patch yesterday, and we ended up with removing
> the NULL checks, just keeping the workload->id != RCS.
> -Chris
> 
Ah, OK, thanks for the clarification Chris.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

[Joe Perches]

On Wed, 2018-03-21 at 19:18 +, Colin Ian King wrote:
> On 21/03/18 19:09, Joe Perches wrote:
> > On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> > > From: Colin Ian King 
> > > 
> > > The pointer workload is dereferenced before it is null checked, hence
> > > there is a potential for a null pointer dereference on workload. Fix
> > > this by only dereferencing workload after it is null checked.
> > > 
> > > Detected by CoverityScan, CID#1466017 ("Dereference before null check")
> > 
> > Maybe true, but is it possible for workload to be null?
> > Maybe the null test should be removed instead.
> 
> From what I understand from the static analysis, there may be a
> potential for workload to be null, I couldn't rule it out so I went with
> the more paranoid stance of keeping the null check in.

workload cannot be null here.

Look at the uses of sr_oa_regs and see that
workload has already been dereferenced.

> > 
> > > Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> > > Signed-off-by: Colin Ian King 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
> > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> > > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > index 068126404151..f3010e365a48 100644
> > > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > @@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
> > >  static void sr_oa_regs(struct intel_vgpu_workload *workload,
> > >   u32 *reg_state, bool save)
> > >  {
> > > - struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> > > - u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> > > - u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> > > + struct drm_i915_private *dev_priv;
> > > + u32 ctx_oactxctrl;
> > > + u32 ctx_flexeu0;
> > >   int i = 0;
> > >   u32 flex_mmio[] = {
> > >   i915_mmio_reg_offset(EU_PERF_CNTL0),
> > > @@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload 
> > > *workload,
> > >   if (!workload || !reg_state || workload->ring_id != RCS)
> > >   return;
> > >  
> > > + dev_priv = workload->vgpu->gvt->dev_priv;
> > > + ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> > > + ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> > > +
> > >   if (save) {
> > >   workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
> > >  
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

[Chris Wilson]

Quoting Colin Ian King (2018-03-21 19:18:28)
> On 21/03/18 19:09, Joe Perches wrote:
> > On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> >> From: Colin Ian King 
> >>
> >> The pointer workload is dereferenced before it is null checked, hence
> >> there is a potential for a null pointer dereference on workload. Fix
> >> this by only dereferencing workload after it is null checked.
> >>
> >> Detected by CoverityScan, CID#1466017 ("Dereference before null check")
> > 
> > Maybe true, but is it possible for workload to be null?
> > Maybe the null test should be removed instead.
> 
> From what I understand from the static analysis, there may be a
> potential for workload to be null, I couldn't rule it out so I went with
> the more paranoid stance of keeping the null check in.

Not sr_oa_regs() problem if workload is NULL, that's the callers. I
reviewed the identical patch yesterday, and we ended up with removing
the NULL checks, just keeping the workload->id != RCS.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: move dpll_info to header

[Lucas De Marchi]

On Wed, Mar 21, 2018 at 12:25:40PM +0200, Ville Syrjälä wrote:
> > > This structure seems to be poorly organized for 64bit machines.
> > 
> > 
> > Yes, there's a 4-bytes  right there.  Fixing this unfortunately
> > involves changing
> > all tables inside dpll_mgr.c.
> 
> Those aren't using named initializers?

No. Most of the tables aren't using named initializers. On v2 of the
patch set I did the reordering, but without adding named initializers.

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

[Pandiyan, Dhinakaran]

On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > From: Daniel Vetter 
> > 
> > The definitions for the error register should be valid on bdw/skl too,
> > but there we haven't even enabled DE_MISC handling yet.
> > 
> > Somewhat confusing the the moved register offset on bdw is only for
> > the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> > on bdw.
> > 
> > v2: Fixes from Ville.
> > 
> > v3: From DK
> >  * Rebased on drm-tip
> >  * Removed BDW IIR bit definition, looks like an unintentional change that
> > should be in the following patch.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Daniel Vetter 
> > Signed-off-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c  | 34 ++
> >  drivers/gpu/drm/i915/i915_reg.h  |  8 
> >  drivers/gpu/drm/i915/intel_psr.c |  3 ++-
> >  3 files changed, 44 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 44eef355e12c..e94a835b7515 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > +static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > +{
> > +   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > +
> > +   if (edp_psr_iir & EDP_PSR_ERROR)
> > +   DRM_DEBUG_KMS("PSR error\n");
> > +
> > +   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > +   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> 
> I doubt we want to have the entry/exit interrupts generate all this
> noise in dmesg all the time. We should probably only enable the
> interrupts for testing. The error interrupt I suppose we want always,
> might even want DRM_ERROR on it.

I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.

> 
> > +   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > +   }
> > +
> > +   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > +   DRM_DEBUG_KMS("PSR exit completed\n");
> > +   I915_WRITE(EDP_PSR_IMR, 0);
> > +   }
> > +
> > +   I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > +}
> > +
> >  static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
> > u32 de_iir)
> >  {
> > @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > if (de_iir & DE_ERR_INT_IVB)
> > ivb_err_int_handler(dev_priv);
> >  
> > +   if (de_iir & DE_EDP_PSR_INT_HSW)
> > +   hsw_edp_psr_irq_handler(dev_priv);
> > +
> > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > dp_aux_irq_handler(dev_priv);
> >  
> > @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct drm_device 
> > *dev)
> > if (IS_GEN7(dev_priv))
> > I915_WRITE(GEN7_ERR_INT, 0x);
> >  
> > +   if (IS_HASWELL(dev_priv)) {
> > +   I915_WRITE(EDP_PSR_IMR, 0x);
> > +   I915_WRITE(EDP_PSR_IIR, 0x);
> > +   }
> > +
> > gen5_gt_irq_reset(dev_priv);
> >  
> > ibx_irq_reset(dev_priv);
> > @@ -3663,6 +3691,12 @@ static int ironlake_irq_postinstall(struct 
> > drm_device *dev)
> >   DE_DP_A_HOTPLUG);
> > }
> >  
> > +   if (IS_HASWELL(dev_priv)) {
> > +   gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> > +   I915_WRITE(EDP_PSR_IMR, 0);
> > +   display_mask |= DE_EDP_PSR_INT_HSW;
> > +   }
> > +
> > dev_priv->irq_mask = ~display_mask;
> >  
> > ibx_irq_pre_postinstall(dev);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 1e000f3004cb..3447f03eac3d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3828,6 +3828,13 @@ enum {
> >  #define   EDP_PSR_TP1_TIME_0us (3<<4)
> >  #define   EDP_PSR_IDLE_FRAME_SHIFT 0
> >  
> > +/* Bspec claims those aren't shifted but stay at 0x64800 */
> > +#define EDP_PSR_IMR_MMIO(0x64834)
> > +#define EDP_PSR_IIR_MMIO(0x64838)
> > +#define   EDP_PSR_ERROR(1<<2)
> > +#define   EDP_PSR_POST_EXIT(1<<1)
> > +#define   EDP_PSR_PRE_ENTRY(1<<0)
> > +
> >  #define EDP_PSR_AUX_CTL
> > _MMIO(dev_priv->psr_mmio_base + 0x10)
> >  #define EDP_PSR_AUX_DATA(i)
> > _MMIO(dev_priv->psr_mmio_base + 0x14 + (i) * 4) /* 5 registers */
> >  
> > @@ -6628,6 +6635,7 @@ enum {
> >  #define 

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

[Colin Ian King]

On 21/03/18 19:09, Joe Perches wrote:
> On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
>> From: Colin Ian King 
>>
>> The pointer workload is dereferenced before it is null checked, hence
>> there is a potential for a null pointer dereference on workload. Fix
>> this by only dereferencing workload after it is null checked.
>>
>> Detected by CoverityScan, CID#1466017 ("Dereference before null check")
> 
> Maybe true, but is it possible for workload to be null?
> Maybe the null test should be removed instead.

From what I understand from the static analysis, there may be a
potential for workload to be null, I couldn't rule it out so I went with
the more paranoid stance of keeping the null check in.

> 
>> Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
>> b/drivers/gpu/drm/i915/gvt/scheduler.c
>> index 068126404151..f3010e365a48 100644
>> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
>> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
>> @@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
>>  static void sr_oa_regs(struct intel_vgpu_workload *workload,
>>  u32 *reg_state, bool save)
>>  {
>> -struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
>> -u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>> -u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>> +struct drm_i915_private *dev_priv;
>> +u32 ctx_oactxctrl;
>> +u32 ctx_flexeu0;
>>  int i = 0;
>>  u32 flex_mmio[] = {
>>  i915_mmio_reg_offset(EU_PERF_CNTL0),
>> @@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload 
>> *workload,
>>  if (!workload || !reg_state || workload->ring_id != RCS)
>>  return;
>>  
>> +dev_priv = workload->vgpu->gvt->dev_priv;
>> +ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>> +ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>> +
>>  if (save) {
>>  workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
>>  

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

[Intel-gfx] [PATCH] drm/i915: Use full serialisation around engine->irq_posted

[Chris Wilson]

Using engine->irq_posted for execlists, we are not always serialised by
the tasklet as we supposed. On the reset paths, the tasklet is disabled
and ignored. Instead, we manipulate the engine->irq_posted directly to
account for the reset, but if an interrupt fired before the reset and so
wrote to engine->irq_posted, that write may not be flushed from the
local CPU's cacheline until much later as the tasklet is already active
and so does not generate a mb(). To correctly serialise the interrupt
with reset, we need serialisation on the set_bit() itself.

And at last Mika can be happy.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fa7310766217..27aee25429b7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1405,10 +1405,9 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir)
bool tasklet = false;
 
if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
-   if (READ_ONCE(engine->execlists.active)) {
-   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
-   tasklet = true;
-   }
+   if (READ_ONCE(engine->execlists.active))
+   tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
+   >irq_posted);
}
 
if (iir & GT_RENDER_USER_INTERRUPT) {
-- 
2.16.2

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Stress resets-vs-request-priority

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Stress resets-vs-request-priority
URL   : https://patchwork.freedesktop.org/series/40397/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
db8550b31cc9 drm/i915/selftests: Stress resets-vs-request-priority
-:272: CHECK:SPACING: spaces preferred around that '|' (ctx:VxW)
#272: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:847:
+   TEST_OTHERS | TEST_ACTIVE | TEST_PRIORITY| TEST_SELF,
 ^

total: 0 errors, 0 warnings, 1 checks, 279 lines checked

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

[Joe Perches]

On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> From: Colin Ian King 
> 
> The pointer workload is dereferenced before it is null checked, hence
> there is a potential for a null pointer dereference on workload. Fix
> this by only dereferencing workload after it is null checked.
> 
> Detected by CoverityScan, CID#1466017 ("Dereference before null check")

Maybe true, but is it possible for workload to be null?
Maybe the null test should be removed instead.

> Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 068126404151..f3010e365a48 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
>  static void sr_oa_regs(struct intel_vgpu_workload *workload,
>   u32 *reg_state, bool save)
>  {
> - struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> - u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> - u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> + struct drm_i915_private *dev_priv;
> + u32 ctx_oactxctrl;
> + u32 ctx_flexeu0;
>   int i = 0;
>   u32 flex_mmio[] = {
>   i915_mmio_reg_offset(EU_PERF_CNTL0),
> @@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload 
> *workload,
>   if (!workload || !reg_state || workload->ring_id != RCS)
>   return;
>  
> + dev_priv = workload->vgpu->gvt->dev_priv;
> + ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> + ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> +
>   if (save) {
>   workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

[Colin King]

From: Colin Ian King 

The pointer workload is dereferenced before it is null checked, hence
there is a potential for a null pointer dereference on workload. Fix
this by only dereferencing workload after it is null checked.

Detected by CoverityScan, CID#1466017 ("Dereference before null check")

Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 068126404151..f3010e365a48 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
 static void sr_oa_regs(struct intel_vgpu_workload *workload,
u32 *reg_state, bool save)
 {
-   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
-   u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
-   u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+   struct drm_i915_private *dev_priv;
+   u32 ctx_oactxctrl;
+   u32 ctx_flexeu0;
int i = 0;
u32 flex_mmio[] = {
i915_mmio_reg_offset(EU_PERF_CNTL0),
@@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload *workload,
if (!workload || !reg_state || workload->ring_id != RCS)
return;
 
+   dev_priv = workload->vgpu->gvt->dev_priv;
+   ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
+   ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+
if (save) {
workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
 
-- 
2.15.1

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

Re: [Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

[Chris Wilson]

Quoting Chris Wilson (2018-03-21 18:12:51)
> Quoting Jeff McGee (2018-03-21 17:31:45)
> > On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee 
> > > 
> > > Engine reset is fast. A context switch interrupt may be generated just
> > > prior to the reset such that the top half handler is racing with reset
> > > post-processing. The handler may set the irq_posted bit again after
> > > the reset code has cleared it to start fresh. Then the re-enabled
> > > tasklet will read the CSB head and tail from MMIO, which will be at
> > > the hardware reset values of 0 and 7 respectively, given that no
> > > actual CSB event has occurred since the reset. Mayhem then ensues as
> > > the tasklet starts processing invalid CSB entries.
> > > 
> > > We can handle this corner case without adding any new synchronization
> > > between the irq top half and the reset work item. The tasklet can
> > > just skip CSB processing if the tail is not sane.
> > > 
> > > Signed-off-by: Jeff McGee 
> > > ---
> > If I drop this patch and substitute 
> > https://patchwork.freedesktop.org/patch/211831/
> > I will see irq_posted get set after reset which causes the first tasklet
> > run to re-process a previous CSB event and hit GEM_BUG_ON that nothing
> > was active.
> 
> However, for reset+sync to be followed by an interrupt is surprising.
> What more do we need to do after the reset to flush the last interrupt?

Actually, it may not be a late interrupt, just a late cacheline flush
from one processor to another. __set_bit bites.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

[Chris Wilson]

Quoting Jeff McGee (2018-03-21 18:29:46)
> On Wed, Mar 21, 2018 at 06:06:44PM +, Chris Wilson wrote:
> > Quoting Jeff McGee (2018-03-21 17:33:04)
> > > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> > > > From: Jeff McGee 
> > > > 
> > > > Signed-off-by: Jeff McGee 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > > index beb81f13a3cc..cec4e1653daf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > > @@ -1009,7 +1009,7 @@ static void execlists_submission_tasklet(unsigned 
> > > > long data)
> > > >* imposing the cost of a locked atomic transaction when 
> > > > submitting a
> > > >* new request (outside of the context-switch interrupt).
> > > >*/
> > > > - if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
> > > > + while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
> > > Assuming that this accidentally went missing in the refactor. Chris?
> > 
> > No. process_csb became a do{} while. The caller did a test_bit to avoid
> > the function call for normal rescheduling paths.
> > -Chris
> 
> But there is no loop in process_csb().

There is in my copy. I was trying different things and removing the loop
masked a different issue with tasklet scheduling. Strictly we don't need
a loop here as we will always be re-run following an interrupt. But since
we may need to grab forcewake and whatnot, it seems prudent to keep the
loop around.
-Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

[Ville Syrjälä]

On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> From: Daniel Vetter 
> 
> The definitions for the error register should be valid on bdw/skl too,
> but there we haven't even enabled DE_MISC handling yet.
> 
> Somewhat confusing the the moved register offset on bdw is only for
> the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> on bdw.
> 
> v2: Fixes from Ville.
> 
> v3: From DK
>  * Rebased on drm-tip
>  * Removed BDW IIR bit definition, looks like an unintentional change that
> should be in the following patch.
> 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 
> Cc: Daniel Vetter 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_irq.c  | 34 ++
>  drivers/gpu/drm/i915/i915_reg.h  |  8 
>  drivers/gpu/drm/i915/intel_psr.c |  3 ++-
>  3 files changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 44eef355e12c..e94a835b7515 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct 
> drm_i915_private *dev_priv,
>   ironlake_rps_change_irq_handler(dev_priv);
>  }
>  
> +static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> +{
> + u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> +
> + if (edp_psr_iir & EDP_PSR_ERROR)
> + DRM_DEBUG_KMS("PSR error\n");
> +
> + if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> + DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");

I doubt we want to have the entry/exit interrupts generate all this
noise in dmesg all the time. We should probably only enable the
interrupts for testing. The error interrupt I suppose we want always,
might even want DRM_ERROR on it.

> + I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> + }
> +
> + if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> + DRM_DEBUG_KMS("PSR exit completed\n");
> + I915_WRITE(EDP_PSR_IMR, 0);
> + }
> +
> + I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> +}
> +
>  static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
>   u32 de_iir)
>  {
> @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct 
> drm_i915_private *dev_priv,
>   if (de_iir & DE_ERR_INT_IVB)
>   ivb_err_int_handler(dev_priv);
>  
> + if (de_iir & DE_EDP_PSR_INT_HSW)
> + hsw_edp_psr_irq_handler(dev_priv);
> +
>   if (de_iir & DE_AUX_CHANNEL_A_IVB)
>   dp_aux_irq_handler(dev_priv);
>  
> @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct drm_device *dev)
>   if (IS_GEN7(dev_priv))
>   I915_WRITE(GEN7_ERR_INT, 0x);
>  
> + if (IS_HASWELL(dev_priv)) {
> + I915_WRITE(EDP_PSR_IMR, 0x);
> + I915_WRITE(EDP_PSR_IIR, 0x);
> + }
> +
>   gen5_gt_irq_reset(dev_priv);
>  
>   ibx_irq_reset(dev_priv);
> @@ -3663,6 +3691,12 @@ static int ironlake_irq_postinstall(struct drm_device 
> *dev)
> DE_DP_A_HOTPLUG);
>   }
>  
> + if (IS_HASWELL(dev_priv)) {
> + gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> + I915_WRITE(EDP_PSR_IMR, 0);
> + display_mask |= DE_EDP_PSR_INT_HSW;
> + }
> +
>   dev_priv->irq_mask = ~display_mask;
>  
>   ibx_irq_pre_postinstall(dev);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1e000f3004cb..3447f03eac3d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3828,6 +3828,13 @@ enum {
>  #define   EDP_PSR_TP1_TIME_0us   (3<<4)
>  #define   EDP_PSR_IDLE_FRAME_SHIFT   0
>  
> +/* Bspec claims those aren't shifted but stay at 0x64800 */
> +#define EDP_PSR_IMR  _MMIO(0x64834)
> +#define EDP_PSR_IIR  _MMIO(0x64838)
> +#define   EDP_PSR_ERROR  (1<<2)
> +#define   EDP_PSR_POST_EXIT  (1<<1)
> +#define   EDP_PSR_PRE_ENTRY  (1<<0)
> +
>  #define EDP_PSR_AUX_CTL  
> _MMIO(dev_priv->psr_mmio_base + 0x10)
>  #define EDP_PSR_AUX_DATA(i)  _MMIO(dev_priv->psr_mmio_base + 
> 0x14 + (i) * 4) /* 5 registers */
>  
> @@ -6628,6 +6635,7 @@ enum {
>  #define DE_PCH_EVENT_IVB (1<<28)
>  #define DE_DP_A_HOTPLUG_IVB  (1<<27)
>  #define DE_AUX_CHANNEL_A_IVB (1<<26)
> +#define DE_EDP_PSR_INT_HSW   (1<<19)
>  #define DE_SPRITEC_FLIP_DONE_IVB (1<<14)
>  #define DE_PLANEC_FLIP_DONE_IVB  (1<<13)
>  #define DE_PIPEC_VBLANK_IVB  (1<<10)
> diff --git 

[Intel-gfx] [PATCH] drm/i915/selftests: Stress resets-vs-request-priority

[Chris Wilson]

Watch what happens if we try to reset with a queue of requests with
varying priorities -- that may need reordering or preemption across the
reset.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 154 +++
 1 file changed, 103 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 1969a65072ca..7277054450f8 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -25,6 +25,7 @@
 #include 
 
 #include "../i915_selftest.h"
+#include "i915_random.h"
 
 #include "mock_context.h"
 #include "mock_drm.h"
@@ -576,11 +577,25 @@ static int igt_reset_active_engine(void *arg)
return __igt_reset_engine(arg, true);
 }
 
+struct active_engine {
+   struct task_struct *task;
+   struct intel_engine_cs *engine;
+   unsigned long resets;
+   unsigned int flags;
+};
+
+#define TEST_ACTIVEBIT(0)
+#define TEST_OTHERSBIT(1)
+#define TEST_SELF  BIT(2)
+#define TEST_PRIORITY  BIT(3)
+
 static int active_engine(void *data)
 {
-   struct intel_engine_cs *engine = data;
-   struct i915_request *rq[2] = {};
-   struct i915_gem_context *ctx[2];
+   I915_RND_STATE(prng);
+   struct active_engine *arg = data;
+   struct intel_engine_cs *engine = arg->engine;
+   struct i915_request *rq[8] = {};
+   struct i915_gem_context *ctx[ARRAY_SIZE(rq)];
struct drm_file *file;
unsigned long count = 0;
int err = 0;
@@ -589,25 +604,20 @@ static int active_engine(void *data)
if (IS_ERR(file))
return PTR_ERR(file);
 
-   mutex_lock(>i915->drm.struct_mutex);
-   ctx[0] = live_context(engine->i915, file);
-   mutex_unlock(>i915->drm.struct_mutex);
-   if (IS_ERR(ctx[0])) {
-   err = PTR_ERR(ctx[0]);
-   goto err_file;
-   }
-
-   mutex_lock(>i915->drm.struct_mutex);
-   ctx[1] = live_context(engine->i915, file);
-   mutex_unlock(>i915->drm.struct_mutex);
-   if (IS_ERR(ctx[1])) {
-   err = PTR_ERR(ctx[1]);
-   i915_gem_context_put(ctx[0]);
-   goto err_file;
+   for (count = 0; count < ARRAY_SIZE(ctx); count++) {
+   mutex_lock(>i915->drm.struct_mutex);
+   ctx[count] = live_context(engine->i915, file);
+   mutex_unlock(>i915->drm.struct_mutex);
+   if (IS_ERR(ctx[count])) {
+   err = PTR_ERR(ctx[count]);
+   while (--count)
+   i915_gem_context_put(ctx[count]);
+   goto err_file;
+   }
}
 
while (!kthread_should_stop()) {
-   unsigned int idx = count++ & 1;
+   unsigned int idx = count++ & (ARRAY_SIZE(rq) - 1);
struct i915_request *old = rq[idx];
struct i915_request *new;
 
@@ -619,6 +629,10 @@ static int active_engine(void *data)
break;
}
 
+   if (arg->flags & TEST_PRIORITY)
+   ctx[idx]->priority =
+   i915_prandom_u32_max_state(512, );
+
rq[idx] = i915_request_get(new);
i915_request_add(new);
mutex_unlock(>i915->drm.struct_mutex);
@@ -647,8 +661,9 @@ static int active_engine(void *data)
return err;
 }
 
-static int __igt_reset_engine_others(struct drm_i915_private *i915,
-bool active)
+static int __igt_reset_engines(struct drm_i915_private *i915,
+  const char *test_name,
+  unsigned int flags)
 {
struct intel_engine_cs *engine, *other;
enum intel_engine_id id, tmp;
@@ -662,7 +677,7 @@ static int __igt_reset_engine_others(struct 
drm_i915_private *i915,
if (!intel_has_reset_engine(i915))
return 0;
 
-   if (active) {
+   if (flags & TEST_ACTIVE) {
mutex_lock(>drm.struct_mutex);
err = hang_init(, i915);
mutex_unlock(>drm.struct_mutex);
@@ -671,39 +686,46 @@ static int __igt_reset_engine_others(struct 
drm_i915_private *i915,
}
 
for_each_engine(engine, i915, id) {
-   struct task_struct *threads[I915_NUM_ENGINES] = {};
-   unsigned long resets[I915_NUM_ENGINES];
+   struct active_engine threads[I915_NUM_ENGINES] = {};
unsigned long global = i915_reset_count(>gpu_error);
unsigned long count = 0;
IGT_TIMEOUT(end_time);
 
-   if (active && !intel_engine_can_store_dword(engine))
+   if (flags & TEST_ACTIVE &&
+   !intel_engine_can_store_dword(engine))
continue;
 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Force preemption (rev2)

[Patchwork]

== Series Details ==

Series: Force preemption (rev2)
URL   : https://patchwork.freedesktop.org/series/40120/
State : failure

== Summary ==

Applying: drm/i915/execlists: Refactor out complete_preempt_context()
Applying: drm/i915: Add control flags to i915_handle_error()
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_debugfs.c
M   drivers/gpu/drm/i915/i915_drv.c
M   drivers/gpu/drm/i915/i915_drv.h
M   drivers/gpu/drm/i915/i915_gpu_error.h
M   drivers/gpu/drm/i915/i915_irq.c
M   drivers/gpu/drm/i915/i915_request.c
M   drivers/gpu/drm/i915/intel_hangcheck.c
M   drivers/gpu/drm/i915/selftests/intel_hangcheck.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_hangcheck.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_hangcheck.c
Patch failed at 0002 drm/i915: Add control flags to i915_handle_error()
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

[Jeff McGee]

On Wed, Mar 21, 2018 at 06:06:44PM +, Chris Wilson wrote:
> Quoting Jeff McGee (2018-03-21 17:33:04)
> > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee 
> > > 
> > > Signed-off-by: Jeff McGee 
> > > ---
> > >  drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > index beb81f13a3cc..cec4e1653daf 100644
> > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > @@ -1009,7 +1009,7 @@ static void execlists_submission_tasklet(unsigned 
> > > long data)
> > >* imposing the cost of a locked atomic transaction when submitting 
> > > a
> > >* new request (outside of the context-switch interrupt).
> > >*/
> > > - if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
> > > + while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
> > Assuming that this accidentally went missing in the refactor. Chris?
> 
> No. process_csb became a do{} while. The caller did a test_bit to avoid
> the function call for normal rescheduling paths.
> -Chris

But there is no loop in process_csb().
-Jeff
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for lib/gpgpu_fill: Adding missing configuration parameters for gpgpu_fill function

[Patchwork]

== Series Details ==

Series: lib/gpgpu_fill: Adding missing configuration parameters for gpgpu_fill 
function
URL   : https://patchwork.freedesktop.org/series/40378/
State : success

== Summary ==

 Possible new issues:

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-idle-hang:
skip   -> PASS   (shard-snb)

 Known issues:

Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060 +2
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup blocking-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368 +2
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
fail   -> PASS   (shard-apl) fdo#101623 +1
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test kms_vblank:
Subgroup pipe-a-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583

shard-apltotal:3478 pass:1814 dwarn:1   dfail:0   fail:7   skip:1655 
time:13144s
shard-hswtotal:3478 pass:1763 dwarn:1   dfail:0   fail:6   skip:1707 
time:11887s
shard-snbtotal:3478 pass:1358 dwarn:1   dfail:0   fail:2   skip:2117 
time:7264s
Blacklisted hosts:
shard-kbltotal:3432 pass:1913 dwarn:1   dfail:0   fail:9   skip:1508 
time:9403s

== Logs ==

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

Re: [Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

[Chris Wilson]

Quoting Jeff McGee (2018-03-21 17:31:45)
> On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote:
> > From: Jeff McGee 
> > 
> > Engine reset is fast. A context switch interrupt may be generated just
> > prior to the reset such that the top half handler is racing with reset
> > post-processing. The handler may set the irq_posted bit again after
> > the reset code has cleared it to start fresh. Then the re-enabled
> > tasklet will read the CSB head and tail from MMIO, which will be at
> > the hardware reset values of 0 and 7 respectively, given that no
> > actual CSB event has occurred since the reset. Mayhem then ensues as
> > the tasklet starts processing invalid CSB entries.
> > 
> > We can handle this corner case without adding any new synchronization
> > between the irq top half and the reset work item. The tasklet can
> > just skip CSB processing if the tail is not sane.
> > 
> > Signed-off-by: Jeff McGee 
> > ---
> If I drop this patch and substitute 
> https://patchwork.freedesktop.org/patch/211831/
> I will see irq_posted get set after reset which causes the first tasklet
> run to re-process a previous CSB event and hit GEM_BUG_ON that nothing
> was active.

However, for reset+sync to be followed by an interrupt is surprising.
What more do we need to do after the reset to flush the last interrupt?

What I've been trying to get right is disabling the RING_IMR across the
reset so that we do not get any new interrupts generated for this engine.
(So couple that also with a sync_irq.) We've been kicking around that
plan for yonks, since the beginning of doing per-engine reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

[Chris Wilson]

Quoting Jeff McGee (2018-03-21 17:33:04)
> On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> > From: Jeff McGee 
> > 
> > Signed-off-by: Jeff McGee 
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index beb81f13a3cc..cec4e1653daf 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1009,7 +1009,7 @@ static void execlists_submission_tasklet(unsigned 
> > long data)
> >* imposing the cost of a locked atomic transaction when submitting a
> >* new request (outside of the context-switch interrupt).
> >*/
> > - if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
> > + while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
> Assuming that this accidentally went missing in the refactor. Chris?

No. process_csb became a do{} while. The caller did a test_bit to avoid
the function call for normal rescheduling paths.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Rework FBC schedule locking

[Rodrigo Vivi]

On Fri, Mar 16, 2018 at 04:01:21PM +0100, Maarten Lankhorst wrote:
> Instead of taking fbc->lock inside the worker, don't take any lock
> and cancel the work synchronously to prevent races. Since the worker
> waits for a vblank before activating, wake up all vblank waiters after
> signalling the cancel through unsetting work->scheduled_vblank. This
> will make sure that we don't wait too long when cancelling the activation.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Paulo Zanoni 
> Cc: Rodrigo Vivi 

Overall I'm not comfortable with removing the locks on fbc activate
so I would deffer this to Paulo.

Also my own experience with atomic variables and vblank counters
weren't very positive on psr+dmc case. I always end up finding
a corner case :(

anyways few dummy questions below...

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103167
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  4 +-
>  drivers/gpu/drm/i915/i915_drv.h |  3 +-
>  drivers/gpu/drm/i915/intel_fbc.c| 76 
> -
>  3 files changed, 36 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 98e169636f86..cbf5504de183 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1643,9 +1643,9 @@ static int i915_fbc_status(struct seq_file *m, void 
> *unused)
>   else
>   seq_printf(m, "FBC disabled: %s\n", fbc->no_fbc_reason);
>  
> - if (fbc->work.scheduled)
> + if (work_busy(>work.work))
>   seq_printf(m, "FBC worker scheduled on vblank %llu, now %llu\n",
> -fbc->work.scheduled_vblank,
> +(u64)atomic64_read(>work.scheduled_vblank),
>  drm_crtc_vblank_count(>crtc->base));
>  
>   if (intel_fbc_is_active(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9262cfb8aac2..a7a1b0453320 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -558,8 +558,7 @@ struct intel_fbc {
>   } params;
>  
>   struct intel_fbc_work {
> - bool scheduled;
> - u64 scheduled_vblank;
> + atomic64_t scheduled_vblank;

Why FBC is so tied with vblanks?

>   struct work_struct work;
>   } work;
>  
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 707d49c12638..20d45bcb6b6b 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -357,10 +357,6 @@ static bool intel_fbc_hw_is_active(struct 
> drm_i915_private *dev_priv)
>  
>  static void intel_fbc_hw_activate(struct drm_i915_private *dev_priv)
>  {
> - struct intel_fbc *fbc = _priv->fbc;
> -
> - fbc->active = true;
> -
>   if (INTEL_GEN(dev_priv) >= 7)
>   gen7_fbc_activate(dev_priv);
>   else if (INTEL_GEN(dev_priv) >= 5)
> @@ -407,16 +403,13 @@ static void intel_fbc_work_fn(struct work_struct 
> *__work)
>   struct intel_fbc_work *work = >work;
>   struct intel_crtc *crtc = fbc->crtc;
>   struct drm_vblank_crtc *vblank = _priv->drm.vblank[crtc->pipe];
> + u64 vbl;

should we use something more descriptive here
like vbl_counter instead of "vbl" variable right before "vblank" one.

>  
>   if (drm_crtc_vblank_get(>base)) {
>   /* CRTC is now off, leave FBC deactivated */
> - mutex_lock(>lock);
> - work->scheduled = false;
> - mutex_unlock(>lock);
>   return;
>   }
>  
> -retry:
>   /* Delay the actual enabling to let pageflipping cease and the
>* display to settle before starting the compression. Note that
>* this delay also serves a second purpose: it allows for a
> @@ -425,34 +418,35 @@ static void intel_fbc_work_fn(struct work_struct 
> *__work)
>*
>* WaFbcWaitForVBlankBeforeEnable:ilk,snb

why not a simple wait 1 vblank below?

>*
> -  * It is also worth mentioning that since work->scheduled_vblank can be
> -  * updated multiple times by the other threads, hitting the timeout is
> -  * not an error condition. We'll just end up hitting the "goto retry"
> -  * case below.
> +  * This may be killed by unsetting scheduled_vblank, in which
> +  * case we return early without activating.
>*/
>   wait_event_timeout(vblank->queue,
> - drm_crtc_vblank_count(>base) != work->scheduled_vblank,
> + !(vbl = atomic64_read(>scheduled_vblank)) || vbl != 
> drm_crtc_vblank_count(>base),
>   msecs_to_jiffies(50));
>  
> - mutex_lock(>lock);
> + if (vbl)
> + intel_fbc_hw_activate(dev_priv);
>  
> - /* Were we cancelled? */
> - if (!work->scheduled)
> - goto out;
> + 

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

[Jeff McGee]

On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> From: Jeff McGee 
> 
> Signed-off-by: Jeff McGee 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index beb81f13a3cc..cec4e1653daf 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1009,7 +1009,7 @@ static void execlists_submission_tasklet(unsigned long 
> data)
>* imposing the cost of a locked atomic transaction when submitting a
>* new request (outside of the context-switch interrupt).
>*/
> - if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
> + while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
Assuming that this accidentally went missing in the refactor. Chris?

>   process_csb(engine);
>  
>   if (!execlists_is_active(>execlists, EXECLISTS_ACTIVE_PREEMPT))
> -- 
> 2.16.2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

[Jeff McGee]

On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote:
> From: Jeff McGee 
> 
> Engine reset is fast. A context switch interrupt may be generated just
> prior to the reset such that the top half handler is racing with reset
> post-processing. The handler may set the irq_posted bit again after
> the reset code has cleared it to start fresh. Then the re-enabled
> tasklet will read the CSB head and tail from MMIO, which will be at
> the hardware reset values of 0 and 7 respectively, given that no
> actual CSB event has occurred since the reset. Mayhem then ensues as
> the tasklet starts processing invalid CSB entries.
> 
> We can handle this corner case without adding any new synchronization
> between the irq top half and the reset work item. The tasklet can
> just skip CSB processing if the tail is not sane.
> 
> Signed-off-by: Jeff McGee 
> ---
If I drop this patch and substitute 
https://patchwork.freedesktop.org/patch/211831/
I will see irq_posted get set after reset which causes the first tasklet
run to re-process a previous CSB event and hit GEM_BUG_ON that nothing
was active.
-Jeff
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 4/8] drm/i915: Split execlists/guc reset prepartions

[jeff . mcgee]

From: Chris Wilson 

In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 39 +
 drivers/gpu/drm/i915/intel_lrc.c| 11 +---
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 207cda062626..779c8d3156e5 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -776,6 +776,44 @@ static void guc_submission_tasklet(unsigned long data)
guc_dequeue(engine);
 }
 
+static struct i915_request *
+guc_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*
+* Note that this needs to be a single atomic operation on the
+* tasklet (flush existing tasks, prevent new tasks) to prevent
+* a race between reset and set-wedged. It is not, so we do the best
+* we can atm and make sure we don't lock the machine up in the more
+* common case of recursively being called from set-wedged from inside
+* i915_reset.
+*/
+   if (!atomic_read(>tasklet.count))
+   tasklet_kill(>tasklet);
+   tasklet_disable(>tasklet);
+
+   /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+   if (engine->i915->guc.preempt_wq)
+   flush_workqueue(engine->i915->guc.preempt_wq);
+
+   return i915_gem_find_active_request(engine);
+}
+
 /*
  * Everything below here is concerned with setup & teardown, and is
  * therefore not part of the somewhat time-critical batch-submission
@@ -1235,6 +1273,7 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>execlists;
 
execlists->tasklet.func = guc_submission_tasklet;
+   engine->reset.prepare = guc_reset_prepare;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f662a9524233..e5a3ffbc273a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1688,16 +1688,6 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
tasklet_kill(>tasklet);
tasklet_disable(>tasklet);
 
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
return i915_gem_find_active_request(engine);
 }
 
@@ -2115,6 +2105,7 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->cancel_requests = execlists_cancel_requests;
engine->schedule = execlists_schedule;
engine->execlists.tasklet.func = execlists_submission_tasklet;
+   engine->reset.prepare = execlists_reset_prepare;
 
engine->park = NULL;
engine->unpark = NULL;
-- 
2.16.2

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

[Intel-gfx] [RFC 0/8] Force preemption

[jeff . mcgee]

From: Jeff McGee 

Force preemption uses engine reset to enforce a limit on the time
that a request targeted for preemption can block. This feature is
a requirement in automotive systems where the GPU may be shared by
clients of critically high priority and clients of low priority that
may not have been curated to be preemption friendly. There may be
more general applications of this feature. I'm sharing as an RFC to
stimulate that discussion and also to get any technical feedback
that I can before submitting to the product kernel that needs this.
I have developed the patches for ease of rebase, given that this is
for the moment considered a non-upstreamable feature. It would be
possible to refactor hangcheck to fully incorporate force preemption
as another tier of patience (or impatience) with the running request.

Chris Wilson (5):
  drm/i915/execlists: Refactor out complete_preempt_context()
  drm/i915: Add control flags to i915_handle_error()
  drm/i915: Move engine reset prepare/finish to backends
  drm/i915: Split execlists/guc reset prepartions
  drm/i915/execlists: Flush pending preemption events during reset

Jeff McGee (3):
  drm/i915: Fix loop on CSB processing
  drm/i915: Skip CSB processing on invalid CSB tail
  drm/i915: Force preemption to complete via engine reset

 drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.c  |  17 +-
 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/i915_gem.c  |  69 ++--
 drivers/gpu/drm/i915/i915_gpu_error.h|   3 +
 drivers/gpu/drm/i915/i915_irq.c  |  55 +--
 drivers/gpu/drm/i915/i915_params.c   |   3 +
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/i915_request.c  |   2 +-
 drivers/gpu/drm/i915/intel_engine_cs.c   |  40 +++
 drivers/gpu/drm/i915/intel_guc_submission.c  |  39 ++
 drivers/gpu/drm/i915/intel_hangcheck.c   |   8 +-
 drivers/gpu/drm/i915/intel_lrc.c | 436 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  20 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  13 +-
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c |  13 +-
 16 files changed, 469 insertions(+), 264 deletions(-)

-- 
2.16.2

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

[Intel-gfx] [RFC 8/8] drm/i915: Force preemption to complete via engine reset

[jeff . mcgee]

From: Jeff McGee 

The hardware can complete the requested preemption at only certain points
in execution. Thus an uncooperative request that avoids those points can
block a preemption indefinitely. Our only option to bound the preemption
latency is to trigger reset and recovery just as we would if a request had
hung the hardware. This is so-called forced preemption. This change adds
that capability as an option for systems with extremely strict scheduling
latency requirements for its high priority requests. This option must be
used with great care. The force-preempted requests will be discarded at
the point of reset, resulting in various degrees of disruption to the
owning application up to and including crash.

The option is enabled by specifying a non-zero value for new i915 module
parameter fpreempt_timeout. This value becomes the time in milliseconds
after initiation of preemption at which the reset is triggered if the
preemption has not completed normally.

GuC mode is not supported. The fpreempt_timeout parameter is simply
ignored.

Signed-off-by: Jeff McGee 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 27 --
 drivers/gpu/drm/i915/i915_params.c  |  3 +++
 drivers/gpu/drm/i915/i915_params.h  |  1 +
 drivers/gpu/drm/i915/intel_engine_cs.c  | 40 +
 drivers/gpu/drm/i915/intel_lrc.c| 13 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 
 6 files changed, 86 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 38f7160d99c9..0ad448792bfb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2896,8 +2896,24 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
return active;
 }
 
-static bool engine_stalled(struct intel_engine_cs *engine)
+static bool engine_stalled(struct intel_engine_cs *engine,
+  struct i915_request *request)
 {
+   if (engine->fpreempt_stalled) {
+   /* Pardon the request if it managed to yield the
+* engine by completing just prior to the reset. We
+* could be even more sophisticated here and pardon
+* the request if it preempted out (mid-batch) prior
+* to the reset, but that's not so straight-forward
+* to detect. Perhaps not worth splitting hairs when
+* the request had clearly behaved badly to get here.
+*/
+   if (i915_request_completed(request))
+   return false;
+
+   return true;
+   }
+
if (!engine->hangcheck.stalled)
return false;
 
@@ -3038,7 +3054,7 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
 * subsequent hangs.
 */
 
-   if (engine_stalled(engine)) {
+   if (engine_stalled(engine, request)) {
i915_gem_context_mark_guilty(request->ctx);
skip_request(request);
 
@@ -3046,6 +3062,13 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
if (i915_gem_context_is_banned(request->ctx))
engine_skip_context(request);
} else {
+   /* If the request that we just pardoned was the target of a
+* force preemption there is no possibility of the next
+* request in line having started.
+*/
+   if (engine->fpreempt_stalled)
+   return NULL;
+
/*
 * Since this is not the hung engine, it may have advanced
 * since the hang declaration. Double check by refinding
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce5be21..71bc8213acb2 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -178,6 +178,9 @@ i915_param_named(enable_dpcd_backlight, bool, 0600,
 i915_param_named(enable_gvt, bool, 0400,
"Enable support for Intel GVT-g graphics virtualization host 
support(default:false)");
 
+i915_param_named(fpreempt_timeout, uint, 0600,
+   "Wait time in msecs before forcing a preemption with reset (0:never 
force [default])");
+
 static __always_inline void _print_param(struct drm_printer *p,
 const char *name,
 const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c96360398072..1d50f223b637 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -55,6 +55,7 @@ struct drm_printer;
param(int, edp_vswing, 0) \
param(int, reset, 2) \
param(unsigned int, inject_load_failure, 0) \
+   param(unsigned int, fpreempt_timeout, 0) \
/* leave bools at 

[Intel-gfx] [RFC 2/8] drm/i915: Add control flags to i915_handle_error()

[jeff . mcgee]

From: Chris Wilson 

Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.

v2: Pass msg down to i915_reset/i915_reset_engine so that we include the
reason for the reset in the dev_notice(), superseding the earlier option
to not print that notice.
v3: Stash the reason inside the i915->gpu_error to handover to the direct
reset from the blocking waiter.

Signed-off-by: Chris Wilson 
Cc: Jeff McGee 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  4 +-
 drivers/gpu/drm/i915/i915_drv.c  | 17 
 drivers/gpu/drm/i915/i915_drv.h  | 10 ++---
 drivers/gpu/drm/i915/i915_gpu_error.h|  3 ++
 drivers/gpu/drm/i915/i915_irq.c  | 55 ++--
 drivers/gpu/drm/i915/i915_request.c  |  2 +-
 drivers/gpu/drm/i915/intel_hangcheck.c   |  8 ++--
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 13 +++---
 8 files changed, 60 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 964ea1a12357..7816cd53100a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4011,8 +4011,8 @@ i915_wedged_set(void *data, u64 val)
engine->hangcheck.stalled = true;
}
 
-   i915_handle_error(i915, val, "Manually set wedged engine mask = %llx",
- val);
+   i915_handle_error(i915, val, I915_ERROR_CAPTURE,
+ "Manually set wedged engine mask = %llx", val);
 
wait_on_bit(>gpu_error.flags,
I915_RESET_HANDOFF,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1021bf40e236..6b04cc3be513 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1869,7 +1869,6 @@ static int i915_resume_switcheroo(struct drm_device *dev)
 /**
  * i915_reset - reset chip after a hang
  * @i915: #drm_i915_private to reset
- * @flags: Instructions
  *
  * Reset the chip.  Useful if a hang is detected. Marks the device as wedged
  * on failure.
@@ -1884,7 +1883,7 @@ static int i915_resume_switcheroo(struct drm_device *dev)
  *   - re-init interrupt state
  *   - re-init display
  */
-void i915_reset(struct drm_i915_private *i915, unsigned int flags)
+void i915_reset(struct drm_i915_private *i915)
 {
struct i915_gpu_error *error = >gpu_error;
int ret;
@@ -1901,8 +1900,9 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
if (!i915_gem_unset_wedged(i915))
goto wakeup;
 
-   if (!(flags & I915_RESET_QUIET))
-   dev_notice(i915->drm.dev, "Resetting chip after gpu hang\n");
+   if (error->reason)
+   dev_notice(i915->drm.dev,
+  "Resetting chip for %s\n", error->reason);
error->reset_count++;
 
disable_irq(i915->drm.irq);
@@ -2003,7 +2003,7 @@ static inline int intel_gt_reset_engine(struct 
drm_i915_private *dev_priv,
 /**
  * i915_reset_engine - reset GPU engine to recover from a hang
  * @engine: engine to reset
- * @flags: options
+ * @msg: reason for GPU reset; or NULL for no dev_notice()
  *
  * Reset a specific GPU engine. Useful if a hang is detected.
  * Returns zero on successful reset or otherwise an error code.
@@ -2013,7 +2013,7 @@ static inline int intel_gt_reset_engine(struct 
drm_i915_private *dev_priv,
  *  - reset engine (which will force the engine to idle)
  *  - re-init/configure engine
  */
-int i915_reset_engine(struct intel_engine_cs *engine, unsigned int flags)
+int i915_reset_engine(struct intel_engine_cs *engine, const char *msg)
 {
struct i915_gpu_error *error = >i915->gpu_error;
struct i915_request *active_request;
@@ -2028,10 +2028,9 @@ int i915_reset_engine(struct intel_engine_cs *engine, 
unsigned int flags)
goto out;
}
 
-   if (!(flags & I915_RESET_QUIET)) {
+   if (msg)
dev_notice(engine->i915->drm.dev,
-  "Resetting %s after gpu hang\n", engine->name);
-   }
+  "Resetting %s for %s\n", engine->name, msg);
error->reset_engine_count[engine->id]++;
 
if (!engine->i915->guc.execbuf_client)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e27ba8fb64e6..c9c3b2ba6a86 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2700,10 +2700,8 @@ extern void i915_driver_unload(struct drm_device *dev);
 extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
 extern bool 

[Intel-gfx] [RFC 1/8] drm/i915/execlists: Refactor out complete_preempt_context()

[jeff . mcgee]

From: Chris Wilson 

As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.

Signed-off-by: Chris Wilson 
Cc: Jeff McGee 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/intel_lrc.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 53f1c009ed7b..0bfaeb56b8c7 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -531,8 +531,17 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
 
-   execlists_clear_active(>execlists, EXECLISTS_ACTIVE_HWACK);
-   execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+   execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
+static void complete_preempt_context(struct intel_engine_execlists *execlists)
+{
+   execlists_cancel_port_requests(execlists);
+   execlists_unwind_incomplete_requests(execlists);
+
+   GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
 }
 
 static void execlists_dequeue(struct intel_engine_cs *engine)
@@ -939,14 +948,7 @@ static void execlists_submission_tasklet(unsigned long 
data)
if (status & GEN8_CTX_STATUS_COMPLETE &&
buf[2*head + 1] == 
execlists->preempt_complete_status) {
GEM_TRACE("%s preempt-idle\n", engine->name);
-
-   execlists_cancel_port_requests(execlists);
-   execlists_unwind_incomplete_requests(execlists);
-
-   GEM_BUG_ON(!execlists_is_active(execlists,
-   
EXECLISTS_ACTIVE_PREEMPT));
-   execlists_clear_active(execlists,
-  
EXECLISTS_ACTIVE_PREEMPT);
+   complete_preempt_context(execlists);
continue;
}
 
-- 
2.16.2

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

[Intel-gfx] [RFC 5/8] drm/i915/execlists: Flush pending preemption events during reset

[jeff . mcgee]

From: Chris Wilson 

Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_lrc.c | 355 ++-
 1 file changed, 197 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e5a3ffbc273a..beb81f13a3cc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -828,186 +828,192 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
local_irq_restore(flags);
 }
 
-/*
- * Check the unread Context Status Buffers and manage the submission of new
- * contexts to the ELSP accordingly.
- */
-static void execlists_submission_tasklet(unsigned long data)
+static void process_csb(struct intel_engine_cs *engine)
 {
-   struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port * const port = execlists->port;
-   struct drm_i915_private *dev_priv = engine->i915;
+   struct drm_i915_private *i915 = engine->i915;
+   unsigned int head, tail;
+   const u32 *buf;
bool fw = false;
 
-   /* We can skip acquiring intel_runtime_pm_get() here as it was taken
-* on our behalf by the request (see i915_gem_mark_busy()) and it will
-* not be relinquished until the device is idle (see
-* i915_gem_idle_work_handler()). As a precaution, we make sure
-* that all ELSP are drained i.e. we have processed the CSB,
-* before allowing ourselves to idle and calling intel_runtime_pm_put().
-*/
-   GEM_BUG_ON(!dev_priv->gt.awake);
+   if (unlikely(execlists->csb_use_mmio)) {
+   buf = (u32 * __force)
+   (i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
+   execlists->csb_head = -1; /* force mmio read of CSB ptrs */
+   } else {
+   /* The HWSP contains a (cacheable) mirror of the CSB */
+   buf = >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
+   }
 
-   /* Prefer doing test_and_clear_bit() as a two stage operation to avoid
-* imposing the cost of a locked atomic transaction when submitting a
-* new request (outside of the context-switch interrupt).
+   /*
+* The write will be ordered by the uncached read (itself
+* a memory barrier), so we do not need another in the form
+* of a locked instruction. The race between the interrupt
+* handler and the split test/clear is harmless as we order
+* our clear before the CSB read. If the interrupt arrived
+* first between the test and the clear, we read the updated
+* CSB and clear the bit. If the interrupt arrives as we read
+* the CSB or later (i.e. after we had cleared the bit) the bit
+* is set and we do a new loop.
 */
-   while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
-   /* The HWSP contains a (cacheable) mirror of the CSB */
-   const u32 *buf =
-   >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
-   unsigned int head, tail;
-
-   if (unlikely(execlists->csb_use_mmio)) {
-   buf = (u32 * __force)
-   (dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
-   execlists->csb_head = -1; /* force mmio read of CSB 
ptrs */
-   }
+   __clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   if (unlikely(execlists->csb_head == -1)) { /* following a reset */
+   intel_uncore_forcewake_get(i915, execlists->fw_domains);
+   fw = true;
+
+   head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+   tail = GEN8_CSB_WRITE_PTR(head);
+   head = GEN8_CSB_READ_PTR(head);
+   execlists->csb_head = head;
+   } else {
+   const int write_idx =
+   intel_hws_csb_write_index(i915) -
+   I915_HWS_CSB_BUF0_INDEX;
+
+   head = execlists->csb_head;
+   tail = READ_ONCE(buf[write_idx]);
+   }
+   GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
+ engine->name,
+ head, GEN8_CSB_READ_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
+
+   while (head != tail) {
+  

[Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

[jeff . mcgee]

From: Jeff McGee 

Engine reset is fast. A context switch interrupt may be generated just
prior to the reset such that the top half handler is racing with reset
post-processing. The handler may set the irq_posted bit again after
the reset code has cleared it to start fresh. Then the re-enabled
tasklet will read the CSB head and tail from MMIO, which will be at
the hardware reset values of 0 and 7 respectively, given that no
actual CSB event has occurred since the reset. Mayhem then ensues as
the tasklet starts processing invalid CSB entries.

We can handle this corner case without adding any new synchronization
between the irq top half and the reset work item. The tasklet can
just skip CSB processing if the tail is not sane.

Signed-off-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_lrc.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cec4e1653daf..d420c2ecb50a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -865,6 +865,14 @@ static void process_csb(struct intel_engine_cs *engine)
head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
+
+   /* The MMIO read CSB tail may be at the reset value of
+* 0x7 if there hasn't been a valid CSB event since
+* the engine reset.
+*/
+   if (tail >= GEN8_CSB_ENTRIES)
+   goto out;
+
execlists->csb_head = head;
} else {
const int write_idx =
@@ -873,6 +881,7 @@ static void process_csb(struct intel_engine_cs *engine)
 
head = execlists->csb_head;
tail = READ_ONCE(buf[write_idx]);
+   GEM_BUG_ON(tail >= GEN8_CSB_ENTRIES);
}
GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
  engine->name,
@@ -981,7 +990,7 @@ static void process_csb(struct intel_engine_cs *engine)
writel(_MASKED_FIELD(GEN8_CSB_READ_PTR_MASK, head << 8),
   i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
}
-
+out:
if (unlikely(fw))
intel_uncore_forcewake_put(i915, execlists->fw_domains);
 }
-- 
2.16.2

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

[Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

[jeff . mcgee]

From: Jeff McGee 

Signed-off-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_lrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index beb81f13a3cc..cec4e1653daf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1009,7 +1009,7 @@ static void execlists_submission_tasklet(unsigned long 
data)
 * imposing the cost of a locked atomic transaction when submitting a
 * new request (outside of the context-switch interrupt).
 */
-   if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
+   while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
process_csb(engine);
 
if (!execlists_is_active(>execlists, EXECLISTS_ACTIVE_PREEMPT))
-- 
2.16.2

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

[Intel-gfx] [RFC 3/8] drm/i915: Move engine reset prepare/finish to backends

[jeff . mcgee]

From: Chris Wilson 

In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
CC: Michel Thierry 
Cc: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_gem.c | 42 --
 drivers/gpu/drm/i915/intel_lrc.c| 52 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 --
 4 files changed, 78 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 802df8e1a544..38f7160d99c9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2917,7 +2917,7 @@ static bool engine_stalled(struct intel_engine_cs *engine)
 struct i915_request *
 i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
 {
-   struct i915_request *request = NULL;
+   struct i915_request *request;
 
/*
 * During the reset sequence, we must prevent the engine from
@@ -2940,40 +2940,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 */
kthread_park(engine->breadcrumbs.signaler);
 
-   /*
-* Prevent request submission to the hardware until we have
-* completed the reset in i915_gem_reset_finish(). If a request
-* is completed by one engine, it may then queue a request
-* to a second via its execlists->tasklet *just* as we are
-* calling engine->init_hw() and also writing the ELSP.
-* Turning off the execlists->tasklet until the reset is over
-* prevents the race.
-*
-* Note that this needs to be a single atomic operation on the
-* tasklet (flush existing tasks, prevent new tasks) to prevent
-* a race between reset and set-wedged. It is not, so we do the best
-* we can atm and make sure we don't lock the machine up in the more
-* common case of recursively being called from set-wedged from inside
-* i915_reset.
-*/
-   if (!atomic_read(>execlists.tasklet.count))
-   tasklet_kill(>execlists.tasklet);
-   tasklet_disable(>execlists.tasklet);
-
-   /*
-* We're using worker to queue preemption requests from the tasklet in
-* GuC submission mode.
-* Even though tasklet was disabled, we may still have a worker queued.
-* Let's make sure that all workers scheduled before disabling the
-* tasklet are completed before continuing with the reset.
-*/
-   if (engine->i915->guc.preempt_wq)
-   flush_workqueue(engine->i915->guc.preempt_wq);
-
-   if (engine->irq_seqno_barrier)
-   engine->irq_seqno_barrier(engine);
-
-   request = i915_gem_find_active_request(engine);
+   request = engine->reset.prepare(engine);
if (request && request->fence.error == -EIO)
request = ERR_PTR(-EIO); /* Previous reset failed! */
 
@@ -3120,7 +3087,7 @@ void i915_gem_reset_engine(struct intel_engine_cs *engine,
}
 
/* Setup the CS to resume from the breadcrumb of the hung request */
-   engine->reset_hw(engine, request);
+   engine->reset.reset(engine, request);
 }
 
 void i915_gem_reset(struct drm_i915_private *dev_priv)
@@ -3172,7 +3139,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
 
 void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
 {
-   tasklet_enable(>execlists.tasklet);
+   engine->reset.finish(engine);
+
kthread_unpark(engine->breadcrumbs.signaler);
 
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0bfaeb56b8c7..f662a9524233 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1663,6 +1663,44 @@ static int gen9_init_render_ring(struct intel_engine_cs 
*engine)
return init_workarounds_ring(engine);
 }
 
+static struct i915_request *
+execlists_reset_prepare(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists * const execlists = >execlists;
+
+   /*
+* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its execlists->tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the execlists->tasklet until the reset is over
+* prevents the race.
+*
+* Note that this needs to be a single atomic operation on the
+* tasklet (flush existing tasks, prevent new tasks) to 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Include the trace as a debug aide (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Include the trace as a debug aide (rev2)
URL   : https://patchwork.freedesktop.org/series/40362/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-shrfb-fliptrack:
fail   -> PASS   (shard-apl) fdo#101623 +1
Test kms_plane:
Subgroup plane-position-covered-pipe-a-planes:
pass   -> FAIL   (shard-apl) fdo#103166
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_vblank:
Subgroup pipe-b-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583

shard-apltotal:3478 pass:1812 dwarn:1   dfail:0   fail:9   skip:1655 
time:13117s
shard-hswtotal:3478 pass:1765 dwarn:1   dfail:0   fail:4   skip:1707 
time:11797s
shard-snbtotal:3478 pass:1358 dwarn:1   dfail:0   fail:2   skip:2117 
time:7278s
Blacklisted hosts:
shard-kbltotal:3478 pass:1939 dwarn:1   dfail:0   fail:10  skip:1528 
time:9916s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8431/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: Flush pending interrupt following a GPU reset

[Jeff McGee]

On Wed, Mar 21, 2018 at 04:42:32PM +, Chris Wilson wrote:
> Quoting Jeff McGee (2018-03-21 15:55:16)
> > On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> > > After resetting the GPU (or subset of engines), call synchronize_irq()
> > > to flush any pending irq before proceeding with the cleanup. For a
> > > device level reset, we disable the interupts around the reset, but when
> > > resetting just one engine, we have to avoid such global disabling. This
> > > leaves us open to an interrupt arriving for the engine as we try to
> > > reset it. We already do try to flush the IIR following the reset, but we
> > > have to ensure that the in-flight interrupt does not land after we start
> > > cleaning up after the reset; enter synchronize_irq().
> > > 
> > > As it current stands, we very rarely, but fatally, see sequences such as:
> > > 
> > > 2 57964564us : execlists_reset_prepare: rcs0
> > > 2 57964613us : execlists_reset: rcs0 seqno=424
> > > 0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1
> > > 2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
> > > global_seqno 1060
> > > 2 57964703us : execlists_reset_finish: rcs0
> > > 0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, 
> > > active=0, irq-posted?=1
> > > 
> > I can repro this sequence easily with force preemption IGT.
> 
> With the sequence I suggested?
> -Chris

Yes. Your approach to protecting port[1] context is working well. This is
the only issue I'm still hitting. I'll post my updated RFC set in a sec.
-Jeff
___
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: Flush pending interrupt following a GPU reset

[Patchwork]

== Series Details ==

Series: drm/i915: Flush pending interrupt following a GPU reset
URL   : https://patchwork.freedesktop.org/series/40383/
State : success

== Summary ==

Series 40383v1 drm/i915: Flush pending interrupt following a GPU reset
https://patchwork.freedesktop.org/api/1.0/series/40383/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (fi-cfl-s2) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-cnl-y3) fdo#103167

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:295s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:508s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:516s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:500s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s2total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-drrs  total:285  pass:254  dwarn:3   dfail:0   fail:0   skip:28  
time:525s
fi-cnl-y3total:285  pass:258  dwarn:0   dfail:0   fail:1   skip:26  
time:585s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:321s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:474s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:478s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:656s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:427s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:583s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:398s

69b094355a7bc8d1752a43508ded3266d4e5a223 drm-tip: 2018y-03m-21d-15h-43m-50s UTC 
integration manifest
c3bbd56f3b68 drm/i915: Flush pending interrupt following a GPU reset

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

[Chris Wilson]

Quoting Michel Thierry (2018-03-21 17:01:12)
> On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
> > Chris Wilson  writes:
> > 
> >> We were relying on the uncached reads when processing the CSB to provide
> >> ourselves with the serialisation with the interrupt handler (so we could
> >> detect new interrupts in the middle of processing the old one). However,
> >> in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD
> >> from the HWSP") those uncached reads were eliminated (on one path at
> >> least) and along with them our serialisation. The result is that we
> >> would very rarely miss notification of a new interrupt and leave a
> >> context-switch unprocessed, hanging the GPU.
> >>
> >> Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD 
> >> from the HWSP")
> >> Signed-off-by: Chris Wilson 
> >> Cc: Michel Thierry 
> >> Cc: Tvrtko Ursulin 
> >> Cc: Mika Kuoppala 
> >> ---
> >>   drivers/gpu/drm/i915/intel_lrc.c | 21 -
> >>   1 file changed, 8 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >> b/drivers/gpu/drm/i915/intel_lrc.c
> >> index 53f1c009ed7b..67b6a0f658d6 100644
> >> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >> @@ -831,7 +831,8 @@ static void execlists_submission_tasklet(unsigned long 
> >> data)
> >>  struct drm_i915_private *dev_priv = engine->i915;
> >>  bool fw = false;
> >>   
> >> -/* We can skip acquiring intel_runtime_pm_get() here as it was taken
> >> +/*
> >> + * We can skip acquiring intel_runtime_pm_get() here as it was taken
> >>   * on our behalf by the request (see i915_gem_mark_busy()) and it will
> >>   * not be relinquished until the device is idle (see
> >>   * i915_gem_idle_work_handler()). As a precaution, we make sure
> >> @@ -840,7 +841,8 @@ static void execlists_submission_tasklet(unsigned long 
> >> data)
> >>   */
> >>  GEM_BUG_ON(!dev_priv->gt.awake);
> >>   
> >> -/* Prefer doing test_and_clear_bit() as a two stage operation to avoid
> >> +/*
> >> + * Prefer doing test_and_clear_bit() as a two stage operation to avoid
> >>   * imposing the cost of a locked atomic transaction when submitting a
> >>   * new request (outside of the context-switch interrupt).
> >>   */
> >> @@ -856,17 +858,10 @@ static void execlists_submission_tasklet(unsigned 
> >> long data)
> >>  execlists->csb_head = -1; /* force mmio read of CSB 
> >> ptrs */
> >>  }
> >>   
> >> -/* The write will be ordered by the uncached read (itself
> >> - * a memory barrier), so we do not need another in the form
> >> - * of a locked instruction. The race between the interrupt
> >> - * handler and the split test/clear is harmless as we order
> >> - * our clear before the CSB read. If the interrupt arrived
> >> - * first between the test and the clear, we read the updated
> >> - * CSB and clear the bit. If the interrupt arrives as we read
> >> - * the CSB or later (i.e. after we had cleared the bit) the 
> >> bit
> >> - * is set and we do a new loop.
> >> - */
> >> -__clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >> +/* Clear before reading to catch new interrupts */
> >> +clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >> +smp_mb__after_atomic();
> 
> Checkpatch wants a comment for the memory barrier... Are we being strict 
> about it? (https://patchwork.freedesktop.org/series/40359/)
> 
> > 
> > I was confused about this memory barrier as our test is in the
> > same context and ordered wrt this. Chris noted in irc that this is for
> > the documentation for ordering wrt the code that follows.
> > 
> > I am fine with that so,
> > Reviewed-by: Mika Kuoppala 
> > 
> 
> Fine by me too,
> 
> Reviewed-by: Michel Thierry 

It definitely appears to be fixing an issue I've been seeing for the
last few months since using HWSP for execlists. But I only seeing in
conjunction with another set of patches, so my presumption was upon
those and not drm-tip (which kept on testing clear).

Thanks for the review, pushed. I'm sure I'll moan about the locked
instruction appearing in the profiles, just as much as I moan about the
locked instructions for tasklet_schedule() dominating some profiles.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium

[Eric Anholt]

Maxime Ripard  writes:

> [ Unknown signature status ]
> Hi,
>
> On Mon, Mar 05, 2018 at 03:21:26PM +0100, Maxime Ripard wrote:
>> Here is an RFC at starting to test the plane formats using the
>> Chamelium over the HDMI. This was tested using the vc4 DRM driver
>> found on the RaspberryPi.
>> 
>> This is still pretty rough around the edges at this point, but I'd
>> like to get feedback on a few issues before getting any further.
>> 
>>   * I've used pixman for now to convert back and forth the pattern and
>> the captured frame. While this worked quite well for the RGB
>> formats since pixman supports most (but not all) of them. However,
>> the long term plan is to also test YUV and more exotic (like
>> vendor specific) formats that pixman has 0 support for. So I
>> really wonder whether this is the right approach compared to:
>> - Using something else (but what?)?
>> - Rolling our own format conversion library?

Let's start with pixman and either extend pixman if we have formats we
need (they should be pretty amenable for non-yuv channel layouts), or
roll our own YUV bits.  For tiling, I think we can just take
pixman-generated linear image content and do the tiling in igt.

>>   * I've so far had a single big test that will test all the formats
>> exposed by the planes that have a pixman representation. I wonder
>> whether this is preferrable, or if we want to have a subtest per
>> format. I guess the latter will be slightly better since we would
>> be able to catch regressions in the number of formats exposed that
>> we wouldn't be able to with the former.

Yeah, exposing the formats as subtests is probably a good idea.

>>   * Kind of related, I'm not sure what is the policy when it comes to
>> tests, and whether I should merge this tests with kms_chamelium or
>> leave it as a separate file.

I'll leave this up to the original test author.

>>   * One of the biggest challenge of the serie is to support formats
>> that have less bits than the reference frame. Indeed, the flow of
>> patterns is this one: the pattern will first be generated in
>> ARGB. It will then be converted to whatever format we want to
>> test, be fed into the display engine, that will output it, and the
>> Chamelium will capture it in ARGB.
>> However, when the plane format has less than 8 bits per color,
>> some upsampling will happen, where the less significant bits will
>> be filled with values that probably depend on the display
>> engine. Another side effect is that the CRC used in the Chamelium
>> tests cannot be used anymore.
>> The way I'm testing currently is that I'm retrieving the frame,
>> and then compare each pixels on their most significant bits. This
>> sounds inefficient, and it is, especially on the RPi that doesn't
>> have the best networking throughput out there.
>> I guess we could also generate a CRC for both an upsampling with
>> the lowest bits set to 1, and one for the lowest bits set to 0,
>> and try to see if one of them match. I guess this should cover
>> most of the situation.

I still think that we should expect the top bits to be replicated into
the low bits, until we find hardware that just can't do that.


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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

[Chris Wilson]

Quoting Chris Wilson (2018-03-21 17:05:06)
> Quoting Michel Thierry (2018-03-21 17:01:12)
> > On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
> > > Chris Wilson  writes:
> > > 
> > >> We were relying on the uncached reads when processing the CSB to provide
> > >> ourselves with the serialisation with the interrupt handler (so we could
> > >> detect new interrupts in the middle of processing the old one). However,
> > >> in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD
> > >> from the HWSP") those uncached reads were eliminated (on one path at
> > >> least) and along with them our serialisation. The result is that we
> > >> would very rarely miss notification of a new interrupt and leave a
> > >> context-switch unprocessed, hanging the GPU.
> > >>
> > >> Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD 
> > >> from the HWSP")
> > >> Signed-off-by: Chris Wilson 
> > >> Cc: Michel Thierry 
> > >> Cc: Tvrtko Ursulin 
> > >> Cc: Mika Kuoppala 
> > >> ---
> > >>   drivers/gpu/drm/i915/intel_lrc.c | 21 -
> > >>   1 file changed, 8 insertions(+), 13 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > >> b/drivers/gpu/drm/i915/intel_lrc.c
> > >> index 53f1c009ed7b..67b6a0f658d6 100644
> > >> --- a/drivers/gpu/drm/i915/intel_lrc.c
> > >> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > >> @@ -831,7 +831,8 @@ static void execlists_submission_tasklet(unsigned 
> > >> long data)
> > >>  struct drm_i915_private *dev_priv = engine->i915;
> > >>  bool fw = false;
> > >>   
> > >> -/* We can skip acquiring intel_runtime_pm_get() here as it was taken
> > >> +/*
> > >> + * We can skip acquiring intel_runtime_pm_get() here as it was taken
> > >>   * on our behalf by the request (see i915_gem_mark_busy()) and it 
> > >> will
> > >>   * not be relinquished until the device is idle (see
> > >>   * i915_gem_idle_work_handler()). As a precaution, we make sure
> > >> @@ -840,7 +841,8 @@ static void execlists_submission_tasklet(unsigned 
> > >> long data)
> > >>   */
> > >>  GEM_BUG_ON(!dev_priv->gt.awake);
> > >>   
> > >> -/* Prefer doing test_and_clear_bit() as a two stage operation to 
> > >> avoid
> > >> +/*
> > >> + * Prefer doing test_and_clear_bit() as a two stage operation to 
> > >> avoid
> > >>   * imposing the cost of a locked atomic transaction when submitting 
> > >> a
> > >>   * new request (outside of the context-switch interrupt).
> > >>   */
> > >> @@ -856,17 +858,10 @@ static void execlists_submission_tasklet(unsigned 
> > >> long data)
> > >>  execlists->csb_head = -1; /* force mmio read of CSB 
> > >> ptrs */
> > >>  }
> > >>   
> > >> -/* The write will be ordered by the uncached read (itself
> > >> - * a memory barrier), so we do not need another in the form
> > >> - * of a locked instruction. The race between the interrupt
> > >> - * handler and the split test/clear is harmless as we order
> > >> - * our clear before the CSB read. If the interrupt arrived
> > >> - * first between the test and the clear, we read the updated
> > >> - * CSB and clear the bit. If the interrupt arrives as we 
> > >> read
> > >> - * the CSB or later (i.e. after we had cleared the bit) the 
> > >> bit
> > >> - * is set and we do a new loop.
> > >> - */
> > >> -__clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> > >> +/* Clear before reading to catch new interrupts */
> > >> +clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> > >> +smp_mb__after_atomic();
> > 
> > Checkpatch wants a comment for the memory barrier... Are we being strict 
> > about it? (https://patchwork.freedesktop.org/series/40359/)
> 
> There's a comment for it not two lines above! Silly perl script.

Besides it being only a simulacrum of a mb. Silly perl script :) 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

[Chris Wilson]

Quoting Michel Thierry (2018-03-21 17:01:12)
> On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
> > Chris Wilson  writes:
> > 
> >> We were relying on the uncached reads when processing the CSB to provide
> >> ourselves with the serialisation with the interrupt handler (so we could
> >> detect new interrupts in the middle of processing the old one). However,
> >> in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD
> >> from the HWSP") those uncached reads were eliminated (on one path at
> >> least) and along with them our serialisation. The result is that we
> >> would very rarely miss notification of a new interrupt and leave a
> >> context-switch unprocessed, hanging the GPU.
> >>
> >> Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD 
> >> from the HWSP")
> >> Signed-off-by: Chris Wilson 
> >> Cc: Michel Thierry 
> >> Cc: Tvrtko Ursulin 
> >> Cc: Mika Kuoppala 
> >> ---
> >>   drivers/gpu/drm/i915/intel_lrc.c | 21 -
> >>   1 file changed, 8 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >> b/drivers/gpu/drm/i915/intel_lrc.c
> >> index 53f1c009ed7b..67b6a0f658d6 100644
> >> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >> @@ -831,7 +831,8 @@ static void execlists_submission_tasklet(unsigned long 
> >> data)
> >>  struct drm_i915_private *dev_priv = engine->i915;
> >>  bool fw = false;
> >>   
> >> -/* We can skip acquiring intel_runtime_pm_get() here as it was taken
> >> +/*
> >> + * We can skip acquiring intel_runtime_pm_get() here as it was taken
> >>   * on our behalf by the request (see i915_gem_mark_busy()) and it will
> >>   * not be relinquished until the device is idle (see
> >>   * i915_gem_idle_work_handler()). As a precaution, we make sure
> >> @@ -840,7 +841,8 @@ static void execlists_submission_tasklet(unsigned long 
> >> data)
> >>   */
> >>  GEM_BUG_ON(!dev_priv->gt.awake);
> >>   
> >> -/* Prefer doing test_and_clear_bit() as a two stage operation to avoid
> >> +/*
> >> + * Prefer doing test_and_clear_bit() as a two stage operation to avoid
> >>   * imposing the cost of a locked atomic transaction when submitting a
> >>   * new request (outside of the context-switch interrupt).
> >>   */
> >> @@ -856,17 +858,10 @@ static void execlists_submission_tasklet(unsigned 
> >> long data)
> >>  execlists->csb_head = -1; /* force mmio read of CSB 
> >> ptrs */
> >>  }
> >>   
> >> -/* The write will be ordered by the uncached read (itself
> >> - * a memory barrier), so we do not need another in the form
> >> - * of a locked instruction. The race between the interrupt
> >> - * handler and the split test/clear is harmless as we order
> >> - * our clear before the CSB read. If the interrupt arrived
> >> - * first between the test and the clear, we read the updated
> >> - * CSB and clear the bit. If the interrupt arrives as we read
> >> - * the CSB or later (i.e. after we had cleared the bit) the 
> >> bit
> >> - * is set and we do a new loop.
> >> - */
> >> -__clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >> +/* Clear before reading to catch new interrupts */
> >> +clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >> +smp_mb__after_atomic();
> 
> Checkpatch wants a comment for the memory barrier... Are we being strict 
> about it? (https://patchwork.freedesktop.org/series/40359/)

There's a comment for it not two lines above! Silly perl script.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

[Michel Thierry]

On 3/21/2018 3:46 AM, Mika Kuoppala wrote:

Chris Wilson  writes:


We were relying on the uncached reads when processing the CSB to provide
ourselves with the serialisation with the interrupt handler (so we could
detect new interrupts in the middle of processing the old one). However,
in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD
from the HWSP") those uncached reads were eliminated (on one path at
least) and along with them our serialisation. The result is that we
would very rarely miss notification of a new interrupt and leave a
context-switch unprocessed, hanging the GPU.

Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the 
HWSP")
Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_lrc.c | 21 -
  1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 53f1c009ed7b..67b6a0f658d6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -831,7 +831,8 @@ static void execlists_submission_tasklet(unsigned long data)
struct drm_i915_private *dev_priv = engine->i915;
bool fw = false;
  
-	/* We can skip acquiring intel_runtime_pm_get() here as it was taken

+   /*
+* We can skip acquiring intel_runtime_pm_get() here as it was taken
 * on our behalf by the request (see i915_gem_mark_busy()) and it will
 * not be relinquished until the device is idle (see
 * i915_gem_idle_work_handler()). As a precaution, we make sure
@@ -840,7 +841,8 @@ static void execlists_submission_tasklet(unsigned long data)
 */
GEM_BUG_ON(!dev_priv->gt.awake);
  
-	/* Prefer doing test_and_clear_bit() as a two stage operation to avoid

+   /*
+* Prefer doing test_and_clear_bit() as a two stage operation to avoid
 * imposing the cost of a locked atomic transaction when submitting a
 * new request (outside of the context-switch interrupt).
 */
@@ -856,17 +858,10 @@ static void execlists_submission_tasklet(unsigned long 
data)
execlists->csb_head = -1; /* force mmio read of CSB 
ptrs */
}
  
-		/* The write will be ordered by the uncached read (itself

-* a memory barrier), so we do not need another in the form
-* of a locked instruction. The race between the interrupt
-* handler and the split test/clear is harmless as we order
-* our clear before the CSB read. If the interrupt arrived
-* first between the test and the clear, we read the updated
-* CSB and clear the bit. If the interrupt arrives as we read
-* the CSB or later (i.e. after we had cleared the bit) the bit
-* is set and we do a new loop.
-*/
-   __clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   /* Clear before reading to catch new interrupts */
+   clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   smp_mb__after_atomic();


Checkpatch wants a comment for the memory barrier... Are we being strict 
about it? (https://patchwork.freedesktop.org/series/40359/)




I was confused about this memory barrier as our test is in the
same context and ordered wrt this. Chris noted in irc that this is for
the documentation for ordering wrt the code that follows.

I am fine with that so,
Reviewed-by: Mika Kuoppala 



Fine by me too,

Reviewed-by: Michel Thierry 


+
if (unlikely(execlists->csb_head == -1)) { /* following a reset 
*/
if (!fw) {
intel_uncore_forcewake_get(dev_priv,
--
2.16.2

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

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


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Flush pending interrupt following a GPU reset

[Patchwork]

== Series Details ==

Series: drm/i915: Flush pending interrupt following a GPU reset
URL   : https://patchwork.freedesktop.org/series/40383/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c3bbd56f3b68 drm/i915: Flush pending interrupt following a GPU reset
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#23: 
2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
global_seqno 1060

total: 0 errors, 1 warnings, 0 checks, 15 lines checked

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

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

[Chris Wilson]

Quoting Jeff McGee (2018-03-21 15:55:16)
> On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> > After resetting the GPU (or subset of engines), call synchronize_irq()
> > to flush any pending irq before proceeding with the cleanup. For a
> > device level reset, we disable the interupts around the reset, but when
> > resetting just one engine, we have to avoid such global disabling. This
> > leaves us open to an interrupt arriving for the engine as we try to
> > reset it. We already do try to flush the IIR following the reset, but we
> > have to ensure that the in-flight interrupt does not land after we start
> > cleaning up after the reset; enter synchronize_irq().
> > 
> > As it current stands, we very rarely, but fatally, see sequences such as:
> > 
> > 2 57964564us : execlists_reset_prepare: rcs0
> > 2 57964613us : execlists_reset: rcs0 seqno=424
> > 0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1
> > 2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
> > global_seqno 1060
> > 2 57964703us : execlists_reset_finish: rcs0
> > 0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, 
> > active=0, irq-posted?=1
> > 
> I can repro this sequence easily with force preemption IGT.

With the sequence I suggested?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

[Chris Wilson]

Quoting Jeff McGee (2018-03-21 15:55:16)
> On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> > After resetting the GPU (or subset of engines), call synchronize_irq()
> > to flush any pending irq before proceeding with the cleanup. For a
> > device level reset, we disable the interupts around the reset, but when
> > resetting just one engine, we have to avoid such global disabling. This
> > leaves us open to an interrupt arriving for the engine as we try to
> > reset it. We already do try to flush the IIR following the reset, but we
> > have to ensure that the in-flight interrupt does not land after we start
> > cleaning up after the reset; enter synchronize_irq().
> > 
> > As it current stands, we very rarely, but fatally, see sequences such as:
> > 
> > 2 57964564us : execlists_reset_prepare: rcs0
> > 2 57964613us : execlists_reset: rcs0 seqno=424
> > 0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1
> > 2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
> > global_seqno 1060
> > 2 57964703us : execlists_reset_finish: rcs0
> > 0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, 
> > active=0, irq-posted?=1
> > 
> I can repro this sequence easily with force preemption IGT. Just tried this
> patch and the issue is still there. For the moment I can just mitigate with
> https://patchwork.freedesktop.org/patch/211086/

These patch is purely to make sure that the irq_handler is not called
after execlists_reset, as that is what we rely on.

We *should* never be in a situation where CSB tail is invalid, that
implies either we screwed up or the hw is incoherent.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

[Jeff McGee]

On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> After resetting the GPU (or subset of engines), call synchronize_irq()
> to flush any pending irq before proceeding with the cleanup. For a
> device level reset, we disable the interupts around the reset, but when
> resetting just one engine, we have to avoid such global disabling. This
> leaves us open to an interrupt arriving for the engine as we try to
> reset it. We already do try to flush the IIR following the reset, but we
> have to ensure that the in-flight interrupt does not land after we start
> cleaning up after the reset; enter synchronize_irq().
> 
> As it current stands, we very rarely, but fatally, see sequences such as:
> 
> 2 57964564us : execlists_reset_prepare: rcs0
> 2 57964613us : execlists_reset: rcs0 seqno=424
> 0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1
> 2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
> global_seqno 1060
> 2 57964703us : execlists_reset_finish: rcs0
> 0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, active=0, 
> irq-posted?=1
> 
I can repro this sequence easily with force preemption IGT. Just tried this
patch and the issue is still there. For the moment I can just mitigate with
https://patchwork.freedesktop.org/patch/211086/

> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michel Thierry 
> Cc: Michał Winiarski 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 4c616d074a97..04830d6125d6 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2116,11 +2116,14 @@ int intel_gpu_reset(struct drm_i915_private 
> *dev_priv, unsigned engine_mask)
>   i915_stop_engines(dev_priv, engine_mask);
>  
>   ret = -ENODEV;
> - if (reset)
> + if (reset) {
> + GEM_TRACE("engine_mask=%x\n", engine_mask);
>   ret = reset(dev_priv, engine_mask);
> + }
>   if (ret != -ETIMEDOUT)
>   break;
>  
> + synchronize_irq(dev_priv->drm.irq);
>   cond_resched();
>   }
>   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> -- 
> 2.16.2
> 
> ___
> 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] [PULL] gvt-next-fixes for 4.17

[Joonas Lahtinen]

Quoting Zhenyu Wang (2018-03-20 04:41:08)
> 
> Hi, Joonas
> 
> Here's gvt-next-fixes update for 4.17. One regression that
> caused guest VM gpu hang has been fixed and with other changes
> as details below.

Pulled, thanks.

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

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Handle GuC log flush event in dedicated function

[Chris Wilson]

Quoting Michał Winiarski (2018-03-20 18:56:59)
> On Mon, Mar 19, 2018 at 12:50:49PM +, Michal Wajdeczko wrote:
> > We already try to keep all GuC log related code in separate file,
> > handling flush event should be placed there too. This will also
> > allow future code reuse.
> > 
> > v2: rebased
> > 
> > Signed-off-by: Michal Wajdeczko 
> > Cc: Michal Winiarski 
> > Cc: Sagar Arun Kamble 
> > Cc: Chris Wilson 
> > Cc: Oscar Mateo 
> 
> Reviewed-by: Michał Winiarski 

And pushed, thanks for the patch and review. (Sorry for the lack of
creativity in writing these thank you notes...)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Unify parameters of public CT functions

[Chris Wilson]

Quoting Michal Wajdeczko (2018-03-20 16:20:20)
> There is no need to mix parameter types in public CT functions
> as we can always accept intel_guc_ct.
> 
> v2: fix 'Return' doc, s/dev_priv/i915 (Sagar)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Reviewed-by: Sagar Arun Kamble 

And pushed, thanks for the patch and review,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/guc: Unify naming of private GuC action functions

[Chris Wilson]

Quoting Patchwork (2018-03-20 19:04:24)
> == Series Details ==
> 
> Series: series starting with [CI,1/3] drm/i915/guc: Unify naming of private 
> GuC action functions
> URL   : https://patchwork.freedesktop.org/series/40311/
> State : success
> 
> == Summary ==
> 
> Series 40311v1 series starting with [CI,1/3] drm/i915/guc: Unify naming of 
> private GuC action functions
> https://patchwork.freedesktop.org/api/1.0/series/40311/revisions/1/mbox/
> 
>  Possible new issues:
> 
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> incomplete -> PASS   (fi-cfl-s2)
> 
>  Known issues:
> 
> Test gem_mmap_gtt:
> Subgroup basic-small-bo-tiledx:
> pass   -> FAIL   (fi-gdg-551) fdo#102575
> 
> fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

And pushed, thanks for the patch and review.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

[Chris Wilson]

Quoting Michel Thierry (2018-03-14 23:34:33)
> On 14/03/18 15:23, Michal Wajdeczko wrote:
> > On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry 
> >  wrote:
> > 
> >> On 14/03/18 13:04, Michal Wajdeczko wrote:
> >>> We try to keep all HuC related code in dedicated file.
> >>> There is no need to peek HuC register directly during
> >>> handling getparam ioctl.
> >>>  Signed-off-by: Michal Wajdeczko 
> >>> Cc: Michel Thierry 
> >>> Cc: Rodrigo Vivi 
> >>> Cc: Anusha Srivatsa 
> >>> ---
> >>>   drivers/gpu/drm/i915/i915_drv.c  |  6 +++---
> >>>   drivers/gpu/drm/i915/intel_huc.c | 25 +
> >>>   drivers/gpu/drm/i915/intel_huc.h |  1 +
> >>>   3 files changed, 29 insertions(+), 3 deletions(-)
> >>>  diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >>> b/drivers/gpu/drm/i915/i915_drv.c
> >>> index f03555e..a902e88 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.c
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >>> @@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device 
> >>> *dev, void *data,
> >>>   value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
> >>>   break;
> >>>   case I915_PARAM_HUC_STATUS:
> >>> -    intel_runtime_pm_get(dev_priv);
> >>> -    value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> >>> -    intel_runtime_pm_put(dev_priv);
> >>> +    value = intel_huc_check_status(_priv->huc);
> >>> +    if (value < 0)
> >>> +    return value;
> >>>   break;
> >>>   case I915_PARAM_MMAP_GTT_VERSION:
> >>>   /* Though we've started our numbering from 1, and so class all
> >>> diff --git a/drivers/gpu/drm/i915/intel_huc.c 
> >>> b/drivers/gpu/drm/i915/intel_huc.c
> >>> index 1d6c47b..2912852 100644
> >>> --- a/drivers/gpu/drm/i915/intel_huc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_huc.c
> >>> @@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
> >>>   DRM_ERROR("HuC: Authentication failed %d\n", ret);
> >>>   return ret;
> >>>   }
> >>> +
> >>> +/**
> >>> + * intel_huc_check_status() - check HuC status
> >>> + * @huc: intel_huc structure
> >>> + *
> >>> + * This function reads status register to verify if HuC
> >>> + * firmware was successfully loaded.
> >>> + *
> >>> + * Returns positive value if HuC firmware is loaded and verified
> >>> + * and -ENODEV if HuC is not present.
> >>
> >> Before if huc was not loaded, get_param would just return 0 and the 
> >> ioctl call would be OK.
> > 
> > There is another potential problem, as in case HuC was loaded, this
> > getparam would return specific bit from register instead of predefined
> > value that shall indicate "loaded/verified" like "1".
> > What if this bit from register will be moved on future platforms?
> 
> Really? ;)
> I once heard someone claiming he had talked with the hw team and they've 
> agreed not to randomly shuffle register specifications
> (please laugh with me).
> 
> > Should we still return this old one?
> > 
> >> Maybe there's a test somewhere that would break?
> > 
> > I hope not, and given above concern, I assume we can still modify it.
> > Is there any documentation what to expect from this getparam?
> > 
> 
> And the media driver would survive the change [1] if that's what we care 
> about.
> 
> But is the response from getparam ABI? I would say just 
> drm_i915_getparam_t is.

So long as we obey the rule to not overwrite on error, we should be
within the existing ABI. Then we only have the argument over what errno
suits the ABI.

-ENODEV is what we have been using for a user call for a function not
supported by the HW, so fine by me.

Pushed, thanks for the patch and review.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

[Jani Nikula]

On Wed, 21 Mar 2018, Patchwork  wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/i915: prefer INTEL_GEN() over 
> INTEL_INFO()->gen
> URL   : https://patchwork.freedesktop.org/series/40380/
> State : failure
>
> == Summary ==
>
> CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   DESCEND  objtool
>   CHK scripts/mod/devicetable-offsets.h
>   CHK include/generated/compile.h
>   CHK kernel/config_data.h
>   CC [M]  drivers/gpu/drm/i915/i915_gem.o
> In file included from drivers/gpu/drm/i915/i915_gem.c:6001:0:
> drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 
> ‘mock_gem_device’:
> drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:27: error: ‘struct 
> intel_device_info’ has no member named ‘gen’; did you mean ‘__gen’?
>   mkwrite_device_info(i915)->gen = -1;

Looks like someone(tm) has CONFIG_DRM_I915_SELFTEST=n in their dev
repo. *blush*.


>^~
> scripts/Makefile.build:324: recipe for target 
> 'drivers/gpu/drm/i915/i915_gem.o' failed
> make[4]: *** [drivers/gpu/drm/i915/i915_gem.o] Error 1
> scripts/Makefile.build:583: recipe for target 'drivers/gpu/drm/i915' failed
> make[3]: *** [drivers/gpu/drm/i915] Error 2
> scripts/Makefile.build:583: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:583: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:1051: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>

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

[Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

[Chris Wilson]

After resetting the GPU (or subset of engines), call synchronize_irq()
to flush any pending irq before proceeding with the cleanup. For a
device level reset, we disable the interupts around the reset, but when
resetting just one engine, we have to avoid such global disabling. This
leaves us open to an interrupt arriving for the engine as we try to
reset it. We already do try to flush the IIR following the reset, but we
have to ensure that the in-flight interrupt does not land after we start
cleaning up after the reset; enter synchronize_irq().

As it current stands, we very rarely, but fatally, see sequences such as:

2 57964564us : execlists_reset_prepare: rcs0
2 57964613us : execlists_reset: rcs0 seqno=424
0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1
2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- 
global_seqno 1060
2 57964703us : execlists_reset_finish: rcs0
0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, active=0, 
irq-posted?=1

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/intel_uncore.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 4c616d074a97..04830d6125d6 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2116,11 +2116,14 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
unsigned engine_mask)
i915_stop_engines(dev_priv, engine_mask);
 
ret = -ENODEV;
-   if (reset)
+   if (reset) {
+   GEM_TRACE("engine_mask=%x\n", engine_mask);
ret = reset(dev_priv, engine_mask);
+   }
if (ret != -ETIMEDOUT)
break;
 
+   synchronize_irq(dev_priv->drm.irq);
cond_resched();
}
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
-- 
2.16.2

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