Re: [Intel-gfx] [PATCH 8/8] drm/i915/uc: Simplify firmware path handling

[Joonas Lahtinen]

On ke, 2017-02-22 at 16:52 +0100, Arkadiusz Hiler wrote:
> On Wed, Feb 22, 2017 at 04:30:49PM +0100, Arkadiusz Hiler wrote:
> > 
> > On Wed, Feb 22, 2017 at 12:53:47PM +, Chris Wilson wrote:
> > > 
> > > Now plan for having fw_path overriden by a i915_param.guc_firmware.
> > > 
> > > Perhaps something like
> > >   if (i915_param.guc_firmware) {
> > >   guc->fw.path = i915_param.guc_firmware; /* needs 0400! */
> > >   guc->fw.major_ver_wanted = -1;
> > >   guc->fw.minor_ver_wanted = -1;
> > >   } else if (IS_SKYLAKE
> > > works?
> > 
> > Sorry, I do not quite understand the comment. Can you elaborate?
> 
> Nevermind, got it.
> 
> LGTM, but for it to fully work we need to make uc_fetch_fw (or however
> it will end up being named) aware that -1 have special meaning.
> 
> Now the version cross-check looks like that:
> 
> if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
> uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {

What Chris proposed, together with tweaking the check sounds good.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for GLK plane/scaling fixes (rev2)

[Patchwork]

== Series Details ==

Series: GLK plane/scaling fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/20051/
State : success

== Summary ==

Series 20051v2 GLK plane/scaling fixes
https://patchwork.freedesktop.org/api/1.0/series/20051/revisions/2/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 
fi-byt-n2820 failed to collect. IGT log at Patchwork_3941/fi-byt-n2820/igt.log

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
2ab3ea2 drm/i915/glk: Fix Geminilake scalers mode programming
ec7e6c0 drm/i915/glk: Pass dev_priv to intel_atomic_setup_scalers()
5fe955a drm/i915/glk: Fix maximum scaling factor for Geminilake scalers
9d11448 drm/i915/glk: Fix watermark computations for third sprite plane

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3941/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 15/16] drm/i915: Immediately process a reset before starting waiting

[Chris Wilson]

As we handoff the GPU reset to the waiter, we need to check we don't
miss a wakeup if it has already been sent prior to us starting the wait.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index ee601e13e28a..eaa333a35f7c 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1081,8 +1081,10 @@ long i915_wait_request(struct drm_i915_gem_request *req,
trace_i915_gem_request_wait_begin(req, flags);
 
add_wait_queue(>execute, );
-   if (flags & I915_WAIT_LOCKED)
+   if (flags & I915_WAIT_LOCKED) {
add_wait_queue(errq, );
+   __i915_wait_request_check_and_reset(req);
+   }
 
intel_wait_init();
 
@@ -1120,7 +1122,8 @@ long i915_wait_request(struct drm_i915_gem_request *req,
goto complete;
 
set_current_state(state);
-   if (intel_engine_add_wait(req->engine, ))
+   if (intel_engine_add_wait(req->engine, ) ||
+   flags & I915_WAIT_LOCKED)
/* In order to check that we haven't missed the interrupt
 * as we enabled it, we need to kick ourselves to do a
 * coherent check on the seqno before we sleep.
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw()

[Joonas Lahtinen]

On ke, 2017-02-22 at 16:29 +0100, Arkadiusz Hiler wrote:
> On Wed, Feb 22, 2017 at 03:59:01PM +0200, Joonas Lahtinen wrote:
> > 
> > > + * @huc: intel_huc struct
> > >   *
> > >   * Called early during driver load, but after GEM is initialised. The 
> > > loading
> > >   * will continue only when driver explicitly specify firmware name and 
> > > version.
> > > @@ -152,42 +152,41 @@ static int huc_ucode_xfer(struct drm_i915_private 
> > > *dev_priv)
> > >   *
> > >   * The DMA-copying to HW is done later when intel_huc_init_hw() is 
> > > called.
> > >   */
> > > -void intel_huc_init(struct drm_i915_private *dev_priv)
> > > +void intel_huc_fetch_fw(struct intel_huc *huc)
> > >  {
> > > > > > -   struct intel_huc *huc = _priv->huc;
> > > > > > -   struct intel_uc_fw *huc_fw = >fw;
> > > > > > +   struct drm_i915_private *dev_priv = huc_to_i915(huc);
> > > > > >     const char *fw_path = NULL;
> > 
> > Similarly arrange to get rid of fw_path here.
> 
> Patch 8 in the series addresses that issue as well. Maybe I should move
> them around?

Nah, it's fine, the intermediary steps need to be working (for
bisecting), but not necessarily 100% pretty. If it's addressed later,
it's good.

> > > @@ -30,6 +30,12 @@ void intel_uc_init_early(struct drm_i915_private 
> > > *dev_priv)
> > >   mutex_init(_priv->guc.send_mutex);
> > >  }
> > >  
> > > +void intel_uc_fetch_fw(struct drm_i915_private *dev_priv)
> > 
> > This function might be worth calling intel_uc_init (See above), if the
> > need comes to add other stuff. But either way.
> 
> This is quite confusing now. I was fine it being named init, someone
> suggested to be more descriptive with the name, as it is not general
> enough to be "init". Seemed reasonable enough for me, so I incorporated
> that in the respin.
> 
> This is turning into some heavy bikeshedding now...

That's why actual code in the mailing list is the only right way,
discussion in IRC can be misleading :)

> 
> I agree that it's more than fetch, it actually selects + fetches +
> populates the structures.
> 
> I'll gladly ignore previous feedback on being to vague with name and
> just go with init, but let give the _fw postfix one last chance:
> 
> 
> intel_guc_init_fw {
> intel_guc_select_fw
> if (NULL != guc.fw.path)

if (guc.fw.patch) to stick to coding style.

>   intel_uc_prepare_fw
> }
> 
> Where select does what the guc's fetch fw does sans the uc_fetch call.

Sounds good to me.

> Also intel_{g,h}uc_select_fw can be made part of the sanitize options,
> but I think it better belongs here.
> 
> That's is basing on your suggestions for the other patch.

Thats, correct, select_fw should be here.


if (!HAS_GUC(dev_priv)) {
i915.enable_guc_loading = 0;
i915.enable_guc_submission = 0;
} else {
/* A negative value means "use platform default" */
if (i915.enable_guc_loading < 0)
i915.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
if (i915.enable_guc_submission < 0)
i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
}

This part is a perfect fit to the sanitize_options function, because
that's what it does, makes sure we don't try to enable something we
don't have.

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

[Intel-gfx] [PATCH v4 06/16] drm/i915: Inline __i915_gem_request_wait_for_execute()

[Chris Wilson]

It had only one callsite and existed to keep the code clearer. Now
having shared the wait-on-error between phases and with plans to change
the wait-for-execute in the next few patches, remove the out of line
wait loop and move it into the main body of i915_wait_request.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 78 -
 1 file changed, 29 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index ed1d42e7a206..88139dbf8fcc 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1005,54 +1005,6 @@ bool __i915_spin_request(const struct 
drm_i915_gem_request *req,
return false;
 }
 
-static long
-__i915_request_wait_for_execute(struct drm_i915_gem_request *request,
-   unsigned int flags,
-   long timeout)
-{
-   const int state = flags & I915_WAIT_INTERRUPTIBLE ?
-   TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
-   wait_queue_head_t *q = >i915->gpu_error.wait_queue;
-   DEFINE_WAIT(reset);
-   DEFINE_WAIT(wait);
-
-   if (flags & I915_WAIT_LOCKED)
-   add_wait_queue(q, );
-
-   do {
-   prepare_to_wait(>execute.wait, , state);
-
-   if (i915_sw_fence_done(>execute))
-   break;
-
-   if (flags & I915_WAIT_LOCKED &&
-   i915_reset_in_progress(>i915->gpu_error)) {
-   __set_current_state(TASK_RUNNING);
-   i915_reset(request->i915);
-   reset_wait_queue(q, );
-   continue;
-   }
-
-   if (signal_pending_state(state, current)) {
-   timeout = -ERESTARTSYS;
-   break;
-   }
-
-   if (!timeout) {
-   timeout = -ETIME;
-   break;
-   }
-
-   timeout = io_schedule_timeout(timeout);
-   } while (1);
-   finish_wait(>execute.wait, );
-
-   if (flags & I915_WAIT_LOCKED)
-   remove_wait_queue(q, );
-
-   return timeout;
-}
-
 /**
  * i915_wait_request - wait until execution of request has finished
  * @req: the request to wait upon
@@ -1102,7 +1054,35 @@ long i915_wait_request(struct drm_i915_gem_request *req,
add_wait_queue(errq, );
 
if (!i915_sw_fence_done(>execute)) {
-   timeout = __i915_request_wait_for_execute(req, flags, timeout);
+   DEFINE_WAIT(exec);
+
+   do {
+   prepare_to_wait(>execute.wait, , state);
+   if (i915_sw_fence_done(>execute))
+   break;
+
+   if (flags & I915_WAIT_LOCKED &&
+   i915_reset_in_progress(>i915->gpu_error)) {
+   __set_current_state(TASK_RUNNING);
+   i915_reset(req->i915);
+   reset_wait_queue(errq, );
+   continue;
+   }
+
+   if (signal_pending_state(state, current)) {
+   timeout = -ERESTARTSYS;
+   break;
+   }
+
+   if (!timeout) {
+   timeout = -ETIME;
+   break;
+   }
+
+   timeout = io_schedule_timeout(timeout);
+   } while (1);
+   finish_wait(>execute.wait, );
+
if (timeout < 0)
goto complete;
 
-- 
2.11.0

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

[Intel-gfx] [PATCH v4 01/16] drm/i915: Check against the signaled bit for fences/requests

[Chris Wilson]

When dma_fence_signal() is called, it sets a flag to indicate the fence
is complete. Before the dma_fence is signaled, the seqno check will
first be passed. During an unlocked check (such as inside a waiter), it
is possible for the fence to be signaled even though the seqno has been
reset (by engine wraparound). In this case the waiter will be kicked,
but for an extra layer of protection we can check the persistent
signaled bit from the fence.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 994929660027..0d3f787a0a7a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4026,6 +4026,15 @@ __i915_request_irq_complete(struct drm_i915_gem_request 
*req)
 {
struct intel_engine_cs *engine = req->engine;
 
+   /* Note that the engine may have wrapped around the seqno, and
+* so our request->global_seqno will be ahead of the hardware,
+* even though it completed the request before wrapping. We catch
+* this by kicking all the waiters before resetting the seqno
+* in hardware, and also signal the fence.
+*/
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+   return true;
+
/* Before we do the heavier coherent read of the seqno,
 * check the value (hopefully) in the CPU cacheline.
 */
-- 
2.11.0

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

[Intel-gfx] [PATCH v4 12/16] drm/i915: Exercise request cancellation using a mock selftest

[Chris Wilson]

Add a mock selftest to preempt a request and check that we cancel it,
requeue the request and then complete its execution.

v2: Error leaks no more.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/i915_gem_request.c | 64 +++
 drivers/gpu/drm/i915/selftests/mock_request.c | 19 +++
 drivers/gpu/drm/i915/selftests/mock_request.h |  2 +
 3 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
index 9d056a86723d..42bdeac93324 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
@@ -26,6 +26,7 @@
 
 #include "../i915_selftest.h"
 
+#include "mock_context.h"
 #include "mock_gem_device.h"
 
 static int igt_add_request(void *arg)
@@ -181,12 +182,75 @@ static int igt_fence_wait(void *arg)
return err;
 }
 
+static int igt_request_rewind(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct drm_i915_gem_request *request, *vip;
+   struct i915_gem_context *ctx[2];
+   int err = -EINVAL;
+
+   mutex_lock(>drm.struct_mutex);
+   ctx[0] = mock_context(i915, "A");
+   request = mock_request(i915->engine[RCS], ctx[0], 2 * HZ);
+   if (!request) {
+   err = -ENOMEM;
+   goto err_context_0;
+   }
+
+   i915_gem_request_get(request);
+   i915_add_request(request);
+
+   ctx[1] = mock_context(i915, "B");
+   vip = mock_request(i915->engine[RCS], ctx[1], 0);
+   if (!vip) {
+   err = -ENOMEM;
+   goto err_context_1;
+   }
+
+   /* Simulate preemption by manual reordering */
+   if (!mock_cancel_request(request)) {
+   pr_err("failed to cancel request (already executed)!\n");
+   i915_add_request(vip);
+   goto err_context_1;
+   }
+   i915_gem_request_get(vip);
+   i915_add_request(vip);
+   request->engine->submit_request(request);
+
+   mutex_unlock(>drm.struct_mutex);
+
+   if (i915_wait_request(vip, 0, HZ) == -ETIME) {
+   pr_err("timed out waiting for high priority request, 
vip.seqno=%d, current seqno=%d\n",
+  vip->global_seqno, 
intel_engine_get_seqno(i915->engine[RCS]));
+   goto err;
+   }
+
+   if (i915_gem_request_completed(request)) {
+   pr_err("low priority request already completed\n");
+   goto err;
+   }
+
+   err = 0;
+err:
+   i915_gem_request_put(vip);
+   mutex_lock(>drm.struct_mutex);
+err_context_1:
+   mock_context_close(ctx[1]);
+   i915_gem_request_put(request);
+err_context_0:
+   mock_context_close(ctx[0]);
+   mock_device_flush(i915);
+   mutex_unlock(>drm.struct_mutex);
+   return err;
+}
+
 int i915_gem_request_mock_selftests(void)
 {
static const struct i915_subtest tests[] = {
SUBTEST(igt_add_request),
SUBTEST(igt_wait_request),
SUBTEST(igt_fence_wait),
+   SUBTEST(igt_request_rewind),
};
struct drm_i915_private *i915;
int err;
diff --git a/drivers/gpu/drm/i915/selftests/mock_request.c 
b/drivers/gpu/drm/i915/selftests/mock_request.c
index e23242d1b88a..0e8d2e7f8c70 100644
--- a/drivers/gpu/drm/i915/selftests/mock_request.c
+++ b/drivers/gpu/drm/i915/selftests/mock_request.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include "mock_engine.h"
 #include "mock_request.h"
 
 struct drm_i915_gem_request *
@@ -42,3 +43,21 @@ mock_request(struct intel_engine_cs *engine,
 
return >base;
 }
+
+bool mock_cancel_request(struct drm_i915_gem_request *request)
+{
+   struct mock_request *mock = container_of(request, typeof(*mock), base);
+   struct mock_engine *engine =
+   container_of(request->engine, typeof(*engine), base);
+   bool was_queued;
+
+   spin_lock_irq(>hw_lock);
+   was_queued = !list_empty(>link);
+   list_del_init(>link);
+   spin_unlock_irq(>hw_lock);
+
+   if (was_queued)
+   i915_gem_request_unsubmit(request);
+
+   return was_queued;
+}
diff --git a/drivers/gpu/drm/i915/selftests/mock_request.h 
b/drivers/gpu/drm/i915/selftests/mock_request.h
index cc76d4f4eb4e..4dea74c8e96d 100644
--- a/drivers/gpu/drm/i915/selftests/mock_request.h
+++ b/drivers/gpu/drm/i915/selftests/mock_request.h
@@ -41,4 +41,6 @@ mock_request(struct intel_engine_cs *engine,
 struct i915_gem_context *context,
 unsigned long delay);
 
+bool mock_cancel_request(struct drm_i915_gem_request *request);
+
 #endif /* !__MOCK_REQUEST__ */
-- 
2.11.0

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

[Intel-gfx] [PATCH v4 13/16] drm/i915: Replace reset_wait_queue with default_wake_function

[Chris Wilson]

If we change the wait_queue_t from using the autoremove_wake_function to
the default_wake_function, we no longer have to restore the wait_queue_t
entry on the wait_queue_head_t list after being woken up by it, as we
are unusual in sleeping multiple times on the same wait_queue_t.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 30 +++---
 1 file changed, 7 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 76e31cd7840e..e04f66002047 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -946,16 +946,6 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
 }
 
