Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

[Saarinen, Jani]

> == Series Details ==
> 
> Series: drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+
> URL   : https://patchwork.freedesktop.org/series/14426/
> State : warning
> 
> == Summary ==
> 
> Series 14426v1 drm/i915/fbc: Assume maximum 8mb of stolen is used for
> gen8+
> https://patchwork.freedesktop.org/api/1.0/series/14426/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (fi-ilk-650)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-skl-6770hq)
https://bugs.freedesktop.org/show_bug.cgi?id=97929 still there.

> dmesg-warn -> PASS   (fi-ilk-650)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31
> fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61
> fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26
> fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23
> fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14
> fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38
> 
> 0eefa35311a3d85e6cbfda4bb326809581acc3b1 drm-intel-nightly: 2016y-10m-
> 26d-17h-38m-29s UTC integration manifest 2412c2c drm/i915/fbc: Assume
> maximum 8mb of stolen is used for gen8+
> 
> Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2830/
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2830/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Show the execlist queue in debugfs/i915_engine_info

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915: Show the execlist queue in 
debugfs/i915_engine_info
URL   : https://patchwork.freedesktop.org/series/1/
State : success

== Summary ==

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


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

5854c608e6354948f1f5e6be53132c897d0d4902 drm-intel-nightly: 
2016y-10m-26d-21h-22m-02s UTC integration manifest
44515eb drm/i915: Show the execlist queue in debugfs/i915_engine_info

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2835/

== Logs ==

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

Re: [Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers

[Matt Roper]

On Thu, Oct 27, 2016 at 01:15:03AM +0100, Chris Wilson wrote:
> On Wed, Oct 26, 2016 at 03:51:27PM -0700, Matt Roper wrote:
> > Gen9 has a traditional cursor plane that is mutually exclusive with the
> > system's top-most "universal" plane; it seems likely that two planes are 
> > really
> > a single shared hardware unit with two different register interfaces.  Thus 
> > far
> > i915 has exposed a cursor plane to userspace that's hooked up to the 
> > old-style
> > cursor registers; we just pretended that the top-most universal plane didn't
> > exist and reported one fewer "sprite/overlay" planes for each pipe than the
> > platform technically has.  Let's switch this around so that the cursor 
> > exposed
> > to userspace is actually wired up to the previously-unused top-most 
> > universal
> > plane registers.  With this change we'll still present the same cursor ABI 
> > to
> > userspace that we always have, but internally we'll just be programming a
> > different set of registers and doing so in a way that's more consistent with
> > how all the other gen9 planes work --- less cursor-specific special cases
> > throughout the code.
> 
> But you still report it as PLANE_TYPE_CURSOR right? Otherwise those that
> both expose all the overlay planes and use the legacy cursor abi will be
> trying to use that plane simultaneously via two different paths (and
> clients). Or is this another cap?
>   DRM_CLIENT_CAP_UNIVERSAL_PLANES = no-legacy-cursor-abi

Right, with this patch it's still reported as PLANE_TYPE_CURSOR so
userspace won't see any difference.  The followup work to this will be
to eventually do one of the following:

 * Add a new capability bit "don't need legacy cursor" that disables the
   legacy cursor interfaces (-EINVAL) and makes these repurposed planes
   flip over to PLANE_TYPE_OVERLAY in the plane list for that specific
   client.  Clients that don't set it will continue to see
   PLANE_TYPE_CURSOR as usual.

or

 * Always leave the plane as DRM_PLANE_TYPE_CURSOR for all clients, but
   add some extra properties to them that hint to userspace that the
   plane might be more capable than a traditional cursor in some ways.
   Userspace could then do atomic TEST_ONLY to see whether the cursor is
   actually featureful enough to meet its general plane needs and just
   use it like an extra overlay if that turns out to be true.  In this
   case userspace should be smart enough to realize it's already using
   the cursor as a full-featured plane and not try to also submit
   conflicting legacy ioctls against it.

We actually have some experimental patches on an internal tree that use
the first approach above, but I'm open to either approach going forward.
Either way, I think the first step is to just make sure we're doing our
internal programming via the universal plane registers, regardless of
how the plane gets exposed to userspace.

Those next steps are probably something to discuss at the general DRM
level; my understanding is that a lot of ARM platforms don't really have
dedicated cursors at all, so *all* of their cursor planes are actually
repurposed sprites that could probably be put to better use in some
use cases.


Matt

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers

[Chris Wilson]

On Wed, Oct 26, 2016 at 03:51:27PM -0700, Matt Roper wrote:
> Gen9 has a traditional cursor plane that is mutually exclusive with the
> system's top-most "universal" plane; it seems likely that two planes are 
> really
> a single shared hardware unit with two different register interfaces.  Thus 
> far
> i915 has exposed a cursor plane to userspace that's hooked up to the old-style
> cursor registers; we just pretended that the top-most universal plane didn't
> exist and reported one fewer "sprite/overlay" planes for each pipe than the
> platform technically has.  Let's switch this around so that the cursor exposed
> to userspace is actually wired up to the previously-unused top-most universal
> plane registers.  With this change we'll still present the same cursor ABI to
> userspace that we always have, but internally we'll just be programming a
> different set of registers and doing so in a way that's more consistent with
> how all the other gen9 planes work --- less cursor-specific special cases
> throughout the code.

But you still report it as PLANE_TYPE_CURSOR right? Otherwise those that
both expose all the overlay planes and use the legacy cursor abi will be
trying to use that plane simultaneously via two different paths (and
clients). Or is this another cap?
DRM_CLIENT_CAP_UNIVERSAL_PLANES = no-legacy-cursor-abi
-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 6/6] drm/i915/scheduler: Support user-defined priorities

[Chris Wilson]

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

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

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

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

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 19 +++
 drivers/gpu/drm/i915/i915_gem_request.c |  2 +-
 include/uapi/drm/i915_drm.h |  3 +++
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 075ce2b503ed..b909a9ba6722 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -948,6 +948,7 @@ struct i915_gem_context {
/* Unique identifier for this context, used by the hw for tracking */
unsigned int hw_id;
u32 user_handle;
+   int priority; /* greater priorities are serviced first */
 
u32 ggtt_alignment;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 34daef828dca..f688807b1c06 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1095,6 +1095,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
args->value = !!(ctx->flags & CONTEXT_NO_ERROR_CAPTURE);
break;
+   case I915_CONTEXT_PARAM_PRIORITY:
+   args->value = ctx->priority;
+   break;
default:
ret = -EINVAL;
break;
@@ -1150,6 +1153,22 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
ctx->flags &= ~CONTEXT_NO_ERROR_CAPTURE;
}
break;
+
+   case I915_CONTEXT_PARAM_PRIORITY:
+   {
+   int priority = args->value;
+
+   if (args->size)
+   ret = -EINVAL;
+   else if (priority >= 1024 || priority <= -1024)
+   ret = -EINVAL;
+   else if (priority > 0 && !capable(CAP_SYS_ADMIN))
+   ret = -EPERM;
+   else
+   ctx->priority = priority;
+   }
+   break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a62911a6a5fa..cab40e3d044a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -821,7 +821,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
 * run at the earliest possible convenience.
 */
if (engine->schedule)
-   engine->schedule(request, 0);
+   engine->schedule(request, request->ctx->priority);
 
local_bh_disable();
i915_sw_fence_commit(>submit);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f51d429feaae..9fa5eee64f6b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -404,6 +404,8 @@ typedef struct drm_i915_irq_wait {
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
+ * The initial priority for each batch is supplied by the context and is
+ * controlled via I915_CONTEXT_PARAM_PRIORITY.
  */
 #define I915_PARAM_HAS_SCHEDULER43
 
@@ -1283,6 +1285,7 @@ struct drm_i915_gem_context_param {
 #define I915_CONTEXT_PARAM_NO_ZEROMAP  0x2
 #define I915_CONTEXT_PARAM_GTT_SIZE0x3
 #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE0x4
+#define I915_CONTEXT_PARAM_PRIORITY0x5
__u64 value;
 };
 
-- 
2.10.1

___
Intel-gfx mailing list

[Intel-gfx] [PATCH 4/6] drm/i915/scheduler: Execute requests in order of priorities

[Chris Wilson]

Track the priority of each request and use it to determine the order in
which we submit requests to the hardware via execlists.

The priority of the request is determined by the user (eventually via
the context) but may be overridden at any time by the driver. When we set
the priority of the request, we bump the priority of all of its
dependencies to match - so that a high priority drawing operation is not
stuck behind a background task.

When the request is ready to execute (i.e. we have signaled the submit
fence following completion of all its dependencies, including third
party fences), we put the request into a priority sorted rbtree to be
submitted to the hardware. If the request is higher priority than all
pending requests, it will be submitted on the next context-switch
interrupt as soon as the hardware has completed the current request. We
do not currently preempt any current execution to immediately run a very
high priority request, at least not yet.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  7 ++-
 drivers/gpu/drm/i915/i915_gem.c|  3 +-
 drivers/gpu/drm/i915/i915_gem_request.c|  4 ++
 drivers/gpu/drm/i915/i915_gem_request.h|  5 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  1 +
 drivers/gpu/drm/i915/intel_engine_cs.c |  3 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 93 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  3 +-
 8 files changed, 103 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e9382ea2e626..fcf171e468c6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -631,8 +631,9 @@ static void print_request(struct seq_file *m,
  struct drm_i915_gem_request *rq,
  const char *prefix)
 {
-   seq_printf(m, "%s%x [%x:%x] @ %d: %s\n", prefix,
+   seq_printf(m, "%s%x [%x:%x] prio=%d @ %dms: %s\n", prefix,
   rq->global_seqno, rq->ctx->hw_id, rq->fence.seqno,
+  rq->priotree.priority,
   jiffies_to_msecs(jiffies - rq->emitted_jiffies),
   rq->timeline->common->name);
 }
@@ -3219,6 +3220,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
 
if (i915.enable_execlists) {
u32 ptr, read, write;
+   struct rb_node *rb;
 
seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3258,7 +3260,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
rcu_read_unlock();
 
spin_lock_irq(>execlist_lock);
-   list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
+   for (rb = engine->execlist_first; rb; rb = rb_next(rb)) 
{
+   rq = rb_entry(rb, typeof(*rq), priotree.node);
print_request(m, rq, "\t\tQ ");
}
spin_unlock_irq(>execlist_lock);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bdc18c680afe..5a29b2bf9750 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2683,10 +2683,11 @@ static void i915_gem_cleanup_engine(struct 
intel_engine_cs *engine)
 
if (i915.enable_execlists) {
spin_lock(>execlist_lock);
-   INIT_LIST_HEAD(>execlist_queue);
i915_gem_request_put(engine->execlist_port[0].request);
i915_gem_request_put(engine->execlist_port[1].request);
memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
+   engine->execlist_queue = RB_ROOT;
+   engine->execlist_first = NULL;
spin_unlock(>execlist_lock);
}
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index cf06b036b47a..a62911a6a5fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -141,6 +141,8 @@ i915_priotree_fini(struct i915_priotree *pt)
 {
struct i915_dependency *dep, *next;
 
+   GEM_BUG_ON(!RB_EMPTY_NODE(>node));
+
/* Everyone we depended upon should retire before us and remove
 * themselves from our list. However, retirement is run independently
 * on each timeline and so we may be called out-of-order.
@@ -164,6 +166,8 @@ i915_priotree_init(struct i915_priotree *pt)
 {
INIT_LIST_HEAD(>pre_list);
INIT_LIST_HEAD(>post_list);
+   RB_CLEAR_NODE(>node);
+   pt->priority = INT_MIN;
 }
 
 void i915_gem_retire_noop(struct i915_gem_active *active,
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 

[Intel-gfx] [PATCH 5/6] drm/i915/scheduler: Boost priorities for flips

[Chris Wilson]

Boost the priority of any rendering required to show the next pageflip
as we want to avoid missing the vblank by being delayed by invisible
workload. We prioritise avoiding jank and jitter in the GUI over
starving background tasks.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 
 drivers/gpu/drm/i915/i915_gem.c  | 54 
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 3 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a53c80172752..075ce2b503ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3386,6 +3386,11 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 unsigned int flags,
 long timeout,
 struct intel_rps_client *rps);
+int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int priority);
+#define I915_PRIORITY_DISPLAY 1024
+
 int __must_check
 i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
  bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a29b2bf9750..055c9e48ebe6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -433,6 +433,60 @@ i915_gem_object_wait_reservation(struct reservation_object 
*resv,
return timeout;
 }
 
+static void
+i915_gem_object_boost_fence(struct dma_fence *fence, int boost)
+{
+   struct drm_i915_gem_request *rq;
+   struct intel_engine_cs *engine;
+
+   if (!dma_fence_is_i915(fence))
+   return;
+
+   rq = to_request(fence);
+   if (i915_gem_request_completed(rq))
+   return;
+
+   engine = rq->engine;
+   if (!engine->schedule)
+   return;
+
+   engine->schedule(rq, rq->priotree.priority + boost);
+}
+
+int
+i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int boost)
+{
+   struct dma_fence *excl;
+
+   if (flags & I915_WAIT_ALL) {
+   struct dma_fence **shared;
+   unsigned int count, i;
+   int ret;
+
+   ret = reservation_object_get_fences_rcu(obj->resv,
+   , , );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < count; i++) {
+   i915_gem_object_boost_fence(shared[i], boost);
+   dma_fence_put(shared[i]);
+   }
+
+   kfree(shared);
+   } else {
+   excl = reservation_object_get_excl_rcu(obj->resv);
+   }
+
+   if (excl) {
+   i915_gem_object_boost_fence(excl, boost);
+   dma_fence_put(excl);
+   }
+   return 0;
+}
+
 /**
  * Waits for rendering to the object to be completed
  * @obj: i915 gem object
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 39cda13b6267..45d21421a2be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14213,6 +14213,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
}
}
 
+   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
+
return 0;
 }
 
-- 
2.10.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/scheduler: Record all dependencies upon request construction

[Chris Wilson]

The scheduler needs to know the dependencies of each request for the
lifetime of the request, as it may choose to reschedule the requests at
any time and must ensure the dependency tree is not broken. This is in
additional to using the fence to only allow execution after all
dependencies have been completed.

One option was to extend the fence to support the bidirectional
dependency tracking required by the scheduler. However the mismatch in
lifetimes between the submit fence and the request essentially meant
that we had to build a completely separate struct (and we could not
simply reuse the existing waitqueue in the fence for one half of the
dependency tracking). The extra dependency tracking simply did not mesh
well with the fence, and keeping it separate both keeps the fence
implementation simpler and allows us to extend the dependency tracking
into a priority tree (whilst maintaining support for reordering the
tree).

To avoid the additional allocations and list manipulations, the use of
the priotree is disabled when there are no schedulers to use it.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 71 -
 drivers/gpu/drm/i915/i915_gem_request.h | 23 +++
 2 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 864ab686af33..cf06b036b47a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -113,6 +113,59 @@ i915_gem_request_remove_from_client(struct 
drm_i915_gem_request *request)
spin_unlock(_priv->mm.lock);
 }
 
+static int
+i915_priotree_add_dependency(struct i915_priotree *pt,
+struct i915_priotree *signal,
+struct i915_dependency *dep)
+{
+   unsigned long flags = 0;
+
+   if (!dep) {
+   dep = kmalloc(sizeof(*dep), GFP_KERNEL);
+   if (!dep)
+   return -ENOMEM;
+
+   flags |= I915_DEPENDENCY_ALLOC;
+   }
+
+   dep->signal = signal;
+   dep->flags = flags;
+
+   list_add(>post_link, >post_list);
+   list_add(>pre_link, >pre_list);
+   return 0;
+}
+
+static void
+i915_priotree_fini(struct i915_priotree *pt)
+{
+   struct i915_dependency *dep, *next;
+
+   /* Everyone we depended upon should retire before us and remove
+* themselves from our list. However, retirement is run independently
+* on each timeline and so we may be called out-of-order.
+*/
+   list_for_each_entry_safe(dep, next, >pre_list, pre_link) {
+   list_del(>post_link);
+   if (dep->flags & I915_DEPENDENCY_ALLOC)
+   kfree(dep);
+   }
+
+   /* Remove ourselves from everyone who depends upon us */
+   list_for_each_entry_safe(dep, next, >post_list, post_link) {
+   list_del(>pre_link);
+   if (dep->flags & I915_DEPENDENCY_ALLOC)
+   kfree(dep);
+   }
+}
+
+static void
+i915_priotree_init(struct i915_priotree *pt)
+{
+   INIT_LIST_HEAD(>pre_list);
+   INIT_LIST_HEAD(>post_list);
+}
+
 void i915_gem_retire_noop(struct i915_gem_active *active,
  struct drm_i915_gem_request *request)
 {
@@ -182,6 +235,8 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
i915_gem_context_put(request->ctx);
 
dma_fence_signal(>fence);
+
+   i915_priotree_fini(>priotree);
i915_gem_request_put(request);
 }
 
@@ -441,6 +496,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
   __timeline_get_seqno(req->timeline->common));
 
i915_sw_fence_init(>submit, submit_notify);
+   i915_priotree_init(>priotree);
 
INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
@@ -495,6 +551,14 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,
 
GEM_BUG_ON(to == from);
 
+   if (to->engine->schedule) {
+   ret = i915_priotree_add_dependency(>priotree,
+  >priotree,
+  NULL);
+   if (ret < 0)
+   return ret;
+   }
+
if (to->timeline == from->timeline)
return 0;
 
@@ -718,9 +782,14 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
 
prev = i915_gem_active_raw(>last_request,
   >i915->drm.struct_mutex);
-   if (prev)
+   if (prev) {
i915_sw_fence_await_sw_fence(>submit, >submit,
 >submitq);
+   if (engine->schedule)
+   i915_priotree_add_dependency(>priotree,
+>priotree,
+   

[Intel-gfx] [PATCH 2/6] drm/i915/scheduler: Signal the arrival of a new request

[Chris Wilson]

The start of the scheduler, add a hook into request submission for the
scheduler to see the arrival of new requests and prepare its runqueues.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 
 drivers/gpu/drm/i915/i915_gem_request.c | 13 +
 drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 +
 include/uapi/drm/i915_drm.h |  5 +
 5 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dd02ad69eb7b..11b9f6c38699 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -323,6 +323,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 */
value = i915_gem_mmap_gtt_version();
break;
+   case I915_PARAM_HAS_SCHEDULER:
+   value = dev_priv->engine[RCS] &&
+   dev_priv->engine[RCS]->schedule;
+   break;
case I915_PARAM_MMAP_VERSION:
/* Remember to bump this if the version changes! */
case I915_PARAM_HAS_GEM:
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 2232f86b892d..864ab686af33 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -737,6 +737,19 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
 
i915_gem_mark_busy(engine);
 
+   /* Let the backend know a new request has arrived that may need
+* to adjust the existing execution schedule due to a high priority
+* request - i.e. we may want to preempt the current request in order
+* to run a high priority dependency chain *before* we can execute this
+* request.
+*
+* This is called before the request is ready to run so that we can
+* decide whether to preempt the entire chain so that it is ready to
+* run at the earliest possible convenience.
+*/
+   if (engine->schedule)
+   engine->schedule(request, 0);
+
local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 94de3d66733d..3e8ecbd9b95d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -102,6 +102,9 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;
 
+   /* Nothing to do here, execute in order of dependencies */
+   engine->schedule = NULL;
+
dev_priv->engine[id] = engine;
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index dcb145c67e89..97e162efe557 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -267,6 +267,15 @@ struct intel_engine_cs {
 */
void(*submit_request)(struct drm_i915_gem_request *req);
 
+   /* Call when the priority on a request has changed and it and its
+* dependencies may need rescheduling. Note the request itself may
+* not be ready to run!
+*
+* Called under the struct_mutex.
+*/
+   void(*schedule)(struct drm_i915_gem_request *request,
+   int priority);
+
/* Some chipsets are not quite as coherent as advertised and need
 * an expensive kick to force a true read of the up-to-date seqno.
 * However, the up-to-date seqno is not always required and the last
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a1d04d8bc80a..f51d429feaae 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -402,6 +402,11 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_HAS_EXEC_FENCE   42
 
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
+ * priorities and the driver will attempt to execute batches in priority order.
+ */
+#define I915_PARAM_HAS_SCHEDULER43
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
-- 
2.10.1

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

[Intel-gfx] [PATCH 1/6] drm/i915: Show the execlist queue in debugfs/i915_engine_info

[Chris Wilson]

When looking at freezes whilst working on execlists, knowing the order
of the pending requests in the driver is useful.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 925aaedd7fd9..e9382ea2e626 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3256,6 +3256,12 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
else
seq_printf(m, "\t\tELSP[1] idle\n");
rcu_read_unlock();
+
+   spin_lock_irq(>execlist_lock);
+   list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
+   print_request(m, rq, "\t\tQ ");
+   }
+   spin_unlock_irq(>execlist_lock);
} else if (INTEL_GEN(dev_priv) > 6) {
seq_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
   I915_READ(RING_PP_DIR_BASE(engine)));
-- 
2.10.1

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

[Intel-gfx] Trivial scheduler

[Chris Wilson]

Started out as what intended to be a quick look at how to extend the
fences to support the priority inheritance ended up completing the final
few steps to implement the most trivial priority based scheduler. A lot
of the policy decisions have been left out (such as e.g. only submitting
one request from each context each interrupt) so that it is not very
fine-grained, nor does it implement time-slicing and fair load
balancing, and continues to live in blissful ignorance of the challenge
of preemption. It is also execlists only. It purely serves as fodder to
take the next steps towards a real scheduler, and in the meantime offers
one benefit to current desktops, giving uber priority to the rendering
of the pageflip.

This adds the dependency tracking of the requests required to do
inflight reordering (as distinct from the dependency tracking required
to decide when we can submit the request to hardware) and implements a
priority sorted rbtree of the ready-to-execute requests to be submitted
on the next context-switch.
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm: Define a work struct for scheduling a uevent for modeset retry

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm: Define a work struct for scheduling a 
uevent for modeset retry
URL   : https://patchwork.freedesktop.org/series/14442/
State : failure

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> TIMEOUT(fi-snb-2520m)
Subgroup hang-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:194  pass:164  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

5854c608e6354948f1f5e6be53132c897d0d4902 drm-intel-nightly: 
2016y-10m-26d-21h-22m-02s UTC integration manifest
2953a14 drm/i915: Find fallback link rate/lane count
e208699 drm/i915; Add a function to return index of link rate
119f0ef drm/i915: Change the placement of some static functions in intel_dp.c
5e242c3b drm/i915: Set link status property for DP connector
63e66a6 drm: Add a new connector property for link status
41f2ca3 drm: Define a work struct for scheduling a uevent for modeset retry

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2834/

== Logs ==

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

[Intel-gfx] [PATCH 5/7] drm/i915; Add a function to return index of link rate

[Manasi Navare]

This is required to return the index of link rate into
common_rates array. This gets used to retry the link
training at lower link rate.

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aecfd22..39116c8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,21 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+   int *common_rates, int link_rate)
+{
+   int common_len;
+   int index;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   for (index = 0; index < common_len; index++) {
+   if (link_rate == common_rates[common_len - index - 1])
+   return common_len - index - 1;
+   }
+
+   return -1;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/7] drm: Define a work struct for scheduling a uevent for modeset retry

[Manasi Navare]

This work struct will be used to schedule a uevent on a separate
thread. This will be scheduled after a link train failure during modeset
to indicate a modeset retry request. It will get executed after the
current modeset is complete and all locks are released. This was
required to avoid deadlock.

v2:
* Create a generic work func not i915 specific (Daniel Vetter)

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 

Signed-off-by: Manasi Navare 
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ac9d7d8..fc9d475 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -682,6 +682,11 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+   /* Work struct to schedule a uevent on link train failure for
+* DisplayPort.
+*/
+   struct work_struct modeset_retry_work;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/7] drm: Add a new connector property for link status

[Manasi Navare]

A new default connector property is added for keeping
track of whether the link is good (link training passed) or
link is bad (link training  failed). If the link status property
is not good, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in the mode list
or connector status.

v2:
* Make this a default connector property (Daniel Vetter)

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 17 +
 include/drm/drm_connector.h |  1 -
 include/drm/drm_crtc.h  |  5 +
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2db7fb5..d4e852f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
  config->dpms_property, 0);
 
+   drm_object_attach_property(>base,
+  config->link_status_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -622,6 +632,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.tile_property = prop;
 
+   prop = drm_property_create_enum(dev, 0, "link-status",
+   drm_link_status_enum_list,
+   ARRAY_SIZE(drm_link_status_enum_list));
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.link_status_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fc9d475..3bb420d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -759,7 +759,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
-
 int drm_mode_connector_set_path_property(struct drm_connector *connector,
 const char *path);
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa1aa21..b86ca19 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1151,6 +1151,11 @@ struct drm_mode_config {
 */
struct drm_property *tile_property;
/**
+* @link_status_property: Default connector property for link status
+* of a connector as a result of link training.
+*/
+   struct drm_property *link_status_property;
+   /**
 * @plane_type_property: Default plane property to differentiate
 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 */
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 084b50a..f1b0afd 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -121,6 +121,10 @@
 #define DRM_MODE_DIRTY_ON   1
 #define DRM_MODE_DIRTY_ANNOTATE 2
 
+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD  0
+#define DRM_MODE_LINK_STATUS_BAD   1
+
 struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/7] drm/i915: Set link status property for DP connector

[Manasi Navare]

This defines a helper function to set the property value.
This will be used to set the link status to Bad in case
of link training failures.

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 16 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3c2293b..795897c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4673,6 +4673,22 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
return 0;
 }
 
+int
+intel_dp_set_link_status_property(struct drm_connector *connector,
+ uint64_t val)
+{
+   struct drm_device *dev = connector->dev;
+   int ret = 0;
+
+   ret = drm_object_property_set_value(>base,
+   
dev->mode_config.link_status_property,
+   val);
+   if (ret)
+   return ret;
+
+   return ret;
+}
+
 static int
 intel_dp_connector_register(struct drm_connector *connector)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7dda79d..f6fe05a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1397,6 +1397,8 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb, 
int plane,
 bool intel_dp_init(struct drm_device *dev, i915_reg_t output_reg, enum port 
port);
 bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 struct intel_connector *intel_connector);
+int intel_dp_set_link_status_property(struct drm_connector *connector,
+ uint64_t val);
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  int link_rate, uint8_t lane_count,
  bool link_mst);
-- 
1.9.1

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

[Intel-gfx] [PATCH 4/7] drm/i915: Change the placement of some static functions in intel_dp.c

[Manasi Navare]

From: "Navare, Manasi D" 

These static helper functions are required to be used during
fallback link rate implemnetation so they need to be placed at the top
of the file.

v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 795897c..aecfd22 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -213,6 +213,81 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
*intel_dp)
return max_dotclk;
 }
 
+static int
+intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
+{
+   if (intel_dp->num_sink_rates) {
+   *sink_rates = intel_dp->sink_rates;
+   return intel_dp->num_sink_rates;
+   }
+
+   *sink_rates = default_rates;
+
+   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
+}
+
+static int
+intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   int size;
+
+   if (IS_BROXTON(dev_priv)) {
+   *source_rates = bxt_rates;
+   size = ARRAY_SIZE(bxt_rates);
+   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
+   *source_rates = skl_rates;
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
+   }
+
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (!intel_dp_source_supports_hbr2(intel_dp))
+   size--;
+
+   return size;
+}
+
+static int intersect_rates(const int *source_rates, int source_len,
+  const int *sink_rates, int sink_len,
+  int *common_rates)
+{
+   int i = 0, j = 0, k = 0;
+
+   while (i < source_len && j < sink_len) {
+   if (source_rates[i] == sink_rates[j]) {
+   if (WARN_ON(k >= DP_MAX_SUPPORTED_RATES))
+   return k;
+   common_rates[k] = source_rates[i];
+   ++k;
+   ++i;
+   ++j;
+   } else if (source_rates[i] < sink_rates[j]) {
+   ++i;
+   } else {
+   ++j;
+   }
+   }
+   return k;
+}
+
+static int intel_dp_common_rates(struct intel_dp *intel_dp,
+int *common_rates)
+{
+   const int *source_rates, *sink_rates;
+   int source_len, sink_len;
+
+   sink_len = intel_dp_sink_rates(intel_dp, _rates);
+   source_len = intel_dp_source_rates(intel_dp, _rates);
+
+   return intersect_rates(source_rates, source_len,
+  sink_rates, sink_len,
+  common_rates);
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1291,19 +1366,6 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
intel_dp->aux.transfer = intel_dp_aux_transfer;
 }
 
