[Intel-gfx] [PATCH igt v2] igt/gem_ctx_switch: Exercise all engines at once

[Chris Wilson]

Just a small variant to apply a continuous context-switch load to all
engines.

v2: Adapt to for_each_physical_engine() and sane gem_context_create()

Signed-off-by: Chris Wilson 
Cc: Antonio Argenziano 
---
 tests/gem_ctx_switch.c | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/tests/gem_ctx_switch.c b/tests/gem_ctx_switch.c
index 79b1d74b..b8c97c72 100644
--- a/tests/gem_ctx_switch.c
+++ b/tests/gem_ctx_switch.c
@@ -133,6 +133,80 @@ static void single(int fd, uint32_t handle,
gem_context_destroy(fd, contexts[n]);
 }
 
+static void all(int fd, uint32_t handle, unsigned flags, int timeout)
+{
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 obj[2];
+   unsigned int engine[16], e;
+   const char *name[16];
+   uint32_t contexts[65];
+   unsigned int nengine;
+   int n;
+
+   nengine = 0;
+   for_each_physical_engine(fd, e) {
+   engine[nengine] = e;
+   name[nengine] = e__->name;
+   nengine++;
+   }
+   igt_require(nengine);
+
+   for (n = 0; n < ARRAY_SIZE(contexts); n++)
+   contexts[n] = gem_context_create(fd);
+
+   memset(obj, 0, sizeof(obj));
+   obj[1].handle = handle;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer(obj + 1);
+   execbuf.buffer_count = 1;
+   execbuf.rsvd1 = contexts[0];
+   execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
+   execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
+   igt_require(__gem_execbuf(fd, ) == 0);
+   gem_sync(fd, handle);
+   execbuf.buffers_ptr = to_user_pointer(obj);
+   execbuf.buffer_count = 2;
+
+   for (int pot = 2; pot <= 64; pot *= 2) {
+   for (int nctx = pot - 1; nctx <= pot + 1; nctx++) {
+   igt_fork(child, nengine) {
+   struct timespec start, now;
+   unsigned int count = 0;
+
+   obj[0].handle = gem_create(fd, 4096);
+   execbuf.flags |= engine[child];
+   for (int loop = 0; loop < ARRAY_SIZE(contexts); 
loop++) {
+   execbuf.rsvd1 = contexts[loop];
+   gem_execbuf(fd, );
+   }
+   gem_sync(fd, obj[0].handle);
+
+   clock_gettime(CLOCK_MONOTONIC, );
+   do {
+   for (int loop = 0; loop < 1024; loop++) 
{
+   execbuf.rsvd1 = contexts[loop % 
nctx];
+   gem_execbuf(fd, );
+   }
+   count += 1024;
+   clock_gettime(CLOCK_MONOTONIC, );
+   } while (elapsed(, ) < timeout);
+   gem_sync(fd, obj[0].handle);
+   clock_gettime(CLOCK_MONOTONIC, );
+   gem_close(fd, obj[0].handle);
+
+   igt_info("[%d:%d] %s: %'u cycles: %.3fus%s\n",
+nctx, child, name[child], count, 
elapsed(, )*1e6 / count,
+flags & INTERRUPTIBLE ? " 
(interruptible)" : "");
+   }
+   igt_waitchildren();
+   }
+   }
+
+   for (n = 0; n < ARRAY_SIZE(contexts); n++)
+   gem_context_destroy(fd, contexts[n]);
+}
+
 igt_main
 {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -175,6 +249,11 @@ igt_main
single(fd, light, e, INTERRUPTIBLE, ncpus, 150);
}
 
+   igt_subtest("basic-all")
+   all(fd, light, 0, 5);
+   igt_subtest("basic-all-heavy")
+   all(fd, heavy, 0, 20);
+
igt_fixture {
igt_stop_hang_detector();
gem_close(fd, heavy);
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array

[Jani Nikula]

On Wed, 28 Feb 2018, Manasi Navare  wrote:
> dp_rates[] array is a superset of all the link rates supported
> by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
> to the set of link rates supported by sink. This patch adds this rate
> to dp_rates[] array that gets used to populate the sink_rates[]
> array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register.
>
> v2:
> * Rebased on top of Jani's localized rates patch
>
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Manasi Navare 

And pushed to dinq, thanks for the patch.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 750c25a..aba2f45 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -136,7 +136,7 @@ static void intel_dp_unset_edid(struct intel_dp 
> *intel_dp);
>  static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
>  {
>   static const int dp_rates[] = {
> - 162000, 27, 54
> + 162000, 27, 54, 81
>   };
>   int i, max_rate;

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

Re: [Intel-gfx] [igt-dev] [PATCH igt 1/5] lib/dummyload: Avoid assertions in lowlevel spin constructor

[Abdiel Janulgue]

On 02/28/2018 05:51 PM, Chris Wilson wrote:
> __igt_spin_batch_new() may be used inside a background helper which is
> competing against the GPU being reset. As such, we cannot even assert
> that the spin->handle is busy immediately after submission as it may
> have already been reset by another client writing to i915_wedged.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Abdiel Janulgue 

> ---
>  lib/igt_dummyload.c | 17 ++---
>  tests/pm_rps.c  |  4 +++-
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index ddd43451..4b20f23d 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -207,7 +208,6 @@ ___igt_spin_batch_new(int fd, uint32_t ctx, unsigned 
> engine, uint32_t dep,
>  
>   spin->out_fence = emit_recursive_batch(spin, fd, ctx, engine, dep,
>  out_fence);
> - igt_assert(gem_bo_busy(fd, spin->handle));
>  
>   pthread_mutex_lock(_lock);
>   igt_list_add(>link, _list);
> @@ -240,9 +240,14 @@ __igt_spin_batch_new(int fd, uint32_t ctx, unsigned 
> engine, uint32_t dep)
>  igt_spin_t *
>  igt_spin_batch_new(int fd, uint32_t ctx, unsigned engine, uint32_t dep)
>  {
> + igt_spin_t *spin;
> +
>   igt_require_gem(fd);
>  
> - return __igt_spin_batch_new(fd, ctx, engine, dep);
> + spin = __igt_spin_batch_new(fd, ctx, engine, dep);
> + igt_assert(gem_bo_busy(fd, spin->handle));
> +
> + return spin;
>  }
>  
>  igt_spin_t *
> @@ -269,10 +274,16 @@ __igt_spin_batch_new_fence(int fd, uint32_t ctx, 
> unsigned engine)
>  igt_spin_t *
>  igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned engine)
>  {
> + igt_spin_t *spin;
> +
>   igt_require_gem(fd);
>   igt_require(gem_has_exec_fence(fd));
>  
> - return __igt_spin_batch_new_fence(fd, ctx, engine);
> + spin = __igt_spin_batch_new_fence(fd, ctx, engine);
> + igt_assert(gem_bo_busy(fd, spin->handle));
> + igt_assert(poll(&(struct pollfd){spin->out_fence, POLLIN}, 1, 0) == 0);
> +
> + return spin;
>  }
>  
>  static void notify(union sigval arg)
> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> index f71976ed..006d084b 100644
> --- a/tests/pm_rps.c
> +++ b/tests/pm_rps.c
> @@ -221,6 +221,8 @@ static void load_helper_run(enum load load)
>   return;
>   }
>  
> + igt_require_gem(drm_fd);
> +
>   lh.exit = false;
>   lh.load = load;
>  
> @@ -233,7 +235,7 @@ static void load_helper_run(enum load load)
>  
>   igt_debug("Applying %s load...\n", lh.load ? "high" : "low");
>  
> - spin[0] = igt_spin_batch_new(drm_fd, 0, 0, 0);
> + spin[0] = __igt_spin_batch_new(drm_fd, 0, 0, 0);
>   if (lh.load == HIGH)
>   spin[1] = __igt_spin_batch_new(drm_fd, 0, 0, 0);
>   while (!lh.exit) {
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Wedged engine mask makes more sense in hex

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-28 17:18:44)
> From: Tvrtko Ursulin 
> 
> In decimal its just a weird big number, while in hex can actually log
> which engines were requested to be wedged.
> 
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 

Oh, and another thing that bugs me, is "action: reset". That's all we
say, and I think it's immaterial to the post-mortem error state. Just
creates extra work for me in removing that useless bit of information
when it gets cut and pasted into bug reports.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH igt 5/5] igt/gem_exec_fence: Exercise merging fences

[Chris Wilson]

Quoting Antonio Argenziano (2018-02-28 22:44:31)
> On 28/02/18 07:51, Chris Wilson wrote:
> > + igt_assert(!gem_bo_busy(fd, obj.handle));
> > + igt_assert_eq(sync_fence_status(all),
> > +   flags & HANG ? -EIO : SYNC_FENCE_OK);
> 
> Do you get -EIO also if only one engine hangs?

Yes. If the hang occurs on the fence (single request/engine, or many
requests/engines merged sync_file) we expect to be notified with -EIO.
That part of the contract is checked in gem_eio and should be checked in
gem_reset_stats (pretty much all that test should be doing, injecting a
hang on each ring, observing fence states and reset-stats for itself and
concurrent contexts).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

[Sagar Arun Kamble]

On 2/28/2018 11:29 PM, Oscar Mateo wrote:



On 2/26/2018 9:49 PM, Sagar Arun Kamble wrote:



On 2/27/2018 4:34 AM, Oscar Mateo wrote:



On 2/25/2018 9:22 PM, Sagar Arun Kamble wrote:



On 2/23/2018 4:35 AM, Oscar Mateo wrote:





+ * We might have detected that some engines are fused off after 
we initialized
+ * the forcewake domains. Prune them, to make sure they only 
reference existing

+ * engines.
+ */
+void intel_uncore_prune(struct drm_i915_private *dev_priv)
+{
+    if (INTEL_GEN(dev_priv) >= 11) {
+    enum forcewake_domains fw_domains = 
dev_priv->uncore.fw_domains;

+    enum forcewake_domain_id domain_id;
+    int i;
+
+    for (i = 0; i < I915_MAX_VCS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VDBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VCS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
fw_domains check seems redundant as it is initialized based on 
HAS_ENGINE.

we can just have
if (!HAS_ENGINE(dev_priv, _VCS(i)))
    fw_domain_fini(dev_priv, domain_id);


I don't want to call fw_domain_fini on something we never 
initialized in the first place (e.g. VCS1/3 and VECS1/2/3 on an 
ICL-LP).



Right. Makes sense.
for loop iterating over engines based on ring_mask can help us rely 
on only HAS_ENGINE condition and then we can have complete pruning 
in single for loop.

what do you think?


Hmmm.. I'm not sure I follow: intel_device_info_init_mmio modifies 
ring_mask, so if I loop over engines based on ring_mask I am going 
to miss those I want to prune, right?



Oops ... you are right ...
My suggestion about skipping fw_domains check will not work 
currently. In future may be if we create default ring_mask and 
runtime ring_mask it can be reworked.


Other suggestion to use single for loop (for_each_engine()) can be 
done I think.
It will make it generic for all engine types.  Below is what I am 
thinking of as part of intel_uncore_prune:


for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
    if (HAS_ENGINE(dev_priv, i))
        continue;
    if (fw_domains & BIT(i))
        fw_domain_fini(dev_priv, i);
}


This won't work either, because the index for engines and forcewake 
domains is different. If you think it is important to make the prune 
function more generic, I can translate between the two (but it will be 
for naught if, as you mentioned, we are working to create separate 
default ring_mask and runtime ring_mask in the future).


Yes. Translation will help (I thought of FW_D_ID_MEDIA to be reused for 
FW_D_ID_MEDIA_VDB0).
I think this patch can go in current shape and will pursue other changes 
as follow up based on inputs.


I feel making it generic will allow pruning to scale across engine types 
(if that is needed in future).
I am not sure if we want to pursue the default/runtime ring_mask change 
(another use case of this that i think is if user wants to know default 
config vs fused)

Tvrtko, Chris - what do you think?

+ fw_domain_fini(dev_priv, domain_id);
+    }
+
+    for (i = 0; i < I915_MAX_VECS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VEBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VECS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
+    fw_domain_fini(dev_priv, domain_id);
+    }
+    }
+}
+
  void intel_uncore_fini(struct drm_i915_private *dev_priv)
  {
  /* Paranoia: make sure we have disabled everything before 
we exit. */
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h

index 53ef77d..28feabf 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -129,6 +129,7 @@ struct intel_uncore {
    void intel_uncore_sanitize(struct drm_i915_private *dev_priv);
  void intel_uncore_init(struct drm_i915_private *dev_priv);
+void intel_uncore_prune(struct drm_i915_private *dev_priv);
  bool intel_uncore_unclaimed_mmio(struct drm_i915_private 
*dev_priv);
  bool intel_uncore_arm_unclaimed_mmio_detection(struct 
drm_i915_private *dev_priv);

  void intel_uncore_fini(struct drm_i915_private *dev_priv);














--
Thanks,
Sagar

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array
URL   : https://patchwork.freedesktop.org/series/39165/
State : warning

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-left-edge:
pass   -> DMESG-WARN (shard-snb)
Subgroup pipe-b-256x256-bottom-edge:
pass   -> DMESG-WARN (shard-snb)
Test pm_rpm:
Subgroup system-suspend-modeset:
incomplete -> PASS   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_flip:
Subgroup 2x-plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-pwrite:
pass   -> SKIP   (shard-snb) fdo#103167
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#99912
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755

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

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:7   skip:1632 
time:12195s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11850s
shard-snbtotal:3460 pass:1356 dwarn:3   dfail:0   fail:1   skip:2100 
time:6583s
Blacklisted hosts:
shard-kbltotal:3434 pass:1930 dwarn:1   dfail:0   fail:7   skip:1495 
time:9364s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8191/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 drm/i915: Add an option to disable SAGV

[Patchwork]

== Series Details ==

Series: drm/i915: Add an option to disable SAGV
URL   : https://patchwork.freedesktop.org/series/39161/
State : warning

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
pass   -> DMESG-WARN (shard-snb)
Test kms_vblank:
Subgroup pipe-c-ts-continuation-dpms-suspend:
fail   -> PASS   (shard-hsw)
Test pm_rc6_residency:
Subgroup rc6-accuracy:
pass   -> SKIP   (shard-snb)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
fail   -> PASS   (shard-hsw) k.org#196691
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-top-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
fail   -> PASS   (shard-hsw) fdo#105087
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887 +1
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#103928
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912
Test kms_vblank:
Subgroup pipe-c-ts-continuation-suspend:
fail   -> PASS   (shard-hsw) fdo#103540 +1

k.org#196691 https://bugzilla.kernel.org/show_bug.cgi?id=196691
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#105087 https://bugs.freedesktop.org/show_bug.cgi?id=105087
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:7   skip:1632 
time:12149s
shard-hswtotal:3446 pass:1754 dwarn:1   dfail:0   fail:3   skip:1686 
time:11290s
shard-snbtotal:3460 pass:1357 dwarn:3   dfail:0   fail:1   skip:2099 
time:6620s
Blacklisted hosts:
shard-kbltotal:3410 pass:1906 dwarn:16  dfail:0   fail:7   skip:1480 
time:9393s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v11,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Patchwork]

== Series Details ==

Series: series starting with [v11,1/6] drm/i915/guc: Rename guc_ggtt_offset to 
intel_guc_ggtt_offset
URL   : https://patchwork.freedesktop.org/series/39176/
State : failure

== Summary ==

Series 39176v1 series starting with [v11,1/6] drm/i915/guc: Rename 
guc_ggtt_offset to intel_guc_ggtt_offset
https://patchwork.freedesktop.org/api/1.0/series/39176/revisions/1/mbox/

 Possible new issues:

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-FAIL (fi-skl-gvtdvm)
Subgroup basic-reload:
pass   -> DMESG-FAIL (fi-skl-gvtdvm)
Subgroup basic-reload-inject:
pass   -> DMESG-FAIL (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-threads:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-files:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default-heavy:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd:
WARNING: Long output truncated

d8a07978aff3aef5cb6a8105ca4996cde837bd2f drm-tip: 2018y-02m-28d-21h-21m-07s UTC 
integration manifest
cb533c953af5 HAX Enable GuC Submission for CI
9ab4ac19f48b drm/i915/guc: Check the locking status of GuC WOPCM registers
1dbad0a3d83a drm/i915: Add HuC firmware size related restriction for Gen9 and 
CNL A0
7c95388257de drm/i915: Add support to return CNL specific reserved WOPCM size
90d692ac4183 drm/i915: Implement dynamic GuC WOPCM offset and size calculation
3f48b9f958af drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

== Logs ==

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

[Intel-gfx] [PATCH] sna/uxa: Fix colormap handling at screen depth 30.

[Mario Kleiner]

The various clut handling functions like a setup
consistent with the x-screen color depth. Otherwise
we observe improper sampling in the gamma tables
at depth 30.

Therefore replace hard-coded bitsPerRGB = 8 by actual
bits per channel scrn->rgbBits. Also use this for call
to xf86HandleColormaps().

Tested for uxa and sna at depths 8, 16, 24 and 30 on
IvyBridge, and tested at depth 24 and 30 that xgamma
and gamma table animations work, and with measurement
equipment to make sure identity gamma ramps actually
are identity mappings at the output.

Signed-off-by: Mario Kleiner 
---
 src/sna/sna_driver.c   | 5 +++--
 src/uxa/intel_driver.c | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c
index 2643e6c..9c4bcd4 100644
--- a/src/sna/sna_driver.c
+++ b/src/sna/sna_driver.c
@@ -1145,7 +1145,7 @@ sna_screen_init(SCREEN_INIT_ARGS_DECL)
if (!miInitVisuals(, , , , ,
   ,
   ((unsigned long)1 << (scrn->bitsPerPixel - 1)),
-  8, -1))
+  scrn->rgbBits, -1))
return FALSE;
 