-static void reset_wait_queue(wait_queue_head_t *q, wait_queue_t *wait)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(>lock, flags);
-   if (list_empty(>task_list))
-   __add_wait_queue(q, wait);
-   spin_unlock_irqrestore(>lock, flags);
-}
-
 static unsigned long local_clock_us(unsigned int *cpu)
 {
unsigned long t;
@@ -1060,8 +1050,8 @@ long i915_wait_request(struct drm_i915_gem_request *req,
const int state = flags & I915_WAIT_INTERRUPTIBLE ?
TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
wait_queue_head_t *errq = >i915->gpu_error.wait_queue;
-   DEFINE_WAIT(reset);
-   DEFINE_WAIT(exec);
+   DEFINE_WAIT_FUNC(reset, default_wake_function);
+   DEFINE_WAIT_FUNC(exec, default_wake_function);
struct intel_wait wait;
 
might_sleep();
@@ -1080,13 +1070,13 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
trace_i915_gem_request_wait_begin(req, flags);
 
+   add_wait_queue(>execute, );
if (flags & I915_WAIT_LOCKED)
add_wait_queue(errq, );
 
intel_wait_init();
 
 restart:
-   reset_wait_queue(>execute, );
if (!intel_wait_update_request(, req)) {
do {
set_current_state(state);
@@ -1098,26 +1088,21 @@ long i915_wait_request(struct drm_i915_gem_request *req,
i915_reset_in_progress(>i915->gpu_error)) {
__set_current_state(TASK_RUNNING);
i915_reset(req->i915);
-   reset_wait_queue(errq, );
continue;
}
 
if (signal_pending_state(state, current)) {
timeout = -ERESTARTSYS;
-   break;
+   goto complete;
}
 
if (!timeout) {
timeout = -ETIME;
-   break;
+   goto complete;
}
 
timeout = io_schedule_timeout(timeout);
} while (1);
-   finish_wait(>execute, );
-
-   if (timeout < 0)
-   goto complete;
 
GEM_BUG_ON(!intel_wait_has_seqno());
}
@@ -1177,7 +1162,6 @@ long i915_wait_request(struct drm_i915_gem_request *req,
i915_reset_in_progress(>i915->gpu_error)) {
__set_current_state(TASK_RUNNING);
i915_reset(req->i915);
-   reset_wait_queue(errq, );
continue;
}
 
@@ -1192,11 +1176,11 @@ long i915_wait_request(struct drm_i915_gem_request *req,
}
 
intel_engine_remove_wait(req->engine, );
-   __set_current_state(TASK_RUNNING);
-
 complete:
+   __set_current_state(TASK_RUNNING);
if (flags & I915_WAIT_LOCKED)
remove_wait_queue(errq, );
+   remove_wait_queue(>execute, );
trace_i915_gem_request_wait_end(req);
 
return timeout;
-- 
2.11.0

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

[Intel-gfx] Preemption preparation pass phaw

[Chris Wilson]

Tvrkto ordered a stay of execution for the intel_wait_helpers.
-Chris

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

[Intel-gfx] [PATCH v4 16/16] drm/i915: Remove one level of indention from wait-for-execute

[Chris Wilson]

Now that the code is getting simpler, we can reduce the indentation when
waiting for the global_seqno.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 39 +++--
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index eaa333a35f7c..bb29255dd3a1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1089,32 +1089,29 @@ long i915_wait_request(struct drm_i915_gem_request *req,
intel_wait_init();
 
 restart:
-   if (!intel_wait_update_request(, req)) {
-   do {
-   set_current_state(state);
-
-   if (intel_wait_update_request(, req))
-   break;
+   do {
+   set_current_state(state);
+   if (intel_wait_update_request(, req))
+   break;
 
-   if (flags & I915_WAIT_LOCKED &&
-   __i915_wait_request_check_and_reset(req))
-   continue;
+   if (flags & I915_WAIT_LOCKED &&
+   __i915_wait_request_check_and_reset(req))
+   continue;
 
-   if (signal_pending_state(state, current)) {
-   timeout = -ERESTARTSYS;
-   goto complete;
-   }
+   if (signal_pending_state(state, current)) {
+   timeout = -ERESTARTSYS;
+   goto complete;
+   }
 
-   if (!timeout) {
-   timeout = -ETIME;
-   goto complete;
-   }
+   if (!timeout) {
+   timeout = -ETIME;
+   goto complete;
+   }
 
-   timeout = io_schedule_timeout(timeout);
-   } while (1);
+   timeout = io_schedule_timeout(timeout);
+   } while (1);
 
-   GEM_BUG_ON(!intel_wait_has_seqno());
-   }
+   GEM_BUG_ON(!intel_wait_has_seqno());
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
 
/* Optimistic short spin before touching IRQs */
-- 
2.11.0

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

[Intel-gfx] [PATCH v4 08/16] drm/i915: Protect the request->global_seqno with the engine->timeline lock

[Chris Wilson]

A request is assigned a global seqno only when it is on the hardware
execution queue. The global seqno can be used to maintain a list of
requests on the same engine in retirement order, for example for
constructing a priority queue for waiting. Prior to its execution, or
if it is subsequently removed in the event of preemption, its global
seqno is zero. As both insertion and removal from the execution queue
may operate in IRQ context, it is not guarded by the usual struct_mutex
BKL. Instead those relying on the global seqno must be prepared for its
value to change between reads. Only when the request is complete can
the global seqno be stable (due to the memory barriers on submitting
the commands to the hardware to write the breadcrumb, if the HWS shows
that it has passed the global seqno and the global seqno is unchanged
after the read, it is indeed complete).

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h| 17 +-
 drivers/gpu/drm/i915/i915_gem.c| 16 --
 drivers/gpu/drm/i915/i915_gem_request.c| 45 ++-
 drivers/gpu/drm/i915/i915_gem_request.h| 66 +-
 drivers/gpu/drm/i915/intel_breadcrumbs.c   | 11 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h| 39 -
 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  6 +-
 7 files changed, 155 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0d3f787a0a7a..343d75181bb7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4022,9 +4022,10 @@ wait_remaining_ms_from_jiffies(unsigned long 
timestamp_jiffies, int to_wait_ms)
 }
 
 static inline bool
-__i915_request_irq_complete(struct drm_i915_gem_request *req)
+__i915_request_irq_complete(const struct drm_i915_gem_request *req)
 {
struct intel_engine_cs *engine = req->engine;
+   u32 seqno;
 
/* Note that the engine may have wrapped around the seqno, and
 * so our request->global_seqno will be ahead of the hardware,
@@ -4035,10 +4036,20 @@ __i915_request_irq_complete(struct drm_i915_gem_request 
*req)
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
return true;
 
+   /* The request was dequeued before we were awoken. We check after
+* inspecting the hw to confirm that this was the same request
+* that generated the HWS update. The memory barriers within
+* the request execution are sufficient to ensure that a check
+* after reading the value from hw matches this request.
+*/
+   seqno = i915_gem_request_global_seqno(req);
+   if (!seqno)
+   return false;
+
/* Before we do the heavier coherent read of the seqno,
 * check the value (hopefully) in the CPU cacheline.
 */
-   if (__i915_gem_request_completed(req))
+   if (__i915_gem_request_completed(req, seqno))
return true;
 
/* Ensure our read of the seqno is coherent so that we
@@ -4089,7 +4100,7 @@ __i915_request_irq_complete(struct drm_i915_gem_request 
*req)
wake_up_process(tsk);
rcu_read_unlock();
 
-   if (__i915_gem_request_completed(req))
+   if (__i915_gem_request_completed(req, seqno))
return true;
}
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fce2cec8e665..f950cedb6516 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -397,7 +397,7 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
if (flags & I915_WAIT_LOCKED && i915_gem_request_completed(rq))
i915_gem_request_retire_upto(rq);
 
-   if (rps && rq->global_seqno == intel_engine_last_submit(rq->engine)) {
+   if (rps && i915_gem_request_global_seqno(rq) == 
intel_engine_last_submit(rq->engine)) {
/* The GPU is now idle and this client has stalled.
 * Since no other client has submitted a request in the
 * meantime, assume that this client is the only one
@@ -2609,7 +2609,8 @@ static void i915_gem_context_mark_innocent(struct 
i915_gem_context *ctx)
 struct drm_i915_gem_request *
 i915_gem_find_active_request(struct intel_engine_cs *engine)
 {
-   struct drm_i915_gem_request *request;
+   struct drm_i915_gem_request *request, *active = NULL;
+   unsigned long flags;
 
/* We are called by the error capture and reset at a random
 * point in time. In particular, note that neither is crucially
@@ -2619,17 +2620,22 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 * extra delay for a recent interrupt is pointless. Hence, we do
 * not need an engine->irq_seqno_barrier() before the seqno reads.
 

[Intel-gfx] [PATCH v4 05/16] drm/i915: Add ourselves to the gpu error waitqueue for the entire wait

[Chris Wilson]

Add ourselves to the gpu error waitqueue earlier on, even before we
determine we have to wait on the seqno. This is so that we can then
share the waitqueue between stages in subsequent patches.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index c1a1da3ee0d7..ed1d42e7a206 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1098,6 +1098,9 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
trace_i915_gem_request_wait_begin(req, flags);
 
+   if (flags & I915_WAIT_LOCKED)
+   add_wait_queue(errq, );
+
if (!i915_sw_fence_done(>execute)) {
timeout = __i915_request_wait_for_execute(req, flags, timeout);
if (timeout < 0)
@@ -1113,9 +1116,6 @@ long i915_wait_request(struct drm_i915_gem_request *req,
goto complete;
 
set_current_state(state);
-   if (flags & I915_WAIT_LOCKED)
-   add_wait_queue(errq, );
-
intel_wait_init(, req->global_seqno);
if (intel_engine_add_wait(req->engine, ))
/* In order to check that we haven't missed the interrupt
@@ -1175,11 +1175,11 @@ long i915_wait_request(struct drm_i915_gem_request *req,
}
 
intel_engine_remove_wait(req->engine, );
-   if (flags & I915_WAIT_LOCKED)
-   remove_wait_queue(errq, );
__set_current_state(TASK_RUNNING);
 
 complete:
+   if (flags & I915_WAIT_LOCKED)
+   remove_wait_queue(errq, );
trace_i915_gem_request_wait_end(req);
 
return timeout;
-- 
2.11.0

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

[Intel-gfx] [PATCH v4 14/16] drm/i915: Refactor direct GPU reset from request waiters

[Chris Wilson]

Combine the common code for the pair of waiters into a single function.

v2: Rename reset_request to wait_request_check_and_reset

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

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index e04f66002047..ee601e13e28a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1024,6 +1024,16 @@ bool __i915_spin_request(const struct 
drm_i915_gem_request *req,
return false;
 }
 
+static bool __i915_wait_request_check_and_reset(struct drm_i915_gem_request 
*request)
+{
+   if (likely(!i915_reset_in_progress(>i915->gpu_error)))
+   return false;
+
+   __set_current_state(TASK_RUNNING);
+   i915_reset(request->i915);
+   return true;
+}
+
 /**
  * i915_wait_request - wait until execution of request has finished
  * @req: the request to wait upon
@@ -1085,11 +1095,8 @@ long i915_wait_request(struct drm_i915_gem_request *req,
break;
 
if (flags & I915_WAIT_LOCKED &&
-   i915_reset_in_progress(>i915->gpu_error)) {
-   __set_current_state(TASK_RUNNING);
-   i915_reset(req->i915);
+   __i915_wait_request_check_and_reset(req))
continue;
-   }
 
if (signal_pending_state(state, current)) {
timeout = -ERESTARTSYS;
@@ -1159,11 +1166,8 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 * itself, or indirectly by recovering the GPU).
 */
if (flags & I915_WAIT_LOCKED &&
-   i915_reset_in_progress(>i915->gpu_error)) {
-   __set_current_state(TASK_RUNNING);
-   i915_reset(req->i915);
+   __i915_wait_request_check_and_reset(req))
continue;
-   }
 
/* Only spin if we know the GPU is processing this request */
if (i915_spin_request(req, state, 2))
-- 
2.11.0

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

[Intel-gfx] [PATCH v4 11/16] drm/i915: Remove the preempted request from the execution queue

[Chris Wilson]

After the request is cancelled, we then need to remove it from the
global execution timeline and return it to the context timeline, the
inverse of submit_request().

v2: Move manipulation of struct intel_wait to helpers

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c  | 55 
 drivers/gpu/drm/i915/i915_gem_request.h  |  3 ++
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 17 --
 3 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5ed52521397f..76e31cd7840e 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -441,6 +441,55 @@ void i915_gem_request_submit(struct drm_i915_gem_request 
*request)
spin_unlock_irqrestore(>timeline->lock, flags);
 }
 
+void __i915_gem_request_unsubmit(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   struct intel_timeline *timeline;
+
+   assert_spin_locked(>timeline->lock);
+
+   /* Only unwind in reverse order, required so that the per-context list
+* is kept in seqno/ring order.
+*/
+   GEM_BUG_ON(request->global_seqno != engine->timeline->seqno);
+   engine->timeline->seqno--;
+
+   /* We may be recursing from the signal callback of another i915 fence */
+   spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+   request->global_seqno = 0;
+   if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+   intel_engine_cancel_signaling(request);
+   spin_unlock(>lock);
+
+   /* Transfer back from the global per-engine timeline to per-context */
+   timeline = request->timeline;
+   GEM_BUG_ON(timeline == engine->timeline);
+
+   spin_lock(>lock);
+   list_move(>link, >requests);
+   spin_unlock(>lock);
+
+   /* We don't need to wake_up any waiters on request->execute, they
+* will get woken by any other event or us re-adding this request
+* to the engine timeline (__i915_gem_request_submit()). The waiters
+* should be quite adapt at finding that the request now has a new
+* global_seqno to the one they went to sleep on.
+*/
+}
+
+void i915_gem_request_unsubmit(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   unsigned long flags;
+
+   /* Will be called from irq-context when using foreign fences. */
+   spin_lock_irqsave(>timeline->lock, flags);
+
+   __i915_gem_request_unsubmit(request);
+
+   spin_unlock_irqrestore(>timeline->lock, flags);
+}
+
 static int __i915_sw_fence_call
 submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
 {
@@ -1036,6 +1085,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
intel_wait_init();
 
+restart:
reset_wait_queue(>execute, );
if (!intel_wait_update_request(, req)) {
do {
@@ -1134,6 +1184,11 @@ long i915_wait_request(struct drm_i915_gem_request *req,
/* Only spin if we know the GPU is processing this request */
if (i915_spin_request(req, state, 2))
break;
+
+   if (!intel_wait_check_request(, req)) {
+   intel_engine_remove_wait(req->engine, );
+   goto restart;
+   }
}
 
intel_engine_remove_wait(req->engine, );
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index b81f6709905c..5f73d8c0a38a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -274,6 +274,9 @@ void __i915_add_request(struct drm_i915_gem_request *req, 
bool flush_caches);
 void __i915_gem_request_submit(struct drm_i915_gem_request *request);
 void i915_gem_request_submit(struct drm_i915_gem_request *request);
 
+void __i915_gem_request_unsubmit(struct drm_i915_gem_request *request);
+void i915_gem_request_unsubmit(struct drm_i915_gem_request *request);
+
 struct intel_rps_client;
 #define NO_WAITBOOST ERR_PTR(-1)
 #define IS_RPS_CLIENT(p) (!IS_ERR(p))
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index dd39e4f7a560..027c93e34c97 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -453,7 +453,12 @@ void intel_engine_remove_wait(struct intel_engine_cs 
*engine,
spin_unlock_irq(>lock);
 }
 
-static bool signal_complete(struct drm_i915_gem_request *request)
+static bool signal_valid(const struct drm_i915_gem_request *request)
+{
+   return intel_wait_check_request(>signaling.wait, request);
+}
+
+static bool signal_complete(const struct drm_i915_gem_request *request)
 {
if (!request)
return 

[Intel-gfx] [PATCH v4 03/16] drm/i915: Move reserve_seqno() next to unreserve_seqno()

[Chris Wilson]

Move the companion functions next to each other.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 161 +++-
 1 file changed, 77 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index e8b354cf2f06..31c454089c87 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -198,6 +198,83 @@ i915_priotree_init(struct i915_priotree *pt)
pt->priority = INT_MIN;
 }
 
+static int reset_all_global_seqno(struct drm_i915_private *i915, u32 seqno)
+{
+   struct i915_gem_timeline *timeline = >gt.global_timeline;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   int ret;
+
+   /* Carefully retire all requests without writing to the rings */
+   ret = i915_gem_wait_for_idle(i915,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED);
+   if (ret)
+   return ret;
+
+   i915_gem_retire_requests(i915);
+   GEM_BUG_ON(i915->gt.active_requests > 1);
+
+   /* If the seqno wraps around, we need to clear the breadcrumb rbtree */
+   for_each_engine(engine, i915, id) {
+   struct intel_timeline *tl = >engine[id];
+
+   if (!i915_seqno_passed(seqno, tl->seqno)) {
+   /* spin until threads are complete */
+   while (intel_breadcrumbs_busy(engine))
+   cond_resched();
+   }
+
+   /* Finally reset hw state */
+   tl->seqno = seqno;
+   intel_engine_init_global_seqno(engine, seqno);
+   }
+
+   list_for_each_entry(timeline, >gt.timelines, link) {
+   for_each_engine(engine, i915, id) {
+   struct intel_timeline *tl = >engine[id];
+
+   memset(tl->sync_seqno, 0, sizeof(tl->sync_seqno));
+   }
+   }
+
+   return 0;
+}
+
+int i915_gem_set_global_seqno(struct drm_device *dev, u32 seqno)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   lockdep_assert_held(_priv->drm.struct_mutex);
+
+   if (seqno == 0)
+   return -EINVAL;
+
+   /* HWS page needs to be set less than what we
+* will inject to ring
+*/
+   return reset_all_global_seqno(dev_priv, seqno - 1);
+}
+
+static int reserve_seqno(struct intel_engine_cs *engine)
+{
+   u32 active = ++engine->timeline->inflight_seqnos;
+   u32 seqno = engine->timeline->seqno;
+   int ret;
+
+   /* Reservation is fine until we need to wrap around */
+   if (likely(!add_overflows(seqno, active)))
+   return 0;
+
+   ret = reset_all_global_seqno(engine->i915, 0);
+   if (ret) {
+   engine->timeline->inflight_seqnos--;
+   return ret;
+   }
+
+   return 0;
+}
+
 static void unreserve_seqno(struct intel_engine_cs *engine)
 {
GEM_BUG_ON(!engine->timeline->inflight_seqnos);
@@ -314,90 +391,6 @@ void i915_gem_request_retire_upto(struct 
drm_i915_gem_request *req)
} while (tmp != req);
 }
 
-static int reset_all_global_seqno(struct drm_i915_private *i915, u32 seqno)
-{
-   struct i915_gem_timeline *timeline = >gt.global_timeline;
-   struct intel_engine_cs *engine;
-   enum intel_engine_id id;
-   int ret;
-
-   /* Carefully retire all requests without writing to the rings */
-   ret = i915_gem_wait_for_idle(i915,
-I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
-   if (ret)
-   return ret;
-
-   i915_gem_retire_requests(i915);
-   GEM_BUG_ON(i915->gt.active_requests > 1);
-
-   /* If the seqno wraps around, we need to clear the breadcrumb rbtree */
-   for_each_engine(engine, i915, id) {
-   struct intel_timeline *tl = >engine[id];
-
-   if (!i915_seqno_passed(seqno, tl->seqno)) {
-   /* spin until threads are complete */
-   while (intel_breadcrumbs_busy(engine))
-   cond_resched();
-   }
-
-   /* Finally reset hw state */
-   tl->seqno = seqno;
-   intel_engine_init_global_seqno(engine, seqno);
-   }
-
-   list_for_each_entry(timeline, >gt.timelines, link) {
-   for_each_engine(engine, i915, id) {
-   struct intel_timeline *tl = >engine[id];
-
-   memset(tl->sync_seqno, 0, sizeof(tl->sync_seqno));
-   }
-   }
-
-   return 0;
-}
-
-int i915_gem_set_global_seqno(struct drm_device *dev, u32 seqno)
-{
-   struct drm_i915_private *dev_priv = to_i915(dev);
-
-   

[Intel-gfx] [PATCH v4 02/16] drm/i915: Keep a global seqno per-engine

[Chris Wilson]

Replace the global device seqno with one for each engine, and account
for in-flight seqno on each separately. This is consistent with
dma-fence as each timeline has separate fence-contexts for each engine
and a seqno is only ordered within a fence-context (i.e.  seqno do not
need to be ordered wrt to other engines, just ordered within a single
engine). This is required to enable request rewinding for preemption on
individual engines (we have to rewind the global seqno to avoid
overflow, and we do not have to rewind all engines just to preempt one.)

v2: Rename active_seqno to inflight_seqnos to more clearly indicate that
it is a counter and not equivalent to the existing seqno. Update
functions that operated on active_seqno similarly.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 11 +
 drivers/gpu/drm/i915/i915_gem_request.c  | 83 +---
 drivers/gpu/drm/i915/i915_gem_request.h  |  8 +--
 drivers/gpu/drm/i915/i915_gem_timeline.h |  9 +++-
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 33 ++---
 drivers/gpu/drm/i915/intel_engine_cs.c   |  2 -
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  4 +-
 7 files changed, 70 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 655e60d609c2..1a28b5279bec 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1080,15 +1080,6 @@ static const struct file_operations 
i915_error_state_fops = {
 #endif
 
 static int
-i915_next_seqno_get(void *data, u64 *val)
-{
-   struct drm_i915_private *dev_priv = data;
-
-   *val = 1 + atomic_read(_priv->gt.global_timeline.seqno);
-   return 0;
-}
-
-static int
 i915_next_seqno_set(void *data, u64 val)
 {
struct drm_i915_private *dev_priv = data;
@@ -1106,7 +1097,7 @@ i915_next_seqno_set(void *data, u64 val)
 }
 
 DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
-   i915_next_seqno_get, i915_next_seqno_set,
+   NULL, i915_next_seqno_set,
"0x%llx\n");
 
 static int i915_frequency_info(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 51bc24d1d7c9..e8b354cf2f06 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -198,6 +198,12 @@ i915_priotree_init(struct i915_priotree *pt)
pt->priority = INT_MIN;
 }
 
+static void unreserve_seqno(struct intel_engine_cs *engine)
+{
+   GEM_BUG_ON(!engine->timeline->inflight_seqnos);
+   engine->timeline->inflight_seqnos--;
+}
+
 void i915_gem_retire_noop(struct i915_gem_active *active,
  struct drm_i915_gem_request *request)
 {
@@ -237,6 +243,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
 >i915->gt.idle_work,
 msecs_to_jiffies(100));
}
+   unreserve_seqno(request->engine);
 
/* Walk through the active list, calling retire on each. This allows
 * objects to track their GPU activity and mark themselves as idle
@@ -307,7 +314,7 @@ void i915_gem_request_retire_upto(struct 
drm_i915_gem_request *req)
} while (tmp != req);
 }
 
-static int i915_gem_init_global_seqno(struct drm_i915_private *i915, u32 seqno)
+static int reset_all_global_seqno(struct drm_i915_private *i915, u32 seqno)
 {
struct i915_gem_timeline *timeline = >gt.global_timeline;
struct intel_engine_cs *engine;
@@ -325,15 +332,19 @@ static int i915_gem_init_global_seqno(struct 
drm_i915_private *i915, u32 seqno)
GEM_BUG_ON(i915->gt.active_requests > 1);
 
/* If the seqno wraps around, we need to clear the breadcrumb rbtree */
-   if (!i915_seqno_passed(seqno, atomic_read(>seqno))) {
-   while (intel_breadcrumbs_busy(i915))
-   cond_resched(); /* spin until threads are complete */
-   }
-   atomic_set(>seqno, seqno);
+   for_each_engine(engine, i915, id) {
+   struct intel_timeline *tl = >engine[id];
 
-   /* Finally reset hw state */
-   for_each_engine(engine, i915, id)
+   if (!i915_seqno_passed(seqno, tl->seqno)) {
+   /* spin until threads are complete */
+   while (intel_breadcrumbs_busy(engine))
+   cond_resched();
+   }
+
+   /* Finally reset hw state */
+   tl->seqno = seqno;
intel_engine_init_global_seqno(engine, seqno);
+   }
 
list_for_each_entry(timeline, >gt.timelines, link) {
for_each_engine(engine, i915, id) {
@@ -358,37 +369,38 @@ int i915_gem_set_global_seqno(struct drm_device 

[Intel-gfx] [PATCH v4 10/16] drm/i915: Allow a request to be cancelled

[Chris Wilson]

If we preempt a request and remove it from the execution queue, we need
to undo its global seqno and restart any waiters.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 71 +---
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  1 +
 2 files changed, 57 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index a35d59d00bfb..dd39e4f7a560 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -356,22 +356,15 @@ static inline int wakeup_priority(struct 
intel_breadcrumbs *b,
return tsk->prio;
 }
 
-void intel_engine_remove_wait(struct intel_engine_cs *engine,
- struct intel_wait *wait)
+static void __intel_engine_remove_wait(struct intel_engine_cs *engine,
+  struct intel_wait *wait)
 {
struct intel_breadcrumbs *b = >breadcrumbs;
 
-   /* Quick check to see if this waiter was already decoupled from
-* the tree by the bottom-half to avoid contention on the spinlock
-* by the herd.
-*/
-   if (RB_EMPTY_NODE(>node))
-   return;
-
-   spin_lock_irq(>lock);
+   assert_spin_locked(>lock);
 
if (RB_EMPTY_NODE(>node))
-   goto out_unlock;
+   goto out;
 
if (b->first_wait == wait) {
const int priority = wakeup_priority(b, wait->tsk);
@@ -436,11 +429,27 @@ void intel_engine_remove_wait(struct intel_engine_cs 
*engine,
GEM_BUG_ON(RB_EMPTY_NODE(>node));
rb_erase(>node, >waiters);
 
-out_unlock:
+out:
GEM_BUG_ON(b->first_wait == wait);
GEM_BUG_ON(rb_first(>waiters) !=
   (b->first_wait ? >first_wait->node : NULL));
GEM_BUG_ON(!rcu_access_pointer(b->irq_seqno_bh) ^ 
RB_EMPTY_ROOT(>waiters));
+}
+
+void intel_engine_remove_wait(struct intel_engine_cs *engine,
+ struct intel_wait *wait)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   /* Quick check to see if this waiter was already decoupled from
+* the tree by the bottom-half to avoid contention on the spinlock
+* by the herd.
+*/
+   if (RB_EMPTY_NODE(>node))
+   return;
+
+   spin_lock_irq(>lock);
+   __intel_engine_remove_wait(engine, wait);
spin_unlock_irq(>lock);
 }
 
@@ -506,11 +515,13 @@ static int intel_breadcrumbs_signaler(void *arg)
dma_fence_signal(>fence);
local_bh_enable(); /* kick start the tasklets */
 
+   spin_lock_irq(>lock);
+
/* Wake up all other completed waiters and select the
 * next bottom-half for the next user interrupt.
 */
-   intel_engine_remove_wait(engine,
->signaling.wait);
+   __intel_engine_remove_wait(engine,
+  >signaling.wait);
 
/* Find the next oldest signal. Note that as we have
 * not been holding the lock, another client may
@@ -518,7 +529,6 @@ static int intel_breadcrumbs_signaler(void *arg)
 * we just completed - so double check we are still
 * the oldest before picking the next one.
 */
-   spin_lock_irq(>lock);
if (request == rcu_access_pointer(b->first_signal)) {
struct rb_node *rb =
rb_next(>signaling.node);
@@ -526,6 +536,8 @@ static int intel_breadcrumbs_signaler(void *arg)
   rb ? to_signaler(rb) : NULL);
}
rb_erase(>signaling.node, >signals);
+   RB_CLEAR_NODE(>signaling.node);
+
spin_unlock_irq(>lock);
 
i915_gem_request_put(request);
@@ -613,6 +625,35 @@ void intel_engine_enable_signaling(struct 
drm_i915_gem_request *request)
wake_up_process(b->signaler);
 }
 
+void intel_engine_cancel_signaling(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   assert_spin_locked(>lock);
+   GEM_BUG_ON(!request->signaling.wait.seqno);
+
+   spin_lock(>lock);
+
+   if (!RB_EMPTY_NODE(>signaling.node)) {
+   if (request == rcu_access_pointer(b->first_signal)) {
+   struct rb_node *rb =
+   rb_next(>signaling.node);
+   rcu_assign_pointer(b->first_signal,
+   

[Intel-gfx] [PATCH v4 07/16] drm/i915: Deconstruct execute fence

[Chris Wilson]

On reflection, we are only using the execute fence as a waitqueue on the
global_seqno and not using it for dependency tracking between fences
(unlike the submit and dma fences). By only treating it as a waitqueue,
we can then treat it similar to the other waitqueues during submit,
making the code simpler.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 50 -
 drivers/gpu/drm/i915/i915_gem_request.h | 10 +--
 2 files changed, 13 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 88139dbf8fcc..477e8fc125ce 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -69,7 +69,6 @@ static void i915_fence_release(struct dma_fence *fence)
 * caught trying to reuse dead objects.
 */
i915_sw_fence_fini(>submit);
-   i915_sw_fence_fini(>execute);
 
kmem_cache_free(req->i915->requests, req);
 }
@@ -294,7 +293,6 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
-   GEM_BUG_ON(!i915_sw_fence_signaled(>execute));
GEM_BUG_ON(!i915_gem_request_completed(request));
GEM_BUG_ON(!request->i915->gt.active_requests);
 
@@ -402,6 +400,8 @@ void __i915_gem_request_submit(struct drm_i915_gem_request 
*request)
struct intel_timeline *timeline;
u32 seqno;
 
+   trace_i915_gem_request_execute(request);
+
/* Transfer from per-context onto the global per-engine timeline */
timeline = engine->timeline;
GEM_BUG_ON(timeline == request->timeline);
@@ -426,8 +426,7 @@ void __i915_gem_request_submit(struct drm_i915_gem_request 
*request)
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
 
-   i915_sw_fence_commit(>execute);
-   trace_i915_gem_request_execute(request);
+   wake_up_all(>execute);
 }
 
 void i915_gem_request_submit(struct drm_i915_gem_request *request)
@@ -463,24 +462,6 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
return NOTIFY_DONE;
 }
 
-static int __i915_sw_fence_call
-execute_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
-{
-   struct drm_i915_gem_request *request =
-   container_of(fence, typeof(*request), execute);
-
-   switch (state) {
-   case FENCE_COMPLETE:
-   break;
-
-   case FENCE_FREE:
-   i915_gem_request_put(request);
-   break;
-   }
-
-   return NOTIFY_DONE;
-}
-
 /**
  * i915_gem_request_alloc - allocate a request structure
  *
@@ -573,13 +554,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 
/* We bump the ref for the fence chain */
i915_sw_fence_init(_gem_request_get(req)->submit, submit_notify);
-   i915_sw_fence_init(_gem_request_get(req)->execute, execute_notify);
-
-   /* Ensure that the execute fence completes after the submit fence -
-* as we complete the execute fence from within the submit fence
-* callback, its completion would otherwise be visible first.
-*/
-   i915_sw_fence_await_sw_fence(>execute, >submit, >execq);
+   init_waitqueue_head(>execute);
 
i915_priotree_init(>priotree);
 
@@ -1032,6 +1007,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
wait_queue_head_t *errq = >i915->gpu_error.wait_queue;
DEFINE_WAIT(reset);
+   DEFINE_WAIT(exec);
struct intel_wait wait;
 
might_sleep();
@@ -1053,12 +1029,11 @@ long i915_wait_request(struct drm_i915_gem_request *req,
if (flags & I915_WAIT_LOCKED)
add_wait_queue(errq, );
 
-   if (!i915_sw_fence_done(>execute)) {
-   DEFINE_WAIT(exec);
-
+   reset_wait_queue(>execute, );
+   if (!req->global_seqno) {
do {
-   prepare_to_wait(>execute.wait, , state);
-   if (i915_sw_fence_done(>execute))
+   set_current_state(state);
+   if (req->global_seqno)
break;
 
if (flags & I915_WAIT_LOCKED &&
@@ -1081,15 +1056,14 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
timeout = io_schedule_timeout(timeout);
} while (1);
-   finish_wait(>execute.wait, );
+   finish_wait(>execute, );
 
if (timeout < 0)
goto complete;
 
-   GEM_BUG_ON(!i915_sw_fence_done(>execute));
+   GEM_BUG_ON(!req->global_seqno);
}
-   GEM_BUG_ON(!i915_sw_fence_done(>submit));
-   

[Intel-gfx] [PATCH v4 04/16] drm/i915: Use a local to shorten req->i915->gpu_error.wait_queue

[Chris Wilson]

Use a local variable to avoid having to type out the full name of the
gpu_error wait_queue.

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

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 31c454089c87..c1a1da3ee0d7 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1078,6 +1078,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 {
const int state = flags & I915_WAIT_INTERRUPTIBLE ?
TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
+   wait_queue_head_t *errq = >i915->gpu_error.wait_queue;
DEFINE_WAIT(reset);
struct intel_wait wait;
 
@@ -1113,7 +1114,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
set_current_state(state);
if (flags & I915_WAIT_LOCKED)
-   add_wait_queue(>i915->gpu_error.wait_queue, );
+   add_wait_queue(errq, );
 
intel_wait_init(, req->global_seqno);
if (intel_engine_add_wait(req->engine, ))
@@ -1164,8 +1165,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
i915_reset_in_progress(>i915->gpu_error)) {
__set_current_state(TASK_RUNNING);
i915_reset(req->i915);
-   reset_wait_queue(>i915->gpu_error.wait_queue,
-);
+   reset_wait_queue(errq, );
continue;
}
 
@@ -1176,7 +1176,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
intel_engine_remove_wait(req->engine, );
if (flags & I915_WAIT_LOCKED)
-   remove_wait_queue(>i915->gpu_error.wait_queue, );
+   remove_wait_queue(errq, );
__set_current_state(TASK_RUNNING);
 
 complete:
-- 
2.11.0

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

[Intel-gfx] [PATCH v4 09/16] drm/i915: Take a reference whilst processing the signaler request

[Chris Wilson]

The plan in the near-future is to allow requests to be removed from the
signaler. We can no longer then rely on holding a reference to the
request for the duration it is in the signaling tree, and instead must
obtain a reference to the request for the current operation using RCU.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 22 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index d5bf4c0b2deb..a35d59d00bfb 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -496,7 +496,11 @@ static int intel_breadcrumbs_signaler(void *arg)
 * need to wait for a new interrupt from the GPU or for
 * a new client.
 */
-   request = READ_ONCE(b->first_signal);
+   rcu_read_lock();
+   request = rcu_dereference(b->first_signal);
+   if (request)
+   request = i915_gem_request_get_rcu(request);
+   rcu_read_unlock();
if (signal_complete(request)) {
local_bh_disable();
dma_fence_signal(>fence);
@@ -515,24 +519,28 @@ static int intel_breadcrumbs_signaler(void *arg)
 * the oldest before picking the next one.
 */
spin_lock_irq(>lock);
-   if (request == b->first_signal) {
+   if (request == rcu_access_pointer(b->first_signal)) {
struct rb_node *rb =
rb_next(>signaling.node);
-   b->first_signal = rb ? to_signaler(rb) : NULL;
+   rcu_assign_pointer(b->first_signal,
+  rb ? to_signaler(rb) : NULL);
}
rb_erase(>signaling.node, >signals);
spin_unlock_irq(>lock);
 
i915_gem_request_put(request);
} else {
-   if (kthread_should_stop())
+   if (kthread_should_stop()) {
+   GEM_BUG_ON(request);
break;
+   }
 
schedule();
 
if (kthread_should_park())
kthread_parkme();
}
+   i915_gem_request_put(request);
} while (1);
__set_current_state(TASK_RUNNING);
 
@@ -597,7 +605,7 @@ void intel_engine_enable_signaling(struct 
drm_i915_gem_request *request)
rb_link_node(>signaling.node, parent, p);
rb_insert_color(>signaling.node, >signals);
if (first)
-   smp_store_mb(b->first_signal, request);
+   rcu_assign_pointer(b->first_signal, request);
 
spin_unlock(>lock);
 
@@ -670,7 +678,7 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs 
*engine)
/* The engines should be idle and all requests accounted for! */
WARN_ON(READ_ONCE(b->first_wait));
WARN_ON(!RB_EMPTY_ROOT(>waiters));
-   WARN_ON(READ_ONCE(b->first_signal));
+   WARN_ON(rcu_access_pointer(b->first_signal));
WARN_ON(!RB_EMPTY_ROOT(>signals));
 
if (!IS_ERR_OR_NULL(b->signaler))
@@ -691,7 +699,7 @@ bool intel_breadcrumbs_busy(struct intel_engine_cs *engine)
busy |= intel_engine_flag(engine);
}
 
-   if (b->first_signal) {
+   if (rcu_access_pointer(b->first_signal)) {
wake_up_process(b->signaler);
busy |= intel_engine_flag(engine);
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 04e7d5a9ee3a..fbf34af7bc77 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -242,7 +242,7 @@ struct intel_engine_cs {
struct rb_root signals; /* sorted by retirement */
struct intel_wait *first_wait; /* oldest waiter by retirement */
struct task_struct *signaler; /* used for fence signalling */
-   struct drm_i915_gem_request *first_signal;
+   struct drm_i915_gem_request __rcu *first_signal;
struct timer_list fake_irq; /* used after a missed interrupt */
struct timer_list hangcheck; /* detect missed interrupts */
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Don't sleep so much in basic hpd tests

[Chris Wilson]

On Wed, Feb 22, 2017 at 10:18:33PM -0500, Lyude wrote:
> Now that we can just disable HPD storm detection, there's no need to
> sleep between each hotplug cycle.
> 
> Signed-off-by: Lyude 
> ---
>  tests/chamelium.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/chamelium.c b/tests/chamelium.c
> index 849e1ac..810c955 100644
> --- a/tests/chamelium.c
> +++ b/tests/chamelium.c
> @@ -154,6 +154,7 @@ test_basic_hotplug(data_t *data, struct chamelium_port 
> *port)
>   int i;
>  
>   reset_state(data, port);
> + igt_hpd_storm_set_threshold(0);

You will want to check that you have the debugfs interface first and
skip the test otherwise. Or was there a fallback? Or is it already
checkd?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/4] drm/i915/glk: Fix watermark computations for third sprite plane

[Ander Conselvan de Oliveira]

Geminilake has a third sprite plane (or fourth universal plane) that is
independent from the cursor. Make sure that for_each_plane_id_on_crtc()
is aware of that extra plane so that the watermark code takes it into
account.

Fixes: e9c9882556fc ("drm/i915/glk: Configure number of sprite planes properly")
Cc: Ander Conselvan de Oliveira 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc: 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e346b2d..70892ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -293,6 +293,7 @@ enum plane_id {
PLANE_PRIMARY,
PLANE_SPRITE0,
PLANE_SPRITE1,
+   PLANE_SPRITE2,
PLANE_CURSOR,
I915_MAX_PLANES,
 };
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 0/4] GLK plane/scaling fixes

[Ander Conselvan de Oliveira]

Ander Conselvan de Oliveira (4):
  drm/i915/glk: Fix watermark computations for third sprite plane
  drm/i915/glk: Fix maximum scaling factor for Geminilake scalers
  drm/i915/glk: Pass dev_priv to intel_atomic_setup_scalers()
  drm/i915/glk: Fix Geminilake scalers mode programming

 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_atomic.c  | 14 --
 drivers/gpu/drm/i915/intel_display.c | 17 -
 drivers/gpu/drm/i915/intel_drv.h |  6 +++---
 4 files changed, 24 insertions(+), 14 deletions(-)

-- 
2.9.3

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

[Intel-gfx] [PATCH v2 3/4] drm/i915/glk: Pass dev_priv to intel_atomic_setup_scalers()

[Ander Conselvan de Oliveira]

Pass dev_priv to intel_atomic_setup_scalers(). The next patch will need
a dev_priv pointer.

Cc: Ville Syrjälä 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_atomic.c  | 10 +-
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index aa9160e..58916e3 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -121,7 +121,7 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
 
 /**
  * intel_atomic_setup_scalers() - setup scalers for crtc per staged requests
- * @dev: DRM device
+ * @dev_priv: i915 device
  * @crtc: intel crtc
  * @crtc_state: incoming crtc_state to validate and setup scalers
  *
@@ -136,9 +136,9 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
  * 0 - scalers were setup succesfully
  * error code - otherwise
  */
-int intel_atomic_setup_scalers(struct drm_device *dev,
-   struct intel_crtc *intel_crtc,
-   struct intel_crtc_state *crtc_state)
+int intel_atomic_setup_scalers(struct drm_i915_private *dev_priv,
+  struct intel_crtc *intel_crtc,
+  struct intel_crtc_state *crtc_state)
 {
struct drm_plane *plane = NULL;
struct intel_plane *intel_plane;
@@ -199,7 +199,7 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
 */
if (!plane) {
struct drm_plane_state *state;
-   plane = drm_plane_from_index(dev, i);
+   plane = drm_plane_from_index(_priv->drm, i);
state = drm_atomic_get_plane_state(drm_state, 
plane);
if (IS_ERR(state)) {
DRM_DEBUG_KMS("Failed to add [PLANE:%d] 
to drm_state\n",
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6b65adf..606fff5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10959,7 +10959,7 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
ret = skl_update_scaler_crtc(pipe_config);
 
if (!ret)
-   ret = intel_atomic_setup_scalers(dev, intel_crtc,
+   ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
 pipe_config);
}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0edc499..d9d96d6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1910,9 +1910,9 @@ intel_atomic_get_existing_plane_state(struct 
drm_atomic_state *state,
return to_intel_plane_state(plane_state);
 }
 
-int intel_atomic_setup_scalers(struct drm_device *dev,
-   struct intel_crtc *intel_crtc,
-   struct intel_crtc_state *crtc_state);
+int intel_atomic_setup_scalers(struct drm_i915_private *dev_priv,
+  struct intel_crtc *intel_crtc,
+  struct intel_crtc_state *crtc_state);
 
 /* intel_atomic_plane.c */
 struct intel_plane_state *intel_create_plane_state(struct drm_plane *plane);
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 4/4] drm/i915/glk: Fix Geminilake scalers mode programming

[Ander Conselvan de Oliveira]

Geminilake scalers can do 7x7 filtering for all supported input sizes,
so it doesn't need the "high quality" mode programming, which was
actually removed from that platform.

v2: Split dev_priv parameter change out. (Ville)
Cc: Ville Syrjälä ,
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_atomic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 58916e3..e65818e 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -247,7 +247,9 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
}
 
/* set scaler mode */
-   if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) {
+   if (IS_GEMINILAKE(dev_priv)) {
+   scaler_state->scalers[*scaler_id].mode = 0;
+   } else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
 * when only 1 scaler is in use on either pipe A or B,
 * scaler 0 operates in high quality (HQ) mode.
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 2/4] drm/i915/glk: Fix maximum scaling factor for Geminilake scalers

[Ander Conselvan de Oliveira]

Geminilake can output two pixels per clock, and that affects the maximum
scaling factor for its scalers. Take that into account and avoid the
following warning:

WARNING: CPU: 1 PID: 593 at drivers/gpu/drm/i915/intel_display.c:13223 
skl_max_scale.part.129+0x78/0x80 [i915]
WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
Modules linked in: x86_pkg_temp_thermal i915 coretemp kvm_intel kvm 
i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul prime_numbers 
crc32_pclmul drm ghash_clmulni_intel shpchp tpm_tis tpm_tis_core tpm nfsd authw
CPU: 1 PID: 593 Comm: kworker/u8:3 Tainted: GW   4.10.0-rc8ander+ 
#330
Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS 
GELKRVPA.X64.0035.B33.1702150552 02/15/2017
Workqueue: events_unbound async_run_entry_fn
Call Trace:
 dump_stack+0x86/0xc3
 __warn+0xcb/0xf0
 warn_slowpath_fmt+0x5f/0x80
 skl_max_scale.part.129+0x78/0x80 [i915]
 intel_check_primary_plane+0xa6/0xc0 [i915]
 intel_plane_atomic_check_with_state+0xd1/0x1a0 [i915]
 ? drm_printk+0xb5/0xc0 [drm]
 intel_plane_atomic_check+0x3d/0x80 [i915]
 drm_atomic_helper_check_planes+0x7c/0x200 [drm_kms_helper]
 intel_atomic_check+0xa5b/0x11a0 [i915]
 drm_atomic_check_only+0x353/0x600 [drm]
 ? drm_atomic_add_affected_connectors+0x10c/0x120 [drm]
 drm_atomic_commit+0x18/0x50 [drm]
 restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper]
 drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
 drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
 intel_fbdev_set_par+0x1a/0x70 [i915]
 fbcon_init+0x582/0x610
 visual_init+0xd6/0x130
 do_bind_con_driver+0x1da/0x3c0
 do_take_over_console+0x116/0x180
 do_fbcon_takeover+0x5c/0xb0
 fbcon_event_notify+0x772/0x8a0
 ? __blocking_notifier_call_chain+0x35/0x70
 notifier_call_chain+0x4a/0x70
 __blocking_notifier_call_chain+0x4d/0x70
 blocking_notifier_call_chain+0x16/0x20
 fb_notifier_call_chain+0x1b/0x20
 register_framebuffer+0x278/0x360
 drm_fb_helper_initial_config+0x253/0x440 [drm_kms_helper]
 intel_fbdev_initial_config+0x18/0x30 [i915]
 async_run_entry_fn+0x39/0x170
 process_one_work+0x212/0x670
 ? process_one_work+0x197/0x670
 worker_thread+0x4e/0x490
 kthread+0x101/0x140
 ? process_one_work+0x670/0x670
 ? kthread_create_on_node+0x60/0x60
 ret_from_fork+0x31/0x40

v2: s/max_pixclk/max_dotclk/ (Ville)
Cc: Rodrigo Vivi 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 957c62d..6b65adf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13211,16 +13211,22 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
 int
 skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
 {
+   struct drm_i915_private *dev_priv;
int max_scale;
-   int crtc_clock, cdclk;
+   int crtc_clock, max_dotclk;
 
if (!intel_crtc || !crtc_state->base.enable)
return DRM_PLANE_HELPER_NO_SCALING;
 
+   dev_priv = to_i915(intel_crtc->base.dev);
+
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
-   cdclk = 
to_intel_atomic_state(crtc_state->base.state)->cdclk.logical.cdclk;
+   max_dotclk = 
to_intel_atomic_state(crtc_state->base.state)->cdclk.logical.cdclk;
+
+   if (IS_GEMINILAKE(dev_priv))
+   max_dotclk *= 2;
 
-   if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
+   if (WARN_ON_ONCE(!crtc_clock || max_dotclk < crtc_clock))
return DRM_PLANE_HELPER_NO_SCALING;
 
/*
@@ -13229,7 +13235,8 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
intel_crtc_state *crtc_state
 *or
 *cdclk/crtc_clock
 */
-   max_scale = min((1 << 16) * 3 - 1, (1 << 8) * ((cdclk << 8) / 
crtc_clock));
+   max_scale = min((1 << 16) * 3 - 1,
+   (1 << 8) * ((max_dotclk << 8) / crtc_clock));
 
return max_scale;
 }
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915: enable scrambling

[Sharma, Shashank]

Regards

Shashank


On 2/22/2017 10:59 PM, Ville Syrjälä wrote:

On Wed, Feb 22, 2017 at 06:48:30PM +0530, Shashank Sharma wrote:

Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
   driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
   in intel_enable_ddi() before enabling the port.

V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
   so that the implementation could be close to the language of
   HDMI spec.

V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
   high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_reg.h   |   4 ++
  drivers/gpu/drm/i915/intel_ddi.c  |  28 ++
  drivers/gpu/drm/i915/intel_drv.h  |  14 +
  drivers/gpu/drm/i915/intel_hdmi.c | 108 ++
  4 files changed, 154 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 141a5c1..81cf10b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7819,7 +7819,11 @@ enum {
  #define  TRANS_DDI_EDP_INPUT_B_ONOFF  (5<<12)
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
+#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
+#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
  #define  TRANS_DDI_BFI_ENABLE (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
  
  /* DisplayPort Transport Control */

  #define _DP_TP_CTL_A  0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd6fedd..bd8293d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (IS_GEMINILAKE(dev_priv))
+   temp = intel_hdmi_handle_source_scrambling(
+   intel_encoder,
+   _crtc->config->base.adjusted_mode, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
@@ -1843,6 +1848,21 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
  
+		if (IS_GEMINILAKE(dev_priv)) {

+   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
+   /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by sink, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+   intel_hdmi_handle_sink_scrambling(intel_encoder,
+   conn_state->connector,
+   crtc->config, true);
+   }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
 * are ignored so nothing special needs to be done besides
 * enabling the port.
@@ -1875,6 +1895,14 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder,
if (old_crtc_state->has_audio)
intel_audio_codec_disable(intel_encoder);
  
+	if (type == INTEL_OUTPUT_HDMI) {

+   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+
+   intel_hdmi_handle_sink_scrambling(intel_encoder,
+   old_conn_state->connector,
+   intel_crtc->config, false);
+   }
+
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
  
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index 821c57c..c7262d7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -691,6 +691,12 @@ struct intel_crtc_state {
  
  	/* Gamma mode programmed on the pipe */

Re: [Intel-gfx] [PATCH] drm/i915: Perform link quality check unconditionally during long pulse

[Palmer Dabbelt]

On Thu, Feb 16, 2017 at 9:46 AM, Ville Syrjälä
 wrote:
> On Thu, Feb 16, 2017 at 09:24:09AM -0800, Manasi Navare wrote:
>> On Thu, Feb 16, 2017 at 07:18:57PM +0200, Ville Syrjälä wrote:
>> > On Thu, Feb 16, 2017 at 09:07:53AM -0800, Manasi Navare wrote:
>> > > On Thu, Feb 16, 2017 at 05:30:07PM +0200, ville.syrj...@linux.intel.com 
>> > > wrote:
>> > > > From: Ville Syrjälä 
>> > > >
>> > > > Apparently some DP sinks are a little nuts and cause HPD to drop
>> > > > intermittently during modesets. This happens eg. on an ASUS PB287Q.
>> > > > In oder to recover from this we can't really use the previous
>> > > > connector status to determine if the link needs retraining, so let's
>> > > > just ignore that piece of information and do the retrain
>> > > > unconditionally. We do of course still check whether the link is
>> > > > supposed to be running or not.
>> > > >
>> > > > Cc: sta...@vger.kernel.org
>> > > > Cc: Palmer Dabbelt 
>> > > > Reported-by: Palmer Dabbelt 
>> > > > References: 
>> > > > https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
>> > > > Signed-off-by: Ville Syrjälä 
>> > > > ---
>> > > >  drivers/gpu/drm/i915/intel_dp.c | 15 +++
>> > > >  1 file changed, 11 insertions(+), 4 deletions(-)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> > > > b/drivers/gpu/drm/i915/intel_dp.c
>> > > > index 024798a9c016..37a746f7fbc3 100644
>> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > > > @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
>> > > > *intel_connector)
>> > > >  */
>> > > > status = connector_status_disconnected;
>> > > > goto out;
>> > > > -   } else if (connector->status == connector_status_connected) {
>> > > > +   } else {
>> > > > /*
>> > > > -* If display was connected already and is still 
>> > > > connected
>> > > > -* check links status, there has been known issues of
>> > > > -* link loss triggerring long pulse
>> > > > +* If display is now connected check links status,
>> > > > +* there has been known issues of link loss triggerring
>> > > > +* long pulse.
>> > > > +*
>> > > > +* Some sinks (eg. ASUS PB287Q) seem to perform some
>> > > > +* weird HPD ping pong during modesets. So we can 
>> > > > apparely
>> > > > +* end up with HPD going low during a modeset, and then
>> > > > +* going back up soon after. And once that happens we 
>> > > > must
>> > > > +* retrain the link to get a picture. That's in case no
>> > > > +* userspace component reacted to intermittent HPD dip.
>> > > >  */
>> > > > drm_modeset_lock(>mode_config.connection_mutex, 
>> > > > NULL);
>> > > > intel_dp_check_link_status(intel_dp);
>> > > > --
>> > >
>> > > So here we basically just ignore the connector status and retrain 
>> > > irrespectively.
>> >
>> > We ignore the _previous_ connector status.
>> >
>> > > But that means even if we have newer values now for max link rate/lane 
>> > > count from
>> > > DPCD, during this retrain we are just using the stale value of 
>> > > intel_dp->link_rate
>> > > and intel_dp->lane_count. I think intel_dp->link_rate and lane count 
>> > > values
>> > > should be set to 0 on HPD pulse, they would be set only during a modeset.
>> >
>> > The DPCD has already been parsed by this time.
>> >
>> > --
>> > Ville Syrjälä
>> > Intel OTC
>>
>> Yes, we have parsed the DPCD but we dont write to intel_dp->link-rate and 
>> intel_dp->lane_count
>> until we do a modeset (these get written during pre_enable) and these values 
>> get used
>> during the retraining of the link. So at this point we will still use stale 
>> values.
>
> They're not stale. They're exactly what we used when we set up the
> mode that's still being drive out. This is just retraining the link
> at the same parameters.
>
>> Shouldnt we set the link status to BAD and send a hotplug event, like the 
>> solution we implemneted
>> for retraining?
>>
>> Regards
>> Manasi
>>
>> Regards
>> Manasi
>
> --
> Ville Syrjälä
> Intel OTC

Sorry, I forgot about this.  A log is attached of my machine booting
with the monitor attached, me detaching the monitor, and then plugging
it back in.


log.gz
Description: GNU Zip compressed data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 4/6] drm: scrambling support in drm layer

[Sharma, Shashank]

Regards

Shashank


On 2/22/2017 10:54 PM, Ville Syrjälä wrote:

On Wed, Feb 22, 2017 at 06:48:29PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.

This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.

V2: Addressed review comments from Thierry, Ville and Dhinakaran
Thierry:
- Mhz -> MHz in comments and commit message.
- i2c -> I2C in comments.
- Fix the function documentations, keep in sync with drm_scdc_helper.c
- drm_connector -> DRM connector.
- Create structure for SCDC, and save scrambling status inside that,
   in a sub-structure.
- Call this sub-structure scrambling instead of scr_info.
- low_rates -> low_clocks in scrambling status structure.
- Store the return value of I2C read/write and print the error code
   in case of failure.

Thierry and Ville:
- Move the scrambling enable/disable/query functions in
   drm_scdc_helper.c file.
- Add drm_SCDC prefix for the functions.
- Optimize the return statement from function
   drm_SCDC_check_scrambling_status.

Ville:
- Dont overwrite saved max TMDS clock value in display_info,
   if max tmds clock from HF-VSDB is not > 340 MHz.
- drm_detect_hdmi_scrambling -> drm_parse_hdmi_forum_vsdb.
- Remove dynamic tracking of SCDC status from DRM layer, force bool.
- Program clock ratio bit also, while enabling scrambling.

Dhinakaran:
- Add a comment about *5000 while extracting max clock supported.

V3: Addressed review comments from Jose.
- Create separate functions to enable scrambling and to set TMDS
   clock/character rate ratio.

V4: Rebase

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c|  33 +++-
  drivers/gpu/drm/drm_scdc_helper.c | 164 ++
  include/drm/drm_connector.h   |  19 +
  include/drm/drm_edid.h|   6 +-
  include/drm/drm_scdc_helper.h |  41 ++
  5 files changed, 261 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 63b79be..1e18c0a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "drm_crtc_internal.h"
  
@@ -3811,13 +3812,43 @@ enum hdmi_quantization_range

  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
  {
-   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+   struct drm_display_info *display = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
  
  	if (hf_vsdb[6] & 0x80) {

hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
hdmi->scdc.read_request = true;
}
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
+* * SCDC support available (let's check)
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   /* max clock is 5000 KHz times block value */
+   u32 max_tmds_clock = hf_vsdb[5] * 5000;
+   struct drm_scdc *scdc = >scdc;
+
+   if (max_tmds_clock > 34) {
+   display->max_tmds_clock = max_tmds_clock;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+   }
+
+   if (scdc->supported) {
+   scdc->scrambling.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   scdc->scrambling.low_rates = true;
+   }
+   }
  }
  
  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index fe0e121..c0cf82b 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
   */
  
  #include 

+#include 
  
  #include 

+#include 
  
  /**

   * DOC: scdc helpers
@@ -109,3 +111,165 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
offset,
return err;
  }
  EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambling status.
+ *
+ * Returns:
+ * True if 

Re: [Intel-gfx] [PATCH v4 1/6] drm: Add SCDC helpers

[Sharma, Shashank]

Thanks for the review Ville, my comments inline.

Regards

Shashank


On 2/22/2017 10:39 PM, Ville Syrjälä wrote:

On Wed, Feb 22, 2017 at 06:48:26PM +0530, Shashank Sharma wrote:

From: Thierry Reding 

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase

Signed-off-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
Reviewed-by: Jose Abreu 
---
  Documentation/gpu/drm-kms-helpers.rst |  12 
  drivers/gpu/drm/Makefile  |   3 +-
  drivers/gpu/drm/drm_scdc_helper.c | 111 
  include/drm/drm_scdc_helper.h | 132 ++
  4 files changed, 257 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
  create mode 100644 include/drm/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
  .. kernel-doc:: drivers/gpu/drm/drm_edid.c
 :export:
  
+SCDC Helper Functions Reference

+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :export:
+
  Rectangle Utilities Reference
  =
  
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile

index 92de399..ad91cd9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
-   drm_simple_kms_helper.o drm_modeset_helper.o
+   drm_simple_kms_helper.o drm_modeset_helper.o \
+   drm_scdc_helper.o
  
  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o

  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..fe0e121
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+#include 
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * The number of bytes read from SCDC or a negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t size)
+{
+   struct i2c_msg msgs[2] = {
+   {
+   .addr = SCDC_I2C_SLAVE_ADDRESS,
+   .flags = 0,
+  

[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_debugfs: Add functions/tests for controlling/testing HPD storm logic

[Lyude]

Recently we added i915_hpd_storm_ctl into i915's debugfs directory,
which allows us to control the thresholds i915 uses for detecting
hotplug interrupt storms from userspace, along with the ability to
entirely disable them. This adds some helper functions into IGT to
enable making use of this feature, along with adding some chamelium
tests for it.

Signed-off-by: Lyude 
---
 lib/igt_debugfs.c | 111 ++
 lib/igt_debugfs.h |   5 +++
 tests/chamelium.c |  61 ++
 3 files changed, 177 insertions(+)

diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 982573d..e64d001 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -463,6 +463,117 @@ void igt_require_pipe_crc(void)
fclose(ctl);
 }
 
+/**
+ * igt_hpd_storm_set_threshold:
+ * @threshold: How many hotplugs per second required to trigger an HPD storm,
+ * or 0 to disable storm detection.
+ *
+ * Convienence helper to configure the HPD storm detection threshold for i915
+ * through debugfs. Useful for hotplugging tests where HPD storm detection
+ * might get in the way and slow things down.
+ *
+ * If the system does not support HPD storm detection, this function does
+ * nothing.
+ *
+ * See: https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html#hotplug
+ */
+void igt_hpd_storm_set_threshold(unsigned int threshold)
+{
+   int fd = igt_debugfs_open("i915_hpd_storm_ctl", O_WRONLY);
+   char buf[16];
+
+   if (fd < 0)
+   return;
+
+   igt_debug("Setting HPD storm threshold to %d\n", threshold);
+   snprintf(buf, sizeof(buf), "%d", threshold);
+   igt_assert_eq(write(fd, buf, strlen(buf)), strlen(buf));
+
+   close(fd);
+   igt_install_exit_handler((igt_exit_handler_t)igt_hpd_storm_reset);
+}
+
+/**
+ * igt_hpd_storm_reset:
+ *
+ * Convienence helper to reset HPD storm detection to it's default settings.
+ * If hotplug detection was disabled on any ports due to an HPD storm, it will
+ * be immediately re-enabled. Always called on exit if the HPD storm detection
+ * threshold was modified during any tests.
+ *
+ * If the system does not support HPD storm detection, this function does
+ * nothing.
+ *
+ * See: https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html#hotplug
+ */
+void igt_hpd_storm_reset(void)
+{
+   int fd = igt_debugfs_open("i915_hpd_storm_ctl", O_WRONLY);
+   const char *buf = "reset";
+
+   if (fd < 0)
+   return;
+
+   igt_debug("Resetting HPD storm threshold\n");
+   igt_assert_eq(write(fd, buf, strlen(buf)), strlen(buf));
+
+   close(fd);
+}
+
+/**
+ * igt_hpd_storm_detected:
+ *
+ * Checks whether or not i915 has detected an HPD interrupt storm on any of the
+ * system's ports.
+ *
+ * This function always returns false on systems that do not support HPD storm
+ * detection.
+ *
+ * See: https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html#hotplug
+ *
+ * Returns: Whether or not an HPD storm has been detected.
+ */
+bool igt_hpd_storm_detected(void)
+{
+   int fd = igt_debugfs_open("i915_hpd_storm_ctl", O_RDONLY);
+   char *start_loc;
+   char buf[32] = {0}, detected_str[4];
+   bool ret;
+
+   if (fd < 0)
+   return false;
+
+   igt_assert_lt(0, read(fd, buf, sizeof(buf)));
+   igt_assert(start_loc = strstr(buf, "Detected: "));
+   igt_assert_eq(sscanf(start_loc, "Detected: %s\n", detected_str), 1);
+
+   if (strcmp(detected_str, "yes") == 0)
+   ret = true;
+   else if (strcmp(detected_str, "no") == 0)
+   ret = false;
+   else
+   igt_fail_on_f(true, "Unknown hpd storm detection status '%s'\n",
+ detected_str);
+
+   close(fd);
+   return ret;
+}
+
+/**
+ * igt_require_hpd_storm_ctl:
+ *
+ * Skips the current test if the system does not have HPD storm detection.
+ *
+ * See: https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html#hotplug
+ */
+void igt_require_hpd_storm_ctl(void)
+{
+   int fd = igt_debugfs_open("i915_hpd_storm_ctl", O_RDONLY);
+
+   igt_require_f(fd > 0, "No i915_hpd_storm_ctl found in debugfs\n");
+   close(fd);
+}
+
 static igt_pipe_crc_t *
 pipe_crc_new(enum pipe pipe, enum intel_pipe_crc_source source, int flags)
 {
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index 86c25dd..5587ad4 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -129,6 +129,11 @@ int igt_pipe_crc_get_crcs(igt_pipe_crc_t *pipe_crc, int 
n_crcs,
  igt_crc_t **out_crcs);
 void igt_pipe_crc_collect_crc(igt_pipe_crc_t *pipe_crc, igt_crc_t *out_crc);
 
+void igt_hpd_storm_set_threshold(unsigned int threshold);
+void igt_hpd_storm_reset(void);
+bool igt_hpd_storm_detected(void);
+void igt_require_hpd_storm_ctl(void);
+
 /*
  * Drop caches
  */
diff --git a/tests/chamelium.c b/tests/chamelium.c
index f340279..849e1ac 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -44,6 

[Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Don't sleep so much in basic hpd tests

[Lyude]

Now that we can just disable HPD storm detection, there's no need to
sleep between each hotplug cycle.

Signed-off-by: Lyude 
---
 tests/chamelium.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tests/chamelium.c b/tests/chamelium.c
index 849e1ac..810c955 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -154,6 +154,7 @@ test_basic_hotplug(data_t *data, struct chamelium_port 
*port)
int i;
 
reset_state(data, port);
+   igt_hpd_storm_set_threshold(0);
 
for (i = 0; i < 15; i++) {
igt_flush_hotplugs(mon);
@@ -171,12 +172,10 @@ test_basic_hotplug(data_t *data, struct chamelium_port 
*port)
igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
igt_assert_eq(reprobe_connector(data, port),
  DRM_MODE_DISCONNECTED);
-
-   /* Sleep so we don't accidentally cause an hpd storm */
-   usleep(500 * 1000);
}
 
igt_cleanup_hotplug(mon);
+   igt_hpd_storm_reset();
 }
 
 static void
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH i-g-t v2] igt/drv_hangman: Fix clear_error_state

[Michel Thierry]

On 22/02/17 18:31, Michel Thierry wrote:

v2: Use new igt_sysfs_write, add len > 0 assert in igt_sysfs_set to
catch future errors, clean-up strcasecmp logic (Chris).


Nevermind, didn't see you were faster than me...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2] igt/drv_hangman: Fix clear_error_state

[Michel Thierry]

clear_error_state was not doing anything (igt_sysfs_set was not writing to
the error file because strlen was 0).

Also fix assert_entry to catch this issue; strcasecmp returns 0 when
there's a match, or an integer in a mismatch.

v2: Use new igt_sysfs_write, add len > 0 assert in igt_sysfs_set to
catch future errors, clean-up strcasecmp logic (Chris).

Cc: Chris Wilson 
Fixes: 79c6a84ca85b ("igt/drv_hangman: Migrate to sysfs")
Signed-off-by: Michel Thierry 
---
 lib/igt_sysfs.c | 26 ++
 lib/igt_sysfs.h |  1 +
 tests/drv_hangman.c |  4 ++--
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/lib/igt_sysfs.c b/lib/igt_sysfs.c
index ded10a67..d244d9b6 100644
--- a/lib/igt_sysfs.c
+++ b/lib/igt_sysfs.c
@@ -172,6 +172,31 @@ int igt_sysfs_open_parameters(int device)
 
return params;
 }
+
+/**
+ * igt_sysfs_write:
+ * @dir: directory for the device from igt_sysfs_open()
+ * @attr: name of the sysfs node to open
+ *
+ * This writes a single byte to the sysfs file.
+ *
+ * Returns:
+ * True on success, false on failure.
+ */
+bool igt_sysfs_write(int dir, const char *attr)
+{
+   int fd, ret;
+
+   fd = openat(dir, attr, O_WRONLY);
+   if (fd < 0)
+   return false;
+
+   ret = write(fd, "\0", 1);
+   close(fd);
+
+   return ret;
+}
+
 /**
  * igt_sysfs_set:
  * @dir: directory for the device from igt_sysfs_open()
@@ -192,6 +217,7 @@ bool igt_sysfs_set(int dir, const char *attr, const char 
*value)
return false;
 
len = strlen(value);
+   igt_assert(len > 0);
ret = writeN(fd, value, len);
close(fd);
 
diff --git a/lib/igt_sysfs.h b/lib/igt_sysfs.h
index 69b2e5ec..145a9be6 100644
--- a/lib/igt_sysfs.h
+++ b/lib/igt_sysfs.h
@@ -29,6 +29,7 @@
 
 int igt_sysfs_open(int device, int *idx);
 int igt_sysfs_open_parameters(int device);
+bool igt_sysfs_write(int dir, const char *attr);
 bool igt_sysfs_set(int dir, const char *attr, const char *value);
 char *igt_sysfs_get(int dir, const char *attr);
 
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index cafdf4c1..df9c763f 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -58,7 +58,7 @@ static void assert_entry(const char *s, bool expect)
error = igt_sysfs_get(sysfs, "error");
igt_assert(error);
 
-   igt_assert_f(strcasecmp(error, s) != expect,
+   igt_assert_f(!!strcasecmp(error, s) != expect,
 "contents of error: '%s' (expected %s '%s')\n",
 error, expect ? "": "not", s);
 
@@ -77,7 +77,7 @@ static void assert_error_state_collected(void)
 
 static void clear_error_state(void)
 {
-   igt_sysfs_set(sysfs, "error", "");
+   igt_sysfs_write(sysfs, "error");
 }
 
 static void test_error_state_basic(void)
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

[Michel Thierry]

On 22/02/17 18:04, Chris Wilson wrote:

On Thu, Feb 23, 2017 at 01:52:04AM +, Chris Wilson wrote:

On Wed, Feb 22, 2017 at 05:26:29PM -0800, Michel Thierry wrote:

 static void clear_error_state(void)
 {
-   igt_sysfs_set(sysfs, "error", "");
+   igt_sysfs_set(sysfs, "error", " ");


My bad, I was expecting it write the nul character. "\0" would be my
preference


Still needs an explicit igt_sysfs_write() to avoid strlen.
-Chris



Yes, strlen(\0) is 0, which at the end is write(x, 0) and ignored.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

[Chris Wilson]

On Thu, Feb 23, 2017 at 01:52:04AM +, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 05:26:29PM -0800, Michel Thierry wrote:
> >  static void clear_error_state(void)
> >  {
> > -   igt_sysfs_set(sysfs, "error", "");
> > +   igt_sysfs_set(sysfs, "error", " ");
> 
> My bad, I was expecting it write the nul character. "\0" would be my
> preference

Still needs an explicit igt_sysfs_write() to avoid strlen.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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/guc: fix mmio whitelist mmio_start offset and add reminder (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder 
(rev2)
URL   : https://patchwork.freedesktop.org/series/17287/
State : success

== Summary ==

Series 17287v2 drm/i915/guc: fix mmio whitelist mmio_start offset and add 
reminder
https://patchwork.freedesktop.org/api/1.0/series/17287/revisions/2/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 
fi-byt-n2820 failed to collect. IGT log at Patchwork_3940/fi-byt-n2820/igt.log

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
fceb0c7 drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3940/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

[Chris Wilson]

On Wed, Feb 22, 2017 at 05:26:29PM -0800, Michel Thierry wrote:
> clear_error_state was not doing anything (igt_sysfs_set was not writing to
> the error file).
> 
> Also fix assert_entry to catch this issue; strcasecmp returns 0 when
> there's a match, or an integer in a mismatch.
> 
> Finally, only print part of the error string when the assert fails.
> 
> Cc: Chris Wilson 
> Fixes: 79c6a84ca85b ("igt/drv_hangman: Migrate to sysfs")
> Signed-off-by: Michel Thierry 
> ---
>  tests/drv_hangman.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
> index cafdf4c1..43f73661 100644
> --- a/tests/drv_hangman.c
> +++ b/tests/drv_hangman.c
> @@ -58,9 +58,15 @@ static void assert_entry(const char *s, bool expect)
>   error = igt_sysfs_get(sysfs, "error");
>   igt_assert(error);
>  
> - igt_assert_f(strcasecmp(error, s) != expect,
!!strcasecmp != expect
or (bool)strcasecmp != expect, type promotion working in the opposite
direction.

> -  "contents of error: '%s' (expected %s '%s')\n",
> -  error, expect ? "": "not", s);
> + if (expect) {
> + igt_assert_f(strcasecmp(error, s) == 0,
> +  "contents of error: '%.24s' (expected %s '%s')\n",
> +  error, expect ? "": "not", s);

Keep the full error state, it can be very informative. 24 characters
isn't enough to determine what.

> + } else {
> + igt_assert_f(strcasecmp(error, s) != 0,
> +  "contents of error: '%.24s' (expected %s '%s')\n",
> +  error, expect ? "": "not", s);
> + }
>  
>   free(error);
>  }
> @@ -77,7 +83,7 @@ static void assert_error_state_collected(void)
>  
>  static void clear_error_state(void)
>  {
> - igt_sysfs_set(sysfs, "error", "");
> + igt_sysfs_set(sysfs, "error", " ");

My bad, I was expecting it write the nul character. "\0" would be my
preference
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

[Michel Thierry]

clear_error_state was not doing anything (igt_sysfs_set was not writing to
the error file).

Also fix assert_entry to catch this issue; strcasecmp returns 0 when
there's a match, or an integer in a mismatch.

Finally, only print part of the error string when the assert fails.

Cc: Chris Wilson 
Fixes: 79c6a84ca85b ("igt/drv_hangman: Migrate to sysfs")
Signed-off-by: Michel Thierry 
---
 tests/drv_hangman.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index cafdf4c1..43f73661 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -58,9 +58,15 @@ static void assert_entry(const char *s, bool expect)
error = igt_sysfs_get(sysfs, "error");
igt_assert(error);
 
-   igt_assert_f(strcasecmp(error, s) != expect,
-"contents of error: '%s' (expected %s '%s')\n",
-error, expect ? "": "not", s);
+   if (expect) {
+   igt_assert_f(strcasecmp(error, s) == 0,
+"contents of error: '%.24s' (expected %s '%s')\n",
+error, expect ? "": "not", s);
+   } else {
+   igt_assert_f(strcasecmp(error, s) != 0,
+"contents of error: '%.24s' (expected %s '%s')\n",
+error, expect ? "": "not", s);
+   }
 
free(error);
 }
@@ -77,7 +83,7 @@ static void assert_error_state_collected(void)
 
 static void clear_error_state(void)
 {
-   igt_sysfs_set(sysfs, "error", "");
+   igt_sysfs_set(sysfs, "error", " ");
 }
 
 static void test_error_state_basic(void)
-- 
2.11.0

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

[Intel-gfx] [PATCH v2] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

[Daniele Ceraolo Spurio]

The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV
register the GuC can use to restore the provided whitelist when an
engine reset via GuC (which we still don't support) is triggered.

We're currently adding the mmio_base of the engine to the absolute
address of the RCS version of the register, which results in the wrong
offset. Fix it by using the definition we already have instead of
re-defining it in the GuC FW header.

Also add a comment to avoid future issues with FORCE_TO_NONPRIV
registers, which are also used by the workaround framework.

v2: improve comment (Michal), move comment about save/restore because it
is not related to the mmio_white_list field.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 11 +--
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 -
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index beec88a..c689fe5 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -852,10 +852,17 @@ static void guc_addon_create(struct intel_guc *guc)
 
for_each_engine(engine, dev_priv, id) {
reg_state->mmio_white_list[engine->guc_id].mmio_start =
-   engine->mmio_base + GUC_MMIO_WHITE_LIST_START;
+   
i915_mmio_reg_offset(RING_FORCE_TO_NONPRIV(engine->mmio_base, 0));
 
-   /* Nothing to be saved or restored for now. */
+   /*
+* Note: if the GuC whitelist management is enabled, the values
+* should be filled using the workaround framework to avoid
+* inconsistencies with the handling of FORCE_TO_NONPRIV
+* registers.
+*/
reg_state->mmio_white_list[engine->guc_id].count = 0;
+
+   /* Nothing to be saved or restored for now. */
}
 
ads->reg_state_addr = ads->scheduler_policies +
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 25691f0..da7dcac 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -386,7 +386,6 @@ struct guc_policies {
 #define GUC_REGSET_SAVE_CURRENT_VALUE  0x10
 
 #define GUC_REGSET_MAX_REGISTERS   25
-#define GUC_MMIO_WHITE_LIST_START  0x24d0
 #define GUC_MMIO_WHITE_LIST_MAX12
 #define GUC_S3_SAVE_SPACE_PAGES10
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both in skl_pcode_try_request()

[Li, Weinan Z]

Thanks Imre. I see, it's a little hard to read, need to check the final state 
across 2 level function return value.

Thanks.
Best Regards.
Weinan, LI


> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, February 22, 2017 4:56 PM
> To: Li, Weinan Z 
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both
> in skl_pcode_try_request()
> 
> On Wed, Feb 22, 2017 at 10:17:21AM +0200, Li, Weinan Z wrote:
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Wednesday, February 22, 2017 3:54 PM
> > > To: Li, Weinan Z 
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > intel-gvt-...@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: check status and reply
> > > value both in skl_pcode_try_request()
> > >
> > > On Wed, Feb 22, 2017 at 10:25:44AM +0800, Weinan Li wrote:
> > > > skl_pcode_try_request() call sandybridge_pcode_read(), check both
> > > > return status and value simultanously, ensure it got correct value
> > > > without
> > > error.
> > > >
> > > > Signed-off-by: Weinan Li 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c index ae2c0bb..e7b12ec 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -7882,7 +7882,7 @@ static bool skl_pcode_try_request(struct
> > > > drm_i915_private *dev_priv, u32 mbox,
> > > >
> > > > *status = sandybridge_pcode_read(dev_priv, mbox, );
> > > >
> > > > -   return *status || ((val & reply_mask) == reply);
> > *status == 0 means success, otherwise error happened.
> 
> Yes.
> 
> > > > +   return (!*status) && ((val & reply_mask) == reply);
> > > >  }
> > >
> > > The original looks ok to me. The condition becomes true if PCODE
> > > reports an error in *status or we get the expected reply. *status is
> > > then rechecked in skl_pcode_request().
> > int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> request,
> >   u32 reply_mask, u32 reply, int timeout_base_ms) {
> > u32 status;
> > int ret;
> >
> > WARN_ON(!mutex_is_locked(_priv->rps.hw_lock));
> >
> > #define COND skl_pcode_try_request(dev_priv, mbox, request,
> reply_mask, reply, \
> >)
> >
> > /*
> >  * Prime the PCODE by doing a request first. Normally it guarantees
> >  * that a subsequent request, at most @timeout_base_ms later,
> succeeds.
> >  * _wait_for() doesn't guarantee when its passed condition is
> evaluated
> >  * first, so send the first request explicitly.
> >  */
> > if (COND) {##here will deal as success although pcode_read() get
> error happened.
> > Is this expected behavior?##
> 
> It's not regarded as success, it's regarded as a condition to end the polling.
> That is either a PCODE error returned in status or the expected reply
> received (matching reply_mask/reply). status is rechecked at the end of the
> function.
> 
> --Imre
> 
> > ret = 0;
> > goto out;
> > }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove Braswell GGTT update w/a

[Chris Wilson]

On Wed, Feb 22, 2017 at 06:02:46PM +, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 11:39:30AM +, Chris Wilson wrote:
> > On Wed, Feb 22, 2017 at 01:27:41PM +0200, Joonas Lahtinen wrote:
> > > On ma, 2017-02-20 at 12:47 +, Chris Wilson wrote:
> > > > Testing with concurrent GGTT accesses no longer show the coherency
> > > > problems from yonder, commit 5bab6f60cb4d ("drm/i915: Serialise updates
> > > > to GGTT with access through GGTT on Braswell"). My presumption is that
> > > > the root cause was more likely fixed by commit 3b5724d702ef ("drm/i915:
> > > > Wait for writes through the GTT to land before reading back"), along
> > > > with the use of WC updates to the global gTT in commit 8448661d65f6
> > > > ("drm/i915: Convert clflushed pagetables over to WC maps". Given
> > > > that the original symptoms can no longer be reproduced, time to remove
> > > > the workaround.
> > > > 
> > > > Testcase: igt/gem_concurrenct_blit
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Daniel Vetter 
> > > 
> > > Makes one think if the original fix has been appropriate, when adding
> > > stop_machine for a software bug :P
> > 
> > Depends if you consider the months of hair pulling trying to find where
> > the flush/stall was missing. It was a desperate patch to fix an annoying
> > corruption issue - and since it seems that we now just avoid the
> > dangerous path by taking a different route through hw, I don't think
> > it is was wholly a sw bug.
> 
> Bah, after a few days of continuous testing, I've hit a workload that
> shows the bug again. (Small numbers of large GTT objects, rather than
> large number of small GTT objects.)

Hmm, and it also died with the w/a with nigh on identical symptoms. And
appears quite tempermental. Uncertainity is prevailing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/: DMC 1.04 for Geminilake

[Patchwork]

== Series Details ==

Series: drm/i915/: DMC 1.04 for Geminilake
URL   : https://patchwork.freedesktop.org/series/20091/
State : warning

== Summary ==

Series 20091v1 drm/i915/: DMC 1.04 for Geminilake
https://patchwork.freedesktop.org/api/1.0/series/20091/revisions/1/mbox/

Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> DMESG-WARN (fi-byt-n2820)

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:221  dwarn:1   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
9708322 drm/i915/: DMC 1.04 for Geminilake

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3939/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-02-22 at 09:59 +0530, Archit Taneja wrote:
> 
> On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> >>
> >> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> >>> On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
>  Hi,
> 
>  On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
> > It is necessary to track states for objects other than connector, crtc
> > and plane for atomic modesets. But adding objects like DP MST link
> > bandwidth to drm_atomic_state would mean that a non-core object will be
> > modified by the core helper functions for swapping and clearing
> > it's state. So, lets add void * objects and helper functions that 
> > operate
> > on void * types to keep these objects and states private to the core.
> > Drivers can then implement specific functions to swap and clear states.
> > The other advantage having just void * for these objects in
> > drm_atomic_state is that objects of different types can be managed in 
> > the
> > same state array.
> >
> > v2: Added docs and new iterator to filter private objects (Daniel)
> >
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 68 +++
> >  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
> >  include/drm/drm_atomic.h| 91 
> > +
> >  3 files changed, 164 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index a567310..1a9ffe8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> > drm_atomic_state *state)
> > kfree(state->connectors);
> > kfree(state->crtcs);
> > kfree(state->planes);
> > +   kfree(state->private_objs);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >
> > @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> > drm_atomic_state *state)
> > state->planes[i].ptr = NULL;
> > state->planes[i].state = NULL;
> > }
> > +
> > +   for (i = 0; i < state->num_private_objs; i++) {
> > +   void *private_obj = state->private_objs[i].obj;
> > +   void *obj_state = state->private_objs[i].obj_state;
> > +
> > +   if (!private_obj)
> > +   continue;
> > +
> > +   state->private_objs[i].funcs->destroy_state(obj_state);
> > +   state->private_objs[i].obj = NULL;
> > +   state->private_objs[i].obj_state = NULL;
> > +   state->private_objs[i].funcs = NULL;
> > +   }
> > +
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >
> > @@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
> > drm_printer *p,
> >  }
> >
> >  /**
> > + * drm_atomic_get_private_obj_state - get private object state
> > + * @state: global atomic state
> > + * @obj: private object to get the state for
> > + * @funcs: pointer to the struct of function pointers that identify 
> > the object
> > + * type
> > + *
> > + * This function returns the private object state for the given 
> > private object,
> > + * allocating the state if needed. It does not grab any locks as the 
> > caller is
> > + * expected to care of any required locking.
> > + *
> > + * RETURNS:
> > + *
> > + * Either the allocated state or the error code encoded into a pointer.
> > + */
> > +void *
> > +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void 
> > *obj,
> > + const struct drm_private_state_funcs 
> > *funcs)
> > +{
> > +   int index, num_objs, i;
> > +   size_t size;
> > +   struct __drm_private_objs_state *arr;
> > +
> > +   for (i = 0; i < state->num_private_objs; i++)
> > +   if (obj == state->private_objs[i].obj &&
> > +   state->private_objs[i].obj_state)
> > +   return state->private_objs[i].obj_state;
> 
>  Comparing this func to 
>  drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
>  doesn't seem to call drm_modeset_lock if the obj_state doesn't already 
>  exist. I
>  don't understand the locking stuff toowell, I just noticed this 
>  difference when
>  comparing this approach with what is done in the msm kms driver (where we
>  have subclassed drm_atomic_state to msm_kms_state).
> 
>  Thanks,
>  Archit
> 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,01/15] drm/i915: Keep a global seqno per-engine (rev2)

[Chris Wilson]

On Wed, Feb 22, 2017 at 08:52:45PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,01/15] drm/i915: Keep a global seqno 
> per-engine (rev2)
> URL   : https://patchwork.freedesktop.org/series/20056/
> State : warning
> 
> == Summary ==
> 
> Series 20056v2 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20056/revisions/2/mbox/
> 
> Test gem_exec_parallel:
> Subgroup basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)
> pass   -> DMESG-WARN (fi-skl-6260u)
> pass   -> DMESG-WARN (fi-skl-6700k)
> pass   -> DMESG-WARN (fi-kbl-7500u)
> pass   -> DMESG-WARN (fi-bxt-j4205)
> pass   -> DMESG-WARN (fi-bdw-5557u)

Uh oh, the series is not bisect clean.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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 [v2,01/15] drm/i915: Keep a global seqno per-engine (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/15] drm/i915: Keep a global seqno 
per-engine (rev2)
URL   : https://patchwork.freedesktop.org/series/20056/
State : warning

== Summary ==

Series 20056v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20056/revisions/2/mbox/

Test gem_exec_parallel:
Subgroup basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-bdw-5557u)
Test gem_ringfill:
Subgroup basic-default-interruptible:
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-snb-2600)
Test gem_sync:
Subgroup basic-many-each:
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-skl-6700k)
Subgroup basic-store-all:
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-bdw-5557u)
Test gem_wait:
Subgroup basic-await-all:
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-snb-2600)
Subgroup basic-wait-all:
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-snb-2600)