-static int
-intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
-{
-   if (intel_dp->num_sink_rates) {
-   *sink_rates = intel_dp->sink_rates;
-   return intel_dp->num_sink_rates;
-   }
-
-   *sink_rates = default_rates;
-
-   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
-}
-
 bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -1316,31 +1378,6 @@ bool intel_dp_source_supports_hbr2(struct intel_dp 
*intel_dp)
return false;
 }
 
-static int
-intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
-{
-   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   int size;
-
-   if (IS_BROXTON(dev_priv)) {
-   *source_rates = bxt_rates;
-   size = ARRAY_SIZE(bxt_rates);
-   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
-   *source_rates = skl_rates;
-   size = ARRAY_SIZE(skl_rates);
-   } else {
-   *source_rates = default_rates;
-   size = ARRAY_SIZE(default_rates);
-   }
-
- 

[Intel-gfx] [PATCH 6/7] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 28 
 drivers/gpu/drm/i915/intel_drv.h |  6 ++
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 39116c8..369b5ce 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -303,6 +303,34 @@ static int intel_dp_link_rate_index(struct intel_dp 
*intel_dp,
return -1;
 }
 
+void intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+int link_rate, uint8_t lane_count)
+{
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+   int common_len;
+   int link_rate_index = -1;
+
+   if (!intel_dp->link_train_failed)
+   return;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  link_rate);
+   if (link_rate_index > 0) {
+   intel_dp->fallback_link_rate_index = link_rate_index - 1;
+   intel_dp->fallback_link_rate = 
common_rates[intel_dp->fallback_link_rate_index];
+   intel_dp->fallback_lane_count = 
intel_dp_max_lane_count(intel_dp);
+   } else if (lane_count > 1) {
+   intel_dp->fallback_link_rate_index = common_len -1;
+   intel_dp->fallback_link_rate = 
common_rates[intel_dp->fallback_link_rate_index];
+   intel_dp->fallback_lane_count = lane_count - 1;
+   } else {
+   DRM_ERROR ("Link Training Unsuccessful\n");
+   intel_dp->link_train_failed = false;
+   }
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f6fe05a..c6789ee 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -890,6 +890,10 @@ struct intel_dp {
uint32_t DP;
int link_rate;
uint8_t lane_count;
+   int fallback_link_rate;
+   uint8_t fallback_lane_count;
+   int fallback_link_rate_index;
+   bool link_train_failed;
uint8_t sink_count;
bool link_mst;
bool has_audio;
@@ -1402,6 +1406,8 @@ int intel_dp_set_link_status_property(struct 
drm_connector *connector,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  int link_rate, uint8_t lane_count,
  bool link_mst);
+void intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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

[Intel-gfx] [PATCH 7/7] drm/i915: Link Rate fallback on Link training failure

[Manasi Navare]

If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed and use a lower link rate
to prune the modes. It will redo the modeset on the current mode
at lower link rate or if the current mode gets pruned due to lower
link constraints then, it will send a hotplug uevent for userspace
to handle it.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 22 -
 drivers/gpu/drm/i915/intel_dp.c   | 47 +--
 drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +--
 drivers/gpu/drm/i915/intel_drv.h  |  2 +-
 4 files changed, 75 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fb18d69..11eae06 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1712,6 +1712,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
 
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
@@ -1722,7 +1724,25 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
+   if (!intel_dp_start_link_train(intel_dp)) {
+   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
count = %d",
+ link_rate, lane_count);
+   intel_dp->link_train_failed = true;
+   intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
+   lane_count);
+   /* Schedule a Hotplug Uevent to userspace to start modeset */
+   schedule_work(>modeset_retry_work);
+   } else {
+   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
count = %d",
+ link_rate, lane_count);
+   intel_dp->link_train_failed = false;
+   intel_dp->fallback_link_rate_index = -1;
+   intel_dp->fallback_link_rate = 0;
+   intel_dp->fallback_lane_count = 0;
+   intel_dp_set_link_status_property(connector,
+ DRM_MODE_LINK_STATUS_GOOD);
+   }
+
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 369b5ce..7d5b1a7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -354,8 +354,14 @@ void intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
target_clock = fixed_mode->clock;
}
 
-   max_link_clock = intel_dp_max_link_rate(intel_dp);
-   max_lanes = intel_dp_max_lane_count(intel_dp);
+   /* Prune the modes using the fallback link rate/lane count */
+   if (intel_dp->link_train_failed) {
+   max_link_clock = intel_dp->fallback_link_rate;
+   max_lanes = intel_dp->fallback_lane_count;
+   } else {
+   max_link_clock = intel_dp_max_link_rate(intel_dp);
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   }
 
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1645,6 +1651,12 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;
 
+   /* Fall back to lower link rate in case of failure in previous modeset 
*/
+   if (intel_dp->link_train_failed) {
+   min_lane_count = max_lane_count = intel_dp->fallback_lane_count;
+   min_clock = max_clock = intel_dp->fallback_link_rate_index;
+   }
+
DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %d pixel clock %iKHz\n",
  max_lane_count, common_rates[max_clock],
@@ -4548,7 +4560,7 @@ static bool intel_digital_port_connected(struct 
drm_i915_private *dev_priv,
}
 
/* If full detect is not performed yet, 

Re: [Intel-gfx] [PATCH v2 09/11] drm/i915/gen9+: Program watermarks as a separate step during evasion, v2.

[Matt Roper]

On Wed, Oct 26, 2016 at 03:41:37PM +0200, Maarten Lankhorst wrote:
> The watermark updates for SKL style watermarks are no longer done
> in the plane callbacks, but are now called in a separate watermark
> update function that's called during the same vblank evasion,
> before the plane updates.
> 
> This also gets rid of the global skl_results, which was required for
> keeping track of the current atomic commit.
> 
> Changes since v1:
> - Move line unwrap to correct patch. (Lyude)
> - Make sure we don't regress ILK watermarks. (Matt)
> - Rephrase commit message. (Matt)
> 
...
> @@ -14459,8 +14436,17 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   intel_check_cpu_fifo_underruns(dev_priv);
>   intel_check_pch_fifo_underruns(dev_priv);
>  
> - if (!crtc->state->active)
> - intel_update_watermarks(crtc);
> + if (!crtc->state->active) {
> + /*
> +  * Make sure we don't call initial_watermarks
> +  * for ILK-style watermark updates.
> +  */
> + if (HAS_DDI(dev_priv) && 
> dev_priv->display.initial_watermarks)

Aren't HSW/BDW DDI platforms?  They still use the ILK-style watermarks,
so I don't think this is protecting all the platforms it needs to.

Even if that weren't the case, I wouldn't be wild about using HAS_DDI
here since whether or not a platform has DDI isn't really the reason
we're programming watermarks differently so the code is a bit confusing
to the casual reader.


Matt

> + 
> dev_priv->display.initial_watermarks(intel_state,
> +  
> to_intel_crtc_state(crtc->state));
> + else
> + intel_update_watermarks(crtc);
> + }
>   }
>   }
>  
> @@ -14631,7 +14617,6 @@ static int intel_atomic_commit(struct drm_device *dev,
>  
>   drm_atomic_helper_swap_state(state, true);
>   dev_priv->wm.distrust_bios_wm = false;
> - dev_priv->wm.skl_results = intel_state->wm_results;
>   intel_shared_dpll_commit(state);
>   intel_atomic_track_fbs(state);
>  
> @@ -14939,7 +14924,7 @@ static void intel_begin_crtc_commit(struct drm_crtc 
> *crtc,
>   intel_pipe_update_start(intel_crtc);
>  
>   if (modeset)
> - return;
> + goto out;
>  
>   if (crtc->state->color_mgmt_changed || 
> to_intel_crtc_state(crtc->state)->update_pipe) {
>   intel_color_set_csc(crtc->state);
> @@ -14951,6 +14936,7 @@ static void intel_begin_crtc_commit(struct drm_crtc 
> *crtc,
>   else if (INTEL_GEN(dev_priv) >= 9)
>   skl_detach_scalers(intel_crtc);
>  
> +out:
>   if (dev_priv->display.atomic_evade_watermarks)
>   
> dev_priv->display.atomic_evade_watermarks(to_intel_atomic_state(old_crtc_state->state),
>  intel_cstate);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 77a0a73e37b0..2cd7c5fd9ebd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1747,13 +1747,6 @@ bool skl_ddb_allocation_equals(const struct 
> skl_ddb_allocation *old,
>  enum pipe pipe);
>  bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
>struct intel_crtc *intel_crtc);
> -void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
> -  const struct skl_plane_wm *wm,
> -  const struct skl_ddb_allocation *ddb);
> -void skl_write_plane_wm(struct intel_crtc *intel_crtc,
> - const struct skl_plane_wm *wm,
> - const struct skl_ddb_allocation *ddb,
> - int plane);
>  uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
>  bool ilk_disable_lp_wm(struct drm_device *dev);
>  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fe4bc97ed56a..e2541539967b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4201,26 +4201,35 @@ skl_compute_wm(struct drm_atomic_state *state)
>   return 0;
>  }
>  
> -static void skl_evade_crtc_wm(struct intel_atomic_state *state,
> -   struct intel_crtc_state *cstate)
> +static void skl_evade_crtc_wm(struct intel_atomic_state *state, struct 
> intel_crtc_state *cstate)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(cstate->base.crtc);
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   struct skl_pipe_wm *pipe_wm = >wm.skl.optimal;
> + const struct skl_ddb_allocation *ddb = 

[Intel-gfx] ✓ Fi.CI.BAT: success for Wire gen9 cursor interface to universal plane registers

[Patchwork]

== Series Details ==

Series: Wire gen9 cursor interface to universal plane registers
URL   : https://patchwork.freedesktop.org/series/14440/
State : success

== Summary ==

Series 14440v1 Wire gen9 cursor interface to universal plane registers
https://patchwork.freedesktop.org/api/1.0/series/14440/revisions/1/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

5854c608e6354948f1f5e6be53132c897d0d4902 drm-intel-nightly: 
2016y-10m-26d-21h-22m-02s UTC integration manifest
8db2854 drm/i915/gen9: Skip debugfs cursor output for universal plane platforms
9f8edab drm/i915/gen9: Expose top-most universal plane as cursor
471d03b drm/i915: Use macro in place of open-coded for_each_universal_plane loop
b7f616e drm/i915: Rename for_each_plane -> for_each_universal_plane

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2833/

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915/gen9+: Use the watermarks from crtc_state for everything, v2.

[Matt Roper]

On Wed, Oct 26, 2016 at 03:41:36PM +0200, Maarten Lankhorst wrote:
> There's no need to keep a duplicate skl_pipe_wm around any more,
> everything can be discovered from crtc_state, which we pass around
> correctly now even in case of plane disable.
> 
> The copy in intel_crtc->wm.skl.active is equal to
> crtc_state->wm.skl.optimal after the atomic commit completes.
> It's useful for two-step watermark programming, but not required for
> gen9+ which does it in a single step. We can pull the old allocation
> from old_crtc_state.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Matt Roper 
> Reviewed-by: Paulo Zanoni 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_display.c |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h |  1 -
>  drivers/gpu/drm/i915/intel_pm.c  | 18 --
>  3 files changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 48eb0635ec0f..592a6ec354a7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13478,7 +13478,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
>   return;
>  
>   skl_pipe_wm_get_hw_state(crtc, _wm);
> - sw_wm = _crtc->wm.active.skl;
> + sw_wm = _intel_crtc_state(new_state)->wm.skl.optimal;
>  
>   skl_ddb_get_hw_state(dev_priv, _ddb);
>   sw_ddb = _priv->wm.skl_hw.ddb;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 73be640fad36..77a0a73e37b0 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -723,7 +723,6 @@ struct intel_crtc {
>   /* watermarks currently being used  */
>   union {
>   struct intel_pipe_wm ilk;
> - struct skl_pipe_wm skl;
>   } active;
>  
>   /* allow CxSR on this pipe */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5ff35833b258..fe4bc97ed56a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3930,11 +3930,11 @@ bool skl_ddb_allocation_overlaps(struct 
> drm_atomic_state *state,
>  }
>  
>  static int skl_update_pipe_wm(struct drm_crtc_state *cstate,
> -   struct skl_ddb_allocation *ddb, /* out */
> +   const struct skl_pipe_wm *old_pipe_wm,
> struct skl_pipe_wm *pipe_wm, /* out */
> +   struct skl_ddb_allocation *ddb, /* out */
> bool *changed /* out */)
>  {
> - struct intel_crtc *intel_crtc = to_intel_crtc(cstate->crtc);
>   struct intel_crtc_state *intel_cstate = to_intel_crtc_state(cstate);
>   int ret;
>  
> @@ -3942,7 +3942,7 @@ static int skl_update_pipe_wm(struct drm_crtc_state 
> *cstate,
>   if (ret)
>   return ret;
>  
> - if (!memcmp(_crtc->wm.active.skl, pipe_wm, sizeof(*pipe_wm)))
> + if (!memcmp(old_pipe_wm, pipe_wm, sizeof(*pipe_wm)))
>   *changed = false;
>   else
>   *changed = true;
> @@ -4177,10 +4177,12 @@ skl_compute_wm(struct drm_atomic_state *state)
>   for_each_crtc_in_state(state, crtc, cstate, i) {
>   struct intel_crtc_state *intel_cstate =
>   to_intel_crtc_state(cstate);
> + const struct skl_pipe_wm *old_pipe_wm =
> + _intel_crtc_state(crtc->state)->wm.skl.optimal;
>  
>   pipe_wm = _cstate->wm.skl.optimal;
> - ret = skl_update_pipe_wm(cstate, >ddb, pipe_wm,
> -  );
> + ret = skl_update_pipe_wm(cstate, old_pipe_wm, pipe_wm,
> +  >ddb, );
>   if (ret)
>   return ret;
>  
> @@ -4224,8 +4226,6 @@ static void skl_update_wm(struct drm_crtc *crtc)
>   if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
>   return;
>  
> - intel_crtc->wm.active.skl = *pipe_wm;
> -
>   mutex_lock(_priv->wm.wm_mutex);
>  
>   /*
> @@ -4395,10 +4395,8 @@ void skl_wm_get_hw_state(struct drm_device *dev)
>  
>   skl_pipe_wm_get_hw_state(crtc, >wm.skl.optimal);
>  
> - if (intel_crtc->active) {
> + if (intel_crtc->active)
>   hw->dirty_pipes |= drm_crtc_mask(crtc);
> - intel_crtc->wm.active.skl = cstate->wm.skl.optimal;
> - }
>   }
>  
>   if (dev_priv->active_crtcs) {
> -- 
> 2.7.4
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 07/11] drm/i915: Add a atomic evasion step to watermark programming, v2.

[Matt Roper]

Minor grammar fix in the headline...it should be "an atomic" rather than
"a atomic."  Sorry I missed that the first time around.

I know i915 tends to be somewhat lax about adhering to the 80-character
line limit, but the lines that add the extra parameter are starting to
get _really_ long now, so it would be good to wrap them if possible.

Otherwise the change here look good to me, so with the minor cosmetic
stuff fixed,

Reviewed-by: Matt Roper 


Matt

On Wed, Oct 26, 2016 at 03:41:35PM +0200, Maarten Lankhorst wrote:
> Allow the driver to write watermarks during atomic evasion.
> This will make it possible to write the watermarks in a cleaner
> way on gen9+.
> 
> intel_atomic_state is not used here yet, but will be used when
> we program all watermarks as a separate step during evasion.
> 
> This also writes linetime all the time, while before it was only
> done during plane updates. This looks like this could be a bugfix,
> but I'm not sure what it affects.
> 
> Changes since v1:
> - Add comment about atomic evasion to commit message.
> - Unwrap I915_WRITE call. (Lyude)
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Matt Roper 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  6 --
>  drivers/gpu/drm/i915/intel_display.c | 20 +---
>  drivers/gpu/drm/i915/intel_pm.c  | 18 --
>  3 files changed, 29 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7a621c74254e..7a477d6a486e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -485,6 +485,7 @@ struct sdvo_device_mapping {
>  
>  struct intel_connector;
>  struct intel_encoder;
> +struct intel_atomic_state;
>  struct intel_crtc_state;
>  struct intel_initial_plane_config;
>  struct intel_crtc;
> @@ -498,8 +499,9 @@ struct drm_i915_display_funcs {
>   int (*compute_intermediate_wm)(struct drm_device *dev,
>  struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *newstate);
> - void (*initial_watermarks)(struct intel_crtc_state *cstate);
> - void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> + void (*initial_watermarks)(struct intel_atomic_state *state, struct 
> intel_crtc_state *cstate);
> + void (*atomic_evade_watermarks)(struct intel_atomic_state *state, 
> struct intel_crtc_state *cstate);
> + void (*optimize_watermarks)(struct intel_atomic_state *state, struct 
> intel_crtc_state *cstate);
>   int (*compute_global_watermarks)(struct drm_atomic_state *state);
>   void (*update_wm)(struct drm_crtc *crtc);
>   int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9ea9a3bc0bc0..48eb0635ec0f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5170,7 +5170,7 @@ static void intel_pre_plane_update(struct 
> intel_crtc_state *old_crtc_state)
>* us to.
>*/
>   if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(pipe_config);
> + 
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> pipe_config);
>   else if (pipe_config->update_wm_pre)
>   intel_update_watermarks(>base);
>  }
> @@ -5384,7 +5384,7 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   intel_color_load_luts(_config->base);
>  
>   if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(intel_crtc->config);
> + 
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> intel_crtc->config);
>   intel_enable_pipe(intel_crtc);
>  
>   if (intel_crtc->config->has_pch_encoder)
> @@ -5490,7 +5490,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   intel_ddi_enable_transcoder_func(crtc);
>  
>   if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(pipe_config);
> + 
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
> pipe_config);
>   else
>   intel_update_watermarks(crtc);
>  
> @@ -14526,7 +14526,7 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   intel_cstate = to_intel_crtc_state(crtc->state);
>  
>   if (dev_priv->display.optimize_watermarks)
> - dev_priv->display.optimize_watermarks(intel_cstate);
> + dev_priv->display.optimize_watermarks(intel_state, 
> intel_cstate);
>   }
>  
>   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
> @@ -14934,7 +14934,6 

[Intel-gfx] [RFC 3/4] drm/i915/gen9: Expose top-most universal plane as cursor

[Matt Roper]

Gen9 has a traditional cursor plane that is mutually exclusive with the
system's top-most "universal" plane; it seems likely that two planes are
really a single shared hardware unit with two different register
interfaces.  Thus far i915 has exposed a cursor plane to userspace
that's hooked up to the old-style cursor registers; we just pretended
that the top-most universal plane didn't exist and reported one fewer
"sprite/overlay" planes for each pipe than the platform technically has.
Let's switch this around so that the cursor exposed to userspace is
actually wired up to top-most universal plane registers.  We'll continue
to present the same cursor ABI to userspace that we always have, but
internally we'll just be programming a different set of registers and
doing so in a way that's more consistent with how all the other gen9
planes work --- less cursor-specific special cases throughout the code.

Aside from making the code a bit simpler (fewer cursor-specific special
cases), this will also pave the way to eventually exposing the top-most
plane in a more full-featured manner to userspace clients that don't
need a traditional cursor and wish to opt into having access to an
additional sprite/overlay-style plane instead.

It's worth noting that a lot of the special-cased cursor-specific code
was in the gen9 watermark programming.  It's good to simplify that code,
but we should keep an eye out for any unwanted side effects of this
patch; since sprites/overlays tend to get used less than cursors, it's
possible that this could help us uncover additional underruns that
nobody had run across yet.  Or it could have the opposite effect and
eliminate some of the underruns that we haven't been able to get rid of
yet.

Cc: Bob Paauwe 
Cc: Maarten Lankhorst 
Cc: Paulo Zanoni 
Cc: Lyude Paul 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  4 --
 drivers/gpu/drm/i915/i915_drv.h  | 11 +++-
 drivers/gpu/drm/i915/intel_device_info.c | 38 +
 drivers/gpu/drm/i915/intel_display.c | 97 
 drivers/gpu/drm/i915/intel_drv.h |  7 +++
 drivers/gpu/drm/i915/intel_pm.c  | 85 
 drivers/gpu/drm/i915/intel_sprite.c  |  6 +-
 7 files changed, 93 insertions(+), 155 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9f5a392..0bba472 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3469,10 +3469,6 @@ static int i915_ddb_info(struct seq_file *m, void 
*unused)
   entry->start, entry->end,
   skl_ddb_entry_size(entry));
}
-
-   entry = >plane[pipe][PLANE_CURSOR];
-   seq_printf(m, "  %-13s%8u%8u%8u\n", "Cursor", entry->start,
-  entry->end, skl_ddb_entry_size(entry));
}
 