if (!miScreenInit(screen, NULL,
@@ -1217,7 +1217,8 @@ sna_screen_init(SCREEN_INIT_ARGS_DECL)
return FALSE;
 
if (sna->mode.num_real_crtc &&
-   !xf86HandleColormaps(screen, 256, 8, sna_load_palette, NULL,
+   !xf86HandleColormaps(screen, 1 << scrn->rgbBits, scrn->rgbBits,
+sna_load_palette, NULL,
 CMAP_RELOAD_ON_MODE_SWITCH |
 CMAP_PALETTED_TRUECOLOR))
return FALSE;
diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index 3703c41..88c749e 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -991,7 +991,8 @@ I830ScreenInit(SCREEN_INIT_ARGS_DECL)
if (!miCreateDefColormap(screen))
return FALSE;
 
-   if (!xf86HandleColormaps(screen, 256, 8, I830LoadPalette, NULL,
+   if (!xf86HandleColormaps(screen, 1 << scrn->rgbBits, scrn->rgbBits,
+I830LoadPalette, NULL,
 CMAP_RELOAD_ON_MODE_SWITCH |
 CMAP_PALETTED_TRUECOLOR)) {
return FALSE;
-- 
2.7.4

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

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

[Rodrigo Vivi]

Hi Dave,

I have these same patches stashed since last week, but last week
I wasn't confident that CI was happy with these ones so I decided to
hold on. Now after running multiple times with and without the patches applied
I see that it was only a fix on test case, which is now catching old bugs

So I'm now convinced that these patches here are good to go.

And no new fix this week.

Here goes drm-intel-fixes-2018-02-28:

- 2 display fixes: audio av_enc_map overflow check, and Cannonlake PLL related 
register offset.
- 3 gem fixes: Clear for in-fence out-fence, fix for clearing exec_flags on 
execbuf failure, and add back global seqno to tracepoints that had been removed 
recently by other fence related patch.

Thanks,
Rodrigo.

The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb:

  Linux 4.16-rc3 (2018-02-25 18:50:41 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-02-28

for you to fetch changes up to fa89782b4f9c40d40e3f7d9ad7ef14e0bb0c3ca0:

  drm/i915: Make global seqno known in i915_gem_request_execute tracepoint 
(2018-02-28 11:10:48 -0800)


- 2 display fixes: audio av_enc_map overflow check, and Cannonlake PLL related 
register offset.
- 3 gem fixes: Clear for in-fence out-fence, fix for clearing exec_flags on 
execbuf failure, and add back global seqno to tracepoints that had been removed 
recently by other fence related patch.


Chris Wilson (1):
  drm/i915: Clear the in-use marker on execbuf failure

Daniele Ceraolo Spurio (1):
  drm/i915: Fix rsvd2 mask when out-fence is returned

Jani Nikula (1):
  drm/i915/audio: fix check for av_enc_map overflow

Mahesh Kumar (1):
  drm/i915/cnl: Fix PORT_TX_DW5/7 register address

Tvrtko Ursulin (1):
  drm/i915: Make global seqno known in i915_gem_request_execute tracepoint

 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++-
 drivers/gpu/drm/i915/i915_gem_request.c| 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 4 ++--
 drivers/gpu/drm/i915/intel_audio.c | 6 +++---
 4 files changed, 10 insertions(+), 8 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v11 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Jackie Li]

GuC related exported functions should start with "intel_guc_" prefix and
pass intel_guc as the first parameter since its GuC related. Current
guc_ggtt_offset() failed to follow this code convention and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offset against the GuC WOPCM top.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates
the related code to pass intel_guc pointer to this function call, so that
we can have a unified coding style for GuC code and also enable the future
patches to get GuC related data from intel_guc to do the offset
verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
intel_guc_regs.h to intel_guc.h since it is not GuC register related
definition.

v8:
 - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar)
 - Updated commit message to explain to reason and motivation to add
   intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)

v9:
 - Fixed code alignment issue due to line break (Chris)

v10:
 - Removed unnecessary comments, redundant code and avoided reuse variable
   to avoid potential issues (Joonas)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc.c| 11 ++-
 drivers/gpu/drm/i915/intel_guc.h| 14 --
 drivers/gpu/drm/i915/intel_guc_ads.c|  8 
 drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
 drivers/gpu/drm/i915/intel_guc_fw.c |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h|  3 ---
 drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
 drivers/gpu/drm/i915/intel_huc.c|  6 --
 9 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e6512cc..a788e15 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -269,8 +269,9 @@ void intel_guc_init_params(struct intel_guc *guc)
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
-   u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-   u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+   u32 ads = intel_guc_ggtt_offset(guc,
+   guc->ads_vma) >> PAGE_SHIFT;
+   u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
 
params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
@@ -418,7 +419,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -441,7 +442,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   data[6] = guc_ggtt_offset(guc->shared_data);
+   data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -463,7 +464,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..0c8b10a 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -100,13 +100,23 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
 }
 
-/*
+/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
+#define GUC_GGTT_TOP   0xFEE0
+
+/**
+ * intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
+ * @guc: intel_guc structure.
+ * @vma: i915 graphics virtual memory area.
+ *
  * GuC does not allow any gfx GGTT address that falls into range [0, 
WOPCM_TOP),
  * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address 
is
  * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
  * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets the GuC 

[Intel-gfx] [PATCH v11 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Jackie Li]

GuC WOPCM registers are write-once registers. Current driver code accesses
these registers without checking the accessibility to these registers which
will lead to unpredictable driver behaviors if these registers were touch
by other components (such as faulty BIOS code).

This patch moves the GuC WOPCM registers updating code into
intel_guc_wopcm.c and adds check before and after the update to GuC WOPCM
registers so that we can make sure the driver is in a known state before
and after writing to these write-once registers.

v6:
 - Made sure module reloading won't bug the kernel while doing
   locking status checking

v7:
 - Fixed patch format issues

v8:
 - Fixed coding style issue on register lock bit macro definition (Sagar)

v9:
 - Avoided to use redundant !! to cast uint to bool (Chris)
 - Return error code instead of GEM_BUG_ON for locked with invalid register
   values case (Sagar)
 - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
 - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
   WOPCM offset register based on the presence of HuC firmware (Michal)
 - Use bit fields instead of macros for GuC WOPCM flags (Michal)

v10:
 - Refined variable names, removed redundant comments (Joonas)
 - Introduced lockable_reg to handle the write once register write and
   propagate the write error to caller (Joonas)
 - Used lockable_reg abstraction to avoid locking bit check on generic
   i915_reg_t (Michal)
 - Added log message for error paths (Michal)
 - Removed hw_updated flag and only relies on real hardware status

v11:
 - Replaced lockable_reg with simplified function (Michal)
 - Used new macros for locking bits of WOPCM size/offset registers instead
   of using BIT(0) directly (Michal)
 - use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC
   WOPCM register setup instead of calling from intel_uc_init_hw() (Michal)

BSpec: 10875, 10833

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_gem.c  |  6 
 drivers/gpu/drm/i915/intel_guc_reg.h |  3 ++
 drivers/gpu/drm/i915/intel_uc.c  |  5 ---
 drivers/gpu/drm/i915/intel_wopcm.c   | 63 
 drivers/gpu/drm/i915/intel_wopcm.h   |  1 +
 5 files changed, 73 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d31ad0b..662d670 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5122,6 +5122,12 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
goto out;
}
 
+   ret = intel_wopcm_init_hw(_priv->wopcm);
+   if (ret) {
+   DRM_ERROR("Enabling WOPCM failed (%d)\n", ret);
+   goto out;
+   }
+
/* We can't enable contexts until all firmware is loaded */
ret = intel_uc_init_hw(dev_priv);
if (ret) {
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 01963d0..d860847 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -66,15 +66,18 @@
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   GUC_WOPCM_OFFSET_VALID (1<<0)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define   GUC_WOPCM_OFFSET_SHIFT   14
+#define   GUC_WOPCM_OFFSET_MASK  (0x3 << 
GUC_WOPCM_OFFSET_SHIFT)
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
 #define HUC_STATUS2 _MMIO(0xD3B0)
 #define   HUC_FW_VERIFIED   (1<<7)
 
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
+#define   GUC_WOPCM_SIZE_LOCKED  (1<<0)
 #define   GUC_WOPCM_SIZE_SHIFT 12
 #define   GUC_WOPCM_SIZE_MASK(0xf << GUC_WOPCM_SIZE_SHIFT)
 
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 964e49f..58186f2 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -341,11 +341,6 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
 
-   /* init WOPCM */
-   I915_WRITE(GUC_WOPCM_SIZE, dev_priv->wopcm.guc.size);
-   I915_WRITE(DMA_GUC_WOPCM_OFFSET,
-  dev_priv->wopcm.guc.base | HUC_LOADING_AGENT_GUC);
-
/* WaEnableuKernelHeaderValidFix:skl */
/* WaEnableGuCBootHashCheckNotSet:skl,bxt,kbl */
if (IS_GEN9(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index b30d7ff..2d9103a 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -219,3 +219,66 @@ 

[Intel-gfx] [PATCH v11 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

[Jackie Li]

On CNL A0 and Gen9, there's a hardware restriction that requires the
available GuC WOPCM size to be larger than or equal to HuC firmware size.

This patch adds new verification code to ensure the available GuC WOPCM
size to be larger than or equal to HuC firmware size on both Gen9 and CNL
A0.

v6:
 - Extended HuC FW size check against GuC WOPCM size to all
   Gen9 and CNL A0 platforms

v7:
 - Fixed patch format issues

v8:
 - Renamed variables and functions to avoid ambiguity (Joonas)
 - Updated commit message and comments to be more comprehensive (Sagar)

v9:
 - Moved code that is not related to restriction check into a separate
   patch and updated the commit message accordingly (Sagar/Michal)
 - Avoided to call uc_get_fw_size for better layer isolation (Michal)

v10:
 - Shorten function names and reorganized size_check code to have clear
   isolation (Joonas)
 - Removed unnecessary comments (Joonas)

v11:
 - Fixed logic error in size check (Michal)

BSpec: 10875

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index bb78043..b30d7ff 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -107,8 +107,26 @@ static inline int gen9_check_dword_gap(u32 guc_wopcm_base, 
u32 guc_wopcm_size)
return 0;
 }
 
+static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 huc_fw_size)
+{
+   /*
+* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
+* size to be larger than or equal to HuC firmware size. Otherwise,
+* firmware uploading would fail.
+*/
+   if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
+   DRM_ERROR("HuC fw(%uKiB) won't fit in GuC WOPCM(%uKiB).\n",
+ huc_fw_size / 1024,
+ (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);
+   return -E2BIG;
+   }
+
+   return 0;
+}
+
 static inline int check_hw_restriction(struct drm_i915_private *i915,
-  u32 guc_wopcm_base, u32 guc_wopcm_size)
+  u32 guc_wopcm_base, u32 guc_wopcm_size,
+  u32 huc_fw_size)
 {
int err = 0;
 
@@ -117,7 +135,10 @@ static inline int check_hw_restriction(struct 
drm_i915_private *i915,
if (err)
return err;
 
-   return 0;
+   if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+   err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+
+   return err;
 }
 
 /**
@@ -186,7 +207,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
return -E2BIG;
}
 
-   err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size);
+   err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+  huc_fw_size);
if (err) {
DRM_ERROR("Failed to meet HW restriction.\n");
return err;
-- 
2.7.4

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

[Intel-gfx] [PATCH v11 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

[Jackie Li]

Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than the
value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will lead to GuC firmware execution failures. On the other hand, with
current static GuC WOPCM offset and size values (512KB for both offset and
size), the GuC WOPCM size verification will fail on Gen9 even if it can be
fixed by lowering the GuC WOPCM offset by calculating its value based on
HuC firmware size (which is likely less than 200KB on Gen9), so that we can
have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
size check.

This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support
to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To
meet all above requirements, let's provide dynamic partitioning of the
WOPCM that will be based on platform specific HuC/GuC firmware sizes.

v2:
 - Removed intel_wopcm_init (Ville/Sagar/Joonas)
 - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
 - Removed unnecessary function calls (Joonas)
 - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
 - Fixed indentation issues (Chris)
 - Removed layering violation code (Chris/Michal)
 - Created separat files for GuC wopcm code  (Michal)
 - Used inline function to avoid code duplication (Michal)

v4:
 - Preset the GuC WOPCM top during early GuC init (Chris)
 - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

v5:
 - Moved GuC DMA WOPCM register updating code into intel_wopcm.c
 - Took care of the locking status before writing to GuC DMA
   Write-Once registers. (Joonas)

v6:
 - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)

v8:
 - Updated comments and fixed naming issues (Sagar/Joonas)
 - Updated commit message to include more description about the hardware
   restriction on GuC WOPCM size (Sagar)

v9:
 - Minor changes variable names and code comments (Sagar)
 - Added detailed GuC WOPCM layout drawing (Sagar/Michal)
 - Refined macro definitions to be reader friendly (Michal)
 - Removed redundent check to valid flag (Michal)
 - Unified first parameter for exported GuC WOPCM functions (Michal)
 - Refined the name and parameter list of hardware restriction checking
   functions (Michal)

v10:
 - Used shorter function name for internal functions (Joonas)
 - Moved init-ealry function into c file (Joonas)
 - Consolidated and removed redundant size checks (Joonas/Michal)
 - Removed unnecessary unlikely() from code which is only called once
   during boot (Joonas)
 - More fixes to kernel-doc format and content (Michal)
 - Avoided the use of PAGE_MASK for 4K pages (Michal)
 - Added error log messages to error paths (Michal)

v11:
 - Replaced intel_guc_wopcm with more generic intel_wopcm and attached
   intel_wopcm to drm_i915_private instead intel_guc (Michal)
 - dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top
   offset from GuC WOPCM base) (Michal)
 - Moved WOPCM marco definitions into .c source file (Michal)
 - Exported WOPCM layout diagram as kernel-doc (Michal)

Bspec: 12690

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/Makefile   |   3 +-
 drivers/gpu/drm/i915/i915_drv.c |   1 +
 drivers/gpu/drm/i915/i915_drv.h |   8 ++
 drivers/gpu/drm/i915/i915_gem.c |   4 +
 drivers/gpu/drm/i915/i915_gem_context.c |   5 +-
 drivers/gpu/drm/i915/intel_guc.c|  66 ---
 drivers/gpu/drm/i915/intel_guc.h|  16 ++-
 drivers/gpu/drm/i915/intel_guc_reg.h|   8 +-
 drivers/gpu/drm/i915/intel_huc.c|   2 +-
 drivers/gpu/drm/i915/intel_uc.c |   6 +-
 drivers/gpu/drm/i915/intel_uc_fw.c  |  13 +--
 drivers/gpu/drm/i915/intel_uc_fw.h  |  16 +++
 drivers/gpu/drm/i915/intel_wopcm.c  | 195 
 drivers/gpu/drm/i915/intel_wopcm.h  |  34 ++
 14 files changed, 337 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_wopcm.c
 create mode 100644 drivers/gpu/drm/i915/intel_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 881d712..652549e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,7 

[Intel-gfx] [PATCH v11 3/6] drm/i915: Add support to return CNL specific reserved WOPCM size

[Jackie Li]

CNL has its specific reserved GuC WOPCM size for RC6 and other hardware
contexts.

This patch updates the code to return CNL specific reserved GuC WOPCM size
for RC6 and other hardware contexts so that the GuC WOPCM size can be
calculated correctly for CNL.

v9:
 - Created a new patch for these changes originally made in v8 4/6 patch of
   this series (Sagar/Michal)

v10:
 - Used if-else ladder to the returning of context sizes (Joonas)

v11:
 - Removed GUC_ prefix from context size macro (Michal)

Bspec: 12690

Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 83516c9..bb78043 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -54,6 +54,8 @@
 
 /* 24KB at the end of WOPCM is reserved for RC6 CTX on BXT. */
 #define BXT_WOPCM_RC6_CTX_RESERVED (24 * 1024)
+/* 36KB WOPCM reserved at the end of WOPCM on CNL. */
+#define CNL_WOPCM_HW_CTX_RESERVED  (36 * 1024)
 
 /* 128KB from GUC_WOPCM_RESERVED is reserved for FW on Gen9. */
 #define GEN9_GUC_FW_RESERVED   (128 * 1024)
@@ -78,6 +80,8 @@ static inline u32 context_reserved_size(struct 
drm_i915_private *i915)
 {
if (IS_GEN9_LP(i915))
return BXT_WOPCM_RC6_CTX_RESERVED;
+   else if (INTEL_GEN(i915) >= 10)
+   return CNL_WOPCM_HW_CTX_RESERVED;
else
return 0;
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH v11 6/6] HAX Enable GuC Submission for CI

[Jackie Li]

Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..b49ae20 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -152,7 +152,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
 i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.7.4

___
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/guc: Removed unused GuC parameters.

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Removed unused GuC parameters.
URL   : https://patchwork.freedesktop.org/series/39154/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-right-edge:
pass   -> DMESG-WARN (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-xrgb-mmap-cpu-xtiled:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-badstride:
pass   -> FAIL   (shard-apl) fdo#101623

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

shard-apltotal:3434 pass:1794 dwarn:2   dfail:0   fail:14  skip:1622 
time:11971s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11804s
shard-snbtotal:3460 pass:1358 dwarn:2   dfail:0   fail:1   skip:2099 
time:6621s
Blacklisted hosts:
shard-kbltotal:3265 pass:1744 dwarn:29  dfail:1   fail:14  skip:1474 
time:8753s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8189/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/skl+: Add and enable DP AUX CH mutex

[Souza, Jose]

On Wed, 2018-02-28 at 13:09 +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote:
> > On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
> > > wrote:
> > > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions
> > > > by it
> > > > self, so lets use the mutex register that is available in gen9+
> > > > to
> > > > avoid concurrent access by hardware and driver.
> > > > Older gen handling will be done separated.
> > > > 
> > > > Reference: https://01.org/sites/default/files/documentation/int
> > > > el-g
> > > > fx-prm-osrc-skl-vol12-display.pdf
> > > > Page 198 - AUX programming sequence
> > > > 
> > > > Reviewed-by: Dhinakaran Pandiyan  > > > >
> > > > Reviewed-by: Rodrigo Vivi 
> > > > Cc: Jani Nikula 
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > > 
> > > > Changelog:
> > > > v2
> > > > - removed the PSR dependency, now getting lock all the times
> > > > when
> > > > available
> > > > - renamed functions to avoid nested calls
> > > > - moved register bits right after the DP_AUX_CH_MUTEX()
> > > > - removed 'drm/i915: keep AUX powered while PSR is enabled'
> > > > Dhinakaran Pandiyan will sent a better and final version
> > > > v3
> > > > - rebased on top of Ville's AUX series
> > > > - moved port registers to above DP_AUX_CH_MUTEX()
> > > > - using intel_wait_for_register() instead of the internal
> > > > version
> > > > v4
> > > > - removed virtual function to get mutex register address
> > > > - enabling the mutex back only on aux channel init
> > > > - added the aux channel name to the timeout debug message
> > > > v5
> > > > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> > > > - renamed goto label when intel_dp_aux_ch_trylock() fails
> > > > 
> > > >  drivers/gpu/drm/i915/i915_reg.h |  9 
> > > >  drivers/gpu/drm/i915/intel_dp.c | 47
> > > > +
> > > >  2 files changed, 56 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index eea5b2c537d4..bce2e6dad4c4 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -5385,6 +5385,15 @@ enum {
> > > >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> > > >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> > > >  
> > > > +#define _DPA_AUX_CH_MUTEX  (dev_priv-
> > > > > info.display_mmio_offset + 0x6402C)
> > > > 
> > > > +#define _DPB_AUX_CH_MUTEX  (dev_priv-
> > > > > info.display_mmio_offset + 0x6412C)
> > > > 
> > > > +#define _DPC_AUX_CH_MUTEX  (dev_priv-
> > > > > info.display_mmio_offset + 0x6422C)
> > > > 
> > > > +#define _DPD_AUX_CH_MUTEX  (dev_priv-
> > > > > info.display_mmio_offset + 0x6432C)
> > > > 
> > > > +#define _DPF_AUX_CH_MUTEX  (dev_priv-
> > > > > info.display_mmio_offset + 0x6452C)
> > > > 
> > > > +#define DP_AUX_CH_MUTEX(aux_ch)_MMIO_PORT(aux_ch,
> > > > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> > > > +#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
> > > > +#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
> > > > +
> > > >  /*
> > > >   * Computing GMCH M and N values for the Display Port link
> > > >   *
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 2a3b3ae4e3da..7f4bf77227cd 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -1081,6 +1081,42 @@ static uint32_t
> > > > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > > > aux_clock_divi
> > > > der)
> > > > ;
> > > >  }
> > > >  
> > > > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > > > +{
> > > > +   struct intel_digital_port *intel_dig_port =
> > > > dp_to_dig_port(intel_dp);
> > > > +   struct drm_i915_private *dev_priv =
> > > > +   to_i915(intel_dig_port-
> > > > >base.base.dev);
> > > > +
> > > > +   if (INTEL_GEN(dev_priv) < 9)
> > > > +   return true;
> > > > +
> > > > +   /* Spec says that mutex is acquired when status bit is
> > > > read as unset,
> > > > +* here waiting for 2msec(+-4 aux transactions) before
> > > > give up.
> > > > +*/
> > > > +   if (intel_wait_for_register(dev_priv,
> > > > DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > > > +   DP_AUX_CH_MUTEX_STATUS, 0,
> > > > 2))
> > > > {
> > > > +   DRM_DEBUG_KMS("aux channel %c locked for
> > > > 2msec,
> > > > timing out\n",
> > > > + aux_ch_name(intel_dp->aux_ch));
> > > > +   return false;
> > > > +   }
> > > > +
> > > > +   

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Pandiyan, Dhinakaran]

On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote:
> > > 
> > > 
> > > 
> > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > >>> Preparing a framebuffer should not require a flush. 
> > > > >>> _post_plane_update()
> > > > >>> takes care of flushing when a flip is scheduled, this should be
> > > > >>> sufficient for PSR and FBC.
> > > > >> Makes sense.
> > > > >>  
> > > > > I also think this might speed up the flips a bit by avoiding flushes. 
> > > > >
> > > > >>> Cc: Paulo Zanoni 
> > > > >>> Cc: Ville Syrjälä 
> > > > >>> Cc: Chris Wilson 
> > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > >> Also
> > > > >> Cc: Maarten Lankhorst 
> > > > >> to validate the flow through atomic.
> > > > >> -Chris
> > > > >>
> > > > Page flips used to do intel_frontbuffer_flip_prepare here, followed by 
> > > > intel_frontbuffer_flip_complete. I think it would make sense to change 
> > > > the patch to do that?
> > > > 
> > > 
> > > I have no context why it was removed, I'll have to understand that
> > > change and get back to you.
> > 
> > Since we supposedly have hw nuke for both fbc and psr there doesn't seem
> > to be much need to do anything for flips. I guess DRRS is the only
> > thing that kinda needs it (not really, just avoids flipping with the
> > slow timings). But I think DRRS should really be tied into the vblank
> > stuff somehow so that we switch to the fast timings whenever a vblank
> > interrupts are enabled.
> 
> Oh, I guess VLV/CHV PSR is what would need this. To do that properly
> (ie. main link off) I think we'd basically need to do a full modeset
> when exiting PSR, so it should probably handled somewhere higher up
> during modeset, and for other uses the frontbuffer tracking
> should perhaps just schedule a work to do the full modeset.
> 
The mention of "full modeset" got me thinking. I believe you said full
modeset because the link needs to be trained on PSR exit if it was off.
But, link off isn't supported on VLV/CHV

else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
/* On VLV and CHV only standby mode is supported. */
dev_priv->psr.link_standby = true;


So we are good here?



___
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/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array
URL   : https://patchwork.freedesktop.org/series/39165/
State : success

== Summary ==

Series 39165v1 drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array
https://patchwork.freedesktop.org/api/1.0/series/39165/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:378s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:394s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:452s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:493s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:496s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:436s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:520s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s

d8a07978aff3aef5cb6a8105ca4996cde837bd2f drm-tip: 2018y-02m-28d-21h-21m-07s UTC 
integration manifest
957ad814bc0e drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array

== Logs ==

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

Re: [Intel-gfx] [igt-dev] [PATCH igt 5/5] igt/gem_exec_fence: Exercise merging fences

[Antonio Argenziano]

On 28/02/18 07:51, Chris Wilson wrote:

Execute the same batch on each engine and check that the composite fence
across all engines completes only after the batch is completed on every
engine.

Signed-off-by: Chris Wilson 


LGTM.

Reviewed-by: Antonio Argenziano 


---
  tests/gem_exec_fence.c | 127 +
  1 file changed, 127 insertions(+)

diff --git a/tests/gem_exec_fence.c b/tests/gem_exec_fence.c
index 93ed3b9b..36459e56 100644
--- a/tests/gem_exec_fence.c
+++ b/tests/gem_exec_fence.c
@@ -208,6 +208,113 @@ static void test_fence_busy(int fd, unsigned ring, 
unsigned flags)
gem_quiescent_gpu(fd);
  }
  
+static void test_fence_busy_all(int fd, unsigned flags)

+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   struct drm_i915_gem_exec_object2 obj;
+   struct drm_i915_gem_relocation_entry reloc;
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct timespec tv;
+   uint32_t *batch;
+   unsigned int engine;
+   int all, i, timeout;
+
+   gem_quiescent_gpu(fd);
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer();
+   execbuf.buffer_count = 1;
+
+   memset(, 0, sizeof(obj));
+   obj.handle = gem_create(fd, 4096);
+
+   obj.relocs_ptr = to_user_pointer();
+   obj.relocation_count = 1;
+   memset(, 0, sizeof(reloc));
+
+   batch = gem_mmap__wc(fd, obj.handle, 0, 4096, PROT_WRITE);
+   gem_set_domain(fd, obj.handle,
+  I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+
+   reloc.target_handle = obj.handle; /* recurse */
+   reloc.presumed_offset = 0;
+   reloc.offset = sizeof(uint32_t);
+   reloc.delta = 0;
+   reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
+   reloc.write_domain = 0;
+
+   i = 0;
+   batch[i] = MI_BATCH_BUFFER_START;
+   if (gen >= 8) {
+   batch[i] |= 1 << 8 | 1;
+   batch[++i] = 0;
+   batch[++i] = 0;
+   } else if (gen >= 6) {
+   batch[i] |= 1 << 8;
+   batch[++i] = 0;
+   } else {
+   batch[i] |= 2 << 6;
+   batch[++i] = 0;
+   if (gen < 4) {
+   batch[i] |= 1;
+   reloc.delta = 1;
+   }
+   }
+   i++;
+
+   all = -1;
+   for_each_engine(fd, engine) {
+   int fence, new;
+
+   execbuf.flags = engine | LOCAL_EXEC_FENCE_OUT;
+   execbuf.rsvd2 = -1;
+   gem_execbuf_wr(fd, );
+   fence = execbuf.rsvd2 >> 32;
+   igt_assert(fence != -1);
+
+   if (all < 0) {
+   all = fence;
+   break;
+   }
+
+   new = sync_fence_merge(all, fence);
+   igt_assert_lte(0, new);
+   close(all);
+   close(fence);
+
+   all = new;
+   }
+
+   igt_assert(gem_bo_busy(fd, obj.handle));
+   igt_assert(fence_busy(all));
+
+   timeout = 120;
+   if ((flags & HANG) == 0) {
+   *batch = MI_BATCH_BUFFER_END;
+   __sync_synchronize();
+   timeout = 1;
+   }
+   munmap(batch, 4096);
+
+   if (flags & WAIT) {
+   struct pollfd pfd = { .fd = all, .events = POLLIN };
+   igt_assert(poll(, 1, timeout*1000) == 1);
+   } else {
+   memset(, 0, sizeof(tv));
+   while (fence_busy(all))
+   igt_assert(igt_seconds_elapsed() < timeout);
+   }
+
+   igt_assert(!gem_bo_busy(fd, obj.handle));
+   igt_assert_eq(sync_fence_status(all),
+ flags & HANG ? -EIO : SYNC_FENCE_OK);


Do you get -EIO also if only one engine hangs?

Thanks,
Antonio


+
+   close(all);
+   gem_close(fd, obj.handle);
+
+   gem_quiescent_gpu(fd);
+}
+
  static void test_fence_await(int fd, unsigned ring, unsigned flags)
  {
const int gen = intel_gen(intel_get_drm_devid(fd));
@@ -1465,6 +1572,26 @@ igt_main
gem_submission_print_method(i915);
}
  