fi-bdw-5557u total:253  pass:237  dwarn:5   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:212  dwarn:2   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:229  dwarn:5   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:224  dwarn:2   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:220  dwarn:2   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:234  dwarn:3   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:234  dwarn:3   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:201  dwarn:2   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:232  dwarn:3   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:230  

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Check against the signaled bit for fences/requests (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Check against the signaled bit for fences/requests (rev2)
URL   : https://patchwork.freedesktop.org/series/20085/
State : warning

== Summary ==

Series 20085v2 drm/i915: Check against the signaled bit for fences/requests
https://patchwork.freedesktop.org/api/1.0/series/20085/revisions/2/mbox/

Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:242  dwarn:1   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
1fa99b0 drm/i915: Check against the signaled bit for fences/requests

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3937/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/: DMC 1.04 for Geminilake

[Anusha Srivatsa]

There is a nre version of DMC available for GLK.

The release notes mentions:
This FW has the fix to remove the hang conditions due to
some debug related issues.

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

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 14659c7..34aa9fa 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -34,9 +34,9 @@
  * low-power state and comes back to normal.
  */
 
-#define I915_CSR_GLK "i915/glk_dmc_ver1_03.bin"
+#define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
 MODULE_FIRMWARE(I915_CSR_GLK);
-#define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 3)
+#define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
 
 #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
 MODULE_FIRMWARE(I915_CSR_KBL);
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over macro

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over 
macro
URL   : https://patchwork.freedesktop.org/series/20086/
State : success

== Summary ==

Series 20086v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20086/revisions/1/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
1eb3847 drm/i915/gtt: Setup vm callbacks late
f0c09dc drm/i915/gtt: No need to do tlb flush with 48bit vm
d2e664a drm/i915/gtt: Use 32bit instead of legacy
4114551 drm/i915: Don't mark pdps clear if pdps are not submitted
9777694 drm/i915/gtt: Prefer i915_vm_is_48bit() over macro

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3936/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable OA unit for Gen 8 and 9 in i915 perf

[Patchwork]

== Series Details ==

Series: Enable OA unit for Gen 8 and 9 in i915 perf
URL   : https://patchwork.freedesktop.org/series/20084/
State : success

== Summary ==

Series 20084v1 Enable OA unit for Gen 8 and 9 in i915 perf
https://patchwork.freedesktop.org/api/1.0/series/20084/revisions/1/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
733c1e5 drm/i915: Add 'render basic' Gen8+ OA unit configs
73646a7 drm/i915: Add uncore mmio api for per-context registers
26c9eb3 drm/i915: expose _SUBSLICE_MASK GETPARM
b035818 drm/i915: expose _SLICE_MASK GETPARM

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3935/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Remove the preempted request from the execution queue

[Chris Wilson]

After the request is cancelled, we then need to remove it from the
global execution timeline and return it to the context timeline, the
inverse of submit_request().

v2: Move manipulation of struct intel_wait to helpers

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c| 66 --
 drivers/gpu/drm/i915/i915_gem_request.h|  3 +
 drivers/gpu/drm/i915/intel_breadcrumbs.c   | 17 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h| 37 +++-
 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  6 +-
 5 files changed, 117 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index d18f450977e0..76e31cd7840e 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -441,6 +441,55 @@ void i915_gem_request_submit(struct drm_i915_gem_request 
*request)
spin_unlock_irqrestore(>timeline->lock, flags);
 }
 