drm_modeset_unlock_all(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4714051..83aaed2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -178,7 +178,7 @@ enum plane {
PLANE_A = 0,
PLANE_B,
PLANE_C,
-   PLANE_CURSOR,
+   PLANE_D,
I915_MAX_PLANES,
 };
 #define plane_name(p) ((p) + 'A')
@@ -316,9 +316,15 @@ struct i915_hotplug {
for ((__p) = 0; \
 (__p) < INTEL_INFO(__dev_priv)->num_sprites[(__pipe)] + 1; \
 (__p)++)
+
+/*
+ * Only iterate over sprites exposed as sprites; omit sprites that
+ * are being repurposed to simulate a cursor.
+ */
 #define for_each_sprite(__dev_priv, __p, __s)  \
for ((__s) = 0; \
-(__s) < INTEL_INFO(__dev_priv)->num_sprites[(__p)];\
+(__s) < INTEL_INFO(__dev_priv)->num_sprites[(__p)] -   \
+(INTEL_INFO(__dev_priv)->has_real_cursor ? 0 : 1); \
 (__s)++)
 
 #define for_each_port_masked(__port, __ports_mask) \
@@ -687,6 +693,7 @@ struct intel_csr {
func(has_psr); \
func(has_rc6); \
func(has_rc6p); \
+   func(has_real_cursor); \
func(has_resource_streamer); \
func(has_runtime_pm); \
func(has_snoop); \
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index d6a8f11..a464e0e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -271,23 +271,39 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
enum pipe pipe;
 
/*
-* Skylake and Broxton currently don't expose the topmost plane as its
-* use is exclusive with the 

[Intel-gfx] [RFC 4/4] drm/i915/gen9: Skip debugfs cursor output for universal plane platforms

[Matt Roper]

The universal plane acting as a cursor for userspace purposes still
shows up farther down the output so we still have all the important
information.

Refactor the cursor printing out to a new function while we're at it;
the nesting was getting a bit deep.

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0bba472..d105777 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3008,6 +3008,23 @@ static bool cursor_position(struct drm_i915_private 
*dev_priv,
return cursor_active(dev_priv, pipe);
 }
 
+static void intel_cursor_info(struct seq_file *m, struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   bool active;
+   int x, y;
+
+   if (!INTEL_INFO(dev_priv)->has_real_cursor)
+   return;
+
+   active = cursor_position(dev_priv, crtc->pipe, , );
+   seq_printf(m, "\tcursor visible? %s, position (%d, %d), size %dx%d, 
addr 0x%08x, active? %s\n",
+  yesno(crtc->cursor_base),
+  x, y, crtc->base.cursor->state->crtc_w,
+  crtc->base.cursor->state->crtc_h,
+  crtc->cursor_addr, yesno(active));
+}
+
 static const char *plane_type(enum drm_plane_type type)
 {
switch (type) {
@@ -3130,9 +3147,7 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
seq_printf(m, "CRTC info\n");
seq_printf(m, "-\n");
for_each_intel_crtc(dev, crtc) {
-   bool active;
struct intel_crtc_state *pipe_config;
-   int x, y;
 
pipe_config = to_intel_crtc_state(crtc->base.state);
 
@@ -3145,12 +3160,7 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
if (pipe_config->base.active) {
intel_crtc_info(m, crtc);
 
-   active = cursor_position(dev_priv, crtc->pipe, , );
-   seq_printf(m, "\tcursor visible? %s, position (%d, %d), 
size %dx%d, addr 0x%08x, active? %s\n",
-  yesno(crtc->cursor_base),
-  x, y, crtc->base.cursor->state->crtc_w,
-  crtc->base.cursor->state->crtc_h,
-  crtc->cursor_addr, yesno(active));
+   intel_cursor_info(m, crtc);
intel_scaler_info(m, crtc);
intel_plane_info(m, crtc);
}
-- 
2.1.4

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

[Intel-gfx] [RFC 2/4] drm/i915: Use macro in place of open-coded for_each_universal_plane loop

[Matt Roper]

This was the only use of (misleadingly-named) intel_num_planes()
function, so we can remove it as well.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_drv.h | 9 -
 drivers/gpu/drm/i915/intel_pm.c  | 2 +-
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2f3863..c31fddd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1108,15 +1108,6 @@ hdmi_to_dig_port(struct intel_hdmi *intel_hdmi)
return container_of(intel_hdmi, struct intel_digital_port, hdmi);
 }
 
-/*
- * Returns the number of planes for this pipe, ie the number of sprites + 1
- * (primary plane). This doesn't count the cursor plane then.
- */
-static inline unsigned int intel_num_planes(struct intel_crtc *crtc)
-{
-   return INTEL_INFO(crtc->base.dev)->num_sprites[crtc->pipe] + 1;
-}
-
 /* intel_fifo_underrun.c */
 bool intel_set_cpu_fifo_underrun_reporting(struct drm_i915_private *dev_priv,
   enum pipe pipe, bool enable);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 58d3ba0..6f19e60 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4232,7 +4232,7 @@ static void skl_update_wm(struct drm_crtc *crtc)
if (crtc->state->active_changed) {
int plane;
 
-   for (plane = 0; plane < intel_num_planes(intel_crtc); plane++)
+   for_each_universal_plane(dev_priv, pipe, plane)
skl_write_plane_wm(intel_crtc, _wm->planes[plane],
   >ddb, plane);
 
-- 
2.1.4

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

[Intel-gfx] [RFC 1/4] drm/i915: Rename for_each_plane -> for_each_universal_plane

[Matt Roper]

This macro's name is a bit misleading; it doesn't actually iterate over
all planes since it omits the cursor plane.  Its only uses are in gen9
code which is using it to iterate over the universal planes (which we
treat as primary+sprites); in these cases the legacy cursor registers
are programmed independently if necessary.  The macro's iterator value
(0 for primary plane, spritenum+1 for each secondary plane) also isn't
meaningful outside the gen9 context where the hardware considers them to
all be "universal" planes that follow this numbering.

This is just a renaming/clarification patch with no functional change.
However it will make the subsequent patches more clear.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 2 +-
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index be92efe..9f5a392 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3463,7 +3463,7 @@ static int i915_ddb_info(struct seq_file *m, void *unused)
for_each_pipe(dev_priv, pipe) {
seq_printf(m, "Pipe %c\n", pipe_name(pipe));
 
-   for_each_plane(dev_priv, pipe, plane) {
+   for_each_universal_plane(dev_priv, pipe, plane) {
entry = >plane[pipe][plane];
seq_printf(m, "  Plane%-8d%8u%8u%8u\n", plane + 1,
   entry->start, entry->end,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 55afb66..4714051 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -312,7 +312,7 @@ struct i915_hotplug {
 #define for_each_pipe_masked(__dev_priv, __p, __mask) \
for ((__p) = 0; (__p) < INTEL_INFO(__dev_priv)->num_pipes; (__p)++) \
for_each_if ((__mask) & (1 << (__p)))
-#define for_each_plane(__dev_priv, __pipe, __p)
\
+#define for_each_universal_plane(__dev_priv, __pipe, __p)  \
for ((__p) = 0; \
 (__p) < INTEL_INFO(__dev_priv)->num_sprites[(__pipe)] + 1; \
 (__p)++)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 895b3dc..cb7dd11 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13485,7 +13485,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
sw_ddb = _priv->wm.skl_hw.ddb;
 
/* planes */
-   for_each_plane(dev_priv, pipe, plane) {
+   for_each_universal_plane(dev_priv, pipe, plane) {
hw_plane_wm = _wm.planes[plane];
sw_plane_wm = _wm->planes[plane];
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9e0e874..58d3ba0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3160,7 +3160,7 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
-   for_each_plane(dev_priv, pipe, plane) {
+   for_each_universal_plane(dev_priv, pipe, plane) {
val = I915_READ(PLANE_BUF_CFG(pipe, plane));
skl_ddb_entry_init_from_hw(>plane[pipe][plane],
   val);
-- 
2.1.4

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

[Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers

[Matt Roper]

Gen9 has a traditional cursor plane that is mutually exclusive with the
system's top-most "universal" plane; it seems likely that two planes are really
a single shared hardware unit with two different register interfaces.  Thus far
i915 has exposed a cursor plane to userspace that's hooked up to the old-style
cursor registers; we just pretended that the top-most universal plane didn't
exist and reported one fewer "sprite/overlay" planes for each pipe than the
platform technically has.  Let's switch this around so that the cursor exposed
to userspace is actually wired up to the previously-unused top-most universal
plane registers.  With this change we'll still present the same cursor ABI to
userspace that we always have, but internally we'll just be programming a
different set of registers and doing so in a way that's more consistent with
how all the other gen9 planes work --- less cursor-specific special cases
throughout the code.

Aside from making the code a bit simpler (fewer cursor-specific special
cases), this will also pave the way to eventually exposing the top-most
plane in a more full-featured manner to userspace clients that don't
need a traditional cursor and wish to opt into having access to an
additional sprite/overlay-style plane instead.

It's worth noting that a lot of the special-cased cursor-specific code
was in the gen9 watermark programming.  It's good to simplify that code,
but we should keep an eye out for any unwanted side effects of this
patch; since sprites/overlays tend to get used less than cursors, it's
possible that this could help us uncover additional underruns that
nobody had run across yet.  Or it could have the opposite effect and
eliminate some of the underruns that we haven't been able to get rid of
yet.

This is just an RFC at this point; we should probably land all of the in-flight
watermark work before this so that those series don't need additional rebasing.
There's also still one known problem I need to track down --- it seems the
color correction of the plane is slightly different when programming the
universal registers vs the legacy cursor registers, so IGT tests like
kms_cursor_crc report CRC mismatches, even though the results look correct
visually.

Note that patches #1 and 2 are trivial renaming patches and could probably be
merged immediately if nobody has concerns with them.


Matt Roper (4):
  drm/i915: Rename for_each_plane -> for_each_universal_plane
  drm/i915: Use macro in place of open-coded for_each_universal_plane
loop
  drm/i915/gen9: Expose top-most universal plane as cursor
  drm/i915/gen9: Skip debugfs cursor output for universal plane
platforms

 drivers/gpu/drm/i915/i915_debugfs.c  | 32 ++-
 drivers/gpu/drm/i915/i915_drv.h  | 13 -
 drivers/gpu/drm/i915/intel_device_info.c | 38 
 drivers/gpu/drm/i915/intel_display.c | 99 
 drivers/gpu/drm/i915/intel_drv.h | 16 +++---
 drivers/gpu/drm/i915/intel_pm.c  | 89 
 drivers/gpu/drm/i915/intel_sprite.c  |  6 +-
 7 files changed, 116 insertions(+), 177 deletions(-)

-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

[Paulo Zanoni]

Em Qua, 2016-10-26 às 11:22 -0700, Rodrigo Vivi escreveu:
> Since Broxton has same FBC block as BDW+ let's assume it also
> don't have access to the stolen usable range.
> 
> FBC is currently not saving power on Broxton and I believe
> the compression threshold is limited to 1x.

NAK.

What is said above has nothing to do with what the code below does. The
amount of stolen memory is decided by i915_gem_init_stolen() and its
friends, not by the FBC code.

What this patch does is that it potentially reduces the amount of
usable stolen memory available to FBC by up to 8mb. That's totally not
going to help making FBC save more power. It can only do the opposite.

Also, the 1x compression threshold is the best thing.

The (unpatched) code below implements the restriction documented in
FBC_CFB_BASE, and it's not applicable to BXT (the spec explicitly says
that).

Also, we have a history of people who try to measure how much power FBC
saves, but they forget to do things such as properly setting the SATA
link power management or other stuff, leaving the system stuck in PC3
state or worse, and then they toggle FBC and conclude that FBC does not
save power. Power testing should really be done by the power management
team. 

Due to the past situations we had, I'd like to see data on the
measurements done before I can believe that the problem is really FBC.

> 
> Cc: Paulo Zanoni 
> Cc: Marc Herbert 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index cbe2ebd..640db67 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -530,12 +530,11 @@ static int find_compression_threshold(struct
> drm_i915_private *dev_priv,
>   int ret;
>   u64 end;
>  
> - /* The FBC hardware for BDW/SKL doesn't have access to the
> stolen
> + /* The FBC hardware for gen8+ doesn't have access to the
> stolen
>    * reserved range size, so it always assumes the maximum
> (8mb) is used.
>    * If we enable FBC using a CFB on that memory range we'll
> get FIFO
>    * underruns, even if that range is not reserved by the
> BIOS. */
> - if (IS_BROADWELL(dev_priv) ||
> - IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> + if (INTEL_INFO(dev_priv)->gen <= 8)
>   end = ggtt->stolen_size - 8 * 1024 * 1024;
>   else
>   end = ggtt->stolen_usable_size;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

[David Weinehall]

On Wed, Oct 26, 2016 at 09:18:59PM +, Vivi, Rodrigo wrote:
> On Wed, 2016-10-26 at 22:45 +0200, David Weinehall wrote:
> > On Wed, Oct 26, 2016 at 11:22:00AM -0700, Rodrigo Vivi wrote:
> > > Since Broxton has same FBC block as BDW+ let's assume it also
> > > don't have access to the stolen usable range.
> > > 
> > > FBC is currently not saving power on Broxton and I believe
> > > the compression threshold is limited to 1x.
> > > 
> > > Cc: Paulo Zanoni 
> > > Cc: Marc Herbert 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > index cbe2ebd..640db67 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > @@ -530,12 +530,11 @@ static int find_compression_threshold(struct 
> > > drm_i915_private *dev_priv,
> > >   int ret;
> > >   u64 end;
> > >  
> > > - /* The FBC hardware for BDW/SKL doesn't have access to the stolen
> > > + /* The FBC hardware for gen8+ doesn't have access to the stolen
> > >* reserved range size, so it always assumes the maximum (8mb) is used.
> > 
> > Might I suggest correcting the comment to say megabyte instead of
> > millibit while at it?
> 
> you mean s/8mb/8MB right? I can change it in a v3 for sure.

Indeed.

> > 
> > >* If we enable FBC using a CFB on that memory range we'll get FIFO
> > >* underruns, even if that range is not reserved by the BIOS. */
> > > - if (IS_BROADWELL(dev_priv) ||
> > > - IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> > > + if (INTEL_INFO(dev_priv)->gen <= 8)
> > 
> > INTEL_GEN(dev_priv)
> 
> yeap, good point. will change that later .
> 
> Although for Marc the old style has more chance to get applied on his
> tree for now.

Fair enough.

> Let's wait for his confirmation before the v3 anyway.
> 
> > 
> > Also, shouldn't this be >= 8? Also, 
> 
> duh! sorry!
> Marc already pointed me this mistake... v2 was sent already.

Yeah, I noticed just after I pressed send :)

> > remember that gen8 also includes
> > CherryView -- is the behaviour the same there?
> 
> chv doesn't have fbc so I hope it never reaches this path...

Goodie.


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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

On Wed, Oct 26, 2016 at 4:03 PM, Robert Bragg 
wrote:

> On 26 Oct 2016 11:08 a.m., "Matthew Auld" 
> wrote:
> >
> > On 26 October 2016 at 00:51, Robert Bragg  wrote:
> > >
> > >
> > > On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > >  wrote:
> > >>
> > >> On 25 October 2016 at 00:19, Robert Bragg 
> wrote:
> > >
> > >
> > >>
> > >>
> > >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > >> > b/drivers/gpu/drm/i915/i915_drv.h
> > >> > index 3448d05..ea24814 100644
> > >> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > >> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > >> > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > >>
> > >> >
> > >> >  struct drm_i915_private {
> > >> > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > >> >
> > >> > struct {
> > >> > bool initialized;
> > >> > +
> > >> > struct mutex lock;
> > >> > struct list_head streams;
> > >> >
> > >> > +   spinlock_t hook_lock;
> > >> > +
> > >> > struct {
> > >> > -   u32 metrics_set;
> > >> > +   struct i915_perf_stream *exclusive_stream;
> > >> > +
> > >> > +   u32 specific_ctx_id;
> > >> Can we just get rid of this, now that the vma remains pinned we can
> > >> simply get the ggtt address at the time of configuring the OA_CONTROL
> > >> register ?
> > >
> > >
> > > I considered that, but would ideally prefer to keep it considering the
> gen8+
> > > patches to come. For gen8+ (with execlists) the context ID isn't a gtt
> > > offset.
> > >
> > >>
> > >>
> > >> > +
> > >> > +   struct hrtimer poll_check_timer;
> > >> > +   wait_queue_head_t poll_wq;
> > >> > +   atomic_t pollin;
> > >> > +
> > >>
> > >
> > >>
> > >> > +/* The maximum exponent the hardware accepts is 63 (essentially it
> > >> > selects one
> > >> > + * of the 64bit timestamp bits to trigger reports from) but there's
> > >> > currently
> > >> > + * no known use case for sampling as infrequently as once per 47
> > >> > thousand years.
> > >> > + *
> > >> > + * Since the timestamps included in OA reports are only 32bits it
> seems
> > >> > + * reasonable to limit the OA exponent where it's still possible to
> > >> > account for
> > >> > + * overflow in OA report timestamps.
> > >> > + */
> > >> > +#define OA_EXPONENT_MAX 31
> > >> > +
> > >> > +#define INVALID_CTX_ID 0x
> > >> We shouldn't need this anymore.
> > >
> > >
> > > yeah I removed it and then added it back, just for the sake of
> explicitly
> > > setting the specific_ctx_id to an invalid ID when closing the exclusive
> > > stream - though resetting the value isn't strictly necessary.
> > Can we not make the specific_ctx_id per-stream, the gem context
> > already is, then we don't need to be concerned with resetting it ?
>
> Hmm, I'm not sure about that, conceptually to me it's global OA unit state.
>
> Currently the driver only supports a single exclusive stream, while Sourab
> later relaxes that to a per-engine stream and that could be relaxed further
> with non-oa metric stream types.
>
> With multiple streams we'll still only be able to programmer a single ctx
> id in oacontol.
>
> Conceptually to me, other stream types could be associated with different
> contexts (if they don't depend on the OA unit) so to me stream->ctx isn't
> necessarily OA unit state.
>
> It probably could be played around with, but right now we don't track OA
> specific state in the stream. For the ID it's just semantics to say it's OA
> state, and we could consider that it's maybe generally useful to track the
> ID, even for future non-oa streams. That might mean potentially redundantly
> pinning state for the sake of tracking the ID for streams that don't end up
> needing it.
>

I started to try out moving the specific_ctx_id and vma pointer (new) to
the stream, and also looked at initializing them together with the
stream->ctx reference, but I'm not really happy with how it's looking.

The specific_ctx_id and pinning are only for the render context, since the
OA unit is only well integrated with the render engine, which makes me more
inclined to consider them OA stream specific, not something we want/need
for all streams (considering that Sourab enables multiple streams in his
series).

Btw, for reference, my patches for gen8+ can also end up making use of the
INVALID_CTX_ID define (when overwriting the undefined ctx_id field in HW
reports when the report's ctx-id is flagged as invalid by the OA unit.) so
we maybe don't want to worry to much about removing the need for it here.

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

Re: [Intel-gfx] [PATCH] drm/i915/DMC/KBL: Load DMC on KBL using the no_stepping_info array

[Vivi, Rodrigo]

Patch merged to dinq. Thanks for the patch and thanks for the ack.

On Wed, 2016-10-26 at 09:12 -0700, Rodrigo Vivi wrote:
> On Wed, 2016-10-26 at 15:32 +0300, Imre Deak wrote:
> > On ti, 2016-10-25 at 18:00 +, Vivi, Rodrigo wrote:
> > > Reviewed-by: Rodrigo Vivi 
> > > 
> > > On Mon, 2016-10-24 at 17:28 -0700, Anusha Srivatsa wrote:
> > > > Currently, for display there is only one DMC image for KBL.
> > > > Remove the stepping_info table for KBL and use the no_stepping_info
> > > > array for loading the firmware.
> > > > 
> > > > v2: Removed the block of code as pointed out by Rodrigo to make the
> > > > loads as generic as possible.
> > > > 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: Anusha Srivatsa 
> > 
> > I assume the goal is to simplify the code. kbl_dmc_ver1_01.bin has
> > indeed only a single *,* entry and I assume it was confirmed that there
> > is no plan to release KBL firmware images in the future with multiple
> > stepping entries. With that this looks ok:
> 
> That is the case.
> 
> > Acked-by: Imre Deak 
> 
> Thanks.
> 
> > 
> > I think it would be good to also emit a warn from the driver if we use
> > no_stepping_info and there are stepping entries in the firmware image
> > other than *,* since then we may end up loading the wrong firmware
> > version.
> 
> yeap, this seems a good idea. a conservative approach.
> although, along with the confirmation we got the promise
> that this kind of information would be now on in the official
> release notes we receive along with the binary images.
> 
> 
> > 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_csr.c | 11 +--
> > > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > > > b/drivers/gpu/drm/i915/intel_csr.c
> > > > index 1ea0e1f..d7a04bc 100644
> > > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > > @@ -168,12 +168,6 @@ struct stepping_info {
> > > > char substepping;
> > > >  };
> > > >  
> > > > -static const struct stepping_info kbl_stepping_info[] = {
> > > > -   {'A', '0'}, {'B', '0'}, {'C', '0'},
> > > > -   {'D', '0'}, {'E', '0'}, {'F', '0'},
> > > > -   {'G', '0'}, {'H', '0'}, {'I', '0'},
> > > > -};
> > > > -
> > > >  static const struct stepping_info skl_stepping_info[] = {
> > > > {'A', '0'}, {'B', '0'}, {'C', '0'},
> > > > {'D', '0'}, {'E', '0'}, {'F', '0'},
> > > > @@ -194,10 +188,7 @@ intel_get_stepping_info(struct
> > > > drm_i915_private *dev_priv)
> > > > const struct stepping_info *si;
> > > > unsigned int size;
> > > >  
> > > > -   if (IS_KABYLAKE(dev_priv)) {
> > > > -   size = ARRAY_SIZE(kbl_stepping_info);
> > > > -   si = kbl_stepping_info;
> > > > -   } else if (IS_SKYLAKE(dev_priv)) {
> > > > +   if (IS_SKYLAKE(dev_priv)) {
> > > > size = ARRAY_SIZE(skl_stepping_info);
> > > > si = skl_stepping_info;
> > > > } else if (IS_BROXTON(dev_priv)) {
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

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

Re: [Intel-gfx] [PATCH] drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

[Vivi, Rodrigo]

On Wed, 2016-10-26 at 22:45 +0200, David Weinehall wrote:
> On Wed, Oct 26, 2016 at 11:22:00AM -0700, Rodrigo Vivi wrote:
> > Since Broxton has same FBC block as BDW+ let's assume it also
> > don't have access to the stolen usable range.
> > 
> > FBC is currently not saving power on Broxton and I believe
> > the compression threshold is limited to 1x.
> > 
> > Cc: Paulo Zanoni 
> > Cc: Marc Herbert 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index cbe2ebd..640db67 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -530,12 +530,11 @@ static int find_compression_threshold(struct 
> > drm_i915_private *dev_priv,
> > int ret;
> > u64 end;
> >  
> > -   /* The FBC hardware for BDW/SKL doesn't have access to the stolen
> > +   /* The FBC hardware for gen8+ doesn't have access to the stolen
> >  * reserved range size, so it always assumes the maximum (8mb) is used.
> 
> Might I suggest correcting the comment to say megabyte instead of
> millibit while at it?

you mean s/8mb/8MB right? I can change it in a v3 for sure.

> 
> >  * If we enable FBC using a CFB on that memory range we'll get FIFO
> >  * underruns, even if that range is not reserved by the BIOS. */
> > -   if (IS_BROADWELL(dev_priv) ||
> > -   IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> > +   if (INTEL_INFO(dev_priv)->gen <= 8)
> 
> INTEL_GEN(dev_priv)

yeap, good point. will change that later .

Although for Marc the old style has more chance to get applied on his
tree for now.

Let's wait for his confirmation before the v3 anyway.

> 
> Also, shouldn't this be >= 8? Also, 

duh! sorry!
Marc already pointed me this mistake... v2 was sent already.

> remember that gen8 also includes
> CherryView -- is the behaviour the same there?

chv doesn't have fbc so I hope it never reaches this path...

> 
> > end = ggtt->stolen_size - 8 * 1024 * 1024;
> > else
> > end = ggtt->stolen_usable_size;
> > -- 
> > 1.9.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+ (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+ (rev2)
URL   : https://patchwork.freedesktop.org/series/14426/
State : warning

== Summary ==

Series 14426v2 drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+
https://patchwork.freedesktop.org/api/1.0/series/14426/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup bad-pipe:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup bad-source:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:182  dwarn:3   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

908bf09d04a2d83eadeb033f62a7f45d2c2a6aca drm-intel-nightly: 
2016y-10m-26d-19h-59m-01s UTC integration manifest
4b49688 drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2832/

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/{igt_sysfs, igt_aux}: Make available to other users kick_fbcon() (unbind_fbcon()), and added helpers to igt_aux.

[Marius Vlad]

On Mon, Oct 24, 2016 at 10:40:37AM +0200, Daniel Vetter wrote:
> On Thu, Oct 20, 2016 at 10:36:47PM +0300, Marius Vlad wrote:
> > Previously under unbind_fbcon(), disable/enable framebuffer console.
> > 
> > lib/igt_aux: Added helpers to help convert sh scripts to C version. libkmod 
> > and
> > procps interface.
> > 
> > Signed-off-by: Marius Vlad 
> > ---
> >  configure.ac|   2 +
> >  lib/Makefile.am |   2 +
> >  lib/igt_aux.c   | 278 
> > 
> >  lib/igt_aux.h   |   7 ++
> >  lib/igt_gvt.c   |  43 +
> >  lib/igt_sysfs.c |  54 +++
> >  lib/igt_sysfs.h |   2 +
> >  7 files changed, 347 insertions(+), 41 deletions(-)
> 
> If you go with extracting stuff into helpers I'd go with a new helper
> library like igt_kmod.c. Or just keep it in-line with tests, extracting
> code is imo overrated ;-)
Have no issue putting kmod helpers into their own file. Can't really
tell which is the best approach though: the only user is drv_module_reload
yet the test already got ``fatten'' up with the gem subtests (see v3).
> 
> Also pls make sure the docs are correct and look good, there's a bunch of
> issues with them (like non-matching function names between comment and
> actual code).
Sorry, I totally missed your input, will double check on this.
> -Daniel
> 
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 735cfd5..2c6e49d 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -121,6 +121,8 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
> >  
> >  PKG_CHECK_MODULES(DRM, [libdrm])
> >  PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
> > +PKG_CHECK_MODULES(KMOD, [libkmod])
> > +PKG_CHECK_MODULES(PROCPS, [libprocps])
> >  
> >  case "$target_cpu" in
> > x86*|i?86)
> > diff --git a/lib/Makefile.am b/lib/Makefile.am
> > index 4c0893d..e1737bd 100644
> > --- a/lib/Makefile.am
> > +++ b/lib/Makefile.am
> > @@ -34,6 +34,8 @@ AM_CFLAGS += $(CAIRO_CFLAGS)
> >  libintel_tools_la_LIBADD = \
> > $(DRM_LIBS) \
> > $(PCIACCESS_LIBS) \
> > +   $(PROCPS_LIBS) \
> > +   $(KMOD_LIBS) \
> > $(CAIRO_LIBS) \
> > $(LIBUDEV_LIBS) \
> > $(LIBUNWIND_LIBS) \
> > diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> > index 421f6d4..d150818 100644
> > --- a/lib/igt_aux.c
> > +++ b/lib/igt_aux.c
> > @@ -51,6 +51,9 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +#include 
> > +
> >  #include "drmtest.h"
> >  #include "i915_drm.h"
> >  #include "intel_chipset.h"
> > @@ -1193,6 +1196,281 @@ void igt_set_module_param_int(const char *name, int 
> > val)
> > igt_set_module_param(name, str);
> >  }
> >  
> > +/**
> > + * igt_pkill:
> > + * @sig: Signal to send
> > + * @name: Name of process in the form found in /proc/pid/comm (limited to 
> > 15
> > + * chars)
> > + * @returns: 0 in case the process is not found running or the signal has 
> > been
> > + * sent successfully or -1 otherwise.
> > + *
> > + * This function sends the signal @sig for a process found in process table
> > + * with name @comm.
> > + */
> > +int
> > +igt_pkill(int sig, const char *comm)
> > +{
> > +   int err = 0, try = 5;
> > +   PROCTAB *proc;
> > +   proc_t *proc_info;
> > +
> > +   proc = openproc(PROC_FILLCOM | PROC_FILLSTAT | PROC_FILLARG);
> > +   igt_assert(proc != NULL);
> > +
> > +   while ((proc_info = readproc(proc, NULL))) {
> > +   if (proc_info &&
> > +   !strncasecmp(proc_info->cmd, comm, sizeof(proc_info->cmd))) 
> > {
> > +   switch (sig) {
> > +   case SIGTERM:
> > +   case SIGKILL:
> > +   do {
> > +   kill(proc_info->tid, sig);
> > +   } while (kill(proc_info->tid, 0) < 0 && try--);
> > +
> > +   if (kill(proc_info->tid, 0) < 0)
> > +   err = -1;
> > +   break;
> > +   default:
> > +   if (kill(proc_info->tid, sig) < 0)
> > +   err = -1;
> > +   break;
> > +   }
> > +
> > +   freeproc(proc_info);
> > +   break;
> > +   }
> > +   freeproc(proc_info);
> > +   }
> > +
> > +   closeproc(proc);
> > +   return err;
> > +}
> > +
> > +/**
> > + * igt_kill:
> > + * @sig: Signal to send.
> > + * @pid: Process pid to send.
> > + * @returns: 0 in case of success or -1 otherwise.
> > + *
> > + * This function is identical to igt_pkill() only that it searches the 
> > process
> > + * table using @pid instead of comm name.
> > + *
> > + */
> > +int
> > +igt_kill(int sig, pid_t pid)
> > +{
> > +   int err = 0, try = 5;
> > +   PROCTAB *proc;
> > +   proc_t *proc_info;
> > +
> > +   proc = openproc(PROC_PID | PROC_FILLSTAT | PROC_FILLARG);
> > +   igt_assert(proc != NULL);
> > +
> > +   while ((proc_info = readproc(proc, NULL))) {
> > +   if (proc_info && 

Re: [Intel-gfx] [PATCH] drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

[David Weinehall]

On Wed, Oct 26, 2016 at 11:22:00AM -0700, Rodrigo Vivi wrote:
> Since Broxton has same FBC block as BDW+ let's assume it also
> don't have access to the stolen usable range.
> 
> FBC is currently not saving power on Broxton and I believe
> the compression threshold is limited to 1x.
> 
> Cc: Paulo Zanoni 
> Cc: Marc Herbert 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index cbe2ebd..640db67 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -530,12 +530,11 @@ static int find_compression_threshold(struct 
> drm_i915_private *dev_priv,
>   int ret;
>   u64 end;
>  
> - /* The FBC hardware for BDW/SKL doesn't have access to the stolen
> + /* The FBC hardware for gen8+ doesn't have access to the stolen
>* reserved range size, so it always assumes the maximum (8mb) is used.

Might I suggest correcting the comment to say megabyte instead of
millibit while at it?

>* If we enable FBC using a CFB on that memory range we'll get FIFO
>* underruns, even if that range is not reserved by the BIOS. */
> - if (IS_BROADWELL(dev_priv) ||
> - IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> + if (INTEL_INFO(dev_priv)->gen <= 8)

INTEL_GEN(dev_priv)

Also, shouldn't this be >= 8? Also, remember that gen8 also includes
CherryView -- is the behaviour the same there?

>   end = ggtt->stolen_size - 8 * 1024 * 1024;
>   else
>   end = ggtt->stolen_usable_size;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Wed, 2016-10-26 at 22:06 +0300, Jani Nikula wrote:
> On Wed, 26 Oct 2016, "Pandiyan, Dhinakaran"  
> wrote:
> > On Wed, 2016-10-26 at 11:57 +0300, Jani Nikula wrote:
> >> On Wed, 26 Oct 2016, Dhinakaran Pandiyan  
> >> wrote:
> >> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> >> > let's set this bit right before enabling the audio codec. Playing audio
> >> > without setting this bit results in pipe FIFO underruns.
> >> >
> >> > This workaround is applicable only for audio sample rates up to 96kHz. 
> >> > For
> >> > frequencies above 96kHz, this is insufficient and cdclk should be 
> >> > increased
> >> > to at least 432 MHz, just like BDW. Since, the audio driver does not
> >> > support sample rates > 48 kHz, we are safe with this fix for now.
> >> >
> >> > v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
> >> > Fixed the port clock typo
> >> > Added TODO comment
> >> > Signed-off-by: Dhinakaran Pandiyan 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_reg.h|  5 +
> >> >  drivers/gpu/drm/i915/intel_audio.c | 30 +-
> >> >  2 files changed, 34 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >> > b/drivers/gpu/drm/i915/i915_reg.h
> >> > index 00efaa1..76dac48 100644
> >> > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> > @@ -6236,6 +6236,11 @@ enum {
> >> >  #define SLICE_ECO_CHICKEN0  _MMIO(0x7308)
> >> >  #define   PIXEL_MASK_CAMMING_DISABLE(1 << 14)
> >> >  
> >> > +#define _CHICKEN_TRANS_A0x420C0
> >> > +#define _CHICKEN_TRANS_B0x420C4
> >> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> >> > _CHICKEN_TRANS_B)
> >> > +#define SPARE_13(1<<13)
> >> > +
> >> >  /* WaCatErrorRejectionIssue */
> >> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG  _MMIO(0x9030)
> >> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB   (1<<11)
> >> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> >> > b/drivers/gpu/drm/i915/intel_audio.c
> >> > index 7093cfb..894f11e 100644
> >> > --- a/drivers/gpu/drm/i915/intel_audio.c
> >> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> >> > @@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct 
> >> > intel_encoder *encoder)
> >> >  {
> >> >  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >> >  struct intel_crtc *intel_crtc = 
> >> > to_intel_crtc(encoder->base.crtc);
> >> > +struct intel_crtc_state *crtc_config =  intel_crtc->config;
> >> > +enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> >> >  enum pipe pipe = intel_crtc->pipe;
> >> >  uint32_t tmp;
> >> >  
> >> > @@ -290,13 +292,21 @@ static void hsw_audio_codec_disable(struct 
> >> > intel_encoder *encoder)
> >> >  
> >> >  mutex_lock(_priv->av_mutex);
> >> >  
> >> > +/*Disable DP audio stall fix for HBR2*/
> >> 
> >> Nitpick, spaces after /* and before */.
> >> 
> >> > +if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) 
> >> > &&
> >> > +crtc_config->port_clock >= 54) {
> >> > +tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> >> > +tmp &= ~SPARE_13;
> >> > +I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
> >> > +}
> >> 
> >> Hmm. Why don't we just do this unconditionally?
> >> 
> >
> > That bit is disabled by default, so avoiding  two MMIO ops. that are not
> > required.
> 
> That makes no difference on the modeset path.
> 

Because we do a lot of MMIO ops. anyway?


> >
> >> > +
> >> >  /* Disable timestamps */
> >> >  tmp = I915_READ(HSW_AUD_CFG(pipe));
> >> >  tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> >> >  tmp |= AUD_CONFIG_N_PROG_ENABLE;
> >> >  tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> >> >  tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> >> > -if (intel_crtc_has_dp_encoder(intel_crtc->config))
> >> > +if (intel_crtc_has_dp_encoder(crtc_config))
> >> >  tmp |= AUD_CONFIG_N_VALUE_INDEX;
> >> >  I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> >> >  
> >> > @@ -315,6 +325,8 @@ static void hsw_audio_codec_enable(struct 
> >> > drm_connector *connector,
> >> >  {
> >> >  struct drm_i915_private *dev_priv = to_i915(connector->dev);
> >> >  struct intel_crtc *intel_crtc = 
> >> > to_intel_crtc(intel_encoder->base.crtc);
> >> > +struct intel_crtc_state *crtc_config =  intel_crtc->config;
> >> > +enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> >> >  enum pipe pipe = intel_crtc->pipe;
> >> >  enum port port = intel_encoder->port;
> >> >  const uint8_t *eld = connector->eld;
> >> > @@ -326,6 +338,22 @@ static void hsw_audio_codec_enable(struct 
> >> > drm_connector 

[Intel-gfx] [PATCH] drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

[Rodrigo Vivi]

Since Broxton has same FBC block as BDW+ let's assume it also
don't have access to the stolen usable range.

FBC is currently not saving power on Broxton and I believe
the compression threshold is limited to 1x.

v2: duh! inverted check. (Thanks Marc)

Cc: Paulo Zanoni 
Cc: Marc Herbert 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index cbe2ebd..214b2de 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -530,12 +530,11 @@ static int find_compression_threshold(struct 
drm_i915_private *dev_priv,
int ret;
u64 end;
 
-   /* The FBC hardware for BDW/SKL doesn't have access to the stolen
+   /* The FBC hardware for gen8+ doesn't have access to the stolen
 * reserved range size, so it always assumes the maximum (8mb) is used.
 * If we enable FBC using a CFB on that memory range we'll get FIFO
 * underruns, even if that range is not reserved by the BIOS. */
-   if (IS_BROADWELL(dev_priv) ||
-   IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+   if (INTEL_INFO(dev_priv)->gen >= 8)
end = ggtt->stolen_size - 8 * 1024 * 1024;
else
end = ggtt->stolen_usable_size;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] lib/ida: Document locking requirements a bit better

[Tejun Heo]

Hello, Daniel.

On Wed, Oct 26, 2016 at 09:25:25PM +0200, Daniel Vetter wrote:
> > > + * Note that callers must ensure that concurrent access to @ida is not 
> > > possible.
> > > + * When simplicity trumps concurrency needs look at ida_simple_get() 
> > > instead.
> > 
> > Maybe we can make it a bit less dramatic?
> 
> What about?
> 
> "Note that callers must ensure that concurrent access to @ida is not possible.
> See ida_simple_get() for a varaint which takes care of locking.

Yeah, that reads easier to me.

> > Hmm... so, this isn't necessarily about speed.  For example, id
> > allocation might have to happen inside a spinlock which protects a
> > larger scope.  To guarantee GFP_KERNEL allocation behavior in such
> > cases, the caller would have to call ida_pre_get() outside the said
> > spinlock and then call ida_get_new_above() inside the lock.
> 
> Hm, ida_simple_get does that for you already ...

Here's an example.

spin_lock();
do some stuff;
something->id = ida_simple_get(some gfp flag);
do some stuff;
spin_unlock();

In this scenario, you can't use sleeping GFPs for ida_simple_get()
because it does preloading inside it.  What one has to do is...

ida_pre_get(GFP_KERNEL);
spin_lock();
do some stuff;
something->id = ida_get_new_above(GFP_NOWAIT);
do some stuff;
spin_unlock();

So, I guess it can be sometimes about avoiding the extra locking
overhead but it's more often about separating out allocation context
into an earlier call.

> > I think it'd be better to explain what the simple version does and
> > expects and then say that unless there are specific requirements using
> > the simple version is recommended.
> 
> What about:
> 
> "Compared to ida_get_new_above() this function does its own locking, and
> should be used unless there are special requirements."

Yeah, looks good to me.

Thanks.

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

Re: [Intel-gfx] [PATCH v2] drm: Print some debug/error info during DP dual mode detect

[Sean Paul]

On Wed, Oct 26, 2016 at 12:29 PM, Imre Deak  wrote:
> There's at least one LSPCON device that occasionally returns an unexpected
> adaptor ID which leads to a failed detect. Print some debug info to help
> debugging this and future cases. Also print an error for an unexpected
> adaptor ID, so users can report it.
>
> v2:
> - s/adapter/adaptor/ and add code comment about incorrect type 1 adaptor
>   IDs. (Ville)
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> Reviewed-by: Ville Syrjälä 


Applied to drm-misc, thanks

Sean

> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 488355b..e025639 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -142,6 +142,11 @@ static bool is_hdmi_adaptor(const char 
> hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN])
>   sizeof(dp_dual_mode_hdmi_id)) == 0;
>  }
>
> +static bool is_type1_adaptor(uint8_t adaptor_id)
> +{
> +   return adaptor_id == 0 || adaptor_id == 0xff;
> +}
> +
>  static bool is_type2_adaptor(uint8_t adaptor_id)
>  {
> return adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
> @@ -193,6 +198,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
> i2c_adapter *adapter)
>  */
> ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_HDMI_ID,
> hdmi_id, sizeof(hdmi_id));
> +   DRM_DEBUG_KMS("DP dual mode HDMI ID: %*pE (err %zd)\n",
> + ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
> if (ret)
> return DRM_DP_DUAL_MODE_UNKNOWN;
>
> @@ -210,6 +217,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
> i2c_adapter *adapter)
>  */
> ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
> _id, sizeof(adaptor_id));
> +   DRM_DEBUG_KMS("DP dual mode adaptor ID: %02x (err %zd)\n",
> + adaptor_id, ret);
> if (ret == 0) {
> if (is_lspcon_adaptor(hdmi_id, adaptor_id))
> return DRM_DP_DUAL_MODE_LSPCON;
> @@ -219,6 +228,15 @@ enum drm_dp_dual_mode_type 
> drm_dp_dual_mode_detect(struct i2c_adapter *adapter)
> else
> return DRM_DP_DUAL_MODE_TYPE2_DVI;
> }
> +   /*
> +* If neither a proper type 1 ID nor a broken type 1 adaptor
> +* as described above, assume type 1, but let the user know
> +* that we may have misdetected the type.
> +*/
> +   if (!is_type1_adaptor(adaptor_id) && adaptor_id != hdmi_id[0])
> +   DRM_ERROR("Unexpected DP dual mode adaptor ID %02x\n",
> + adaptor_id);
> +
> }
>
> if (is_hdmi_adaptor(hdmi_id))
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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/fbc: Assume maximum 8mb of stolen is used for gen8+

[Patchwork]

== Series Details ==

Series: drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+
URL   : https://patchwork.freedesktop.org/series/14426/
State : warning

== Summary ==

Series 14426v1 drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+
https://patchwork.freedesktop.org/api/1.0/series/14426/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

0eefa35311a3d85e6cbfda4bb326809581acc3b1 drm-intel-nightly: 
2016y-10m-26d-17h-38m-29s UTC integration manifest
2412c2c drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2830/

== Logs ==

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

[Intel-gfx] [PATCH 3/5] drm/i915/skl: Update DDB values atomically with wms/plane attrs

[Lyude]

commit 27082493e9c6371b05370a619ab9d2877c5f4726 upstream

Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.

The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.

The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:

We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:

|   A   |   B   |xxx|

Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.

1. Flush pipes with new allocation contained into old space. None
   apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
   previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
   giving us the following update order: A, B

This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.

As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().

This long overdue patch fixes the rest of the underruns on Skylake.

Changes since v1:
 - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
 - Use the method for updating CRTCs that Ville suggested
 - In skl_update_wm(), only copy the watermarks for the crtc that was
   passed to us
Changes since v3:
 - Small comment fix in skl_ddb_allocation_overlaps()
Changes since v4:
 - Remove the second loop in intel_update_crtcs() and use Ville's
   suggestion for updating the ddb allocations in the right order
 - Get rid of the second loop and just use the ddb state as it updates
   to determine what order to update everything in (thanks for the
   suggestion Ville)
 - Simplify skl_ddb_allocation_overlaps()
 - Split actual overlap checking into it's own helper

Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]

Testcase: kms_cursor_legacy
Testcase: plane-all-modeset-transition
Signed-off-by: Lyude 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
Signed-off-by: Maarten Lankhorst 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-2-git-send-email-cp...@redhat.com
---
 drivers/gpu/drm/i915/intel_display.c |  93 +---
 drivers/gpu/drm/i915/intel_drv.h |   7 ++
 drivers/gpu/drm/i915/intel_pm.c  | 200 ---
 3 files changed, 132 insertions(+), 168 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2c46eb..8086e62 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12967,16 +12967,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
  hw_entry->start, hw_entry->end);
}
 
-   /* cursor */
-   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
-   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
-
-   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+   if (intel_crtc->cursor_addr) {
+   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
+   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
+
+   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+  

[Intel-gfx] [PATCH 0/5] drm/i915/skl: Backport watermark fixes for 4.8.y

[Lyude]

Now that these have finally made it into 4.9, it's time to finally backport
these fixes. Skylake has been a mess in multi-monitor setups for a while now
because up until recently we've been updating the watermarks on Skylake just
like we would for previous generations of Intel GPUs. This means updating
attributes for each plane, and then only after they've been updated writing
their new watermark values.

The problem with this approach is Skylake has double buffered watermark
registers that are flipped at the same time as the rest of the plane registers.
This means that the original approach will leave planes active with new
attributes but without the required watermark programming that would ensure the
display pipe reads enough data from each plane. As a result, pipes start to
underrun and the user's displays starts to flicker heavily. Usually in response
to plugging in new monitors, or moving cursors from one screen to another
(which triggers a plane and watermark update).

Additionally, issues were found with the original code for configuring ddb,
display data buffer, allocations between display planes on Skylake. On Skylake
all planes have space allocated to them in the ddb, and the hardware requires
that these allocations never overlap at any point in time. Because ddb
allocations were not updated alongside plane attributes despite also being
double buffered registers armed by plane updates, planes were likely to get
stuck momentarily with ddb allocations that overlapped one another. This would
also lead to pipe underruns and display flickering.

The new approach fixes this problem by making sure that on Skylake, attributes
for display planes are always updated at the same time as the watermarks, and
pipes are updated in an order that ensures their ddb allocations don't
overlap at any point between plane updates. This ensures the display pipes are
always programmed correctly, and dramatically reduces the chance of display
flickering.

(note: my e-mail has changed since these patches were upstreamed, and I updated
the e-mails in these patches to reflect this. if this is wrong I will be happy
to update and resend the patches).

Lyude (4):
  drm/i915/skl: Update plane watermarks atomically during plane updates
  drm/i915: Move CRTC updating in atomic_commit into it's own hook
  drm/i915/skl: Update DDB values atomically with wms/plane attrs
  drm/i915/skl: Don't try to update plane watermarks if they haven't
changed

Paulo Zanoni (1):
  drm/i915/gen9: only add the planes actually affected by ddb changes

 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_display.c | 189 +++-
 drivers/gpu/drm/i915/intel_drv.h |  12 ++
 drivers/gpu/drm/i915/intel_pm.c  | 271 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  14 ++
 5 files changed, 289 insertions(+), 199 deletions(-)

-- 
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/skl: Don't try to update plane watermarks if they haven't changed

[Lyude]

commit ccebc23b57c313229526dc76383ce82f5e0b9001 upstream

i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.

Simple reproduction recipe:
 - Get a SKL laptop, launch any kind of X session
 - Get two extra monitors
 - Keep hotplugging both displays (so that the display configuration
   jumps from 1 active pipe to 3 active pipes and back)
 - Eventually underrun

Changes since v1:
 - Fix incorrect use of "it's"
Changes since v2:
 - Add reproduction recipe

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically during 
plane updates")
Testcase: kms_plane
Signed-off-by: Maarten Lankhorst 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1472488288-27280-1-git-send-email-cp...@redhat.com
Cc: drm-intel-fi...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 drivers/gpu/drm/i915/intel_sprite.c  | 8 
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8086e62..85d161a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3068,7 +3068,12 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
 
-   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!to_intel_plane_state(crtc->primary->state)->visible)
+   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index d8bfff1..4178849 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -314,6 +314,14 @@ skl_disable_plane(struct drm_plane *dplane, struct 
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;
 
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!to_intel_plane_state(dplane->state)->visible)
+   skl_write_plane_wm(to_intel_crtc(crtc),
+  _priv->wm.skl_results, plane);
+
I915_WRITE(PLANE_CTL(pipe, plane), 0);
 
I915_WRITE(PLANE_SURF(pipe, plane), 0);
-- 
2.7.4

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

[Intel-gfx] [PATCH 5/5] drm/i915/gen9: only add the planes actually affected by ddb changes

[Lyude]

From: Paulo Zanoni 

commit be5c571b2ff3a164d2e14ccc100cb5b2b3d3fb7c upstream

We were previously adding all the planes owned by the CRTC even when
the ddb partitioning didn't change for them. As a consequence, a lot
of functions were being called when we were just moving the cursor
around the screen, such as skylake_update_primary_plane().

This was causing flickering on the primary plane when moving the
cursor. I'm not 100% sure which operation caused the flickering, but
we were writing to a lot of registers, so it could be any of these
writes. With this patch, just moving the mouse won't add the primary
plane to the commit since it won't trigger a change in DDB
partitioning.

v2: Use skl_ddb_entry_equal() (Lyude).
v3: Change Reported-and-bisected-by: to Reported-by: for checkpatch

Fixes: 05a76d3d6ad1 ("drm/i915/skl: Ensure pipes with changed wms get added to 
the state")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97888
Cc: Mike Lothian 
Cc: sta...@vger.kernel.org
Reported-by: Mike Lothian 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Lyude 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1475177808-29955-1-git-send-email-paulo.r.zan...@intel.com
(cherry picked from commit 7f60e200e254cd53ad1bd74a56bdd23e813ac4b7)
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_pm.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a0c5c4e..5f763f4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3940,6 +3940,41 @@ pipes_modified(struct drm_atomic_state *state)
return ret;
 }
 
+int
+skl_ddb_add_affected_planes(struct intel_crtc_state *cstate)
+{
+   struct drm_atomic_state *state = cstate->base.state;
+   struct drm_device *dev = state->dev;
+   struct drm_crtc *crtc = cstate->base.crtc;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
+   struct skl_ddb_allocation *cur_ddb = _priv->wm.skl_hw.ddb;
+   struct drm_plane_state *plane_state;
+   struct drm_plane *plane;
+   enum pipe pipe = intel_crtc->pipe;
+   int id;
+
+   WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
+
+   drm_for_each_plane_mask(plane, dev, crtc->state->plane_mask) {
+   id = skl_wm_plane_id(to_intel_plane(plane));
+
+   if (skl_ddb_entry_equal(_ddb->plane[pipe][id],
+   _ddb->plane[pipe][id]) &&
+   skl_ddb_entry_equal(_ddb->y_plane[pipe][id],
+   _ddb->y_plane[pipe][id]))
+   continue;
+
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state))
+   return PTR_ERR(plane_state);
+   }
+
+   return 0;
+}
+
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
@@ -4004,7 +4039,7 @@ skl_compute_ddb(struct drm_atomic_state *state)
if (ret)
return ret;
 
-   ret = drm_atomic_add_affected_planes(state, _crtc->base);
+   ret = skl_ddb_add_affected_planes(cstate);
if (ret)
return ret;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/5] drm/i915/skl: Update plane watermarks atomically during plane updates

[Lyude]

commit c145d3be1c313184be71d2629fd575561b7e38d4 upstream

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

  or

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

Now we update watermarks atomically like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
  yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.

Changes since original patch series:
 - Remove mutex_lock/mutex_unlock since they don't do anything and we're
   not touching global state
 - Move skl_write_cursor_wm/skl_write_plane_wm functions into
   intel_pm.c, make externally visible
 - Add skl_write_plane_wm calls to skl_update_plane
 - Fix conditional for for loop in skl_write_plane_wm (level < max_level
   should be level <= max_level)
 - Make diagram in commit more accurate to what's actually happening
 - Add Fixes:

Changes since v1:
 - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
   then just Skylake
 - Update description to make it clear this patch doesn't fix everything
 - Check if pipes were actually changed before writing watermarks

Changes since v2:
 - Write PIPE_WM_LINETIME during vblank evasion

Changes since v3:
 - Rebase against new SAGV patch changes

Changes since v4:
 - Add a parameter to choose what skl_wm_values struct to use when
   writing new plane watermarks

Changes since v5:
 - Remove cursor ddb entry write in skl_write_cursor_wm(), defer until
   patch 6
 - Write WM_LINETIME in intel_begin_crtc_commit()

Changes since v6:
 - Remove redundant dirty_pipes check in skl_write_plane_wm (we check
   this in all places where we call this function, and it was supposed
   to have been removed earlier anyway)
 - In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of
   IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this
   needs to be done for gen10 as well

Changes since v7:
 - Fix rebase fail (unused variable obj)
 - Make struct skl_wm_values *wm const
 - Fix indenting
 - Use INTEL_GEN() instead of dev_priv->info.gen

Changes since v8:
 - Don't forget calls to skl_write_plane_wm() when disabling planes
 - Use INTEL_GEN(), not INTEL_INFO()->gen in intel_begin_crtc_commit()

Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Signed-off-by: Maarten Lankhorst 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1471884608-10671-1-git-send-email-cp...@redhat.com
Link: 
http://patchwork.freedesktop.org/patch/msgid/1471884608-10671-1-git-send-email-cp...@redhat.com
---
 drivers/gpu/drm/i915/intel_display.c | 21 +--
 drivers/gpu/drm/i915/intel_drv.h |  5 
 drivers/gpu/drm/i915/intel_pm.c  | 50 

[Intel-gfx] [PATCH 2/5] drm/i915: Move CRTC updating in atomic_commit into it's own hook

[Lyude]

commit 896e5bb022bce64e29ce2e1b2fc2a7476d311a15 upstream

Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.

Based off of Matt Rope's suggestions

Changes since v1:
 - Drop pipe_config->base.active check in intel_update_crtcs() since we
   check that before calling the function

Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 

Signed-off-by: Lyude 
Signed-off-by: Maarten Lankhorst 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-1-git-send-email-cp...@redhat.com
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/intel_display.c | 74 +---
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f68c789..ad75dbd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -631,6 +631,8 @@ struct drm_i915_display_funcs {
  struct intel_crtc_state *crtc_state);
void (*crtc_enable)(struct drm_crtc *crtc);
void (*crtc_disable)(struct drm_crtc *crtc);
+   void (*update_crtcs)(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask);
void (*audio_codec_enable)(struct drm_connector *connector,
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1ae587f..e2c46eb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13682,6 +13682,52 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
return false;
 }
 
+static void intel_update_crtc(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_crtc_state,
+ unsigned int *crtc_vblank_mask)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state);
+   bool modeset = needs_modeset(crtc->state);
+
+   if (modeset) {
+   update_scanline_offset(intel_crtc);
+   dev_priv->display.crtc_enable(crtc);
+   } else {
+   intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
+   }
+
+   if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
+   intel_fbc_enable(
+   intel_crtc, pipe_config,
+   to_intel_plane_state(crtc->primary->state));
+   }
+
+   drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
+
+   if (needs_vblank_wait(pipe_config))
+   *crtc_vblank_mask |= drm_crtc_mask(crtc);
+}
+
+static void intel_update_crtcs(struct drm_atomic_state *state,
+  unsigned int *crtc_vblank_mask)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *old_crtc_state;
+   int i;
+
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+   if (!crtc->state->active)
+   continue;
+
+   intel_update_crtc(crtc, state, old_crtc_state,
+ crtc_vblank_mask);
+   }
+}
+
 static void intel_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
@@ -13780,17 +13826,9 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
intel_modeset_verify_disabled(dev);
}
 
-   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
+   /* Complete the events for pipes that have now been disabled */
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->state);
-
-   if (modeset && crtc->state->active) {
-   update_scanline_offset(to_intel_crtc(crtc));
-   dev_priv->display.crtc_enable(crtc);
-  

Re: [Intel-gfx] [PATCH] lib/ida: Document locking requirements a bit better

[Daniel Vetter]

On Wed, Oct 26, 2016 at 10:39:29AM -0400, Tejun Heo wrote:
> Hello, Daniel.
> 
> On Wed, Oct 26, 2016 at 04:27:39PM +0200, Daniel Vetter wrote:
> > I wanted to wrap a bunch of ida_simple_get calls into their own
> > locking, until I dug around and read the original commit message.
> > Stuff like this should imo be added to the kernel doc, let's do that.
> 
> Generally agreed but some nits below.

I value good docs but I suck at typing them ;-)

> > @@ -927,6 +927,9 @@ EXPORT_SYMBOL(ida_pre_get);
> >   * and go back to the ida_pre_get() call.  If the ida is full, it will
> >   * return %-ENOSPC.
> >   *
> > + * Note that callers must ensure that concurrent access to @ida is not 
> > possible.
> > + * When simplicity trumps concurrency needs look at ida_simple_get() 
> > instead.
> 
> Maybe we can make it a bit less dramatic?

What about?

"Note that callers must ensure that concurrent access to @ida is not possible.
See ida_simple_get() for a varaint which takes care of locking.
> 
> 
> > @@ -1073,6 +1076,10 @@ EXPORT_SYMBOL(ida_destroy);
> >   * Allocates an id in the range start <= id < end, or returns -ENOSPC.
> >   * On memory allocation failure, returns -ENOMEM.
> >   *
> > + * Compared to ida_get_new_above() this function does its own locking and 
> > hence
> > + * is recommended everywhere where simplicity is preferred over the last 
> > bit of
> > + * speed.
> 
> Hmm... so, this isn't necessarily about speed.  For example, id
> allocation might have to happen inside a spinlock which protects a
> larger scope.  To guarantee GFP_KERNEL allocation behavior in such
> cases, the caller would have to call ida_pre_get() outside the said
> spinlock and then call ida_get_new_above() inside the lock.

Hm, ida_simple_get does that for you already ...

> I think it'd be better to explain what the simple version does and
> expects and then say that unless there are specific requirements using
> the simple version is recommended.

What about:

"Compared to ida_get_new_above() this function does its own locking, and
should be used unless there are special requirements."

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix scaling check for 90/270 degree plane rotation

[Patchwork]

== Series Details ==

Series: drm/i915: Fix scaling check for 90/270 degree plane rotation
URL   : https://patchwork.freedesktop.org/series/14423/
State : success

== Summary ==

Series 14423v1 drm/i915: Fix scaling check for 90/270 degree plane rotation
https://patchwork.freedesktop.org/api/1.0/series/14423/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

0eefa35311a3d85e6cbfda4bb326809581acc3b1 drm-intel-nightly: 
2016y-10m-26d-17h-38m-29s UTC integration manifest
a444c32 drm/i915: Fix scaling check for 90/270 degree plane rotation

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2829/

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: BDW cdclk fix for DP audio

[Jani Nikula]

On Wed, 26 Oct 2016, "Pandiyan, Dhinakaran"  
wrote:
> On Wed, 2016-10-26 at 11:54 +0300, Jani Nikula wrote:
>> On Wed, 26 Oct 2016, Dhinakaran Pandiyan  
>> wrote:
>> > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
>> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
>> >
>> > Having a lower cdclk triggers pipe underruns, which then lead to displays
>> > continuously cycling off and on. This is essential for DP MST audio as the
>> > link is trained at HBR2 and 4 lanes by default.
>> >
>> > v3: Combine BDW pixel rate adjustments into a function (Jani)
>> > v2: Restrict fix to BDW
>> > Retain the set cdclk across modesets (Ville)
>> > Cc: sta...@vger.kernel.org
>> > Signed-off-by: Dhinakaran Pandiyan 
>> > Reviewed-by: Ville Syrjälä 
>> 
>> Reviewed-by: Jani Nikula 
>> 
>> We'll need this fix for Skylake too, don't we? Maybe Kabylake? Please
>> send a follow-up patch for Skylake with the changes mentioned inline
>> below.
>> 
>> BR,
>> Jani.
>> 
>> 
>
> Patch 1/2 should take care of gen9 platforms when audio sampling rates
> are <= 96 kHz. I am still not sure how to increase increase cdclk when
> the sampling rates > 96kHZ , that is why I have added the TODO in Patch
> 1/2.

IIUC the two patches and fixes are related, but separate. This one
requires 4 lanes, the other one doesn't. For this one there's no mention
of audio sampling rate.

BR,
Jani.


>
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c | 27 ---
>> >  1 file changed, 24 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index a94f7d1..efe46b4 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -10260,6 +10260,27 @@ static void bxt_modeset_commit_cdclk(struct 
>> > drm_atomic_state *old_state)
>> >bxt_set_cdclk(to_i915(dev), req_cdclk);
>> >  }
>> >  
>> > +static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
>> > *crtc_state,
>> > +int pixel_rate)
>> > +{
>> > +  /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
>> > +  if (crtc_state->ips_enabled)
>> 
>> if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
>> 
>> > +  pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
>> > +
>> > +  /* BSpec says "Do not use DisplayPort with CDCLK less than
>> > +   * 432 MHz, audio enabled, port width x4, and link rate
>> > +   * HBR2 (5.4 GHz), or else there may be audio corruption or
>> > +   * screen corruption."
>> > +   */
>> > +  if (intel_crtc_has_dp_encoder(crtc_state) &&
>> > +  crtc_state->has_audio &&
>> > +  crtc_state->port_clock >= 54 &&
>> > +  crtc_state->lane_count == 4)
>> > +  pixel_rate = max(432000, pixel_rate);
>> > +
>> > +  return pixel_rate;
>> > +}
>> > +
>> >  /* compute the max rate for new configuration */
>> >  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
>> >  {
>> > @@ -10285,9 +10306,9 @@ static int ilk_max_pixel_rate(struct 
>> > drm_atomic_state *state)
>> >  
>> >pixel_rate = ilk_pipe_pixel_rate(crtc_state);
>> >  
>> > -  /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
>> > -  if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
>> > -  pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
>> > +  if (IS_BROADWELL(dev_priv))
>> 
>> if (IS_BROADWELL(dev_priv) || IS_SKYLAKE(dev_priv))
>> 
>> > +  pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
>> > +  pixel_rate);
>> >  
>> >intel_state->min_pixclk[i] = pixel_rate;
>> >}
>> 
>

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

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Jani Nikula]

On Wed, 26 Oct 2016, "Pandiyan, Dhinakaran"  
wrote:
> On Wed, 2016-10-26 at 11:57 +0300, Jani Nikula wrote:
>> On Wed, 26 Oct 2016, Dhinakaran Pandiyan  
>> wrote:
>> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
>> > let's set this bit right before enabling the audio codec. Playing audio
>> > without setting this bit results in pipe FIFO underruns.
>> >
>> > This workaround is applicable only for audio sample rates up to 96kHz. For
>> > frequencies above 96kHz, this is insufficient and cdclk should be increased
>> > to at least 432 MHz, just like BDW. Since, the audio driver does not
>> > support sample rates > 48 kHz, we are safe with this fix for now.
>> >
>> > v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
>> > Fixed the port clock typo
>> > Added TODO comment
>> > Signed-off-by: Dhinakaran Pandiyan 
>> > ---
>> >  drivers/gpu/drm/i915/i915_reg.h|  5 +
>> >  drivers/gpu/drm/i915/intel_audio.c | 30 +-
>> >  2 files changed, 34 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index 00efaa1..76dac48 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -6236,6 +6236,11 @@ enum {
>> >  #define SLICE_ECO_CHICKEN0_MMIO(0x7308)
>> >  #define   PIXEL_MASK_CAMMING_DISABLE  (1 << 14)
>> >  
>> > +#define _CHICKEN_TRANS_A  0x420C0
>> > +#define _CHICKEN_TRANS_B  0x420C4
>> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
>> > _CHICKEN_TRANS_B)
>> > +#define SPARE_13  (1<<13)
>> > +
>> >  /* WaCatErrorRejectionIssue */
>> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG_MMIO(0x9030)
>> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB (1<<11)
>> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>> > b/drivers/gpu/drm/i915/intel_audio.c
>> > index 7093cfb..894f11e 100644
>> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > @@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct 
>> > intel_encoder *encoder)
>> >  {
>> >struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> >struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
>> > +  struct intel_crtc_state *crtc_config =  intel_crtc->config;
>> > +  enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
>> >enum pipe pipe = intel_crtc->pipe;
>> >uint32_t tmp;
>> >  
>> > @@ -290,13 +292,21 @@ static void hsw_audio_codec_disable(struct 
>> > intel_encoder *encoder)
>> >  
>> >mutex_lock(_priv->av_mutex);
>> >  
>> > +  /*Disable DP audio stall fix for HBR2*/
>> 
>> Nitpick, spaces after /* and before */.
>> 
>> > +  if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
>> > +  crtc_config->port_clock >= 54) {
>> > +  tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
>> > +  tmp &= ~SPARE_13;
>> > +  I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
>> > +  }
>> 
>> Hmm. Why don't we just do this unconditionally?
>> 
>
> That bit is disabled by default, so avoiding  two MMIO ops. that are not
> required.

That makes no difference on the modeset path.

>
>> > +
>> >/* Disable timestamps */
>> >tmp = I915_READ(HSW_AUD_CFG(pipe));
>> >tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
>> >tmp |= AUD_CONFIG_N_PROG_ENABLE;
>> >tmp &= ~AUD_CONFIG_UPPER_N_MASK;
>> >tmp &= ~AUD_CONFIG_LOWER_N_MASK;
>> > -  if (intel_crtc_has_dp_encoder(intel_crtc->config))
>> > +  if (intel_crtc_has_dp_encoder(crtc_config))
>> >tmp |= AUD_CONFIG_N_VALUE_INDEX;
>> >I915_WRITE(HSW_AUD_CFG(pipe), tmp);
>> >  
>> > @@ -315,6 +325,8 @@ static void hsw_audio_codec_enable(struct 
>> > drm_connector *connector,
>> >  {
>> >struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> >struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
>> > +  struct intel_crtc_state *crtc_config =  intel_crtc->config;
>> > +  enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
>> >enum pipe pipe = intel_crtc->pipe;
>> >enum port port = intel_encoder->port;
>> >const uint8_t *eld = connector->eld;
>> > @@ -326,6 +338,22 @@ static void hsw_audio_codec_enable(struct 
>> > drm_connector *connector,
>> >  
>> >mutex_lock(_priv->av_mutex);
>> >  
>> > +  /* Enable DP audio stall fix for HBR2
>> > +   *
>> > +   * TODO: This workaround is applicable only for audio sample rates up
>> > +   * to 96kHz. For frequencies above 96kHz, this is insufficient and
>> > +   * cdclk should be increased to at least 432 MHz, just like BDW. Since,
>> > +   * the audio driver does not support sample rates > 48 kHz, we are safe
>> > +   * with this fix for now.
>> > +   */
>> 
>> Is this TODO required if you already have that check in patch 2/2?
>> 
>
> 

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

On 26 Oct 2016 5:54 p.m., "Ville Syrjälä" 
wrote:
>
> On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote:
> > On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <
> > ville.syrj...@linux.intel.com> wrote:
> >
> > > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> > > > On 26 Oct 2016 9:54 a.m., "Chris Wilson" 
> > > wrote:
> > > > >
> > > > > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > > > > >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > > > > ><[1]matthew.william.a...@gmail.com> wrote:
> > > > > >
> > > > > >  On 25 October 2016 at 00:19, Robert Bragg <[2]
> > > rob...@sixbynine.org>
> > > > > >  wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >  > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > >  b/drivers/gpu/drm/i915/i915_drv.h
> > > > > >  > index 3448d05..ea24814 100644
> > > > > >  > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > >  > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > >  > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > > > > >
> > > > > >  >
> > > > > >  >  struct drm_i915_private {
> > > > > >  > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > > > > >  >
> > > > > >  > struct {
> > > > > >  > bool initialized;
> > > > > >  > +
> > > > > >  > struct mutex lock;
> > > > > >  > struct list_head streams;
> > > > > >  >
> > > > > >  > +   spinlock_t hook_lock;
> > > > > >  > +
> > > > > >  > struct {
> > > > > >  > -   u32 metrics_set;
> > > > > >  > +   struct i915_perf_stream
> > > > *exclusive_stream;
> > >
> > > OT:
> > > What kind of MUA are you using that mangles quoted mails like this?
I've
> > > not seen it on intel-gfx before. mesa-dev seems rife with it, but as I
> > > rarely read that in any great detail I've managed to ignore it there.
> > > Anyways, it makes it espesially hard to navigate long mails since
mutt's
> > > 'S' (skip quoted text) no longer works correctly.
> > >
> >
> > Not sure I want to say, and get booted out the door :-)
> >
> > I've heard that gmail has an annoying habit of forcibly wrapping plain
text
> > emails like this, and a lot of people have complained that there's no
way
> > to disable that 'feature' :-/
> >
> > I used to use Mutt, but I don't think I could really bare to go back to
it
> > any more. Last time I was using it I found myself spending too much time
> > patching it to try and make it work how I'd like, but can't say I got
much
> > enjoyment from that process.
>
> Isn't gmail just a pile of client side javascript or something? Maybe
> you'd enjoy patching that one more? ;)
>
> >
> > I've tried most MUA options available, and can't say any of them make me
> > very happy - I think these days it's just not something developers are
very
> > interesting in working on.
> >
> > I'm a sell out and just use Gmail... sorry. I can't really see myself
> > changing, though I do wish Google weren't so pedantic about forcing
> > wrapping without any option to change that behaviour. I suspect you
> > wouldn't be happy with me sending html emails, which has been Google's
> > default response to this complaint afik.
> >
> > Maybe it's gmail users causing trouble on the Mesa list too.
> >
> > - Robert
> >
> > P.S please don't think lesser of me due to my misguided MUA choices.
>
> I think I'll just reserve the right to ignore any mail with bad quoting.

Okey, fwiw, at least my patches sent out via git send-email should be fine,
so maybe just ignore my replies to feedback - which I promise not to
exploit to achieve 'consensus' through silence.

- Robert

--
Sent from Gmail on Android, in a spare moment at a VR for Immersive Theatre
meet up.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vlv: Prevent enabling hpd polling in late suspend

[Patchwork]

== Series Details ==

Series: drm/i915/vlv: Prevent enabling hpd polling in late suspend
URL   : https://patchwork.freedesktop.org/series/14420/
State : success

== Summary ==

Series 14420v1 drm/i915/vlv: Prevent enabling hpd polling in late suspend
https://patchwork.freedesktop.org/api/1.0/series/14420/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

0eefa35311a3d85e6cbfda4bb326809581acc3b1 drm-intel-nightly: 
2016y-10m-26d-17h-38m-29s UTC integration manifest
c96a2cc drm/i915/vlv: Prevent enabling hpd polling in late suspend

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2828/

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Wed, 2016-10-26 at 08:37 +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 09:18:36PM -0700, Dhinakaran Pandiyan wrote:
> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> > let's set this bit right before enabling the audio codec. Playing audio
> > without setting this bit results in pipe FIFO underruns.
> 
> Please insert a full Bspec citation here so that we can find where this is
> documented in the future. Both where in Bspec it is, and then just quote
> the full text with the explanation and put that into the commit message.
> 
> Otherwise there's no way we'll ever find this again in the future.
> -Daniel
> 
This particular update has not landed in BSpec yet. I will update the
commit message and re-send the patches after they are reviewed.

> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  5 +
> >  drivers/gpu/drm/i915/intel_ddi.c | 38 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  3 files changed, 45 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00efaa1..76dac48 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6236,6 +6236,11 @@ enum {
> >  #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
> >  #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
> >  
> > +#define _CHICKEN_TRANS_A   0x420C0
> > +#define _CHICKEN_TRANS_B   0x420C4
> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> > _CHICKEN_TRANS_B)
> > +#define SPARE_13   (1<<13)
> > +
> >  /* WaCatErrorRejectionIssue */
> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index fb18d69..84c91c1 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1858,6 +1858,38 @@ void intel_ddi_fdi_post_disable(struct intel_encoder 
> > *intel_encoder,
> > I915_WRITE(FDI_RX_CTL(PIPE_A), val);
> >  }
> >  
> > +void gen9_enable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(pipe_config->base.crtc->dev);
> > +   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > +   uint32_t temp;
> > +
> > +   if (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->port_clock >= 54000) {
> > +
> > +   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   temp |= SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
> > +   }
> > +}
> > +
> > +void gen9_disable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(pipe_config->base.crtc->dev);
> > +   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > +   uint32_t temp;
> > +
> > +   if (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->port_clock >= 54000) {
> > +
> > +   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   temp &= ~SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
> > +   }
> > +}
> > +
> >  static void intel_enable_ddi(struct intel_encoder *intel_encoder,
> >  struct intel_crtc_state *pipe_config,
> >  struct drm_connector_state *conn_state)
> > @@ -1893,6 +1925,9 @@ static void intel_enable_ddi(struct intel_encoder 
> > *intel_encoder,
> > }
> >  
> > if (intel_crtc->config->has_audio) {
> > +   if (IS_GEN9(dev_priv))
> > +   gen9_enable_dp_audio_stall_fix(pipe_config);
> > +
> > intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
> > intel_audio_codec_enable(intel_encoder);
> > }
> > @@ -1912,6 +1947,9 @@ static void intel_disable_ddi(struct intel_encoder 
> > *intel_encoder,
> > if (intel_crtc->config->has_audio) {
> > intel_audio_codec_disable(intel_encoder);
> > intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
> > +
> > +   if (IS_GEN9(dev_priv))
> > +   gen9_disable_dp_audio_stall_fix(old_crtc_state);
> > }
> >  
> > if (type == INTEL_OUTPUT_EDP) {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 4e90b07..ef02c62 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1189,6 +1189,8 @@ unsigned int intel_fb_align_height(struct drm_device 
> > *dev,
> >uint64_t fb_format_modifier);
> >  u32 intel_fb_stride_alignment(const struct drm_i915_private *dev_priv,
> >   uint64_t fb_modifier, uint32_t pixel_format);
> > +void 

[Intel-gfx] [PATCH] drm/i915/fbc: Assume maximum 8mb of stolen is used for gen8+

[Rodrigo Vivi]

Since Broxton has same FBC block as BDW+ let's assume it also
don't have access to the stolen usable range.

FBC is currently not saving power on Broxton and I believe
the compression threshold is limited to 1x.

Cc: Paulo Zanoni 
Cc: Marc Herbert 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index cbe2ebd..640db67 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -530,12 +530,11 @@ static int find_compression_threshold(struct 
drm_i915_private *dev_priv,
int ret;
u64 end;
 
-   /* The FBC hardware for BDW/SKL doesn't have access to the stolen
+   /* The FBC hardware for gen8+ doesn't have access to the stolen
 * reserved range size, so it always assumes the maximum (8mb) is used.
 * If we enable FBC using a CFB on that memory range we'll get FIFO
 * underruns, even if that range is not reserved by the BIOS. */
-   if (IS_BROADWELL(dev_priv) ||
-   IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+   if (INTEL_INFO(dev_priv)->gen <= 8)
end = ggtt->stolen_size - 8 * 1024 * 1024;
else
end = ggtt->stolen_usable_size;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: BDW cdclk fix for DP audio

[Pandiyan, Dhinakaran]

On Wed, 2016-10-26 at 11:54 +0300, Jani Nikula wrote:
> On Wed, 26 Oct 2016, Dhinakaran Pandiyan  
> wrote:
> > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> >
> > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > continuously cycling off and on. This is essential for DP MST audio as the
> > link is trained at HBR2 and 4 lanes by default.
> >
> > v3: Combine BDW pixel rate adjustments into a function (Jani)
> > v2: Restrict fix to BDW
> > Retain the set cdclk across modesets (Ville)
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Dhinakaran Pandiyan 
> > Reviewed-by: Ville Syrjälä 
> 
> Reviewed-by: Jani Nikula 
> 
> We'll need this fix for Skylake too, don't we? Maybe Kabylake? Please
> send a follow-up patch for Skylake with the changes mentioned inline
> below.
> 
> BR,
> Jani.
> 
> 

Patch 1/2 should take care of gen9 platforms when audio sampling rates
are <= 96 kHz. I am still not sure how to increase increase cdclk when
the sampling rates > 96kHZ , that is why I have added the TODO in Patch
1/2.

> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 27 ---
> >  1 file changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a94f7d1..efe46b4 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10260,6 +10260,27 @@ static void bxt_modeset_commit_cdclk(struct 
> > drm_atomic_state *old_state)
> > bxt_set_cdclk(to_i915(dev), req_cdclk);
> >  }
> >  
> > +static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> > *crtc_state,
> > + int pixel_rate)
> > +{
> > +   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> > +   if (crtc_state->ips_enabled)
> 
> if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> 
> > +   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> > +
> > +   /* BSpec says "Do not use DisplayPort with CDCLK less than
> > +* 432 MHz, audio enabled, port width x4, and link rate
> > +* HBR2 (5.4 GHz), or else there may be audio corruption or
> > +* screen corruption."
> > +*/
> > +   if (intel_crtc_has_dp_encoder(crtc_state) &&
> > +   crtc_state->has_audio &&
> > +   crtc_state->port_clock >= 54 &&
> > +   crtc_state->lane_count == 4)
> > +   pixel_rate = max(432000, pixel_rate);
> > +
> > +   return pixel_rate;
> > +}
> > +
> >  /* compute the max rate for new configuration */
> >  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
> >  {
> > @@ -10285,9 +10306,9 @@ static int ilk_max_pixel_rate(struct 
> > drm_atomic_state *state)
> >  
> > pixel_rate = ilk_pipe_pixel_rate(crtc_state);
> >  
> > -   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> > -   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> > -   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> > +   if (IS_BROADWELL(dev_priv))
> 
> if (IS_BROADWELL(dev_priv) || IS_SKYLAKE(dev_priv))
> 
> > +   pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
> > +   pixel_rate);
> >  
> > intel_state->min_pixclk[i] = pixel_rate;
> > }
> 

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

Re: [Intel-gfx] [PATCH igt 3/3] igt/gem_exec_parse: update for version 8 changes

[Chris Wilson]

On Wed, Oct 26, 2016 at 05:01:33PM +0100, Robert Bragg wrote:
> This adapts the tests to account for the parser no longer reporting
> privilege violations back to userspace as EINVAL errors (they are left
> to the HW command parser to squash the commands to NOOPS).
> 
> The interface change isn't expected to affect userspace and in fact it
> looks like the previous behaviour was liable to break userspace, such as
> Mesa which explicitly tries to observe whether OACONTROL LRIs are
> squashed to NOOPs but Mesa will abort for execbuffer errors.

That's an extremely large patch for a simple version check. The test for
LRI turning into noops is already there.
-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/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Wed, 2016-10-26 at 11:57 +0300, Jani Nikula wrote:
> On Wed, 26 Oct 2016, Dhinakaran Pandiyan  
> wrote:
> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> > let's set this bit right before enabling the audio codec. Playing audio
> > without setting this bit results in pipe FIFO underruns.
> >
> > This workaround is applicable only for audio sample rates up to 96kHz. For
> > frequencies above 96kHz, this is insufficient and cdclk should be increased
> > to at least 432 MHz, just like BDW. Since, the audio driver does not
> > support sample rates > 48 kHz, we are safe with this fix for now.
> >
> > v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
> > Fixed the port clock typo
> > Added TODO comment
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h|  5 +
> >  drivers/gpu/drm/i915/intel_audio.c | 30 +-
> >  2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00efaa1..76dac48 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6236,6 +6236,11 @@ enum {
> >  #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
> >  #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
> >  
> > +#define _CHICKEN_TRANS_A   0x420C0
> > +#define _CHICKEN_TRANS_B   0x420C4
> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> > _CHICKEN_TRANS_B)
> > +#define SPARE_13   (1<<13)
> > +
> >  /* WaCatErrorRejectionIssue */
> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 7093cfb..894f11e 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder *encoder)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > +   struct intel_crtc_state *crtc_config =  intel_crtc->config;
> > +   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> > enum pipe pipe = intel_crtc->pipe;
> > uint32_t tmp;
> >  
> > @@ -290,13 +292,21 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder *encoder)
> >  
> > mutex_lock(_priv->av_mutex);
> >  
> > +   /*Disable DP audio stall fix for HBR2*/
> 
> Nitpick, spaces after /* and before */.
> 
> > +   if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
> > +   crtc_config->port_clock >= 54) {
> > +   tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   tmp &= ~SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
> > +   }
> 
> Hmm. Why don't we just do this unconditionally?
> 

That bit is disabled by default, so avoiding  two MMIO ops. that are not
required.

> > +
> > /* Disable timestamps */
> > tmp = I915_READ(HSW_AUD_CFG(pipe));
> > tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> > tmp |= AUD_CONFIG_N_PROG_ENABLE;
> > tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> > tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> > -   if (intel_crtc_has_dp_encoder(intel_crtc->config))
> > +   if (intel_crtc_has_dp_encoder(crtc_config))
> > tmp |= AUD_CONFIG_N_VALUE_INDEX;
> > I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> >  
> > @@ -315,6 +325,8 @@ static void hsw_audio_codec_enable(struct drm_connector 
> > *connector,
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
> > +   struct intel_crtc_state *crtc_config =  intel_crtc->config;
> > +   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> > enum pipe pipe = intel_crtc->pipe;
> > enum port port = intel_encoder->port;
> > const uint8_t *eld = connector->eld;
> > @@ -326,6 +338,22 @@ static void hsw_audio_codec_enable(struct 
> > drm_connector *connector,
> >  
> > mutex_lock(_priv->av_mutex);
> >  
> > +   /* Enable DP audio stall fix for HBR2
> > +*
> > +* TODO: This workaround is applicable only for audio sample rates up
> > +* to 96kHz. For frequencies above 96kHz, this is insufficient and
> > +* cdclk should be increased to at least 432 MHz, just like BDW. Since,
> > +* the audio driver does not support sample rates > 48 kHz, we are safe
> > +* with this fix for now.
> > +*/
> 
> Is this TODO required if you already have that check in patch 2/2?
> 

In fact, this patch itself is not required if we are increasing the
cdclk to 432 MHz for gen9 platforms (like patch 2/2). Having this
workaround gives us the option running the pipeline at a lower cdclk
frequency 

Re: [Intel-gfx] [PATCH i-g-t v2] configure.ac: correctly manage DRM_INTEL_{CFLAGS, LIBS}

[Brian Starkey]

Hi Emil,

On Wed, Oct 26, 2016 at 05:18:47PM +0100, Emil Velikov wrote:

From: Emil Velikov 

Currently the latter is only set when using --enable-intel.

Whereas for the CFLAGS: if we "enable" PKG_CHECK_MODULES sets the
variable, while for "disable" we do it locally. In either case the
CFLAGS is not propagated through, this one can get build issues
regardless of the actual state of the toggle.

v2: Add -I for the include directive and correctly propagate
$(top_srcdir).

Cc: Brian Starkey 
Cc: Robert Foss 
Reported-by: Brian Starkey 
Signed-off-by: Emil Velikov 
---


This fixes my include path problem, so:

Tested-by: Brian Starkey 

Thanks very much for your help,
-Brian


This time fully tested:
- enable/disable/auto with and w/o libdrm_intel :-)

Did not see much point in splitting the v2 only changes to 1/2 and keep
this as 2/2. I don't mind either way though :-)
---
configure.ac | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 735cfd5..e181c83 100644
--- a/configure.ac
+++ b/configure.ac
@@ -178,12 +178,15 @@ fi
if test "x$INTEL" = xyes; then
PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])
AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel support])
-   DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
-   AC_SUBST([DRM_LIBS])
else
-   DRM_INTEL_CFLAGS=$(top_srcdir)/lib/stubs/drm/
-   AC_SUBST([DRM_INTEL_CFLAGS])
+   DRM_INTEL_CFLAGS=-I$\(top_srcdir\)/lib/stubs/drm/
+   DRM_INTEL_LIBS=
fi
+DRM_CFLAGS="$DRM_CFLAGS $DRM_INTEL_CFLAGS"
+DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
+AC_SUBST([DRM_CFLAGS])
+AC_SUBST([DRM_LIBS])
+
AM_CONDITIONAL(HAVE_LIBDRM_INTEL, [test "x$INTEL" = xyes])

# for dma-buf tests
--
2.9.3


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

[Intel-gfx] [PATCH 0/4] drm/i915: Abort if crtc/plane init fails

[ville . syrjala]

From: Ville Syrjälä 

I recently realized that we can't really continue with loading the driver
if we fail to initialize some of the crtcs or planes. So this series makes
us fail the load in those cases. The failures would be due to kmalloc()
failing anyway, so doesn't seem too drastic to abort entirely in that case.

I also reorder things so that we'll initialize the planes in an order that
matches the new rules for handling zpos conflicts between the planes. We don't
expose the zpos property yet, but I have some preliminary patches for that
as well sitting around in a branch. Actually only VLV, CHV and pre-g4x can
dynamically adjust the zpos of the planes, for the rest it's entirely fixed.

And finally I do a bit of house cleaning in the sprite init code.

Entire series available here:
git://github.com/vsyrjala/linux.git plane_init_order

Ville Syrjälä (4):
  drm/i915: Don't try to initialize sprite planes on pre-ilk
  drm/i915: Initialize planes in a reasonable order
  drm/i915: Bail if plane/crtc init fails
  drm/i915: Reorganize sprite init

 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.c |   5 +-
 drivers/gpu/drm/i915/intel_display.c | 107 ---
 drivers/gpu/drm/i915/intel_drv.h |   3 +-
 drivers/gpu/drm/i915/intel_sprite.c  |  81 ++-
 6 files changed, 112 insertions(+), 90 deletions(-)

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[Ville Syrjälä]

On Tue, Oct 25, 2016 at 10:55:35AM +0100, Chris Wilson wrote:
> On Tue, Oct 25, 2016 at 12:39:43PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 25, 2016 at 08:20:46AM +0100, Chris Wilson wrote:
> > > On Mon, Oct 24, 2016 at 07:13:04PM +0300, ville.syrj...@linux.intel.com 
> > > wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Pass the framebuffer size in .16 fixed point coordinates to
> > > > drm_rect_rotate() since that's what the source coordinates are as well
> > > > at this stage. We used to do this part of the computation in integer
> > > > coordinates, but that got changed when moving the computation to
> > > > happen in the check phase of the operation. Unfortunately I forgot
> > > > to shift up the fb width and height appropriately.
> > > > 
> > > > With the bogus size we ended up with some negative fb offset, which when
> > > > added to the vma offset caused out scanout to start at an offset earlier
> > > > than we inteded. Eg. when testing on my SKL I saw a row of incorrect
> > > > tiles at the top of my screen.
> > > > 
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: Sivakumar Thulasimani 
> > > > Cc: drm-intel-fi...@lists.freedesktop.org
> > > > Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the 
> > > > plane check hook for SKL+")
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 5a036999487b..c783f884f85d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -2985,7 +2985,8 @@ int skl_check_plane_surface(struct 
> > > > intel_plane_state *plane_state)
> > > > /* Rotate src coordinates to match rotated GTT view */
> > > > if (drm_rotation_90_or_270(rotation))
> > > > drm_rect_rotate(_state->base.src,
> > > > -   fb->width, fb->height, DRM_ROTATE_270);
> > > > +   fb->width << 16, fb->height << 16,
> > > > +   DRM_ROTATE_270);
> > > 
> > > Line 2576 (intel_fill_fb_info()) also looks wrong.
> > > 
> > > drm_rect_rotate(,
> > >   rot_info->plane[i].width * tile_width,
> > >   rot_info->plane[i].height * tile_height,
> > >   DRM_ROTATE_270);
> > 
> > That should be fine. No sub-pixel stuff going on in that
> > function.
> 
> Ah, yes r is not scaled.
> 
> Reviewed-by: Chris Wilson 

Pushed to dinq. Thanks for the review and testing.

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

[Intel-gfx] [PATCH] drm/i915: Fix scaling check for 90/270 degree plane rotation

[ville . syrjala]

From: Ville Syrjälä 

Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface
offset in the plane check hook for SKL+") we've already rotated the src
coordinates by 270 degrees by the time we check if a scaler is needed
or not, so we must not account for the rotation a second time.
Previously we did these steps in the opposite order and hence the
scaler check had to deal with rotation itself. The double rotation
handling causes us to enable a scaler pretty much every time 90/270
degree plane rotation is requested, leading to fuzzier fonts and whatnot.

Cc: Sivakumar Thulasimani 
Cc: Tvrtko Ursulin 
Cc: drm-intel-fi...@lists.freedesktop.org
Reported-by: Tvrtko Ursulin 
Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane 
check hook for SKL+")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5a036999487b..587cd604ce92 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4671,7 +4671,7 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
- unsigned scaler_user, int *scaler_id, unsigned int rotation,
+ unsigned scaler_user, int *scaler_id,
  int src_w, int src_h, int dst_w, int dst_h)
 {
struct intel_crtc_scaler_state *scaler_state =
@@ -4680,9 +4680,12 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
to_intel_crtc(crtc_state->base.crtc);
int need_scaling;
 
-   need_scaling = drm_rotation_90_or_270(rotation) ?
-   (src_h != dst_w || src_w != dst_h):
-   (src_w != dst_w || src_h != dst_h);
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
+   need_scaling = src_w != dst_w || src_h != dst_h;
 
/*
 * if plane is being disabled or scaler is no more required or force 
detach
@@ -4749,7 +4752,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
  intel_crtc->pipe, SKL_CRTC_INDEX);
 
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
-   >scaler_state.scaler_id, DRM_ROTATE_0,
+   >scaler_state.scaler_id,
state->pipe_src_w, state->pipe_src_h,
adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
 }
@@ -4783,7 +4786,6 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
ret = skl_update_scaler(crtc_state, force_detach,
drm_plane_index(_plane->base),
_state->scaler_id,
-   plane_state->base.rotation,
drm_rect_width(_state->base.src) >> 16,
drm_rect_height(_state->base.src) >> 16,
drm_rect_width(_state->base.dst),
-- 
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: Print some debug/error info during DP dual mode detect (rev2)

[Patchwork]

== Series Details ==

Series: drm: Print some debug/error info during DP dual mode detect (rev2)
URL   : https://patchwork.freedesktop.org/series/14412/
State : success

== Summary ==

Series 14412v2 drm: Print some debug/error info during DP dual mode detect
https://patchwork.freedesktop.org/api/1.0/series/14412/revisions/2/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

fe116755dd4cf23c17c8ad50227ca4376480d015 drm-intel-nightly: 
2016y-10m-26d-14h-34m-03s UTC integration manifest
99d41e5 drm: Print some debug/error info during DP dual mode detect

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2827/

== Logs ==

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote:
> On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
> 
> > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> > > On 26 Oct 2016 9:54 a.m., "Chris Wilson" 
> > wrote:
> > > >
> > > > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > > > >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > > > ><[1]matthew.william.a...@gmail.com> wrote:
> > > > >
> > > > >  On 25 October 2016 at 00:19, Robert Bragg <[2]
> > rob...@sixbynine.org>
> > > > >  wrote:
> > > > >
> > > > >
> > > > >
> > > > >  > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > >  b/drivers/gpu/drm/i915/i915_drv.h
> > > > >  > index 3448d05..ea24814 100644
> > > > >  > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > >  > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > >  > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > > > >
> > > > >  >
> > > > >  >  struct drm_i915_private {
> > > > >  > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > > > >  >
> > > > >  > struct {
> > > > >  > bool initialized;
> > > > >  > +
> > > > >  > struct mutex lock;
> > > > >  > struct list_head streams;
> > > > >  >
> > > > >  > +   spinlock_t hook_lock;
> > > > >  > +
> > > > >  > struct {
> > > > >  > -   u32 metrics_set;
> > > > >  > +   struct i915_perf_stream
> > > *exclusive_stream;
> >
> > OT:
> > What kind of MUA are you using that mangles quoted mails like this? I've
> > not seen it on intel-gfx before. mesa-dev seems rife with it, but as I
> > rarely read that in any great detail I've managed to ignore it there.
> > Anyways, it makes it espesially hard to navigate long mails since mutt's
> > 'S' (skip quoted text) no longer works correctly.
> >
> 
> Not sure I want to say, and get booted out the door :-)
> 
> I've heard that gmail has an annoying habit of forcibly wrapping plain text
> emails like this, and a lot of people have complained that there's no way
> to disable that 'feature' :-/
> 
> I used to use Mutt, but I don't think I could really bare to go back to it
> any more. Last time I was using it I found myself spending too much time
> patching it to try and make it work how I'd like, but can't say I got much
> enjoyment from that process.

Isn't gmail just a pile of client side javascript or something? Maybe
you'd enjoy patching that one more? ;)

> 
> I've tried most MUA options available, and can't say any of them make me
> very happy - I think these days it's just not something developers are very
> interesting in working on.
> 
> I'm a sell out and just use Gmail... sorry. I can't really see myself
> changing, though I do wish Google weren't so pedantic about forcing
> wrapping without any option to change that behaviour. I suspect you
> wouldn't be happy with me sending html emails, which has been Google's
> default response to this complaint afik.
> 
> Maybe it's gmail users causing trouble on the Mesa list too.
> 
> - Robert
> 
> P.S please don't think lesser of me due to my misguided MUA choices.

I think I'll just reserve the right to ignore any mail with bad quoting.

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Daniel Vetter]

On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote:
> On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
> 
> > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> > > On 26 Oct 2016 9:54 a.m., "Chris Wilson" 
> > wrote:
> > > >
> > > > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > > > >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > > > ><[1]matthew.william.a...@gmail.com> wrote:
> > > > >
> > > > >  On 25 October 2016 at 00:19, Robert Bragg <[2]
> > rob...@sixbynine.org>
> > > > >  wrote:
> > > > >
> > > > >
> > > > >
> > > > >  > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > >  b/drivers/gpu/drm/i915/i915_drv.h
> > > > >  > index 3448d05..ea24814 100644
> > > > >  > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > >  > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > >  > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > > > >
> > > > >  >
> > > > >  >  struct drm_i915_private {
> > > > >  > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > > > >  >
> > > > >  > struct {
> > > > >  > bool initialized;
> > > > >  > +
> > > > >  > struct mutex lock;
> > > > >  > struct list_head streams;
> > > > >  >
> > > > >  > +   spinlock_t hook_lock;
> > > > >  > +
> > > > >  > struct {
> > > > >  > -   u32 metrics_set;
> > > > >  > +   struct i915_perf_stream
> > > *exclusive_stream;
> >
> > OT:
> > What kind of MUA are you using that mangles quoted mails like this? I've
> > not seen it on intel-gfx before. mesa-dev seems rife with it, but as I
> > rarely read that in any great detail I've managed to ignore it there.
> > Anyways, it makes it espesially hard to navigate long mails since mutt's
> > 'S' (skip quoted text) no longer works correctly.
> >
> 
> Not sure I want to say, and get booted out the door :-)
> 
> I've heard that gmail has an annoying habit of forcibly wrapping plain text
> emails like this, and a lot of people have complained that there's no way
> to disable that 'feature' :-/
> 
> I used to use Mutt, but I don't think I could really bare to go back to it
> any more. Last time I was using it I found myself spending too much time
> patching it to try and make it work how I'd like, but can't say I got much
> enjoyment from that process.
> 
> I've tried most MUA options available, and can't say any of them make me
> very happy - I think these days it's just not something developers are very
> interesting in working on.
> 
> I'm a sell out and just use Gmail... sorry. I can't really see myself
> changing, though I do wish Google weren't so pedantic about forcing
> wrapping without any option to change that behaviour. I suspect you
> wouldn't be happy with me sending html emails, which has been Google's
> default response to this complaint afik.
> 
> Maybe it's gmail users causing trouble on the Mesa list too.
> 
> - Robert
> 
> P.S please don't think lesser of me due to my misguided MUA choices.

I use a mix of mutt+gmail web interface, since each has their upsides.
Haven't yet seen badly misquoted stuff, I think it mostly seems to work
for me. And there's lots of kernel folks who use gmail too afaik.
-Daniel

> 
> 
> 
> >
> > > > >  > +
> > > > >  > +   u32 specific_ctx_id;
> > > > >  Can we just get rid of this, now that the vma remains pinned we
> > can
> > > > >  simply get the ggtt address at the time of configuring the
> > > OA_CONTROL
> > > > >  register ?
> > > > >
> > > > >I considered that, but would ideally prefer to keep it considering
> > > the
> > > > >gen8+ patches to come. For gen8+ (with execlists) the context ID
> > > isn't a
> > > > >gtt offset.
> > > >
> > > > In terms of symmetry, keeping the vma you pinned and unpinning the same
> > > > later makes its ownership much clearer. (And I do want the owner of
> > each
> > > > pin to be clear, for when we start enabling debug to catch the VMA
> > > > leaks.)
> > >
> > > Keeping our own pointer to the pinned vma could be a clarification.
> > >
> > > Considering Matt's comments too, I'm thinking I'll put the pinning and
> > > specific_ctx_id initialization together with setting stream->ctx, keeping
> > > the state together under the stream. It's going to potentially mean
> > > redundantly pinning the ctx for the sake of the ID in the future for
> > > streams that don't really need it, but I think it's probably not worth
> > > worrying about that.
> > >
> > > - Robert
> > >
> > > > -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/vlv: Prevent enabling hpd polling in late suspend

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 12:36:09PM -0400, Lyude wrote:
> One of the CI machines began to run into issues with the hpd poller
> suddenly waking up in the midst of the late suspend phase. It looks like
> this is getting caused by the fact we now deinitialize power wells in
> late suspend, which means that intel_hpd_poll_init() gets called in late
> suspend causing polling to get re-enabled. So, when deinitializing power
> wells on valleyview we now refrain from enabling polling in the midst of
> suspend.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
> Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd")
> Signed-off-by: Lyude 
> Cc: Ville Syrjälä 
> Cc: Jani Saarinen 
> Cc: Petry Latvala 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 82edba2..ac85482 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1138,7 +1138,9 @@ static void vlv_display_power_well_deinit(struct 
> drm_i915_private *dev_priv)
>  
>   intel_power_sequencer_reset(dev_priv);
>  
> - intel_hpd_poll_init(dev_priv);
> + /* Prevent us from re-enabling polling on accident in late suspend */
> + if (!dev_priv->drm.dev->power.is_suspended)
> + intel_hpd_poll_init(dev_priv);

The flag would appear to get set between suspend and suspend_late, so
looks like this should be sufficient for our purposes.

Reviewed-by: Ville Syrjälä 

>  }
>  
>  static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
> -- 
> 2.7.4

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

[Intel-gfx] [PATCH i-g-t] lib: use the local intel_aub.h file

[Emil Velikov]

From: Emil Velikov 

File is provided by the libdrm_intel package which is optional. Since we
already have a local copy of the file, we might as well use it ;-)

Cc: Brian Starkey 
Reported-by: Brian Starkey 
Signed-off-by: Emil Velikov 
---
An alternative would be to $ git mv tools/intel_aub.h lib/stubs/drm/ and
drop the intel_aub.h reference from tools/Makefile.am.
---
 lib/rendercopy_gen8.c | 2 +-
 lib/rendercopy_gen9.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index a7fc2c4..3c4a040 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -22,7 +22,7 @@
 #include "intel_reg.h"
 #include "igt_aux.h"
 
-#include 
+#include "tools/intel_aub.h"
 
 #define VERTEX_SIZE (3*4)
 
diff --git a/lib/rendercopy_gen9.c b/lib/rendercopy_gen9.c
index 9537480..4fef584 100644
--- a/lib/rendercopy_gen9.c
+++ b/lib/rendercopy_gen9.c
@@ -23,7 +23,7 @@
 #include "intel_reg.h"
 #include "igt_aux.h"
 
-#include 
+#include "tools/intel_aub.h"
 
 #define VERTEX_SIZE (3*4)
 
-- 
2.9.3

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

[Intel-gfx] ✓ Fi.CI.BAT: success for MAINTAINERS: drop dri-devel list for i915

[Patchwork]

== Series Details ==

Series: MAINTAINERS: drop dri-devel list for i915
URL   : https://patchwork.freedesktop.org/series/14418/
State : success

== Summary ==

Series 14418v1 MAINTAINERS: drop dri-devel list for i915
https://patchwork.freedesktop.org/api/1.0/series/14418/revisions/1/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

fe116755dd4cf23c17c8ad50227ca4376480d015 drm-intel-nightly: 
2016y-10m-26d-14h-34m-03s UTC integration manifest
48e8b2c MAINTAINERS: drop dri-devel list for i915

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2826/

== Logs ==

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:

> On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> > On 26 Oct 2016 9:54 a.m., "Chris Wilson" 
> wrote:
> > >
> > > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > > >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > > ><[1]matthew.william.a...@gmail.com> wrote:
> > > >
> > > >  On 25 October 2016 at 00:19, Robert Bragg <[2]
> rob...@sixbynine.org>
> > > >  wrote:
> > > >
> > > >
> > > >
> > > >  > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > >  b/drivers/gpu/drm/i915/i915_drv.h
> > > >  > index 3448d05..ea24814 100644
> > > >  > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > >  > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > >  > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > > >
> > > >  >
> > > >  >  struct drm_i915_private {
> > > >  > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > > >  >
> > > >  > struct {
> > > >  > bool initialized;
> > > >  > +
> > > >  > struct mutex lock;
> > > >  > struct list_head streams;
> > > >  >
> > > >  > +   spinlock_t hook_lock;
> > > >  > +
> > > >  > struct {
> > > >  > -   u32 metrics_set;
> > > >  > +   struct i915_perf_stream
> > *exclusive_stream;
>
> OT:
> What kind of MUA are you using that mangles quoted mails like this? I've
> not seen it on intel-gfx before. mesa-dev seems rife with it, but as I
> rarely read that in any great detail I've managed to ignore it there.
> Anyways, it makes it espesially hard to navigate long mails since mutt's
> 'S' (skip quoted text) no longer works correctly.
>

Not sure I want to say, and get booted out the door :-)

I've heard that gmail has an annoying habit of forcibly wrapping plain text
emails like this, and a lot of people have complained that there's no way
to disable that 'feature' :-/

I used to use Mutt, but I don't think I could really bare to go back to it
any more. Last time I was using it I found myself spending too much time
patching it to try and make it work how I'd like, but can't say I got much
enjoyment from that process.

I've tried most MUA options available, and can't say any of them make me
very happy - I think these days it's just not something developers are very
interesting in working on.

I'm a sell out and just use Gmail... sorry. I can't really see myself
changing, though I do wish Google weren't so pedantic about forcing
wrapping without any option to change that behaviour. I suspect you
wouldn't be happy with me sending html emails, which has been Google's
default response to this complaint afik.

Maybe it's gmail users causing trouble on the Mesa list too.

- Robert

P.S please don't think lesser of me due to my misguided MUA choices.



>
> > > >  > +
> > > >  > +   u32 specific_ctx_id;
> > > >  Can we just get rid of this, now that the vma remains pinned we
> can
> > > >  simply get the ggtt address at the time of configuring the
> > OA_CONTROL
> > > >  register ?
> > > >
> > > >I considered that, but would ideally prefer to keep it considering
> > the
> > > >gen8+ patches to come. For gen8+ (with execlists) the context ID
> > isn't a
> > > >gtt offset.
> > >
> > > In terms of symmetry, keeping the vma you pinned and unpinning the same
> > > later makes its ownership much clearer. (And I do want the owner of
> each
> > > pin to be clear, for when we start enabling debug to catch the VMA
> > > leaks.)
> >
> > Keeping our own pointer to the pinned vma could be a clarification.
> >
> > Considering Matt's comments too, I'm thinking I'll put the pinning and
> > specific_ctx_id initialization together with setting stream->ctx, keeping
> > the state together under the stream. It's going to potentially mean
> > redundantly pinning the ctx for the sake of the ID in the future for
> > streams that don't really need it, but I think it's probably not worth
> > worrying about that.
> >
> > - Robert
> >
> > > -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
>
>
> --
> Ville Syrjälä
> Intel OTC
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] igt_fb: Add Y-tiling support

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 11:20:51AM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 09:09:26AM +0100, Tvrtko Ursulin wrote:
> > 
> > On 26/10/2016 07:32, Daniel Vetter wrote:
> > > On Tue, Oct 25, 2016 at 03:02:33PM +, Paneri, Praveen wrote:
> > >>> So when you say that all Y tiling tests fail without this kernel hack, 
> > >>> which tests you are referring to?
> > >> If I revert this IGT patch and do not make below kernel change, 
> > >> kms_draw_crc (ytiled cases, last patch in this series) fail with 
> > >> following error.
> > >>
> > >> Test assertion failure function igt_assert_crc_equal, file 
> > >> hardware/intel/intel-gpu-tools/lib/igt_debugfs.c:266:
> > >> Failed assertion: a->crc[i] == b->crc[i]
> > >> error: 0x68c96b8b != 0x948e53b
> > >>
> > >> I think, I shall debug it further and try to fix it without making this 
> > >> change.
> > >
> > > Can't we just set the fb modifiers when creating the drm_fb in the igt
> > > helpers?
> > 
> > Thats already there, if I understand what you mean. But it only does the 
> > modifer and does not set the object tiling. So I suspect this test might 
> > be depending on object tiling being set as well? In which case we  may 
> > be missing the capability to create the object separately from the fb 
> > creation, because otherwise it is too late to try to change the object 
> > tiling.
> 
> I'm pretty sure I had patches to split the two apart. Assuming I never
> posted them, they must be on a branch... somewhere.

Failed to find them. So someone will have to reimplement if needed.

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

[Intel-gfx] [PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

[Lyude]

One of the CI machines began to run into issues with the hpd poller
suddenly waking up in the midst of the late suspend phase. It looks like
this is getting caused by the fact we now deinitialize power wells in
late suspend, which means that intel_hpd_poll_init() gets called in late
suspend causing polling to get re-enabled. So, when deinitializing power
wells on valleyview we now refrain from enabling polling in the midst of
suspend.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd")
Signed-off-by: Lyude 
Cc: Ville Syrjälä 
Cc: Jani Saarinen 
Cc: Petry Latvala 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 82edba2..ac85482 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1138,7 +1138,9 @@ static void vlv_display_power_well_deinit(struct 
drm_i915_private *dev_priv)
 
intel_power_sequencer_reset(dev_priv);
 
-   intel_hpd_poll_init(dev_priv);
+   /* Prevent us from re-enabling polling on accident in late suspend */
+   if (!dev_priv->drm.dev->power.is_suspended)
+   intel_hpd_poll_init(dev_priv);
 }
 
 static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
-- 
2.7.4

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

[Intel-gfx] [PATCH v2] drm: Print some debug/error info during DP dual mode detect

[Imre Deak]

There's at least one LSPCON device that occasionally returns an unexpected
adaptor ID which leads to a failed detect. Print some debug info to help
debugging this and future cases. Also print an error for an unexpected
adaptor ID, so users can report it.

v2:
- s/adapter/adaptor/ and add code comment about incorrect type 1 adaptor
  IDs. (Ville)

Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 488355b..e025639 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -142,6 +142,11 @@ static bool is_hdmi_adaptor(const char 
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN])
  sizeof(dp_dual_mode_hdmi_id)) == 0;
 }
 