+	igt_subtest_group {

+   igt_fixture {
+   igt_fork_hang_detector(i915);
+   }
+
+   igt_subtest("basic-busy-all")
+   test_fence_busy_all(i915, 0);
+   igt_subtest("basic-wait-all")
+   test_fence_busy_all(i915, WAIT);
+
+   igt_fixture {
+   igt_stop_hang_detector();
+   }
+
+   igt_subtest("busy-hang-all")
+   test_fence_busy_all(i915, HANG);
+   igt_subtest("wait-hang-all")
+   test_fence_busy_all(i915, WAIT | HANG);
+   }
+
for (e = intel_execution_engines; e->name; e++) {
igt_subtest_group {
igt_fixture {

[Intel-gfx] [PATCH v2] drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array

[Manasi Navare]

dp_rates[] array is a superset of all the link rates supported
by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
to the set of link rates supported by sink. This patch adds this rate
to dp_rates[] array that gets used to populate the sink_rates[]
array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register.

v2:
* Rebased on top of Jani's localized rates patch

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 750c25a..aba2f45 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -136,7 +136,7 @@ static void intel_dp_unset_edid(struct intel_dp *intel_dp);
 static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
 {
static const int dp_rates[] = {
-   162000, 27, 54
+   162000, 27, 54, 81
};
int i, max_rate;
 
-- 
2.7.4

___
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: Wedged engine mask makes more sense in hex

[Patchwork]

== Series Details ==

Series: drm/i915: Wedged engine mask makes more sense in hex
URL   : https://patchwork.freedesktop.org/series/39147/
State : failure

== Summary ==

 Possible new issues:

Test kms_draw_crc:
Subgroup draw-method-xrgb-mmap-cpu-xtiled:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-hsw)
Test pm_rc6_residency:
Subgroup rc6-accuracy:
skip   -> PASS   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#105087
Test kms_flip:
Subgroup 2x-plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +2
Subgroup dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

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

shard-apltotal:3434 pass:1805 dwarn:1   dfail:0   fail:6   skip:1621 
time:11765s
shard-hswtotal:3370 pass:1721 dwarn:1   dfail:0   fail:3   skip:1642 
time:10990s
shard-snbtotal:3460 pass:1360 dwarn:1   dfail:0   fail:1   skip:2098 
time:6630s
Blacklisted hosts:
shard-kbltotal:3434 pass:1927 dwarn:1   dfail:0   fail:8   skip:1497 
time:9271s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

[Michel Thierry]

On 28/02/18 12:26, Michel Thierry wrote:

On 28/02/18 10:42, Piotr Piórkowski wrote:

In the i915 driver, there is a function, intel_guc_init_params(),
which initializes the GuC parameter block which is passed into
the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
GfxGtType and GfxCoreFamily unused by GuC.

This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
GfxCoreFamily parameters and also unnecessary functions
get_gt_type() and get_core_family().



Hi,

Looking at the fw code, you're partially right, GfxGtType is ignored... 
but GfxCoreFamily isn't.




Unless whoever wrote the fw was smart enough to forget to call the 
function that is reading GfxCoreFamily... I didn't count on that.


So yes, guc couldn't care less about what value we put in GfxCoreFamily.

Then I would also remove the defines from intel_guc_fwif.h:

--#define GUC_CORE_FAMILY_GEN912
--#define GUC_CORE_FAMILY_UNKNOWN 0x7fff

-Michel

If you don't pass a known GfxCoreFamily, SLPC will be disabled (enabling 
SLPC is in some manager's wish list). Also it seems nobody remembered to 
add GUC_CORE_FAMILY_GEN10 for CNL.



Signed-off-by: Piotr Piórkowski 
---
  drivers/gpu/drm/i915/i915_params.h    |  2 +-
  drivers/gpu/drm/i915/intel_guc.c  | 24 
  drivers/gpu/drm/i915/intel_guc_fwif.h |  4 
  drivers/gpu/drm/i915/intel_uc.c   |  2 ++
  4 files changed, 3 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h

index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
  param(int, disable_power_well, -1) \
  param(int, enable_ips, 1) \
  param(int, invert_brightness, 0) \
-    param(int, enable_guc, 0) \
+    param(int, enable_guc, -1) \


This shouldn't be part of your patch, enable guc submission in a 2nd 
patch, for example: [PATCH 2/2] HAX: Enable GuC submission for CI



  param(int, guc_log_level, 0) \
  param(char *, guc_firmware_path, NULL) \
  param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 21140ccd7a97..5f6d84251830 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
  guc_shared_data_destroy(guc);
  }
-static u32 get_gt_type(struct drm_i915_private *dev_priv)
-{
-    /* XXX: GT type based on PCI device ID? field seems unused by fw */
-    return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-    u32 gen = INTEL_GEN(dev_priv);
-
-    switch (gen) {
-    case 9:
-    return GUC_CORE_FAMILY_GEN9;
-
-    default:
-    MISSING_CASE(gen);
-    return GUC_CORE_FAMILY_UNKNOWN;
-    }
-}
-
  static u32 get_log_verbosity_flags(void)
  {
  if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
  memset(params, 0, sizeof(params));
-    params[GUC_CTL_DEVICE_INFO] |=
-    (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-    (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
  /*
   * GuC ARAT increment is 10 ns. GuC default scheduler quantum is 
one

   * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h

index 6a10aa6f04d3..0f381de44722 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -81,10 +81,6 @@
  #define GUC_CTL_ARAT_HIGH    1
  #define GUC_CTL_ARAT_LOW    2
-#define GUC_CTL_DEVICE_INFO    3
-#define   GUC_CTL_GT_TYPE_SHIFT    0
-#define   GUC_CTL_CORE_FAMILY_SHIFT    7
-
  #define GUC_CTL_LOG_PARAMS    4
  #define   GUC_LOG_VALID    (1 << 0)
  #define   GUC_LOG_NOTIFY_ON_HALF_FULL    (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 9f1bac6398fb..b48056fb769d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct 
drm_i915_private *dev_priv)

  enable_guc |= ENABLE_GUC_LOAD_HUC;
  /* Any platform specific fine-tuning can be done here */
+    if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+    enable_guc = 0;


This is also part of [PATCH 2/2] HAX: Enable GuC submission for CI


  return enable_guc;
  }



-Michel

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

Re: [Intel-gfx] [RFC] drm/i915/dp: move link rate arrays where they're used

[Jani Nikula]

On Wed, 28 Feb 2018, Manasi Navare  wrote:
> On Tue, Feb 27, 2018 at 12:59:11PM +0200, Jani Nikula wrote:
>> Localize link rate arrays by moving them to the functions where they're
>> used. Further clarify the distinction between source and sink
>> capabilities. Split pre and post Haswell arrays, and get rid of the
>> array size arithmetics. Use a direct rate value in the paranoia case of
>> no common rates find.
>> 
>> Cc: Manasi Navare 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Manasi Navare 

Auch, I hit enter before I saw this. Pushed to dinq, thanks for the
reviews, and apologies for failing to record yours in the commit.

BR,
Jani.


>
> manasi
>
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 44 
>> +
>>  1 file changed, 27 insertions(+), 17 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 801a21b16004..6fa6583b16bd 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -96,15 +96,6 @@ static const struct dp_link_dpll chv_dpll[] = {
>>  { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
>>  };
>>  
>> -static const int bxt_rates[] = { 162000, 216000, 243000, 27,
>> -  324000, 432000, 54 };
>> -static const int skl_rates[] = { 162000, 216000, 27,
>> -  324000, 432000, 54 };
>> -static const int cnl_rates[] = { 162000, 216000, 27,
>> - 324000, 432000, 54,
>> - 648000, 81 };
>> -static const int default_rates[] = { 162000, 27, 54 };
>> -
>>  /**
>>   * intel_dp_is_edp - is the given port attached to an eDP panel (either CPU 
>> or PCH)
>>   * @intel_dp: DP struct
>> @@ -144,14 +135,17 @@ static void intel_dp_unset_edid(struct intel_dp 
>> *intel_dp);
>>  /* update sink rates from dpcd */
>>  static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
>>  {
>> +static const int dp_rates[] = {
>> +162000, 27, 54
>> +};
>>  int i, max_rate;
>>  
>>  max_rate = 
>> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>>  
>> -for (i = 0; i < ARRAY_SIZE(default_rates); i++) {
>> -if (default_rates[i] > max_rate)
>> +for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
>> +if (dp_rates[i] > max_rate)
>>  break;
>> -intel_dp->sink_rates[i] = default_rates[i];
>> +intel_dp->sink_rates[i] = dp_rates[i];
>>  }
>>  
>>  intel_dp->num_sink_rates = i;
>> @@ -268,6 +262,22 @@ static int cnl_max_source_rate(struct intel_dp 
>> *intel_dp)
>>  static void
>>  intel_dp_set_source_rates(struct intel_dp *intel_dp)
>>  {
>> +/* The values must be in increasing order */
>> +static const int cnl_rates[] = {
>> +162000, 216000, 27, 324000, 432000, 54, 648000, 81
>> +};
>> +static const int bxt_rates[] = {
>> +162000, 216000, 243000, 27, 324000, 432000, 54
>> +};
>> +static const int skl_rates[] = {
>> +162000, 216000, 27, 324000, 432000, 54
>> +};
>> +static const int hsw_rates[] = {
>> +162000, 27, 54
>> +};
>> +static const int g4x_rates[] = {
>> +162000, 27
>> +};
>>  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>>  struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>>  const struct ddi_vbt_port_info *info =
>> @@ -290,11 +300,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>>  size = ARRAY_SIZE(skl_rates);
>>  } else if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
>> IS_BROADWELL(dev_priv)) {
>> -source_rates = default_rates;
>> -size = ARRAY_SIZE(default_rates);
>> +source_rates = hsw_rates;
>> +size = ARRAY_SIZE(hsw_rates);
>>  } else {
>> -source_rates = default_rates;
>> -size = ARRAY_SIZE(default_rates) - 1;
>> +source_rates = g4x_rates;
>> +size = ARRAY_SIZE(g4x_rates);
>>  }
>>  
>>  if (max_rate && vbt_max_rate)
>> @@ -356,7 +366,7 @@ static void intel_dp_set_common_rates(struct intel_dp 
>> *intel_dp)
>>  
>>  /* Paranoia, there should always be something in common. */
>>  if (WARN_ON(intel_dp->num_common_rates == 0)) {
>> -intel_dp->common_rates[0] = default_rates[0];
>> +intel_dp->common_rates[0] = 162000;
>>  intel_dp->num_common_rates = 1;
>>  }
>>  }
>> -- 
>> 2.11.0
>> 

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add an option to disable SAGV

[Patchwork]

== Series Details ==

Series: drm/i915: Add an option to disable SAGV
URL   : https://patchwork.freedesktop.org/series/39161/
State : success

== Summary ==

Series 39161v1 drm/i915: Add an option to disable SAGV
https://patchwork.freedesktop.org/api/1.0/series/39161/revisions/1/mbox/

 Possible new issues:

Test gem_sync:
Subgroup basic-each:
dmesg-fail -> PASS   (fi-bsw-n3050)
Subgroup basic-many-each:
skip   -> PASS   (fi-bsw-n3050)
Subgroup basic-store-all:
skip   -> PASS   (fi-bsw-n3050)
Subgroup basic-store-each:
skip   -> PASS   (fi-bsw-n3050)
Test gem_tiled_blits:
Subgroup basic:
skip   -> PASS   (fi-bsw-n3050)
Test gem_tiled_fence_blits:
Subgroup basic:
skip   -> PASS   (fi-bsw-n3050)
Test gem_wait:
Subgroup basic-await-all:
skip   -> PASS   (fi-bsw-n3050)
Subgroup basic-busy-all:
skip   -> PASS   (fi-bsw-n3050)
Subgroup basic-wait-all:
skip   -> PASS   (fi-bsw-n3050)
Test gem_workarounds:
Subgroup basic-read:
skip   -> PASS   (fi-bsw-n3050)
Test kms_busy:
Subgroup basic-flip-c:
skip   -> PASS   (fi-bsw-n3050)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (fi-bsw-n3050)
Subgroup basic-busy-flip-before-cursor-legacy:
skip   -> PASS   (fi-bsw-n3050)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-bsw-n3050)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
dmesg-fail -> PASS   (fi-bsw-n3050)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-bsw-n3050)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:478s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:592s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:405s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:446s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248 

Re: [Intel-gfx] [RFC] drm/i915/dp: move link rate arrays where they're used

[Manasi Navare]

On Tue, Feb 27, 2018 at 12:59:11PM +0200, Jani Nikula wrote:
> Localize link rate arrays by moving them to the functions where they're
> used. Further clarify the distinction between source and sink
> capabilities. Split pre and post Haswell arrays, and get rid of the
> array size arithmetics. Use a direct rate value in the paranoia case of
> no common rates find.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Reviewed-by: Manasi Navare 

manasi

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 44 
> +
>  1 file changed, 27 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 801a21b16004..6fa6583b16bd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -96,15 +96,6 @@ static const struct dp_link_dpll chv_dpll[] = {
>   { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
>  };
>  
> -static const int bxt_rates[] = { 162000, 216000, 243000, 27,
> -   324000, 432000, 54 };
> -static const int skl_rates[] = { 162000, 216000, 27,
> -   324000, 432000, 54 };
> -static const int cnl_rates[] = { 162000, 216000, 27,
> -  324000, 432000, 54,
> -  648000, 81 };
> -static const int default_rates[] = { 162000, 27, 54 };
> -
>  /**
>   * intel_dp_is_edp - is the given port attached to an eDP panel (either CPU 
> or PCH)
>   * @intel_dp: DP struct
> @@ -144,14 +135,17 @@ static void intel_dp_unset_edid(struct intel_dp 
> *intel_dp);
>  /* update sink rates from dpcd */
>  static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
>  {
> + static const int dp_rates[] = {
> + 162000, 27, 54
> + };
>   int i, max_rate;
>  
>   max_rate = 
> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>  
> - for (i = 0; i < ARRAY_SIZE(default_rates); i++) {
> - if (default_rates[i] > max_rate)
> + for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
> + if (dp_rates[i] > max_rate)
>   break;
> - intel_dp->sink_rates[i] = default_rates[i];
> + intel_dp->sink_rates[i] = dp_rates[i];
>   }
>  
>   intel_dp->num_sink_rates = i;
> @@ -268,6 +262,22 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
>  static void
>  intel_dp_set_source_rates(struct intel_dp *intel_dp)
>  {
> + /* The values must be in increasing order */
> + static const int cnl_rates[] = {
> + 162000, 216000, 27, 324000, 432000, 54, 648000, 81
> + };
> + static const int bxt_rates[] = {
> + 162000, 216000, 243000, 27, 324000, 432000, 54
> + };
> + static const int skl_rates[] = {
> + 162000, 216000, 27, 324000, 432000, 54
> + };
> + static const int hsw_rates[] = {
> + 162000, 27, 54
> + };
> + static const int g4x_rates[] = {
> + 162000, 27
> + };
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>   const struct ddi_vbt_port_info *info =
> @@ -290,11 +300,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>   size = ARRAY_SIZE(skl_rates);
>   } else if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
>  IS_BROADWELL(dev_priv)) {
> - source_rates = default_rates;
> - size = ARRAY_SIZE(default_rates);
> + source_rates = hsw_rates;
> + size = ARRAY_SIZE(hsw_rates);
>   } else {
> - source_rates = default_rates;
> - size = ARRAY_SIZE(default_rates) - 1;
> + source_rates = g4x_rates;
> + size = ARRAY_SIZE(g4x_rates);
>   }
>  
>   if (max_rate && vbt_max_rate)
> @@ -356,7 +366,7 @@ static void intel_dp_set_common_rates(struct intel_dp 
> *intel_dp)
>  
>   /* Paranoia, there should always be something in common. */
>   if (WARN_ON(intel_dp->num_common_rates == 0)) {
> - intel_dp->common_rates[0] = default_rates[0];
> + intel_dp->common_rates[0] = 162000;
>   intel_dp->num_common_rates = 1;
>   }
>  }
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Alex Deucher]

On Tue, Feb 27, 2018 at 7:56 AM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
>
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
>
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes(). For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().
>
> Cc: Keith Packard 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> Cc: Shashank Sharma 
> Cc: Stefan Agner 
> Cc: Thierry Reding 
> Cc: Boris Brezillon 
> Cc: Philipp Zabel 
> Cc: Laurent Pinchart 
> Cc: Manfred Schlaegl 
> Cc: Marek Vasut 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Alison Wang 
> Cc: Eric Anholt 
> Cc: Linus Walleij 
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Maxime Ripard 
> Signed-off-by: Ville Syrjälä 

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

Re: [Intel-gfx] [RFC] drm/i915/dp: move link rate arrays where they're used

[Ville Syrjälä]

On Tue, Feb 27, 2018 at 12:59:11PM +0200, Jani Nikula wrote:
> Localize link rate arrays by moving them to the functions where they're
> used. Further clarify the distinction between source and sink
> capabilities. Split pre and post Haswell arrays, and get rid of the
> array size arithmetics. Use a direct rate value in the paranoia case of
> no common rates find.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 44 
> +
>  1 file changed, 27 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 801a21b16004..6fa6583b16bd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -96,15 +96,6 @@ static const struct dp_link_dpll chv_dpll[] = {
>   { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
>  };
>  
> -static const int bxt_rates[] = { 162000, 216000, 243000, 27,
> -   324000, 432000, 54 };
> -static const int skl_rates[] = { 162000, 216000, 27,
> -   324000, 432000, 54 };
> -static const int cnl_rates[] = { 162000, 216000, 27,
> -  324000, 432000, 54,
> -  648000, 81 };
> -static const int default_rates[] = { 162000, 27, 54 };
> -
>  /**
>   * intel_dp_is_edp - is the given port attached to an eDP panel (either CPU 
> or PCH)
>   * @intel_dp: DP struct
> @@ -144,14 +135,17 @@ static void intel_dp_unset_edid(struct intel_dp 
> *intel_dp);
>  /* update sink rates from dpcd */
>  static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
>  {
> + static const int dp_rates[] = {
> + 162000, 27, 54
> + };
>   int i, max_rate;
>  
>   max_rate = 
> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>  
> - for (i = 0; i < ARRAY_SIZE(default_rates); i++) {
> - if (default_rates[i] > max_rate)
> + for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
> + if (dp_rates[i] > max_rate)
>   break;
> - intel_dp->sink_rates[i] = default_rates[i];
> + intel_dp->sink_rates[i] = dp_rates[i];
>   }
>  
>   intel_dp->num_sink_rates = i;
> @@ -268,6 +262,22 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
>  static void
>  intel_dp_set_source_rates(struct intel_dp *intel_dp)
>  {
> + /* The values must be in increasing order */
> + static const int cnl_rates[] = {
> + 162000, 216000, 27, 324000, 432000, 54, 648000, 81
> + };
> + static const int bxt_rates[] = {
> + 162000, 216000, 243000, 27, 324000, 432000, 54
> + };
> + static const int skl_rates[] = {
> + 162000, 216000, 27, 324000, 432000, 54
> + };
> + static const int hsw_rates[] = {
> + 162000, 27, 54
> + };
> + static const int g4x_rates[] = {
> + 162000, 27
> + };
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>   const struct ddi_vbt_port_info *info =
> @@ -290,11 +300,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>   size = ARRAY_SIZE(skl_rates);
>   } else if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
>  IS_BROADWELL(dev_priv)) {
> - source_rates = default_rates;
> - size = ARRAY_SIZE(default_rates);
> + source_rates = hsw_rates;
> + size = ARRAY_SIZE(hsw_rates);
>   } else {
> - source_rates = default_rates;
> - size = ARRAY_SIZE(default_rates) - 1;
> + source_rates = g4x_rates;
> + size = ARRAY_SIZE(g4x_rates);
>   }
>  
>   if (max_rate && vbt_max_rate)
> @@ -356,7 +366,7 @@ static void intel_dp_set_common_rates(struct intel_dp 
> *intel_dp)
>  
>   /* Paranoia, there should always be something in common. */
>   if (WARN_ON(intel_dp->num_common_rates == 0)) {
> - intel_dp->common_rates[0] = default_rates[0];
> + intel_dp->common_rates[0] = 162000;
>   intel_dp->num_common_rates = 1;
>   }
>  }
> -- 
> 2.11.0

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

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Fix plane YCbCr->RGB conversion for GLK

[Imre Deak]

On Wed, Feb 14, 2018 at 09:23:24PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> On GLK the plane CSC controls moved into the COLOR_CTL register.
> Update the code to progam the YCbCr->RGB CSC mode correctly when
> faced with an YCbCr framebuffer.
> 
> The spec is rather confusing as it calls the mode "YUV601 to RGB709".
> I'm going to assume that just means it's going to use the YCbCr->RGB
> matrix as specified in BT.601 and doesn't actually change the gamut.
> 
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: Daniel Stone 
> Cc: Russell King - ARM Linux 
> Cc: Ilia Mirkin 
> Cc: Hans Verkuil 
> Cc: Uma Shankar 
> Cc: Shashank Sharma 
> Signed-off-by: Ville Syrjälä 

Matches the spec, so:
Reviewed-by: Imre Deak 

I asked for clarification in the spec about the BT.601 vs. 709 oddity you
noticed.

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  5 +
>  drivers/gpu/drm/i915/intel_display.c |  3 +++
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_sprite.c  | 10 +-
>  4 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 28b36eac064e..6abeaf64c2d2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6463,6 +6463,11 @@ enum {
>  #define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
>  #define   PLANE_COLOR_PIPE_GAMMA_ENABLE  (1 << 30)
>  #define   PLANE_COLOR_PIPE_CSC_ENABLE(1 << 23)
> +#define   PLANE_COLOR_CSC_MODE_BYPASS(0 << 17)
> +#define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709  (1 << 17)
> +#define   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709  (2 << 17)
> +#define   PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020(3 << 17)
> +#define   PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020 (4 << 17)
>  #define   PLANE_COLOR_PLANE_GAMMA_DISABLE(1 << 13)
>  #define   PLANE_COLOR_ALPHA_MASK (0x3 << 4)
>  #define   PLANE_COLOR_ALPHA_DISABLE  (0 << 4)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 286a9591d179..a22b583838f7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3573,6 +3573,9 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
> *crtc_state,
>   plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
>   plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
>  
> + if (intel_format_is_yuv(fb->format->format))
> + plane_color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> +
>   return plane_color_ctl;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 898064e8bea7..6e43da40c859 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1591,6 +1591,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
> *crtc_state,
>   const struct intel_plane_state *plane_state);
>  u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
> const struct intel_plane_state *plane_state);
> +u32 glk_color_ctl(const struct intel_plane_state *plane_state);
>  u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
>unsigned int rotation);
>  int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
> @@ -2016,6 +2017,7 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
>  
>  
>  /* intel_sprite.c */
> +bool intel_format_is_yuv(u32 format);
>  int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>int usecs);
>  struct intel_plane *intel_sprite_plane_create(struct drm_i915_private 
> *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index fac9e01b4795..b4acde2058fe 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -41,8 +41,7 @@
>  #include 
>  #include "i915_drv.h"
>  
> -static bool
> -format_is_yuv(uint32_t format)
> +bool intel_format_is_yuv(u32 format)
>  {
>   switch (format) {
>   case DRM_FORMAT_YUYV:
> @@ -266,6 +265,7 @@ skl_update_plane(struct intel_plane *plane,
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>   I915_WRITE_FW(PLANE_COLOR_CTL(pipe, plane_id),
> plane_state->color_ctl);
> +
>   if (key->flags) {
>   I915_WRITE_FW(PLANE_KEYVAL(pipe, plane_id), key->min_value);
>   I915_WRITE_FW(PLANE_KEYMAX(pipe, plane_id), key->max_value);
> @@ -354,7 +354,7 @@ chv_update_csc(const struct intel_plane_state 
> 

[Intel-gfx] [PATCH v2] drm/i915: Add an option to disable SAGV

[Azhar Shaikh]

On Gen9 systems, with SAGV enabled, we have seen display
corruption(screenshots attached in the bug) which eventually lead to a
system hang. This happens when we have overlay plane and on enabling
and disabling the overlay plane. When the system hangs, we do not have
enough logs or information to debug the issue.
Having a module parameter will help in debugging the system hang.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104975
Signed-off-by: Azhar Shaikh 
---
Changes from v1:
- Update the title and commit message.
- Rename the module param to enable_sagv and set it to default true.

 drivers/gpu/drm/i915/i915_params.c | 3 +++
 drivers/gpu/drm/i915/i915_params.h | 3 ++-
 drivers/gpu/drm/i915/intel_pm.c| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce5be21..88610720334e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -167,6 +167,9 @@ struct i915_params i915_modparams __read_mostly = {
 i915_param_named_unsafe(enable_dp_mst, bool, 0600,
"Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");
 
+i915_param_named_unsafe(enable_sagv, bool, 0600,
+   "Enable SAGV (default: true)");
+
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
 i915_param_named_unsafe(inject_load_failure, uint, 0400,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..507d231b0ca6 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -69,7 +69,8 @@
param(bool, nuclear_pageflip, false) \
param(bool, enable_dp_mst, true) \
param(bool, enable_dpcd_backlight, false) \
-   param(bool, enable_gvt, false)
+   param(bool, enable_gvt, false) \
+   param(bool, enable_sagv, true)
 
 #define MEMBER(T, member, ...) T member;
 struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 21dac6ebc202..4ac94045cc08 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3693,7 +3693,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
int level, latency;
int sagv_block_time_us;
 
-   if (!intel_has_sagv(dev_priv))
+   if (!intel_has_sagv(dev_priv) || !i915_modparams.enable_sagv)
return false;
 
if (IS_GEN9(dev_priv))
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > >>> Preparing a framebuffer should not require a flush. 
> > > >>> _post_plane_update()
> > > >>> takes care of flushing when a flip is scheduled, this should be
> > > >>> sufficient for PSR and FBC.
> > > >> Makes sense.
> > > >>  
> > > > I also think this might speed up the flips a bit by avoiding flushes. 
> > > >
> > > >>> Cc: Paulo Zanoni 
> > > >>> Cc: Ville Syrjälä 
> > > >>> Cc: Chris Wilson 
> > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > >> Also
> > > >> Cc: Maarten Lankhorst 
> > > >> to validate the flow through atomic.
> > > >> -Chris
> > > >>
> > > Page flips used to do intel_frontbuffer_flip_prepare here, followed by 
> > > intel_frontbuffer_flip_complete. I think it would make sense to change 
> > > the patch to do that?
> > > 
> > 
> > I have no context why it was removed, I'll have to understand that
> > change and get back to you.
> 
> Since we supposedly have hw nuke for both fbc and psr there doesn't seem
> to be much need to do anything for flips. I guess DRRS is the only
> thing that kinda needs it (not really, just avoids flipping with the
> slow timings). But I think DRRS should really be tied into the vblank
> stuff somehow so that we switch to the fast timings whenever a vblank
> interrupts are enabled.

Oh, I guess VLV/CHV PSR is what would need this. To do that properly
(ie. main link off) I think we'd basically need to do a full modeset
when exiting PSR, so it should probably handled somewhere higher up
during modeset, and for other uses the frontbuffer tracking
should perhaps just schedule a work to do the full modeset.

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

[Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Here's this weeks pull, relatively small when you pull out the trivial fixes.

drm-misc-next-2018-02-28:
drm-misc-next for 4.17:

UAPI Changes:
 Fix drm_color_ctm matrix docs to match usage and change the type to
 __u64 make it obvious (Ville)

Core Changes:
 Check modifier with format when checking if a plane state is supported (Ville)

Driver Changes:
 sun4i: Improve hw plane utilization (Maxime)
 simple: Add per-pipe enable/disable vblank functions (Oleksandr)
 virtio: Whitespace + checkpatch changes (Rodrigo)

Cc: Maxime Ripard 
Cc: Oleksandr Andrushchenko 
Cc: Ville Syrjälä 
Cc: Rodrigo Siqueira 

Cheers, Sean


The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:

  drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28

for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:

  tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)


drm-misc-next for 4.17:

UAPI Changes:
 Fix drm_color_ctm matrix docs to match usage and change the type to
 __u64 make it obvious (Ville)

Core Changes:
 Check modifier with format when checking if a plane state is supported (Ville)

Driver Changes:
 sun4i: Improve hw plane utilization (Maxime)
 simple: Add per-pipe enable/disable vblank functions (Oleksandr)
 virtio: Whitespace + checkpatch changes (Rodrigo)

Cc: Maxime Ripard 
Cc: Oleksandr Andrushchenko 
Cc: Ville Syrjälä 
Cc: Rodrigo Siqueira 


Arnd Bergmann (2):
  drm: fix drm_get_max_iomem type mismatch
  tinydrm: add backlight dependency

Benjamin Gaignard (1):
  drm/stm: check pitch and size calculations even if !CONFIG_MMU

Chris Wilson (1):
  drm/mm: Fix caching of leftmost node in the interval tree

Linus Walleij (1):
  drm/panel: Fix ARM Versatile panel clocks

Maxime Ripard (4):
  drm/sun4i: backend: Assign the pipes automatically
  drm/sun4i: Remove the plane description structure
  drm/sun4i: backend: Make zpos configurable
  drm/sun4i: backend: Remove ARGB spoofing

Oleksandr Andrushchenko (5):
  drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC
  drm/simple_kms_helper: Add {enable|disable}_vblank callback support
  drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
  drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
  drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank

Rodrigo Siqueira (7):
  drm/virtio: Add tabs at the start of a line
  drm/virtio: Add blank line after variable declarations
  drm/virtio: Add */ in block comments to separate line
  drm/virtio: Remove return from void function
  drm/virtio: Replace 'unsigned' for 'unsigned int'
  drm/virtio: Remove multiple blank lines
  drm/virtio: Add spaces around operators

Thierry Reding (1):
  drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC

Ville Syrjälä (4):
  drm: Check that the plane supports the request format+modifier combo
  drm/i915: Remove the pipe/plane ID checks from skl_check_ccs_aux_surface()
  drm: Include the header with the prototype for 
drm_get_panel_orientation_quirk()
  drm/uapi: The ctm matrix uses sign-magnitude representation

 drivers/gpu/drm/drm_atomic.c   | 10 +++--
 drivers/gpu/drm/drm_crtc.c | 10 +++--
 drivers/gpu/drm/drm_crtc_internal.h|  4 +-
 drivers/gpu/drm/drm_memory.c   |  2 +-
 drivers/gpu/drm/drm_mm.c   |  9 +++--
 drivers/gpu/drm/drm_panel_orientation_quirks.c |  1 +
 drivers/gpu/drm/drm_plane.c| 33 
 drivers/gpu/drm/drm_simple_kms_helper.c| 34 
 drivers/gpu/drm/i915/intel_display.c   |  8 
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 54 +
 drivers/gpu/drm/panel/panel-arm-versatile.c|  8 ++--
 drivers/gpu/drm/pl111/Kconfig  |  1 -
 drivers/gpu/drm/pl111/pl111_display.c  | 15 +--
 drivers/gpu/drm/pl111/pl111_drm.h  |  2 -
 drivers/gpu/drm/pl111/pl111_drv.c  |  5 ---
 drivers/gpu/drm/stm/drv.c  |  2 -
 drivers/gpu/drm/sun4i/sun4i_backend.c  | 52 ++--
 drivers/gpu/drm/sun4i/sun4i_layer.c| 55 ++
 drivers/gpu/drm/sun4i/sun4i_layer.h|  1 +
 drivers/gpu/drm/tinydrm/Kconfig|  2 +
 drivers/gpu/drm/tve200/tve200_display.c| 10 

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Ville Syrjälä]

On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > >>> Preparing a framebuffer should not require a flush. _post_plane_update()
> > >>> takes care of flushing when a flip is scheduled, this should be
> > >>> sufficient for PSR and FBC.
> > >> Makes sense.
> > >>  
> > > I also think this might speed up the flips a bit by avoiding flushes. 
> > >
> > >>> Cc: Paulo Zanoni 
> > >>> Cc: Ville Syrjälä 
> > >>> Cc: Chris Wilson 
> > >>> Signed-off-by: Dhinakaran Pandiyan 
> > >> Also
> > >> Cc: Maarten Lankhorst 
> > >> to validate the flow through atomic.
> > >> -Chris
> > >>
> > Page flips used to do intel_frontbuffer_flip_prepare here, followed by 
> > intel_frontbuffer_flip_complete. I think it would make sense to change the 
> > patch to do that?
> > 
> 
> I have no context why it was removed, I'll have to understand that
> change and get back to you.

Since we supposedly have hw nuke for both fbc and psr there doesn't seem
to be much need to do anything for flips. I guess DRRS is the only
thing that kinda needs it (not really, just avoids flipping with the
slow timings). But I think DRRS should really be tied into the vblank
stuff somehow so that we switch to the fast timings whenever a vblank
interrupts are enabled.

-- 
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] drm/i915/guc: Removed unused GuC parameters.

[Michel Thierry]

On 28/02/18 10:42, Piotr Piórkowski wrote:

In the i915 driver, there is a function, intel_guc_init_params(),
which initializes the GuC parameter block which is passed into
the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
GfxGtType and GfxCoreFamily unused by GuC.

This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
GfxCoreFamily parameters and also unnecessary functions
get_gt_type() and get_core_family().



Hi,

Looking at the fw code, you're partially right, GfxGtType is ignored... 
but GfxCoreFamily isn't.


If you don't pass a known GfxCoreFamily, SLPC will be disabled (enabling 
SLPC is in some manager's wish list). Also it seems nobody remembered to 
add GUC_CORE_FAMILY_GEN10 for CNL.



Signed-off-by: Piotr Piórkowski 
---
  drivers/gpu/drm/i915/i915_params.h|  2 +-
  drivers/gpu/drm/i915/intel_guc.c  | 24 
  drivers/gpu/drm/i915/intel_guc_fwif.h |  4 
  drivers/gpu/drm/i915/intel_uc.c   |  2 ++
  4 files changed, 3 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \


This shouldn't be part of your patch, enable guc submission in a 2nd 
patch, for example: [PATCH 2/2] HAX: Enable GuC submission for CI



param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 21140ccd7a97..5f6d84251830 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
  }
  
-static u32 get_gt_type(struct drm_i915_private *dev_priv)

-{
-   /* XXX: GT type based on PCI device ID? field seems unused by fw */
-   return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-   u32 gen = INTEL_GEN(dev_priv);
-
-   switch (gen) {
-   case 9:
-   return GUC_CORE_FAMILY_GEN9;
-
-   default:
-   MISSING_CASE(gen);
-   return GUC_CORE_FAMILY_UNKNOWN;
-   }
-}
-
  static u32 get_log_verbosity_flags(void)
  {
if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	memset(params, 0, sizeof(params));
  
-	params[GUC_CTL_DEVICE_INFO] |=

-   (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-   (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
/*
 * GuC ARAT increment is 10 ns. GuC default scheduler quantum is one
 * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..0f381de44722 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -81,10 +81,6 @@
  #define GUC_CTL_ARAT_HIGH 1
  #define GUC_CTL_ARAT_LOW  2
  
-#define GUC_CTL_DEVICE_INFO		3

-#define   GUC_CTL_GT_TYPE_SHIFT0
-#define   GUC_CTL_CORE_FAMILY_SHIFT7
-
  #define GUC_CTL_LOG_PARAMS4
  #define   GUC_LOG_VALID   (1 << 0)
  #define   GUC_LOG_NOTIFY_ON_HALF_FULL (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9f1bac6398fb..b48056fb769d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
  
  	/* Any platform specific fine-tuning can be done here */

+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;


This is also part of [PATCH 2/2] HAX: Enable GuC submission for CI

  
  	return enable_guc;

  }



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

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Lyude Paul]

On Wed, 2018-02-28 at 11:57 -0800, Manasi Navare wrote:
> On Wed, Feb 28, 2018 at 02:41:06PM -0500, Lyude Paul wrote:
> > On Wed, 2018-02-28 at 11:27 -0800, Manasi Navare wrote:
> > > On Wed, Feb 28, 2018 at 02:07:34PM -0500, Lyude Paul wrote:
> > > > 
> > > > On Tue, 2018-02-27 at 23:17 -0800, Manasi Navare wrote:
> > > > > Ville,  thanks for the patch and
> > > > > Sorry for not being able to review this earlier.
> > > > > Please find some comments below:
> > > > > 
> > > > > On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> > > > > > On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > > > > > > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > > > > > > > From: Ville Syrjälä 
> > > > > > > > 
> > > > > > > > Doing link retraining from the short pulse handler is
> > > > > > > > problematic
> > > > > > > > since
> > > > > > > > that might introduce deadlocks with MST sideband processing.
> > > > > > > > Currently
> > > > > > > > we don't retrain MST links from this code, but we want to
> > > > > > > > change
> > > > > > > > that.
> > > > > > > > So better to move the entire thing to the hotplug work. We can
> > > > > > > > utilize
> > > > > > > > the new encoder->hotplug() hook for this.
> > > > > > > > 
> > > > > > > > The only thing we leave in the short pulse handler is the link
> > > > > > > > status
> > > > > > > > check. That one still depends on the link parameters stored
> > > > > > > > under
> > > > > > > > intel_dp, so no locking around that but races should be mostly
> > > > > > > > harmless
> > > > > > > > as the actual retraining code will recheck the link state if
> > > > > > > > we
> > > > > > > > end up there by mistake.
> > > > > > > > 
> > > > > > > > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > > > > > > > Check the connector type to figure out if we should do
> > > > > > > > the HDMI thing or the DP think for DDI
> > > > > > > > 
> > > > > > > > Cc: Manasi Navare 
> > > > > > > > Cc: Maarten Lankhorst 
> > > > > > > > Signed-off-by: Ville Syrjälä 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> > > > > > > >  drivers/gpu/drm/i915/intel_dp.c  | 196
> > > > > > > > ++--
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> > > > > > > >  3 files changed, 120 insertions(+), 88 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > index 25793bdc692f..5f3d58f1ae6e 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct
> > > > > > > > intel_encoder
> > > > > > > > *encoder,
> > > > > > > > drm_modeset_acquire_init(, 0);
> > > > > > > >  
> > > > > > > > for (;;) {
> > > > > > > > -   ret = intel_hdmi_reset_link(encoder, );
> > > > > > > > +   if (connector->base.connector_type ==
> > > > > > > > DRM_MODE_CONNECTOR_HDMIA)
> > > > > > > > +   ret = intel_hdmi_reset_link(encoder,
> > > > > > > > );
> > > > > > > > +   else
> > > > > > > > +   ret = intel_dp_retrain_link(encoder,
> > > > > > > > );
> > > > > > > >  
> > > > > > > > if (ret == -EDEADLK) {
> > > > > > > > drm_modeset_backoff();
> > > > > > > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct
> > > > > > > > drm_i915_private
> > > > > > > > *dev_priv,
> > > > > > > > enum port port)
> > > > > > > > drm_encoder_init(_priv->drm, encoder,
> > > > > > > > _ddi_funcs,
> > > > > > > >  DRM_MODE_ENCODER_TMDS, "DDI %c",
> > > > > > > > port_name(port));
> > > > > > > >  
> > > > > > > > -   if (init_hdmi)
> > > > > > > > -   intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > > > -   else
> > > > > > > > -   intel_encoder->hotplug =
> > > > > > > > intel_encoder_hotplug;
> > > > > > > > +   intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > > > intel_encoder->compute_output_type =
> > > > > > > > intel_ddi_compute_output_type;
> > > > > > > > intel_encoder->compute_config =
> > > > > > > > intel_ddi_compute_config;
> > > > > > > > intel_encoder->enable = intel_enable_ddi;
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > > index 6bbf14410c2a..152016e09a11 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct
> > > > > > > > intel_dp
> > > > > > > > 

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Nuke intel_dp->channel_eq_status

[Manasi Navare]

On Thu, Jan 18, 2018 at 10:59:04PM -0800, Rodrigo Vivi wrote:
> On Wed, Jan 17, 2018 at 07:21:48PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > intel_dp->channel_eq_status is used in exactly one function, and we
> > don't need it to persist between calls. So just go back to using a
> > local variable instead.
> > 
> > Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

> 
> Reviewed-by: Rodrigo Vivi 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 6 +++---
> >  drivers/gpu/drm/i915/intel_drv.h  | 1 -
> >  2 files changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa8a553..1314f5d87d7d 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -248,6 +248,7 @@ intel_dp_link_training_channel_equalization(struct 
> > intel_dp *intel_dp)
> > int tries;
> > u32 training_pattern;
> > uint8_t link_status[DP_LINK_STATUS_SIZE];
> > +   bool channel_eq = false;
> >  
> > training_pattern = intel_dp_training_pattern(intel_dp);
> >  
> > @@ -259,7 +260,6 @@ intel_dp_link_training_channel_equalization(struct 
> > intel_dp *intel_dp)
> > return false;
> > }
> >  
> > -   intel_dp->channel_eq_status = false;
> > for (tries = 0; tries < 5; tries++) {
> >  
> > drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
> > @@ -279,7 +279,7 @@ intel_dp_link_training_channel_equalization(struct 
> > intel_dp *intel_dp)
> >  
> > if (drm_dp_channel_eq_ok(link_status,
> >  intel_dp->lane_count)) {
> > -   intel_dp->channel_eq_status = true;
> > +   channel_eq = true;
> > DRM_DEBUG_KMS("Channel EQ done. DP Training "
> >   "successful\n");
> > break;
> > @@ -301,7 +301,7 @@ intel_dp_link_training_channel_equalization(struct 
> > intel_dp *intel_dp)
> >  
> > intel_dp_set_idle_link_train(intel_dp);
> >  
> > -   return intel_dp->channel_eq_status;
> > +   return channel_eq;
> >  
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index ddf28a442cd7..1d018869ad02 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1045,7 +1045,6 @@ struct intel_dp {
> > bool link_mst;
> > bool has_audio;
> > bool detect_done;
> > -   bool channel_eq_status;
> > bool reset_link_params;
> > uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
> > uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> > -- 
> > 2.13.6
> > 
> > ___
> > 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

Re: [Intel-gfx] [PATCH 04/17] drm/i915/icl: compute the combo PHY (DPLL) DP registers

[James Ausmus]

On Thu, Feb 22, 2018 at 12:55:06AM -0300, Paulo Zanoni wrote:
> Just use the hardcoded tables provided by our spec.
> 
> v2: Rebase.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 86 
> ++-
>  1 file changed, 85 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 4d9265d14661..5d7bacc80688 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2389,6 +2389,90 @@ static const struct intel_dpll_mgr cnl_pll_mgr = {
>   .dump_hw_state = cnl_dump_hw_state,
>  };
>  
> +/*
> + * These values alrea already adjusted: they're the bits we write to the
> + * registers, not the logical values.
> + */
> +static const struct skl_wrpll_params icl_dp_combo_pll_24MHz_values[] = {
> + { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [0]: 5.4 */
> +   .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [1]: 2.7 */
> +   .pdiv = 0x2 /* 3 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [2]: 1.62 */
> +   .pdiv = 0x4 /* 5 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [3]: 3.24 */
> +   .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x168, .dco_fraction = 0x, /* [4]: 2.16 */
> +   .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 1, .qdiv_ratio = 2},
> + { .dco_integer = 0x168, .dco_fraction = 0x, /* [5]: 4.32 */
> +   .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x195, .dco_fraction = 0x, /* [6]: 6.48 */
> +   .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [7]: 8.1 */
> +   .pdiv = 0x1 /* 2 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> +};
> +

Maybe:

/* Also used for 38.4MHz values */

Either way -

Reviewed-by: James Ausmus 

> +static const struct skl_wrpll_params icl_dp_combo_pll_19_2MHz_values[] = {
> + { .dco_integer = 0x1A5, .dco_fraction = 0x7000, /* [0]: 5.4 */
> +   .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x1A5, .dco_fraction = 0x7000, /* [1]: 2.7 */
> +   .pdiv = 0x2 /* 3 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x1A5, .dco_fraction = 0x7000, /* [2]: 1.62 */
> +   .pdiv = 0x4 /* 5 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x1A5, .dco_fraction = 0x7000, /* [3]: 3.24 */
> +   .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x1C2, .dco_fraction = 0x, /* [4]: 2.16 */
> +   .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 1, .qdiv_ratio = 2},
> + { .dco_integer = 0x1C2, .dco_fraction = 0x, /* [5]: 4.32 */
> +   .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x1FA, .dco_fraction = 0x2000, /* [6]: 6.48 */
> +   .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> + { .dco_integer = 0x1A5, .dco_fraction = 0x7000, /* [7]: 8.1 */
> +   .pdiv = 0x1 /* 2 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> +};
> +
> +static bool icl_calc_dp_combo_pll(struct drm_i915_private *dev_priv, int 
> clock,
> +   struct skl_wrpll_params *pll_params)
> +{
> + const struct skl_wrpll_params *params;
> +
> + params = dev_priv->cdclk.hw.ref == 24000 ?
> + icl_dp_combo_pll_24MHz_values :
> + icl_dp_combo_pll_19_2MHz_values;
> +
> + switch (clock) {
> + case 54:
> + *pll_params = params[0];
> + break;
> + case 27:
> + *pll_params = params[1];
> + break;
> + case 162000:
> + *pll_params = params[2];
> + break;
> + case 324000:
> + *pll_params = params[3];
> + break;
> + case 216000:
> + *pll_params = params[4];
> + break;
> + case 432000:
> + *pll_params = params[5];
> + break;
> + case 648000:
> + *pll_params = params[6];
> + break;
> + case 81:
> + *pll_params = params[7];
> + break;
> + default:
> + MISSING_CASE(clock);
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static bool icl_calc_dpll_state(struct intel_crtc_state *crtc_state,
>   struct intel_encoder *encoder, int clock,
>   

Re: [Intel-gfx] [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Jani Nikula]

On Wed, 28 Feb 2018, Thierry Reding  wrote:
> Anyone that needs something other than normal mode should use the new
> atomic PWM API.

At the risk of revealing my true ignorance, what is the new atomic PWM
API? Where? Examples of how one would convert old code over to the new
API?

BR,
Jani.

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Track whether the DP link is trained or not

[Manasi Navare]

On Wed, Jan 17, 2018 at 09:21:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> LSPCON likes to throw short HPDs during the enable seqeunce prior to the
> link being trained. These obviously result in the channel CR/EQ check
> failing and thus we schedule a pointless hotplug work to retrain the
> link. Avoid that by ignoring the bad CR/EQ status until we've actually
> initially trained the link.
> 
> I've not actually investigated to see what LSPCON is trying to signal
> with the short pulse. But as long as it signals anything I think we're
> supposed to check the link status anyway, so I don't really see other
> good ways to solve this. I've not seen these short pulses being
> generated by normal DP sinks.
>

I agree with avoiding the retraining of the link through these HPDs
when its not trained even for the first time.
The only concern I have here is that we probably shouldnt set the link_trained 
to true
unless it has been sucessfully trained. So move it to the 
intel_dp_start_link_train
before failure handling. This will also avoid the case where we are in the 
retraining
and we get these short HPDs.
Also the link_trained should be set to false in failure_handling in 
intel_dp_start_link_train()
before scheduling the retry modeset work function.
Thoughts?
 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  |  2 ++
>  drivers/gpu/drm/i915/intel_dp.c   | 10 +++---
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h  |  1 +
>  4 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 5f3d58f1ae6e..7a4c5a2d36ed 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2466,6 +2466,8 @@ static void intel_disable_ddi_dp(struct intel_encoder 
> *encoder,
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>  
> + intel_dp->link_trained = false;
> +
>   if (old_crtc_state->has_audio)
>   intel_audio_codec_disable(encoder,
> old_crtc_state, old_conn_state);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 152016e09a11..0cf92aa60f3e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1854,6 +1854,7 @@ void intel_dp_set_link_params(struct intel_dp *intel_dp,
> int link_rate, uint8_t lane_count,
> bool link_mst)
>  {
> + intel_dp->link_trained = false;
>   intel_dp->link_rate = link_rate;
>   intel_dp->lane_count = lane_count;
>   intel_dp->link_mst = link_mst;
> @@ -2702,6 +2703,8 @@ static void intel_disable_dp(struct intel_encoder 
> *encoder,
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>  
> + intel_dp->link_trained = false;
> +
>   if (old_crtc_state->has_audio)
>   intel_audio_codec_disable(encoder,
> old_crtc_state, old_conn_state);
> @@ -4280,10 +4283,11 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
>  {
>   u8 link_status[DP_LINK_STATUS_SIZE];
>  
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - DRM_ERROR("Failed to get link status\n");
> + if (!intel_dp->link_trained)
> + return false;
> +
> + if (!intel_dp_get_link_status(intel_dp, link_status))
>   return false;
> - }
>  
>   /*
>* Validate the cached values of intel_dp->link_rate and
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 1314f5d87d7d..78f1fe934da3 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -307,6 +307,8 @@ intel_dp_link_training_channel_equalization(struct 
> intel_dp *intel_dp)
>  
>  void intel_dp_stop_link_train(struct intel_dp *intel_dp)
>  {
> + intel_dp->link_trained = true;
> +

Move to intel_dp_start_link_train() on successful link train?

Manasi

>   intel_dp_set_link_train(intel_dp,
>   DP_TRAINING_PATTERN_DISABLE);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1d018869ad02..7a45ffb9e524 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1043,6 +1043,7 @@ struct intel_dp {
>   uint8_t lane_count;
>   uint8_t sink_count;
>   bool link_mst;
> + bool link_trained;
>   bool has_audio;
>   bool detect_done;
>   bool reset_link_params;
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset
URL   : https://patchwork.freedesktop.org/series/39129/
State : warning

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
pass   -> DMESG-WARN (shard-snb)
Subgroup pipe-b-64x64-left-edge:
pass   -> DMESG-WARN (shard-snb)
Test pm_rc6_residency:
Subgroup rc6-accuracy:
skip   -> PASS   (shard-snb)

 Known issues:

Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking-fencing:
pass   -> FAIL   (shard-apl) fdo#103207
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-top-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +1
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
fail   -> PASS   (shard-snb) fdo#103167
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

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

shard-apltotal:3460 pass:1818 dwarn:1   dfail:0   fail:8   skip:1632 
time:12185s
shard-hswtotal:3429 pass:1751 dwarn:1   dfail:0   fail:2   skip:1673 
time:11330s
shard-snbtotal:3460 pass:1357 dwarn:4   dfail:0   fail:1   skip:2098 
time:6596s
Blacklisted hosts:
shard-kbltotal:3410 pass:1920 dwarn:2   dfail:0   fail:7   skip:1480 
time:9368s

== Logs ==

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

Re: [Intel-gfx] [PATCH 03/17] drm/i915/icl: compute the combo PHY (DPLL) HDMI registers

[James Ausmus]

On Thu, Feb 22, 2018 at 12:55:05AM -0300, Paulo Zanoni wrote:
> HDMI mode DPLL programming on ICL is the same as CNL, so just reuse
> the CNL code.
> 
> v2:
>  - Properly detect HDMI crtcs.
>  - Rebase after changes to the cnl function (clock * 1000).
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 34 +++---
>  1 file changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 8520a1b0279f..4d9265d14661 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2203,6 +2203,7 @@ cnl_ddi_calculate_wrpll(int clock,
>   struct skl_wrpll_params *wrpll_params)
>  {
>   u32 afe_clock = clock * 5;
> + uint32_t ref_clock;
>   u32 dco_min = 7998000;
>   u32 dco_max = 1000;
>   u32 dco_mid = (dco_min + dco_max) / 2;
> @@ -2235,8 +2236,12 @@ cnl_ddi_calculate_wrpll(int clock,
>  
>   cnl_wrpll_get_multipliers(best_div, , , );
>  
> - cnl_wrpll_params_populate(wrpll_params, best_dco,
> -   dev_priv->cdclk.hw.ref, pdiv, qdiv, kdiv);
> + ref_clock = dev_priv->cdclk.hw.ref;
> + if (IS_ICELAKE(dev_priv) && ref_clock == 38400)

This could use a comment - something like

/* 
 * ICL BSpec states "If reference frequency is 38.4, use 19.2 because
 * the DPLL automatically divides that by 2."
 */


With that -

Reviewed-by: James Ausmus 

> + ref_clock = 19200;
> +
> + cnl_wrpll_params_populate(wrpll_params, best_dco, ref_clock, pdiv, qdiv,
> +   kdiv);
>  
>   return true;
>  }
> @@ -2388,7 +2393,30 @@ static bool icl_calc_dpll_state(struct 
> intel_crtc_state *crtc_state,
>   struct intel_encoder *encoder, int clock,
>   struct intel_dpll_hw_state *pll_state)
>  {
> - /* TODO */
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + uint32_t cfgcr0, cfgcr1;
> + struct skl_wrpll_params pll_params = { 0 };
> + bool ret;
> +
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> + ret = cnl_ddi_calculate_wrpll(clock, dev_priv, _params);
> + else
> + ret = false; /* TODO */
> +
> + if (!ret)
> + return false;
> +
> + cfgcr0 = DPLL_CFGCR0_DCO_FRACTION(pll_params.dco_fraction) |
> +  pll_params.dco_integer;
> +
> + cfgcr1 = DPLL_CFGCR1_QDIV_RATIO(pll_params.qdiv_ratio) |
> +  DPLL_CFGCR1_QDIV_MODE(pll_params.qdiv_mode) |
> +  DPLL_CFGCR1_KDIV(pll_params.kdiv) |
> +  DPLL_CFGCR1_PDIV(pll_params.pdiv) |
> +  DPLL_CFGCR1_CENTRAL_FREQ_8400;
> +
> + pll_state->cfgcr0 = cfgcr0;
> + pll_state->cfgcr1 = cfgcr1;
>   return true;
>  }
>  
> -- 
> 2.14.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Manasi Navare]

On Wed, Feb 28, 2018 at 02:41:06PM -0500, Lyude Paul wrote:
> On Wed, 2018-02-28 at 11:27 -0800, Manasi Navare wrote:
> > On Wed, Feb 28, 2018 at 02:07:34PM -0500, Lyude Paul wrote:
> > > 
> > > On Tue, 2018-02-27 at 23:17 -0800, Manasi Navare wrote:
> > > > Ville,  thanks for the patch and
> > > > Sorry for not being able to review this earlier.
> > > > Please find some comments below:
> > > > 
> > > > On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > > > > > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > > > > > > From: Ville Syrjälä 
> > > > > > > 
> > > > > > > Doing link retraining from the short pulse handler is problematic
> > > > > > > since
> > > > > > > that might introduce deadlocks with MST sideband processing.
> > > > > > > Currently
> > > > > > > we don't retrain MST links from this code, but we want to change
> > > > > > > that.
> > > > > > > So better to move the entire thing to the hotplug work. We can
> > > > > > > utilize
> > > > > > > the new encoder->hotplug() hook for this.
> > > > > > > 
> > > > > > > The only thing we leave in the short pulse handler is the link
> > > > > > > status
> > > > > > > check. That one still depends on the link parameters stored under
> > > > > > > intel_dp, so no locking around that but races should be mostly
> > > > > > > harmless
> > > > > > > as the actual retraining code will recheck the link state if we
> > > > > > > end up there by mistake.
> > > > > > > 
> > > > > > > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > > > > > > Check the connector type to figure out if we should do
> > > > > > > the HDMI thing or the DP think for DDI
> > > > > > > 
> > > > > > > Cc: Manasi Navare 
> > > > > > > Cc: Maarten Lankhorst 
> > > > > > > Signed-off-by: Ville Syrjälä 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> > > > > > >  drivers/gpu/drm/i915/intel_dp.c  | 196 ++--
> > > > > > > 
> > > > > > > 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> > > > > > >  3 files changed, 120 insertions(+), 88 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > index 25793bdc692f..5f3d58f1ae6e 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct
> > > > > > > intel_encoder
> > > > > > > *encoder,
> > > > > > >   drm_modeset_acquire_init(, 0);
> > > > > > >  
> > > > > > >   for (;;) {
> > > > > > > - ret = intel_hdmi_reset_link(encoder, );
> > > > > > > + if (connector->base.connector_type ==
> > > > > > > DRM_MODE_CONNECTOR_HDMIA)
> > > > > > > + ret = intel_hdmi_reset_link(encoder,
> > > > > > > );
> > > > > > > + else
> > > > > > > + ret = intel_dp_retrain_link(encoder,
> > > > > > > );
> > > > > > >  
> > > > > > >   if (ret == -EDEADLK) {
> > > > > > >   drm_modeset_backoff();
> > > > > > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct drm_i915_private
> > > > > > > *dev_priv,
> > > > > > > enum port port)
> > > > > > >   drm_encoder_init(_priv->drm, encoder,
> > > > > > > _ddi_funcs,
> > > > > > >DRM_MODE_ENCODER_TMDS, "DDI %c",
> > > > > > > port_name(port));
> > > > > > >  
> > > > > > > - if (init_hdmi)
> > > > > > > - intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > > - else
> > > > > > > - intel_encoder->hotplug = intel_encoder_hotplug;
> > > > > > > + intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > >   intel_encoder->compute_output_type =
> > > > > > > intel_ddi_compute_output_type;
> > > > > > >   intel_encoder->compute_config = intel_ddi_compute_config;
> > > > > > >   intel_encoder->enable = intel_enable_ddi;
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > index 6bbf14410c2a..152016e09a11 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct intel_dp
> > > > > > > *intel_dp)
> > > > > > >   return -EINVAL;
> > > > > > >  }
> > > > > > >  
> > > > > > > -static void
> > > > > > > -intel_dp_retrain_link(struct intel_dp *intel_dp)
> > > > > > > +static bool
> > > > > > > +intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > > > > > > +{
> > > > > > > + u8 link_status[DP_LINK_STATUS_SIZE];
> > > > > > > +
> > > > > > > + if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > > > > > > + DRM_ERROR("Failed to get link status\n");
> > > > > > > +

Re: [Intel-gfx] [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Thierry Reding]

On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
> were adapted to this change.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>  drivers/bus/ts-nbus.c|  2 +-
>  drivers/clk/clk-pwm.c|  3 ++-
>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>  drivers/hwmon/pwm-fan.c  |  2 +-
>  drivers/input/misc/max77693-haptic.c |  2 +-
>  drivers/input/misc/max8997_haptic.c  |  6 +-
>  drivers/leds/leds-pwm.c  |  5 -
>  drivers/media/rc/ir-rx51.c   |  5 -
>  drivers/media/rc/pwm-ir-tx.c |  5 -
>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>  drivers/video/backlight/lp8788_bl.c  |  5 -
>  drivers/video/backlight/pwm_bl.c | 11 +--
>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>  include/linux/pwm.h  |  6 --
>  16 files changed, 70 insertions(+), 21 deletions(-)

I don't think it makes sense to leak mode support into the legacy API.
The pwm_config() function is considered legacy and should eventually go
away. As such it doesn't make sense to integrate a new feature such as
PWM modes into it. All users of pwm_config() assume normal mode, and
that's what pwm_config() should provide.

Anyone that needs something other than normal mode should use the new
atomic PWM API.

Thierry


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 v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Lyude Paul]

On Wed, 2018-02-28 at 11:27 -0800, Manasi Navare wrote:
> On Wed, Feb 28, 2018 at 02:07:34PM -0500, Lyude Paul wrote:
> > 
> > On Tue, 2018-02-27 at 23:17 -0800, Manasi Navare wrote:
> > > Ville,  thanks for the patch and
> > > Sorry for not being able to review this earlier.
> > > Please find some comments below:
> > > 
> > > On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > > > > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > > > > > From: Ville Syrjälä 
> > > > > > 
> > > > > > Doing link retraining from the short pulse handler is problematic
> > > > > > since
> > > > > > that might introduce deadlocks with MST sideband processing.
> > > > > > Currently
> > > > > > we don't retrain MST links from this code, but we want to change
> > > > > > that.
> > > > > > So better to move the entire thing to the hotplug work. We can
> > > > > > utilize
> > > > > > the new encoder->hotplug() hook for this.
> > > > > > 
> > > > > > The only thing we leave in the short pulse handler is the link
> > > > > > status
> > > > > > check. That one still depends on the link parameters stored under
> > > > > > intel_dp, so no locking around that but races should be mostly
> > > > > > harmless
> > > > > > as the actual retraining code will recheck the link state if we
> > > > > > end up there by mistake.
> > > > > > 
> > > > > > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > > > > > Check the connector type to figure out if we should do
> > > > > > the HDMI thing or the DP think for DDI
> > > > > > 
> > > > > > Cc: Manasi Navare 
> > > > > > Cc: Maarten Lankhorst 
> > > > > > Signed-off-by: Ville Syrjälä 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> > > > > >  drivers/gpu/drm/i915/intel_dp.c  | 196 ++--
> > > > > > 
> > > > > > 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> > > > > >  3 files changed, 120 insertions(+), 88 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > index 25793bdc692f..5f3d58f1ae6e 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct
> > > > > > intel_encoder
> > > > > > *encoder,
> > > > > > drm_modeset_acquire_init(, 0);
> > > > > >  
> > > > > > for (;;) {
> > > > > > -   ret = intel_hdmi_reset_link(encoder, );
> > > > > > +   if (connector->base.connector_type ==
> > > > > > DRM_MODE_CONNECTOR_HDMIA)
> > > > > > +   ret = intel_hdmi_reset_link(encoder,
> > > > > > );
> > > > > > +   else
> > > > > > +   ret = intel_dp_retrain_link(encoder,
> > > > > > );
> > > > > >  
> > > > > > if (ret == -EDEADLK) {
> > > > > > drm_modeset_backoff();
> > > > > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct drm_i915_private
> > > > > > *dev_priv,
> > > > > > enum port port)
> > > > > > drm_encoder_init(_priv->drm, encoder,
> > > > > > _ddi_funcs,
> > > > > >  DRM_MODE_ENCODER_TMDS, "DDI %c",
> > > > > > port_name(port));
> > > > > >  
> > > > > > -   if (init_hdmi)
> > > > > > -   intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > -   else
> > > > > > -   intel_encoder->hotplug = intel_encoder_hotplug;
> > > > > > +   intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > > intel_encoder->compute_output_type =
> > > > > > intel_ddi_compute_output_type;
> > > > > > intel_encoder->compute_config = intel_ddi_compute_config;
> > > > > > intel_encoder->enable = intel_enable_ddi;
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index 6bbf14410c2a..152016e09a11 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct intel_dp
> > > > > > *intel_dp)
> > > > > > return -EINVAL;
> > > > > >  }
> > > > > >  
> > > > > > -static void
> > > > > > -intel_dp_retrain_link(struct intel_dp *intel_dp)
> > > > > > +static bool
> > > > > > +intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > > > > > +{
> > > > > > +   u8 link_status[DP_LINK_STATUS_SIZE];
> > > > > > +
> > > > > > +   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > > > > > +   DRM_ERROR("Failed to get link status\n");
> > > > > > +   return false;
> > > > > > +   }
> > > > > > +
> > > > > > +   /*
> > > > > > +* Validate the cached values of intel_dp->link_rate and
> > > > > > +* intel_dp->lane_count before attempting to retrain.
> > > > > > +  

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Manasi Navare]

On Wed, Feb 28, 2018 at 02:07:34PM -0500, Lyude Paul wrote:
> 
> On Tue, 2018-02-27 at 23:17 -0800, Manasi Navare wrote:
> > Ville,  thanks for the patch and
> > Sorry for not being able to review this earlier.
> > Please find some comments below:
> > 
> > On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > > > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > Doing link retraining from the short pulse handler is problematic
> > > > > since
> > > > > that might introduce deadlocks with MST sideband processing. Currently
> > > > > we don't retrain MST links from this code, but we want to change that.
> > > > > So better to move the entire thing to the hotplug work. We can utilize
> > > > > the new encoder->hotplug() hook for this.
> > > > > 
> > > > > The only thing we leave in the short pulse handler is the link status
> > > > > check. That one still depends on the link parameters stored under
> > > > > intel_dp, so no locking around that but races should be mostly
> > > > > harmless
> > > > > as the actual retraining code will recheck the link state if we
> > > > > end up there by mistake.
> > > > > 
> > > > > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > > > > Check the connector type to figure out if we should do
> > > > > the HDMI thing or the DP think for DDI
> > > > > 
> > > > > Cc: Manasi Navare 
> > > > > Cc: Maarten Lankhorst 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> > > > >  drivers/gpu/drm/i915/intel_dp.c  | 196 ++--
> > > > > 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> > > > >  3 files changed, 120 insertions(+), 88 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > index 25793bdc692f..5f3d58f1ae6e 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct
> > > > > intel_encoder
> > > > > *encoder,
> > > > >   drm_modeset_acquire_init(, 0);
> > > > >  
> > > > >   for (;;) {
> > > > > - ret = intel_hdmi_reset_link(encoder, );
> > > > > + if (connector->base.connector_type ==
> > > > > DRM_MODE_CONNECTOR_HDMIA)
> > > > > + ret = intel_hdmi_reset_link(encoder, );
> > > > > + else
> > > > > + ret = intel_dp_retrain_link(encoder, );
> > > > >  
> > > > >   if (ret == -EDEADLK) {
> > > > >   drm_modeset_backoff();
> > > > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct drm_i915_private
> > > > > *dev_priv,
> > > > > enum port port)
> > > > >   drm_encoder_init(_priv->drm, encoder, _ddi_funcs,
> > > > >DRM_MODE_ENCODER_TMDS, "DDI %c",
> > > > > port_name(port));
> > > > >  
> > > > > - if (init_hdmi)
> > > > > - intel_encoder->hotplug = intel_ddi_hotplug;
> > > > > - else
> > > > > - intel_encoder->hotplug = intel_encoder_hotplug;
> > > > > + intel_encoder->hotplug = intel_ddi_hotplug;
> > > > >   intel_encoder->compute_output_type =
> > > > > intel_ddi_compute_output_type;
> > > > >   intel_encoder->compute_config = intel_ddi_compute_config;
> > > > >   intel_encoder->enable = intel_enable_ddi;
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 6bbf14410c2a..152016e09a11 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct intel_dp
> > > > > *intel_dp)
> > > > >   return -EINVAL;
> > > > >  }
> > > > >  
> > > > > -static void
> > > > > -intel_dp_retrain_link(struct intel_dp *intel_dp)
> > > > > +static bool
> > > > > +intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > > > > +{
> > > > > + u8 link_status[DP_LINK_STATUS_SIZE];
> > > > > +
> > > > > + if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > > > > + DRM_ERROR("Failed to get link status\n");
> > > > > + return false;
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > +  * Validate the cached values of intel_dp->link_rate and
> > > > > +  * intel_dp->lane_count before attempting to retrain.
> > > > > +  */
> > > > > + if (!intel_dp_link_params_valid(intel_dp, intel_dp-
> > > > > >link_rate,
> > > > > + intel_dp->lane_count))
> > > > > + return false;
> > > > > +
> > > > > + /* Retrain if Channel EQ or CR not ok */
> > > > > + return 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Removed unused GuC parameters.

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Removed unused GuC parameters.
URL   : https://patchwork.freedesktop.org/series/39154/
State : success

== Summary ==

Series 39154v1 drm/i915/guc: Removed unused GuC parameters.
https://patchwork.freedesktop.org/api/1.0/series/39154/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:493s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:288s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s

573e919160e546baa4268a213400f9f42f72ae97 drm-tip: 2018y-02m-28d-16h-17m-37s UTC 
integration manifest
413edd39a3f2 drm/i915/guc: Removed unused GuC parameters.

== Logs ==

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

Re: [Intel-gfx] [igt-dev] [PATCH igt 3/5] igt/gem_ctx_switch: Exercise all engines at once

[Antonio Argenziano]

On 28/02/18 07:51, Chris Wilson wrote:

Just a small variant to apply a continuous context-switch load to all
engines.
---
  tests/gem_ctx_switch.c | 83 ++
  1 file changed, 83 insertions(+)

diff --git a/tests/gem_ctx_switch.c b/tests/gem_ctx_switch.c
index 79b1d74b..4c7c5391 100644
--- a/tests/gem_ctx_switch.c
+++ b/tests/gem_ctx_switch.c
@@ -133,6 +133,84 @@ static void single(int fd, uint32_t handle,
gem_context_destroy(fd, contexts[n]);
  }
  
+static void all(int fd, uint32_t handle, unsigned flags, int timeout)

+{
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 obj[2];
+   unsigned int engine[16], e;
+   const char *name[16];
+   uint32_t contexts[65];
+   unsigned int nengine;
+   int n;
+
+   nengine = 0;
+   for_each_engine(fd, e) {
+   if (e == 0 || e == I915_EXEC_BSD)
+   continue;


for_each_physical_engine()?


+
+   engine[nengine] = e;
+   name[nengine] = e__->name;
+   nengine++;
+   }
+   igt_require(nengine);
+
+   igt_require(__gem_context_create(fd, [0]) == 0);


gem_require_contexts already in fixture.

Thanks,
Antonio


+   for (n = 1; n < ARRAY_SIZE(contexts); n++)
+   contexts[n] = gem_context_create(fd);
+
+   memset(obj, 0, sizeof(obj));
+   obj[1].handle = handle;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer(obj + 1);
+   execbuf.buffer_count = 1;
+   execbuf.rsvd1 = contexts[0];
+   execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
+   execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
+   igt_require(__gem_execbuf(fd, ) == 0);
+   gem_sync(fd, handle);
+   execbuf.buffers_ptr = to_user_pointer(obj);
+   execbuf.buffer_count = 2;
+
+   for (int pot = 2; pot <= 64; pot *= 2) {
+   for (int nctx = pot - 1; nctx <= pot + 1; nctx++) {
+   igt_fork(child, nengine) {
+   struct timespec start, now;
+   unsigned int count = 0;
+
+   obj[0].handle = gem_create(fd, 4096);
+   execbuf.flags |= engine[child];
+   for (int loop = 0; loop < ARRAY_SIZE(contexts); 
loop++) {
+   execbuf.rsvd1 = contexts[loop];
+   gem_execbuf(fd, );
+   }
+   gem_sync(fd, obj[0].handle);
+
+   clock_gettime(CLOCK_MONOTONIC, );
+   do {
+   for (int loop = 0; loop < 1024; loop++) 
{
+   execbuf.rsvd1 = contexts[loop % 
nctx];
+   gem_execbuf(fd, );
+   }
+   count += 1024;
+   clock_gettime(CLOCK_MONOTONIC, );
+   } while (elapsed(, ) < timeout);
+   gem_sync(fd, obj[0].handle);
+   clock_gettime(CLOCK_MONOTONIC, );
+   gem_close(fd, obj[0].handle);
+
+   igt_info("[%d:%d] %s: %'u cycles: %.3fus%s\n",
+nctx, child, name[child], count, 
elapsed(, )*1e6 / count,
+flags & INTERRUPTIBLE ? " (interruptible)" : 
"");
+   }
+   igt_waitchildren();
+   }
+   }
+
+   for (n = 0; n < ARRAY_SIZE(contexts); n++)
+   gem_context_destroy(fd, contexts[n]);
+}
+
  igt_main
  {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -175,6 +253,11 @@ igt_main
single(fd, light, e, INTERRUPTIBLE, ncpus, 150);
}
  
+	igt_subtest("basic-all")

+   all(fd, light, 0, 5);
+   igt_subtest("basic-all-heavy")
+   all(fd, heavy, 0, 20);
+
igt_fixture {
igt_stop_hang_detector();
gem_close(fd, heavy);


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

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Lyude Paul]

On Tue, 2018-02-27 at 23:17 -0800, Manasi Navare wrote:
> Ville,  thanks for the patch and
> Sorry for not being able to review this earlier.
> Please find some comments below:
> 
> On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Doing link retraining from the short pulse handler is problematic
> > > > since
> > > > that might introduce deadlocks with MST sideband processing. Currently
> > > > we don't retrain MST links from this code, but we want to change that.
> > > > So better to move the entire thing to the hotplug work. We can utilize
> > > > the new encoder->hotplug() hook for this.
> > > > 
> > > > The only thing we leave in the short pulse handler is the link status
> > > > check. That one still depends on the link parameters stored under
> > > > intel_dp, so no locking around that but races should be mostly
> > > > harmless
> > > > as the actual retraining code will recheck the link state if we
> > > > end up there by mistake.
> > > > 
> > > > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > > > Check the connector type to figure out if we should do
> > > > the HDMI thing or the DP think for DDI
> > > > 
> > > > Cc: Manasi Navare 
> > > > Cc: Maarten Lankhorst 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> > > >  drivers/gpu/drm/i915/intel_dp.c  | 196 ++--
> > > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> > > >  3 files changed, 120 insertions(+), 88 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 25793bdc692f..5f3d58f1ae6e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct
> > > > intel_encoder
> > > > *encoder,
> > > > drm_modeset_acquire_init(, 0);
> > > >  
> > > > for (;;) {
> > > > -   ret = intel_hdmi_reset_link(encoder, );
> > > > +   if (connector->base.connector_type ==
> > > > DRM_MODE_CONNECTOR_HDMIA)
> > > > +   ret = intel_hdmi_reset_link(encoder, );
> > > > +   else
> > > > +   ret = intel_dp_retrain_link(encoder, );
> > > >  
> > > > if (ret == -EDEADLK) {
> > > > drm_modeset_backoff();
> > > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct drm_i915_private
> > > > *dev_priv,
> > > > enum port port)
> > > > drm_encoder_init(_priv->drm, encoder, _ddi_funcs,
> > > >  DRM_MODE_ENCODER_TMDS, "DDI %c",
> > > > port_name(port));
> > > >  
> > > > -   if (init_hdmi)
> > > > -   intel_encoder->hotplug = intel_ddi_hotplug;
> > > > -   else
> > > > -   intel_encoder->hotplug = intel_encoder_hotplug;
> > > > +   intel_encoder->hotplug = intel_ddi_hotplug;
> > > > intel_encoder->compute_output_type =
> > > > intel_ddi_compute_output_type;
> > > > intel_encoder->compute_config = intel_ddi_compute_config;
> > > > intel_encoder->enable = intel_enable_ddi;
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 6bbf14410c2a..152016e09a11 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct intel_dp
> > > > *intel_dp)
> > > > return -EINVAL;
> > > >  }
> > > >  
> > > > -static void
> > > > -intel_dp_retrain_link(struct intel_dp *intel_dp)
> > > > +static bool
> > > > +intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > > > +{
> > > > +   u8 link_status[DP_LINK_STATUS_SIZE];
> > > > +
> > > > +   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > > > +   DRM_ERROR("Failed to get link status\n");
> > > > +   return false;
> > > > +   }
> > > > +
> > > > +   /*
> > > > +* Validate the cached values of intel_dp->link_rate and
> > > > +* intel_dp->lane_count before attempting to retrain.
> > > > +*/
> > > > +   if (!intel_dp_link_params_valid(intel_dp, intel_dp-
> > > > >link_rate,
> > > > +   intel_dp->lane_count))
> > > > +   return false;
> > > > +
> > > > +   /* Retrain if Channel EQ or CR not ok */
> > > > +   return !drm_dp_channel_eq_ok(link_status, intel_dp-
> > > > >lane_count);
> > > > +}
> > > > +
> > > > +/*
> > > > + * If display is now connected check links status,
> > > > + * there has been known issues of link loss 

Re: [Intel-gfx] [PATCH] drm/i915: Wedged engine mask makes more sense in hex

[Michel Thierry]

On 28/02/18 09:18, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In decimal its just a weird big number, while in hex can actually log
which engines were requested to be wedged.



And IGT is not reading the hang reason in this case, so


Reviewed-by: Michel Thierry 


Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 472240349388..2a4c258b90fd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3977,7 +3977,8 @@ i915_wedged_set(void *data, u64 val)
engine->hangcheck.stalled = true;
}
  
-	i915_handle_error(i915, val, "Manually setting wedged to %llu", val);

+   i915_handle_error(i915, val, "Manually set wedged engine mask = %llx",
+ val);
  
  	wait_on_bit(>gpu_error.flags,

I915_RESET_HANDOFF,


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

[Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

[Piotr Piórkowski]

In the i915 driver, there is a function, intel_guc_init_params(),
which initializes the GuC parameter block which is passed into
the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
GfxGtType and GfxCoreFamily unused by GuC.

This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
GfxCoreFamily parameters and also unnecessary functions
get_gt_type() and get_core_family().

Signed-off-by: Piotr Piórkowski 
---
 drivers/gpu/drm/i915/i915_params.h|  2 +-
 drivers/gpu/drm/i915/intel_guc.c  | 24 
 drivers/gpu/drm/i915/intel_guc_fwif.h |  4 
 drivers/gpu/drm/i915/intel_uc.c   |  2 ++
 4 files changed, 3 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..3deae1e22974 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 21140ccd7a97..5f6d84251830 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -200,26 +200,6 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
 }
 
-static u32 get_gt_type(struct drm_i915_private *dev_priv)
-{
-   /* XXX: GT type based on PCI device ID? field seems unused by fw */
-   return 0;
-}
-
-static u32 get_core_family(struct drm_i915_private *dev_priv)
-{
-   u32 gen = INTEL_GEN(dev_priv);
-
-   switch (gen) {
-   case 9:
-   return GUC_CORE_FAMILY_GEN9;
-
-   default:
-   MISSING_CASE(gen);
-   return GUC_CORE_FAMILY_UNKNOWN;
-   }
-}
-
 static u32 get_log_verbosity_flags(void)
 {
if (i915_modparams.guc_log_level > 0) {
@@ -246,10 +226,6 @@ void intel_guc_init_params(struct intel_guc *guc)
 
memset(params, 0, sizeof(params));
 
-   params[GUC_CTL_DEVICE_INFO] |=
-   (get_gt_type(dev_priv) << GUC_CTL_GT_TYPE_SHIFT) |
-   (get_core_family(dev_priv) << GUC_CTL_CORE_FAMILY_SHIFT);
-
/*
 * GuC ARAT increment is 10 ns. GuC default scheduler quantum is one
 * second. This ARAR is calculated by:
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..0f381de44722 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -81,10 +81,6 @@
 #define GUC_CTL_ARAT_HIGH  1
 #define GUC_CTL_ARAT_LOW   2
 
-#define GUC_CTL_DEVICE_INFO3
-#define   GUC_CTL_GT_TYPE_SHIFT0
-#define   GUC_CTL_CORE_FAMILY_SHIFT7
-
 #define GUC_CTL_LOG_PARAMS 4
 #define   GUC_LOG_VALID(1 << 0)
 #define   GUC_LOG_NOTIFY_ON_HALF_FULL  (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9f1bac6398fb..b48056fb769d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
2.14.3

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array

[Jani Nikula]

On Wed, 28 Feb 2018, Manasi Navare  wrote:
> On Wed, Feb 28, 2018 at 11:05:24AM +0200, Jani Nikula wrote:
>> On Tue, 27 Feb 2018, Manasi Navare  wrote:
>> > default_rates[] array is a superset of all the link rates supported
>> > by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
>> > to the set of link rates supported by sink. This patch adds this rate
>> > to default_rates[] array that gets used to populate the sink_rates[]
>> > array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register.
>> >
>> > Cc: Jani Nikula 
>> > Cc: Ville Syrjälä 
>> > Signed-off-by: Manasi Navare 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> > b/drivers/gpu/drm/i915/intel_dp.c
>> > index 2a3b3ae..f0766fb 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > @@ -103,7 +103,7 @@ static const int skl_rates[] = { 162000, 216000, 
>> > 27,
>> >  static const int cnl_rates[] = { 162000, 216000, 27,
>> > 324000, 432000, 54,
>> > 648000, 81 };
>> > -static const int default_rates[] = { 162000, 27, 54 };
>> > +static const int default_rates[] = { 162000, 27, 54, 81 };
>> 
>> Now this is part of the reason I wanted to do [1], especially the part
>> that switches to using hsw_rates and g4x_rates, instead of doing
>> ARRAY_SIZE(default_rates) - 1. This innocent looking patch now "enables"
>> HBR2 on g4x and HBR3 on hsw and bdw.
>> 
>> BR,
>> Jani.
>>
>
> Oh yes I didnt realize that default rates are also getting used to populate
> the source rates for HSW and g4x. Yes so localized or not, we definetly need 
> to separate
> out the hsw and g4x rates. and then we can add 81 in the array and call 
> it dp_rates
> like your patch does.
>
> I will try to combine your patch with this and resubmit.

Combine what part? Please don't conflate the two into one.

BR,
Jani.


>
> Manasi
>  
>> 
>> [1] 
>> http://patchwork.freedesktop.org/patch/msgid/20180227105911.4485-1-jani.nik...@intel.com
>> 
>> 
>> >  
>> >  /**
>> >   * intel_dp_is_edp - is the given port attached to an eDP panel (either 
>> > CPU or PCH)
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center

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

Re: [Intel-gfx] [PATCH] drm/i915/perf: fix perf stream opening lock

[Matthew Auld]

On 28 February 2018 at 11:45, Lionel Landwerlin
 wrote:
> We're seeing on CI that some contexts don't have the programmed OA
> period timer that directs the OA unit on how often to write reports.
>
> The issue is that we're not holding the drm lock from when we edit the
> context images down to when we set the exclusive_stream variable. This
> leaves a window for the deferred context allocation to call
> i915_oa_init_reg_state() that will not program the expected OA timer
> value, because we haven't set the exclusive_stream yet.
>
> Signed-off-by: Lionel Landwerlin 
> Fixes: 701f8231a2f ("drm/i915/perf: prune OA configs")
> Cc:  # v4.14+
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102254
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 41 
> +++-
>  1 file changed, 19 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 2741b1bc7095..7016abfc8ba9 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1757,21 +1757,16 @@ static int 
> gen8_switch_to_updated_kernel_context(struct drm_i915_private *dev_pr
>   */
>  static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
>const struct i915_oa_config *oa_config,
> -  bool interruptible)
> +  bool need_lock)
>  {
> struct i915_gem_context *ctx;
> int ret;
> unsigned int wait_flags = I915_WAIT_LOCKED;
>
> -   if (interruptible) {
> -   ret = i915_mutex_lock_interruptible(_priv->drm);
> -   if (ret)
> -   return ret;
> -
> -   wait_flags |= I915_WAIT_INTERRUPTIBLE;
> -   } else {
> +   if (need_lock)
> mutex_lock(_priv->drm.struct_mutex);
> -   }
> +
> +   lockdep_assert_held(_priv->drm.struct_mutex);
>
> /* Switch away from any user context. */
> ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
> @@ -1819,7 +1814,8 @@ static int gen8_configure_all_contexts(struct 
> drm_i915_private *dev_priv,
> }
>
>   out:
> -   mutex_unlock(_priv->drm.struct_mutex);
> +   if (need_lock)
> +   mutex_unlock(_priv->drm.struct_mutex);
>
> return ret;
>  }
> @@ -1863,7 +1859,7 @@ static int gen8_enable_metric_set(struct 
> drm_i915_private *dev_priv,
>  * to make sure all slices/subslices are ON before writing to NOA
>  * registers.
>  */
> -   ret = gen8_configure_all_contexts(dev_priv, oa_config, true);
> +   ret = gen8_configure_all_contexts(dev_priv, oa_config, false);
> if (ret)
> return ret;
>
> @@ -1878,7 +1874,7 @@ static int gen8_enable_metric_set(struct 
> drm_i915_private *dev_priv,
>  static void gen8_disable_metric_set(struct drm_i915_private *dev_priv)
>  {
> /* Reset all contexts' slices/subslices configurations. */
> -   gen8_configure_all_contexts(dev_priv, NULL, false);
> +   gen8_configure_all_contexts(dev_priv, NULL, true);

Maybe move the ops.disable_metric_set() to also be within the lock, so
need_lock=false, then we can get rid of need_lock?

>
> I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
>   ~GT_NOA_ENABLE));
> @@ -1888,7 +1884,7 @@ static void gen8_disable_metric_set(struct 
> drm_i915_private *dev_priv)
>  static void gen10_disable_metric_set(struct drm_i915_private *dev_priv)
>  {
> /* Reset all contexts' slices/subslices configurations. */
> -   gen8_configure_all_contexts(dev_priv, NULL, false);
> +   gen8_configure_all_contexts(dev_priv, NULL, true);
>
> /* Make sure we disable noa to save power. */
> I915_WRITE(RPM_CONFIG1,
> @@ -2138,13 +2134,6 @@ static int i915_oa_stream_init(struct i915_perf_stream 
> *stream,
> if (ret)
> goto err_oa_buf_alloc;
>
> -   ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
> - stream->oa_config);
> -   if (ret)
> -   goto err_enable;
> -
> -   stream->ops = _oa_stream_ops;
> -
> /* Lock device for exclusive_stream access late because
>  * enable_metric_set() might lock as well on gen8+.
>  */

Ok, we can get rid of this comment now.

> @@ -2152,16 +2141,24 @@ static int i915_oa_stream_init(struct 
> i915_perf_stream *stream,
> if (ret)
> goto err_lock;
>
> +   ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
> + stream->oa_config);
> +   if (ret)
> +   

Re: [Intel-gfx] [PATCH v9] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

[Oscar Mateo]

On 2/26/2018 9:49 PM, Sagar Arun Kamble wrote:



On 2/27/2018 4:34 AM, Oscar Mateo wrote:



On 2/25/2018 9:22 PM, Sagar Arun Kamble wrote:



On 2/23/2018 4:35 AM, Oscar Mateo wrote:





+ * We might have detected that some engines are fused off after 
we initialized
+ * the forcewake domains. Prune them, to make sure they only 
reference existing

+ * engines.
+ */
+void intel_uncore_prune(struct drm_i915_private *dev_priv)
+{
+    if (INTEL_GEN(dev_priv) >= 11) {
+    enum forcewake_domains fw_domains = 
dev_priv->uncore.fw_domains;

+    enum forcewake_domain_id domain_id;
+    int i;
+
+    for (i = 0; i < I915_MAX_VCS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VDBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VCS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
fw_domains check seems redundant as it is initialized based on 
HAS_ENGINE.

we can just have
if (!HAS_ENGINE(dev_priv, _VCS(i)))
    fw_domain_fini(dev_priv, domain_id);


I don't want to call fw_domain_fini on something we never 
initialized in the first place (e.g. VCS1/3 and VECS1/2/3 on an 
ICL-LP).



Right. Makes sense.
for loop iterating over engines based on ring_mask can help us rely 
on only HAS_ENGINE condition and then we can have complete pruning 
in single for loop.

what do you think?


Hmmm.. I'm not sure I follow: intel_device_info_init_mmio modifies 
ring_mask, so if I loop over engines based on ring_mask I am going to 
miss those I want to prune, right?



Oops ... you are right ...
My suggestion about skipping fw_domains check will not work currently. 
In future may be if we create default ring_mask and runtime ring_mask 
it can be reworked.


Other suggestion to use single for loop (for_each_engine()) can be 
done I think.
It will make it generic for all engine types.  Below is what I am 
thinking of as part of intel_uncore_prune:


for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
    if (HAS_ENGINE(dev_priv, i))
        continue;
    if (fw_domains & BIT(i))
        fw_domain_fini(dev_priv, i);
}


This won't work either, because the index for engines and forcewake 
domains is different. If you think it is important to make the prune 
function more generic, I can translate between the two (but it will be 
for naught if, as you mentioned, we are working to create separate 
default ring_mask and runtime ring_mask in the future).



+ fw_domain_fini(dev_priv, domain_id);
+    }
+
+    for (i = 0; i < I915_MAX_VECS; i++) {
+    domain_id = FW_DOMAIN_ID_MEDIA_VEBOX0 + i;
+
+    if (HAS_ENGINE(dev_priv, _VECS(i)))
+    continue;
+
+    if (fw_domains & BIT(domain_id))
+    fw_domain_fini(dev_priv, domain_id);
+    }
+    }
+}
+
  void intel_uncore_fini(struct drm_i915_private *dev_priv)
  {
  /* Paranoia: make sure we have disabled everything before 
we exit. */
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h

index 53ef77d..28feabf 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -129,6 +129,7 @@ struct intel_uncore {
    void intel_uncore_sanitize(struct drm_i915_private *dev_priv);
  void intel_uncore_init(struct drm_i915_private *dev_priv);
+void intel_uncore_prune(struct drm_i915_private *dev_priv);
  bool intel_uncore_unclaimed_mmio(struct drm_i915_private 
*dev_priv);
  bool intel_uncore_arm_unclaimed_mmio_detection(struct 
drm_i915_private *dev_priv);

  void intel_uncore_fini(struct drm_i915_private *dev_priv);












___
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: Wedged engine mask makes more sense in hex

[Patchwork]

== Series Details ==

Series: drm/i915: Wedged engine mask makes more sense in hex
URL   : https://patchwork.freedesktop.org/series/39147/
State : success

== Summary ==

Series 39147v1 drm/i915: Wedged engine mask makes more sense in hex
https://patchwork.freedesktop.org/api/1.0/series/39147/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-skl-guc) fdo#103191

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:464s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:590s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-skl-guc   total:245  pass:220  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:529s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s

573e919160e546baa4268a213400f9f42f72ae97 drm-tip: 2018y-02m-28d-16h-17m-37s UTC 
integration manifest
a1a2ccdff789 drm/i915: Wedged engine mask makes more sense in hex

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8188/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/dp: Add HBR3 rate (8.1 Gbps) to default rates array

[Manasi Navare]

On Wed, Feb 28, 2018 at 11:05:24AM +0200, Jani Nikula wrote:
> On Tue, 27 Feb 2018, Manasi Navare  wrote:
> > default_rates[] array is a superset of all the link rates supported
> > by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
> > to the set of link rates supported by sink. This patch adds this rate
> > to default_rates[] array that gets used to populate the sink_rates[]
> > array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register.
> >
> > Cc: Jani Nikula 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2a3b3ae..f0766fb 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -103,7 +103,7 @@ static const int skl_rates[] = { 162000, 216000, 27,
> >  static const int cnl_rates[] = { 162000, 216000, 27,
> >  324000, 432000, 54,
> >  648000, 81 };
> > -static const int default_rates[] = { 162000, 27, 54 };
> > +static const int default_rates[] = { 162000, 27, 54, 81 };
> 
> Now this is part of the reason I wanted to do [1], especially the part
> that switches to using hsw_rates and g4x_rates, instead of doing
> ARRAY_SIZE(default_rates) - 1. This innocent looking patch now "enables"
> HBR2 on g4x and HBR3 on hsw and bdw.
> 
> BR,
> Jani.
>

Oh yes I didnt realize that default rates are also getting used to populate
the source rates for HSW and g4x. Yes so localized or not, we definetly need to 
separate
out the hsw and g4x rates. and then we can add 81 in the array and call it 
dp_rates
like your patch does.

I will try to combine your patch with this and resubmit.

Manasi
 
> 
> [1] 
> http://patchwork.freedesktop.org/patch/msgid/20180227105911.4485-1-jani.nik...@intel.com
> 
> 
> >  
> >  /**
> >   * intel_dp_is_edp - is the given port attached to an eDP panel (either 
> > CPU or PCH)
> 
> -- 
> 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: Wedged engine mask makes more sense in hex

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In decimal its just a weird big number, while in hex can actually log
which engines were requested to be wedged.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 472240349388..2a4c258b90fd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3977,7 +3977,8 @@ i915_wedged_set(void *data, u64 val)
engine->hangcheck.stalled = true;
}
 
-   i915_handle_error(i915, val, "Manually setting wedged to %llu", val);
+   i915_handle_error(i915, val, "Manually set wedged engine mask = %llx",
+ val);
 
wait_on_bit(>gpu_error.flags,
I915_RESET_HANDOFF,
-- 
2.14.1

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

[Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Test busyness reporting in face of GPU hangs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Verify that the reported busyness is in line with what would we expect
from a batch which causes a hang and gets kicked out from the engine.

v2: Change to explicit igt_force_gpu_reset instead of guessing when a spin
batch will hang. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 tests/perf_pmu.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 3bbb18d2f216..f5c70776e2cf 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -168,6 +168,7 @@ static unsigned int e2ring(int gem_fd, const struct 
intel_execution_engine2 *e)
 #define TEST_TRAILING_IDLE (4)
 #define TEST_RUNTIME_PM (8)
 #define FLAG_LONG (16)
+#define FLAG_HANG (32)
 
 static void end_spin(int fd, igt_spin_t *spin, unsigned int flags)
 {
@@ -204,11 +205,27 @@ single(int gem_fd, const struct intel_execution_engine2 
*e, unsigned int flags)
end_spin(gem_fd, spin, flags);
val = pmu_read_single(fd) - val;
 
-   end_spin(gem_fd, spin, FLAG_SYNC);
+   if (flags & FLAG_HANG)
+   igt_force_gpu_reset(gem_fd);
+   else
+   end_spin(gem_fd, spin, FLAG_SYNC);
+
+   assert_within_epsilon(val, flags & TEST_BUSY ? slept : 0.f, tolerance);
+
+   /* Check for idle after hang. */
+   if (flags & FLAG_HANG) {
+   /* Sleep for a bit for reset unwind to settle. */
+   sleep(1);
+   val = pmu_read_single(fd);
+   slept = measured_usleep(batch_duration_ns / 1000);
+   val = pmu_read_single(fd) - val;
+
+   assert_within_epsilon(val, 0, tolerance);
+   }
+
igt_spin_batch_free(gem_fd, spin);
close(fd);
 
-   assert_within_epsilon(val, flags & TEST_BUSY ? slept : 0.f, tolerance);
gem_quiescent_gpu(gem_fd);
 }
 
@@ -1690,6 +1707,9 @@ igt_main
  pct[i], e->name)
accuracy(fd, e, pct[i]);
}
+
+   igt_subtest_f("busy-hang-%s", e->name)
+   single(fd, e, TEST_BUSY | FLAG_HANG);
}
 
/**
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset

[Imre Deak]

On Wed, Feb 28, 2018 at 06:05:11PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 05:36:56PM +0200, Imre Deak wrote:
> > Enabling FBC on a plane having a Y-offset that isn't dividable by 4 may
> > cause pipe FIFO underruns and flickers, so disable FBC on such a config.
> > 
> > I tried to the followings to work around the issue:
> > - enable each HW work around in ILK_DPFC_CHICKEN
> > - disable each compression algorithm in ILK_DPFC_CONTROL
> > - disable low-power watermarks
> > None of the above got rid of the problem. I haven't found this issue in
> > the Bspec/WA database either.
> > 
> > Besides the igt testcase below (yet to be merged) an easy way to
> > reproduce the issue is to enable a plane with FBC and a plane Y-offset
> > not aligned to 4 and then just enable/disable FBC in a loop, keeping the
> > plane enabled.
> > 
> > I could trigger the problem on BXT/GLK/SKL, so assume for now that it's
> > only present on GEN9.
> > 
> > Cc: Paulo Zanoni 
> > Cc: Ville Syrjälä 
> > Testcase: igt/kms_plane/plane-clipping-pipe-A-planes
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 38b036c499d9..224c6a795f70 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -859,6 +859,17 @@ static bool intel_fbc_can_activate(struct intel_crtc 
> > *crtc)
> > return false;
> > }
> >  
> > +   /*
> > +* Work around a problem on GEN9 HW, where enabling FBC on a plane
> > +* having a Y offset that isn't dividable by 4 causes FIFO underrun
> > +* and screen ficker.
> 
> "divisible", "flicker"
> 
> > +*/
> > +   if (INTEL_GEN(dev_priv) == 9 &&
> 
> IS_GEN9()?

Ok, will fix those.

> 
> I do wonder about gen10+ however. GLK display pipes/planes did come
> from CNL after all so it seems at least possible tht CNL suffers from
> the same issue.

Hm, right. I thought to enable the WA on CNL in case the same happens in
CI once the igt test is merged. It happens with the testcase somewhat
sporadically though but easy to repro with the FBC on/off method, so
I'll give it a go tomorrow on CNL as well.

I wonder if adding a better testcase doing only FBC on/off would make
sense (without the current delay during FBC enabling).

> 
> The patch seems sensible either way so
> Reviewed-by: Ville Syrjälä 
> 
> > +   (fbc->state_cache.plane.adjusted_y & 3)) {
> > +   fbc->no_fbc_reason = "plane Y offset is misaligned";
> > +   return false;
> > +   }
> > +
> > return true;
> >  }
> >  
> > -- 
> > 2.13.2
> 
> -- 
> 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 5/8] drm/i915: Consult aux_ch instead of port in ->get_aux_clock_divider()

[Ville Syrjälä]

On Thu, Feb 22, 2018 at 08:10:33PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> While it seems totally unlikely that any system would mix a cpu/north
> aux channel with a pch/south port (or vice versa) we should still
> consult intel_dp->aux_ch rather than encoder->port when figuring out
> which clock is actually used by the aux ch.
> 
> Signed-off-by: Ville Syrjälä 

Pushed to dinq with Chris's irc r-b:
15:07 < vsyrjala> a few trivial patches looking for r-bs: 
https://patchwork.freedesktop.org/patch/206279/
  https://patchwork.freedesktop.org/patch/206280/
15:41 < ickle> s/_ch/_xfer/ r-b
15:42 < ickle> aux_ch makes sense, but requires some reading for me
16:26 < ickle> vsyrjala: read enough to be happy with AUX_CH_foo, so r-b

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2c3eb90b9499..8d503be73dbd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -956,8 +956,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool 
> has_aux_irq)
>  
>  static uint32_t g4x_get_aux_clock_divider(struct intel_dp *intel_dp, int 
> index)
>  {
> - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv = 
> to_i915(intel_dig_port->base.base.dev);
> + struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
>  
>   if (index)
>   return 0;
> @@ -971,8 +970,7 @@ static uint32_t g4x_get_aux_clock_divider(struct intel_dp 
> *intel_dp, int index)
>  
>  static uint32_t ilk_get_aux_clock_divider(struct intel_dp *intel_dp, int 
> index)
>  {
> - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv = 
> to_i915(intel_dig_port->base.base.dev);
> + struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
>  
>   if (index)
>   return 0;
> @@ -982,7 +980,7 @@ static uint32_t ilk_get_aux_clock_divider(struct intel_dp 
> *intel_dp, int index)
>* like to run at 2MHz.  So, take the cdclk or PCH rawclk value and
>* divide by 2000 and use that
>*/
> - if (intel_dig_port->base.port == PORT_A)
> + if (intel_dp->aux_ch == AUX_CH_A)
>   return DIV_ROUND_CLOSEST(dev_priv->cdclk.hw.cdclk, 2000);
>   else
>   return DIV_ROUND_CLOSEST(dev_priv->rawclk_freq, 2000);
> @@ -990,10 +988,9 @@ static uint32_t ilk_get_aux_clock_divider(struct 
> intel_dp *intel_dp, int index)
>  
>  static uint32_t hsw_get_aux_clock_divider(struct intel_dp *intel_dp, int 
> index)
>  {
> - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv = 
> to_i915(intel_dig_port->base.base.dev);
> + struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
>  
> - if (intel_dig_port->base.port != PORT_A && HAS_PCH_LPT_H(dev_priv)) {
> + if (intel_dp->aux_ch != AUX_CH_A && HAS_PCH_LPT_H(dev_priv)) {
>   /* Workaround for non-ULT HSW */
>   switch (index) {
>   case 0: return 63;
> -- 
> 2.13.6

-- 
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 06/43] misc/mei/hdcp: Add KBuild for mei hdcp driver

[Winkler, Tomas]

> On Wednesday 14 February 2018 08:24 PM, Winkler, Tomas wrote:
> >> Signed-off-by: Ramalingam C 
> >> ---
> >>   drivers/misc/mei/Kconfig  | 6 ++
> >>   drivers/misc/mei/Makefile | 2 ++
> >>   2 files changed, 8 insertions(+)
> >>
> >> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
> >> index
> >> c49e1d2269af..90977132d1e2 100644
> >> --- a/drivers/misc/mei/Kconfig
> >> +++ b/drivers/misc/mei/Kconfig
> >> @@ -43,3 +43,9 @@ config INTEL_MEI_TXE
> >>
> >>  Supported SoCs:
> >>  Intel Bay Trail
> >> +
> >> +config INTEL_MEI_HDCP
> >> +  tristate "Intel HDCP2.2 services of ME Interface"
> >> +  depends on INTEL_MEI && DRM_I915
> >> +  help
> >> +MEI Support for HDCP2.2 Services on Intel SoCs.
> >> diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
> >> index cd6825afa8e1..ee19754c1aec 100644
> >> --- a/drivers/misc/mei/Makefile
> >> +++ b/drivers/misc/mei/Makefile
> >> @@ -23,3 +23,5 @@ mei-txe-objs += hw-txe.o
> >>
> >>   mei-$(CONFIG_EVENT_TRACING) += mei-trace.o  CFLAGS_mei-trace.o = -
> >> I$(src)
> >> +
> >> +obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o
> > Should go to the separate directory.
> Instead of dedicated makefile for a single file, can I do something like
> 
> +obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/mei_hdcp.o
> 
Both will work, but it should be a new Makefile as we need that separation.
Thanks
Tomas

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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 05:36:56PM +0200, Imre Deak wrote:
> Enabling FBC on a plane having a Y-offset that isn't dividable by 4 may
> cause pipe FIFO underruns and flickers, so disable FBC on such a config.
> 
> I tried to the followings to work around the issue:
> - enable each HW work around in ILK_DPFC_CHICKEN
> - disable each compression algorithm in ILK_DPFC_CONTROL
> - disable low-power watermarks
> None of the above got rid of the problem. I haven't found this issue in
> the Bspec/WA database either.
> 
> Besides the igt testcase below (yet to be merged) an easy way to
> reproduce the issue is to enable a plane with FBC and a plane Y-offset
> not aligned to 4 and then just enable/disable FBC in a loop, keeping the
> plane enabled.
> 
> I could trigger the problem on BXT/GLK/SKL, so assume for now that it's
> only present on GEN9.
> 
> Cc: Paulo Zanoni 
> Cc: Ville Syrjälä 
> Testcase: igt/kms_plane/plane-clipping-pipe-A-planes
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 38b036c499d9..224c6a795f70 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -859,6 +859,17 @@ static bool intel_fbc_can_activate(struct intel_crtc 
> *crtc)
>   return false;
>   }
>  
> + /*
> +  * Work around a problem on GEN9 HW, where enabling FBC on a plane
> +  * having a Y offset that isn't dividable by 4 causes FIFO underrun
> +  * and screen ficker.

"divisible", "flicker"

> +  */
> + if (INTEL_GEN(dev_priv) == 9 &&

IS_GEN9()?

I do wonder about gen10+ however. GLK display pipes/planes did come
from CNL after all so it seems at least possible tht CNL suffers from
the same issue.

The patch seems sensible either way so
Reviewed-by: Ville Syrjälä 

> + (fbc->state_cache.plane.adjusted_y & 3)) {
> + fbc->no_fbc_reason = "plane Y offset is misaligned";
> + return false;
> + }
> +
>   return true;
>  }
>  
> -- 
> 2.13.2

-- 
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 drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset
URL   : https://patchwork.freedesktop.org/series/39129/
State : success

== Summary ==

Series 39129v1 drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset
https://patchwork.freedesktop.org/api/1.0/series/39129/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#103191

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:389s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:494s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:479s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s

4d8ce7ac845a5152c92a18afb0e22e9278c9f7e1 drm-tip: 2018y-02m-28d-14h-17m-44s UTC 
integration manifest
1f0c25767bfc drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset

== Logs ==

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

[Intel-gfx] [PATCH igt 4/5] igt/gem_exec_capture: Exercise readback of userptr

[Chris Wilson]

EXEC_OBJECT_CAPTURE extends the type of buffers we may read during error
capture. Previously we knew that we would only see batch buffers (which
limited the objects to being from gem_create()), but now we need to
check that any buffer the user can create can be read. The first
alternate buffer type is a userptr.

Signed-off-by: Chris Wilson 
---
 tests/gem_exec_capture.c | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/tests/gem_exec_capture.c b/tests/gem_exec_capture.c
index 43c443be..2dc06ce4 100644
--- a/tests/gem_exec_capture.c
+++ b/tests/gem_exec_capture.c
@@ -57,7 +57,7 @@ static void check_error_state(int dir, struct 
drm_i915_gem_exec_object2 *obj)
igt_assert(found);
 }
 
-static void capture(int fd, int dir, unsigned ring)
+static void __capture(int fd, int dir, unsigned ring, uint32_t target)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
struct drm_i915_gem_exec_object2 obj[4];
@@ -72,7 +72,7 @@ static void capture(int fd, int dir, unsigned ring)
 
memset(obj, 0, sizeof(obj));
obj[SCRATCH].handle = gem_create(fd, 4096);
-   obj[CAPTURE].handle = gem_create(fd, 4096);
+   obj[CAPTURE].handle = target;
obj[CAPTURE].flags = LOCAL_OBJECT_CAPTURE;
obj[NOCAPTURE].handle = gem_create(fd, 4096);
 
@@ -159,10 +159,32 @@ static void capture(int fd, int dir, unsigned ring)
 
gem_close(fd, obj[BATCH].handle);
gem_close(fd, obj[NOCAPTURE].handle);
-   gem_close(fd, obj[CAPTURE].handle);
gem_close(fd, obj[SCRATCH].handle);
 }
 
+static void capture(int fd, int dir, unsigned ring)
+{
+   uint32_t handle;
+
+   handle = gem_create(fd, 4096);
+   __capture(fd, dir, ring, handle);
+   gem_close(fd, handle);
+}
+
+static void userptr(int fd, int dir)
+{
+   uint32_t handle;
+   void *ptr;
+
+   igt_assert(posix_memalign(, 4096, 4096) == 0);
+   igt_require(__gem_userptr(fd, ptr, 4096, 0, 0, ) == 0);
+
+   __capture(fd, dir, 0, handle);
+
+   gem_close(fd, handle);
+   free(ptr);
+}
+
 static bool has_capture(int fd)
 {
drm_i915_getparam_t gp;
@@ -214,6 +236,13 @@ igt_main
}
}
 
+   /* And check we can read from different types of objects */
+
+   igt_subtest_f("userptr") {
+   igt_require(gem_can_store_dword(fd, 0));
+   userptr(fd, dir);
+   }
+
igt_fixture {
close(dir);
igt_disallow_hang(fd, hang);
-- 
2.16.2

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

[Intel-gfx] [PATCH igt 5/5] igt/gem_exec_fence: Exercise merging fences

[Chris Wilson]

Execute the same batch on each engine and check that the composite fence
across all engines completes only after the batch is completed on every
engine.

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

diff --git a/tests/gem_exec_fence.c b/tests/gem_exec_fence.c
index 93ed3b9b..36459e56 100644
--- a/tests/gem_exec_fence.c
+++ b/tests/gem_exec_fence.c
@@ -208,6 +208,113 @@ static void test_fence_busy(int fd, unsigned ring, 
unsigned flags)
gem_quiescent_gpu(fd);
 }
 
+static void test_fence_busy_all(int fd, unsigned flags)
+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   struct drm_i915_gem_exec_object2 obj;
+   struct drm_i915_gem_relocation_entry reloc;
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct timespec tv;
+   uint32_t *batch;
+   unsigned int engine;
+   int all, i, timeout;
+
+   gem_quiescent_gpu(fd);
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer();
+   execbuf.buffer_count = 1;
+
+   memset(, 0, sizeof(obj));
+   obj.handle = gem_create(fd, 4096);
+
+   obj.relocs_ptr = to_user_pointer();
+   obj.relocation_count = 1;
+   memset(, 0, sizeof(reloc));
+
+   batch = gem_mmap__wc(fd, obj.handle, 0, 4096, PROT_WRITE);
+   gem_set_domain(fd, obj.handle,
+  I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+
+   reloc.target_handle = obj.handle; /* recurse */
+   reloc.presumed_offset = 0;
+   reloc.offset = sizeof(uint32_t);
+   reloc.delta = 0;
+   reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
+   reloc.write_domain = 0;
+
+   i = 0;
+   batch[i] = MI_BATCH_BUFFER_START;
+   if (gen >= 8) {
+   batch[i] |= 1 << 8 | 1;
+   batch[++i] = 0;
+   batch[++i] = 0;
+   } else if (gen >= 6) {
+   batch[i] |= 1 << 8;
+   batch[++i] = 0;
+   } else {
+   batch[i] |= 2 << 6;
+   batch[++i] = 0;
+   if (gen < 4) {
+   batch[i] |= 1;
+   reloc.delta = 1;
+   }
+   }
+   i++;
+
+   all = -1;
+   for_each_engine(fd, engine) {
+   int fence, new;
+
+   execbuf.flags = engine | LOCAL_EXEC_FENCE_OUT;
+   execbuf.rsvd2 = -1;
+   gem_execbuf_wr(fd, );
+   fence = execbuf.rsvd2 >> 32;
+   igt_assert(fence != -1);
+
+   if (all < 0) {
+   all = fence;
+   break;
+   }
+
+   new = sync_fence_merge(all, fence);
+   igt_assert_lte(0, new);
+   close(all);
+   close(fence);
+
+   all = new;
+   }
+
+   igt_assert(gem_bo_busy(fd, obj.handle));
+   igt_assert(fence_busy(all));
+
+   timeout = 120;
+   if ((flags & HANG) == 0) {
+   *batch = MI_BATCH_BUFFER_END;
+   __sync_synchronize();
+   timeout = 1;
+   }
+   munmap(batch, 4096);
+
+   if (flags & WAIT) {
+   struct pollfd pfd = { .fd = all, .events = POLLIN };
+   igt_assert(poll(, 1, timeout*1000) == 1);
+   } else {
+   memset(, 0, sizeof(tv));
+   while (fence_busy(all))
+   igt_assert(igt_seconds_elapsed() < timeout);
+   }
+
+   igt_assert(!gem_bo_busy(fd, obj.handle));
+   igt_assert_eq(sync_fence_status(all),
+ flags & HANG ? -EIO : SYNC_FENCE_OK);
+
+   close(all);
+   gem_close(fd, obj.handle);
+
+   gem_quiescent_gpu(fd);
+}
+
 static void test_fence_await(int fd, unsigned ring, unsigned flags)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
@@ -1465,6 +1572,26 @@ igt_main
gem_submission_print_method(i915);
}
 
+   igt_subtest_group {
+   igt_fixture {
+   igt_fork_hang_detector(i915);
+   }
+
+   igt_subtest("basic-busy-all")
+   test_fence_busy_all(i915, 0);
+   igt_subtest("basic-wait-all")
+   test_fence_busy_all(i915, WAIT);
+
+   igt_fixture {
+   igt_stop_hang_detector();
+   }
+
+   igt_subtest("busy-hang-all")
+   test_fence_busy_all(i915, HANG);
+   igt_subtest("wait-hang-all")
+   test_fence_busy_all(i915, WAIT | HANG);
+   }
+
for (e = intel_execution_engines; e->name; e++) {
igt_subtest_group {
igt_fixture {
-- 
2.16.2

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

[Intel-gfx] [PATCH igt 3/5] igt/gem_ctx_switch: Exercise all engines at once

[Chris Wilson]

Just a small variant to apply a continuous context-switch load to all
engines.
---
 tests/gem_ctx_switch.c | 83 ++
 1 file changed, 83 insertions(+)

diff --git a/tests/gem_ctx_switch.c b/tests/gem_ctx_switch.c
index 79b1d74b..4c7c5391 100644
--- a/tests/gem_ctx_switch.c
+++ b/tests/gem_ctx_switch.c
@@ -133,6 +133,84 @@ static void single(int fd, uint32_t handle,
gem_context_destroy(fd, contexts[n]);
 }
 
+static void all(int fd, uint32_t handle, unsigned flags, int timeout)
+{
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 obj[2];
+   unsigned int engine[16], e;
+   const char *name[16];
+   uint32_t contexts[65];
+   unsigned int nengine;
+   int n;
+
+   nengine = 0;
+   for_each_engine(fd, e) {
+   if (e == 0 || e == I915_EXEC_BSD)
+   continue;
+
+   engine[nengine] = e;
+   name[nengine] = e__->name;
+   nengine++;
+   }
+   igt_require(nengine);
+
+   igt_require(__gem_context_create(fd, [0]) == 0);
+   for (n = 1; n < ARRAY_SIZE(contexts); n++)
+   contexts[n] = gem_context_create(fd);
+
+   memset(obj, 0, sizeof(obj));
+   obj[1].handle = handle;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer(obj + 1);
+   execbuf.buffer_count = 1;
+   execbuf.rsvd1 = contexts[0];
+   execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
+   execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
+   igt_require(__gem_execbuf(fd, ) == 0);
+   gem_sync(fd, handle);
+   execbuf.buffers_ptr = to_user_pointer(obj);
+   execbuf.buffer_count = 2;
+
+   for (int pot = 2; pot <= 64; pot *= 2) {
+   for (int nctx = pot - 1; nctx <= pot + 1; nctx++) {
+   igt_fork(child, nengine) {
+   struct timespec start, now;
+   unsigned int count = 0;
+
+   obj[0].handle = gem_create(fd, 4096);
+   execbuf.flags |= engine[child];
+   for (int loop = 0; loop < ARRAY_SIZE(contexts); 
loop++) {
+   execbuf.rsvd1 = contexts[loop];
+   gem_execbuf(fd, );
+   }
+   gem_sync(fd, obj[0].handle);
+
+   clock_gettime(CLOCK_MONOTONIC, );
+   do {
+   for (int loop = 0; loop < 1024; loop++) 
{
+   execbuf.rsvd1 = contexts[loop % 
nctx];
+   gem_execbuf(fd, );
+   }
+   count += 1024;
+   clock_gettime(CLOCK_MONOTONIC, );
+   } while (elapsed(, ) < timeout);
+   gem_sync(fd, obj[0].handle);
+   clock_gettime(CLOCK_MONOTONIC, );
+   gem_close(fd, obj[0].handle);
+
+   igt_info("[%d:%d] %s: %'u cycles: %.3fus%s\n",
+nctx, child, name[child], count, 
elapsed(, )*1e6 / count,
+flags & INTERRUPTIBLE ? " 
(interruptible)" : "");
+   }
+   igt_waitchildren();
+   }
+   }
+
+   for (n = 0; n < ARRAY_SIZE(contexts); n++)
+   gem_context_destroy(fd, contexts[n]);
+}
+
 igt_main
 {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -175,6 +253,11 @@ igt_main
single(fd, light, e, INTERRUPTIBLE, ncpus, 150);
}
 
+   igt_subtest("basic-all")
+   all(fd, light, 0, 5);
+   igt_subtest("basic-all-heavy")
+   all(fd, heavy, 0, 20);
+
igt_fixture {
igt_stop_hang_detector();
gem_close(fd, heavy);
-- 
2.16.2

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

[Intel-gfx] [PATCH igt 1/5] lib/dummyload: Avoid assertions in lowlevel spin constructor

[Chris Wilson]

__igt_spin_batch_new() may be used inside a background helper which is
competing against the GPU being reset. As such, we cannot even assert
that the spin->handle is busy immediately after submission as it may
have already been reset by another client writing to i915_wedged.

Signed-off-by: Chris Wilson 
---
 lib/igt_dummyload.c | 17 ++---
 tests/pm_rps.c  |  4 +++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index ddd43451..4b20f23d 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -207,7 +208,6 @@ ___igt_spin_batch_new(int fd, uint32_t ctx, unsigned 
engine, uint32_t dep,
 
spin->out_fence = emit_recursive_batch(spin, fd, ctx, engine, dep,
   out_fence);
-   igt_assert(gem_bo_busy(fd, spin->handle));
 
pthread_mutex_lock(_lock);
igt_list_add(>link, _list);
@@ -240,9 +240,14 @@ __igt_spin_batch_new(int fd, uint32_t ctx, unsigned 
engine, uint32_t dep)
 igt_spin_t *
 igt_spin_batch_new(int fd, uint32_t ctx, unsigned engine, uint32_t dep)
 {
+   igt_spin_t *spin;
+
igt_require_gem(fd);
 
-   return __igt_spin_batch_new(fd, ctx, engine, dep);
+   spin = __igt_spin_batch_new(fd, ctx, engine, dep);
+   igt_assert(gem_bo_busy(fd, spin->handle));
+
+   return spin;
 }
 
 igt_spin_t *
@@ -269,10 +274,16 @@ __igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned 
engine)
 igt_spin_t *
 igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned engine)
 {
+   igt_spin_t *spin;
+
igt_require_gem(fd);
igt_require(gem_has_exec_fence(fd));
 
-   return __igt_spin_batch_new_fence(fd, ctx, engine);
+   spin = __igt_spin_batch_new_fence(fd, ctx, engine);
+   igt_assert(gem_bo_busy(fd, spin->handle));
+   igt_assert(poll(&(struct pollfd){spin->out_fence, POLLIN}, 1, 0) == 0);
+
+   return spin;
 }
 
 static void notify(union sigval arg)
diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index f71976ed..006d084b 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -221,6 +221,8 @@ static void load_helper_run(enum load load)
return;
}
 
+   igt_require_gem(drm_fd);
+
lh.exit = false;
lh.load = load;
 
@@ -233,7 +235,7 @@ static void load_helper_run(enum load load)
 
igt_debug("Applying %s load...\n", lh.load ? "high" : "low");
 
-   spin[0] = igt_spin_batch_new(drm_fd, 0, 0, 0);
+   spin[0] = __igt_spin_batch_new(drm_fd, 0, 0, 0);
if (lh.load == HIGH)
spin[1] = __igt_spin_batch_new(drm_fd, 0, 0, 0);
while (!lh.exit) {
-- 
2.16.2

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

[Intel-gfx] [PATCH igt 2/5] igt/gem_spin_batch: Avoid waiting when running concurrently

[Chris Wilson]

If we do a global wait while trying to execute spinners in parallel,
it ends badly with a GPU hang.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104352
Signed-off-by: Chris Wilson 
---
 tests/gem_spin_batch.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/tests/gem_spin_batch.c b/tests/gem_spin_batch.c
index 026f9830..cffeb6d7 100644
--- a/tests/gem_spin_batch.c
+++ b/tests/gem_spin_batch.c
@@ -41,7 +41,7 @@ static void spin(int fd, unsigned int engine, unsigned int 
timeout_sec)
struct timespec itv = { };
uint64_t elapsed;
 
-   spin = igt_spin_batch_new(fd, 0, engine, 0);
+   spin = __igt_spin_batch_new(fd, 0, engine, 0);
while ((elapsed = igt_nsec_elapsed()) >> 30 < timeout_sec) {
igt_spin_t *next = __igt_spin_batch_new(fd, 0, engine, 0);
 
@@ -64,7 +64,6 @@ static void spin(int fd, unsigned int engine, unsigned int 
timeout_sec)
 loops, (long long)elapsed, (long)(elapsed / timeout_100ms));
 
assert_within_epsilon(timeout_100ms * loops, elapsed, MAX_ERROR);
-   igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
 }
 
 static void spin_exit_handler(int sig)
@@ -101,15 +100,18 @@ igt_main
}
 
for (e = intel_execution_engines; e->name; e++) {
-   if (e->exec_id == 0)
-   continue;
-
-   igt_subtest_f("basic-%s", e->name)
+   igt_subtest_f("basic-%s", e->name) {
+   intel_detect_and_clear_missed_interrupts(fd);
spin(fd, e->exec_id, 3);
+   
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+   }
}
 
-   igt_subtest("spin-each")
+   igt_subtest("spin-each") {
+   intel_detect_and_clear_missed_interrupts(fd);
spin_on_all_engines(fd, 3);
+   igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+   }
 
igt_fixture {
igt_stop_hang_detector();
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH 06/43] misc/mei/hdcp: Add KBuild for mei hdcp driver

[Ramalingam C]

On Wednesday 14 February 2018 08:24 PM, Winkler, Tomas wrote:

Signed-off-by: Ramalingam C 
---
  drivers/misc/mei/Kconfig  | 6 ++
  drivers/misc/mei/Makefile | 2 ++
  2 files changed, 8 insertions(+)

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index
c49e1d2269af..90977132d1e2 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -43,3 +43,9 @@ config INTEL_MEI_TXE

  Supported SoCs:
  Intel Bay Trail
+
+config INTEL_MEI_HDCP
+   tristate "Intel HDCP2.2 services of ME Interface"
+   depends on INTEL_MEI && DRM_I915
+   help
+ MEI Support for HDCP2.2 Services on Intel SoCs.
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile index
cd6825afa8e1..ee19754c1aec 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -23,3 +23,5 @@ mei-txe-objs += hw-txe.o

  mei-$(CONFIG_EVENT_TRACING) += mei-trace.o  CFLAGS_mei-trace.o = -
I$(src)
+
+obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o

Should go to the separate directory.

Instead of dedicated makefile for a single file, can I do something like

+obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/mei_hdcp.o

--Ram


Thanks
Tomas



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

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

[Gustavo Padovan]

Hi Dave,

A few more fixes for 4.16, including 2 regression fixes. Please pull.

Thanks,

Gustavo

drm-misc-fixes-2018-02-28:
Two regression fixes here: a fb format regression on nouveau and a 4.16-rc1
regression with on LVDS with one sun4i device. Plus a sun4i and  a virtio-gpu
fixes.
The following changes since commit dfe8db22372873d205c78a9fd5370b1b088a2b87:

  Merge tag 'drm-misc-fixes-2018-02-21' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-02-22 08:39:26 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/drm-misc tags/drm-misc-fixes-2018-02-28

for you to fetch changes up to 9a191b114906457c4b2494c474f58ae4142d4e67:

  virtio-gpu: fix ioctl and expose the fixed status to userspace. (2018-02-27 
08:37:58 +0100)


Two regression fixes here: a fb format regression on nouveau and a 4.16-rc1
regression with on LVDS with one sun4i device. Plus a sun4i and  a virtio-gpu
fixes.


Dave Airlie (1):
  virtio-gpu: fix ioctl and expose the fixed status to userspace.

Ilia Mirkin (1):
  drm/nouveau: prefer XBGR2101010 for addfb ioctl

Maxime Ripard (1):
  drm/sun4i: Protect the TCON pixel clocks

Ondrej Jirman (1):
  drm/sun4i: Enable the output on the pins (tcon0)

 drivers/gpu/drm/drm_framebuffer.c  |  4 
 drivers/gpu/drm/nouveau/nv50_display.c |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  7 +--
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 17 +++--
 include/drm/drm_drv.h  |  1 +
 include/uapi/drm/virtgpu_drm.h |  1 +
 6 files changed, 23 insertions(+), 8 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset

[Imre Deak]

Enabling FBC on a plane having a Y-offset that isn't dividable by 4 may
cause pipe FIFO underruns and flickers, so disable FBC on such a config.

I tried to the followings to work around the issue:
- enable each HW work around in ILK_DPFC_CHICKEN
- disable each compression algorithm in ILK_DPFC_CONTROL
- disable low-power watermarks
None of the above got rid of the problem. I haven't found this issue in
the Bspec/WA database either.

Besides the igt testcase below (yet to be merged) an easy way to
reproduce the issue is to enable a plane with FBC and a plane Y-offset
not aligned to 4 and then just enable/disable FBC in a loop, keeping the
plane enabled.

I could trigger the problem on BXT/GLK/SKL, so assume for now that it's
only present on GEN9.

Cc: Paulo Zanoni 
Cc: Ville Syrjälä 
Testcase: igt/kms_plane/plane-clipping-pipe-A-planes
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_fbc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 38b036c499d9..224c6a795f70 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -859,6 +859,17 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
 
+   /*
+* Work around a problem on GEN9 HW, where enabling FBC on a plane
+* having a Y offset that isn't dividable by 4 causes FIFO underrun
+* and screen ficker.
+*/
+   if (INTEL_GEN(dev_priv) == 9 &&
+   (fbc->state_cache.plane.adjusted_y & 3)) {
+   fbc->no_fbc_reason = "plane Y offset is misaligned";
+   return false;
+   }
+
return true;
 }
 
-- 
2.13.2

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

[Intel-gfx] [PATCH i-g-t v2] lib/igt_pm: Restore runtime pm state on test exit

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some tests (the ones which call igt_setup_runtime_pm and
igt_pm_enable_audio_runtime_pm) change default system configuration and
never restore it.

The configured runtime suspend is aggressive and may influence behaviour
of subsequent tests, so it is better to restore to previous values on test
exit.

This way system behaviour, with regards to a random sequence of executed
tests, will be more consistent from one run to another.

v2: Read failure means no runtime pm support so don't assert on it.

Signed-off-by: Tvrtko Ursulin 
Cc: Imre Deak 
Reviewed-by: Chris Wilson  # v1
---
 lib/igt_pm.c | 122 ---
 1 file changed, 117 insertions(+), 5 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 5bf5b2e23cdc..04e2b89cca95 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -63,6 +63,46 @@ enum {
 /* Remember to fix this if adding longer strings */
 #define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
 
+static char __igt_pm_audio_runtime_power_save[64];
+static char __igt_pm_audio_runtime_control[64];
+
+static void __igt_pm_audio_runtime_exit_handler(int sig)
+{
+   int fd;
+
+   igt_debug("Restoring audio power management to '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
+   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+   if (fd < 0)
+   return;
+   if (write(fd, __igt_pm_audio_runtime_power_save,
+ strlen(__igt_pm_audio_runtime_power_save)) !=
+   strlen(__igt_pm_audio_runtime_power_save))
+   igt_warn("Failed to restore audio power_save to '%s'\n",
+__igt_pm_audio_runtime_power_save);
+   close(fd);
+
+   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   if (fd < 0)
+   return;
+   if (write(fd, __igt_pm_audio_runtime_control,
+ strlen(__igt_pm_audio_runtime_control)) !=
+   strlen(__igt_pm_audio_runtime_control))
+   igt_warn("Failed to restore audio control to '%s'\n",
+__igt_pm_audio_runtime_control);
+   close(fd);
+}
+
+static void strchomp(char *str)
+{
+   int len = strlen(str);
+
+   if (len && str[len - 1] == '\n')
+   str[len - 1] = 0;
+}
+
 /**
  * igt_pm_enable_audio_runtime_pm:
  *
@@ -78,16 +118,32 @@ void igt_pm_enable_audio_runtime_pm(void)
 {
int fd;
 
-   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+   /* Check if already enabled. */
+   if (__igt_pm_audio_runtime_power_save[0])
+   return;
+
+   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
if (fd >= 0) {
+   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+   strchomp(__igt_pm_audio_runtime_power_save);
igt_assert_eq(write(fd, "1\n", 2), 2);
+   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
close(fd);
}
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
if (fd >= 0) {
+   igt_assert(read(fd, __igt_pm_audio_runtime_control,
+   sizeof(__igt_pm_audio_runtime_control)) > 0);
+   strchomp(__igt_pm_audio_runtime_control);
igt_assert_eq(write(fd, "auto\n", 5), 5);
close(fd);
}
+
+   igt_debug("Saved audio power management as '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
/* Give some time for it to react. */
sleep(1);
 }
@@ -238,6 +294,38 @@ void igt_pm_restore_sata_link_power_management(int8_t 
*pm_data)
 /* We just leak this on exit ... */
 int pm_status_fd = -1;
 
+static char __igt_pm_runtime_autosuspend[64];
+static char __igt_pm_runtime_control[64];
+
+static void __igt_pm_runtime_exit_handler(int sig)
+{
+   int fd;
+
+   igt_debug("Restoring runtime management to '%s' and '%s'\n",
+ __igt_pm_runtime_autosuspend,
+ __igt_pm_runtime_control);
+
+   fd = open(POWER_DIR "/autosuspend_delay_ms", O_WRONLY);
+   if (fd < 0)
+   return;
+   if (write(fd, __igt_pm_runtime_autosuspend,
+ strlen(__igt_pm_runtime_autosuspend)) !=
+   strlen(__igt_pm_runtime_autosuspend))
+   igt_warn("Failed to restore runtime pm autosuspend delay to 
'%s'\n",
+__igt_pm_runtime_autosuspend);
+   close(fd);
+
+   fd = open(POWER_DIR "/control", 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: fix perf stream opening lock

[Patchwork]

== Series Details ==

Series: drm/i915/perf: fix perf stream opening lock
URL   : https://patchwork.freedesktop.org/series/39112/
State : success

== Summary ==

 Possible new issues:

Test kms_rotation_crc:
Subgroup primary-rotation-270:
fail   -> PASS   (shard-apl)

 Known issues:

Test gem_softpin:
Subgroup noreloc-s3:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#103928
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test perf:
Subgroup oa-exponents:
incomplete -> PASS   (shard-apl) fdo#102254
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test perf_pmu:
Subgroup busy-start-vcs0:
pass   -> FAIL   (shard-snb) fdo#105106

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#105106 https://bugs.freedesktop.org/show_bug.cgi?id=105106

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:7   skip:1632 
time:12215s
shard-hswtotal:3460 pass:1765 dwarn:1   dfail:0   fail:3   skip:1690 
time:11640s
shard-snbtotal:3460 pass:1357 dwarn:1   dfail:0   fail:3   skip:2099 
time:6604s
Blacklisted hosts:
shard-kbltotal:3452 pass:1939 dwarn:1   dfail:0   fail:7   skip:1504 
time:9341s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8186/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: Don't deref request->ctx inside unlocked print_request()

[Patchwork]

== Series Details ==

Series: drm/i915: Don't deref request->ctx inside unlocked print_request()
URL   : https://patchwork.freedesktop.org/series/39098/
State : success

== Summary ==

 Possible new issues:

Test kms_rotation_crc:
Subgroup primary-rotation-270:
fail   -> PASS   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test gem_softpin:
Subgroup noreloc-s3:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup flip-vs-modeset-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> SKIP   (shard-snb) fdo#103375
Test perf:
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Subgroup oa-exponents:
incomplete -> PASS   (shard-apl) fdo#102254
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3531 pass:1860 dwarn:1   dfail:0   fail:9   skip:1659 
time:12200s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11716s
shard-snbtotal:3460 pass:1354 dwarn:4   dfail:0   fail:2   skip:2100 
time:6599s
Blacklisted hosts:
shard-kbltotal:3375 pass:1877 dwarn:18  dfail:2   fail:6   skip:1470 
time:8954s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_pm: Restore runtime pm state on test exit

[Tvrtko Ursulin]

On 28/02/2018 12:27, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-02-28 11:38:01)


On 28/02/2018 11:12, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-02-28 11:08:29)

From: Tvrtko Ursulin 

Some tests (the ones which call igt_setup_runtime_pm and
igt_pm_enable_audio_runtime_pm) change default system configuration and
never restore it.

The configured runtime suspend is aggressive and may influence behaviour
of subsequent tests, so it is better to restore to previous values on test
exit.

This way system behaviour, with regards to a random sequence of executed
tests, will be more consistent from one run to another.


Otoh, if behaviour changes in subsequent tests, we likely have a lack of
testing :(


Yeah, and I am not saying it does - haven't spotted anything like that,
just that it leaves the auto-suspend with zero delay afterwards,
compared to otherwise default 10s.

Maybe it is good for coverage, even with the downside of randomness
considering shard runs, or maybe it needs to be more explicit.


I actually thought (or at least picked up the idea) we enabled 0
autosuspend delay throughout igt. And that it's only because most of time
we have a display connected that prevents rpm madness.


Yes fair point, the effect of this patch is only visible on esoteric 
headless setups like mine. :)


Anyway, unless I am missing something, I think it is conceptually 
correct to restore, as long as the zero autosuspend delay is not a 
global IGT setup but a helper called by a few tests.


Regards,

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

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_pm: Restore runtime pm state on test exit

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-28 11:08:29)
> From: Tvrtko Ursulin 
> 
> Some tests (the ones which call igt_setup_runtime_pm and
> igt_pm_enable_audio_runtime_pm) change default system configuration and
> never restore it.
> 
> The configured runtime suspend is aggressive and may influence behaviour
> of subsequent tests, so it is better to restore to previous values on test
> exit.
> 
> This way system behaviour, with regards to a random sequence of executed
> tests, will be more consistent from one run to another.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Imre Deak 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

[Chris Wilson]

Quoting Mika Kuoppala (2018-02-28 12:49:00)
> Chris Wilson  writes:
> 
> > Although we protect the request itself, we don't lock inside
> > intel_engine_dump() and so the request maybe retired as we peek into it.
> > One consequence is that the request->ctx may be freed before we
> > dereference it, leading to a use-after-free. Replace the hw_id we are
> > peeking from inside request->ctx with the request->fence.context, with
> > which we can still track from which context the request originated
> > (although to tie to HW reports requires a little more legwork, but is
> > good enough to follow the GEM traces).
> >
> > [52640.729670] general protection fault:  [#2] SMP
> > [52640.729694] Dumping ftrace buffer:
> > [52640.729701](ftrace buffer empty)
> > [52640.729705] Modules linked in: vgem snd_hda_codec_hdmi 
> > snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_\
> > temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
> > snd_hda_intel snd_hda_codec snd_hwdep gha\
> > sh_clmulni_intel snd_hda_core snd_pcm mei_me mei i915 r8169 mii 
> > prime_numbers i2c_hid
> > [52640.729748] CPU: 2 PID: 4335 Comm: gem_exec_schedu Tainted: G UD W   
> >  4.16.0-rc3+ #7
> > [52640.729759] Hardware name: Acer Aspire E5-575G/Ironman_SK  , BIOS V1.12 
> > 08/02/2016
> > [52640.729803] RIP: 0010:print_request+0x2b/0xb0 [i915]
> > [52640.729811] RSP: 0018:c90001453c18 EFLAGS: 00010206
> > [52640.729820] RAX: 6b6b6b6b6b6b6b6b RBX: 8801e0292d40 RCX: 
> > 0006
> > [52640.729829] RDX: c90001453c60 RSI: 8801e0292d40 RDI: 
> > 0003
> > [52640.729838] RBP: c90001453d80 R08:  R09: 
> > 0001
> > [52640.729847] R10: c90001453bd0 R11: c90001453c73 R12: 
> > c90001453c60
> > [52640.729856] R13: c90001453d80 R14: 8801d5a683c8 R15: 
> > 8801e0292d40
> > [52640.729866] FS:  7f1ee50548c0() GS:8801e820() 
> > knlGS:
> > [52640.729876] CS:  0010 DS:  ES:  CR0: 80050033
> > [52640.729884] CR2: 7f1ee5077000 CR3: 0001d9411004 CR4: 
> > 003606e0
> > [52640.729893] Call Trace:
> > [52640.729922]  intel_engine_print_registers+0x623/0x890 [i915]
> > [52640.729948]  intel_engine_dump+0x4a3/0x590 [i915]
> > [52640.729957]  ? seq_printf+0x3a/0x50
> > [52640.729977]  i915_engine_info+0xb8/0xe0 [i915]
> > [52640.729984]  ? drm_mode_gamma_get_ioctl+0xf0/0xf0
> > [52640.729990]  seq_read+0xd5/0x410
> > [52640.729997]  full_proxy_read+0x4b/0x70
> > [52640.730004]  __vfs_read+0x1e/0x120
> > [52640.730009]  ? do_sys_open+0x134/0x220
> > [52640.730015]  ? kmem_cache_free+0x174/0x2b0
> > [52640.730021]  vfs_read+0xa1/0x150
> > [52640.730026]  SyS_read+0x40/0xa0
> > [52640.730032]  do_syscall_64+0x65/0x1a0
> > [52640.730038]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> >
> > Reported-by: Mika Kuoppala 
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> 
> I found how to associate hw_id with fence.context on trace,
> so lets fix this race.
> 
> Reviewed-by: Mika Kuoppala 

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Don't mangle the CTM on pre-HSW

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 01:11:12PM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Friday, February 23, 2018 7:23 PM
> >To: Shankar, Uma 
> >Cc: intel-gfx@lists.freedesktop.org; Lin, Johnson ;
> >Sharma, Shashank 
> >Subject: Re: [PATCH 4/4] drm/i915: Don't mangle the CTM on pre-HSW
> >
> >On Fri, Feb 23, 2018 at 01:33:42PM +, Shankar, Uma wrote:
> >>
> >>
> >> >-Original Message-
> >> >From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> >> >Sent: Friday, February 23, 2018 3:13 AM
> >> >To: intel-gfx@lists.freedesktop.org
> >> >Cc: Lin, Johnson ; Shankar, Uma
> >> >; Sharma, Shashank 
> >> >Subject: [PATCH 4/4] drm/i915: Don't mangle the CTM on pre-HSW
> >> >
> >> >From: Ville Syrjälä 
> >> >
> >> >On pre-HSW we have dedicated hardware for the RGB limited range
> >> >handling, and so we don't want to compress with the CSC matrix.
> >> >
> >> >Toss in a FIXME about gamma LUT vs. limited range using the CSC.
> >> >
> >> >Cc: Johnson Lin 
> >> >Cc: Uma Shankar 
> >> >Cc: Shashank Sharma 
> >> >Signed-off-by: Ville Syrjälä 
> >> >---
> >> > drivers/gpu/drm/i915/intel_color.c | 16 
> >> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >> >
> >> >diff --git a/drivers/gpu/drm/i915/intel_color.c
> >> >b/drivers/gpu/drm/i915/intel_color.c
> >> >index af1e61d3bacd..89ab0f70aa22 100644
> >> >--- a/drivers/gpu/drm/i915/intel_color.c
> >> >+++ b/drivers/gpu/drm/i915/intel_color.c
> >> >@@ -140,6 +140,14 @@ static void ilk_load_csc_matrix(struct
> >> >drm_crtc_state
> >> >*crtc_state)
> >> >  int i, pipe = intel_crtc->pipe;
> >> >  uint16_t coeffs[9] = { 0, };
> >> >  struct intel_crtc_state *intel_crtc_state =
> >> >to_intel_crtc_state(crtc_state);
> >> >+ bool limited_color_range = false;
> >> >+
> >> >+ /*
> >> >+  * FIXME if there's a gamma LUT after the CSC, we should
> >> >+  * do the range compression using the gamma LUT instead.
> >> >+  */
> >> >+ if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
> >> >+ limited_color_range = intel_crtc_state->limited_color_range;
> >> >
> >>
> >> Hi Ville,
> >> For VLV or similar platforms (having dedicated color range h/w) for
> >> limited_range this matrix would have been getting used. Though they
> >> have a dedicated h/w but I don't think it's getting programmed
> >> currently. Not sure, with removing this CSC scaling logic, it may
> >> break the limited_color scenarios on those platforms. I believe using
> >> the dedicated h/w or this scaled_down CSC should be giving similar
> >> results making the things work currently. Not sure if we are using any
> >> limited_range combinations on those platforms though :)
> >
> >All pre-HSW platforms that have the pipe CSC (ILK,SNB,IVB) are using the
> >dedicated hardware for the limited range RGB output. We don't use the CSC on
> >those platforms for anything at the moment so it doesn't actually matter what
> >we program into it. But we want to start using the CSC for ctm and ycbcr444
> >output which means we have to start setting it up correctly.
> >
> 
> Sounds good. 
> Reviewed-by: Uma Shankar 

Thanks. Pushed to dinq.

-- 
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/4] drm/i915: Don't mangle the CTM on pre-HSW

[Shankar, Uma]

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, February 23, 2018 7:23 PM
>To: Shankar, Uma 
>Cc: intel-gfx@lists.freedesktop.org; Lin, Johnson ;
>Sharma, Shashank 
>Subject: Re: [PATCH 4/4] drm/i915: Don't mangle the CTM on pre-HSW
>
>On Fri, Feb 23, 2018 at 01:33:42PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Friday, February 23, 2018 3:13 AM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: Lin, Johnson ; Shankar, Uma
>> >; Sharma, Shashank 
>> >Subject: [PATCH 4/4] drm/i915: Don't mangle the CTM on pre-HSW
>> >
>> >From: Ville Syrjälä 
>> >
>> >On pre-HSW we have dedicated hardware for the RGB limited range
>> >handling, and so we don't want to compress with the CSC matrix.
>> >
>> >Toss in a FIXME about gamma LUT vs. limited range using the CSC.
>> >
>> >Cc: Johnson Lin 
>> >Cc: Uma Shankar 
>> >Cc: Shashank Sharma 
>> >Signed-off-by: Ville Syrjälä 
>> >---
>> > drivers/gpu/drm/i915/intel_color.c | 16 
>> > 1 file changed, 12 insertions(+), 4 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/intel_color.c
>> >b/drivers/gpu/drm/i915/intel_color.c
>> >index af1e61d3bacd..89ab0f70aa22 100644
>> >--- a/drivers/gpu/drm/i915/intel_color.c
>> >+++ b/drivers/gpu/drm/i915/intel_color.c
>> >@@ -140,6 +140,14 @@ static void ilk_load_csc_matrix(struct
>> >drm_crtc_state
>> >*crtc_state)
>> >int i, pipe = intel_crtc->pipe;
>> >uint16_t coeffs[9] = { 0, };
>> >struct intel_crtc_state *intel_crtc_state =
>> >to_intel_crtc_state(crtc_state);
>> >+   bool limited_color_range = false;
>> >+
>> >+   /*
>> >+* FIXME if there's a gamma LUT after the CSC, we should
>> >+* do the range compression using the gamma LUT instead.
>> >+*/
>> >+   if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
>> >+   limited_color_range = intel_crtc_state->limited_color_range;
>> >
>>
>> Hi Ville,
>> For VLV or similar platforms (having dedicated color range h/w) for
>> limited_range this matrix would have been getting used. Though they
>> have a dedicated h/w but I don't think it's getting programmed
>> currently. Not sure, with removing this CSC scaling logic, it may
>> break the limited_color scenarios on those platforms. I believe using
>> the dedicated h/w or this scaled_down CSC should be giving similar
>> results making the things work currently. Not sure if we are using any
>> limited_range combinations on those platforms though :)
>
>All pre-HSW platforms that have the pipe CSC (ILK,SNB,IVB) are using the
>dedicated hardware for the limited range RGB output. We don't use the CSC on
>those platforms for anything at the moment so it doesn't actually matter what
>we program into it. But we want to start using the CSC for ctm and ycbcr444
>output which means we have to start setting it up correctly.
>

Sounds good. 
Reviewed-by: Uma Shankar 

>>
>> Regards,
>> Uma Shankar
>>
>> >if (intel_crtc_state->ycbcr420) {
>> >ilk_load_ycbcr_conversion_matrix(intel_crtc);
>> >@@ -150,7 +158,7 @@ static void ilk_load_csc_matrix(struct
>> >drm_crtc_state
>> >*crtc_state)
>> >const u64 *input;
>> >u64 temp[9];
>> >
>> >-   if (intel_crtc_state->limited_color_range)
>> >+   if (limited_color_range)
>> >input = ctm_mult_by_limited(temp, ctm->matrix);
>> >else
>> >input = ctm->matrix;
>> >@@ -200,7 +208,7 @@ static void ilk_load_csc_matrix(struct
>> >drm_crtc_state
>> >*crtc_state)
>> > * into consideration.
>> > */
>> >for (i = 0; i < 3; i++) {
>> >-   if (intel_crtc_state->limited_color_range)
>> >+   if (limited_color_range)
>> >coeffs[i * 3 + i] =
>> >ILK_CSC_COEFF_LIMITED_RANGE;
>> >else
>> >@@ -224,7 +232,7 @@ static void ilk_load_csc_matrix(struct
>> >drm_crtc_state
>> >*crtc_state)
>> >if (INTEL_GEN(dev_priv) > 6) {
>> >uint16_t postoff = 0;
>> >
>> >-   if (intel_crtc_state->limited_color_range)
>> >+   if (limited_color_range)
>> >postoff = (16 * (1 << 12) / 255) & 0x1fff;
>> >
>> >I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), postoff); @@ -235,7
>> >+243,7 @@ static void ilk_load_csc_matrix(struct drm_crtc_state
>> >+*crtc_state)
>> >} else {
>> >uint32_t mode = CSC_MODE_YUV_TO_RGB;
>> >
>> >-   if (intel_crtc_state->limited_color_range)
>> >+   if (limited_color_range)
>> >mode 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915/icl: Prepare for more rings

[Mika Kuoppala]

Patchwork  writes:

> == Series Details ==
>
> Series: series starting with [CI,1/2] drm/i915/icl: Prepare for more rings
> URL   : https://patchwork.freedesktop.org/series/39102/
> State : warning
>
> == Summary ==
>
> Series 39102v1 series starting with [CI,1/2] drm/i915/icl: Prepare for more 
> rings
> https://patchwork.freedesktop.org/api/1.0/series/39102/revisions/1/mbox/
>
>  Possible new issues:
>
> Test drv_module_reload:
> Subgroup basic-no-display:
> pass   -> DMESG-WARN (fi-cfl-8700k)

https://bugs.freedesktop.org/show_bug.cgi?id=91883
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Rename pipe CSC to use ilk_ prefix

[Ville Syrjälä]

On Fri, Feb 23, 2018 at 01:05:25PM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> >Sent: Friday, February 23, 2018 3:13 AM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Lin, Johnson ; Shankar, Uma
> >; Sharma, Shashank 
> >Subject: [PATCH 3/4] drm/i915: Rename pipe CSC to use ilk_ prefix
> >
> >From: Ville Syrjälä 
> >
> >The pipe CSC was introduced by ILK, so change everything related to use ilk_ 
> >as
> >the prefix.
> >
> 
> Looks ok to me.
> Reviewed-by: Uma Shankar 

Patches 2 and 3 pushed to dinq. Thanks for the review.

Patch 4 still needs an r-b...

> 
> >Cc: Johnson Lin 
> >Cc: Uma Shankar 
> >Cc: Shashank Sharma 
> >Signed-off-by: Ville Syrjälä 
> >---
> > drivers/gpu/drm/i915/intel_color.c | 39 
> > +++---
> > 1 file changed, 19 insertions(+), 20 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_color.c
> >b/drivers/gpu/drm/i915/intel_color.c
> >index c9af260be113..af1e61d3bacd 100644
> >--- a/drivers/gpu/drm/i915/intel_color.c
> >+++ b/drivers/gpu/drm/i915/intel_color.c
> >@@ -66,13 +66,13 @@
> >  * of the CTM coefficient and we write the value from bit 3. We also round 
> > the
> >  * value.
> >  */
> >-#define I9XX_CSC_COEFF_FP(coeff, fbits) \
> >+#define ILK_CSC_COEFF_FP(coeff, fbits)  \
> > (clamp_val(((coeff) >> (32 - (fbits) - 3)) + 4, 0, 0xfff) & 0xff8)
> >
> >-#define I9XX_CSC_COEFF_LIMITED_RANGE\
> >-I9XX_CSC_COEFF_FP(CTM_COEFF_LIMITED_RANGE, 9)
> >-#define I9XX_CSC_COEFF_1_0  \
> >-((7 << 12) | I9XX_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
> >+#define ILK_CSC_COEFF_LIMITED_RANGE \
> >+ILK_CSC_COEFF_FP(CTM_COEFF_LIMITED_RANGE, 9)
> >+#define ILK_CSC_COEFF_1_0   \
> >+((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
> >
> > static bool crtc_state_is_legacy_gamma(struct drm_crtc_state *state)  { @@ -
> >108,7 +108,7 @@ static u64 *ctm_mult_by_limited(u64 *result, const u64 
> >*input)
> > return result;
> > }
> >
> >-static void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
> >+static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc
> >+*intel_crtc)
> > {
> > int pipe = intel_crtc->pipe;
> > struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev); @@ -
> >132,8 +132,7 @@ static void i9xx_load_ycbcr_conversion_matrix(struct
> >intel_crtc *intel_crtc)
> > I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> > }
> >
> >-/* Set up the pipe CSC unit. */
> >-static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
> >+static void ilk_load_csc_matrix(struct drm_crtc_state *crtc_state)
> > {
> > struct drm_crtc *crtc = crtc_state->crtc;
> > struct drm_i915_private *dev_priv = to_i915(crtc->dev); @@ -143,7
> >+142,7 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
> > struct intel_crtc_state *intel_crtc_state = 
> > to_intel_crtc_state(crtc_state);
> >
> > if (intel_crtc_state->ycbcr420) {
> >-i9xx_load_ycbcr_conversion_matrix(intel_crtc);
> >+ilk_load_ycbcr_conversion_matrix(intel_crtc);
> > return;
> > } else if (crtc_state->ctm) {
> > struct drm_color_ctm *ctm =
> >@@ -175,21 +174,21 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state
> >*crtc_state)
> >
> > if (abs_coeff < CTM_COEFF_0_125)
> > coeffs[i] |= (3 << 12) |
> >-I9XX_CSC_COEFF_FP(abs_coeff, 12);
> >+ILK_CSC_COEFF_FP(abs_coeff, 12);
> > else if (abs_coeff < CTM_COEFF_0_25)
> > coeffs[i] |= (2 << 12) |
> >-I9XX_CSC_COEFF_FP(abs_coeff, 11);
> >+ILK_CSC_COEFF_FP(abs_coeff, 11);
> > else if (abs_coeff < CTM_COEFF_0_5)
> > coeffs[i] |= (1 << 12) |
> >-I9XX_CSC_COEFF_FP(abs_coeff, 10);
> >+ILK_CSC_COEFF_FP(abs_coeff, 10);
> > else if (abs_coeff < CTM_COEFF_1_0)
> >-coeffs[i] |= I9XX_CSC_COEFF_FP(abs_coeff, 9);
> >+coeffs[i] |= ILK_CSC_COEFF_FP(abs_coeff, 9);
> > else if (abs_coeff < CTM_COEFF_2_0)
> > coeffs[i] |= (7 << 12) |
> >-I9XX_CSC_COEFF_FP(abs_coeff, 8);
> >+ILK_CSC_COEFF_FP(abs_coeff, 8);
> > else
> > coeffs[i] |= (6 << 12) |
> >-I9XX_CSC_COEFF_FP(abs_coeff, 7);
> >+   

Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Ville Syrjälä]

On Fri, Feb 23, 2018 at 04:04:10PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 23, 2018 at 01:52:22PM +, Brian Starkey wrote:
> > Hi Ville,
> > 
> > On Thu, Feb 22, 2018 at 11:42:29PM +0200, Ville Syrjala wrote:
> > >From: Ville Syrjälä 
> > >
> > >The documentation for the ctm matrix suggests a two's complement
> > >format, but at least the i915 implementation is using sign-magnitude
> > >instead. And looks like malidp is doing the same. Change the docs
> > >to match the current implementation, and change the type from __s64
> > >to __u64 to drive the point home.
> > 
> > I totally agree that this is a good idea, but...
> > 
> > >
> > >Cc: dri-de...@lists.freedesktop.org
> > >Cc: Mihail Atanassov 
> > >Cc: Liviu Dudau 
> > >Cc: Brian Starkey 
> > >Cc: Mali DP Maintainers 
> > >Cc: Johnson Lin 
> > >Cc: Uma Shankar 
> > >Cc: Shashank Sharma 
> > >Signed-off-by: Ville Syrjälä 
> > >---
> > > include/uapi/drm/drm_mode.h | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > >diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > >index 2c575794fb52..b5d7d9e0eff5 100644
> > >--- a/include/uapi/drm/drm_mode.h
> > >+++ b/include/uapi/drm/drm_mode.h
> > >@@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
> > > };
> > >
> > > struct drm_color_ctm {
> > >-  /* Conversion matrix in S31.32 format. */
> > >-  __s64 matrix[9];
> > >+  /*
> > >+   * Conversion matrix in S31.32 sign-magnitude
> > >+   * (not two's complement!) format.
> > >+   */
> > >+  __u64 matrix[9];
> > 
> > Isn't changing the type liable to break something for someone?
> 
> I hope not. Renaming the member would be a no no, but just changing the
> type should be mostly safe I think. I suppose if someone is building
> something with very strict compiler -W flags and -Werror it might cause
> a build failure, so I guess one might label it as a minor api break but
> not an abi break.
> 
> If people think that's a serious concern I guess we can keep the
> __s64, but I'd rather not give people that much rope to hang
> themselves by interpreting it as 2's complement.

OK, no one complained loudly so I've gone and pushed this to
drm-misc-next. Now we wait and see whether I can dodge the egg...

-- 
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] drm/i915: Don't deref request->ctx inside unlocked print_request()

[Mika Kuoppala]

Chris Wilson  writes:

> Although we protect the request itself, we don't lock inside
> intel_engine_dump() and so the request maybe retired as we peek into it.
> One consequence is that the request->ctx may be freed before we
> dereference it, leading to a use-after-free. Replace the hw_id we are
> peeking from inside request->ctx with the request->fence.context, with
> which we can still track from which context the request originated
> (although to tie to HW reports requires a little more legwork, but is
> good enough to follow the GEM traces).
>
> [52640.729670] general protection fault:  [#2] SMP
> [52640.729694] Dumping ftrace buffer:
> [52640.729701](ftrace buffer empty)
> [52640.729705] Modules linked in: vgem snd_hda_codec_hdmi 
> snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_\
> temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
> snd_hda_intel snd_hda_codec snd_hwdep gha\
> sh_clmulni_intel snd_hda_core snd_pcm mei_me mei i915 r8169 mii prime_numbers 
> i2c_hid
> [52640.729748] CPU: 2 PID: 4335 Comm: gem_exec_schedu Tainted: G UD W 
>4.16.0-rc3+ #7
> [52640.729759] Hardware name: Acer Aspire E5-575G/Ironman_SK  , BIOS V1.12 
> 08/02/2016
> [52640.729803] RIP: 0010:print_request+0x2b/0xb0 [i915]
> [52640.729811] RSP: 0018:c90001453c18 EFLAGS: 00010206
> [52640.729820] RAX: 6b6b6b6b6b6b6b6b RBX: 8801e0292d40 RCX: 
> 0006
> [52640.729829] RDX: c90001453c60 RSI: 8801e0292d40 RDI: 
> 0003
> [52640.729838] RBP: c90001453d80 R08:  R09: 
> 0001
> [52640.729847] R10: c90001453bd0 R11: c90001453c73 R12: 
> c90001453c60
> [52640.729856] R13: c90001453d80 R14: 8801d5a683c8 R15: 
> 8801e0292d40
> [52640.729866] FS:  7f1ee50548c0() GS:8801e820() 
> knlGS:
> [52640.729876] CS:  0010 DS:  ES:  CR0: 80050033
> [52640.729884] CR2: 7f1ee5077000 CR3: 0001d9411004 CR4: 
> 003606e0
> [52640.729893] Call Trace:
> [52640.729922]  intel_engine_print_registers+0x623/0x890 [i915]
> [52640.729948]  intel_engine_dump+0x4a3/0x590 [i915]
> [52640.729957]  ? seq_printf+0x3a/0x50
> [52640.729977]  i915_engine_info+0xb8/0xe0 [i915]
> [52640.729984]  ? drm_mode_gamma_get_ioctl+0xf0/0xf0
> [52640.729990]  seq_read+0xd5/0x410
> [52640.729997]  full_proxy_read+0x4b/0x70
> [52640.730004]  __vfs_read+0x1e/0x120
> [52640.730009]  ? do_sys_open+0x134/0x220
> [52640.730015]  ? kmem_cache_free+0x174/0x2b0
> [52640.730021]  vfs_read+0xa1/0x150
> [52640.730026]  SyS_read+0x40/0xa0
> [52640.730032]  do_syscall_64+0x65/0x1a0
> [52640.730038]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
>
> Reported-by: Mika Kuoppala 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

I found how to associate hw_id with fence.context on trace,
so lets fix this race.

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

Re: [Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

[Chris Wilson]

Quoting Mika Kuoppala (2018-02-28 12:32:40)
> Chris Wilson  writes:
> 
> > Although we protect the request itself, we don't lock inside
> > intel_engine_dump() and so the request maybe retired as we peek into it.
> > One consequence is that the request->ctx may be freed before we
> > dereference it, leading to a use-after-free. Replace the hw_id we are
> > peeking from inside request->ctx with the request->fence.context, with
> > which we can still track from which context the request originated
> > (although to tie to HW reports requires a little more legwork, but is
> > good enough to follow the GEM traces).
> 
> How we do the legwork? I tried to see from the code how we
> can associate ctx hw_id with the fence.context id but failed.

It's currently inside tracepoints.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

[Mika Kuoppala]

Chris Wilson  writes:

> Although we protect the request itself, we don't lock inside
> intel_engine_dump() and so the request maybe retired as we peek into it.
> One consequence is that the request->ctx may be freed before we
> dereference it, leading to a use-after-free. Replace the hw_id we are
> peeking from inside request->ctx with the request->fence.context, with
> which we can still track from which context the request originated
> (although to tie to HW reports requires a little more legwork, but is
> good enough to follow the GEM traces).

How we do the legwork? I tried to see from the code how we
can associate ctx hw_id with the fence.context id but failed.

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

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_pm: Restore runtime pm state on test exit

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-28 11:38:01)
> 
> On 28/02/2018 11:12, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-02-28 11:08:29)
> >> From: Tvrtko Ursulin 
> >>
> >> Some tests (the ones which call igt_setup_runtime_pm and
> >> igt_pm_enable_audio_runtime_pm) change default system configuration and
> >> never restore it.
> >>
> >> The configured runtime suspend is aggressive and may influence behaviour
> >> of subsequent tests, so it is better to restore to previous values on test
> >> exit.
> >>
> >> This way system behaviour, with regards to a random sequence of executed
> >> tests, will be more consistent from one run to another.
> > 
> > Otoh, if behaviour changes in subsequent tests, we likely have a lack of
> > testing :(
> 
> Yeah, and I am not saying it does - haven't spotted anything like that, 
> just that it leaves the auto-suspend with zero delay afterwards, 
> compared to otherwise default 10s.
> 
> Maybe it is good for coverage, even with the downside of randomness 
> considering shard runs, or maybe it needs to be more explicit.

I actually thought (or at least picked up the idea) we enabled 0
autosuspend delay throughout igt. And that it's only because most of time
we have a display connected that prevents rpm madness.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt v2] tests: Add a random load generator

[Chris Wilson]

Quoting Arkadiusz Hiler (2018-02-28 12:11:41)
> On Mon, Jan 22, 2018 at 11:14:01AM +0200, Chris Wilson wrote:
> > Apply a random load to one or all engines in order to apply stress to
> > RPS as it tries to constantly adjust the GPU frequency to meet the
> > changing workload.
> 
> Doing some IGT archeology here.
> 
> Seems like both 'all' and 'pulse' subtests cause nasty incompletes.
> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_809/shards-all.html#igt@gem_exec_load@all

Not nasty, just a failure in the test runner. They are intentionally
long running tests as the problem may take days to manifest.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: fix perf stream opening lock

[Patchwork]

== Series Details ==

Series: drm/i915/perf: fix perf stream opening lock
URL   : https://patchwork.freedesktop.org/series/39112/
State : success

== Summary ==

Series 39112v1 drm/i915/perf: fix perf stream opening lock
https://patchwork.freedesktop.org/api/1.0/series/39112/revisions/1/mbox/

 Known issues:

Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> INCOMPLETE (fi-pnv-d510) fdo#101600
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:397s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:585s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:447s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-pnv-d510  total:146  pass:113  dwarn:0   dfail:0   fail:0   skip:32 
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s

9a02ae14ae024bdbb268333cddccbaf01d8f02ef drm-tip: 2018y-02m-28d-10h-13m-18s UTC 
integration manifest
7d20f8980c5b drm/i915/perf: fix perf stream opening lock

== Logs ==

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

Re: [Intel-gfx] [PATCH igt v2] tests: Add a random load generator

[Arkadiusz Hiler]

On Mon, Jan 22, 2018 at 11:14:01AM +0200, Chris Wilson wrote:
> Apply a random load to one or all engines in order to apply stress to
> RPS as it tries to constantly adjust the GPU frequency to meet the
> changing workload.

Doing some IGT archeology here.

Seems like both 'all' and 'pulse' subtests cause nasty incompletes.
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_809/shards-all.html#igt@gem_exec_load@all

What are the plans for the gem_exec_load nowadays?

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

[Intel-gfx] [PATCH] drm/i915/perf: fix perf stream opening lock

[Lionel Landwerlin]

We're seeing on CI that some contexts don't have the programmed OA
period timer that directs the OA unit on how often to write reports.

The issue is that we're not holding the drm lock from when we edit the
context images down to when we set the exclusive_stream variable. This
leaves a window for the deferred context allocation to call
i915_oa_init_reg_state() that will not program the expected OA timer
value, because we haven't set the exclusive_stream yet.

Signed-off-by: Lionel Landwerlin 
Fixes: 701f8231a2f ("drm/i915/perf: prune OA configs")
Cc:  # v4.14+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102254
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
---
 drivers/gpu/drm/i915/i915_perf.c | 41 +++-
 1 file changed, 19 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2741b1bc7095..7016abfc8ba9 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1757,21 +1757,16 @@ static int gen8_switch_to_updated_kernel_context(struct 
drm_i915_private *dev_pr
  */
 static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
   const struct i915_oa_config *oa_config,
-  bool interruptible)
+  bool need_lock)
 {
struct i915_gem_context *ctx;
int ret;
unsigned int wait_flags = I915_WAIT_LOCKED;
 
-   if (interruptible) {
-   ret = i915_mutex_lock_interruptible(_priv->drm);
-   if (ret)
-   return ret;
-
-   wait_flags |= I915_WAIT_INTERRUPTIBLE;
-   } else {
+   if (need_lock)
mutex_lock(_priv->drm.struct_mutex);
-   }
+
+   lockdep_assert_held(_priv->drm.struct_mutex);
 
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
@@ -1819,7 +1814,8 @@ static int gen8_configure_all_contexts(struct 
drm_i915_private *dev_priv,
}
 
  out:
-   mutex_unlock(_priv->drm.struct_mutex);
+   if (need_lock)
+   mutex_unlock(_priv->drm.struct_mutex);
 
return ret;
 }
@@ -1863,7 +1859,7 @@ static int gen8_enable_metric_set(struct drm_i915_private 
*dev_priv,
 * to make sure all slices/subslices are ON before writing to NOA
 * registers.
 */
-   ret = gen8_configure_all_contexts(dev_priv, oa_config, true);
+   ret = gen8_configure_all_contexts(dev_priv, oa_config, false);
if (ret)
return ret;
 
@@ -1878,7 +1874,7 @@ static int gen8_enable_metric_set(struct drm_i915_private 
*dev_priv,
 static void gen8_disable_metric_set(struct drm_i915_private *dev_priv)
 {
/* Reset all contexts' slices/subslices configurations. */
-   gen8_configure_all_contexts(dev_priv, NULL, false);
+   gen8_configure_all_contexts(dev_priv, NULL, true);
 
I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
  ~GT_NOA_ENABLE));
@@ -1888,7 +1884,7 @@ static void gen8_disable_metric_set(struct 
drm_i915_private *dev_priv)
 static void gen10_disable_metric_set(struct drm_i915_private *dev_priv)
 {
/* Reset all contexts' slices/subslices configurations. */
-   gen8_configure_all_contexts(dev_priv, NULL, false);
+   gen8_configure_all_contexts(dev_priv, NULL, true);
 
/* Make sure we disable noa to save power. */
I915_WRITE(RPM_CONFIG1,
@@ -2138,13 +2134,6 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
if (ret)
goto err_oa_buf_alloc;
 
-   ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
- stream->oa_config);
-   if (ret)
-   goto err_enable;
-
-   stream->ops = _oa_stream_ops;
-
/* Lock device for exclusive_stream access late because
 * enable_metric_set() might lock as well on gen8+.
 */
@@ -2152,16 +2141,24 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
if (ret)
goto err_lock;
 
+   ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
+ stream->oa_config);
+   if (ret)
+   goto err_enable;
+
+   stream->ops = _oa_stream_ops;
+
dev_priv->perf.oa.exclusive_stream = stream;
 
mutex_unlock(_priv->drm.struct_mutex);
 
return 0;
 
-err_lock:
+err_enable:
+   mutex_unlock(_priv->drm.struct_mutex);
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
 
-err_enable:
+err_lock:
free_oa_buffer(dev_priv);
 
 err_oa_buf_alloc:
-- 
2.16.1

___
Intel-gfx 

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_pm: Restore runtime pm state on test exit

[Tvrtko Ursulin]

On 28/02/2018 11:12, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-02-28 11:08:29)

From: Tvrtko Ursulin 

Some tests (the ones which call igt_setup_runtime_pm and
igt_pm_enable_audio_runtime_pm) change default system configuration and
never restore it.

The configured runtime suspend is aggressive and may influence behaviour
of subsequent tests, so it is better to restore to previous values on test
exit.

This way system behaviour, with regards to a random sequence of executed
tests, will be more consistent from one run to another.


Otoh, if behaviour changes in subsequent tests, we likely have a lack of
testing :(


Yeah, and I am not saying it does - haven't spotted anything like that, 
just that it leaves the auto-suspend with zero delay afterwards, 
compared to otherwise default 10s.


Maybe it is good for coverage, even with the downside of randomness 
considering shard runs, or maybe it needs to be more explicit.


Regards,

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915/icl: Prepare for more rings

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/icl: Prepare for more rings
URL   : https://patchwork.freedesktop.org/series/39102/
State : warning

== Summary ==

Series 39102v1 series starting with [CI,1/2] drm/i915/icl: Prepare for more 
rings
https://patchwork.freedesktop.org/api/1.0/series/39102/revisions/1/mbox/

 Possible new issues:

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (fi-cfl-8700k)

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-8700k total:288  pass:259  dwarn:1   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:484s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:389s

9a02ae14ae024bdbb268333cddccbaf01d8f02ef drm-tip: 2018y-02m-28d-10h-13m-18s UTC 
integration manifest
a4fe8c3a60ee drm/i915/icl: Interrupt handling
a28809c1ee8d drm/i915/icl: Prepare for more rings

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't deref request->ctx inside unlocked print_request()

[Patchwork]

== Series Details ==

Series: drm/i915: Don't deref request->ctx inside unlocked print_request()
URL   : https://patchwork.freedesktop.org/series/39098/
State : success

== Summary ==

Series 39098v1 drm/i915: Don't deref request->ctx inside unlocked 
print_request()
https://patchwork.freedesktop.org/api/1.0/series/39098/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:447s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:523s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

9a02ae14ae024bdbb268333cddccbaf01d8f02ef drm-tip: 2018y-02m-28d-10h-13m-18s UTC 
integration manifest
90da86ec774d drm/i915: Don't deref request->ctx inside unlocked print_request()

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_pm: Restore runtime pm state on test exit

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-28 11:08:29)
> From: Tvrtko Ursulin 
> 
> Some tests (the ones which call igt_setup_runtime_pm and
> igt_pm_enable_audio_runtime_pm) change default system configuration and
> never restore it.
> 
> The configured runtime suspend is aggressive and may influence behaviour
> of subsequent tests, so it is better to restore to previous values on test
> exit.
> 
> This way system behaviour, with regards to a random sequence of executed
> tests, will be more consistent from one run to another.

Otoh, if behaviour changes in subsequent tests, we likely have a lack of
testing :(
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote:
> On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> > On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
> > wrote:
> > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > > self, so lets use the mutex register that is available in gen9+ to
> > > avoid concurrent access by hardware and driver.
> > > Older gen handling will be done separated.
> > > 
> > > Reference: https://01.org/sites/default/files/documentation/intel-g
> > > fx-prm-osrc-skl-vol12-display.pdf
> > > Page 198 - AUX programming sequence
> > > 
> > > Reviewed-by: Dhinakaran Pandiyan 
> > > Reviewed-by: Rodrigo Vivi 
> > > Cc: Jani Nikula 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > > 
> > > Changelog:
> > > v2
> > > - removed the PSR dependency, now getting lock all the times when
> > > available
> > > - renamed functions to avoid nested calls
> > > - moved register bits right after the DP_AUX_CH_MUTEX()
> > > - removed 'drm/i915: keep AUX powered while PSR is enabled'
> > > Dhinakaran Pandiyan will sent a better and final version
> > > v3
> > > - rebased on top of Ville's AUX series
> > > - moved port registers to above DP_AUX_CH_MUTEX()
> > > - using intel_wait_for_register() instead of the internal version
> > > v4
> > > - removed virtual function to get mutex register address
> > > - enabling the mutex back only on aux channel init
> > > - added the aux channel name to the timeout debug message
> > > v5
> > > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> > > - renamed goto label when intel_dp_aux_ch_trylock() fails
> > > 
> > >  drivers/gpu/drm/i915/i915_reg.h |  9 
> > >  drivers/gpu/drm/i915/intel_dp.c | 47
> > > +
> > >  2 files changed, 56 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index eea5b2c537d4..bce2e6dad4c4 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5385,6 +5385,15 @@ enum {
> > >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> > >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> > >  
> > > +#define _DPA_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6402C)
> > > +#define _DPB_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6412C)
> > > +#define _DPC_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6422C)
> > > +#define _DPD_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6432C)
> > > +#define _DPF_AUX_CH_MUTEX(dev_priv-
> > > >info.display_mmio_offset + 0x6452C)
> > > +#define DP_AUX_CH_MUTEX(aux_ch)  _MMIO_PORT(aux_ch,
> > > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> > > +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> > > +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> > > +
> > >  /*
> > >   * Computing GMCH M and N values for the Display Port link
> > >   *
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 2a3b3ae4e3da..7f4bf77227cd 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1081,6 +1081,42 @@ static uint32_t
> > > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > >   aux_clock_divider)
> > > ;
> > >  }
> > >  
> > > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *intel_dig_port =
> > > dp_to_dig_port(intel_dp);
> > > + struct drm_i915_private *dev_priv =
> > > + to_i915(intel_dig_port->base.base.dev);
> > > +
> > > + if (INTEL_GEN(dev_priv) < 9)
> > > + return true;
> > > +
> > > + /* Spec says that mutex is acquired when status bit is
> > > read as unset,
> > > +  * here waiting for 2msec(+-4 aux transactions) before
> > > give up.
> > > +  */
> > > + if (intel_wait_for_register(dev_priv,
> > > DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > > + DP_AUX_CH_MUTEX_STATUS, 0, 2))
> > > {
> > > + DRM_DEBUG_KMS("aux channel %c locked for 2msec,
> > > timing out\n",
> > > +   aux_ch_name(intel_dp->aux_ch));
> > > + return false;
> > > + }
> > > +
> > > + return true;
> > > +}
> > > +
> > > +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *intel_dig_port =
> > > dp_to_dig_port(intel_dp);
> > > + struct drm_i915_private *dev_priv =
> > > + to_i915(intel_dig_port->base.base.dev);
> > > +
> > > + if (INTEL_GEN(dev_priv) < 9)
> > > + return;
> > > +
> > > + /* set the status bit releases the mutex + keeping mutex
> > > enabled */
> > > + 

[Intel-gfx] [PATCH i-g-t] lib/igt_pm: Restore runtime pm state on test exit

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some tests (the ones which call igt_setup_runtime_pm and
igt_pm_enable_audio_runtime_pm) change default system configuration and
never restore it.

The configured runtime suspend is aggressive and may influence behaviour
of subsequent tests, so it is better to restore to previous values on test
exit.

This way system behaviour, with regards to a random sequence of executed
tests, will be more consistent from one run to another.

Signed-off-by: Tvrtko Ursulin 
Cc: Imre Deak 
---
 lib/igt_pm.c | 107 +--
 1 file changed, 104 insertions(+), 3 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 5bf5b2e23cdc..0c8b5e8e9257 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -63,6 +63,46 @@ enum {
 /* Remember to fix this if adding longer strings */
 #define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
 
+static char __igt_pm_audio_runtime_power_save[64];
+static char __igt_pm_audio_runtime_control[64];
+
+static void __igt_pm_audio_runtime_exit_handler(int sig)
+{
+   int fd;
+
+   igt_debug("Restoring audio power management to '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
+   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+   if (fd < 0)
+   return;
+   if (write(fd, __igt_pm_audio_runtime_power_save,
+ strlen(__igt_pm_audio_runtime_power_save)) !=
+   strlen(__igt_pm_audio_runtime_power_save))
+   igt_warn("Failed to restore audio power_save to '%s'\n",
+__igt_pm_audio_runtime_power_save);
+   close(fd);
+
+   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   if (fd < 0)
+   return;
+   if (write(fd, __igt_pm_audio_runtime_control,
+ strlen(__igt_pm_audio_runtime_control)) !=
+   strlen(__igt_pm_audio_runtime_control))
+   igt_warn("Failed to restore audio control to '%s'\n",
+__igt_pm_audio_runtime_control);
+   close(fd);
+}
+
+static void strchomp(char *str)
+{
+   int len = strlen(str);
+
+   if (str[len - 1] == '\n')
+   str[len - 1] = 0;
+}
+
 /**
  * igt_pm_enable_audio_runtime_pm:
  *
@@ -78,16 +118,32 @@ void igt_pm_enable_audio_runtime_pm(void)
 {
int fd;
 
-   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+   /* Check if already enabled. */
+   if (__igt_pm_audio_runtime_power_save[0])
+   return;
+
+   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
if (fd >= 0) {
+   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+   strchomp(__igt_pm_audio_runtime_power_save);
igt_assert_eq(write(fd, "1\n", 2), 2);
+   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
close(fd);
}
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
if (fd >= 0) {
+   igt_assert(read(fd, __igt_pm_audio_runtime_control,
+   sizeof(__igt_pm_audio_runtime_control)) > 0);
+   strchomp(__igt_pm_audio_runtime_control);
igt_assert_eq(write(fd, "auto\n", 5), 5);
close(fd);
}
+
+   igt_debug("Saved audio power management as '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
/* Give some time for it to react. */
sleep(1);
 }
@@ -238,6 +294,38 @@ void igt_pm_restore_sata_link_power_management(int8_t 
*pm_data)
 /* We just leak this on exit ... */
 int pm_status_fd = -1;
 
+static char __igt_pm_runtime_autosuspend[64];
+static char __igt_pm_runtime_control[64];
+
+static void __igt_pm_runtime_exit_handler(int sig)
+{
+   int fd;
+
+   igt_debug("Restoring runtime management to '%s' and '%s'\n",
+ __igt_pm_runtime_autosuspend,
+ __igt_pm_runtime_control);
+
+   fd = open(POWER_DIR "/autosuspend_delay_ms", O_WRONLY);
+   if (fd < 0)
+   return;
+   if (write(fd, __igt_pm_runtime_autosuspend,
+ strlen(__igt_pm_runtime_autosuspend)) !=
+   strlen(__igt_pm_runtime_autosuspend))
+   igt_warn("Failed to restore runtime pm autosuspend delay to 
'%s'\n",
+__igt_pm_runtime_autosuspend);
+   close(fd);
+
+   fd = open(POWER_DIR "/control", O_WRONLY);
+   if (fd < 0)
+   return;
+   if (write(fd, __igt_pm_runtime_control,
+ 

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/dp: move link rate arrays where they're used

[Patchwork]

== Series Details ==

Series: drm/i915/dp: move link rate arrays where they're used
URL   : https://patchwork.freedesktop.org/series/39032/
State : warning

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-indfb-msflip-blt:
pass   -> SKIP   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887 +1
Test kms_mmap_write_crc:
fail   -> PASS   (shard-apl) fdo#103286
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_vblank:
Subgroup pipe-b-ts-continuation-dpms-suspend:
incomplete -> PASS   (shard-hsw) fdo#105054
Test pm_rpm:
Subgroup system-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103286 https://bugs.freedesktop.org/show_bug.cgi?id=103286
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#105054 https://bugs.freedesktop.org/show_bug.cgi?id=105054
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:7   skip:1632 
time:12192s
shard-hswtotal:3460 pass:1764 dwarn:1   dfail:0   fail:3   skip:1691 
time:11751s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6589s
Blacklisted hosts:
shard-kbltotal:3460 pass:1942 dwarn:1   dfail:0   fail:8   skip:1509 
time:9581s

== Logs ==

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] tests/kms_frontbuffer_tracking: Fix build warning

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-28 10:07:59)
> From: Tvrtko Ursulin 
> 
> Mark drrs_set as static to avoid a build warning.
> 
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] tests/perf: Fix build warning

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 28/02/18 10:08, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Move variable declaration to top of scope to avoid C90 build warning.

Signed-off-by: Tvrtko Ursulin 
---
  tests/perf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/perf.c b/tests/perf.c
index c302a355b850..78bf6cdd3504 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -1726,6 +1726,7 @@ test_oa_exponents(void)
int buf_size = sample_size * max_reports * 1.5;
uint8_t *buf = calloc(1, buf_size);
int ret, n_timer_reports = 0;
+   uint32_t matches = 0;
struct {
uint32_t report[64];
} timer_reports[30];
@@ -1785,7 +1786,6 @@ test_oa_exponents(void)
igt_debug("report%04i ts=%08x hw_id=0x%08x\n", 0,
  timer_reports[0].report[1],
  oa_report_get_ctx_id(timer_reports[0].report));
-   uint32_t matches = 0;
for (int i = 1; i < n_timer_reports; i++) {
uint32_t delta =
timer_reports[i].report[1] - timer_reports[i - 
1].report[1];



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