+void __i915_gem_request_unsubmit(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   struct intel_timeline *timeline;
+
+   assert_spin_locked(>timeline->lock);
+
+   /* Only unwind in reverse order, required so that the per-context list
+* is kept in seqno/ring order.
+*/
+   GEM_BUG_ON(request->global_seqno != engine->timeline->seqno);
+   engine->timeline->seqno--;
+
+   /* We may be recursing from the signal callback of another i915 fence */
+   spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+   request->global_seqno = 0;
+   if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+   intel_engine_cancel_signaling(request);
+   spin_unlock(>lock);
+
+   /* Transfer back from the global per-engine timeline to per-context */
+   timeline = request->timeline;
+   GEM_BUG_ON(timeline == engine->timeline);
+
+   spin_lock(>lock);
+   list_move(>link, >requests);
+   spin_unlock(>lock);
+
+   /* We don't need to wake_up any waiters on request->execute, they
+* will get woken by any other event or us re-adding this request
+* to the engine timeline (__i915_gem_request_submit()). The waiters
+* should be quite adapt at finding that the request now has a new
+* global_seqno to the one they went to sleep on.
+*/
+}
+
+void i915_gem_request_unsubmit(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   unsigned long flags;
+
+   /* Will be called from irq-context when using foreign fences. */
+   spin_lock_irqsave(>timeline->lock, flags);
+
+   __i915_gem_request_unsubmit(request);
+
+   spin_unlock_irqrestore(>timeline->lock, flags);
+}
+
 static int __i915_sw_fence_call
 submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
 {
@@ -1034,15 +1083,15 @@ long i915_wait_request(struct drm_i915_gem_request *req,
if (flags & I915_WAIT_LOCKED)
add_wait_queue(errq, );
 
-   intel_wait_init(, i915_gem_request_global_seqno(req));
+   intel_wait_init();
 
+restart:
reset_wait_queue(>execute, );
-   if (!wait.seqno) {
+   if (!intel_wait_update_request(, req)) {
do {
set_current_state(state);
 
-   wait.seqno = i915_gem_request_global_seqno(req);
-   if (wait.seqno)
+   if (intel_wait_update_request(, req))
break;
 
if (flags & I915_WAIT_LOCKED &&
@@ -1070,7 +1119,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
if (timeout < 0)
goto complete;
 
-   GEM_BUG_ON(!wait.seqno);
+   GEM_BUG_ON(!intel_wait_has_seqno());
}
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
 
@@ -1100,7 +1149,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
timeout = io_schedule_timeout(timeout);
 
if (intel_wait_complete() &&
-   i915_gem_request_global_seqno(req) == wait.seqno)
+   intel_wait_check_request(, req))
break;
 
set_current_state(state);
@@ -1135,6 +1184,11 @@ long i915_wait_request(struct drm_i915_gem_request *req,
/* Only spin if we know the GPU is processing this request */
if (i915_spin_request(req, state, 2))
break;
+
+   if (!intel_wait_check_request(, req)) {
+   intel_engine_remove_wait(req->engine, );
+   goto restart;
+   }
}
 
intel_engine_remove_wait(req->engine, );
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: don't leak the gem object

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: don't leak the gem object
URL   : https://patchwork.freedesktop.org/series/20077/
State : success

== Summary ==

Series 20077v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20077/revisions/1/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
885d6b6 drm/i915: prefer use of i915_gem_object_put
560ab66 drm/i915/selftests: don't leak the gem object

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3934/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Some minor i915-perf prep changes

[Patchwork]

== Series Details ==

Series: Some minor i915-perf prep changes
URL   : https://patchwork.freedesktop.org/series/20073/
State : success

== Summary ==

Series 20073v1 Some minor i915-perf prep changes
https://patchwork.freedesktop.org/api/1.0/series/20073/revisions/1/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
7c46d4c drm/i915/perf: improve invalid OA format debug message

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3933/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: signal first fence from irq handler if complete

[Chris Wilson]

On Wed, Feb 22, 2017 at 04:53:35PM +, Tvrtko Ursulin wrote:
> 
> On 17/02/2017 15:51, Chris Wilson wrote:
> > if (engine->irq_seqno_barrier &&
> >-rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
> > test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted)) {
> >-struct task_struct *tsk;
> >+unsigned long flags;
> >
> > /* The ordering of irq_posted versus applying the barrier
> >  * is crucial. The clearing of the current irq_posted must
> >@@ -4058,17 +4061,17 @@ __i915_request_irq_complete(const struct 
> >drm_i915_gem_request *req)
> >  * the seqno before we believe it coherent since they see
> >  * irq_posted == false but we are still running).
> >  */
> >-rcu_read_lock();
> >-tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
> >-if (tsk && tsk != current)
> >+spin_lock_irqsave(>breadcrumbs.lock, flags);
> >+if (engine->breadcrumbs.first_wait &&
> >+engine->breadcrumbs.first_wait->tsk != current)
> > /* Note that if the bottom-half is changed as we
> >  * are sending the wake-up, the new bottom-half will
> >  * be woken by whomever made the change. We only have
> >  * to worry about when we steal the irq-posted for
> >  * ourself.
> >  */
> >-wake_up_process(tsk);
> >-rcu_read_unlock();
> >+wake_up_process(engine->breadcrumbs.first_wait->tsk);
> >+spin_unlock_irqrestore(>breadcrumbs.lock, flags);
> 
> Worth caching >breadcrumbs maybe?

Makes no difference to object code, but makes it more pleasant to read,
so yes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove Braswell GGTT update w/a

[Chris Wilson]

On Wed, Feb 22, 2017 at 11:39:30AM +, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 01:27:41PM +0200, Joonas Lahtinen wrote:
> > On ma, 2017-02-20 at 12:47 +, Chris Wilson wrote:
> > > Testing with concurrent GGTT accesses no longer show the coherency
> > > problems from yonder, commit 5bab6f60cb4d ("drm/i915: Serialise updates
> > > to GGTT with access through GGTT on Braswell"). My presumption is that
> > > the root cause was more likely fixed by commit 3b5724d702ef ("drm/i915:
> > > Wait for writes through the GTT to land before reading back"), along
> > > with the use of WC updates to the global gTT in commit 8448661d65f6
> > > ("drm/i915: Convert clflushed pagetables over to WC maps". Given
> > > that the original symptoms can no longer be reproduced, time to remove
> > > the workaround.
> > > 
> > > Testcase: igt/gem_concurrenct_blit
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > 
> > Makes one think if the original fix has been appropriate, when adding
> > stop_machine for a software bug :P
> 
> Depends if you consider the months of hair pulling trying to find where
> the flush/stall was missing. It was a desperate patch to fix an annoying
> corruption issue - and since it seems that we now just avoid the
> dangerous path by taking a different route through hw, I don't think
> it is was wholly a sw bug.

Bah, after a few days of continuous testing, I've hit a workload that
shows the bug again. (Small numbers of large GTT objects, rather than
large number of small GTT objects.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Check against the signaled bit for fences/requests

[Chris Wilson]

When dma_fence_signal() is called, it sets a flag to indicate the fence
is complete. Before the dma_fence is signaled, the seqno check will
first be passed. During an unlocked check (such as inside a waiter), it
is possible for the fence to be signaled even though the seqno has been
reset (by engine wraparound). In this case the waiter will be kicked,
but for an extra layer of protection we can check the persistent
signaled bit from the fence.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 994929660027..0d3f787a0a7a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4026,6 +4026,15 @@ __i915_request_irq_complete(struct drm_i915_gem_request 
*req)
 {
struct intel_engine_cs *engine = req->engine;
 
+   /* Note that the engine may have wrapped around the seqno, and
+* so our request->global_seqno will be ahead of the hardware,
+* even though it completed the request before wrapping. We catch
+* this by kicking all the waiters before resetting the seqno
+* in hardware, and also signal the fence.
+*/
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+   return true;
+
/* Before we do the heavier coherent read of the seqno,
 * check the value (hopefully) in the CPU cacheline.
 */
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lspcon: Switch back to PCON mode after output replug (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/lspcon: Switch back to PCON mode after output replug (rev2)
URL   : https://patchwork.freedesktop.org/series/20072/
State : success

== Summary ==

Series 20072v2 drm/i915/lspcon: Switch back to PCON mode after output replug
https://patchwork.freedesktop.org/api/1.0/series/20072/revisions/2/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
a6ef522 drm/i915/lspcon: Switch back to PCON mode after output replug

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3932/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Chris Wilson]

On Wed, Feb 22, 2017 at 05:26:34PM +, Tvrtko Ursulin wrote:
> 
> On 17/02/2017 15:51, Chris Wilson wrote:
> >A significant cost in setting up a wait is the overhead of enabling the
> >interrupt. As we disable the interrupt whenever the queue of waiters is
> >empty, if we are frequently waiting on alternating batches, we end up
> >re-enabling the interrupt on a frequent basis. We do want to disable the
> >interrupt during normal operations as under high load it may add several
> >thousand interrupts/s - we have been known in the past to occupy whole
> >cores with our interrupt handler after accidentally leaving user
> >interrupts enabled. As a compromise, leave the interrupt enabled until
> >the next IRQ, or the system is idle. This gives a small window for a
> >waiter to keep the interrupt active and not be delayed by having to
> >re-enable the interrupt.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Mika Kuoppala 
> >---
> > drivers/gpu/drm/i915/i915_gem.c  |  4 +-
> > drivers/gpu/drm/i915/i915_irq.c  |  5 +-
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 95 
> > +++-
> > drivers/gpu/drm/i915/intel_ringbuffer.h  |  4 +-
> > 4 files changed, 65 insertions(+), 43 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 6745dcbf3799..9c87aacce43b 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -3003,8 +3003,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
> > if (wait_for(intel_execlists_idle(dev_priv), 10))
> > DRM_ERROR("Timeout waiting for engines to idle\n");
> >
> >-for_each_engine(engine, dev_priv, id)
> >+for_each_engine(engine, dev_priv, id) {
> >+intel_engine_disarm_breadcrumbs(engine);
> > i915_gem_batch_pool_fini(>batch_pool);
> >+}
> >
> > GEM_BUG_ON(!dev_priv->gt.awake);
> > dev_priv->gt.awake = false;
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >b/drivers/gpu/drm/i915/i915_irq.c
> >index 0c370c687c2a..fa597a29bc1d 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -1036,9 +1036,6 @@ static void notify_ring(struct intel_engine_cs *engine)
> > struct drm_i915_gem_request *rq = NULL;
> > struct intel_wait *wait;
> >
> >-if (!intel_engine_has_waiter(engine))
> >-return;
> >-
> > trace_i915_gem_request_notify(engine);
> > atomic_inc(>irq_count);
> > set_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
> >@@ -1064,6 +1061,8 @@ static void notify_ring(struct intel_engine_cs *engine)
> > rq = wait->request;
> >
> > wake_up_process(wait->tsk);
> >+} else {
> >+__intel_engine_disarm_breadcrumbs(engine);
> 
> So we disarm on the irq following the waiter exiting. But the
> overall effect depends on the timings of the wake up thread getting
> scheduled in combined with batch duration which I am not sure I
> quite like.

Correct, and also the overhead of each interrupt depends on the
frequency of batches. Considering this should scale to 2M requests/s,
using a timer is not a good heuristic either. (And don't treat 2M as an
upper bound :)
 
> >+void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
> >+{
> >+struct intel_breadcrumbs *b = >breadcrumbs;
> >+
> >+assert_spin_locked(>lock);
> >+
> >+if (b->irq_enabled) {
> >+irq_disable(engine);
> >+b->irq_enabled = false;
> >+}
> >+
> >+b->irq_armed = false;
> 
> Do we need the two level, armed & enabled scheme? I mean, why not
> just have irq_enabled and disable it from the timer callback? It is
> a bit challenging to figure out how the two level thing works.

The 2 level stuff remains because of the fault injection. The current
timer callback is far too slow imo, it will have the effect of always
keeping the irq alive. That's not nice for older gen. I'm continually
surprised by how well bdw/skl cope with the excess of interrupts from
execlists.
 
> Would a simpler scheme work where we would just bump the irq_enabled
> counter to N on every waiter entering, decrement by one in each user
> interrupt, and finally turn off on reaching zero? Maybe it would be
> too costly in terms of useless wake-ups. Hm, not sure.

Set N to 1... :)

> >@@ -707,14 +724,16 @@ void intel_engine_reset_breadcrumbs(struct 
> >intel_engine_cs *engine)
> > cancel_fake_irq(engine);
> > spin_lock_irq(>lock);
> >
> >-__intel_breadcrumbs_disable_irq(b);
> >+if (b->irq_enabled)
> >+irq_enable(engine);
> 
> Can't hit that GEM_BUG_ON(b->irq_enabled) in
> __intel_breadcrumbs_enable_irq from here?

We bypass __intel_breadcrumbs_enable_irq as the irq is already armed.
Sorry, missing the point you want to raise.

> >+else
> >+irq_disable(engine);
> >+
> > 

Re: [Intel-gfx] [PATCH] drm/i915: Check against the signaled bit for fences/requests

[Chris Wilson]

On Wed, Feb 22, 2017 at 05:30:59PM +, Tvrtko Ursulin wrote:
> 
> On 22/02/2017 16:42, Chris Wilson wrote:
> >When dma_fence_signal() is called, it sets a flag to indicate the fenece
> >is complete. Before the dma_fence is signaled, the seqno check will
> >first be passed. However, if the request is being held by an observer
> >across a global seqno reset, it is possible for the observer to not
> >notice the seqno completion (as the HWS is now zero), but instead we
> >rely on the signaled bit. External holders of the request should be
> >using the fence interface which does first check the signaled bit - it
> >will only be an unlocked waiter that may not notice the request
> >completion.
> >
> >By that analysis, the problem is old as our unlocked waits, but this
> >patch depends upon subclassing dma-fence, so use that as the base
> >commit.
> >
> >Fixes: 04769652c8c7 ("drm/i915: Derive GEM requests from dma-fence")
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc:  # v4.9+
> >---
> > drivers/gpu/drm/i915/i915_drv.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index 994929660027..dcc8f73b26bf 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -4026,6 +4026,9 @@ __i915_request_irq_complete(struct 
> >drm_i915_gem_request *req)
> > {
> > struct intel_engine_cs *engine = req->engine;
> >
> >+if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
> >+return true;
> >+
> > /* Before we do the heavier coherent read of the seqno,
> >  * check the value (hopefully) in the CPU cacheline.
> >  */
> >
> 
> It is obviously correct in a way that it can never give a false
> positive, even though I haven't quite figured how we had false
> negatives without it. I'll leave that for a new day. Hopefully there
> are no other places in our code which could be affected in the same
> way?

For starters, we can exclude all checks that hold struct_mutex (from the
time it gets the request from the source to the
i915_gem_request_completed, they are protected by the init_global_seqno
requiring the struct_mutex to do the rollover, and by retirement
removing the state trackers). That rules out the majority.

For the unlocked accessors, we can remove all the dma-fence clients as
they already have a check against the signaled bit before checking
against the seqno.

The only place I found that was susceptible was the unlocked waiter
And actually that is protected by init_global_seqno clearing the waiters
before doing the rollover.

Okay, no need to panic. I'll mollify the changelog and drop stable - I
still want the patch for the later changes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check against the signaled bit for fences/requests

[Tvrtko Ursulin]

On 22/02/2017 16:42, Chris Wilson wrote:

When dma_fence_signal() is called, it sets a flag to indicate the fenece
is complete. Before the dma_fence is signaled, the seqno check will
first be passed. However, if the request is being held by an observer
across a global seqno reset, it is possible for the observer to not
notice the seqno completion (as the HWS is now zero), but instead we
rely on the signaled bit. External holders of the request should be
using the fence interface which does first check the signaled bit - it
will only be an unlocked waiter that may not notice the request
completion.

By that analysis, the problem is old as our unlocked waits, but this
patch depends upon subclassing dma-fence, so use that as the base
commit.

Fixes: 04769652c8c7 ("drm/i915: Derive GEM requests from dma-fence")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc:  # v4.9+
---
 drivers/gpu/drm/i915/i915_drv.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 994929660027..dcc8f73b26bf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4026,6 +4026,9 @@ __i915_request_irq_complete(struct drm_i915_gem_request 
*req)
 {
struct intel_engine_cs *engine = req->engine;

+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+   return true;
+
/* Before we do the heavier coherent read of the seqno,
 * check the value (hopefully) in the CPU cacheline.
 */



It is obviously correct in a way that it can never give a false 
positive, even though I haven't quite figured how we had false negatives 
without it. I'll leave that for a new day. Hopefully there are no other 
places in our code which could be affected in the same way?


In the mean time:

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915: enable scrambling

[Ville Syrjälä]

On Wed, Feb 22, 2017 at 06:48:30PM +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
> 
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
> 
> V2: Addressed review comments from Ville:
> - Do not track scrambling status in DRM layer, track somewhere in
>   driver like in intel_crtc_state.
> - Don't talk to monitor at such a low layer, set monitor scrambling
>   in intel_enable_ddi() before enabling the port.
> 
> V3: Addressed review comments from Jani
> - In comments, function names, use "sink" instead of "monitor",
>   so that the implementation could be close to the language of
>   HDMI spec.
> 
> V4: Addressed review comment from Maarten
> - scrambling -> hdmi_scrambling
>   high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |   4 ++
>  drivers/gpu/drm/i915/intel_ddi.c  |  28 ++
>  drivers/gpu/drm/i915/intel_drv.h  |  14 +
>  drivers/gpu/drm/i915/intel_hdmi.c | 108 
> ++
>  4 files changed, 154 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 141a5c1..81cf10b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7819,7 +7819,11 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cd6fedd..bd8293d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> *crtc)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   else
>   temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (IS_GEMINILAKE(dev_priv))
> + temp = intel_hdmi_handle_source_scrambling(
> + intel_encoder,
> + _crtc->config->base.adjusted_mode, temp);
>   } else if (type == INTEL_OUTPUT_ANALOG) {
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> @@ -1843,6 +1848,21 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>   struct intel_digital_port *intel_dig_port =
>   enc_to_dig_port(encoder);
>  
> + if (IS_GEMINILAKE(dev_priv)) {
> + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> + /*
> +  * GLK sports a native HDMI 2.0 controller. If required
> +  * clock rate is > 340 Mhz && scrambling is supported
> +  * by sink, enable scrambling before enabling the
> +  * HDMI 2.0 port. The sink can choose to disable the
> +  * scrambling if it doesn't detect a scrambled within
> +  * 100 ms.
> +  */
> + intel_hdmi_handle_sink_scrambling(intel_encoder,
> + conn_state->connector,
> + crtc->config, true);
> + }
> +
>   /* In HDMI/DVI mode, the port width, and swing/emphasis values
>* are ignored so nothing special needs to be done besides
>* enabling the port.
> @@ -1875,6 +1895,14 @@ static void intel_disable_ddi(struct intel_encoder 
> *intel_encoder,
>   if (old_crtc_state->has_audio)
>   intel_audio_codec_disable(intel_encoder);
>  
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> +
> + intel_hdmi_handle_sink_scrambling(intel_encoder,
> + old_conn_state->connector,
> + intel_crtc->config, false);
> + }
> +
>   if (type == INTEL_OUTPUT_EDP) {
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 821c57c..c7262d7 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -691,6 +691,12 @@ 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Tvrtko Ursulin]

On 17/02/2017 15:51, Chris Wilson wrote:

A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c  |  4 +-
 drivers/gpu/drm/i915/i915_irq.c  |  5 +-
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 95 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  4 +-
 4 files changed, 65 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6745dcbf3799..9c87aacce43b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3003,8 +3003,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wait_for(intel_execlists_idle(dev_priv), 10))
DRM_ERROR("Timeout waiting for engines to idle\n");

-   for_each_engine(engine, dev_priv, id)
+   for_each_engine(engine, dev_priv, id) {
+   intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
+   }

GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0c370c687c2a..fa597a29bc1d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1036,9 +1036,6 @@ static void notify_ring(struct intel_engine_cs *engine)
struct drm_i915_gem_request *rq = NULL;
struct intel_wait *wait;

-   if (!intel_engine_has_waiter(engine))
-   return;
-
trace_i915_gem_request_notify(engine);
atomic_inc(>irq_count);
set_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
@@ -1064,6 +1061,8 @@ static void notify_ring(struct intel_engine_cs *engine)
rq = wait->request;

wake_up_process(wait->tsk);
+   } else {
+   __intel_engine_disarm_breadcrumbs(engine);


So we disarm on the irq following the waiter exiting. But the overall 
effect depends on the timings of the wake up thread getting scheduled in 
combined with batch duration which I am not sure I quite like.



}
spin_unlock(>breadcrumbs.lock);

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 860372653a59..94c6ce9c0a6f 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -35,8 +35,10 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 {
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct intel_breadcrumbs *b = >breadcrumbs;
+   struct intel_wait *wait;
+   unsigned long flags;

-   if (!b->irq_enabled)
+   if (!intel_engine_has_waiter(engine))
return;

if (b->hangcheck_interrupts != atomic_read(>irq_count)) {
@@ -49,10 +51,15 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * to process the pending interupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
 */
-   if (!intel_engine_wakeup(engine)) {
+   spin_lock_irqsave(>lock, flags);
+   wait = b->first_wait;
+   if (wait && !wake_up_process(wait->tsk)) {
mod_timer(>hangcheck, wait_timeout());
-   return;
+   wait = NULL;
}
+   spin_unlock_irqrestore(>lock, flags);
+   if (!wait)
+   return;

DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
@@ -107,6 +114,34 @@ static void irq_disable(struct intel_engine_cs *engine)
spin_unlock(>i915->irq_lock);
 }

+void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   assert_spin_locked(>lock);
+
+   if (b->irq_enabled) {
+   irq_disable(engine);
+   b->irq_enabled = false;
+   }
+
+   b->irq_armed = false;


Do we need the two level, armed & enabled scheme? I mean, why not just 
have irq_enabled and disable it from the timer callback? It is a bit 
challenging to 

Re: [Intel-gfx] [PATCH 4/5] drm/i915/gtt: No need to do tlb flush with 48bit vm

[Chris Wilson]

On Wed, Feb 22, 2017 at 06:54:24PM +0200, Mika Kuoppala wrote:
> The pdp rewrite to force tlb flush is only a 32bit ppgtt
> trick. That should not be needed with 48bit ppgtt.
> 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 269a8f1..791cb81 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1103,7 +1103,8 @@ static int gen8_ppgtt_alloc_pdp(struct 
> i915_address_space *vm,
>   gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
>   pdp->used_pdpes++;
>  
> - mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
> + if (!i915_vm_is_48bit(vm))
> + mark_tlbs_dirty(i915_vm_to_ppgtt(vm));

Just thinking the relative merits of unconditionally setting bits vs a
branch miss. It's immaterial as this should not be a hotpath!

I'd like the idea of perhaps calling this mark_pdp_dirty), and have
mark_pml4_dirty, mark_pte_dirty() etc. But they're not used, so pretty
pointless.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 4/6] drm: scrambling support in drm layer

[Ville Syrjälä]

On Wed, Feb 22, 2017 at 06:48:29PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340 MHz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
> 
> This patch adds:
> - A function to detect scrambling support parsing HF-VSDB
> - A function to check scrambling status runtime using SCDC read.
> - Two functions to enable/disable scrambling using SCDC read/write.
> - Few new bools to reflect scrambling support and status.
> 
> V2: Addressed review comments from Thierry, Ville and Dhinakaran
> Thierry:
> - Mhz -> MHz in comments and commit message.
> - i2c -> I2C in comments.
> - Fix the function documentations, keep in sync with drm_scdc_helper.c
> - drm_connector -> DRM connector.
> - Create structure for SCDC, and save scrambling status inside that,
>   in a sub-structure.
> - Call this sub-structure scrambling instead of scr_info.
> - low_rates -> low_clocks in scrambling status structure.
> - Store the return value of I2C read/write and print the error code
>   in case of failure.
> 
> Thierry and Ville:
> - Move the scrambling enable/disable/query functions in
>   drm_scdc_helper.c file.
> - Add drm_SCDC prefix for the functions.
> - Optimize the return statement from function
>   drm_SCDC_check_scrambling_status.
> 
> Ville:
> - Dont overwrite saved max TMDS clock value in display_info,
>   if max tmds clock from HF-VSDB is not > 340 MHz.
> - drm_detect_hdmi_scrambling -> drm_parse_hdmi_forum_vsdb.
> - Remove dynamic tracking of SCDC status from DRM layer, force bool.
> - Program clock ratio bit also, while enabling scrambling.
> 
> Dhinakaran:
> - Add a comment about *5000 while extracting max clock supported.
> 
> V3: Addressed review comments from Jose.
> - Create separate functions to enable scrambling and to set TMDS
>   clock/character rate ratio.
> 
> V4: Rebase
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c|  33 +++-
>  drivers/gpu/drm/drm_scdc_helper.c | 164 
> ++
>  include/drm/drm_connector.h   |  19 +
>  include/drm/drm_edid.h|   6 +-
>  include/drm/drm_scdc_helper.h |  41 ++
>  5 files changed, 261 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 63b79be..1e18c0a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -3811,13 +3812,43 @@ enum hdmi_quantization_range
>  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>const u8 *hf_vsdb)
>  {
> - struct drm_hdmi_info *hdmi = >display_info.hdmi;
> + struct drm_display_info *display = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi;
>  
>   if (hf_vsdb[6] & 0x80) {
>   hdmi->scdc.supported = true;
>   if (hf_vsdb[6] & 0x40)
>   hdmi->scdc.read_request = true;
>   }
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
> +  * * SCDC support available (let's check)
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + /* max clock is 5000 KHz times block value */
> + u32 max_tmds_clock = hf_vsdb[5] * 5000;
> + struct drm_scdc *scdc = >scdc;
> +
> + if (max_tmds_clock > 34) {
> + display->max_tmds_clock = max_tmds_clock;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> + }
> +
> + if (scdc->supported) {
> + scdc->scrambling.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + scdc->scrambling.low_rates = true;
> + }
> + }
>  }
>  
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
> b/drivers/gpu/drm/drm_scdc_helper.c
> index fe0e121..c0cf82b 100644
> --- a/drivers/gpu/drm/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -22,8 +22,10 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
> +#include 
>  
>  /**
>   * DOC: scdc helpers
> @@ -109,3 +111,165 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
> offset,
>   return err;
>  }
>  EXPORT_SYMBOL(drm_scdc_write);
> +
> +/**
> + * drm_scdc_check_scrambling_status - what is status of scrambling?
> + * @adapter: I2C adapter for DDC channel
> + *

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI 2.0: Scrambling in DRM layer (rev4)

[Patchwork]

== Series Details ==

Series: HDMI 2.0: Scrambling in DRM layer (rev4)
URL   : https://patchwork.freedesktop.org/series/19161/
State : success

== Summary ==

Series 19161v4 HDMI 2.0: Scrambling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/4/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
6d613076 drm/i915: allow HDMI 2.0 clock rates
ca0b6ab drm/i915: enable scrambling
960b45d drm: scrambling support in drm layer
526a33d drm/edid: detect SCDC support in HF-VSDB
ca7c9a7 drm/edid: check for HF-VSDB block
47823ce drm: Add SCDC helpers

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3931/
___
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/gtt: Setup vm callbacks late

[Chris Wilson]

On Wed, Feb 22, 2017 at 06:54:25PM +0200, Mika Kuoppala wrote:
> If we manage to tangle errorpaths and get call to callbacks,
> it is better to defensively keep them as null until object init is
> finished so that we get clean null deref on callsite,
> instead of more cryptic wreckage with partly initialized vm objects.
> 
> Signed-off-by: Mika Kuoppala 

Series looks ok, but you opened a can of bikeshed! :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915/gtt: Use 32bit instead of legacy

[Chris Wilson]

On Wed, Feb 22, 2017 at 06:54:23PM +0200, Mika Kuoppala wrote:
> Instead of using the subjective term legacy, use more descriptive and
> less loaded name '32bit' where appropriate.

Hmm. We have a mix of 32/48bit and 3/4 level. I think here we are better
using e.g.

gen8_mm_switch_3lvl
gen8_mm_switch_4lvl

Thoughts? Want to convert these or the others to 32/48?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Don't mark pdps clear if pdps are not submitted

[Chris Wilson]

On Wed, Feb 22, 2017 at 06:54:22PM +0200, Mika Kuoppala wrote:
> Don't mark pdps clear if never do the necessary actions
> with the hardware to make them clear.
> 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 39329d4..5dc2bbb 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1321,7 +1321,7 @@ static int gen8_emit_bb_start(struct 
> drm_i915_gem_request *req,
> u64 offset, u32 len,
> unsigned int dispatch_flags)
>  {
> - bool ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
> + const bool use_ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
>   u32 *cs;
>   int ret;
>  
> @@ -1332,13 +1332,12 @@ static int gen8_emit_bb_start(struct 
> drm_i915_gem_request *req,
>* not idle). PML4 is allocated during ppgtt init so this is
>* not needed in 48-bit.*/
>   if (req->ctx->ppgtt &&
> - (intel_engine_flag(req->engine) & req->ctx->ppgtt->pd_dirty_rings)) 
> {
> - if (!i915_vm_is_48bit(>ctx->ppgtt->base) &&
> - !intel_vgpu_active(req->i915)) {
> - ret = intel_logical_ring_emit_pdps(req);
> - if (ret)
> - return ret;
> - }
> + (intel_engine_flag(req->engine) & req->ctx->ppgtt->pd_dirty_rings) 
> &&
> + !i915_vm_is_48bit(>ctx->ppgtt->base) &&
> + !intel_vgpu_active(req->i915)) {
> + ret = intel_logical_ring_emit_pdps(req);
> + if (ret)
> + return ret;
>  
>   req->ctx->ppgtt->pd_dirty_rings &= 
> ~intel_engine_flag(req->engine);
>   }
> @@ -1348,7 +1347,7 @@ static int gen8_emit_bb_start(struct 
> drm_i915_gem_request *req,
>   return PTR_ERR(cs);
>  
>   /* FIXME(BDW): Address space and security selectors. */
> - *cs++ = MI_BATCH_BUFFER_START_GEN8 | (ppgtt << 8) | (dispatch_flags &
> + *cs++ = MI_BATCH_BUFFER_START_GEN8 | (use_ppgtt << 8) | (dispatch_flags 
> &
>   I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0);

Missed an opportunity here.

*cs++ = MI_BATCH_BUFFER_START_GEN8 |
(dispatch_flags & I915_DISPATCH_SECURE) ? 0 : BIT(8) |
(dispatch_flags & I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER 
: 0);

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/6] drm: Add SCDC helpers

[Ville Syrjälä]

On Wed, Feb 22, 2017 at 06:48:26PM +0530, Shashank Sharma wrote:
> From: Thierry Reding 
> 
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
> 
> This commit introduces helpers to access the SCDC and provides the
> symbolic names for the various registers defined in the specification.
> 
> V2: Rebase.
> V3: Added R-B from Jose.
> V4: Rebase
> 
> Signed-off-by: Thierry Reding 
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Jose Abreu 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |  12 
>  drivers/gpu/drm/Makefile  |   3 +-
>  drivers/gpu/drm/drm_scdc_helper.c | 111 
>  include/drm/drm_scdc_helper.h | 132 
> ++
>  4 files changed, 257 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
>  create mode 100644 include/drm/drm_scdc_helper.h
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 03040aa..7592756 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -217,6 +217,18 @@ EDID Helper Functions Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_edid.c
> :export:
>  
> +SCDC Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> +   :doc: scdc helpers
> +
> +.. kernel-doc:: include/drm/drm_scdc_helper.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> +   :export:
> +
>  Rectangle Utilities Reference
>  =
>  
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 92de399..ad91cd9 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
>   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> - drm_simple_kms_helper.o drm_modeset_helper.o
> + drm_simple_kms_helper.o drm_modeset_helper.o \
> + drm_scdc_helper.o
>  
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
> b/drivers/gpu/drm/drm_scdc_helper.c
> new file mode 100644
> index 000..fe0e121
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sub license,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include 
> +
> +#include 
> +
> +/**
> + * DOC: scdc helpers
> + *
> + * Status and Control Data Channel (SCDC) is a mechanism introduced by the
> + * HDMI 2.0 specification. It is a point-to-point protocol that allows the
> + * HDMI source and HDMI sink to exchange data. The same I2C interface that
> + * is used to access EDID serves as the transport mechanism for SCDC.
> + */
> +
> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
> +
> +/**
> + * drm_scdc_read - read a block of data from SCDC
> + * @adapter: I2C controller
> + * @offset: start offset of block to read
> + * @buffer: return location for the block to read
> + * @size: size of the block to read
> + *
> + * Reads a block of data from SCDC, starting at a given offset.
> + *
> + * Returns:
> + * The number of bytes read from SCDC or a negative error code on failure.
> + */
> +ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
> +   size_t size)
> +{
> + struct i2c_msg msgs[2] = {
> + {
> +  

Re: [Intel-gfx] [PATCH 1/2] drm/i915: signal first fence from irq handler if complete

[Chris Wilson]

On Wed, Feb 22, 2017 at 04:53:35PM +, Tvrtko Ursulin wrote:
> 
> On 17/02/2017 15:51, Chris Wilson wrote:
> >@@ -4034,9 +4038,8 @@ __i915_request_irq_complete(const struct 
> >drm_i915_gem_request *req)
> >  * is woken.
> >  */
> > if (engine->irq_seqno_barrier &&
> >-rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
> > test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted)) {
> >-struct task_struct *tsk;
> >+unsigned long flags;
> >
> > /* The ordering of irq_posted versus applying the barrier
> >  * is crucial. The clearing of the current irq_posted must
> >@@ -4058,17 +4061,17 @@ __i915_request_irq_complete(const struct 
> >drm_i915_gem_request *req)
> >  * the seqno before we believe it coherent since they see
> >  * irq_posted == false but we are still running).
> >  */
> >-rcu_read_lock();
> >-tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
> >-if (tsk && tsk != current)
> >+spin_lock_irqsave(>breadcrumbs.lock, flags);
> >+if (engine->breadcrumbs.first_wait &&
> >+engine->breadcrumbs.first_wait->tsk != current)
> > /* Note that if the bottom-half is changed as we
> >  * are sending the wake-up, the new bottom-half will
> >  * be woken by whomever made the change. We only have
> >  * to worry about when we steal the irq-posted for
> >  * ourself.
> >  */
> >-wake_up_process(tsk);
> >-rcu_read_unlock();
> >+wake_up_process(engine->breadcrumbs.first_wait->tsk);
> >+spin_unlock_irqrestore(>breadcrumbs.lock, flags);
> 
> Worth caching >breadcrumbs maybe?

I'll ask gcc.

> >
> > if (__i915_gem_request_completed(req, seqno))
> > return true;
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index e22eacec022d..2e7bdb0cf069 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >@@ -1083,6 +1083,7 @@ long i915_wait_request(struct drm_i915_gem_request 
> >*req,
> > }
> >
> > wait.tsk = current;
> >+wait.request = req;
> 
> I guess this was the preemption prep tree already. If you decide to
> keep the intel_wait_init helper could add req to it.

Challenge being not all users of intel_wait_init have a request :)

> > restart:
> > do {
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
> >b/drivers/gpu/drm/i915/i915_gem_request.h
> >index 5f73d8c0a38a..0efee879df23 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.h
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.h
> >@@ -32,10 +32,12 @@
> >
> > struct drm_file;
> > struct drm_i915_gem_object;
> >+struct drm_i915_gem_request;
> >
> > struct intel_wait {
> > struct rb_node node;
> > struct task_struct *tsk;
> >+struct drm_i915_gem_request *request;
> > u32 seqno;
> > };
> >
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >b/drivers/gpu/drm/i915/i915_irq.c
> >index 57fa1bf78a85..0c370c687c2a 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -1033,10 +1033,44 @@ static void ironlake_rps_change_irq_handler(struct 
> >drm_i915_private *dev_priv)
> >
> > static void notify_ring(struct intel_engine_cs *engine)
> > {
> >+struct drm_i915_gem_request *rq = NULL;
> >+struct intel_wait *wait;
> >+
> >+if (!intel_engine_has_waiter(engine))
> >+return;
> >+
> >+trace_i915_gem_request_notify(engine);
> > atomic_inc(>irq_count);
> > set_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
> >-if (intel_engine_wakeup(engine))
> >-trace_i915_gem_request_notify(engine);
> >+
> >+rcu_read_lock();
> 
> Not sure this is required from an irq handler. But I don't think it
> harms either, so maybe has an usefulness in documenting things.

That's what I said! It's not, but it's cheap enough that I think it is
worth keeping to document the game being played with rq.

> Looks OK.
> 
> Last time I tested it was a definitive latency improvement but also
> a slight throughput regression on crazy microbenchmarks like
> gem_latency IIRC. But I think overall a good thing for more
> realistic workloads.

Yup. It's a big one for gem_exec_whisper which is latency sensitive (and
gem_exec_latency). I didn't see gem_latency (using tests/gem_latency)
suffer too much. To be precise, which gem_latency are you thinking of?
:) I presume ezbench -b gem:latency ?

I did look at trying to reduce the cost of the spinlocks (by trying to
share them between requests, or the engine->timeline and breadcrumbs)
but came away bruised and battered.

> I leave to you the ordering wrt/ the preemption prep series. I can
> apply my r-b at that point, not sure 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: signal first fence from irq handler if complete

[Tvrtko Ursulin]

On 17/02/2017 15:51, Chris Wilson wrote:

As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h  | 19 +---
 drivers/gpu/drm/i915/i915_gem_request.c  |  1 +
 drivers/gpu/drm/i915/i915_gem_request.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  | 38 ++--
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 10 +
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 30 +
 6 files changed, 62 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5005922f267b..2592a15d7727 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4005,7 +4005,10 @@ static inline bool
 __i915_request_irq_complete(const struct drm_i915_gem_request *req)
 {
struct intel_engine_cs *engine = req->engine;
-   u32 seqno = i915_gem_request_global_seqno(req);
+   u32 seqno;
+
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+   return true;

/* The request was dequeued before we were awoken. We check after
 * inspecting the hw to confirm that this was the same request
@@ -4013,6 +4016,7 @@ __i915_request_irq_complete(const struct 
drm_i915_gem_request *req)
 * the request execution are sufficient to ensure that a check
 * after reading the value from hw matches this request.
 */
+   seqno = i915_gem_request_global_seqno(req);
if (!seqno)
return false;

@@ -4034,9 +4038,8 @@ __i915_request_irq_complete(const struct 
drm_i915_gem_request *req)
 * is woken.
 */
if (engine->irq_seqno_barrier &&
-   rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted)) {
-   struct task_struct *tsk;
+   unsigned long flags;

/* The ordering of irq_posted versus applying the barrier
 * is crucial. The clearing of the current irq_posted must
@@ -4058,17 +4061,17 @@ __i915_request_irq_complete(const struct 
drm_i915_gem_request *req)
 * the seqno before we believe it coherent since they see
 * irq_posted == false but we are still running).
 */
-   rcu_read_lock();
-   tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
-   if (tsk && tsk != current)
+   spin_lock_irqsave(>breadcrumbs.lock, flags);
+   if (engine->breadcrumbs.first_wait &&
+   engine->breadcrumbs.first_wait->tsk != current)
/* Note that if the bottom-half is changed as we
 * are sending the wake-up, the new bottom-half will
 * be woken by whomever made the change. We only have
 * to worry about when we steal the irq-posted for
 * ourself.
 */
-   wake_up_process(tsk);
-   rcu_read_unlock();
+   wake_up_process(engine->breadcrumbs.first_wait->tsk);
+   spin_unlock_irqrestore(>breadcrumbs.lock, flags);


Worth caching >breadcrumbs maybe?



if (__i915_gem_request_completed(req, seqno))
return true;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index e22eacec022d..2e7bdb0cf069 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1083,6 +1083,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
}

wait.tsk = current;
+   wait.request = req;


I guess this was the preemption prep tree already. If you decide to keep 
the intel_wait_init helper could add req to it.




 restart:
do {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 5f73d8c0a38a..0efee879df23 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -32,10 +32,12 @@

 struct drm_file;
 struct drm_i915_gem_object;
+struct 

[Intel-gfx] [PATCH 2/5] drm/i915: Don't mark pdps clear if pdps are not submitted

[Mika Kuoppala]

Don't mark pdps clear if never do the necessary actions
with the hardware to make them clear.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 39329d4..5dc2bbb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1321,7 +1321,7 @@ static int gen8_emit_bb_start(struct drm_i915_gem_request 
*req,
  u64 offset, u32 len,
  unsigned int dispatch_flags)
 {
-   bool ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
+   const bool use_ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
u32 *cs;
int ret;
 
@@ -1332,13 +1332,12 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
 * not idle). PML4 is allocated during ppgtt init so this is
 * not needed in 48-bit.*/
if (req->ctx->ppgtt &&
-   (intel_engine_flag(req->engine) & req->ctx->ppgtt->pd_dirty_rings)) 
{
-   if (!i915_vm_is_48bit(>ctx->ppgtt->base) &&
-   !intel_vgpu_active(req->i915)) {
-   ret = intel_logical_ring_emit_pdps(req);
-   if (ret)
-   return ret;
-   }
+   (intel_engine_flag(req->engine) & req->ctx->ppgtt->pd_dirty_rings) 
&&
+   !i915_vm_is_48bit(>ctx->ppgtt->base) &&
+   !intel_vgpu_active(req->i915)) {
+   ret = intel_logical_ring_emit_pdps(req);
+   if (ret)
+   return ret;
 
req->ctx->ppgtt->pd_dirty_rings &= 
~intel_engine_flag(req->engine);
}
@@ -1348,7 +1347,7 @@ static int gen8_emit_bb_start(struct drm_i915_gem_request 
*req,
return PTR_ERR(cs);
 
/* FIXME(BDW): Address space and security selectors. */
-   *cs++ = MI_BATCH_BUFFER_START_GEN8 | (ppgtt << 8) | (dispatch_flags &
+   *cs++ = MI_BATCH_BUFFER_START_GEN8 | (use_ppgtt << 8) | (dispatch_flags 
&
I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0);
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/5] drm/i915/gtt: Use 32bit instead of legacy

[Mika Kuoppala]

Instead of using the subjective term legacy, use more descriptive and
less loaded name '32bit' where appropriate.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 20 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.h |  8 
 drivers/gpu/drm/i915/intel_lrc.c|  4 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1fdab96..269a8f1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -636,12 +636,12 @@ static int gen8_write_pdp(struct drm_i915_gem_request 
*req,
return 0;
 }
 
-static int gen8_legacy_mm_switch(struct i915_hw_ppgtt *ppgtt,
-struct drm_i915_gem_request *req)
+static int gen8_mm_switch_32bit(struct i915_hw_ppgtt *ppgtt,
+   struct drm_i915_gem_request *req)
 {
int i, ret;
 
-   for (i = GEN8_LEGACY_PDPES - 1; i >= 0; i--) {
+   for (i = GEN8_32BIT_PDPES - 1; i >= 0; i--) {
const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
 
ret = gen8_write_pdp(req, i, pd_daddr);
@@ -652,8 +652,8 @@ static int gen8_legacy_mm_switch(struct i915_hw_ppgtt 
*ppgtt,
return 0;
 }
 
-static int gen8_48b_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct drm_i915_gem_request *req)
+static int gen8_mm_switch_48bit(struct i915_hw_ppgtt *ppgtt,
+   struct drm_i915_gem_request *req)
 {
return gen8_write_pdp(req, 0, px_dma(>pml4));
 }
@@ -857,7 +857,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
}
 
GEM_BUG_ON(!i915_vm_is_48bit(>base) &&
-  pdpe >= GEN8_LEGACY_PDPES);
+  pdpe >= GEN8_32BIT_PDPES);
pd = pdp->page_directory[pdpe];
pde = 0;
}
@@ -984,7 +984,7 @@ static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt 
*ppgtt, bool create)
msg = (create ? VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE :
VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY);
} else {
-   for (i = 0; i < GEN8_LEGACY_PDPES; i++) {
+   for (i = 0; i < GEN8_32BIT_PDPES; i++) {
const u64 daddr = i915_page_dir_dma_addr(ppgtt, i);
 
I915_WRITE(vgtif_reg(pdp[i].lo), lower_32_bits(daddr));
@@ -1275,7 +1275,7 @@ static int gen8_preallocate_top_level_pdp(struct 
i915_hw_ppgtt *ppgtt)
 }
 
 /*
- * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP registers
+ * GEN8 32bit ppgtt programming is accomplished through a max 4 PDP registers
  * with a net effect resembling a 2-level page table in normal x86 terms. Each
  * PDP represents 1GB of memory 4 * 512 * 512 * 4096 = 4GB legacy 32b address
  * space.
@@ -1315,7 +1315,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
 
gen8_initialize_pml4(>base, >pml4);
 
-   ppgtt->switch_mm = gen8_48b_mm_switch;
+   ppgtt->switch_mm = gen8_mm_switch_48bit;
 
ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
@@ -1325,7 +1325,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
if (ret)
goto free_scratch;
 
-   ppgtt->switch_mm = gen8_legacy_mm_switch;
+   ppgtt->switch_mm = gen8_mm_switch_32bit;
 
if (intel_vgpu_active(dev_priv)) {
ret = gen8_preallocate_top_level_pdp(ppgtt);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f7d4e19..83bb718 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -101,13 +101,13 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define HSW_GTT_ADDR_ENCODE(addr)  ((addr) | (((addr) >> 28) & 0x7f0))
 #define HSW_PTE_ADDR_ENCODE(addr)  HSW_GTT_ADDR_ENCODE(addr)
 
-/* GEN8 legacy style address is defined as a 3 level page table:
+/* GEN8 32b style address is defined as a 3 level page table:
  * 31:30 | 29:21 | 20:12 |  11:0
  * PDPE  |  PDE  |  PTE  | offset
  * The difference as compared to normal x86 3 level page table is the PDPEs are
  * programmed via register.
  *
- * GEN8 48b legacy style address is defined as a 4 level page table:
+ * GEN8 48b style address is defined as a 4 level page table:
  * 47:39 | 38:30 | 29:21 | 20:12 |  11:0
  * PML4E | PDPE  |  PDE  |  PTE  | offset
  */
@@ -122,11 +122,11 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define GEN8_PDE_MASK  0x1ff
 #define GEN8_PTE_SHIFT 12
 #define GEN8_PTE_MASK  0x1ff
-#define GEN8_LEGACY_PDPES  4

[Intel-gfx] [PATCH 1/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over macro

[Mika Kuoppala]

If we setup the vm size early, we can use the newly introduced
i915_vm_is_48bit() in majority of callsites wanting to know the vm size.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 58 +
 1 file changed, 33 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a5162cb..1fdab96 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -554,7 +554,7 @@ alloc_pdp(struct i915_address_space *vm)
struct i915_page_directory_pointer *pdp;
int ret = -ENOMEM;
 
-   WARN_ON(!USES_FULL_48BIT_PPGTT(vm->i915));
+   WARN_ON(!i915_vm_is_48bit(vm));
 
pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
if (!pdp)
@@ -582,10 +582,12 @@ static void free_pdp(struct i915_address_space *vm,
 struct i915_page_directory_pointer *pdp)
 {
__pdp_fini(pdp);
-   if (USES_FULL_48BIT_PPGTT(vm->i915)) {
-   cleanup_px(vm, pdp);
-   kfree(pdp);
-   }
+
+   if (!i915_vm_is_48bit(vm))
+   return;
+
+   cleanup_px(vm, pdp);
+   kfree(pdp);
 }
 
 static void gen8_initialize_pdp(struct i915_address_space *vm,
@@ -736,7 +738,7 @@ static void gen8_ppgtt_set_pdpe(struct i915_address_space 
*vm,
gen8_ppgtt_pdpe_t *vaddr;
 
pdp->page_directory[pdpe] = pd;
-   if (!USES_FULL_48BIT_PPGTT(vm->i915))
+   if (!i915_vm_is_48bit(vm))
return;
 
vaddr = kmap_atomic_px(pdp);
@@ -798,7 +800,7 @@ static void gen8_ppgtt_clear_4lvl(struct i915_address_space 
*vm,
struct i915_page_directory_pointer *pdp;
unsigned int pml4e;
 
-   GEM_BUG_ON(!USES_FULL_48BIT_PPGTT(vm->i915));
+   GEM_BUG_ON(!i915_vm_is_48bit(vm));
 
gen8_for_each_pml4e(pdp, pml4, start, length, pml4e) {
if (!gen8_ppgtt_clear_pdp(vm, pdp, start, length))
@@ -941,7 +943,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
goto free_pt;
}
 
-   if (USES_FULL_48BIT_PPGTT(dev)) {
+   if (i915_vm_is_48bit(vm)) {
vm->scratch_pdp = alloc_pdp(vm);
if (IS_ERR(vm->scratch_pdp)) {
ret = PTR_ERR(vm->scratch_pdp);
@@ -951,7 +953,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
 
gen8_initialize_pt(vm, vm->scratch_pt);
gen8_initialize_pd(vm, vm->scratch_pd);
-   if (USES_FULL_48BIT_PPGTT(dev_priv))
+   if (i915_vm_is_48bit(vm))
gen8_initialize_pdp(vm, vm->scratch_pdp);
 
return 0;
@@ -968,12 +970,13 @@ static int gen8_init_scratch(struct i915_address_space 
*vm)
 
 static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt *ppgtt, bool create)
 {
+   struct i915_address_space *vm = >base;
+   struct drm_i915_private *dev_priv = vm->i915;
enum vgt_g2v_type msg;
-   struct drm_i915_private *dev_priv = ppgtt->base.i915;
int i;
 
-   if (USES_FULL_48BIT_PPGTT(dev_priv)) {
-   u64 daddr = px_dma(>pml4);
+   if (i915_vm_is_48bit(vm)) {
+   const u64 daddr = px_dma(>pml4);
 
I915_WRITE(vgtif_reg(pdp[0].lo), lower_32_bits(daddr));
I915_WRITE(vgtif_reg(pdp[0].hi), upper_32_bits(daddr));
@@ -982,7 +985,7 @@ static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt 
*ppgtt, bool create)
VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY);
} else {
for (i = 0; i < GEN8_LEGACY_PDPES; i++) {
-   u64 daddr = i915_page_dir_dma_addr(ppgtt, i);
+   const u64 daddr = i915_page_dir_dma_addr(ppgtt, i);
 
I915_WRITE(vgtif_reg(pdp[i].lo), lower_32_bits(daddr));
I915_WRITE(vgtif_reg(pdp[i].hi), upper_32_bits(daddr));
@@ -999,7 +1002,7 @@ static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt 
*ppgtt, bool create)
 
 static void gen8_free_scratch(struct i915_address_space *vm)
 {
-   if (USES_FULL_48BIT_PPGTT(vm->i915))
+   if (i915_vm_is_48bit(vm))
free_pdp(vm, vm->scratch_pdp);
free_pd(vm, vm->scratch_pd);
free_pt(vm, vm->scratch_pt);
@@ -1044,10 +1047,10 @@ static void gen8_ppgtt_cleanup(struct 
i915_address_space *vm)
if (intel_vgpu_active(dev_priv))
gen8_ppgtt_notify_vgt(ppgtt, false);
 
-   if (!USES_FULL_48BIT_PPGTT(vm->i915))
-   gen8_ppgtt_cleanup_3lvl(>base, >pdp);
-   else
+   if (i915_vm_is_48bit(vm))
gen8_ppgtt_cleanup_4lvl(ppgtt);
+   else
+   gen8_ppgtt_cleanup_3lvl(>base, >pdp);
 
gen8_free_scratch(vm);
 }
@@ -1222,9 +1225,7 @@ static void gen8_dump_ppgtt(struct i915_hw_ppgtt *ppgtt, 
struct seq_file *m)
gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
u64 start = 0, length = ppgtt->base.total;
 
- 

[Intel-gfx] [PATCH 5/5] drm/i915/gtt: Setup vm callbacks late

[Mika Kuoppala]

If we manage to tangle errorpaths and get call to callbacks,
it is better to defensively keep them as null until object init is
finished so that we get clean null deref on callsite,
instead of more cryptic wreckage with partly initialized vm objects.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 791cb81..77276c9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1298,11 +1298,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
}
 
-   ppgtt->base.cleanup = gen8_ppgtt_cleanup;
-   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
-   ppgtt->base.bind_vma = ppgtt_bind_vma;
-   ppgtt->debug_dump = gen8_dump_ppgtt;
-
/* There are only few exceptions for gen >=6. chv and bxt.
 * And we are not sure about the latter so play safe for now.
 */
@@ -1317,7 +1312,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
gen8_initialize_pml4(>base, >pml4);
 
ppgtt->switch_mm = gen8_mm_switch_48bit;
-
ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl;
@@ -1326,8 +1320,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
if (ret)
goto free_scratch;
 
-   ppgtt->switch_mm = gen8_mm_switch_32bit;
-
if (intel_vgpu_active(dev_priv)) {
ret = gen8_preallocate_top_level_pdp(ppgtt);
if (ret) {
@@ -1336,6 +1328,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
}
}
 
+   ppgtt->switch_mm = gen8_mm_switch_32bit;
ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_3lvl;
ppgtt->base.insert_entries = gen8_ppgtt_insert_3lvl;
ppgtt->base.clear_range = gen8_ppgtt_clear_3lvl;
@@ -1344,6 +1337,11 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
if (intel_vgpu_active(dev_priv))
gen8_ppgtt_notify_vgt(ppgtt, true);
 
+   ppgtt->base.cleanup = gen8_ppgtt_cleanup;
+   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
+   ppgtt->base.bind_vma = ppgtt_bind_vma;
+   ppgtt->debug_dump = gen8_dump_ppgtt;
+
return 0;
 
 free_scratch:
@@ -1787,13 +1785,7 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
if (ret)
return ret;
 
-   ppgtt->base.clear_range = gen6_ppgtt_clear_range;
-   ppgtt->base.insert_entries = gen6_ppgtt_insert_entries;
-   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
-   ppgtt->base.bind_vma = ppgtt_bind_vma;
-   ppgtt->base.cleanup = gen6_ppgtt_cleanup;
ppgtt->base.total = I915_PDES * GEN6_PTES * PAGE_SIZE;
-   ppgtt->debug_dump = gen6_dump_ppgtt;
 
gen6_scratch_va_range(ppgtt, 0, ppgtt->base.total);
gen6_write_page_range(ppgtt, 0, ppgtt->base.total);
@@ -1804,6 +1796,13 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
}
 
+   ppgtt->base.clear_range = gen6_ppgtt_clear_range;
+   ppgtt->base.insert_entries = gen6_ppgtt_insert_entries;
+   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
+   ppgtt->base.bind_vma = ppgtt_bind_vma;
+   ppgtt->base.cleanup = gen6_ppgtt_cleanup;
+   ppgtt->debug_dump = gen6_dump_ppgtt;
+
DRM_DEBUG_DRIVER("Allocated pde space (%lldM) at GTT entry: %llx\n",
 ppgtt->node.size >> 20,
 ppgtt->node.start / PAGE_SIZE);
-- 
2.7.4

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

[Intel-gfx] [PATCH 4/5] drm/i915/gtt: No need to do tlb flush with 48bit vm

[Mika Kuoppala]

The pdp rewrite to force tlb flush is only a 32bit ppgtt
trick. That should not be needed with 48bit ppgtt.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 269a8f1..791cb81 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1103,7 +1103,8 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space 
*vm,
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
pdp->used_pdpes++;
 
-   mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
+   if (!i915_vm_is_48bit(vm))
+   mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
}
 
ret = gen8_ppgtt_alloc_pd(vm, pd, start, length);
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add name for DRM_DP_DUAL_MODE_LSPCON

[Patchwork]

== Series Details ==

Series: drm: Add name for DRM_DP_DUAL_MODE_LSPCON
URL   : https://patchwork.freedesktop.org/series/20062/
State : success

== Summary ==

Series 20062v1 drm: Add name for DRM_DP_DUAL_MODE_LSPCON
https://patchwork.freedesktop.org/api/1.0/series/20062/revisions/1/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
e507271 drm: Add name for DRM_DP_DUAL_MODE_LSPCON

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3930/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Check against the signaled bit for fences/requests

[Chris Wilson]

When dma_fence_signal() is called, it sets a flag to indicate the fenece
is complete. Before the dma_fence is signaled, the seqno check will
first be passed. However, if the request is being held by an observer
across a global seqno reset, it is possible for the observer to not
notice the seqno completion (as the HWS is now zero), but instead we
rely on the signaled bit. External holders of the request should be
using the fence interface which does first check the signaled bit - it
will only be an unlocked waiter that may not notice the request
completion.

By that analysis, the problem is old as our unlocked waits, but this
patch depends upon subclassing dma-fence, so use that as the base
commit.

Fixes: 04769652c8c7 ("drm/i915: Derive GEM requests from dma-fence")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc:  # v4.9+
---
 drivers/gpu/drm/i915/i915_drv.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 994929660027..dcc8f73b26bf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4026,6 +4026,9 @@ __i915_request_irq_complete(struct drm_i915_gem_request 
*req)
 {
struct intel_engine_cs *engine = req->engine;
 
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+   return true;
+
/* Before we do the heavier coherent read of the seqno,
 * check the value (hopefully) in the CPU cacheline.
 */
-- 
2.11.0

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

[Intel-gfx] [PATCH 2/6] drm/i915: expose _SUBSLICE_MASK GETPARM

[Robert Bragg]

Assuming a uniform mask across all slices, this enables userspace to
determine the specific sub slices enabled. This information is required,
for example, to be able to analyse some OA counter reports where the
counter configuration depends on the HW sub slice configuration.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d391768f301b..a497537b42d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -364,6 +364,11 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
if (!value)
return -ENODEV;
break;
+   case I915_PARAM_SUBSLICE_MASK:
+   value = INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   if (!value)
+   return -ENODEV;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f47fb7f26f36..e0599e729e68 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -393,6 +393,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
 #define I915_PARAM_SLICE_MASK   45 /* XXX: rebase before landing */
+#define I915_PARAM_SUBSLICE_MASK46
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
-- 
2.11.1

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

[Intel-gfx] [PATCH 0/6] Enable OA unit for Gen 8 and 9 in i915 perf

[Robert Bragg]

This extends i915 perf to support periodic sampling of OA metrics for BDW, CHV,
SKL and BXT.

I've recently been working through a number of issues that were uncovered once
I started adapting the gen7 IGT tests. Some further issues were also noticed by
others using INTEL_performance_query in Mesa.  So compared to earlier Gen8+ OA
series sent out a few notable updates are:

* Implements tail race handling like we have for gen 7
* On SKL we disable automatic reports for slice/unslice clock ratio changes
  because the hardware can generate so many redundant reports (no ratio change)
  that buffer overflows can start to become a problem and userspace ends up
  doing an unreasonable amount of work to keep up.
* WaDisableDopClockGating:bdw is no longer handled in i915_perf.c
* Flex EU register updates within the register state context were using
  incorrect offsets before.
* The generated per-gen config initialization code wasn't initializing the
  flex eu register state.
* While filtering for a single context we weren't forwarding userspace the
  reports it needed to bookend around context switches so that it can discount
  the progress of the counters associated with other contexts.
* Even opening a stream for single context filtered OA metrics requires
  dev.i915.perf_stream_paranoid == 0 since we can no longer reliably hide the
  progress of system-wide metrics, now that filtering is done based on tagging
  reports with an ID instead of physically clock gating the OA unit off for
  other contests.

In case anyone wants to take a look at the IGT tests so far they can be found
here:

  https://github.com/rib/intel-gpu-tools/commits/wip/rib/i915-perf-tests

I should probably write a few additional tests specific to changes made for
gen8+, but I've at least adapted the existing tests for gen7.

I can only say I've tested on Skylake recently, so although we can hopefully
review these patches with an eye towards upstreaming, they do still need some
broader testing across more hardware.

Considering the large number of configs for Gen 8 and 9, and how unsure I am
about the maturity of all the various configs I do have some doubt about
whether we should upstream them all together if someone hasn't looked at the
unique counters for each set against a relevant workload to see that the
numbers look plausible (so ignoring the common A counters). On the other hand
being optimistic means we can make more sets available faster and even makes it
more likely they will be tested across a broader range of workloads.  We can
add replacement configs if needs be or even stop advertising configs
considering how they are advertised to userspace dynamically.

Note: these patches are based on the patches I sent out to update the tail
pointer race workaround for Haswell in i915 perf.

Regards,
- Robert

Robert Bragg (6):
  drm/i915: expose _SLICE_MASK GETPARM
  drm/i915: expose _SUBSLICE_MASK GETPARM
  drm/i915: Add uncore mmio api for per-context registers
  drm/i915: Add 'render basic' Gen8+ OA unit configs
  drm/i915: Add OA unit support for Gen 8+
  drm/i915: Add more OA configs for BDW, CHV, SKL + BXT

 drivers/gpu/drm/i915/Makefile   |8 +-
 drivers/gpu/drm/i915/i915_drv.c |   10 +
 drivers/gpu/drm/i915/i915_drv.h |   20 +
 drivers/gpu/drm/i915/i915_gem_context.h |1 +
 drivers/gpu/drm/i915/i915_oa_bdw.c  | 4954 +++
 drivers/gpu/drm/i915/i915_oa_bdw.h  |   38 +
 drivers/gpu/drm/i915/i915_oa_bxt.c  | 2541 
 drivers/gpu/drm/i915/i915_oa_bxt.h  |   38 +
 drivers/gpu/drm/i915/i915_oa_chv.c  | 2730 +
 drivers/gpu/drm/i915/i915_oa_chv.h  |   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt2.c   | 3303 +
 drivers/gpu/drm/i915/i915_oa_sklgt2.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.c   | 2856 ++
 drivers/gpu/drm/i915/i915_oa_sklgt3.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt4.c   | 2910 ++
 drivers/gpu/drm/i915/i915_oa_sklgt4.h   |   38 +
 drivers/gpu/drm/i915/i915_perf.c| 1067 ++-
 drivers/gpu/drm/i915/i915_reg.h |   12 +
 drivers/gpu/drm/i915/intel_lrc.c|4 +
 drivers/gpu/drm/i915/intel_uncore.c |   73 +
 include/uapi/drm/i915_drm.h |   21 +-
 21 files changed, 20667 insertions(+), 71 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
 create mode 

[Intel-gfx] [PATCH 1/6] drm/i915: expose _SLICE_MASK GETPARM

[Robert Bragg]

Enables userspace to determine the number of slices enabled and also
know what specific slices are enabled. This information is required, for
example, to be able to analyse some OA counter reports where the counter
configuration depends on the HW slice configuration.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b76e8f7ac174..d391768f301b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -359,6 +359,11 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 */
value = 1;
break;
+   case I915_PARAM_SLICE_MASK:
+   value = INTEL_INFO(dev_priv)->sseu.slice_mask;
+   if (!value)
+   return -ENODEV;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3554495bef13..f47fb7f26f36 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -392,6 +392,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_POOLED_EU38
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
+#define I915_PARAM_SLICE_MASK   45 /* XXX: rebase before landing */
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
-- 
2.11.1

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

[Intel-gfx] [PATCH 3/6] drm/i915: Add uncore mmio api for per-context registers

[Robert Bragg]

Since the exponent for periodic OA counter sampling is maintained in a
per-context register while we want to treat it as if it were global
state we need to be able to safely issue an mmio write to a per-context
register and affect any currently running context.

We have to take some extra care in this case and this adds a utility
api to encapsulate what's required.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h |  4 ++
 drivers/gpu/drm/i915/i915_reg.h |  3 ++
 drivers/gpu/drm/i915/intel_uncore.c | 73 +
 3 files changed, 80 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 105b97bd34d7..c8d03a2e89cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -718,6 +718,7 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private 
*dev_priv,
   i915_reg_t reg, unsigned int op);
 
 struct intel_uncore_funcs {
+   int (*wait_for_rcs_busy)(struct drm_i915_private *dev_priv);
void (*force_wake_get)(struct drm_i915_private *dev_priv,
enum forcewake_domains 
domains);
void (*force_wake_put)(struct drm_i915_private *dev_priv,
@@ -751,6 +752,7 @@ struct intel_uncore {
 
struct intel_uncore_funcs funcs;
 
+   atomic_t hold_rcs_busy_count;
unsigned fifo_count;
 
enum forcewake_domains fw_domains;
@@ -3139,6 +3141,8 @@ static inline bool intel_vgpu_active(struct 
drm_i915_private *dev_priv)
 {
return dev_priv->vgpu.active;
 }
+int intel_uncore_begin_ctx_mmio(struct drm_i915_private *dev_priv);
+void intel_uncore_end_ctx_mmio(struct drm_i915_private *dev_priv);
 
 void
 i915_enable_pipestat(struct drm_i915_private *dev_priv, enum pipe pipe,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 141a5c1e3895..94d40e82edc1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2313,6 +2313,9 @@ enum skl_disp_power_wells {
 #define   GEN8_RC_SEMA_IDLE_MSG_DISABLE(1 << 12)
 #define   GEN8_FF_DOP_CLOCK_GATE_DISABLE   (1<<10)
 
+#define GEN6_RCS_PWR_FSM _MMIO(0x22ac)
+#define GEN9_RCS_FE_FSM2 _MMIO(0x22a4)
+
 /* Fuse readout registers for GT */
 #define CHV_FUSE_GT_MMIO(VLV_DISPLAY_BASE + 0x2168)
 #define   CHV_FGT_DISABLE_SS0  (1 << 10)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 441c51fd9746..06bfe5f89ac5 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1274,6 +1274,16 @@ static void intel_uncore_fw_domains_init(struct 
drm_i915_private *dev_priv)
WARN_ON(dev_priv->uncore.fw_domains == 0);
 }
 
+static int gen8_wait_for_rcs_busy(struct drm_i915_private *dev_priv)
+{
+   return wait_for((I915_READ(GEN6_RCS_PWR_FSM) & 0x3f) == 0x30, 50);
+}
+
+static int gen9_wait_for_rcs_busy(struct drm_i915_private *dev_priv)
+{
+   return wait_for((I915_READ(GEN9_RCS_FE_FSM2) & 0x3f) == 0x30, 50);
+}
+
 #define ASSIGN_FW_DOMAINS_TABLE(d) \
 { \
dev_priv->uncore.fw_domains_table = \
@@ -1305,6 +1315,8 @@ void intel_uncore_init(struct drm_i915_private *dev_priv)
dev_priv->uncore.funcs.mmio_writel =
gen9_decoupled_write32;
}
+   dev_priv->uncore.funcs.wait_for_rcs_busy =
+   gen9_wait_for_rcs_busy;
break;
case 8:
if (IS_CHERRYVIEW(dev_priv)) {
@@ -1316,6 +1328,8 @@ void intel_uncore_init(struct drm_i915_private *dev_priv)
ASSIGN_WRITE_MMIO_VFUNCS(gen8);
ASSIGN_READ_MMIO_VFUNCS(gen6);
}
+   dev_priv->uncore.funcs.wait_for_rcs_busy =
+   gen8_wait_for_rcs_busy;
break;
case 7:
case 6:
@@ -1858,6 +1872,65 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private 
*dev_priv,
return fw_domains;
 }
 
+static int hold_rcs_busy(struct drm_i915_private *dev_priv)
+{
+   int ret = 0;
+
+   if (atomic_inc_and_test(_priv->uncore.hold_rcs_busy_count)) {
+   I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
+  _MASKED_BIT_ENABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
+
+   ret = dev_priv->uncore.funcs.wait_for_rcs_busy(dev_priv);
+   }
+
+   return ret;
+}
+
+static void release_rcs_busy(struct drm_i915_private *dev_priv)
+{
+   if (!atomic_dec_and_test(_priv->uncore.hold_rcs_busy_count)) {
+   I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
+  _MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
+   }
+}
+
+/*
+ * From Broadwell PRM, 3D-Media-GPGPU -> Register State Context
+ *
+ * MMIO reads or writes to any of the registers 

[Intel-gfx] [PATCH 4/6] drm/i915: Add 'render basic' Gen8+ OA unit configs

[Robert Bragg]

Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:

 https://github.com/rib/gputop
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_oa_bdw.c| 371 ++
 drivers/gpu/drm/i915/i915_oa_bdw.h|  38 
 drivers/gpu/drm/i915/i915_oa_bxt.c| 322 +
 drivers/gpu/drm/i915/i915_oa_bxt.h|  38 
 drivers/gpu/drm/i915/i915_oa_chv.c| 214 
 drivers/gpu/drm/i915/i915_oa_chv.h|  38 
 drivers/gpu/drm/i915/i915_oa_sklgt2.c | 228 +
 drivers/gpu/drm/i915/i915_oa_sklgt2.h |  38 
 drivers/gpu/drm/i915/i915_oa_sklgt3.c | 236 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.h |  38 
 drivers/gpu/drm/i915/i915_oa_sklgt4.c | 247 ++
 drivers/gpu/drm/i915/i915_oa_sklgt4.h |  38 
 14 files changed, 1855 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b1b580337c7a..65a31450a392 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -127,7 +127,13 @@ i915-y += i915_vgpu.o
 
 # perf code
 i915-y += i915_perf.o \
- i915_oa_hsw.o
+ i915_oa_hsw.o \
+ i915_oa_bdw.o \
+ i915_oa_chv.o \
+ i915_oa_sklgt2.o \
+ i915_oa_sklgt3.o \
+ i915_oa_sklgt4.o \
+ i915_oa_bxt.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c8d03a2e89cc..d5e084b46023 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2437,6 +2437,8 @@ struct drm_i915_private {
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+   const struct i915_oa_reg *flex_regs;
+   int flex_regs_len;
 
struct {
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c 
b/drivers/gpu/drm/i915/i915_oa_bdw.c
new file mode 100644
index ..d5d608ff2a36
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -0,0 +1,371 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_bdw.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_bdw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+};
+
+static const 

[Intel-gfx] [PATCH 5/6] drm/i915: Add OA unit support for Gen 8+

[Robert Bragg]

Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.

Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.

The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).

This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.

The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).

Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h |   14 +
 drivers/gpu/drm/i915/i915_gem_context.h |1 +
 drivers/gpu/drm/i915/i915_perf.c| 1067 +--
 drivers/gpu/drm/i915/i915_reg.h |9 +
 drivers/gpu/drm/i915/intel_lrc.c|4 +
 include/uapi/drm/i915_drm.h |   19 +-
 6 files changed, 1044 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5e084b46023..b6d617e308af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2443,6 +2443,7 @@ struct drm_i915_private {
struct {
struct i915_vma *vma;
u8 *vaddr;
+   u32 last_ctx_id;
int format;
int format_size;
 
@@ -2512,6 +2513,14 @@ struct drm_i915_private {
} oa_buffer;
 
u32 gen7_latched_oastatus1;
+   u32 ctx_oactxctrl_off;
+   u32 ctx_flexeu0_off;
+
+   /* The RPT_ID/reason field for Gen8+ includes a bit
+* to determine if the CTX ID in the report is valid
+* but the specific bit differs between Gen 8 and 9
+*/
+   u32 gen8_valid_ctx_bit;
 
struct i915_oa_ops ops;
const struct i915_oa_format *oa_formats;
@@ -2823,6 +2832,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define IS_KBL_ULX(dev_priv)   (INTEL_DEVID(dev_priv) == 0x590E || \
 INTEL_DEVID(dev_priv) == 0x5915 || \
 INTEL_DEVID(dev_priv) == 0x591E)
+#define IS_SKL_GT2(dev_priv)   (IS_SKYLAKE(dev_priv) && \
+(INTEL_DEVID(dev_priv) & 0x00F0) == 0x0010)
 #define IS_SKL_GT3(dev_priv)   (IS_SKYLAKE(dev_priv) && \
 (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0020)
 #define IS_SKL_GT4(dev_priv)   (IS_SKYLAKE(dev_priv) && \
@@ -3566,6 +3577,9 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,
 
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
+void 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: prefer use of i915_gem_object_put

[Matthew Auld]

On 22 February 2017 at 16:12, Chris Wilson  wrote:
> On Wed, Feb 22, 2017 at 04:01:06PM +, Matthew Auld wrote:
>> Always use i915_gem_object_put over i915_gem_object_free if we can.
>>
>> Signed-off-by: Matthew Auld 
>> Cc: Chris Wilson 
>> Cc: Joonas Lahtinen 
>> ---
>>  drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index f3abdc27c5dd..9ad8c704 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> @@ -599,7 +599,7 @@ _i915_gem_object_create_stolen(struct drm_i915_private 
>> *dev_priv,
>>   return obj;
>>
>>  cleanup:
>> - i915_gem_object_free(obj);
>> + i915_gem_object_put(obj);
>
> Which you can't here. Put(stolen) assumes we have pinned the pages.
Ah, missed that :|
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC Scrub vol. 1 (rev4)

[Patchwork]

== Series Details ==

Series: GuC Scrub vol. 1 (rev4)
URL   : https://patchwork.freedesktop.org/series/16856/
State : success

== Summary ==

Series 16856v4 GuC Scrub vol. 1
https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/4/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
de86964 drm/i915/uc: Simplify firmware path handling
3bd35f1 drm/i915/guc: Simplify intel_guc_init_hw()
9d55149 drm/i915/guc: Extract param logic form guc_init
e5b5068 drm/i915/uc: Make intel_uc_fw_fetch() static
f32b9e4 drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw()
d2ca92a drm/i915/huc: Add huc_to_i915
20c4531 drm/i915/uc: Drop superfluous externs in intel_uc.h
437508e drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3929/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: don't leak the gem object

[Chris Wilson]

On Wed, Feb 22, 2017 at 04:01:05PM +, Matthew Auld wrote:
> For our fake dma objects we can leak the underlying gem object if we
> fail to pin our "backing storage".
> 
> [   39.952618] 
> =
> [   39.952625] BUG mock_object (Tainted: G U ): Objects remaining 
> in mock_object on __kmem_cache_shutdown()
> [   39.952629] 
> -
> 
> [   39.952633] Disabling lock debugging due to kernel taint
> [   39.952635] INFO: Slab 0xea00086c6a00 objects=21 used=1 
> fp=0x88021b1abc00 flags=0x5fff808100
> [   39.952640] CPU: 1 PID: 1258 Comm: drv_selftest Tainted: GBU  
> 4.10.0+ #46
> [   39.952641] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, 
> BIOS MBP111.88Z.0138.B17.1602221718 02/22/2016
> [   39.952642] Call Trace:
> [   39.952648]  dump_stack+0x4d/0x6f
> [   39.952651]  slab_err+0x9d/0xb0
> [   39.952654]  ? ksm_migrate_page+0xe0/0xe0
> [   39.952657]  ? on_each_cpu_cond+0x9a/0xc0
> [   39.952658]  ? __kmalloc+0x1af/0x1c0
> [   39.952660]  ? __kmem_cache_shutdown+0x173/0x3e0
> [   39.952661]  __kmem_cache_shutdown+0x196/0x3e0
> [   39.952664]  kmem_cache_destroy+0xa0/0x150
> [   39.952708]  mock_device_release+0x113/0x140 [i915]
> [   39.952726]  drm_dev_release+0x20/0x40 [drm]
> [   39.952735]  drm_dev_unref+0x23/0x30 [drm]
> [   39.952768]  i915_gem_gtt_mock_selftests+0x55/0x70 [i915]
> [   39.952803]  __run_selftests+0x169/0x1c0 [i915]
> [   39.952805]  ? 0xa0151000
> [   39.952840]  i915_mock_selftests+0x30/0x60 [i915]
> [   39.952869]  i915_init+0xc/0x78 [i915]
> [   39.952870]  ? 0xa0151000
> [   39.952872]  do_one_initcall+0x43/0x170
> [   39.952874]  ? __vunmap+0x81/0xd0
> [   39.952875]  ? kmem_cache_alloc_trace+0x37/0x170
> [   39.952877]  ? do_init_module+0x27/0x1f8
> [   39.952879]  do_init_module+0x5f/0x1f8
> [   39.952881]  load_module+0x2423/0x29b0
> [   39.952882]  ? __symbol_put+0x40/0x40
> [   39.952885]  ? kernel_read_file+0x1a3/0x1c0
> [   39.952887]  SYSC_finit_module+0xbc/0xf0
> [   39.952889]  SyS_finit_module+0xe/0x10
> [   39.952892]  entry_SYSCALL_64_fastpath+0x13/0x94
> 
> v2: use onion teardown and favour i915_gem_object_put
> 
> Fixes: 8d28ba4568f4 ("drm/i915: Exercise filling the top/bottom portions of 
> the ppgtt")
> Signed-off-by: Matthew Auld 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Reviewed-by: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: prefer use of i915_gem_object_put

[Chris Wilson]

On Wed, Feb 22, 2017 at 04:01:06PM +, Matthew Auld wrote:
> Always use i915_gem_object_put over i915_gem_object_free if we can.
> 
> Signed-off-by: Matthew Auld 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index f3abdc27c5dd..9ad8c704 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -599,7 +599,7 @@ _i915_gem_object_create_stolen(struct drm_i915_private 
> *dev_priv,
>   return obj;
>  
>  cleanup:
> - i915_gem_object_free(obj);
> + i915_gem_object_put(obj);

Which you can't here. Put(stolen) assumes we have pinned the pages.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: don't leak the gem object

[Matthew Auld]

For our fake dma objects we can leak the underlying gem object if we
fail to pin our "backing storage".

[   39.952618] 
=
[   39.952625] BUG mock_object (Tainted: G U ): Objects remaining 
in mock_object on __kmem_cache_shutdown()
[   39.952629] 
-

[   39.952633] Disabling lock debugging due to kernel taint
[   39.952635] INFO: Slab 0xea00086c6a00 objects=21 used=1 
fp=0x88021b1abc00 flags=0x5fff808100
[   39.952640] CPU: 1 PID: 1258 Comm: drv_selftest Tainted: GBU  
4.10.0+ #46
[   39.952641] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, 
BIOS MBP111.88Z.0138.B17.1602221718 02/22/2016
[   39.952642] Call Trace:
[   39.952648]  dump_stack+0x4d/0x6f
[   39.952651]  slab_err+0x9d/0xb0
[   39.952654]  ? ksm_migrate_page+0xe0/0xe0
[   39.952657]  ? on_each_cpu_cond+0x9a/0xc0
[   39.952658]  ? __kmalloc+0x1af/0x1c0
[   39.952660]  ? __kmem_cache_shutdown+0x173/0x3e0
[   39.952661]  __kmem_cache_shutdown+0x196/0x3e0
[   39.952664]  kmem_cache_destroy+0xa0/0x150
[   39.952708]  mock_device_release+0x113/0x140 [i915]
[   39.952726]  drm_dev_release+0x20/0x40 [drm]
[   39.952735]  drm_dev_unref+0x23/0x30 [drm]
[   39.952768]  i915_gem_gtt_mock_selftests+0x55/0x70 [i915]
[   39.952803]  __run_selftests+0x169/0x1c0 [i915]
[   39.952805]  ? 0xa0151000
[   39.952840]  i915_mock_selftests+0x30/0x60 [i915]
[   39.952869]  i915_init+0xc/0x78 [i915]
[   39.952870]  ? 0xa0151000
[   39.952872]  do_one_initcall+0x43/0x170
[   39.952874]  ? __vunmap+0x81/0xd0
[   39.952875]  ? kmem_cache_alloc_trace+0x37/0x170
[   39.952877]  ? do_init_module+0x27/0x1f8
[   39.952879]  do_init_module+0x5f/0x1f8
[   39.952881]  load_module+0x2423/0x29b0
[   39.952882]  ? __symbol_put+0x40/0x40
[   39.952885]  ? kernel_read_file+0x1a3/0x1c0
[   39.952887]  SYSC_finit_module+0xbc/0xf0
[   39.952889]  SyS_finit_module+0xe/0x10
[   39.952892]  entry_SYSCALL_64_fastpath+0x13/0x94

v2: use onion teardown and favour i915_gem_object_put

Fixes: 8d28ba4568f4 ("drm/i915: Exercise filling the top/bottom portions of the 
ppgtt")
Signed-off-by: Matthew Auld 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index e23753181720..a2310f8a7559 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -101,7 +101,7 @@ fake_dma_object(struct drm_i915_private *i915, u64 size)
 
obj = i915_gem_object_alloc(i915);
if (!obj)
-   return ERR_PTR(-ENOMEM);
+   goto err;
 
drm_gem_private_object_init(>drm, >base, size);
i915_gem_object_init(obj, _ops);
@@ -112,10 +112,15 @@ fake_dma_object(struct drm_i915_private *i915, u64 size)
 
/* Preallocate the "backing storage" */
if (i915_gem_object_pin_pages(obj))
-   return ERR_PTR(-ENOMEM);
+   goto err_obj;
 
i915_gem_object_unpin_pages(obj);
return obj;
+
+err_obj:
+   i915_gem_object_put(obj);
+err:
+   return ERR_PTR(-ENOMEM);
 }
 
 static int igt_ppgtt_alloc(void *arg)
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/2] drm/i915: prefer use of i915_gem_object_put

[Matthew Auld]

Always use i915_gem_object_put over i915_gem_object_free if we can.

Signed-off-by: Matthew Auld 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index f3abdc27c5dd..9ad8c704 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -599,7 +599,7 @@ _i915_gem_object_create_stolen(struct drm_i915_private 
*dev_priv,
return obj;
 
 cleanup:
-   i915_gem_object_free(obj);
+   i915_gem_object_put(obj);
return 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.BAT: success for drm/i915: Stop using RP_DOWN_EI on Baytrail (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Stop using RP_DOWN_EI on Baytrail (rev2)
URL   : https://patchwork.freedesktop.org/series/20019/
State : success

== Summary ==

Series 20019v2 drm/i915: Stop using RP_DOWN_EI on Baytrail
https://patchwork.freedesktop.org/api/1.0/series/20019/revisions/2/mbox/

fi-bdw-5557u total:253  pass:242  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:253  pass:214  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:253  pass:234  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:253  pass:226  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:253  pass:222  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:253  pass:237  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:253  pass:203  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:253  pass:235  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:253  pass:236  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:253  pass:231  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:253  pass:243  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:253  pass:225  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:253  pass:224  dwarn:0   dfail:0   fail:0   skip:29 

bf89ec45d0822835b03910371ac0baf46c4efa2d drm-tip: 2017y-02m-22d-14h-30m-04s UTC 
integration manifest
8816b7a drm/i915: Stop using RP_DOWN_EI on Baytrail

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3928/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915/uc: Simplify firmware path handling

[Arkadiusz Hiler]

On Wed, Feb 22, 2017 at 04:30:49PM +0100, Arkadiusz Hiler wrote:
> On Wed, Feb 22, 2017 at 12:53:47PM +, Chris Wilson wrote:
> > On Wed, Feb 22, 2017 at 01:41:25PM +0100, Arkadiusz Hiler wrote:
> > > Currently fw->path values can represent one of three possible states:
> > > 
> > >  1) NULL - device without the uC
> > >  2) '\0' - device with the uC but have no firmware
> > >  3) else - device with the uC and we have firmware
> > > 
> > > Second case is used only to WARN at a later stage.
> > > 
> > > We can WARN right away and merge cases 1 and 2.
> > > 
> > > Code can be even further simplified and common (HuC/GuC logic) happening
> > > right before the fetch can be offloaded to the common function.
> > > 
> > > v2: fewer temporary variables, more straightforward flow (M. Wajdeczko)
> > > v3: DRM_ERROR instead of WARN (M. Wajdeczko)
> > > 
> > > Cc: Anusha Srivatsa 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Michal Winiarski 
> > > Cc: Michal Wajdeczko 
> > > Signed-off-by: Arkadiusz Hiler 
> > > ---
> > >  drivers/gpu/drm/i915/intel_guc_loader.c | 39 
> > > +++--
> > >  drivers/gpu/drm/i915/intel_huc.c| 20 +
> > >  drivers/gpu/drm/i915/intel_uc.c |  5 +++--
> > >  3 files changed, 22 insertions(+), 42 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> > > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > index 549a254..336e97d 100644
> > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > @@ -433,12 +433,8 @@ int intel_guc_init_hw(struct drm_i915_private 
> > > *dev_priv)
> > >   intel_uc_fw_status_repr(guc_fw->load_status));
> > >  
> > >   if (fw_path == NULL) {
> > > - /* Device is known to have no uCode (e.g. no GuC) */
> > > + /* We do not have uCode for the device */
> > >   return -ENXIO;
> > > - } else if (*fw_path == '\0') {
> > > - /* Device has a GuC but we don't know what f/w to load? */
> > > - WARN(1, "No GuC firmware known for this platform!\n");
> > > - return -ENODEV;
> > >   }
> > >  
> > >   /* Fetch failed, or already fetched but failed to load? */
> > > @@ -474,7 +470,6 @@ int intel_guc_init_hw(struct drm_i915_private 
> > > *dev_priv)
> > >   return 0;
> > >  }
> > >  
> > > -
> > >  /**
> > >   * intel_guc_fetch_fw() - determine and fetch firmware
> > >   * @guc: intel_guc struct
> > > @@ -487,39 +482,31 @@ int intel_guc_init_hw(struct drm_i915_private 
> > > *dev_priv)
> > >  void intel_guc_fetch_fw(struct intel_guc *guc)
> > >  {
> > >   struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > > - const char *fw_path;
> > >  
> > > - if (!HAS_GUC_UCODE(dev_priv)) {
> > > - fw_path = NULL;
> > > - } else if (IS_SKYLAKE(dev_priv)) {
> > > - fw_path = I915_SKL_GUC_UCODE;
> > > + guc->fw.path = NULL;
> > > + guc->fw.fetch_status = INTEL_UC_FIRMWARE_NONE;
> > > + guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
> > > + guc->fw.fw = INTEL_UC_FW_TYPE_GUC;
> > > +
> > > + if (IS_SKYLAKE(dev_priv)) {
> > > + guc->fw.path = I915_SKL_GUC_UCODE;
> > >   guc->fw.major_ver_wanted = SKL_FW_MAJOR;
> > >   guc->fw.minor_ver_wanted = SKL_FW_MINOR;
> > >   } else if (IS_BROXTON(dev_priv)) {
> > > - fw_path = I915_BXT_GUC_UCODE;
> > > + guc->fw.path = I915_BXT_GUC_UCODE;
> > >   guc->fw.major_ver_wanted = BXT_FW_MAJOR;
> > >   guc->fw.minor_ver_wanted = BXT_FW_MINOR;
> > >   } else if (IS_KABYLAKE(dev_priv)) {
> > > - fw_path = I915_KBL_GUC_UCODE;
> > > + guc->fw.path = I915_KBL_GUC_UCODE;
> > >   guc->fw.major_ver_wanted = KBL_FW_MAJOR;
> > >   guc->fw.minor_ver_wanted = KBL_FW_MINOR;
> > >   } else {
> > > - fw_path = "";   /* unknown device */
> > > + DRM_ERROR("No GuC firmware known for platform with GuC!\n");
> > > + i915.enable_guc_loading = 0;
> > > + return;
> > 
> > Now plan for having fw_path overriden by a i915_param.guc_firmware.
> > 
> > Perhaps something like
> > if (i915_param.guc_firmware) {
> > guc->fw.path = i915_param.guc_firmware; /* needs 0400! */
> > guc->fw.major_ver_wanted = -1;
> > guc->fw.minor_ver_wanted = -1;
> > } else if (IS_SKYLAKE
> > works?
> 
> Sorry, I do not quite understand the comment. Can you elaborate?

Nevermind, got it.

LGTM, but for it to fully work we need to make uc_fetch_fw (or however
it will end up being named) aware that -1 have special meaning.

Now the version cross-check looks like that:

if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {


-- 
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 2/3] drm/i915/perf: better pipeline aged/aging tail updates

[Robert Bragg]

This updates the tail pointer race workaround handling to updating the
'aged' pointer before looking to start aging a new one. There's the
possibility that there is already new data available and so we can
immediately start aging a new pointer without having to first wait for a
later hrtimer callback (and then another to age).

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 41 ++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 19d0e4222974..d04ebaa8406e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -391,6 +391,29 @@ static bool gen7_oa_buffer_check_unlocked(struct 
drm_i915_private *dev_priv)
 
now = ktime_get_mono_fast_ns();
 
+   /* Update the aged tail
+*
+* Flip the tail pointer available for read()s once the aging tail is
+* old enough to trust that the corresponding data will be visible to
+* the CPU...
+*
+* Do this before updating the aging pointer in case we may be able to
+* immediately start aging a new pointer too (if new data has become
+* available) without needing to wait for a later hrtimer callback.
+*/
+   if (aging_tail != INVALID_TAIL_PTR &&
+   ((now - dev_priv->perf.oa.oa_buffer.aging_timestamp) >
+OA_TAIL_MARGIN_NSEC)) {
+   aged_idx ^= 1;
+   dev_priv->perf.oa.oa_buffer.aged_tail_idx = aged_idx;
+
+   aged_tail = aging_tail;
+
+   /* Mark that we need a new pointer to start aging... */
+   dev_priv->perf.oa.oa_buffer.tails[!aged_idx].offset = 
INVALID_TAIL_PTR;
+   aging_tail = INVALID_TAIL_PTR;
+   }
+
/* Update the aging tail
 *
 * We throttle aging tail updates until we have a new tail that
@@ -420,24 +443,6 @@ static bool gen7_oa_buffer_check_unlocked(struct 
drm_i915_private *dev_priv)
}
}
 
-   /* Update the aged tail
-*
-* Flip the tail pointer available for read()s once the aging tail is
-* old enough to trust that the corresponding data will be visible to
-* the CPU...
-*/
-   if (aging_tail != INVALID_TAIL_PTR &&
-   ((now - dev_priv->perf.oa.oa_buffer.aging_timestamp) >
-OA_TAIL_MARGIN_NSEC)) {
-   aged_idx ^= 1;
-   dev_priv->perf.oa.oa_buffer.aged_tail_idx = aged_idx;
-
-   aged_tail = aging_tail;
-
-   /* Mark that we need a new pointer to start aging... */
-   dev_priv->perf.oa.oa_buffer.tails[!aged_idx].offset = 
INVALID_TAIL_PTR;
-   }
-
spin_unlock_irqrestore(_priv->perf.oa.oa_buffer.ptr_lock, flags);
 
return aged_tail == INVALID_TAIL_PTR ?
-- 
2.11.1

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/uc: Simplify firmware path handling

[Arkadiusz Hiler]

On Wed, Feb 22, 2017 at 12:53:47PM +, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 01:41:25PM +0100, Arkadiusz Hiler wrote:
> > Currently fw->path values can represent one of three possible states:
> > 
> >  1) NULL - device without the uC
> >  2) '\0' - device with the uC but have no firmware
> >  3) else - device with the uC and we have firmware
> > 
> > Second case is used only to WARN at a later stage.
> > 
> > We can WARN right away and merge cases 1 and 2.
> > 
> > Code can be even further simplified and common (HuC/GuC logic) happening
> > right before the fetch can be offloaded to the common function.
> > 
> > v2: fewer temporary variables, more straightforward flow (M. Wajdeczko)
> > v3: DRM_ERROR instead of WARN (M. Wajdeczko)
> > 
> > Cc: Anusha Srivatsa 
> > Cc: Tvrtko Ursulin 
> > Cc: Michal Winiarski 
> > Cc: Michal Wajdeczko 
> > Signed-off-by: Arkadiusz Hiler 
> > ---
> >  drivers/gpu/drm/i915/intel_guc_loader.c | 39 
> > +++--
> >  drivers/gpu/drm/i915/intel_huc.c| 20 +
> >  drivers/gpu/drm/i915/intel_uc.c |  5 +++--
> >  3 files changed, 22 insertions(+), 42 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > index 549a254..336e97d 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > @@ -433,12 +433,8 @@ int intel_guc_init_hw(struct drm_i915_private 
> > *dev_priv)
> > intel_uc_fw_status_repr(guc_fw->load_status));
> >  
> > if (fw_path == NULL) {
> > -   /* Device is known to have no uCode (e.g. no GuC) */
> > +   /* We do not have uCode for the device */
> > return -ENXIO;
> > -   } else if (*fw_path == '\0') {
> > -   /* Device has a GuC but we don't know what f/w to load? */
> > -   WARN(1, "No GuC firmware known for this platform!\n");
> > -   return -ENODEV;
> > }
> >  
> > /* Fetch failed, or already fetched but failed to load? */
> > @@ -474,7 +470,6 @@ int intel_guc_init_hw(struct drm_i915_private *dev_priv)
> > return 0;
> >  }
> >  
> > -
> >  /**
> >   * intel_guc_fetch_fw() - determine and fetch firmware
> >   * @guc:   intel_guc struct
> > @@ -487,39 +482,31 @@ int intel_guc_init_hw(struct drm_i915_private 
> > *dev_priv)
> >  void intel_guc_fetch_fw(struct intel_guc *guc)
> >  {
> > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > -   const char *fw_path;
> >  
> > -   if (!HAS_GUC_UCODE(dev_priv)) {
> > -   fw_path = NULL;
> > -   } else if (IS_SKYLAKE(dev_priv)) {
> > -   fw_path = I915_SKL_GUC_UCODE;
> > +   guc->fw.path = NULL;
> > +   guc->fw.fetch_status = INTEL_UC_FIRMWARE_NONE;
> > +   guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
> > +   guc->fw.fw = INTEL_UC_FW_TYPE_GUC;
> > +
> > +   if (IS_SKYLAKE(dev_priv)) {
> > +   guc->fw.path = I915_SKL_GUC_UCODE;
> > guc->fw.major_ver_wanted = SKL_FW_MAJOR;
> > guc->fw.minor_ver_wanted = SKL_FW_MINOR;
> > } else if (IS_BROXTON(dev_priv)) {
> > -   fw_path = I915_BXT_GUC_UCODE;
> > +   guc->fw.path = I915_BXT_GUC_UCODE;
> > guc->fw.major_ver_wanted = BXT_FW_MAJOR;
> > guc->fw.minor_ver_wanted = BXT_FW_MINOR;
> > } else if (IS_KABYLAKE(dev_priv)) {
> > -   fw_path = I915_KBL_GUC_UCODE;
> > +   guc->fw.path = I915_KBL_GUC_UCODE;
> > guc->fw.major_ver_wanted = KBL_FW_MAJOR;
> > guc->fw.minor_ver_wanted = KBL_FW_MINOR;
> > } else {
> > -   fw_path = "";   /* unknown device */
> > +   DRM_ERROR("No GuC firmware known for platform with GuC!\n");
> > +   i915.enable_guc_loading = 0;
> > +   return;
> 
> Now plan for having fw_path overriden by a i915_param.guc_firmware.
> 
> Perhaps something like
>   if (i915_param.guc_firmware) {
>   guc->fw.path = i915_param.guc_firmware; /* needs 0400! */
>   guc->fw.major_ver_wanted = -1;
>   guc->fw.minor_ver_wanted = -1;
>   } else if (IS_SKYLAKE
> works?

Sorry, I do not quite understand the comment. Can you elaborate?

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw()

[Arkadiusz Hiler]

On Wed, Feb 22, 2017 at 03:59:01PM +0200, Joonas Lahtinen wrote:
> On ke, 2017-02-22 at 13:41 +0100, Arkadiusz Hiler wrote:
> > Trying to have subject_verb_object ordering and more descriptive names,
> > the intel_huc_init() and intel_guc_init() functions are renamed:
> > 
> >  * `intel_guc` is the subject, so those functions now take intel_guc
> >    structure, instead of the dev_priv
> >  * fetch is the verb
> >  * fw is the object which better describes the function's role
> > 
> > Same change is done for the huc counterpart.
> > 
> > Also we bulk call both functions from higher-level intel_uc_fetch_fw:
> >  * intel being the subject (taking the dev_priv as param)
> >  * fetch being the verb
> >  * uc_fw being the subject
> > 
> > v2: settle on intel_uc_fetch_fw name (M. Wajdeczko)
> > 
> > Cc: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Michal Wajdeczko 
> > Cc: Michal Winiarski 
> > Signed-off-by: Arkadiusz Hiler 
> 
> 
> 
> > @@ -609,8 +609,7 @@ static int i915_load_modeset_init(struct drm_device 
> > *dev)
> >     if (ret)
> >     goto cleanup_irq;
> >  
> > -   intel_huc_init(dev_priv);
> > -   intel_guc_init(dev_priv);
> > +   intel_uc_fetch_fw(dev_priv);
> 
> intel_uc_init fits this context. (See below)

Answer below.

> 
> >  /**
> > - * intel_guc_init() - define parameters and fetch firmware
> > - * @dev_priv:  i915 device private
> > + * intel_guc_fetch_fw() - define parameters and fetch firmware
> > + * @guc:   intel_guc struct
> >   *
> >   * Called early during driver load, but after GEM is initialised.
> >   *
> >   * The firmware will be transferred to the GuC's memory later,
> >   * when intel_guc_init_hw() is called.
> >   */
> 
> "define parameters" is little vague, maybe "select and fetch firmware"?

I like those verbs. Let start using it through the whole thing!

> 
> > -void intel_guc_init(struct drm_i915_private *dev_priv)
> > +void intel_guc_fetch_fw(struct intel_guc *guc)
> >  {
> > -   struct intel_uc_fw *guc_fw = _priv->guc.fw;
> > +   struct drm_i915_private *dev_priv = guc_to_i915(guc);
> >     const char *fw_path;
> >  
> >     if (!HAS_GUC(dev_priv)) {
> 
> This parameter dance needs to be moved away from guc_fetch_fw function,
> into intel_sanitize_options (I'm pretty sure I've mentioned this
> earlier).

This is removed in patch 8, as the fetch_fw is called conditionally.

> > @@ -751,23 +751,23 @@ void intel_guc_init(struct drm_i915_private *dev_priv)
> >     fw_path = NULL;
> >     } else if (IS_SKYLAKE(dev_priv)) {
> >     fw_path = I915_SKL_GUC_UCODE;
> > -   guc_fw->major_ver_wanted = SKL_FW_MAJOR;
> > -   guc_fw->minor_ver_wanted = SKL_FW_MINOR;
> > +   guc->fw.major_ver_wanted = SKL_FW_MAJOR;
> > +   guc->fw.minor_ver_wanted = SKL_FW_MINOR;
> >     } else if (IS_BROXTON(dev_priv)) {
> >     fw_path = I915_BXT_GUC_UCODE;
> > -   guc_fw->major_ver_wanted = BXT_FW_MAJOR;
> > -   guc_fw->minor_ver_wanted = BXT_FW_MINOR;
> > +   guc->fw.major_ver_wanted = BXT_FW_MAJOR;
> > +   guc->fw.minor_ver_wanted = BXT_FW_MINOR;
> >     } else if (IS_KABYLAKE(dev_priv)) {
> >     fw_path = I915_KBL_GUC_UCODE;
> > -   guc_fw->major_ver_wanted = KBL_FW_MAJOR;
> > -   guc_fw->minor_ver_wanted = KBL_FW_MINOR;
> > +   guc->fw.major_ver_wanted = KBL_FW_MAJOR;
> > +   guc->fw.minor_ver_wanted = KBL_FW_MINOR;
> >     } else {
> >     fw_path = "";   /* unknown device */
> >     }
> >  
> > -   guc_fw->path = fw_path;
> > -   guc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE;
> > -   guc_fw->load_status = INTEL_UC_FIRMWARE_NONE;
> > +   guc->fw.path = fw_path;
> 
> Just get rid of fw_path variable and assign directly, also hoist the
> warning to the else branch, which can then do "return;"

This is done done in patch 8.

> > +   guc->fw.fetch_status = INTEL_UC_FIRMWARE_NONE;
> > +   guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
> 
> Hoist this assignment before the if block, so no need to special for
> the early return from else branch.

This is done done in patch 8.

> 
> 
> >  /**
> > - * intel_huc_init() - initiate HuC firmware loading request
> > - * @dev_priv: the drm_i915_private device
> > + * intel_huc_fetch_fw() - initiate HuC firmware loading request
> 
> Correct this commit too to be more descriptive.

Okay.

> > + * @huc:   intel_huc struct
> >   *
> >   * Called early during driver load, but after GEM is initialised. The 
> > loading
> >   * will continue only when driver explicitly specify firmware name and 
> > version.
> > @@ -152,42 +152,41 @@ static int huc_ucode_xfer(struct drm_i915_private 
> > *dev_priv)
> >   *
> >   * The DMA-copying to HW is done later when intel_huc_init_hw() is called.
> >   */
> > -void intel_huc_init(struct drm_i915_private *dev_priv)
> > +void 

[Intel-gfx] [PATCH 1/3] drm/i915/perf: improve invalid OA format debug message

[Robert Bragg]

A minor improvement to debugging output

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

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 383b5769a851..19d0e4222974 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1898,11 +1898,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
break;
case DRM_I915_PERF_PROP_OA_FORMAT:
if (value == 0 || value >= I915_OA_FORMAT_MAX) {
-   DRM_DEBUG("Invalid OA report format\n");
+   DRM_DEBUG("Out-of-range OA report format 
%llu\n",
+ value);
return -EINVAL;
}
if (!dev_priv->perf.oa.oa_formats[value].size) {
-   DRM_DEBUG("Invalid OA report format\n");
+   DRM_DEBUG("Unsupported OA report format %llu\n",
+ value);
return -EINVAL;
}
props->oa_format = value;
-- 
2.11.1

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

[Intel-gfx] [PATCH 3/3] drm/i915/perf: rate limit spurious oa report notice

[Robert Bragg]

This change is pre-emptively aiming to avoid a potential cause of kernel
logging noise in case some condition were to result in us seeing invalid
OA reports.

The workaround for the OA unit's tail pointer race condition is what
avoids the primary know cause of invalid reports being seen and with
that in place we aren't expecting to see this notice but it can't be
entirely ruled out.

Just in case some condition does lead to the notice then it's likely
that it will be triggered repeatedly while attempting to append a
sequence of reports and depending on the configured OA sampling
frequency that might be a large number of repeat notices.

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

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d04ebaa8406e..a901bcd80263 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -632,7 +632,8 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
 * copying it to userspace...
 */
if (report32[0] == 0) {
-   DRM_NOTE("Skipping spurious, invalid OA report\n");
+   if (printk_ratelimit())
+   DRM_NOTE("Skipping spurious, invalid OA 
report\n");
continue;
}
 
-- 
2.11.1

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

[Intel-gfx] [PATCH 0/3] Some minor i915-perf prep changes

[Robert Bragg]

A small set of i915 perf changes that could ideally land before the gen8+
patches I hope to send out soon.

These are based on top of the gen7 tail pointer race workaround changes that
were sent out recently.

Robert Bragg (3):
  drm/i915/perf: improve invalid OA format debug message
  drm/i915/perf: better pipeline aged/aging tail updates
  drm/i915/perf: rate limit spurious oa report notice

 drivers/gpu/drm/i915/i915_perf.c | 50 +++-
 1 file changed, 29 insertions(+), 21 deletions(-)

-- 
2.11.1

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

[Intel-gfx] [PATCH v2] drm/i915/lspcon: Switch back to PCON mode after output replug

[Imre Deak]

At least a ParadTech PS175 LSPCON chip/firmware uses long instead of
short pulses to signal output unplug/plug events. This is contrary to
how branch devices normally work which use short HPD signaling. This
chip will also switch to LS mode after an unplug event, which could be
the consequence of the long HPD signaling semantics and an effort to
save power automatically. Because of this we'll fail to do AUX and
detect the output after a replug event.

To fix this make sure we are in PCON mode during connector detection.

v2:
- Switch the mode in the proper spot.

Cc: raptort...@gmail.com
Cc: Shashank Sharma 
Cc: Ville Syrjälä 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98912
Reported-and-tested-by: raptort...@gmail.com
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 024798a..e1529ff 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4326,9 +4326,13 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 static enum drm_connector_status
 intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 {
+   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
uint8_t *dpcd = intel_dp->dpcd;
uint8_t type;
 
+   if (lspcon->active)
+   lspcon_resume(lspcon);
+
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
 
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH v2 13/15] drm/i915: Refactor direct GPU reset from request waiters

[Tvrtko Ursulin]

On 22/02/2017 14:26, Chris Wilson wrote:

On Wed, Feb 22, 2017 at 02:16:49PM +, Tvrtko Ursulin wrote:


On 22/02/2017 11:46, Chris Wilson wrote:

Combine the common code for the pair of waiters into a single function.

Signed-off-by: Chris Wilson 
---
drivers/gpu/drm/i915/i915_gem_request.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 42250eaf56ec..66d292384e60 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1024,6 +1024,16 @@ bool __i915_spin_request(const struct 
drm_i915_gem_request *req,
return false;
}

+static bool __i915_reset_request(struct drm_i915_gem_request *request)
+{
+   if (likely(!i915_reset_in_progress(>i915->gpu_error)))
+   return false;
+
+   __set_current_state(TASK_RUNNING);
+   i915_reset(request->i915);
+   return true;
+}



Okay in principle just unclear from the code now what it does. I
suggest __i915_check_and_reset_request or
__i915_request_check_and_reset so it is obvious the statement not
only checks but also does stuff.


__i915_wait_request_check_and_reset ?

Looking at it keeping the i915_wait_request in there to show it's a
dedicated helper will also be sensible.


Sounds good to me.

Regards,

Tvrtko

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