+static bool is_type1_adaptor(uint8_t adaptor_id)
+{
+   return adaptor_id == 0 || adaptor_id == 0xff;
+}
+
 static bool is_type2_adaptor(uint8_t adaptor_id)
 {
return adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
@@ -193,6 +198,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
 */
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_HDMI_ID,
hdmi_id, sizeof(hdmi_id));
+   DRM_DEBUG_KMS("DP dual mode HDMI ID: %*pE (err %zd)\n",
+ ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
if (ret)
return DRM_DP_DUAL_MODE_UNKNOWN;
 
@@ -210,6 +217,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
 */
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
_id, sizeof(adaptor_id));
+   DRM_DEBUG_KMS("DP dual mode adaptor ID: %02x (err %zd)\n",
+ adaptor_id, ret);
if (ret == 0) {
if (is_lspcon_adaptor(hdmi_id, adaptor_id))
return DRM_DP_DUAL_MODE_LSPCON;
@@ -219,6 +228,15 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
else
return DRM_DP_DUAL_MODE_TYPE2_DVI;
}
+   /*
+* If neither a proper type 1 ID nor a broken type 1 adaptor
+* as described above, assume type 1, but let the user know
+* that we may have misdetected the type.
+*/
+   if (!is_type1_adaptor(adaptor_id) && adaptor_id != hdmi_id[0])
+   DRM_ERROR("Unexpected DP dual mode adaptor ID %02x\n",
+ adaptor_id);
+
}
 
if (is_hdmi_adaptor(hdmi_id))
-- 
2.5.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 v2] configure.ac: correctly manage DRM_INTEL_{CFLAGS, LIBS}

[Robert Foss]

Thanks Emil!
This looks good to me.

Signed-off-by: Robert Foss 

On 2016-10-26 12:18 PM, Emil Velikov wrote:

From: Emil Velikov 

Currently the latter is only set when using --enable-intel.

Whereas for the CFLAGS: if we "enable" PKG_CHECK_MODULES sets the
variable, while for "disable" we do it locally. In either case the
CFLAGS is not propagated through, this one can get build issues
regardless of the actual state of the toggle.

v2: Add -I for the include directive and correctly propagate
$(top_srcdir).

Cc: Brian Starkey 
Cc: Robert Foss 
Reported-by: Brian Starkey 
Signed-off-by: Emil Velikov 
---
This time fully tested:
 - enable/disable/auto with and w/o libdrm_intel :-)

Did not see much point in splitting the v2 only changes to 1/2 and keep
this as 2/2. I don't mind either way though :-)
---
 configure.ac | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 735cfd5..e181c83 100644
--- a/configure.ac
+++ b/configure.ac
@@ -178,12 +178,15 @@ fi
 if test "x$INTEL" = xyes; then
PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])
AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel support])
-   DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
-   AC_SUBST([DRM_LIBS])
 else
-   DRM_INTEL_CFLAGS=$(top_srcdir)/lib/stubs/drm/
-   AC_SUBST([DRM_INTEL_CFLAGS])
+   DRM_INTEL_CFLAGS=-I$\(top_srcdir\)/lib/stubs/drm/
+   DRM_INTEL_LIBS=
 fi
+DRM_CFLAGS="$DRM_CFLAGS $DRM_INTEL_CFLAGS"
+DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
+AC_SUBST([DRM_CFLAGS])
+AC_SUBST([DRM_LIBS])
+
 AM_CONDITIONAL(HAVE_LIBDRM_INTEL, [test "x$INTEL" = xyes])

 # for dma-buf tests


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

Re: [Intel-gfx] [PATCH v2 07/11] drm/i915: Add a atomic evasion step to watermark programming, v2.

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 03:41:35PM +0200, Maarten Lankhorst wrote:
> Allow the driver to write watermarks during atomic evasion.
> This will make it possible to write the watermarks in a cleaner
> way on gen9+.
> 
> intel_atomic_state is not used here yet, but will be used when
> we program all watermarks as a separate step during evasion.
> 
> This also writes linetime all the time, while before it was only
> done during plane updates. This looks like this could be a bugfix,
> but I'm not sure what it affects.
> 
> Changes since v1:
> - Add comment about atomic evasion to commit message.
> - Unwrap I915_WRITE call. (Lyude)
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Matt Roper 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  6 --
>  drivers/gpu/drm/i915/intel_display.c | 20 +---
>  drivers/gpu/drm/i915/intel_pm.c  | 18 --
>  3 files changed, 29 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7a621c74254e..7a477d6a486e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -485,6 +485,7 @@ struct sdvo_device_mapping {
>  
>  struct intel_connector;
>  struct intel_encoder;
> +struct intel_atomic_state;
>  struct intel_crtc_state;
>  struct intel_initial_plane_config;
>  struct intel_crtc;
> @@ -498,8 +499,9 @@ struct drm_i915_display_funcs {
>   int (*compute_intermediate_wm)(struct drm_device *dev,
>  struct intel_crtc *intel_crtc,
>  struct intel_crtc_state *newstate);
> - void (*initial_watermarks)(struct intel_crtc_state *cstate);
> - void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> + void (*initial_watermarks)(struct intel_atomic_state *state, struct 
> intel_crtc_state *cstate);
> + void (*atomic_evade_watermarks)(struct intel_atomic_state *state, 
> struct intel_crtc_state *cstate);

Same drive by comment I gave before somewhere:
That name is still super confusing. We're not trying to evade watermarks are we?

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

[Intel-gfx] [PATCH i-g-t v2] configure.ac: correctly manage DRM_INTEL_{CFLAGS, LIBS}

[Emil Velikov]

From: Emil Velikov 

Currently the latter is only set when using --enable-intel.

Whereas for the CFLAGS: if we "enable" PKG_CHECK_MODULES sets the
variable, while for "disable" we do it locally. In either case the
CFLAGS is not propagated through, this one can get build issues
regardless of the actual state of the toggle.

v2: Add -I for the include directive and correctly propagate
$(top_srcdir).

Cc: Brian Starkey 
Cc: Robert Foss 
Reported-by: Brian Starkey 
Signed-off-by: Emil Velikov 
---
This time fully tested:
 - enable/disable/auto with and w/o libdrm_intel :-)

Did not see much point in splitting the v2 only changes to 1/2 and keep
this as 2/2. I don't mind either way though :-)
---
 configure.ac | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 735cfd5..e181c83 100644
--- a/configure.ac
+++ b/configure.ac
@@ -178,12 +178,15 @@ fi
 if test "x$INTEL" = xyes; then
PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])
AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel support])
-   DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
-   AC_SUBST([DRM_LIBS])
 else
-   DRM_INTEL_CFLAGS=$(top_srcdir)/lib/stubs/drm/
-   AC_SUBST([DRM_INTEL_CFLAGS])
+   DRM_INTEL_CFLAGS=-I$\(top_srcdir\)/lib/stubs/drm/
+   DRM_INTEL_LIBS=
 fi
+DRM_CFLAGS="$DRM_CFLAGS $DRM_INTEL_CFLAGS"
+DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
+AC_SUBST([DRM_CFLAGS])
+AC_SUBST([DRM_LIBS])
+
 AM_CONDITIONAL(HAVE_LIBDRM_INTEL, [test "x$INTEL" = xyes])
 
 # for dma-buf tests
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915/DMC/KBL: Load DMC on KBL using the no_stepping_info array

[Vivi, Rodrigo]

On Wed, 2016-10-26 at 15:32 +0300, Imre Deak wrote:
> On ti, 2016-10-25 at 18:00 +, Vivi, Rodrigo wrote:
> > Reviewed-by: Rodrigo Vivi 
> > 
> > On Mon, 2016-10-24 at 17:28 -0700, Anusha Srivatsa wrote:
> > > Currently, for display there is only one DMC image for KBL.
> > > Remove the stepping_info table for KBL and use the no_stepping_info
> > > array for loading the firmware.
> > > 
> > > v2: Removed the block of code as pointed out by Rodrigo to make the
> > > loads as generic as possible.
> > > 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Anusha Srivatsa 
> 
> I assume the goal is to simplify the code. kbl_dmc_ver1_01.bin has
> indeed only a single *,* entry and I assume it was confirmed that there
> is no plan to release KBL firmware images in the future with multiple
> stepping entries. With that this looks ok:

That is the case.

> Acked-by: Imre Deak 

Thanks.

> 
> I think it would be good to also emit a warn from the driver if we use
> no_stepping_info and there are stepping entries in the firmware image
> other than *,* since then we may end up loading the wrong firmware
> version.

yeap, this seems a good idea. a conservative approach.
although, along with the confirmation we got the promise
that this kind of information would be now on in the official
release notes we receive along with the binary images.


> 
> > > ---
> > >  drivers/gpu/drm/i915/intel_csr.c | 11 +--
> > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > > b/drivers/gpu/drm/i915/intel_csr.c
> > > index 1ea0e1f..d7a04bc 100644
> > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > @@ -168,12 +168,6 @@ struct stepping_info {
> > >   char substepping;
> > >  };
> > >  
> > > -static const struct stepping_info kbl_stepping_info[] = {
> > > - {'A', '0'}, {'B', '0'}, {'C', '0'},
> > > - {'D', '0'}, {'E', '0'}, {'F', '0'},
> > > - {'G', '0'}, {'H', '0'}, {'I', '0'},
> > > -};
> > > -
> > >  static const struct stepping_info skl_stepping_info[] = {
> > >   {'A', '0'}, {'B', '0'}, {'C', '0'},
> > >   {'D', '0'}, {'E', '0'}, {'F', '0'},
> > > @@ -194,10 +188,7 @@ intel_get_stepping_info(struct
> > > drm_i915_private *dev_priv)
> > >   const struct stepping_info *si;
> > >   unsigned int size;
> > >  
> > > - if (IS_KABYLAKE(dev_priv)) {
> > > - size = ARRAY_SIZE(kbl_stepping_info);
> > > - si = kbl_stepping_info;
> > > - } else if (IS_SKYLAKE(dev_priv)) {
> > > + if (IS_SKYLAKE(dev_priv)) {
> > >   size = ARRAY_SIZE(skl_stepping_info);
> > >   si = skl_stepping_info;
> > >   } else if (IS_BROXTON(dev_priv)) {
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH] MAINTAINERS: drop dri-devel list for i915

[Jani Nikula]

In practice, none of the i915 developers Cc dri-devel for strictly i915
specific patches. Make MAINTAINERS reflect reality, and reduce random
i915 specific noise on dri-devel.

Also, we have a fairly large crowd reading and responding on intel-gfx,
and we're pretty good at involving dri-devel when that is appropriate.

Cc: dri-de...@lists.freedesktop.org
Acked-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e60e0a188229..f3547144e743 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4054,7 +4054,6 @@ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and 
derivative chipsets)
 M: Daniel Vetter 
 M: Jani Nikula 
 L: intel-gfx@lists.freedesktop.org
-L: dri-de...@lists.freedesktop.org
 W: https://01.org/linuxgraphics/
 Q: http://patchwork.freedesktop.org/project/intel-gfx/
 T: git git://anongit.freedesktop.org/drm-intel
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH v2 09/11] drm/i915/gen9+: Program watermarks as a separate step during evasion, v2.

[Lyude Paul]

This approach is perfect :).

Reviewed-by: Lyude 

On Wed, 2016-10-26 at 15:41 +0200, Maarten Lankhorst wrote:
> The watermark updates for SKL style watermarks are no longer done
> in the plane callbacks, but are now called in a separate watermark
> update function that's called during the same vblank evasion,
> before the plane updates.
> 
> This also gets rid of the global skl_results, which was required for
> keeping track of the current atomic commit.
> 
> Changes since v1:
> - Move line unwrap to correct patch. (Lyude)
> - Make sure we don't regress ILK watermarks. (Matt)
> - Rephrase commit message. (Matt)
> 
> Cc: Matt Roper 
> Cc: Lyude 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  7 ---
>  drivers/gpu/drm/i915/intel_display.c | 40 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  7 ---
>  drivers/gpu/drm/i915/intel_pm.c  | 35 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c  | 18 
>  5 files changed, 31 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 7a477d6a486e..227993f0e3ff 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2038,13 +2038,6 @@ struct drm_i915_private {
>    */
>   uint16_t skl_latency[8];
>  
> - /*
> -  * The skl_wm_values structure is a bit too big for
> stack
> -  * allocation, so we keep the staging struct where
> we store
> -  * intermediate results here instead.
> -  */
> - struct skl_wm_values skl_results;
> -
>   /* current hardware state */
>   union {
>   struct ilk_wm_values hw;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 592a6ec354a7..e80ecf85768a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3384,9 +3384,6 @@ static void skylake_update_primary_plane(struct
> drm_plane *plane,
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> >base.crtc);
>   struct drm_framebuffer *fb = plane_state->base.fb;
> - const struct skl_wm_values *wm = _priv->wm.skl_results;
> - const struct skl_plane_wm *p_wm =
> - _state->wm.skl.optimal.planes[0];
>   int pipe = intel_crtc->pipe;
>   u32 plane_ctl;
>   unsigned int rotation = plane_state->base.rotation;
> @@ -3422,9 +3419,6 @@ static void skylake_update_primary_plane(struct
> drm_plane *plane,
>   intel_crtc->adjusted_x = src_x;
>   intel_crtc->adjusted_y = src_y;
>  
> - if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
> - skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
> -
>   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
>   I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
>   I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
> @@ -3457,18 +3451,8 @@ static void
> skylake_disable_primary_plane(struct drm_plane *primary,
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct intel_crtc_state *cstate = to_intel_crtc_state(crtc-
> >state);
> - const struct skl_plane_wm *p_wm = 
> >wm.skl.optimal.planes[0];
>   int pipe = intel_crtc->pipe;
>  
> - /*
> -  * We only populate skl_results on watermark updates, and if
> the
> -  * plane's visiblity isn't actually changing neither is its
> watermarks.
> -  */
> - if (!crtc->primary->state->visible)
> - skl_write_plane_wm(intel_crtc, p_wm,
> -    _priv->wm.skl_results.ddb,
> 0);
> -
>   I915_WRITE(PLANE_CTL(pipe, 0), 0);
>   I915_WRITE(PLANE_SURF(pipe, 0), 0);
>   POSTING_READ(PLANE_SURF(pipe, 0));
> @@ -10840,16 +10824,9 @@ static void i9xx_update_cursor(struct
> drm_crtc *crtc, u32 base,
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct intel_crtc_state *cstate = to_intel_crtc_state(crtc-
> >state);
> - const struct skl_wm_values *wm = _priv->wm.skl_results;
> - const struct skl_plane_wm *p_wm =
> - >wm.skl.optimal.planes[PLANE_CURSOR];
>   int pipe = intel_crtc->pipe;
>   uint32_t cntl = 0;
>  
> - if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes &
> drm_crtc_mask(crtc))
> - skl_write_cursor_wm(intel_crtc, p_wm, >ddb);
> -
>   if (plane_state && plane_state->base.visible) {
>   cntl = MCURSOR_GAMMA_ENABLE;
>   switch (plane_state->base.crtc_w) {
> @@ -14459,8 

[Intel-gfx] [PATCH igt 3/3] igt/gem_exec_parse: update for version 8 changes

[Robert Bragg]

This adapts the tests to account for the parser no longer reporting
privilege violations back to userspace as EINVAL errors (they are left
to the HW command parser to squash the commands to NOOPS).

The interface change isn't expected to affect userspace and in fact it
looks like the previous behaviour was liable to break userspace, such as
Mesa which explicitly tries to observe whether OACONTROL LRIs are
squashed to NOOPs but Mesa will abort for execbuffer errors.

Signed-off-by: Robert Bragg 
---
 tests/gem_exec_parse.c | 368 +++--
 1 file changed, 200 insertions(+), 168 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 36bf57d..4290701 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -34,7 +34,24 @@
 #define I915_PARAM_CMD_PARSER_VERSION   28
 #endif
 
+#define ARRAY_LEN(A) (sizeof(A) / sizeof(A[0]))
+
+#define OACONTROL 0x2360
 #define DERRMR 0x44050
+#define SO_WRITE_OFFSET_0 0x5280
+#define HSW_CS_GPR(n) (0x2600 + 8*(n))
+#define HSW_CS_GPR0 HSW_CS_GPR(0)
+#define HSW_CS_GPR1 HSW_CS_GPR(1)
+
+#define MI_LOAD_REGISTER_REG (0x2a << 23)
+#define MI_STORE_REGISTER_MEM (0x24 << 23)
+#define MI_ARB_ON_OFF (0x8 << 23)
+#define MI_DISPLAY_FLIP ((0x14 << 23) | 1)
+
+#define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)|2)
+#define   PIPE_CONTROL_QW_WRITE(1<<14)
+#define   PIPE_CONTROL_LRI_POST_OP (1<<23)
+
 
 static int command_parser_version(int fd)
 {
@@ -50,101 +67,8 @@ static int command_parser_version(int fd)
return -1;
 }
 
-#define HSW_CS_GPR(n) (0x2600 + 8*(n))
-#define HSW_CS_GPR0 HSW_CS_GPR(0)
-#define HSW_CS_GPR1 HSW_CS_GPR(1)
-
-#define MI_LOAD_REGISTER_REG (0x2a << 23)
-#define MI_STORE_REGISTER_MEM (0x24 << 23)
-static void hsw_load_register_reg(void)
-{
-   uint32_t buf[16] = {
-   MI_LOAD_REGISTER_IMM | (5 - 2),
-   HSW_CS_GPR0,
-   0xabcdabcd,
-   HSW_CS_GPR1,
-   0xdeadbeef,
-
-   MI_STORE_REGISTER_MEM | (3 - 2),
-   HSW_CS_GPR1,
-   0, /* address0 */
-
-   MI_LOAD_REGISTER_REG | (3 - 2),
-   HSW_CS_GPR0,
-   HSW_CS_GPR1,
-
-   MI_STORE_REGISTER_MEM | (3 - 2),
-   HSW_CS_GPR1,
-   4, /* address1 */
-
-   MI_BATCH_BUFFER_END,
-   };
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 obj[2];
-   struct drm_i915_gem_relocation_entry reloc[2];
-   int fd;
-
-   /* Open again to get a non-master file descriptor */
-   fd = drm_open_driver(DRIVER_INTEL);
-
-   igt_require(IS_HASWELL(intel_get_drm_devid(fd)));
-   igt_require(command_parser_version(fd) >= 7);
-
-   memset(obj, 0, sizeof(obj));
-   obj[0].handle = gem_create(fd, 4096);
-   obj[1].handle = gem_create(fd, 4096);
-   gem_write(fd, obj[1].handle, 0, buf, sizeof(buf));
-
-   memset(reloc, 0, sizeof(reloc));
-   reloc[0].offset = 7*sizeof(uint32_t);
-   reloc[0].target_handle = obj[0].handle;
-   reloc[0].delta = 0;
-   reloc[0].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-   reloc[0].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
-   reloc[1].offset = 13*sizeof(uint32_t);
-   reloc[1].target_handle = obj[0].handle;
-   reloc[1].delta = sizeof(uint32_t);
-   reloc[1].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-   reloc[1].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
-   obj[1].relocs_ptr = (uintptr_t)
-   obj[1].relocation_count = 2;
-
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = (uintptr_t)obj;
-   execbuf.buffer_count = 2;
-   execbuf.batch_len = sizeof(buf);
-   execbuf.flags = I915_EXEC_RENDER;
-   gem_execbuf(fd, );
-   gem_close(fd, obj[1].handle);
-
-   gem_read(fd, obj[0].handle, 0, buf, 2*sizeof(buf[0]));
-   igt_assert_eq_u32(buf[0], 0xdeadbeef); /* before copy */
-   igt_assert_eq_u32(buf[1], 0xabcdabcd); /* after copy */
-
-   /* Now a couple of negative tests that should be filtered */
-   execbuf.buffer_count = 1;
-   execbuf.batch_len = 4*sizeof(buf[0]);
-
-   buf[0] = MI_LOAD_REGISTER_REG | (3 - 2);
-   buf[1] = HSW_CS_GPR0;
-   buf[2] = 0;
-   buf[3] = MI_BATCH_BUFFER_END;
-   gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
-   igt_assert_eq(__gem_execbuf(fd, ), -EINVAL);
-
-   buf[2] = DERRMR; /* master only */
-   gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
-   igt_assert_eq(__gem_execbuf(fd, ), -EINVAL);
-
-   buf[2] = 0x2038; /* RING_START: invalid */
-   gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
-   igt_assert_eq(__gem_execbuf(fd, ), -EINVAL);
-
-   close(fd);
-}
-
-static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
-  int size, int patch_offset, uint64_t 

[Intel-gfx] [PATCH igt 1/3] igt/perf: add i915 perf stream tests for Haswell

[Robert Bragg]

Signed-off-by: Robert Bragg 
---
 tests/Makefile.sources |1 +
 tests/perf.c   | 2173 
 2 files changed, 2174 insertions(+)
 create mode 100644 tests/perf.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..7c6de2f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -211,6 +211,7 @@ TESTS_progs = \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
+   perf \
$(NULL)
 
 # IMPORTANT: The ZZ_ tests need to be run last!
diff --git a/tests/perf.c b/tests/perf.c
new file mode 100644
index 000..f050e31
--- /dev/null
+++ b/tests/perf.c
@@ -0,0 +1,2173 @@
+/*
+ * Copyright © 2016 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "drm.h"
+
+IGT_TEST_DESCRIPTION("Test the i915 perf metrics streaming interface");
+
+#define GEN6_MI_REPORT_PERF_COUNT ((0x28 << 23) | (3 - 2))
+
+#define GFX_OP_PIPE_CONTROL ((3 << 29) | (3 << 27) | (2 << 24))
+#define PIPE_CONTROL_CS_STALL   (1 << 20)
+#define PIPE_CONTROL_GLOBAL_SNAPSHOT_COUNT_RESET(1 << 19)
+#define PIPE_CONTROL_TLB_INVALIDATE (1 << 18)
+#define PIPE_CONTROL_SYNC_GFDT  (1 << 17)
+#define PIPE_CONTROL_MEDIA_STATE_CLEAR  (1 << 16)
+#define PIPE_CONTROL_NO_WRITE   (0 << 14)
+#define PIPE_CONTROL_WRITE_IMMEDIATE(1 << 14)
+#define PIPE_CONTROL_WRITE_DEPTH_COUNT  (2 << 14)
+#define PIPE_CONTROL_WRITE_TIMESTAMP(3 << 14)
+#define PIPE_CONTROL_DEPTH_STALL(1 << 13)
+#define PIPE_CONTROL_RENDER_TARGET_FLUSH (1 << 12)
+#define PIPE_CONTROL_INSTRUCTION_INVALIDATE (1 << 11)
+#define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE   (1 << 10) /* GM45+ only */
+#define PIPE_CONTROL_ISP_DIS(1 << 9)
+#define PIPE_CONTROL_INTERRUPT_ENABLE   (1 << 8)
+#define PIPE_CONTROL_FLUSH_ENABLE   (1 << 7) /* Gen7+ only */
+/* GT */
+#define PIPE_CONTROL_DATA_CACHE_INVALIDATE  (1 << 5)
+#define PIPE_CONTROL_VF_CACHE_INVALIDATE(1 << 4)
+#define PIPE_CONTROL_CONST_CACHE_INVALIDATE (1 << 3)
+#define PIPE_CONTROL_STATE_CACHE_INVALIDATE (1 << 2)
+#define PIPE_CONTROL_STALL_AT_SCOREBOARD(1 << 1)
+#define PIPE_CONTROL_DEPTH_CACHE_FLUSH  (1 << 0)
+#define PIPE_CONTROL_PPGTT_WRITE(0 << 2)
+#define PIPE_CONTROL_GLOBAL_GTT_WRITE   (1 << 2)
+
+static struct {
+const char *name;
+uint64_t id;
+size_t size;
+int a_off; /* bytes */
+int n_a;
+int first_a;
+int b_off;
+int n_b;
+int c_off;
+int n_c;
+} hsw_oa_formats[] = {
+{ "A13", I915_OA_FORMAT_A13, .size = 64,
+.a_off = 12, .n_a = 13 },
+{ "A29", I915_OA_FORMAT_A29, .size = 128,
+.a_off = 12, .n_a = 29 },
+{ "A13_B8_C8", I915_OA_FORMAT_A13_B8_C8, .size = 128,
+.a_off = 12, .n_a = 13,
+.b_off = 64, .n_b = 8,
+.c_off = 96, .n_c = 8 },
+{ "A45_B8_C8", I915_OA_FORMAT_A45_B8_C8, .size = 256,
+.a_off = 12,  .n_a = 45,
+.b_off = 192, .n_b = 8,
+.c_off = 224, .n_c = 8 },
+{ "B4_C8", I915_OA_FORMAT_B4_C8, .size = 64,
+.b_off = 16, .n_b = 4,
+.c_off = 32, .n_c = 8 },
+{ "B4_C8_A16", I915_OA_FORMAT_B4_C8_A16, .size = 128,
+.b_off = 16, .n_b = 4,
+.c_off = 32, .n_c = 8,
+.a_off = 60, .n_a = 16, .first_a = 29 },
+{ "C4_B8", I915_OA_FORMAT_C4_B8, .size = 64,
+.c_off = 16, .n_c = 4,
+.b_off = 28, .n_b = 8 },
+};
+
+static bool hsw_undefined_a_counters[45] = {
+[4] = 

[Intel-gfx] [PATCH igt 0/3] corresponding changes for i915-perf interface

[Robert Bragg]

The i915-perf series affects the command parser and itself includes new uapi
which these i-g-t changes try to cover.

- Robert

Robert Bragg (3):
  igt/perf: add i915 perf stream tests for Haswell
  igt/gem_exec_parse: remove oacontrol checks
  igt/gem_exec_parse: update for version 8 changes

 tests/Makefile.sources |1 +
 tests/gem_exec_parse.c |  436 +-
 tests/perf.c   | 2173 
 3 files changed, 2364 insertions(+), 246 deletions(-)
 create mode 100644 tests/perf.c

-- 
2.10.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Print some debug/error info during DP dual mode detect

[Patchwork]

== Series Details ==

Series: drm: Print some debug/error info during DP dual mode detect
URL   : https://patchwork.freedesktop.org/series/14412/
State : failure

== Summary ==

Series 14412v1 drm: Print some debug/error info during DP dual mode detect
https://patchwork.freedesktop.org/api/1.0/series/14412/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-skl-6260u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:210  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

fe116755dd4cf23c17c8ad50227ca4376480d015 drm-intel-nightly: 
2016y-10m-26d-14h-34m-03s UTC integration manifest
5cff751 drm: Print some debug/error info during DP dual mode detect

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2825/

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/lspcon: Work around resume failure (rev2)

[Imre Deak]

On Tue, 2016-10-25 at 14:46 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/lspcon: Work around resume failure (rev2)
> URL   : https://patchwork.freedesktop.org/series/14280/
> State : warning
> 
> == Summary ==
> 
> Series 14280v2 drm/i915/lspcon: Work around resume failure
> https://patchwork.freedesktop.org/api/1.0/series/14280/revisions/2/mb
> ox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> pass   -> DMESG-WARN (fi-skl-6700hq)

This is due to the bug's persistence over warm reboot. Since I pushed
this w/a there's been two DRM_CI runs without these errors on this
machine (whereas before either this or one of the S3 tests always
failed).

> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> SKIP   (fi-byt-n2820)
> Test kms_frontbuffer_tracking:
> Subgroup basic:
> fail   -> PASS   (fi-skl-6770hq)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-skl-6770hq)

*ERROR* failed to inform PCU about cdclk change
https://bugs.freedesktop.org/show_bug.cgi?id=97929

Thanks for the review, I pushed the patchset to -dinq.

> dmesg-warn -> PASS   (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> 
> fi-bdw-
> 5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-
> n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
> fi-bxt-
> t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
> fi-byt-
> j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
> fi-byt-
> n2820 total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
> fi-hsw-
> 4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
> fi-hsw-
> 4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
> fi-ilk-
> 650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
> fi-ivb-
> 3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
> fi-ivb-
> 3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
> fi-kbl-
> 7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
> fi-skl-
> 6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-
> 6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
> fi-skl-
> 6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
> fi-skl-
> 6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14 
> fi-snb-
> 2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
> fi-snb-
> 2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 
> 
> 3ce99d02d8f2b7d1414d20d5972f8e277b33693e drm-intel-nightly: 2016y-
> 10m-25d-13h-55m-46s UTC integration manifest
> ab50b11 drm/i915/lspcon: Add workaround for resuming in PCON mode
> 607efb9 drm/i915/lspcon: Get DDC adapter via container_of() instead
> of cached ptr
> e281e36 drm/i915/dp: Read DP descriptor for eDP and LSPCON too
> 742a374 drm/i915/lspcon: Fail LSPCON probe if the start of DPCD can't
> be read
> e3a2cc0 drm/i915/dp: Print full branch/sink descriptor
> d6131ca drm/i915/dp: Print only sink or branch specific OUI based on
> dev type
> 3c3c2a2 drm/i915/dp: Remove debug dependency of DPCD SW/HW revision
> read
> 
> Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2810/
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2810/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] kms_atomic : Added subtest for Single Pipe DBUF validation

[Daniel Vetter]

On Wed, Oct 26, 2016 at 09:33:27AM +0530, meghanelogal wrote:
> Existing DDB algorithm divide the DDB wrt data rate,
> hence the planes with the less height but same width
> will be allocated less blocks and watermark are based
> on width which requires more DDB. With this data the flip
> may fail.
> 
> In new DDB algorithm, the DDB is divided based on
> watermark requirement.
> 
> In this subtest, dividing the htotal/200 will allocate
> ~2-4 blocks out of total(512/896), flip may fail with the
> exisiting algorithm.But with the new algorithm it will pass.
> 
> Signed-off-by: Megha Nelogal 

When resending pls at least mention what you've changed in some per-patch
changelog. And maybe address the stuff I've been raising, but this way
your patch just won't land.
-Daniel
> ---
>  tests/kms_atomic.c | 79 
> ++
>  1 file changed, 79 insertions(+)
> 
> diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
> index f27ee46..3ab1d3f 100644
> --- a/tests/kms_atomic.c
> +++ b/tests/kms_atomic.c
> @@ -1280,6 +1280,60 @@ static void atomic_invalid_params(struct 
> kms_atomic_crtc_state *crtc,
>   do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EFAULT);
>  }
>  
> +static void validate_dbuf(struct kms_atomic_crtc_state *crtc,
> + struct kms_atomic_plane_state **plane_array,
> + int plane_count)
> +{
> + int i;
> + struct kms_atomic_desc *desc = crtc->state->desc;
> +
> + /* for active crtc do modeset on the native resolution */
> + drmModeAtomicReq *req = drmModeAtomicAlloc();
> + struct drm_mode_modeinfo *mode = crtc->mode.data;
> + struct kms_atomic_plane_state plane;
> + struct igt_fb fb;
> +
> + crtc_populate_req(crtc, req);
> +
> + /* Add plane data to the structure...*/
> + uint32_t crtc_x = 0;
> + uint32_t crtc_y = 0;
> +
> + for (i = 0; i < plane_count; i++) {
> + plane = *plane_array[i];
> + uint32_t format = plane_get_igt_format();
> +
> + igt_require(format != 0);
> + plane.src_x = 0;
> + plane.src_y = 0;
> + plane.src_w = (mode->hdisplay / (1)) << 16;
> + plane.crtc_x = crtc_x;
> + plane.crtc_y = crtc_y;
> + plane.crtc_w = (mode->hdisplay) / (1);
> + plane.crtc_h = (mode->vdisplay) / (i + 1);
> +
> + plane.crtc_id = crtc->obj;
> +
> + if (i%2 == 0) {
> + plane.src_h = (mode->vdisplay / (1)) << 16;
> + plane.crtc_h = (mode->vdisplay) / (1);
> + }
> +
> + if (i%2 == 1) {
> + plane.src_h = ceil((mode->vdisplay / 200) << 16);
> + plane.crtc_h = ceil((mode->vdisplay / 200));
> + }
> +
> + plane.fb_id = igt_create_fb(plane.state->desc->fd,
> + plane.crtc_w, plane.crtc_h,
> + format, I915_TILING_NONE, );
> + plane_populate_req(, req);
> + }
> + do_atomic_commit(desc->fd, req, ATOMIC_RELAX_NONE);
> + drmModeAtomicFree(req);
> +}
> +
> +
>  igt_main
>  {
>   struct kms_atomic_desc desc;
> @@ -1373,6 +1427,31 @@ igt_main
>   atomic_state_free(scratch);
>   }
>  
> + igt_subtest("validate_dbuf") {
> + int gen;
> +
> + gen = intel_gen(intel_get_drm_devid(desc.fd));
> + igt_require(gen >= 9);
> +
> + struct kms_atomic_state *scratch = atomic_state_dup(current);
> + struct kms_atomic_crtc_state *crtc;
> + struct kms_atomic_plane_state *planes[2];
> +
> + crtc = find_crtc(scratch, true);
> + igt_require(crtc);
> +
> + igt_require(find_connector(scratch, crtc));
> +
> + planes[0] = find_plane(scratch, PLANE_TYPE_PRIMARY, crtc);
> + igt_require(planes[0]);
> +
> + planes[1] = find_plane(scratch, PLANE_TYPE_OVERLAY, crtc);
> + igt_require(planes[1]);
> +
> + validate_dbuf(crtc, planes, 2);
> + atomic_state_free(scratch);
> + }
> +
>   atomic_state_free(current);
>  
>   igt_fixture
> -- 
> 1.9.1
> 

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> On 26 Oct 2016 9:54 a.m., "Chris Wilson"  wrote:
> >
> > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > ><[1]matthew.william.a...@gmail.com> wrote:
> > >
> > >  On 25 October 2016 at 00:19, Robert Bragg <[2]rob...@sixbynine.org>
> > >  wrote:
> > >
> > >
> > >
> > >  > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > >  b/drivers/gpu/drm/i915/i915_drv.h
> > >  > index 3448d05..ea24814 100644
> > >  > --- a/drivers/gpu/drm/i915/i915_drv.h
> > >  > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > >  > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > >
> > >  >
> > >  >  struct drm_i915_private {
> > >  > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > >  >
> > >  > struct {
> > >  > bool initialized;
> > >  > +
> > >  > struct mutex lock;
> > >  > struct list_head streams;
> > >  >
> > >  > +   spinlock_t hook_lock;
> > >  > +
> > >  > struct {
> > >  > -   u32 metrics_set;
> > >  > +   struct i915_perf_stream
> *exclusive_stream;

OT:
What kind of MUA are you using that mangles quoted mails like this? I've
not seen it on intel-gfx before. mesa-dev seems rife with it, but as I
rarely read that in any great detail I've managed to ignore it there.
Anyways, it makes it espesially hard to navigate long mails since mutt's
'S' (skip quoted text) no longer works correctly.

> > >  > +
> > >  > +   u32 specific_ctx_id;
> > >  Can we just get rid of this, now that the vma remains pinned we can
> > >  simply get the ggtt address at the time of configuring the
> OA_CONTROL
> > >  register ?
> > >
> > >I considered that, but would ideally prefer to keep it considering
> the
> > >gen8+ patches to come. For gen8+ (with execlists) the context ID
> isn't a
> > >gtt offset.
> >
> > In terms of symmetry, keeping the vma you pinned and unpinning the same
> > later makes its ownership much clearer. (And I do want the owner of each
> > pin to be clear, for when we start enabling debug to catch the VMA
> > leaks.)
> 
> Keeping our own pointer to the pinned vma could be a clarification.
> 
> Considering Matt's comments too, I'm thinking I'll put the pinning and
> specific_ctx_id initialization together with setting stream->ctx, keeping
> the state together under the stream. It's going to potentially mean
> redundantly pinning the ctx for the sake of the ID in the future for
> streams that don't really need it, but I think it's probably not worth
> worrying about that.
> 
> - Robert
> 
> > -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


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

[Intel-gfx] [PATCH i-g-t] configure.ac: correctly manage DRM_INTEL_{CFLAGS, LIBS}

[Emil Velikov]

From: Emil Velikov 

Currently the latter is only set when using --enable-intel.

Whereas for the CFLAGS with "enable", it's set by PKG_CHECK_MODULES
and it's set locally for "disable". Yet, in either case it's not
propagated through, this one can get a range of build issues regardless of
the actual state of the toggle.

Cc: Brian Starkey 
Cc: Robert Foss 
Reported-by: Brian Starkey 
Signed-off-by: Emil Velikov 
---
If interested, one can do a fine grained addition in the respective
files, but this is the quickest fix ;-)

On a related note: seems like the nouveau and vc4 CFLAGS are _not_
propagated either. Any volunteers ?
---
 configure.ac | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 735cfd5..1c747b3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -178,12 +178,15 @@ fi
 if test "x$INTEL" = xyes; then
PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])
AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel support])
-   DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
-   AC_SUBST([DRM_LIBS])
 else
DRM_INTEL_CFLAGS=$(top_srcdir)/lib/stubs/drm/
-   AC_SUBST([DRM_INTEL_CFLAGS])
+   DRM_INTEL_LIBS=
 fi
+DRM_CFLAGS="$DRM_CFLAGS $DRM_INTEL_CFLAGS"
+DRM_LIBS="$DRM_LIBS $DRM_INTEL_LIBS"
+AC_SUBST([DRM_CFLAGS])
+AC_SUBST([DRM_LIBS])
+
 AM_CONDITIONAL(HAVE_LIBDRM_INTEL, [test "x$INTEL" = xyes])
 
 # for dma-buf tests
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[Ville Syrjälä]

On Tue, Oct 25, 2016 at 10:55:35AM +0100, Chris Wilson wrote:
> On Tue, Oct 25, 2016 at 12:39:43PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 25, 2016 at 08:20:46AM +0100, Chris Wilson wrote:
> > > On Mon, Oct 24, 2016 at 07:13:04PM +0300, ville.syrj...@linux.intel.com 
> > > wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Pass the framebuffer size in .16 fixed point coordinates to
> > > > drm_rect_rotate() since that's what the source coordinates are as well
> > > > at this stage. We used to do this part of the computation in integer
> > > > coordinates, but that got changed when moving the computation to
> > > > happen in the check phase of the operation. Unfortunately I forgot
> > > > to shift up the fb width and height appropriately.
> > > > 
> > > > With the bogus size we ended up with some negative fb offset, which when
> > > > added to the vma offset caused out scanout to start at an offset earlier
> > > > than we inteded. Eg. when testing on my SKL I saw a row of incorrect
> > > > tiles at the top of my screen.
> > > > 
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: Sivakumar Thulasimani 
> > > > Cc: drm-intel-fi...@lists.freedesktop.org
> > > > Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the 
> > > > plane check hook for SKL+")
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 5a036999487b..c783f884f85d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -2985,7 +2985,8 @@ int skl_check_plane_surface(struct 
> > > > intel_plane_state *plane_state)
> > > > /* Rotate src coordinates to match rotated GTT view */
> > > > if (drm_rotation_90_or_270(rotation))
> > > > drm_rect_rotate(_state->base.src,
> > > > -   fb->width, fb->height, DRM_ROTATE_270);
> > > > +   fb->width << 16, fb->height << 16,
> > > > +   DRM_ROTATE_270);
> > > 
> > > Line 2576 (intel_fill_fb_info()) also looks wrong.
> > > 
> > > drm_rect_rotate(,
> > >   rot_info->plane[i].width * tile_width,
> > >   rot_info->plane[i].height * tile_height,
> > >   DRM_ROTATE_270);
> > 
> > That should be fine. No sub-pixel stuff going on in that
> > function.
> 
> Ah, yes r is not scaled.
> 
> Reviewed-by: Chris Wilson 
> 
> drm_plane_subpixel_scale(fb->width) ?
> drm_plane_scale_pixels_to_subpixels(fb->width) ?

I guess we could have something like that. Can't gurarantee it wouldn't
confuse me though. As I replied to Paulo, my brain has a hard time
understanding abstracted fixed point stuff.

> 
> Not sure what terminology you are already using for the plane_state->src
> coordinates.

Me neither. Sometimes I refer to sub-pixel coordinates, sometimes
fractional coordinates, and sometimes perhaps even something else
that I can't recall right now.

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

On 26 Oct 2016 9:54 a.m., "Chris Wilson"  wrote:
>
> On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> ><[1]matthew.william.a...@gmail.com> wrote:
> >
> >  On 25 October 2016 at 00:19, Robert Bragg <[2]rob...@sixbynine.org>
> >  wrote:
> >
> >
> >
> >  > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >  b/drivers/gpu/drm/i915/i915_drv.h
> >  > index 3448d05..ea24814 100644
> >  > --- a/drivers/gpu/drm/i915/i915_drv.h
> >  > +++ b/drivers/gpu/drm/i915/i915_drv.h
> >  > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> >
> >  >
> >  >  struct drm_i915_private {
> >  > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> >  >
> >  > struct {
> >  > bool initialized;
> >  > +
> >  > struct mutex lock;
> >  > struct list_head streams;
> >  >
> >  > +   spinlock_t hook_lock;
> >  > +
> >  > struct {
> >  > -   u32 metrics_set;
> >  > +   struct i915_perf_stream
*exclusive_stream;
> >  > +
> >  > +   u32 specific_ctx_id;
> >  Can we just get rid of this, now that the vma remains pinned we can
> >  simply get the ggtt address at the time of configuring the
OA_CONTROL
> >  register ?
> >
> >I considered that, but would ideally prefer to keep it considering
the
> >gen8+ patches to come. For gen8+ (with execlists) the context ID
isn't a
> >gtt offset.
>
> In terms of symmetry, keeping the vma you pinned and unpinning the same
> later makes its ownership much clearer. (And I do want the owner of each
> pin to be clear, for when we start enabling debug to catch the VMA
> leaks.)

Keeping our own pointer to the pinned vma could be a clarification.

Considering Matt's comments too, I'm thinking I'll put the pinning and
specific_ctx_id initialization together with setting stream->ctx, keeping
the state together under the stream. It's going to potentially mean
redundantly pinning the ctx for the sake of the ID in the future for
streams that don't really need it, but I think it's probably not worth
worrying about that.

- Robert

> -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: Print some debug/error info during DP dual mode detect

[Ville Syrjälä]

On Wed, Oct 26, 2016 at 05:50:08PM +0300, Imre Deak wrote:
> There's at least one LSPCON device that occasionally returns an unexpected
> adaptor ID which leads to a failed detect. Print some debug info to help
> debugging this and future cases. Also print an error for an unexpected
> adaptor ID, so users can report it.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 488355b..a0e603b 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -142,6 +142,11 @@ static bool is_hdmi_adaptor(const char 
> hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN])
> sizeof(dp_dual_mode_hdmi_id)) == 0;
>  }
>  
> +static bool is_type1_adaptor(uint8_t adaptor_id)
> +{
> + return adaptor_id == 0 || adaptor_id == 0xff;
> +}
> +
>  static bool is_type2_adaptor(uint8_t adaptor_id)
>  {
>   return adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
> @@ -193,6 +198,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
> i2c_adapter *adapter)
>*/
>   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_HDMI_ID,
>   hdmi_id, sizeof(hdmi_id));
> + DRM_DEBUG_KMS("DP dual mode HDMI ID: %*pE (err %zd)\n",
> +   ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);

What does that %*pE print with size==0, nothing?

>   if (ret)
>   return DRM_DP_DUAL_MODE_UNKNOWN;
>  
> @@ -210,6 +217,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
> i2c_adapter *adapter)
>*/
>   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
>   _id, sizeof(adaptor_id));
> + DRM_DEBUG_KMS("DP dual mode adaptor ID: %02x (err %zd)\n",
> +   adaptor_id, ret);
>   if (ret == 0) {
>   if (is_lspcon_adaptor(hdmi_id, adaptor_id))
>   return DRM_DP_DUAL_MODE_LSPCON;
> @@ -219,6 +228,10 @@ enum drm_dp_dual_mode_type 
> drm_dp_dual_mode_detect(struct i2c_adapter *adapter)
>   else
>   return DRM_DP_DUAL_MODE_TYPE2_DVI;
>   }
> + if (!is_type1_adaptor(adaptor_id) && adaptor_id != hdmi_id[0])
 
I take it that was to account for the broken adaptors that ignore the
offset?

> + DRM_ERROR("Unexpected DP dual mode adapter ID %02x\n",
> +   adaptor_id);

s/adapter/adaptor/ since that's what the spec called it, and I continued
down the same path to not confuse it the the i2c adapter.

With that
Reviewed-by: Ville Syrjälä 

> +
>   }
>  
>   if (is_hdmi_adaptor(hdmi_id))
> -- 
> 2.5.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[Ville Syrjälä]

On Tue, Oct 25, 2016 at 05:02:15PM -0200, Paulo Zanoni wrote:
> Em Seg, 2016-10-24 às 19:13 +0300, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > Pass the framebuffer size in .16 fixed point coordinates to
> > drm_rect_rotate() since that's what the source coordinates are as
> > well
> > at this stage. We used to do this part of the computation in integer
> > coordinates, but that got changed when moving the computation to
> > happen in the check phase of the operation. Unfortunately I forgot
> > to shift up the fb width and height appropriately.
> > 
> > With the bogus size we ended up with some negative fb offset, which
> > when
> > added to the vma offset caused out scanout to start at an offset
> > earlier
> > than we inteded. Eg. when testing on my SKL I saw a row of incorrect
> > tiles at the top of my screen.
> 
> I already mentioned this while reviewing another patch from another
> author, but let's throw the idea again: how about adding a specific
> 16.16 type in order to prevent these silent failures when mixing them
> with integers?
> 
> struct (or union) int_fixed_16_16 {
>   uint32_t number;
> }
> 
> And them some nice macros for explicit casting to/from int.
> 
> I see include/drm/fixed.h even has a 20_12 type...

I just get hopelessly confused when fixed point math is hidden in
some library. But who knows, perhaps someone might be able to write
one that my brain can handle. So far I've not seen one though.

> 
> I could even volunteer to do this if there's some positive feedback
> upfront, but feel free to do this too in case you want.
> 
> We're humans and we're going to make the same "mix normal integers with
> 16.16 integers" mistake again and again and again, while the compiler
> could really help us if the types were not plain integers.
> 
> Thoughts?
> 
> > 
> > Cc: Tvrtko Ursulin 
> > Cc: Sivakumar Thulasimani 
> > Cc: drm-intel-fi...@lists.freedesktop.org
> > Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the
> > plane check hook for SKL+")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5a036999487b..c783f884f85d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2985,7 +2985,8 @@ int skl_check_plane_surface(struct
> > intel_plane_state *plane_state)
> >     /* Rotate src coordinates to match rotated GTT view */
> >     if (drm_rotation_90_or_270(rotation))
> >     drm_rect_rotate(_state->base.src,
> > -   fb->width, fb->height,
> > DRM_ROTATE_270);
> > +   fb->width << 16, fb->height << 16,
> > +   DRM_ROTATE_270);
> >  
> >     /*
> >      * Handle the AUX surface first since

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

Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

On 26 Oct 2016 11:08 a.m., "Matthew Auld" 
wrote:
>
> On 26 October 2016 at 00:51, Robert Bragg  wrote:
> >
> >
> > On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> >  wrote:
> >>
> >> On 25 October 2016 at 00:19, Robert Bragg  wrote:
> >
> >
> >>
> >>
> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> > b/drivers/gpu/drm/i915/i915_drv.h
> >> > index 3448d05..ea24814 100644
> >> > --- a/drivers/gpu/drm/i915/i915_drv.h
> >> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> >>
> >> >
> >> >  struct drm_i915_private {
> >> > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> >> >
> >> > struct {
> >> > bool initialized;
> >> > +
> >> > struct mutex lock;
> >> > struct list_head streams;
> >> >
> >> > +   spinlock_t hook_lock;
> >> > +
> >> > struct {
> >> > -   u32 metrics_set;
> >> > +   struct i915_perf_stream *exclusive_stream;
> >> > +
> >> > +   u32 specific_ctx_id;
> >> Can we just get rid of this, now that the vma remains pinned we can
> >> simply get the ggtt address at the time of configuring the OA_CONTROL
> >> register ?
> >
> >
> > I considered that, but would ideally prefer to keep it considering the
gen8+
> > patches to come. For gen8+ (with execlists) the context ID isn't a gtt
> > offset.
> >
> >>
> >>
> >> > +
> >> > +   struct hrtimer poll_check_timer;
> >> > +   wait_queue_head_t poll_wq;
> >> > +   atomic_t pollin;
> >> > +
> >>
> >
> >>
> >> > +/* The maximum exponent the hardware accepts is 63 (essentially it
> >> > selects one
> >> > + * of the 64bit timestamp bits to trigger reports from) but there's
> >> > currently
> >> > + * no known use case for sampling as infrequently as once per 47
> >> > thousand years.
> >> > + *
> >> > + * Since the timestamps included in OA reports are only 32bits it
seems
> >> > + * reasonable to limit the OA exponent where it's still possible to
> >> > account for
> >> > + * overflow in OA report timestamps.
> >> > + */
> >> > +#define OA_EXPONENT_MAX 31
> >> > +
> >> > +#define INVALID_CTX_ID 0x
> >> We shouldn't need this anymore.
> >
> >
> > yeah I removed it and then added it back, just for the sake of
explicitly
> > setting the specific_ctx_id to an invalid ID when closing the exclusive
> > stream - though resetting the value isn't strictly necessary.
> Can we not make the specific_ctx_id per-stream, the gem context
> already is, then we don't need to be concerned with resetting it ?

Hmm, I'm not sure about that, conceptually to me it's global OA unit state.

Currently the driver only supports a single exclusive stream, while Sourab
later relaxes that to a per-engine stream and that could be relaxed further
with non-oa metric stream types.

With multiple streams we'll still only be able to programmer a single ctx
id in oacontol.

Conceptually to me, other stream types could be associated with different
contexts (if they don't depend on the OA unit) so to me stream->ctx isn't
necessarily OA unit state.

It probably could be played around with, but right now we don't track OA
specific state in the stream. For the ID it's just semantics to say it's OA
state, and we could consider that it's maybe generally useful to track the
ID, even for future non-oa streams. That might mean potentially redundantly
pinning state for the sake of tracking the ID for streams that don't end up
needing it.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: Print some debug/error info during DP dual mode detect

[Imre Deak]

There's at least one LSPCON device that occasionally returns an unexpected
adaptor ID which leads to a failed detect. Print some debug info to help
debugging this and future cases. Also print an error for an unexpected
adaptor ID, so users can report it.

Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 488355b..a0e603b 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -142,6 +142,11 @@ static bool is_hdmi_adaptor(const char 
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN])
  sizeof(dp_dual_mode_hdmi_id)) == 0;
 }
 
+static bool is_type1_adaptor(uint8_t adaptor_id)
+{
+   return adaptor_id == 0 || adaptor_id == 0xff;
+}
+
 static bool is_type2_adaptor(uint8_t adaptor_id)
 {
return adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
@@ -193,6 +198,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
 */
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_HDMI_ID,
hdmi_id, sizeof(hdmi_id));
+   DRM_DEBUG_KMS("DP dual mode HDMI ID: %*pE (err %zd)\n",
+ ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
if (ret)
return DRM_DP_DUAL_MODE_UNKNOWN;
 
@@ -210,6 +217,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
 */
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
_id, sizeof(adaptor_id));
+   DRM_DEBUG_KMS("DP dual mode adaptor ID: %02x (err %zd)\n",
+ adaptor_id, ret);
if (ret == 0) {
if (is_lspcon_adaptor(hdmi_id, adaptor_id))
return DRM_DP_DUAL_MODE_LSPCON;
@@ -219,6 +228,10 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
else
return DRM_DP_DUAL_MODE_TYPE2_DVI;
}
+   if (!is_type1_adaptor(adaptor_id) && adaptor_id != hdmi_id[0])
+   DRM_ERROR("Unexpected DP dual mode adapter ID %02x\n",
+ adaptor_id);
+
}
 
if (is_hdmi_adaptor(hdmi_id))
-- 
2.5.0

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

[Intel-gfx] [PATCH v3 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

[ville . syrjala]

From: Ville Syrjälä 

The i2c adapter is only relevant for some peer device types, so
let's clear the pdt if it's still the same as the old_pdt when we
tear down the i2c adapter.

I don't really like this design pattern of updating port->whatever
before doing the accompanying changes and passing around old_whatever
to figure stuff out. Would make much more sense to me to the pass the
new value around and only update the port->whatever when things are
consistent. But let's try to work with what we have right now.

Clearing port->pdt in drm_dp_destroy_connector_work() would be enough,
but I chose to do it also in drm_dp_destroy_port(). The reason being
extra consistency so that we don't lose this by accident should someone
choose to refactor the code later.

v2: Cleart port->pdt in the caller, if needed (Daniel)
v3: Amend commit message a bit (Daniel)

Cc: Daniel Vetter 
Cc: sta...@vger.kernel.org
Cc: Carlos Santa 
Cc: Kirill A. Shutemov 
Tested-by: Carlos Santa  (v1)
Tested-by: Kirill A. Shutemov  (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04e457117980..ba13f9d8720b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -914,6 +914,7 @@ static void drm_dp_destroy_port(struct kref *kref)
/* no need to clean up vcpi
 * as if we have no connector we never setup a vcpi */
drm_dp_port_teardown_pdt(port, port->pdt);
+   port->pdt = DP_PEER_DEVICE_NONE;
}
kfree(port);
 }
@@ -2919,6 +2920,7 @@ static void drm_dp_destroy_connector_work(struct 
work_struct *work)
mgr->cbs->destroy_connector(mgr, port->connector);
 
drm_dp_port_teardown_pdt(port, port->pdt);
+   port->pdt = DP_PEER_DEVICE_NONE;
 
if (!port->input && port->vcpi.vcpi > 0) {
drm_dp_mst_reset_vcpi_slots(mgr, port);
-- 
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 lib/ida: Document locking requirements a bit better

[Patchwork]

== Series Details ==

Series: lib/ida: Document locking requirements a bit better
URL   : https://patchwork.freedesktop.org/series/14410/
State : success

== Summary ==

Series 14410v1 lib/ida: Document locking requirements a bit better
https://patchwork.freedesktop.org/api/1.0/series/14410/revisions/1/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 
fi-bsw-n3050 failed to connect after reboot

760634d2b78657f0a2267f73bff0d527f6c69ce5 drm-intel-nightly: 
2016y-10m-26d-11h-52m-53s UTC integration manifest
a8f9106 lib/ida: Document locking requirements a bit better

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2824/

== Logs ==

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

Re: [Intel-gfx] [PATCH] lib/ida: Document locking requirements a bit better

[Tejun Heo]

Hello, Daniel.

On Wed, Oct 26, 2016 at 04:27:39PM +0200, Daniel Vetter wrote:
> I wanted to wrap a bunch of ida_simple_get calls into their own
> locking, until I dug around and read the original commit message.
> Stuff like this should imo be added to the kernel doc, let's do that.

Generally agreed but some nits below.

> @@ -927,6 +927,9 @@ EXPORT_SYMBOL(ida_pre_get);
>   * and go back to the ida_pre_get() call.  If the ida is full, it will
>   * return %-ENOSPC.
>   *
> + * Note that callers must ensure that concurrent access to @ida is not 
> possible.
> + * When simplicity trumps concurrency needs look at ida_simple_get() instead.

Maybe we can make it a bit less dramatic?

> @@ -1073,6 +1076,10 @@ EXPORT_SYMBOL(ida_destroy);
>   * Allocates an id in the range start <= id < end, or returns -ENOSPC.
>   * On memory allocation failure, returns -ENOMEM.
>   *
> + * Compared to ida_get_new_above() this function does its own locking and 
> hence
> + * is recommended everywhere where simplicity is preferred over the last bit 
> of
> + * speed.

Hmm... so, this isn't necessarily about speed.  For example, id
allocation might have to happen inside a spinlock which protects a
larger scope.  To guarantee GFP_KERNEL allocation behavior in such
cases, the caller would have to call ida_pre_get() outside the said
spinlock and then call ida_get_new_above() inside the lock.

I think it'd be better to explain what the simple version does and
expects and then say that unless there are specific requirements using
the simple version is recommended.

Thanks.

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

[Intel-gfx] [PATCH] lib/ida: Document locking requirements a bit better

[Daniel Vetter]

I wanted to wrap a bunch of ida_simple_get calls into their own
locking, until I dug around and read the original commit message.
Stuff like this should imo be added to the kernel doc, let's do that.

Cc: Mel Gorman 
Cc: Michal Hocko 
Cc: Vlastimil Babka 
Cc: Tejun Heo 
Cc: Andrew Morton 
Signed-off-by: Daniel Vetter 
---
 lib/idr.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/lib/idr.c b/lib/idr.c
index 6098336df267..5508d7f6d7be 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -927,6 +927,9 @@ EXPORT_SYMBOL(ida_pre_get);
  * and go back to the ida_pre_get() call.  If the ida is full, it will
  * return %-ENOSPC.
  *
+ * Note that callers must ensure that concurrent access to @ida is not 
possible.
+ * When simplicity trumps concurrency needs look at ida_simple_get() instead.
+ *
  * @p_id returns a value in the range @starting_id ... %0x7fff.
  */
 int ida_get_new_above(struct ida *ida, int starting_id, int *p_id)
@@ -1073,6 +1076,10 @@ EXPORT_SYMBOL(ida_destroy);
  * Allocates an id in the range start <= id < end, or returns -ENOSPC.
  * On memory allocation failure, returns -ENOMEM.
  *
+ * Compared to ida_get_new_above() this function does its own locking and hence
+ * is recommended everywhere where simplicity is preferred over the last bit of
+ * speed.
+ *
  * Use ida_simple_remove() to get rid of an id.
  */
 int ida_simple_get(struct ida *ida, unsigned int start, unsigned int end,
@@ -1119,6 +1126,13 @@ EXPORT_SYMBOL(ida_simple_get);
  * ida_simple_remove - remove an allocated id.
  * @ida: the (initialized) ida.
  * @id: the id returned by ida_simple_get.
+ *
+ * Use to release an id allocated with ida_simple_get().
+ *
+ * Compared to ida_get_new_above() this function does its own locking and hence
+ * is recommended everywhere where simplicity is preferred over the last bit of
+ * speed.
+ *
  */
 void ida_simple_remove(struct ida *ida, unsigned int id)
 {
-- 
2.10.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9+: Atomic watermark fixes.

[Patchwork]

== Series Details ==

Series: drm/i915/gen9+: Atomic watermark fixes.
URL   : https://patchwork.freedesktop.org/series/14405/
State : success

== Summary ==

Series 14405v1 drm/i915/gen9+: Atomic watermark fixes.
https://patchwork.freedesktop.org/api/1.0/series/14405/revisions/1/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

760634d2b78657f0a2267f73bff0d527f6c69ce5 drm-intel-nightly: 
2016y-10m-26d-11h-52m-53s UTC integration manifest
3851736 drm/i915/gen9+: Kill off hw_ddb from intel_crtc.
8088a1f drm/i915/gen9+: Preserve old allocation from crtc_state.
53b40ed drm/i915/gen9+: Program watermarks as a separate step during evasion, 
v2.
280e6c9 drm/i915/gen9+: Use the watermarks from crtc_state for everything, v2.
e1b41c4 drm/i915: Add a atomic evasion step to watermark programming, v2.
e1391f9 drm/i915/skl+: Clean up minimum allocations, v2.
4867fcd drm/i915/skl+: Remove minimum block allocation from crtc state.
e29a244 drm/i915/skl+: Remove data_rate from watermark struct, v2.
e1255cc drm/i915/gen9+: Use for_each_intel_plane_on_crtc in skl_print_wm_changes
09955c2 drm/i915/gen9+: Use cstate plane mask instead of crtc->state.
95e2c7a drm/i915/skl+: Prepare for removing data rate from skl watermark state, 
v2.

Full results at https://intel-gfx-ci.01.org/CI/Patchwork_2823/

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2823/
___
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/3 v3] tests/drv_module_reload: Convert sh script to C version.

[Chris Wilson]

On Wed, Oct 26, 2016 at 04:54:40PM +0300, Marius Vlad wrote:
> +int main(void)
> +{
> + struct drm_i915_gem_sw_finish arg = { 0 };
> + int fd;
> +
> + signal(SIGALRM, SIG_IGN);
> +
> + fd = __drm_open_driver(DRIVER_INTEL);
> + if (fd < 0)
> + return IGT_EXIT_SKIP;
> +
> + alarm(1);
> + if (ioctl(fd, DRM_IOCTL_I915_GEM_SW_FINISH, ) == 0)
> + return IGT_EXIT_SKIP;

Hmm, good point. sw-finish work like this any more. The key was that we
used to wait on the struct_mutex before doing the lookup (and so we
could probe whether the driver was stuck on the reset, or just stuck).

Current candidate for replacement is the SET_CACHEING ioctl
-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 i-g-t 1/3 v3] lib/{igt_sysfs, igt_aux}: Make available to other users kick_fbcon() (unbind_fbcon()), and added helpers to igt_aux.

[Chris Wilson]

On Wed, Oct 26, 2016 at 04:54:39PM +0300, Marius Vlad wrote:
> diff --git a/lib/igt_gvt.c b/lib/igt_gvt.c
> index 0f332d1..8bbf9bd 100644
> --- a/lib/igt_gvt.c
> +++ b/lib/igt_gvt.c
> @@ -23,6 +23,7 @@
>  
>  #include "igt.h"
>  #include "igt_gvt.h"
> +#include "igt_sysfs.h"
>  
>  #include 
>  #include 
> @@ -46,49 +47,9 @@ static bool is_gvt_enabled(void)
>   return enabled;
>  }
>  
>  static void unload_i915(void)
>  {
> - unbind_fbcon();
> + kick_fbcon(false);
>   /* pkill alsact */

Complete the conversion here to the new kmod helpers.
-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 11/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.

[Maarten Lankhorst]

This member is only used in skl_update_crtcs now. It's easy to remove it
by keeping track of which ddb entries in an array, and update them after
we update the crtc. This removes the last bits of SKL-style watermarks
kept outside of crtc_state.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 drivers/gpu/drm/i915/intel_drv.h | 11 +++
 drivers/gpu/drm/i915/intel_pm.c  | 25 +++--
 3 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f73926d62521..7107e2c82daf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14316,6 +14316,14 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
unsigned int updated = 0;
bool progress;
enum pipe pipe;
+   int i;
+
+   const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
+
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i)
+   /* ignore allocations for crtc's that have been turned off. */
+   if (crtc->state->active)
+   entries[i] = 
_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
 
/*
 * Whenever the number of active pipes changes, we need to make sure we
@@ -14324,7 +14332,6 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 * cause pipe underruns and other bad stuff.
 */
do {
-   int i;
progress = false;
 
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
@@ -14335,12 +14342,14 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
cstate = to_intel_crtc_state(crtc->state);
pipe = intel_crtc->pipe;
 
-   if (updated & cmask || !crtc->state->active)
+   if (updated & cmask || !cstate->base.active)
continue;
-   if (skl_ddb_allocation_overlaps(state, intel_crtc))
+
+   if (skl_ddb_allocation_overlaps(entries, 
>wm.skl.ddb, i))
continue;
 
updated |= cmask;
+   entries[i] = >wm.skl.ddb;
 
/*
 * If this is an already active pipe, it's DDB changed,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2cd7c5fd9ebd..4827f1516399 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -729,9 +729,6 @@ struct intel_crtc {
bool cxsr_allowed;
} wm;
 
-   /* gen9+: ddb allocation currently being used */
-   struct skl_ddb_entry hw_ddb;
-
int scanline_offset;
 
struct {
@@ -1742,11 +1739,9 @@ int intel_enable_sagv(struct drm_i915_private *dev_priv);
 int intel_disable_sagv(struct drm_i915_private *dev_priv);
 bool skl_wm_level_equals(const struct skl_wm_level *l1,
 const struct skl_wm_level *l2);
-bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old,
-  const struct skl_ddb_allocation *new,
-  enum pipe pipe);
-bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
-struct intel_crtc *intel_crtc);
+bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry **entries,
+const struct skl_ddb_entry *ddb,
+int ignore);
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6be54cd91f27..b923040bd7e2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3910,25 +3910,16 @@ static inline bool skl_ddb_entries_overlap(const struct 
skl_ddb_entry *a,
return a->start < b->end && b->start < a->end;
 }
 
-bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
-struct intel_crtc *intel_crtc)
-{
-   struct drm_crtc *other_crtc;
-   struct drm_crtc_state *other_cstate;
-   struct intel_crtc *other_intel_crtc;
-   const struct skl_ddb_entry *ddb =
-   _intel_crtc_state(intel_crtc->base.state)->wm.skl.ddb;
+bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry **entries,
+const struct skl_ddb_entry *ddb,
+int ignore)
+{
int i;
 
-   for_each_crtc_in_state(state, other_crtc, other_cstate, i) {
-   other_intel_crtc = to_intel_crtc(other_crtc);
-
-   if (other_intel_crtc == intel_crtc)
-