date:20190225

Re: [Intel-gfx] [PATCH v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Tvrtko Ursulin



On 26/02/2019 07:49, Chris Wilson wrote:

To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests will then be completed, we use a primitive random number
generator instead (with a cycle long enough to not matter over an
interval of a few thousand requests between hangcheck samples).

The alternative to using a dedicated seqno on every request is to issue
a heartbeat request and query its progress through the system. Sadly
this requires us to reduce struct_mutex so that we can issue requests
without requiring that bkl.

v2: And without the extra CS_STALL for the hangcheck seqno -- we don't
need strict serialisation with what comes later, we just need to be sure
we don't write the hangcheck seqno before our batch is flushed.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_debugfs.c |  7 ++---
  drivers/gpu/drm/i915/intel_engine_cs.c  |  5 ++--
  drivers/gpu/drm/i915/intel_hangcheck.c  |  6 ++---
  drivers/gpu/drm/i915/intel_lrc.c| 15 +++
  drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
  drivers/gpu/drm/i915/intel_ringbuffer.h | 19 -
  6 files changed, 77 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 37175414ce89..545091a5180b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1295,7 +1295,7 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
with_intel_runtime_pm(dev_priv, wakeref) {
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
-   seqno[id] = intel_engine_get_seqno(engine);
+   seqno[id] = intel_engine_get_hangcheck_seqno(engine);
}
  
  		intel_engine_get_instdone(dev_priv->engine[RCS], );

@@ -1315,8 +1315,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
-  engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
+  engine->hangcheck.last_seqno,
+  seqno[id],
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies -

engine->hangcheck.action_timestamp));
  
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c

index 81b80f8fd9ea..57bc5c4fb3ff 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1497,10 +1497,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_reset_failed(engine->i915))
drm_printf(m, "*** WEDGED ***\n");
  
-	drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",

+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x/%x [%d ms]\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
-  engine->hangcheck.seqno,
+  engine->hangcheck.last_seqno,
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 9be033b6f4d2..f1d8dfc58049 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -133,21 +133,21 @@ static void hangcheck_load_sample(struct intel_engine_cs 
*engine,
  struct hangcheck *hc)
  {
hc->acthd = intel_engine_get_active_head(engine);
-   hc->seqno = intel_engine_get_seqno(engine);
+   hc->seqno = intel_engine_get_hangcheck_seqno(engine);
  }
  
  static void hangcheck_store_sample(struct intel_engine_cs *engine,

   const struct hangcheck *hc)
  {
engine->hangcheck.acthd = hc->acthd;
-   engine->hangcheck.seqno = hc->seqno;
+   engine->hangcheck.last_seqno = hc->seqno;
  }
  
  static enum intel_engine_hangcheck_action

  hangcheck_get_action(struct intel_engine_cs *engine,
 const struct hangcheck *hc)
  {
-   if (engine->hangcheck.seqno != hc->seqno)
+   if (engine->hangcheck.last_seqno != hc->seqno)
return ENGINE_ACTIVE_SEQNO;
  
  	if

[Intel-gfx] [PATCH v2] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Chris Wilson

To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests will then be completed, we use a primitive random number
generator instead (with a cycle long enough to not matter over an
interval of a few thousand requests between hangcheck samples).

The alternative to using a dedicated seqno on every request is to issue
a heartbeat request and query its progress through the system. Sadly
this requires us to reduce struct_mutex so that we can issue requests
without requiring that bkl.

v2: And without the extra CS_STALL for the hangcheck seqno -- we don't
need strict serialisation with what comes later, we just need to be sure
we don't write the hangcheck seqno before our batch is flushed.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 ++---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  5 ++--
 drivers/gpu/drm/i915/intel_hangcheck.c  |  6 ++---
 drivers/gpu/drm/i915/intel_lrc.c| 15 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 19 -
 6 files changed, 77 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 37175414ce89..545091a5180b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1295,7 +1295,7 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
with_intel_runtime_pm(dev_priv, wakeref) {
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
-   seqno[id] = intel_engine_get_seqno(engine);
+   seqno[id] = intel_engine_get_hangcheck_seqno(engine);
}
 
intel_engine_get_instdone(dev_priv->engine[RCS], );
@@ -1315,8 +1315,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
-  engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
+  engine->hangcheck.last_seqno,
+  seqno[id],
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies -

engine->hangcheck.action_timestamp));
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 81b80f8fd9ea..57bc5c4fb3ff 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1497,10 +1497,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_reset_failed(engine->i915))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x/%x [%d ms]\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
-  engine->hangcheck.seqno,
+  engine->hangcheck.last_seqno,
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 9be033b6f4d2..f1d8dfc58049 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -133,21 +133,21 @@ static void hangcheck_load_sample(struct intel_engine_cs 
*engine,
  struct hangcheck *hc)
 {
hc->acthd = intel_engine_get_active_head(engine);
-   hc->seqno = intel_engine_get_seqno(engine);
+   hc->seqno = intel_engine_get_hangcheck_seqno(engine);
 }
 
 static void hangcheck_store_sample(struct intel_engine_cs *engine,
   const struct hangcheck *hc)
 {
engine->hangcheck.acthd = hc->acthd;
-   engine->hangcheck.seqno = hc->seqno;
+   engine->hangcheck.last_seqno = hc->seqno;
 }
 
 static enum intel_engine_hangcheck_action
 hangcheck_get_action(struct intel_engine_cs *engine,
 const struct hangcheck *hc)
 {
-   if (engine->hangcheck.seqno != hc->seqno)
+   if (engine->hangcheck.last_seqno != hc->seqno)
return ENGINE_ACTIVE_SEQNO;
 
if (intel_engine_is_idle(engine))
diff --git

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Chris Wilson

Quoting Tvrtko Ursulin (2019-02-26 07:34:37)
> 
> On 25/02/2019 18:40, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-25 17:59:40)
> >>
> >> On 25/02/2019 16:23, Chris Wilson wrote:
> >>>static inline struct i915_priolist *to_priolist(struct rb_node *rb)
> >>>{
> >>>return rb_entry(rb, struct i915_priolist, node);
> >>> @@ -2206,6 +2212,10 @@ static u32 *gen8_emit_fini_breadcrumb(struct 
> >>> i915_request *request, u32 *cs)
> >>>  request->fence.seqno,
> >>>  request->timeline->hwsp_offset);
> >>>
> >>> + cs = gen8_emit_ggtt_write(cs,
> >>> +   
> >>> intel_engine_next_hangcheck_seqno(request->engine),
> >>> +   
> >>> intel_hws_hangcheck_address(request->engine));
> >>> +
> >>>cs = gen8_emit_ggtt_write(cs,
> >>>  request->global_seqno,
> >>>  
> >>> intel_hws_seqno_address(request->engine));
> >>> @@ -2230,6 +2240,11 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct 
> >>> i915_request *request, u32 *cs)
> >>>  PIPE_CONTROL_FLUSH_ENABLE |
> >>>  PIPE_CONTROL_CS_STALL);
> >>>
> >>> + cs = gen8_emit_ggtt_write_rcs(cs,
> >>> +   
> >>> intel_engine_next_hangcheck_seqno(request->engine),
> >>> +   
> >>> intel_hws_hangcheck_address(request->engine),
> >>> +   PIPE_CONTROL_CS_STALL);
> >>
> >> Are CS_STALL needed on two writes or only last one would be enough? Or
> >> even, should all flushes be moved to the last pipe control?
> > 
> > The CS_STALL is overkill as there's no requirement for it to be before
> > the global_seqno, but the convenience and ease to reason over win.

[snip]

> Ok have at it.
> 
> Reviewed-by: Tvrtko Ursulin 

I was just about to resend without the CS_STALL...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 09/10] drm/i915: Populate downstream info for HDCP2.2

2019-02-25 Thread Ramalingam C

Populates the downstream info for HDCP2.2 encryption also. On success
of encryption Blob is updated.

Additional two variable are added to downstream info blob. Such as
ver_in_force and content type.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 29 -
 include/uapi/drm/drm_mode.h   |  3 +++
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 9ce634e552c1..8c05f382718c 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1271,6 +1271,12 @@ static int hdcp2_authentication_key_exchange(struct 
intel_connector *connector)
return -EPERM;
}
 
+   hdcp->downstream_info->ver_in_force = DRM_MODE_HDCP22_IN_FORCE;
+   hdcp->downstream_info->content_type = hdcp->content_type;
+   memcpy(hdcp->downstream_info->bksv, msgs.send_cert.cert_rx.receiver_id,
+  HDCP_2_2_RECEIVER_ID_LEN);
+   hdcp->downstream_info->is_repeater = hdcp->is_repeater;
+
/*
 * Here msgs.no_stored_km will hold msgs corresponding to the km
 * stored also.
@@ -1462,6 +1468,11 @@ int hdcp2_authenticate_repeater_topology(struct 
intel_connector *connector)
return -EPERM;
}
 
+   hdcp->downstream_info->device_count = device_cnt;
+   hdcp->downstream_info->depth = HDCP_2_2_DEPTH(rx_info[0]);
+   memcpy(hdcp->downstream_info->ksv_list, msgs.recvid_list.receiver_ids,
+  device_cnt * HDCP_2_2_RECEIVER_ID_LEN);
+
ret = hdcp2_verify_rep_topology_prepare_ack(connector,
_list,
_ack);
@@ -1648,6 +1659,13 @@ static int _intel_hdcp2_enable(struct intel_connector 
*connector)
if (ret) {
DRM_DEBUG_KMS("HDCP2 Type%d  Enabling Failed. (%d)\n",
  hdcp->content_type, ret);
+
+   memset(hdcp->downstream_info, 0,
+  sizeof(struct cp_downstream_info));
+   drm_mode_connector_update_cp_downstream_property(
+   >base,
+   hdcp->downstream_info);
+
return ret;
}
 
@@ -1655,12 +1673,17 @@ static int _intel_hdcp2_enable(struct intel_connector 
*connector)
  connector->base.name, connector->base.base.id,
  hdcp->content_type);
 
+   drm_mode_connector_update_cp_downstream_property(
+   >base,
+   hdcp->downstream_info);
hdcp->hdcp2_encrypted = true;
+
return 0;
 }
 
 static int _intel_hdcp2_disable(struct intel_connector *connector)
 {
+   struct intel_hdcp *hdcp = >hdcp;
int ret;
 
DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
@@ -1671,8 +1694,12 @@ static int _intel_hdcp2_disable(struct intel_connector 
*connector)
if (hdcp2_deauthenticate_port(connector) < 0)
DRM_DEBUG_KMS("Port deauth failed.\n");
 
-   connector->hdcp.hdcp2_encrypted = false;
+   hdcp->hdcp2_encrypted = false;
 
+   memset(hdcp->downstream_info, 0, sizeof(struct cp_downstream_info));
+   drm_mode_connector_update_cp_downstream_property(
+   >base,
+   hdcp->downstream_info);
return ret;
 }
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 93403b2631ef..4d868de06f8f 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -223,6 +223,9 @@ struct cp_downstream_info {
/* Version of HDCP authenticated (1.4/2.2) */
__u32 ver_in_force;
 
+   /* Applicable only for HDCP2.2 */
+   __u8 content_type;
+
/* KSV of immediate HDCP Sink. In Little-Endian Format. */
char bksv[DRM_MODE_HDCP_KSV_LEN];
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 08/10] drm/i915: Populate downstream info for HDCP1.4

2019-02-25 Thread Ramalingam C

Implements drm blob property cp_downstream_info property on HDCP
capable connectors.

Downstream topology info is gathered across authentication stages
and stored in intel_hdcp. When HDCP authentication is complete,
new blob with latest downstream topology information is updated to
cp_downstream_info property.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_hdcp.c | 32 +++-
 include/drm/drm_hdcp.h|  1 +
 include/uapi/drm/drm_mode.h   |  5 +
 4 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 53a463d40f43..c7ef7e71439d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -487,6 +487,8 @@ struct intel_hdcp {
unsigned int revocated_ksv_cnt;
u8 *revocated_ksv_list;
u32 srm_blob_id;
+
+   struct cp_downstream_info *downstream_info;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index b92fc0383788..9ce634e552c1 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -563,6 +563,9 @@ int intel_hdcp_auth_downstream(struct intel_hdcp *hdcp,
if (num_downstream == 0)
return -EINVAL;
 
+   hdcp->downstream_info->device_count = num_downstream;
+   hdcp->downstream_info->depth = DRM_HDCP_DEPTH(bstatus[1]);
+
ksv_fifo = kcalloc(DRM_HDCP_KSV_LEN, num_downstream, GFP_KERNEL);
if (!ksv_fifo)
return -ENOMEM;
@@ -576,6 +579,8 @@ int intel_hdcp_auth_downstream(struct intel_hdcp *hdcp,
return -EPERM;
}
 
+   memcpy(hdcp->downstream_info->ksv_list, ksv_fifo,
+  num_downstream * DRM_HDCP_KSV_LEN);
/*
 * When V prime mismatches, DP Spec mandates re-read of
 * V prime atleast twice.
@@ -677,15 +682,20 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
return -EPERM;
}
 
+   hdcp->downstream_info->ver_in_force = DRM_MODE_HDCP14_IN_FORCE;
+   memcpy(hdcp->downstream_info->bksv, bksv.shim, DRM_MODE_HDCP_KSV_LEN);
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
 
ret = shim->repeater_present(intel_dig_port, _present);
if (ret)
return ret;
-   if (repeater_present)
+   if (repeater_present) {
I915_WRITE(HDCP_REP_CTL,
   intel_hdcp_get_repeater_ctl(intel_dig_port));
+   hdcp->downstream_info->is_repeater = true;
+   }
 
ret = shim->toggle_signalling(intel_dig_port, true);
if (ret)
@@ -781,6 +791,13 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
return ret;
}
 
+   memset(hdcp->downstream_info, 0, sizeof(struct cp_downstream_info));
+
+   if (drm_mode_connector_update_cp_downstream_property(
+   >base,
+   connector->hdcp.downstream_info))
+   DRM_ERROR("Downstream_info update failed.\n");
+
DRM_DEBUG_KMS("HDCP is disabled\n");
return 0;
 }
@@ -814,6 +831,10 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
ret = intel_hdcp_auth(connector);
if (!ret) {
connector->hdcp.hdcp_encrypted = true;
+   if (drm_mode_connector_update_cp_downstream_property(
+   >base,
+   connector->hdcp.downstream_info))
+   DRM_ERROR("Downstream_info update failed.\n");
return 0;
}
 
@@ -1874,6 +1895,15 @@ int intel_hdcp_init(struct intel_connector *connector,
if (ret)
return ret;
 
+   ret = drm_connector_attach_cp_downstream_property(>base);
+   if (ret)
+   return ret;
+
+   hdcp->downstream_info = kzalloc(sizeof(*hdcp->downstream_info),
+   GFP_KERNEL);
+   if (!hdcp->downstream_info)
+   return -ENOMEM;
+
hdcp->shim = shim;
mutex_init(>mutex);
INIT_DELAYED_WORK(>check_work, intel_hdcp_check_work);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 1e630a593b73..2787a2d555b4 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -23,6 +23,7 @@
 #define DRM_HDCP_V_PRIME_PART_LEN  4
 #define DRM_HDCP_V_PRIME_NUM_PARTS 5
 #define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
+#define DRM_HDCP_DEPTH(x)  ((x) & 0x7)
 #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)   (x & BIT(3))
 #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)(x & BIT(7))
 
diff --git a/include/uapi/drm/drm_mode.h

[Intel-gfx] [PATCH 07/10] drm: Add CP downstream_info property

2019-02-25 Thread Ramalingam C

This patch adds CP downstream info blob property to the
connectors. This enables the Userspace to read the information of HDCP
authenticated downstream topology.

Driver will updated this blob with all downstream information at the
end of the authentication.

Userspace need this informations to configure this platform as repeater,
where KMD will be the downstream HDCP ports of the repeater and userspace
implementation will act as upstream HDCP port.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  3 ++
 drivers/gpu/drm/drm_connector.c   | 88 +++
 include/drm/drm_connector.h   | 12 ++
 include/uapi/drm/drm_mode.h   | 27 
 4 files changed, 130 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9c57d8c07d09..f28fb64d1986 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -842,6 +842,9 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->cp_content_type;
} else if (property == connector->cp_srm_property) {
*val = state->cp_srm_blob_id;
+   } else if (property == connector->cp_downstream_property) {
+   *val = connector->cp_downstream_blob_ptr ?
+   connector->cp_downstream_blob_ptr->base.id : 0;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 510941ad532f..0b58d07d1d53 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -245,6 +245,7 @@ int drm_connector_init(struct drm_device *dev,
INIT_LIST_HEAD(>modes);
mutex_init(>mutex);
connector->edid_blob_ptr = NULL;
+   connector->cp_downstream_blob_ptr = NULL;
connector->status = connector_status_unknown;
connector->display_info.panel_orientation =
DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
@@ -1002,6 +1003,25 @@ DRM_ENUM_NAME_FN(drm_get_cp_content_type_name, 
drm_cp_content_type_enum_list)
  * Guideline for programming:
  *   - Property state can be changed only when "Content Protection state is
  * DRM_MODE_CONTENT_PROTECTION_UNDESIRED.
+ * CP_Downstream_Info:
+ * This blob property is used to pass the HDCP downstream topology details
+ * of a HDCP encrypted connector, from kernel to userspace.
+ * This provides all required information to userspace, so that userspace
+ * can implement the HDCP repeater using the kernel as downstream ports of
+ * the repeater. as illustrated below:
+ *
+ *  HDCP Repeaters
+ * +--+
+ * |  |
+ * |   |  |
+ * |   Userspace HDCP Receiver  +->KMD HDCP transmitters  |
+ * |  (Upstream Port)  <--+ (Downstream Ports)|
+ * |   |  |
+ * |  |
+ * +--+
+ *
+ * Kernel will populate this blob only when the HDCP authentication is
+ * successful.
  *
  * max bpc:
  * This range property is used by userspace to limit the bit depth. When
@@ -1664,6 +1684,74 @@ int drm_connector_attach_cp_srm_property(struct 
drm_connector *connector)
 EXPORT_SYMBOL(drm_connector_attach_cp_srm_property);
 
 /**
+ * drm_connector_attach_cp_downstream_property - attach cp downstream
+ * property
+ *
+ * @connector: connector to attach cp downstream property on.
+ *
+ * This is used to add support for content protection downstream info on
+ * select connectors. when Intel platform is configured as repeater,
+ * this downstream info is used by userspace, to complete the repeater
+ * authentication of HDCP specification with upstream HDCP transmitter.
+ *
+ * The cp downstream will be set to _connector_state.cp_downstream
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_cp_downstream_property(
+   struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB |
+  DRM_MODE_PROP_IMMUTABLE,
+  "CP_Downstream_Info", 0);
+   if (!prop)
+   return -ENOMEM;
+
+   drm_object_attach_property(>base, prop, 0);
+
+   connector->cp_downstream_property = prop;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_cp_downstream_property);
+
+/**
+ * drm_mode_connector_update_cp_downstream_property - update

[Intel-gfx] [PATCH 06/10] drm/i915: SRM parsing and revocation check for HDCP2

2019-02-25 Thread Ramalingam C

SRM blob with hdcp2 id is parsed and parsed list of revoked ids is
used in the authentication process to identify the compromised HDCP
sinks.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 86 +--
 include/drm/drm_hdcp.h| 20 +
 2 files changed, 103 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 7d007de984d7..b92fc0383788 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1244,6 +1244,12 @@ static int hdcp2_authentication_key_exchange(struct 
intel_connector *connector)
 
hdcp->is_repeater = HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
 
+   if (intel_hdcp_ksvs_revocated(hdcp,
+ msgs.send_cert.cert_rx.receiver_id, 1)) {
+   DRM_ERROR("Receiver ID is revocated\n");
+   return -EPERM;
+   }
+
/*
 * Here msgs.no_stored_km will hold msgs corresponding to the km
 * stored also.
@@ -1402,7 +1408,7 @@ int hdcp2_authenticate_repeater_topology(struct 
intel_connector *connector)
} msgs;
const struct intel_hdcp_shim *shim = hdcp->shim;
u8 *rx_info;
-   u32 seq_num_v;
+   u32 seq_num_v, device_cnt;
int ret;
 
ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
@@ -1427,6 +1433,14 @@ int hdcp2_authenticate_repeater_topology(struct 
intel_connector *connector)
return -EINVAL;
}
 
+   device_cnt = HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 ||
+   HDCP_2_2_DEV_COUNT_LO(rx_info[1]);
+   if (intel_hdcp_ksvs_revocated(hdcp, msgs.recvid_list.receiver_ids,
+ device_cnt)) {
+   DRM_ERROR("Revoked receiver ID(s) is in list\n");
+   return -EPERM;
+   }
+
ret = hdcp2_verify_rep_topology_prepare_ack(connector,
_list,
_ack);
@@ -1982,12 +1996,72 @@ static int intel_hdcp_parse_srm(struct drm_connector 
*connector,
return 0;
 }
 
+static int intel_hdcp2_parse_srm(struct drm_connector *connector,
+struct drm_property_blob *blob)
+{
+   struct intel_hdcp *hdcp = &(to_intel_connector(connector)->hdcp);
+   struct hdcp2_srm_header *header;
+   u32 vrl_length, ksv_count, ksv_sz;
+   u8 *buf;
+
+   if (blob->length < (sizeof(struct hdcp2_srm_header) +
+   DRM_HDCP_2_VRL_LENGTH_SIZE + DRM_HDCP_2_DCP_SIG_SIZE)) {
+   DRM_ERROR("Invalid blob length\n");
+   return -EINVAL;
+   }
+
+   header = (struct hdcp2_srm_header *)blob->data;
+   DRM_DEBUG_KMS("SRM ID: 0x%x, SRM Ver: 0x%x, SRM Gen No: 0x%x\n",
+ header->spec_indicator.srm_id,
+ __swab16(header->srm_version), header->srm_gen_no);
+   WARN_ON(header->spec_indicator.reserved);
+   buf = blob->data + sizeof(*header);
+
+   vrl_length = (*buf << 16 | *(buf + 1) << 8 | *(buf + 2));
+   if (blob->length < (sizeof(struct hdcp2_srm_header) + vrl_length) ||
+   vrl_length < (DRM_HDCP_2_VRL_LENGTH_SIZE +
+ DRM_HDCP_2_DCP_SIG_SIZE)) {
+   DRM_ERROR("Invalid blob length or vrl length\n");
+   return -EINVAL;
+   }
+
+   /* Length of the all vrls combined */
+   vrl_length -= (DRM_HDCP_2_VRL_LENGTH_SIZE + DRM_HDCP_2_DCP_SIG_SIZE);
+   if (!vrl_length) {
+   DRM_ERROR("No vrl found\n");
+   return -EINVAL;
+   }
+
+   buf += DRM_HDCP_2_VRL_LENGTH_SIZE;
+   ksv_count = (*buf << 2) | DRM_HDCP_2_KSV_COUNT_2_LSBITS(*(buf + 1));
+   if (!ksv_count)
+   return 0;
+
+   kfree(hdcp->revocated_ksv_list);
+   hdcp->revocated_ksv_list = kzalloc(ksv_count * DRM_HDCP_KSV_LEN,
+  GFP_KERNEL);
+   if (!hdcp->revocated_ksv_list) {
+   DRM_ERROR("Out of Memory\n");
+   return -ENOMEM;
+   }
+
+   ksv_sz = ksv_count * DRM_HDCP_KSV_LEN;
+   buf += DRM_HDCP_2_NO_OF_DEV_PLUS_RESERVED_SZ;
+
+   DRM_DEBUG_KMS("Revoked KSVs: %d\n", ksv_count);
+   memcpy(hdcp->revocated_ksv_list, buf, ksv_sz);
+   hdcp->revocated_ksv_cnt = ksv_count;
+
+   return 0;
+}
+
 static void intel_hdcp_update_srm(struct intel_connector *intel_connector,
  u32 srm_blob_id)
 {
struct drm_connector *connector = _connector->base;
struct intel_hdcp *hdcp = _connector->hdcp;
struct drm_property_blob *blob;
+   u8 srm_id;
 
DRM_DEBUG_KMS("srm_blob_id %u\n", srm_blob_id);
 
@@ -2002,8 +2076,14 @@ static void intel_hdcp_update_srm(struct intel_connector 
*intel_connector,
if (!blob || !blob->data)
return;
 
-

[Intel-gfx] [PATCH 05/10] drm/i915: Add revocation check on HDCP1.4 Ksvs

2019-02-25 Thread Ramalingam C

KSV list revocated by DCP LLC is provided as SRM Blob to kernel.
Which is parsed and stored in intel_hdcp->revocated_ksv_list.

This patch adds the revocation check for BKSV and KSV_FIFO in HDCP1.4
authentication.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 67 ++-
 1 file changed, 59 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 4b12274d8987..7d007de984d7 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -273,6 +273,45 @@ u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port 
*intel_dig_port)
return -EINVAL;
 }
 
+static inline void intel_hdcp_print_ksv(u8 *ksv)
+{
+   DRM_DEBUG_KMS("\t%#04x, %#04x, %#04x, %#04x, %#04x\n", *ksv,
+ *(ksv + 1), *(ksv + 2), *(ksv + 3), *(ksv + 4));
+}
+
+/* Check if any of the KSV is revocated by DCP LLC through SRM table */
+static inline
+bool intel_hdcp_ksvs_revocated(struct intel_hdcp *hdcp, u8 *ksvs, u32 
ksv_count)
+{
+   u32 rev_ksv_cnt = hdcp->revocated_ksv_cnt;
+   u8 *rev_ksv_list = hdcp->revocated_ksv_list;
+   u32 cnt, i, j;
+
+   /* If the Revocated ksv list is empty */
+   if (!rev_ksv_cnt || !rev_ksv_list)
+   return false;
+
+   for  (cnt = 0; cnt < ksv_count; cnt++) {
+   rev_ksv_list = hdcp->revocated_ksv_list;
+   for (i = 0; i < rev_ksv_cnt; i++) {
+   for (j = 0; j < DRM_HDCP_KSV_LEN; j++)
+   if (*(ksvs + j) != *(rev_ksv_list + j)) {
+   break;
+   } else if (j == (DRM_HDCP_KSV_LEN - 1)) {
+   DRM_DEBUG_KMS("Revocated KSV is ");
+   intel_hdcp_print_ksv(ksvs);
+   return true;
+   }
+   /* Move the offset to next KSV in the revocated list */
+   rev_ksv_list += DRM_HDCP_KSV_LEN;
+   }
+
+   /* Iterate to next ksv_offset */
+   ksvs += DRM_HDCP_KSV_LEN;
+   }
+   return false;
+}
+
 static
 int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim,
@@ -490,9 +529,10 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port 
*intel_dig_port,
 
 /* Implements Part 2 of the HDCP authorization procedure */
 static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_hdcp *hdcp,
+  struct intel_digital_port *intel_dig_port)
 {
+   const struct intel_hdcp_shim *shim = hdcp->shim;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, tries = 3;
 
@@ -531,6 +571,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
if (ret)
goto err;
 
+   if (intel_hdcp_ksvs_revocated(hdcp, ksv_fifo, num_downstream)) {
+   DRM_ERROR("Revocated Ksv(s) in ksv_fifo\n");
+   return -EPERM;
+   }
+
/*
 * When V prime mismatches, DP Spec mandates re-read of
 * V prime atleast twice.
@@ -557,9 +602,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
 }
 
 /* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
 {
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   const struct intel_hdcp_shim *shim = hdcp->shim;
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
@@ -625,6 +672,11 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
if (ret < 0)
return ret;
 
+   if (intel_hdcp_ksvs_revocated(hdcp, bksv.shim, 1)) {
+   DRM_ERROR("BKSV is revocated\n");
+   return -EPERM;
+   }
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
 
@@ -698,7 +750,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
 */
 
if (repeater_present)
-   return intel_hdcp_auth_downstream(intel_dig_port, shim);
+   return intel_hdcp_auth_downstream(hdcp, intel_dig_port);
 
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
@@ -735,7 +787,6 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
 
 static int _intel_hdcp_enable(struct

[Intel-gfx] [PATCH 02/10] drm/i915: Attach content type property

2019-02-25 Thread Ramalingam C

Attaches the content type property for HDCP2.2 capable connectors.

Implements the update of content type from property and apply the
restriction on HDCP version selection.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 21 +++--
 drivers/gpu/drm/i915/intel_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_hdcp.c | 18 +++---
 3 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1355be8dec3b..ffe7759a3f3a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3499,7 +3499,8 @@ static void intel_enable_ddi(struct intel_encoder 
*encoder,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(to_intel_connector(conn_state->connector));
+   intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->cp_content_type);
 }
 
 static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3562,21 +3563,29 @@ static void intel_ddi_update_pipe_dp(struct 
intel_encoder *encoder,
intel_panel_update_backlight(encoder, crtc_state, conn_state);
 }
 
-static void intel_ddi_update_pipe(struct intel_encoder *encoder,
+static void intel_ddi_update_hdcp(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state,
  const struct drm_connector_state *conn_state)
 {
-   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
-   intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
-
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(to_intel_connector(conn_state->connector));
+   intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->cp_content_type);
else if (conn_state->content_protection ==
 DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
intel_hdcp_disable(to_intel_connector(conn_state->connector));
 }
 
+static void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
+{
+   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+   intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+
+   intel_ddi_update_hdcp(encoder, crtc_state, conn_state);
+}
+
 static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
 const struct intel_crtc_state 
*pipe_config,
 enum port port)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81ec73e4a083..04cff672aead 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2151,7 +2151,7 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
 struct drm_connector_state *new_state);
 int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim);
-int intel_hdcp_enable(struct intel_connector *connector);
+int intel_hdcp_enable(struct intel_connector *connector, u8 content_type);
 int intel_hdcp_disable(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 9ce09f67776d..ab25264a74a4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1782,6 +1782,12 @@ static void intel_hdcp2_init(struct intel_connector 
*connector)
return;
}
 
+   ret = drm_connector_attach_cp_content_type_property(>base);
+   if (ret) {
+   kfree(hdcp->port_data.streams);
+   return;
+   }
+
hdcp->hdcp2_supported = true;
 }
 
@@ -1811,7 +1817,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return 0;
 }
 
-int intel_hdcp_enable(struct intel_connector *connector)
+int intel_hdcp_enable(struct intel_connector *connector, u8 content_type)
 {
struct intel_hdcp *hdcp = >hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
@@ -1823,6 +1829,8 @@ int intel_hdcp_enable(struct intel_connector *connector)
mutex_lock(>mutex);
WARN_ON(hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
 
+   hdcp->content_type = content_type;
+
/*
 * Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
 * is capable of HDCP2.2, it is preferred to use HDCP2.2.
@@ -1833,8 +1841,12 @@ int

Re: [Intel-gfx] [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

2019-02-25 Thread kbuild test robot

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190225]
[cannot apply to v5.0-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/Propagate-DP-over-Type-C-hotplug-events-from-Type-C-subsys-to-drm-drivers/20190226-005334
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-m1-201908 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-5) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "drm_kms_call_oob_hotplug_notifier_chain" 
>> [drivers/usb/typec/altmodes/typec_displayport.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 00/10] HDCP2.2 Phase II

2019-02-25 Thread Ramalingam C

HDCP2.2 phase-II mojorly adds below features:
Addition of three connector properties
CP_Content_Type
CP_SRM
CP_Downstream_Info
parsing for HDCP1.4 and 2.2 SRM Blobs
Once HDCP1.4/2.2 authentication is completed gathering the all
downstream topology for userspace 
Extending debugfs entry to provide the HDCP2.2 capability too.

CP_Content_Type:
This property is used to indicate the content type
classification of a stream. Which indicate the HDCP version required
for the rendering of that streams. This conten type is one of the
parameter in the HDCP2.2 authentication flow, as even downstream
repeaters will mandate the HDCP version requirement.

Two values possible for content type of a stream:
Type 0: Stream can be rendered only on HDCP encrypted link no
restriction on HDCP versions.
Type 1: Stream can be rendered only on HDCP2.2 encrypted link.

There is a parallel effort in #wayland community to add the support for
HDCP2.2 along with content type support. Patches are under review in
#wayland community.

CP_SRM:
This blob property is used by the userspace to pass the SRM table
of HDCP1.4 and 2.2. These are nothing but revocated list of receiver IDs
of the HDCP sinks. KMD will use this list to identify the revocated
devices in the HDCP authentication and deny the hdcp encryption to it.

Work in progress to add the SRM support in the weston HDCP stack.
Yet to publish the patches in the #wayland community.

CP_Downstream_Info:
This blob property is used by the kernel to pass the downstream topology
of the HDCP encrypted port to the userspace.

This is used by the userspace to implement the HDCP repeater, which KMD
implementing the HDCP transmitters(downstream ports) and userspace
implementing the upstream port(HDCP receiver).

Discussion is on going to add the downstream_info support in the
weston HDCP stack.

Test-with: 1551165805-19130-2-git-send-email-ramalinga...@intel.com

Ramalingam C (10):
  drm: Add CP content type property
  drm/i915: Attach content type property
  drm: Add CP System Renewability Msg Property
  drm/i915: Add HDCP SRM Blob parsing
  drm/i915: Add revocation check on HDCP1.4 Ksvs
  drm/i915: SRM parsing and revocation check for HDCP2
  drm: Add CP downstream_info property
  drm/i915: Populate downstream info for HDCP1.4
  drm/i915: Populate downstream info for HDCP2.2
  drm/i915: debugfs: HDCP2.2 capability read

 drivers/gpu/drm/drm_atomic_uapi.c   |  23 +++
 drivers/gpu/drm/drm_connector.c | 204 
 drivers/gpu/drm/i915/i915_debugfs.c |  13 +-
 drivers/gpu/drm/i915/intel_ddi.c|  23 ++-
 drivers/gpu/drm/i915/intel_drv.h|  11 +-
 drivers/gpu/drm/i915/intel_hdcp.c   | 373 ++--
 include/drm/drm_connector.h |  40 
 include/drm/drm_hdcp.h  |  35 
 include/uapi/drm/drm_mode.h |  39 
 9 files changed, 737 insertions(+), 24 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 10/10] drm/i915: debugfs: HDCP2.2 capability read

2019-02-25 Thread Ramalingam C

Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"

This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_hdcp.c   |  2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 37175414ce89..b2fff7be7407 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4762,6 +4762,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file 
*m, void *data)
 {
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+   bool hdcp_cap, hdcp2_cap;
 
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -4772,8 +4773,16 @@ static int i915_hdcp_sink_capability_show(struct 
seq_file *m, void *data)
 
seq_printf(m, "%s:%d HDCP version: ", connector->name,
   connector->base.id);
-   seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
-  "None" : "HDCP1.4");
+   hdcp_cap = intel_hdcp_capable(intel_connector);
+   hdcp2_cap = intel_hdcp2_capable(intel_connector);
+
+   if (hdcp_cap)
+   seq_puts(m, "HDCP1.4 ");
+   if (hdcp2_cap)
+   seq_puts(m, "HDCP2.2 ");
+
+   if (!hdcp_cap && !hdcp2_cap)
+   seq_puts(m, "None");
seq_puts(m, "\n");
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c7ef7e71439d..fb055d688cdf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2163,6 +2163,7 @@ int intel_hdcp_enable(struct intel_connector *connector, 
u8 content_type,
 int intel_hdcp_disable(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
+bool intel_hdcp2_capable(struct intel_connector *connector);
 void intel_hdcp_component_init(struct drm_i915_private *dev_priv);
 void intel_hdcp_component_fini(struct drm_i915_private *dev_priv);
 void intel_hdcp_cleanup(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 8c05f382718c..29175ccddc92 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -76,7 +76,7 @@ bool intel_hdcp_capable(struct intel_connector *connector)
 }
 
 /* Is HDCP2.2 capable on Platform and Sink */
-static bool intel_hdcp2_capable(struct intel_connector *connector)
+bool intel_hdcp2_capable(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
-- 
2.7.4

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

[Intel-gfx] [PATCH 01/10] drm: Add CP content type property

2019-02-25 Thread Ramalingam C

This patch adds a DRM ENUM property to the selected connectors.
This property is used for pass the protected content's type
from userspace to kernel HDCP authentication.

Type of the stream is decided by the protected content providers as
Type 0/1.

Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.

So upon a content protection request with Type 1 as Content type from
userspace, Kernel will declare success only if the HDCP2.2
authentication is successful.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
 drivers/gpu/drm/drm_connector.c   | 64 +++
 include/drm/drm_connector.h   | 15 +
 include/uapi/drm/drm_mode.h   |  4 +++
 4 files changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4eb81f10bc54..5289486565ce 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,14 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->cp_content_type_property) {
+   if (state->content_protection !=
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED &&
+   state->cp_content_type != val) {
+   DRM_DEBUG_KMS("Disable CP, then change Type\n");
+   return -EINVAL;
+   }
+   state->cp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -822,6 +830,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
*val = state->content_protection;
+   } else if (property == connector->cp_content_type_property) {
+   *val = state->cp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 07d65a16c623..5d7738e1e977 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -853,6 +853,13 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] 
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
 };
 
+static struct drm_prop_enum_list drm_cp_content_type_enum_list[] = {
+   { DRM_MODE_CP_CONTENT_TYPE0, "Type 0" },
+   { DRM_MODE_CP_CONTENT_TYPE1, "Type 1" },
+};
+
+DRM_ENUM_NAME_FN(drm_get_cp_content_type_name, drm_cp_content_type_enum_list)
+
 /**
  * DOC: standard connector properties
  *
@@ -958,6 +965,25 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] 
= {
  *   the value transitions from ENABLED to DESIRED. This signifies the link
  *   is no longer protected and userspace should take appropriate action
  *   (whatever that might be).
+ * CP_Content_Type:
+ * This property is used by the userspace to configure the kernel with
+ * upcoming stream's content type. Content Type of a stream is decided by
+ * the owner of the stream, as Type 0 or Type 1.
+ *
+ * The value of the property can be one the below:
+ *   - DRM_MODE_CP_CONTENT_TYPE0 = 0
+ * Type 0 streams can be transmitted on a link which is encrypted
+ * with HDCP 1.4 or HDCP 2.2.
+ *   - DRM_MODE_CP_CONTENT_TYPE1 = 1
+ * Type 1 streams can be transmitted on a link which is encrypted
+ * only with HDCP2.2.
+ *
+ * Please note this content type is introduced at HDCP2.2 and used in its
+ * authentication process.
+ *
+ * Guideline for programming:
+ *   - Property state can be changed only when "Content Protection state is
+ * DRM_MODE_CONTENT_PROTECTION_UNDESIRED.
  *
  * max bpc:
  * This range property is used by userspace to limit the bit depth. When
@@ -1548,6 +1574,44 @@ int drm_connector_attach_content_protection_property(
 EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
 
 /**
+ * drm_connector_attach_cp_content_type_property - attach cp content type
+ * property
+ *
+ * @connector: connector to attach cp content type property on.
+ *
+ * This is used to add support for sending the protected content's stream type
+ * from userspace to kernel on selected connectors. Protected content provider
+ * will decide their type of their content and declare the same to kernel.
+ *
+ * This information will be used during the HDCP2.2 authentication.
+ *
+ * Content type will be set to _connector_state.cp_content_type.
+

[Intel-gfx] [PATCH 04/10] drm/i915: Add HDCP SRM Blob parsing

2019-02-25 Thread Ramalingam C

This patch adds a drm blob property to selected connectors.
And also adds capability to parse the new HDCP1.4 srm blob passed
through cp_srm_property.

The revocated KSV list and their counts are stored in
the intel_hdcp. This list should be used for revocation check
of BKSVs in first stage HDCP authentication and for revocation check of
ksv_fifo in second stage authentication.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_ddi.c  |   6 +-
 drivers/gpu/drm/i915/intel_drv.h  |   8 ++-
 drivers/gpu/drm/i915/intel_hdcp.c | 147 +-
 include/drm/drm_hdcp.h|  14 
 4 files changed, 170 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ffe7759a3f3a..1f935fe9c466 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3500,7 +3500,8 @@ static void intel_enable_ddi(struct intel_encoder 
*encoder,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- (u8)conn_state->cp_content_type);
+ (u8)conn_state->cp_content_type,
+ conn_state->cp_srm_blob_id);
 }
 
 static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3570,7 +3571,8 @@ static void intel_ddi_update_hdcp(struct intel_encoder 
*encoder,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- (u8)conn_state->cp_content_type);
+ (u8)conn_state->cp_content_type,
+ conn_state->cp_srm_blob_id);
else if (conn_state->content_protection ==
 DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
intel_hdcp_disable(to_intel_connector(conn_state->connector));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 04cff672aead..53a463d40f43 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,6 +482,11 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+   /* list of Revocated KSVs and their count from SRM blob Parsing */
+   unsigned int revocated_ksv_cnt;
+   u8 *revocated_ksv_list;
+   u32 srm_blob_id;
 };
 
 struct intel_connector {
@@ -2151,7 +2156,8 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
 struct drm_connector_state *new_state);
 int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim);
-int intel_hdcp_enable(struct intel_connector *connector, u8 content_type);
+int intel_hdcp_enable(struct intel_connector *connector, u8 content_type,
+ u32 srm_blob_id);
 int intel_hdcp_disable(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index ab25264a74a4..4b12274d8987 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1805,6 +1805,10 @@ int intel_hdcp_init(struct intel_connector *connector,
if (ret)
return ret;
 
+   ret = drm_connector_attach_cp_srm_property(>base);
+   if (ret)
+   return ret;
+
hdcp->shim = shim;
mutex_init(>mutex);
INIT_DELAYED_WORK(>check_work, intel_hdcp_check_work);
@@ -1817,7 +1821,144 @@ int intel_hdcp_init(struct intel_connector *connector,
return 0;
 }
 
-int intel_hdcp_enable(struct intel_connector *connector, u8 content_type)
+static u32 intel_hdcp_get_revocated_ksv_count(u8 *buf, u32 vrls_length)
+{
+   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+   do {
+   vrl_ksv_cnt = *buf;
+   ksv_count += vrl_ksv_cnt;
+
+   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+   buf += vrl_sz;
+   parsed_bytes += vrl_sz;
+   } while (parsed_bytes < vrls_length);
+
+   return ksv_count;
+}
+
+static u32 intel_hdcp_get_revocated_ksvs(u8 *ksv_list, const u8 *buf,
+u32 vrls_length)
+{
+   u32 parsed_bytes = 0, ksv_count = 0;
+   u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+   do {
+   vrl_ksv_cnt = *buf;
+   vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+   buf++;
+
+   DRM_DEBUG_KMS("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+   memcpy(ksv_list, buf, vrl_ksv_sz);
+   ksv_count +=

[Intel-gfx] [PATCH 03/10] drm: Add CP System Renewability Msg Property

2019-02-25 Thread Ramalingam C

This patch adds a drm blob property to the selected connector.
This property will be used to pass the SRM Blob ID from userspace
to kernel.

Revocated ksv list from SRM Table will be used by the kernel in the HDCP
authentication.

Kernel doesn't validate the incoming SRM table or store it in
non-volatile storage. So it is expected that userspace will provide the
latest valid SRM table on every power cycle before the HDCP
authentication starts.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 10 
 drivers/gpu/drm/drm_connector.c   | 52 +++
 include/drm/drm_connector.h   | 13 ++
 3 files changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 5289486565ce..9c57d8c07d09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -754,6 +754,14 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->cp_content_type = val;
+   } else if (property == connector->cp_srm_property) {
+   if (state->content_protection !=
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED &&
+   state->cp_srm_blob_id != val) {
+   DRM_DEBUG_KMS("Disable CP, then change SRM Blob\n");
+   return -EINVAL;
+   }
+   state->cp_srm_blob_id = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -832,6 +840,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->content_protection;
} else if (property == connector->cp_content_type_property) {
*val = state->cp_content_type;
+   } else if (property == connector->cp_srm_property) {
+   *val = state->cp_srm_blob_id;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5d7738e1e977..510941ad532f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -984,6 +984,24 @@ DRM_ENUM_NAME_FN(drm_get_cp_content_type_name, 
drm_cp_content_type_enum_list)
  * Guideline for programming:
  *   - Property state can be changed only when "Content Protection state is
  * DRM_MODE_CONTENT_PROTECTION_UNDESIRED.
+ * CP_SRM:
+ * This Blob property is used by the userspace to pass the revocated
+ * receiver ID list of HDCP 1.4 and/or 2.2 versions.
+ * In the HDCP authentication, Kernel uses this list to identify the HDCP
+ * sink which are revocated by the DCP LLC.
+ *
+ * Please note:
+ *   - Userspace is expected to validate the integrity of the SRM table
+ * through the DCP signatures.
+ *   - Userspace has to store the latest SRM securely in non-volatile
+ * storage.
+ *   - Kernel doesn't store or validate the incoming SRM tables. So on
+ * every power cycle, before every HDCP authentication, userspace is
+ * expected to pass the latest valid SRM to kernel.
+ *
+ * Guideline for programming:
+ *   - Property state can be changed only when "Content Protection state is
+ * DRM_MODE_CONTENT_PROTECTION_UNDESIRED.
  *
  * max bpc:
  * This range property is used by userspace to limit the bit depth. When
@@ -1612,6 +1630,40 @@ drm_connector_attach_cp_content_type_property(struct 
drm_connector *connector)
 EXPORT_SYMBOL(drm_connector_attach_cp_content_type_property);
 
 /**
+ * drm_connector_attach_cp_srm_property - attach cp srm
+ * property
+ *
+ * @connector: connector to attach cp srm property on.
+ *
+ * This is used to add support for sending the SRM table from userspace to
+ * kernel on selected connectors. Protected content provider will provide
+ * the system renewability Message(SRM) to userspace before requesting for
+ * HDCP on a port. Hence if a Port supports content protection (mostly HDCP)
+ * then this property will be attached to receive the SRM for revocation check
+ * of the ksvs.
+ *
+ * The srm blob id will be set to _connector_state.cp_srm_blob_id
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_cp_srm_property(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB, "CP_SRM", 0);
+   if (!prop)
+   return -ENOMEM;
+
+   drm_object_attach_property(>base, prop, 0);
+   connector->cp_srm_property = prop;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_cp_srm_property);
+
+/**
  *

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Tvrtko Ursulin



On 25/02/2019 18:40, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2019-02-25 17:59:40)


On 25/02/2019 16:23, Chris Wilson wrote:

   static inline struct i915_priolist *to_priolist(struct rb_node *rb)
   {
   return rb_entry(rb, struct i915_priolist, node);
@@ -2206,6 +2212,10 @@ static u32 *gen8_emit_fini_breadcrumb(struct 
i915_request *request, u32 *cs)
 request->fence.seqno,
 request->timeline->hwsp_offset);
   
+ cs = gen8_emit_ggtt_write(cs,

+   
intel_engine_next_hangcheck_seqno(request->engine),
+   intel_hws_hangcheck_address(request->engine));
+
   cs = gen8_emit_ggtt_write(cs,
 request->global_seqno,
 intel_hws_seqno_address(request->engine));
@@ -2230,6 +2240,11 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct 
i915_request *request, u32 *cs)
 PIPE_CONTROL_FLUSH_ENABLE |
 PIPE_CONTROL_CS_STALL);
   
+ cs = gen8_emit_ggtt_write_rcs(cs,

+   
intel_engine_next_hangcheck_seqno(request->engine),
+   
intel_hws_hangcheck_address(request->engine),
+   PIPE_CONTROL_CS_STALL);


Are CS_STALL needed on two writes or only last one would be enough? Or
even, should all flushes be moved to the last pipe control?


The CS_STALL is overkill as there's no requirement for it to be before
the global_seqno, but the convenience and ease to reason over win.


+
   cs = gen8_emit_ggtt_write_rcs(cs,
 request->global_seqno,
 intel_hws_seqno_address(request->engine),
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 7f841dba87b3..870184bbd169 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -43,6 +43,12 @@
*/
   #define LEGACY_REQUEST_SIZE 200
   
+static inline u32 hws_hangcheck_address(struct intel_engine_cs *engine)

+{
+ return (i915_ggtt_offset(engine->status_page.vma) +
+ I915_GEM_HWS_HANGCHECK_ADDR);
+}
+


You can consolidate by putting the previous copy in a header.


Inline spaghetti means it didn't go where I wanted and I purposely moved
these address computation to their users so that I can kill them off,
one by one. As is the plan even for the new hangcheck seqno.
  

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 5d45ad4ecca9..2869aaa9d225 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -6,6 +6,7 @@
   
   #include 

   #include 
+#include 
   #include 
   
   #include "i915_gem_batch_pool.h"

@@ -119,7 +120,8 @@ struct intel_instdone {
   
   struct intel_engine_hangcheck {

   u64 acthd;
- u32 seqno;
+ u32 last_seqno;
+ u32 next_seqno;


Reading the code I got the impression:

s/last_seqno/hangcheck_seqno/
s/next_seqno/last_seqno/

Could be closer to reality. But your choice.


hangcheck.last_seqno,
hangcheck.next_seqno

hangcheck.hangcheck_seqno? Nah.


Ok have at it.

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH v6 1/3] drm: Add CRTC background color property (v5)

2019-02-25 Thread Maarten Lankhorst

Hey,

Op 21-02-2019 om 01:28 schreef Matt Roper:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes).  Compositors that want a UI with
> a solid color background can potentially save memory bandwidth by
> setting the CRTC background property and using smaller planes to display
> the rest of the content.
>
> To avoid confusion between different ways of encoding RGB data, we
> define a standard 64-bit format that should be used for this property's
> value.  Helper functions and macros are provided to generate and dissect
> values in this standard format with varying component precision values.
>
> v2:
>  - Swap internal representation's blue and red bits to make it easier
>to read if printed out.  (Ville)
>  - Document bgcolor property in drm_blend.c.  (Sean Paul)
>  - s/background_color/bgcolor/ for consistency between property name and
>value storage field.  (Sean Paul)
>  - Add a convenience function to attach property to a given crtc.
>
> v3:
>  - Restructure ARGB component extraction macros to be easier to
>understand and enclose the parameters in () to avoid calculations
>if expressions are passed.  (Sean Paul)
>  - s/rgba/argb/ in helper function/macro names.  Even though the idea is
>to not worry about the internal representation of the u64, it can
>still be confusing to look at code that uses 'rgba' terminology, but
>stores values with argb ordering.  (Ville)
>
> v4:
>  - Drop the bgcolor_changed flag.  (Ville, Brian Starkey)
>  - Clarify in kerneldoc that background color is expected to undergo the
>same pipe-level degamma/csc/gamma transformations that planes do.
>(Brian Starkey)
>  - Update kerneldoc to indicate non-opaque colors are allowed, but are
>generally only useful in special cases such as when writeback
>connectors are used (Brian Starkey / Eric Anholt)
>
> v5:
>  - Set crtc->state->bgcolor to solid black inside
>drm_crtc_add_bgcolor_property() in case drivers don't do this
>themselves.  (Ville)
>  - Add kerneldoc to drm_crtc_add_bgcolor_property() function.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: wei.c...@intel.com
> Cc: harish.krupo@intel.com
> Cc: Ville Syrjälä 
> Cc: Sean Paul 
> Cc: Brian Starkey 
> Cc: Eric Anholt 
> Cc: Stéphane Marchesin 
> Cc: Daniel Vetter 
> Signed-off-by: Matt Roper 
> Reviewed-by(v2): Sean Paul 
> Reviewed-by: Brian Starkey 

I like how bgcolor is a u64 now, but there is an issue with setting 
crtc->state->bgcolor in attaching the property.

We should do it in atomic core init instead, like we already do for 
connector/plane properties..

See for example https://patchwork.freedesktop.org/series/52363/

This was specificallly for the background color proposal, but we probalby have 
to split out the non-trivial conversions of __drm_atomic_helper_crtc_reset.

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Polish DRAM information readout code

2019-02-25 Thread Patchwork

== Series Details ==

Series: Polish DRAM information readout code
URL   : https://patchwork.freedesktop.org/series/57213/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12301_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12301_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_mocs_settings@mocs-reset-bsd2:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_mocs_settings@mocs-settings-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109287] +2

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109312]

  * igt@i915_pm_rpm@basic-rte:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +5

  * igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840]

  * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking-fencing:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-hsw:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-glk:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-apl:  PASS -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl:  PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk:  PASS -> FAIL [fdo#103167] +2

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
- shard-iclb: PASS -> FAIL [fdo#103167] +5

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +8

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-pgflip-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_invalid_dotclock:
- shard-iclb: NOTRUN -> SKIP [fdo#109310]

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  PASS -> FAIL [fdo#108948]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-iclb: PASS -> FAIL [fdo#103166]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724]

  * igt@kms_psr@psr2_sprite_render:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]

  * igt@kms_vblank@pipe-a-ts-continuation-modeset-hang:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +5

  * igt@prime_vgem@fence-write-hang:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +11

  * igt@runner@aborted:
- shard-iclb: NOTRUN -> FAIL [fdo#109593]

  * igt@v3d_get_param@get-bad-param:
- shard-iclb: NOTRUN -> SKIP [fdo#109315]

  
 Possible fixes 

  * igt@i915_pm_rpm@gem-idle:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +6

  * igt@i915_pm_rpm@legacy-planes-dpms:
- shard-iclb: INCOMPLETE [fdo#108840] / [fdo#109369] -> PASS

  * igt@i915_suspend@sysfs-reader:
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS

  * igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-glk:  DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  FAIL [fdo#106510] / [fdo#108145] -> PASS

  * igt@kms_color@pipe-a-ctm-max:
- shard-apl:  FAIL [fdo#108147] -> PASS

  * igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-apl:  FAIL [fdo#103232] -> PASS +3

  * igt@kms_cursor_crc@cursor-size-change:
- shard-glk:  FAIL [fdo#103232] -> PASS

  *

Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

2019-02-25 Thread Alex Deucher

On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
 wrote:
>
> Quoting Dave Airlie (2019-02-25 12:24:48)
> > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
> >  wrote:
> > >
> > > + dri-devel mailing list, especially for the buddy allocator part
> > >
> > > Quoting Dave Airlie (2019-02-15 02:47:07)
> > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld  
> > > > wrote:
> > > > >
> > > > > In preparation for upcoming devices with device local memory, 
> > > > > introduce the
> > > > > concept of different memory regions, and a simple buddy allocator to 
> > > > > manage
> > > > > them.
> > > >
> > > > This is missing the information on why it's not TTM.
> > > >
> > > > Nothing against extending i915 gem off into doing stuff we already
> > > > have examples off in tree, but before you do that it would be good to
> > > > have a why we can't use TTM discussion in public.
> > >
> > > Glad that you asked. It's my fault that it was not included in
> > > the cover letter. I anticipated the question, but was travelling
> > > for a couple of days at the time this was sent. I didn't want
> > > to write a hasty explanation and then disappear, leaving others to
> > > take the heat.
> > >
> > > So here goes the less-hasty version:
> > >
> > > We did an analysis on the effort needed vs benefit gained of using
> > > TTM when this was started initially. The conclusion was that we
> > > already share the interesting bits of code through core DRM, really.
> > >
> > > Re-writing the memory handling to TTM would buy us more fine-grained
> > > locking. But it's more a trait of rewriting the memory handling with
> > > the information we have learned, than rewriting it to use TTM :)
> > >
> > > And further, we've been getting rid of struct_mutex at a steady phase
> > > in the past years, so we have a clear path to the fine-grained locking
> > > already in the not-so-distant future. With all this we did not see
> > > much gained from converting over, as the code sharing is already
> > > substantial.
> > >
> > > We also wanted to have the buddy allocator instead of a for loop making
> > > drm_mm allocations to make sure we can keep the memory fragmentation
> > > at bay. The intent is to move the buddy allocator to core DRM, to the
> > > benefit of all the drivers, if there is interest from community. It has
> > > been written as a strictly separate component with that in mind.
> > >
> > > And if you take the buddy allocator out of the patch set, the rest is
> > > mostly just vfuncing things up to be able to have different backing
> > > storages for objects. We took the opportunity to move over to the more
> > > valgrind friendly mmap while touching things, but it's something we
> > > have been contemplating anyway. And yeah, loads of selftests.
> > >
> > > That's really all that needed adding, and most of it is internal to
> > > i915 and not to do with uAPI. This means porting over an userspace
> > > driver doesn't require a substantial rewrite, but adding new a few
> > > new IOCTLs to set the preferred backing storage placements.
> > >
> > > All the previous GEM abstractions keep applying, so we did not see
> > > a justification to rewrite the kernel driver and userspace drivers.
> > > It would have just to made things look like TTM, when we already
> > > have the important parts of the code shared with TTM drivers
> > > behind the GEM interfaces which all our drivers sit on top of.
> >
> > a) you guys should be the community as well, if the buddy allocator is
> > useful in the core DRM get out there and try and see if anyone else
> > has a use case for it, like the GPU scheduler we have now (can i915
> > use that yet? :-)
>
> Well, the buddy allocator should be useful for anybody wishing to have
> as continuous physical allocations as possible. I have naively assumed
> that would be almost everyone. So it would be only a question if others
> see the amount of work required to convert over is justified for them.
>
> For the common DRM scheduler, I think a solid move from the beginning
> would have been to factor out the i915 scheduler as it was most advanced
> in features :) Now there is a way more trivial common scheduler core with
> no easy path to transition without a feature regression.

Can you elaborate?  What features are missing from the drm gpu scheduler?

>
> We'd have to rewrite many of the more advanced features for that codebase
> before we could transition over. It's hard to justify such work, for
> that it would buy us very little compared to amount of work.
>
> Situation would be different if there was something gained from
> switching over. This would be the situation if the more advanced
> scheduler was picked as the shared codebase.
>
> > b) however this last two paragraphs fill me with no confidence that
> > you've looked at TTM at all. It sounds like you took comments about
> > TTM made 10 years ago, and didn't update them. There should be no
> > major reason for a uapi change just because you adopt TTM. TTM hasn't
>

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Yet another if/else sort of newer to older platforms. (rev2)

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/i915: Yet another if/else sort of newer to older platforms. (rev2)
URL   : https://patchwork.freedesktop.org/series/57112/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12300_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12300_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-bsd1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +1

  * igt@gem_mocs_settings@mocs-reset-bsd2:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_mocs_settings@mocs-settings-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109287]

  * igt@i915_pm_rpm@fences:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +9

  * igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-iclb: PASS -> FAIL [fdo#103375] +2

  * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking-fencing:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-hsw:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-glk:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_color@pipe-a-degamma:
- shard-apl:  PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +2

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  PASS -> FAIL [fdo#105767]

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk:  PASS -> FAIL [fdo#103167] +2
- shard-apl:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-render:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +17

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +8

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-pgflip-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_invalid_dotclock:
- shard-iclb: NOTRUN -> SKIP [fdo#109310]

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-glk:  PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]

  * igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl:  PASS -> FAIL [fdo#103166] +2

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-iclb: PASS -> FAIL [fdo#103166] +1

  * igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-glk:  PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538]

  * igt@prime_vgem@fence-write-hang:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +8

  * igt@v3d_get_param@get-bad-param:
- shard-iclb: NOTRUN -> SKIP [fdo#109315]

  
 Possible fixes 

  * igt@i915_pm_rpm@gem-idle:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +6

  * igt@i915_pm_rpm@legacy-planes-dpms:
- shard-iclb: INCOMPLETE [fdo#108840] / [fdo#109369] -> PASS

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-snb:  DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  FAIL [fdo#106510] / [fdo#108145] -> PASS

  * igt@kms_color@pipe-a-ctm-max:
- shard-apl:  FAIL [fdo#108147] -> PASS

  * igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-apl:  FAIL [fdo#103232] -> PASS +3

  * igt@kms_cursor_crc@cursor-size-change:
- shard-glk:  FAIL [fdo#103232] -> PASS

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-iclb: FAIL [fdo#105363] -> PASS

  *

Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

2019-02-25 Thread Joonas Lahtinen

Quoting Dave Airlie (2019-02-25 12:24:48)
> On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
>  wrote:
> >
> > + dri-devel mailing list, especially for the buddy allocator part
> >
> > Quoting Dave Airlie (2019-02-15 02:47:07)
> > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld  wrote:
> > > >
> > > > In preparation for upcoming devices with device local memory, introduce 
> > > > the
> > > > concept of different memory regions, and a simple buddy allocator to 
> > > > manage
> > > > them.
> > >
> > > This is missing the information on why it's not TTM.
> > >
> > > Nothing against extending i915 gem off into doing stuff we already
> > > have examples off in tree, but before you do that it would be good to
> > > have a why we can't use TTM discussion in public.
> >
> > Glad that you asked. It's my fault that it was not included in
> > the cover letter. I anticipated the question, but was travelling
> > for a couple of days at the time this was sent. I didn't want
> > to write a hasty explanation and then disappear, leaving others to
> > take the heat.
> >
> > So here goes the less-hasty version:
> >
> > We did an analysis on the effort needed vs benefit gained of using
> > TTM when this was started initially. The conclusion was that we
> > already share the interesting bits of code through core DRM, really.
> >
> > Re-writing the memory handling to TTM would buy us more fine-grained
> > locking. But it's more a trait of rewriting the memory handling with
> > the information we have learned, than rewriting it to use TTM :)
> >
> > And further, we've been getting rid of struct_mutex at a steady phase
> > in the past years, so we have a clear path to the fine-grained locking
> > already in the not-so-distant future. With all this we did not see
> > much gained from converting over, as the code sharing is already
> > substantial.
> >
> > We also wanted to have the buddy allocator instead of a for loop making
> > drm_mm allocations to make sure we can keep the memory fragmentation
> > at bay. The intent is to move the buddy allocator to core DRM, to the
> > benefit of all the drivers, if there is interest from community. It has
> > been written as a strictly separate component with that in mind.
> >
> > And if you take the buddy allocator out of the patch set, the rest is
> > mostly just vfuncing things up to be able to have different backing
> > storages for objects. We took the opportunity to move over to the more
> > valgrind friendly mmap while touching things, but it's something we
> > have been contemplating anyway. And yeah, loads of selftests.
> >
> > That's really all that needed adding, and most of it is internal to
> > i915 and not to do with uAPI. This means porting over an userspace
> > driver doesn't require a substantial rewrite, but adding new a few
> > new IOCTLs to set the preferred backing storage placements.
> >
> > All the previous GEM abstractions keep applying, so we did not see
> > a justification to rewrite the kernel driver and userspace drivers.
> > It would have just to made things look like TTM, when we already
> > have the important parts of the code shared with TTM drivers
> > behind the GEM interfaces which all our drivers sit on top of.
> 
> a) you guys should be the community as well, if the buddy allocator is
> useful in the core DRM get out there and try and see if anyone else
> has a use case for it, like the GPU scheduler we have now (can i915
> use that yet? :-)

Well, the buddy allocator should be useful for anybody wishing to have
as continuous physical allocations as possible. I have naively assumed
that would be almost everyone. So it would be only a question if others
see the amount of work required to convert over is justified for them.

For the common DRM scheduler, I think a solid move from the beginning
would have been to factor out the i915 scheduler as it was most advanced
in features :) Now there is a way more trivial common scheduler core with
no easy path to transition without a feature regression.

We'd have to rewrite many of the more advanced features for that codebase
before we could transition over. It's hard to justify such work, for
that it would buy us very little compared to amount of work.

Situation would be different if there was something gained from
switching over. This would be the situation if the more advanced
scheduler was picked as the shared codebase.

> b) however this last two paragraphs fill me with no confidence that
> you've looked at TTM at all. It sounds like you took comments about
> TTM made 10 years ago, and didn't update them. There should be no
> major reason for a uapi change just because you adopt TTM. TTM hasn't
> ever had a common uapi across drivers upstream, one was proposed
> initially > 10 years ago.

This is one part my confusion on what the question was for and other
part bad wording on my behalf.

So an attempt to re-answer: When this effort was started it was obvious
that the amount of new code required was low (as you

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Infoframe precompute/check (rev7)

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/i915: Infoframe precompute/check (rev7)
URL   : https://patchwork.freedesktop.org/series/49983/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12299_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12299_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_big:
- shard-hsw:  PASS -> TIMEOUT [fdo#107937]

  * igt@gem_mocs_settings@mocs-reset-bsd2:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_mocs_settings@mocs-settings-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109287] +2

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109312]

  * igt@gem_workarounds@suspend-resume-fd:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]

  * igt@i915_pm_backlight@fade_with_dpms:
- shard-iclb: PASS -> INCOMPLETE [fdo#107820]

  * igt@i915_pm_rpm@fences:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3

  * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking-fencing:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-hsw:  PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-glk:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_color@pipe-a-degamma:
- shard-apl:  PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +5

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk:  PASS -> FAIL [fdo#103167] +2

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
- shard-iclb: PASS -> FAIL [fdo#103167] +7

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +8

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-pgflip-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_invalid_dotclock:
- shard-iclb: NOTRUN -> SKIP [fdo#109310]

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  PASS -> FAIL [fdo#108948] +1

  * igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-iclb: PASS -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724]

  * igt@kms_psr@no_drrs:
- shard-iclb: PASS -> FAIL [fdo#108341]

  * igt@kms_psr@psr2_sprite_render:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]

  * igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl:  PASS -> FAIL [fdo#109016]

  * igt@kms_vblank@pipe-a-ts-continuation-modeset-hang:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-hsw:  PASS -> FAIL [fdo#104894]

  * igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +5

  * igt@prime_vgem@fence-write-hang:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +8

  * igt@runner@aborted:
- shard-iclb: NOTRUN -> FAIL [fdo#108654]

  * igt@v3d_get_param@get-bad-param:
- shard-iclb: NOTRUN -> SKIP [fdo#109315]

  
 Possible fixes 

  * igt@i915_pm_rpm@legacy-planes-dpms:
- shard-iclb: INCOMPLETE [fdo#108840] / [fdo#109369] -> PASS

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +4

  * igt@i915_suspend@sysfs-reader:
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS

  * igt@kms_color@pipe-a-ctm-max:
- shard-apl:  FAIL [fdo#108147] -> PASS

  * igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-apl:  FAIL [fdo#103232] -> PASS +3

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-apl:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: extract AUX mask assignment to separate function (rev2)

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/i915: extract AUX mask assignment to separate function (rev2)
URL   : https://patchwork.freedesktop.org/series/57119/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12302


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57119/revisions/2/mbox/

Known issues


  Here are the changes found in Patchwork_12302 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   PASS -> DMESG-WARN [fdo#107709]

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  PASS -> FAIL [fdo#103167]

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> FAIL [fdo#107709]

  
 Possible fixes 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  
 Warnings 

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569]

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


Build changes
-

* Linux: CI_DRM_5659 -> Patchwork_12302

  CI_DRM_5659: bffea990c63087245e8501df82fd45f24ce6ad1f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12302: 168ece6d7ac9a2a64f3e2332b1ea4f49feeace65 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

168ece6d7ac9 drm/i915: extract AUX mask assignment to separate function

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Patchwork

== Series Details ==

Series: series starting with [1/4] drm/i915: Replace global_seqno with a 
hangcheck heartbeat seqno
URL   : https://patchwork.freedesktop.org/series/57203/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12298_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12298_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@reset-stress:
- shard-snb:  PASS -> FAIL [fdo#109661]

  * igt@gem_mocs_settings@mocs-reset-bsd2:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_mocs_settings@mocs-settings-vebox:
- shard-iclb: NOTRUN -> SKIP [fdo#109287] +2

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109312]

  * igt@i915_pm_rpm@cursor-dpms:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1

  * igt@i915_pm_rpm@gem-mmap-gtt:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +38

  * igt@i915_pm_rpm@modeset-lpsp:
- shard-iclb: PASS -> INCOMPLETE [fdo#108840]

  * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-glk:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_crc@cursor-128x128-random:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl:  PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_cursor_crc@cursor-512x512-random:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +3

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw:  PASS -> FAIL [fdo#105767]

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  PASS -> FAIL [fdo#105363]

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-render:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +17

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
- shard-iclb: PASS -> FAIL [fdo#103167] +4

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-onoff:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +8

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-pgflip-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_invalid_dotclock:
- shard-iclb: NOTRUN -> SKIP [fdo#109310]

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-glk:  PASS -> FAIL [fdo#108948] +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-iclb: PASS -> FAIL [fdo#103166] +2

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724]

  * igt@kms_psr@psr2_sprite_render:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]

  * igt@kms_sysfs_edid_timing:
- shard-iclb: PASS -> FAIL [fdo#100047]

  * igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +5

  * igt@v3d_get_param@get-bad-param:
- shard-iclb: NOTRUN -> SKIP [fdo#109315]

  
 Possible fixes 

  * igt@i915_pm_rpm@gem-idle:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +5

  * igt@i915_pm_rpm@legacy-planes-dpms:
- shard-iclb: INCOMPLETE [fdo#108840] / [fdo#109369] -> PASS

  * igt@i915_suspend@sysfs-reader:
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-kbl:  DMESG-WARN [fdo#107956] -> PASS +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-hsw:  DMESG-WARN [fdo#107956] -> PASS +1
- shard-iclb: DMESG-WARN [fdo#107956] -> PASS +1

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-snb:  DMESG-WARN [fdo#107956] -> PASS +1

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  FAIL [fdo#106510] / [fdo#108145] -> PASS

  * igt@kms_color@pipe-a-ctm-max:
- shard-apl:  FAIL [fdo#108147] -> PASS

  *

[Intel-gfx] [PATCH v2] drm/i915: extract AUX mask assignment to separate function

2019-02-25 Thread Lucas De Marchi

No change in behavior, this only allows to more easily follow the flow
of gen8_de_irq_handler without the mask assignments for each platform.
This also re-organizes the branches a little bit, so the one-off case
for CNL_WITH_PORT_F is separate from the generic gen >= 11.

v2: rename de_port_iir_aux_mask -> gen8_de_port_aux_mask (Ville)

Signed-off-by: Lucas De Marchi 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Jose Souza 
---
 drivers/gpu/drm/i915/i915_irq.c | 34 +++--
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7c7e84e86c6a..a42eb6394b69 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2676,6 +2676,25 @@ static void gen11_hpd_irq_handler(struct 
drm_i915_private *dev_priv, u32 iir)
DRM_ERROR("Unexpected DE HPD interrupt 0x%08x\n", iir);
 }
 
+static u32 gen8_de_port_aux_mask(struct drm_i915_private *dev_priv)
+{
+   u32 mask = GEN8_AUX_CHANNEL_A;
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   mask |= GEN9_AUX_CHANNEL_B |
+   GEN9_AUX_CHANNEL_C |
+   GEN9_AUX_CHANNEL_D;
+
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   mask |= CNL_AUX_CHANNEL_F;
+
+   if (INTEL_GEN(dev_priv) >= 11)
+   mask |= ICL_AUX_CHANNEL_E |
+   CNL_AUX_CHANNEL_F;
+
+   return mask;
+}
+
 static irqreturn_t
 gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
 {
@@ -2731,20 +2750,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
I915_WRITE(GEN8_DE_PORT_IIR, iir);
ret = IRQ_HANDLED;
 
-   tmp_mask = GEN8_AUX_CHANNEL_A;
-   if (INTEL_GEN(dev_priv) >= 9)
-   tmp_mask |= GEN9_AUX_CHANNEL_B |
-   GEN9_AUX_CHANNEL_C |
-   GEN9_AUX_CHANNEL_D;
-
-   if (INTEL_GEN(dev_priv) >= 11)
-   tmp_mask |= ICL_AUX_CHANNEL_E;
-
-   if (IS_CNL_WITH_PORT_F(dev_priv) ||
-   INTEL_GEN(dev_priv) >= 11)
-   tmp_mask |= CNL_AUX_CHANNEL_F;
-
-   if (iir & tmp_mask) {
+   if (iir & gen8_de_port_aux_mask(dev_priv)) {
dp_aux_irq_handler(dev_priv);
found = true;
}
-- 
2.21.0

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: move MG pll hw_state readout

2019-02-25 Thread Lucas De Marchi


On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:

On Fri, Feb 22, 2019 at 03:23:22PM -0800, Lucas De Marchi wrote:

Let the MG plls have their own hooks since it shares very little with
other PLL types. It's also better so the platform info contains the info
if the PLL is for MG PHY rather than relying on the PLL ids.

Signed-off-by: Lucas De Marchi 


There's quite a bit more cleanup to be done in this area. As a start
https://patchwork.freedesktop.org/series/56354/ ;)


I started reviewing that and even gave my r-b in some patches - first
patches cause several conflicts with in-flight patches though. Not sure
how beneficial they are. IMO last 3 patches could be standalone
(particularly the one that is a bug fix, and doesn't depend on the
previous ones)


This patch looks good to me. It'll conflict with my series though, but
no biggie.
Reviewed-by: Ville Syrjälä 


thanks
Lucas De Marchi




---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 122 --
 1 file changed, 74 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 0a42d11c4c33..e4ec73d415d9 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2966,6 +2966,68 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum 
intel_dpll_id id)
return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
 }

+static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
+   struct intel_shared_dpll *pll,
+   struct intel_dpll_hw_state *hw_state)
+{
+   const enum intel_dpll_id id = pll->info->id;
+   enum tc_port tc_port = icl_pll_id_to_tc_port(id);
+   intel_wakeref_t wakeref;
+   bool ret = false;
+   u32 val;
+
+   wakeref = intel_display_power_get_if_enabled(dev_priv,
+POWER_DOMAIN_PLLS);
+   if (!wakeref)
+   return false;
+
+   val = I915_READ(MG_PLL_ENABLE(tc_port));
+   if (!(val & PLL_ENABLE))
+   goto out;
+
+   hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(tc_port));
+   hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
+
+   hw_state->mg_clktop2_coreclkctl1 =
+   I915_READ(MG_CLKTOP2_CORECLKCTL1(tc_port));
+   hw_state->mg_clktop2_coreclkctl1 &=
+   MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
+
+   hw_state->mg_clktop2_hsclkctl =
+   I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
+   hw_state->mg_clktop2_hsclkctl &=
+   MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
+   MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
+   MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK |
+   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK;
+
+   hw_state->mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
+   hw_state->mg_pll_div1 = I915_READ(MG_PLL_DIV1(tc_port));
+   hw_state->mg_pll_lf = I915_READ(MG_PLL_LF(tc_port));
+   hw_state->mg_pll_frac_lock = I915_READ(MG_PLL_FRAC_LOCK(tc_port));
+   hw_state->mg_pll_ssc = I915_READ(MG_PLL_SSC(tc_port));
+
+   hw_state->mg_pll_bias = I915_READ(MG_PLL_BIAS(tc_port));
+   hw_state->mg_pll_tdc_coldst_bias =
+   I915_READ(MG_PLL_TDC_COLDST_BIAS(tc_port));
+
+   if (dev_priv->cdclk.hw.ref == 38400) {
+   hw_state->mg_pll_tdc_coldst_bias_mask = 
MG_PLL_TDC_COLDST_COLDSTART;
+   hw_state->mg_pll_bias_mask = 0;
+   } else {
+   hw_state->mg_pll_tdc_coldst_bias_mask = -1U;
+   hw_state->mg_pll_bias_mask = -1U;
+   }
+
+   hw_state->mg_pll_tdc_coldst_bias &= 
hw_state->mg_pll_tdc_coldst_bias_mask;
+   hw_state->mg_pll_bias &= hw_state->mg_pll_bias_mask;
+
+   ret = true;
+out:
+   intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS, wakeref);
+   return ret;
+}
+
 static bool icl_pll_get_hw_state(struct drm_i915_private *dev_priv,
 struct intel_shared_dpll *pll,
 struct intel_dpll_hw_state *hw_state)
@@ -2984,50 +3046,8 @@ static bool icl_pll_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!(val & PLL_ENABLE))
goto out;

-   if (intel_dpll_is_combophy(id) ||
-   id == DPLL_ID_ICL_TBTPLL) {
-   hw_state->cfgcr0 = I915_READ(ICL_DPLL_CFGCR0(id));
-   hw_state->cfgcr1 = I915_READ(ICL_DPLL_CFGCR1(id));
-   } else {
-   enum tc_port tc_port = icl_pll_id_to_tc_port(id);
-
-   hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(tc_port));
-   hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
-
-   hw_state->mg_clktop2_coreclkctl1 =
-   I915_READ(MG_CLKTOP2_CORECLKCTL1(tc_port));
-   hw_state->mg_clktop2_coreclkctl1 &=
-   MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
-
-

Re: [Intel-gfx] [PATCH 1/2] drm/i915: remove unused bits from Panel Power Sequence State

2019-02-25 Thread Lucas De Marchi


On Mon, Feb 25, 2019 at 09:28:06PM +0200, Ville Syrjälä wrote:

On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:

No change in behavior. Just removing the unused bits since it makes it
easier to compare them on new platforms and one of them was wrong
(PP_SEQUENCE_STATE_ON_S1_0 vs the supposedly correct name
PP_SEQUENCE_STATE_ON_S1_1)

Cc: Rodrigo Vivi 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_reg.h | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 730bb1917fd1..e855dae978db 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4717,15 +4717,9 @@ enum {
 #define   PP_SEQUENCE_SHIFT28
 #define   PP_CYCLE_DELAY_ACTIVE(1 << 27)
 #define   PP_SEQUENCE_STATE_MASK   0x000f
-#define   PP_SEQUENCE_STATE_OFF_IDLE   (0x0 << 0)
-#define   PP_SEQUENCE_STATE_OFF_S0_1   (0x1 << 0)
-#define   PP_SEQUENCE_STATE_OFF_S0_2   (0x2 << 0)
-#define   PP_SEQUENCE_STATE_OFF_S0_3   (0x3 << 0)
-#define   PP_SEQUENCE_STATE_ON_IDLE(0x8 << 0)
-#define   PP_SEQUENCE_STATE_ON_S1_0(0x9 << 0)
-#define   PP_SEQUENCE_STATE_ON_S1_2(0xa << 0)
-#define   PP_SEQUENCE_STATE_ON_S1_3(0xb << 0)
-#define   PP_SEQUENCE_STATE_RESET  (0xf << 0)
+#define   PP_SEQUENCE_STATE_OFF_IDLE   0x0
+#define   PP_SEQUENCE_STATE_ON_IDLE0x8
+#define   PP_SEQUENCE_STATE_RESET  0xf


But how am I supposed to remember what the register values mean?


We only care for a small subset of those and the name should already be
enough, no? We don't need to bring in all the possible bits from spec,
even worse when they are misnamed. If we keep defining what we don't use
it actually makes our life harder to crosscheck with the spec if
everything is correct. Makes sense?

Lucas De Marchi





 #define _PP_CONTROL0x61204
 #define PP_CONTROL(pps_idx)_MMIO_PPS(pps_idx, _PP_CONTROL)
--
2.20.0

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


--
Ville Syrjälä
Intel

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Disable PSR2 while getting pipe CRC

2019-02-25 Thread Souza, Jose

On Fri, 2019-02-22 at 22:14 -0800, Dhinakaran Pandiyan wrote:
> On Sat, 2019-02-23 at 02:48 +, Souza, Jose wrote:
> > On Fri, 2019-02-22 at 18:13 -0800, Dhinakaran Pandiyan wrote:
> > > On Wed, 2019-02-13 at 18:02 -0800, José Roberto de Souza wrote:
> > > > As stated in CRC_CTL spec, after PSR entry state CRC will not
> > > > be
> > > > calculated anymore what is not a problem as IGT tests do some
> > > > screen
> > > > change and then request the pipe CRC right after the change so
> > > > PSR
> > > > will go to idle state and only will entry again after at least
> > > > 6
> > > > idles frames.
> > > > 
> > > > But for PSR2 it is more problematic as any change to the screen
> > > > could
> > > > trigger a selective/partial update causing the CRC value not to
> > > > be
> > > > calculated over the full frame.
> > > > 
> > > > So here it disables PSR2 and keep it disabled while user is
> > > > requesting pipe CRC.
> > > > 
> > > > BSpec: 7536
> > > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > > >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> > > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 10 ++
> > > >  drivers/gpu/drm/i915/intel_psr.c  | 23
> > > > +++
> > > >  4 files changed, 35 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 17fe942eaafa..609e9c5bd453 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -520,6 +520,7 @@ struct i915_psr {
> > > > bool sink_not_reliable;
> > > > bool irq_aux_error;
> > > > u16 su_x_granularity;
> > > > +   bool pipe_crc_enabled;
> > > >  };
> > > >  
> > > >  enum intel_pch {
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 3398b28c053b..40ce7a600585 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -2103,6 +2103,7 @@ void intel_psr_short_pulse(struct
> > > > intel_dp
> > > > *intel_dp);
> > > >  int intel_psr_wait_for_idle(const struct intel_crtc_state
> > > > *new_crtc_state,
> > > > u32 *out_value);
> > > >  bool intel_psr_enabled(struct intel_dp *intel_dp);
> > > > +void intel_psr_crc_prepare_or_finish(struct drm_i915_private
> > > > *dev_priv, enum pipe pipe, bool prepare);
> > > >  
> > > >  /* intel_quirks.c */
> > > >  void intel_init_quirks(struct drm_i915_private *dev_priv);
> > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > index a8554dc4f196..5d8772399f60 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > @@ -583,6 +583,14 @@ int intel_crtc_verify_crc_source(struct
> > > > drm_crtc
> > > > *crtc, const char *source_name,
> > > > return -EINVAL;
> > > >  }
> > > >  
> > > > +static inline void intel_crtc_crc_prepare_or_finish(struct
> > > > drm_crtc
> > > > *crtc, bool prepare)
> > > > +{
> > > > +   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > > > +   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > > +
> > > > +   intel_psr_crc_prepare_or_finish(dev_priv, intel_crtc-
> > > > >pipe,
> > > > prepare);
> > > > +}
> > > > +
> > > >  int intel_crtc_set_crc_source(struct drm_crtc *crtc, const
> > > > char
> > > > *source_name)
> > > >  {
> > > > struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > > > @@ -609,6 +617,8 @@ int intel_crtc_set_crc_source(struct
> > > > drm_crtc
> > > > *crtc, const char *source_name)
> > > > if (ret != 0)
> > > > goto out;
> > > >  
> > > > +   intel_crtc_crc_prepare_or_finish(crtc, source !=
> > > > INTEL_PIPE_CRC_SOURCE_NONE);
> > > > +
> > > > pipe_crc->source = source;
> > > > I915_WRITE(PIPE_CRC_CTL(crtc->index), val);
> > > > POSTING_READ(PIPE_CRC_CTL(crtc->index));
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 08967836b48e..9c93138988aa 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -577,6 +577,9 @@ static bool intel_psr2_config_valid(struct
> > > > intel_dp *intel_dp,
> > > > return false;
> > > > }
> > > >  
> > > > +   if (dev_priv->psr.pipe_crc_enabled)
> > > > +   return false;
> > > > +
> > > 
> > > Disabling PSR instead of switching to PSR1 is safer considering
> > > the
> > > past bug reports with PSR1.
> > 
> > I thought about that but it would break every PSR subtest in
> > kms_frontbuffer_tracking, I guess is better start by disabling PSR2
> > and
> > then discuss about PSR1 if decided to disable, we need to remove
> > PSR1
> >

Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: decouple dpll ids from type

2019-02-25 Thread Lucas De Marchi


On Mon, Feb 25, 2019 at 10:45:34PM +0200, Ville Syrjälä wrote:

On Fri, Feb 22, 2019 at 03:23:24PM -0800, Lucas De Marchi wrote:

Use the first 3 bits of dpll_info.platform_flags to mark the type of the
PLL instead of relying on the IDs. This is more future proof for
allowing the same set of functions to be reused, even if the IDs change.

The warning about PLL id not corresponding to a combo phy in intel_display
was removed as I don't think it should ever trigger.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_display.c  |  3 --
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 54 +--
 drivers/gpu/drm/i915/intel_dpll_mgr.h |  1 -
 3 files changed, 35 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b1d63c32ca94..a2be35118dd5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9592,9 +9592,6 @@ static void icelake_get_ddi_pll(struct drm_i915_private 
*dev_priv,
temp = I915_READ(DPCLKA_CFGCR0_ICL) &
   DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
-
-   if (WARN_ON(!intel_dpll_is_combophy(id)))
-   return;
} else if (intel_port_is_tc(dev_priv, port)) {
id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv, port));
} else {
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index e4ec73d415d9..cdb4463bab5d 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2639,6 +2639,13 @@ int icl_calc_dp_combo_pll_link(struct drm_i915_private 
*dev_priv,
return link_clock;
 }

+enum icl_dpll_flags {
+   ICL_DPLL_TYPE_COMBOPHY,
+   ICL_DPLL_TYPE_TBT,
+   ICL_DPLL_TYPE_MG,
+   _ICL_DPLL_TYPE_MASK = 0x7,
+};
+
 static enum tc_port icl_pll_id_to_tc_port(enum intel_dpll_id id)
 {
return id - DPLL_ID_ICL_MGPLL1;
@@ -2649,9 +2656,9 @@ enum intel_dpll_id icl_tc_port_to_pll_id(enum tc_port 
tc_port)
return tc_port + DPLL_ID_ICL_MGPLL1;
 }

-bool intel_dpll_is_combophy(enum intel_dpll_id id)
+static enum icl_dpll_flags icl_dpll_type(const struct dpll_info *info)
 {
-   return id == DPLL_ID_ICL_DPLL0 || id == DPLL_ID_ICL_DPLL1;
+   return info->platform_flags & _ICL_DPLL_TYPE_MASK;
 }

 static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool use_ssc,
@@ -2956,14 +2963,22 @@ icl_get_dpll(struct intel_crtc *crtc, struct 
intel_crtc_state *crtc_state,
return pll;
 }

-static i915_reg_t icl_pll_id_to_enable_reg(enum intel_dpll_id id)
+static i915_reg_t
+icl_pll_info_to_enable_reg(const struct dpll_info *info)
 {
-   if (intel_dpll_is_combophy(id))
-   return CNL_DPLL_ENABLE(id);
-   else if (id == DPLL_ID_ICL_TBTPLL)
-   return TBT_PLL_ENABLE;
+   enum icl_dpll_flags type = icl_dpll_type(info);

-   return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
+   switch (type) {
+   case ICL_DPLL_TYPE_COMBOPHY:
+   return CNL_DPLL_ENABLE(info->id);
+   case ICL_DPLL_TYPE_TBT:
+   return TBT_PLL_ENABLE;
+   case ICL_DPLL_TYPE_MG:
+   return MG_PLL_ENABLE(icl_pll_id_to_tc_port(info->id));
+   default:
+   MISSING_CASE(type);
+   return CNL_DPLL_ENABLE(info->id);
+   }
 }


This seems a rather roundabout way of doing things when we already have
the vfuncs.

How about just:

mg_pll_enable()
{
icl_pll_enable(MG_REG);
}

combo_pll_enable()
{
icl_pll_enable(COMBO_REG);
}

or something along those lines.


humn... I thought about this approach as an intermediate step to the
full blown "add another vfunc struct and pass that instead".  Platforms
are free to use this for small differences that don't justify going that
route.

In your approach you go the route of "always use vfunc and add
additional arguments to the common function".
Compared to the approach here, it's not subjective on what to do in
similar cases, but has its downsides as well.

1) The function can't be inlined so there's and extra hop when calling
the vfunc
2) if the callee is inlined we basically duplicate .text, but I doubt
any compiler would do that
3) reg as the argument is probably not a good choice as it may change
in the next platform - so we would need to add a "type" nonetheless

Since flags is already there and under-utilized I don't see much
advantage on the vfunc-only approach. I'm not strongly opposed though:
IMO both are better than the current state.

Lucas De Marchi






 static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
@@ -3042,7 +3057,7 @@ static bool icl_pll_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!wakeref)
return false;

-   val = I915_READ(icl_pll_id_to_enable_reg(id));
+   val =

[Intel-gfx] ✓ Fi.CI.BAT: success for Polish DRAM information readout code

2019-02-25 Thread Patchwork

== Series Details ==

Series: Polish DRAM information readout code
URL   : https://patchwork.freedesktop.org/series/57213/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12301


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57213/revisions/1/mbox/

Known issues


  Here are the changes found in Patchwork_12301 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   PASS -> SKIP [fdo#109271]

  * igt@i915_pm_rpm@basic-rte:
- fi-bsw-kefka:   PASS -> FAIL [fdo#108800]

  * igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 


Build changes
-

* Linux: CI_DRM_5659 -> Patchwork_12301

  CI_DRM_5659: bffea990c63087245e8501df82fd45f24ce6ad1f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12301: 51c5b331412de5a26f602d5bbc2936b5480398c3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

51c5b331412d drm/i915: Read out memory type
e72b3d3ce155 drm/i915: Extract DIMM info on cnl+
c01f3a66c0bb drm/i915: Clean up intel_get_dram_info() a bit
24b522fc37d6 drm/i914: s/l_info/dimm_l/ etc.
922fbda7b9af drm/i915: Generalize intel_is_dram_symmetric()
b73f574462db drm/i915: Use dram_dimm_info more
3472026fb73d drm/i915: Extract DIMM info on GLK too
b7ce42c317b8 drm/i915: Fix DRAM size reporting for BXT
22d9a7332e2c drm/i915: Extract BXT DIMM helpers
bafd36480e66 drm/i915: Polish skl_is_16gb_dimm()
6000a48eb1cf drm/i915: Extract functions to derive SKL+ DIMM info
00f769077034 drm/i915: Store DIMM rank information as a number

== Logs ==

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

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Fix DRAM size reporting for BXT

2019-02-25 Thread Ville Syrjälä

On Mon, Feb 25, 2019 at 08:57:45PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2019-02-25 20:48:10)
> > On Mon, Feb 25, 2019 at 08:35:08PM +, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2019-02-25 20:29:00)
> > > > From: Ville Syrjälä 
> > > > 
> > > > The BXT DUNIT register tells us the size of each DRAM device
> > > > in Gb. We want to report the size of the whole DIMM in GB, so
> > > > that it matches how we report it for non-LP platforms.
> > > > 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.c | 9 -
> > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 1f4a966a9727..c40a738dabd3 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -1322,7 +1322,14 @@ bxt_get_dram_info(struct drm_i915_private 
> > > > *dev_priv)
> > > > width = bxt_get_dimm_width(val);
> > > > ranks = bxt_get_dimm_ranks(val);
> > > >  
> > > > -   DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, 
> > > > ranks:%d\n",
> > > > +   /*
> > > > +* Size in register is Gb per DRAM device.
> > > > +* Convert to total GB to match the way
> > > > +* we report this for non-LP platforms.
> > > > +*/
> > > > +   size = size * ranks * 8 / (width ?: 1);
> > > 
> > > Should it be /8 for Gbits to GBytes?
> > 
> > It's a hand optimized version of
> > 
> > size*ranks*64 / width / 8
> 
> Maybe let the compiler handle the constants, otherwise every time I see
> this I'll think it's backwards ;)
> 
> Maybe be even
> size *= 64 * ranks / (width ?: 1);
> 
> /*
>  * Size in register is Gb per DRAM device.
>  * Convert to total GB to match the way
>  * we report this for non-LP platforms.
>  */
> size /= 8;

I suppose clarity is better here. I'll have to double check
the types though.

There's the opposite calculation in is_16gb_dimm(). I suppose
that should get the same treatment.

Hmm. Maybe I should even extract something like:
intel_dimm_num_devices() {
return 64 * ranks / width;
}
and use that everywhere.

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Polish DRAM information readout code

2019-02-25 Thread Patchwork

== Series Details ==

Series: Polish DRAM information readout code
URL   : https://patchwork.freedesktop.org/series/57213/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Store DIMM rank information as a number
-O:drivers/gpu/drm/i915/i915_drv.c:1192:35: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/i915_drv.c:1192:35: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_drv.c:1187:36: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/i915_drv.c:1187:36: warning: expression using sizeof(void)
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3581:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Extract functions to derive SKL+ DIMM info
Okay!

Commit: drm/i915: Polish skl_is_16gb_dimm()
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3578:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Extract BXT DIMM helpers
Okay!

Commit: drm/i915: Fix DRAM size reporting for BXT
Okay!

Commit: drm/i915: Extract DIMM info on GLK too
Okay!

Commit: drm/i915: Use dram_dimm_info more
Okay!

Commit: drm/i915: Generalize intel_is_dram_symmetric()
Okay!

Commit: drm/i914: s/l_info/dimm_l/ etc.
Okay!

Commit: drm/i915: Clean up intel_get_dram_info() a bit
Okay!

Commit: drm/i915: Extract DIMM info on cnl+
Okay!

Commit: drm/i915: Read out memory type
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3578:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3585:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/tinydrm: Remove tinydrm_device

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/tinydrm: Remove tinydrm_device
URL   : https://patchwork.freedesktop.org/series/57197/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5658_full -> Patchwork_12297_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12297_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@preemptive-hang-bsd2:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] +32

  * igt@i915_pm_rpm@i2c:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +2

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]

  * igt@kms_busy@basic-modeset-e:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-snb:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl:  PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_cursor_crc@cursor-512x512-random:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +2

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl:  PASS -> DMESG-WARN [fdo#108566]

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw:  PASS -> FAIL [fdo#105767]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-iclb: PASS -> FAIL [fdo#105363]

  * igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +11

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: PASS -> FAIL [fdo#103167]

  * igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl:  PASS -> FAIL [fdo#103166]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-none:
- shard-iclb: PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk:  PASS -> FAIL [fdo#103166]

  * igt@kms_setmode@basic:
- shard-kbl:  PASS -> FAIL [fdo#99912]

  * igt@perf_pmu@busy-check-all-vecs0:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +35

  
 Possible fixes 

  * igt@i915_pm_rpm@cursor-dpms:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +2

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  FAIL [fdo#106510] / [fdo#108145] -> PASS

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  FAIL [fdo#104873] -> PASS

  * igt@kms_cursor_legacy@pipe-c-torture-bo:
- shard-hsw:  DMESG-WARN [fdo#107122] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-apl:  FAIL [fdo#103167] -> PASS +1

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk:  FAIL [fdo#103167] -> PASS +3

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: FAIL [fdo#103167] -> PASS +2

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-apl:  FAIL [fdo#108948] -> PASS

  * igt@tools_test@tools_test:
- shard-iclb: SKIP [fdo#109352] -> PASS

  
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
  [fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
  [fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109352]: https://bugs.freedesktop.org/show_bug.cgi?id=109352
  [fdo#99912]:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Polish DRAM information readout code

2019-02-25 Thread Patchwork

== Series Details ==

Series: Polish DRAM information readout code
URL   : https://patchwork.freedesktop.org/series/57213/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
00f769077034 drm/i915: Store DIMM rank information as a number
6000a48eb1cf drm/i915: Extract functions to derive SKL+ DIMM info
bafd36480e66 drm/i915: Polish skl_is_16gb_dimm()
22d9a7332e2c drm/i915: Extract BXT DIMM helpers
b7ce42c317b8 drm/i915: Fix DRAM size reporting for BXT
3472026fb73d drm/i915: Extract DIMM info on GLK too
b73f574462db drm/i915: Use dram_dimm_info more
922fbda7b9af drm/i915: Generalize intel_is_dram_symmetric()
24b522fc37d6 drm/i914: s/l_info/dimm_l/ etc.
c01f3a66c0bb drm/i915: Clean up intel_get_dram_info() a bit
e72b3d3ce155 drm/i915: Extract DIMM info on cnl+
51c5b331412d drm/i915: Read out memory type
-:23: ERROR:BRACKET_SPACE: space prohibited before open square bracket '['
#23: FILE: drivers/gpu/drm/i915/i915_drv.c:1071:
+#define DRAM_TYPE_STR(type) [INTEL_DRAM_ ## type] = #type

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

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

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Fix DRAM size reporting for BXT

2019-02-25 Thread Chris Wilson

Quoting Ville Syrjälä (2019-02-25 20:48:10)
> On Mon, Feb 25, 2019 at 08:35:08PM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-02-25 20:29:00)
> > > From: Ville Syrjälä 
> > > 
> > > The BXT DUNIT register tells us the size of each DRAM device
> > > in Gb. We want to report the size of the whole DIMM in GB, so
> > > that it matches how we report it for non-LP platforms.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 9 -
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 1f4a966a9727..c40a738dabd3 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1322,7 +1322,14 @@ bxt_get_dram_info(struct drm_i915_private 
> > > *dev_priv)
> > > width = bxt_get_dimm_width(val);
> > > ranks = bxt_get_dimm_ranks(val);
> > >  
> > > -   DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, 
> > > ranks:%d\n",
> > > +   /*
> > > +* Size in register is Gb per DRAM device.
> > > +* Convert to total GB to match the way
> > > +* we report this for non-LP platforms.
> > > +*/
> > > +   size = size * ranks * 8 / (width ?: 1);
> > 
> > Should it be /8 for Gbits to GBytes?
> 
> It's a hand optimized version of
> 
> size*ranks*64 / width / 8

Maybe let the compiler handle the constants, otherwise every time I see
this I'll think it's backwards ;)

Maybe be even
size *= 64 * ranks / (width ?: 1);

/*
 * Size in register is Gb per DRAM device.
 * Convert to total GB to match the way
 * we report this for non-LP platforms.
 */
size /= 8;
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Fix DRAM size reporting for BXT

2019-02-25 Thread Ville Syrjälä

On Mon, Feb 25, 2019 at 08:35:08PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-02-25 20:29:00)
> > From: Ville Syrjälä 
> > 
> > The BXT DUNIT register tells us the size of each DRAM device
> > in Gb. We want to report the size of the whole DIMM in GB, so
> > that it matches how we report it for non-LP platforms.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 1f4a966a9727..c40a738dabd3 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1322,7 +1322,14 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
> > width = bxt_get_dimm_width(val);
> > ranks = bxt_get_dimm_ranks(val);
> >  
> > -   DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, 
> > ranks:%d\n",
> > +   /*
> > +* Size in register is Gb per DRAM device.
> > +* Convert to total GB to match the way
> > +* we report this for non-LP platforms.
> > +*/
> > +   size = size * ranks * 8 / (width ?: 1);
> 
> Should it be /8 for Gbits to GBytes?

It's a hand optimized version of

size*ranks*64 / width / 8

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: decouple dpll ids from type

2019-02-25 Thread Ville Syrjälä

On Fri, Feb 22, 2019 at 03:23:24PM -0800, Lucas De Marchi wrote:
> Use the first 3 bits of dpll_info.platform_flags to mark the type of the
> PLL instead of relying on the IDs. This is more future proof for
> allowing the same set of functions to be reused, even if the IDs change.
> 
> The warning about PLL id not corresponding to a combo phy in intel_display
> was removed as I don't think it should ever trigger.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_display.c  |  3 --
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 54 +--
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  1 -
>  3 files changed, 35 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b1d63c32ca94..a2be35118dd5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9592,9 +9592,6 @@ static void icelake_get_ddi_pll(struct drm_i915_private 
> *dev_priv,
>   temp = I915_READ(DPCLKA_CFGCR0_ICL) &
>  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
>   id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
> -
> - if (WARN_ON(!intel_dpll_is_combophy(id)))
> - return;
>   } else if (intel_port_is_tc(dev_priv, port)) {
>   id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv, port));
>   } else {
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index e4ec73d415d9..cdb4463bab5d 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2639,6 +2639,13 @@ int icl_calc_dp_combo_pll_link(struct drm_i915_private 
> *dev_priv,
>   return link_clock;
>  }
>  
> +enum icl_dpll_flags {
> + ICL_DPLL_TYPE_COMBOPHY,
> + ICL_DPLL_TYPE_TBT,
> + ICL_DPLL_TYPE_MG,
> + _ICL_DPLL_TYPE_MASK = 0x7,
> +};
> +
>  static enum tc_port icl_pll_id_to_tc_port(enum intel_dpll_id id)
>  {
>   return id - DPLL_ID_ICL_MGPLL1;
> @@ -2649,9 +2656,9 @@ enum intel_dpll_id icl_tc_port_to_pll_id(enum tc_port 
> tc_port)
>   return tc_port + DPLL_ID_ICL_MGPLL1;
>  }
>  
> -bool intel_dpll_is_combophy(enum intel_dpll_id id)
> +static enum icl_dpll_flags icl_dpll_type(const struct dpll_info *info)
>  {
> - return id == DPLL_ID_ICL_DPLL0 || id == DPLL_ID_ICL_DPLL1;
> + return info->platform_flags & _ICL_DPLL_TYPE_MASK;
>  }
>  
>  static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool use_ssc,
> @@ -2956,14 +2963,22 @@ icl_get_dpll(struct intel_crtc *crtc, struct 
> intel_crtc_state *crtc_state,
>   return pll;
>  }
>  
> -static i915_reg_t icl_pll_id_to_enable_reg(enum intel_dpll_id id)
> +static i915_reg_t
> +icl_pll_info_to_enable_reg(const struct dpll_info *info)
>  {
> - if (intel_dpll_is_combophy(id))
> - return CNL_DPLL_ENABLE(id);
> - else if (id == DPLL_ID_ICL_TBTPLL)
> - return TBT_PLL_ENABLE;
> + enum icl_dpll_flags type = icl_dpll_type(info);
>  
> - return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
> + switch (type) {
> + case ICL_DPLL_TYPE_COMBOPHY:
> + return CNL_DPLL_ENABLE(info->id);
> + case ICL_DPLL_TYPE_TBT:
> + return TBT_PLL_ENABLE;
> + case ICL_DPLL_TYPE_MG:
> + return MG_PLL_ENABLE(icl_pll_id_to_tc_port(info->id));
> + default:
> + MISSING_CASE(type);
> + return CNL_DPLL_ENABLE(info->id);
> + }
>  }

This seems a rather roundabout way of doing things when we already have
the vfuncs.

How about just:

mg_pll_enable()
{
icl_pll_enable(MG_REG);
}

combo_pll_enable()
{
icl_pll_enable(COMBO_REG);
}

or something along those lines.


>  
>  static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
> @@ -3042,7 +3057,7 @@ static bool icl_pll_get_hw_state(struct 
> drm_i915_private *dev_priv,
>   if (!wakeref)
>   return false;
>  
> - val = I915_READ(icl_pll_id_to_enable_reg(id));
> + val = I915_READ(icl_pll_info_to_enable_reg(pll->info));
>   if (!(val & PLL_ENABLE))
>   goto out;
>  
> @@ -3120,7 +3135,8 @@ static void icl_pll_enable(struct drm_i915_private 
> *dev_priv,
>  struct intel_shared_dpll *pll)
>  {
>   const enum intel_dpll_id id = pll->info->id;
> - i915_reg_t enable_reg = icl_pll_id_to_enable_reg(id);
> + enum icl_dpll_flags type = icl_dpll_type(pll->info);
> + i915_reg_t enable_reg = icl_pll_info_to_enable_reg(pll->info);
>   u32 val;
>  
>   val = I915_READ(enable_reg);
> @@ -3135,7 +3151,7 @@ static void icl_pll_enable(struct drm_i915_private 
> *dev_priv,
>   PLL_POWER_STATE, 1))
>   DRM_ERROR("PLL %d Power not enabled\n", id);
>  
> - if (intel_dpll_is_combophy(id) || id == DPLL_ID_ICL_TBTPLL)
> + if (type == ICL_DPLL_TYPE_COMBOPHY || type == ICL_DPLL_TYPE_TBT)
>

Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: move MG pll hw_state readout

2019-02-25 Thread Ville Syrjälä

On Fri, Feb 22, 2019 at 03:23:22PM -0800, Lucas De Marchi wrote:
> Let the MG plls have their own hooks since it shares very little with
> other PLL types. It's also better so the platform info contains the info
> if the PLL is for MG PHY rather than relying on the PLL ids.
> 
> Signed-off-by: Lucas De Marchi 

There's quite a bit more cleanup to be done in this area. As a start
https://patchwork.freedesktop.org/series/56354/ ;)

This patch looks good to me. It'll conflict with my series though, but
no biggie.
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 122 --
>  1 file changed, 74 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 0a42d11c4c33..e4ec73d415d9 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2966,6 +2966,68 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum 
> intel_dpll_id id)
>   return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
>  }
>  
> +static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
> + struct intel_shared_dpll *pll,
> + struct intel_dpll_hw_state *hw_state)
> +{
> + const enum intel_dpll_id id = pll->info->id;
> + enum tc_port tc_port = icl_pll_id_to_tc_port(id);
> + intel_wakeref_t wakeref;
> + bool ret = false;
> + u32 val;
> +
> + wakeref = intel_display_power_get_if_enabled(dev_priv,
> +  POWER_DOMAIN_PLLS);
> + if (!wakeref)
> + return false;
> +
> + val = I915_READ(MG_PLL_ENABLE(tc_port));
> + if (!(val & PLL_ENABLE))
> + goto out;
> +
> + hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(tc_port));
> + hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
> +
> + hw_state->mg_clktop2_coreclkctl1 =
> + I915_READ(MG_CLKTOP2_CORECLKCTL1(tc_port));
> + hw_state->mg_clktop2_coreclkctl1 &=
> + MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
> +
> + hw_state->mg_clktop2_hsclkctl =
> + I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
> + hw_state->mg_clktop2_hsclkctl &=
> + MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
> + MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
> + MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK |
> + MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK;
> +
> + hw_state->mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
> + hw_state->mg_pll_div1 = I915_READ(MG_PLL_DIV1(tc_port));
> + hw_state->mg_pll_lf = I915_READ(MG_PLL_LF(tc_port));
> + hw_state->mg_pll_frac_lock = I915_READ(MG_PLL_FRAC_LOCK(tc_port));
> + hw_state->mg_pll_ssc = I915_READ(MG_PLL_SSC(tc_port));
> +
> + hw_state->mg_pll_bias = I915_READ(MG_PLL_BIAS(tc_port));
> + hw_state->mg_pll_tdc_coldst_bias =
> + I915_READ(MG_PLL_TDC_COLDST_BIAS(tc_port));
> +
> + if (dev_priv->cdclk.hw.ref == 38400) {
> + hw_state->mg_pll_tdc_coldst_bias_mask = 
> MG_PLL_TDC_COLDST_COLDSTART;
> + hw_state->mg_pll_bias_mask = 0;
> + } else {
> + hw_state->mg_pll_tdc_coldst_bias_mask = -1U;
> + hw_state->mg_pll_bias_mask = -1U;
> + }
> +
> + hw_state->mg_pll_tdc_coldst_bias &= 
> hw_state->mg_pll_tdc_coldst_bias_mask;
> + hw_state->mg_pll_bias &= hw_state->mg_pll_bias_mask;
> +
> + ret = true;
> +out:
> + intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS, wakeref);
> + return ret;
> +}
> +
>  static bool icl_pll_get_hw_state(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll,
>struct intel_dpll_hw_state *hw_state)
> @@ -2984,50 +3046,8 @@ static bool icl_pll_get_hw_state(struct 
> drm_i915_private *dev_priv,
>   if (!(val & PLL_ENABLE))
>   goto out;
>  
> - if (intel_dpll_is_combophy(id) ||
> - id == DPLL_ID_ICL_TBTPLL) {
> - hw_state->cfgcr0 = I915_READ(ICL_DPLL_CFGCR0(id));
> - hw_state->cfgcr1 = I915_READ(ICL_DPLL_CFGCR1(id));
> - } else {
> - enum tc_port tc_port = icl_pll_id_to_tc_port(id);
> -
> - hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(tc_port));
> - hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
> -
> - hw_state->mg_clktop2_coreclkctl1 =
> - I915_READ(MG_CLKTOP2_CORECLKCTL1(tc_port));
> - hw_state->mg_clktop2_coreclkctl1 &=
> - MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
> -
> - hw_state->mg_clktop2_hsclkctl =
> - I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
> - hw_state->mg_clktop2_hsclkctl &=
> - MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
> - MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
> -

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Fix DRAM size reporting for BXT

2019-02-25 Thread Chris Wilson

Quoting Ville Syrjala (2019-02-25 20:29:00)
> From: Ville Syrjälä 
> 
> The BXT DUNIT register tells us the size of each DRAM device
> in Gb. We want to report the size of the whole DIMM in GB, so
> that it matches how we report it for non-LP platforms.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1f4a966a9727..c40a738dabd3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1322,7 +1322,14 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
> width = bxt_get_dimm_width(val);
> ranks = bxt_get_dimm_ranks(val);
>  
> -   DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, ranks:%d\n",
> +   /*
> +* Size in register is Gb per DRAM device.
> +* Convert to total GB to match the way
> +* we report this for non-LP platforms.
> +*/
> +   size = size * ranks * 8 / (width ?: 1);

Should it be /8 for Gbits to GBytes?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 11/12] drm/i915: Extract DIMM info on cnl+

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

We'll need information about the memory configuration on cnl+ too.
Extend the code to parse the slightly changed register layout.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 69 -
 drivers/gpu/drm/i915/i915_reg.h | 17 +++-
 2 files changed, 66 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e3aafe2bf3b7..95361814b531 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1095,17 +1095,43 @@ static int skl_get_dimm_ranks(u16 val)
if (skl_get_dimm_size(val) == 0)
return 0;
 
-   switch (val & SKL_DRAM_RANK_MASK) {
-   case SKL_DRAM_RANK_SINGLE:
-   case SKL_DRAM_RANK_DUAL:
-   val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
-   return val + 1;
+   val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
+
+   return val + 1;
+}
+
+static int cnl_get_dimm_size(u16 val)
+{
+   return (val & CNL_DRAM_SIZE_MASK) / 2;
+}
+
+static int cnl_get_dimm_width(u16 val)
+{
+   if (cnl_get_dimm_size(val) == 0)
+   return 0;
+
+   switch (val & CNL_DRAM_WIDTH_MASK) {
+   case CNL_DRAM_WIDTH_X8:
+   case CNL_DRAM_WIDTH_X16:
+   case CNL_DRAM_WIDTH_X32:
+   val = (val & CNL_DRAM_WIDTH_MASK) >> CNL_DRAM_WIDTH_SHIFT;
+   return 8 << val;
default:
MISSING_CASE(val);
return 0;
}
 }
 
+static int cnl_get_dimm_ranks(u16 val)
+{
+   if (cnl_get_dimm_size(val) == 0)
+   return 0;
+
+   val = (val & CNL_DRAM_RANK_MASK) >> CNL_DRAM_RANK_SHIFT;
+
+   return val + 1;
+}
+
 static bool
 skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
 {
@@ -1113,12 +1139,19 @@ skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
 }
 
 static void
-skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
+skl_dram_get_dimm_info(struct drm_i915_private *dev_priv,
+  struct dram_dimm_info *dimm,
   int channel, char dimm_name, u16 val)
 {
-   dimm->size = skl_get_dimm_size(val);
-   dimm->width = skl_get_dimm_width(val);
-   dimm->ranks = skl_get_dimm_ranks(val);
+   if (INTEL_GEN(dev_priv) >= 10) {
+   dimm->size = cnl_get_dimm_size(val);
+   dimm->width = cnl_get_dimm_width(val);
+   dimm->ranks = cnl_get_dimm_ranks(val);
+   } else {
+   dimm->size = skl_get_dimm_size(val);
+   dimm->width = skl_get_dimm_width(val);
+   dimm->ranks = skl_get_dimm_ranks(val);
+   }
 
DRM_DEBUG_KMS("CH%d DIMM %c size: %d GB, width: X%d, ranks: %d, 16Gb 
DIMMs: %s\n",
  channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
@@ -1126,11 +1159,14 @@ skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
 }
 
 static int
-skl_dram_get_channel_info(struct dram_channel_info *ch,
+skl_dram_get_channel_info(struct drm_i915_private *dev_priv,
+ struct dram_channel_info *ch,
  int channel, u32 val)
 {
-   skl_dram_get_dimm_info(>dimm_l, channel, 'L', val & 0x);
-   skl_dram_get_dimm_info(>dimm_s, channel, 'S', val >> 16);
+   skl_dram_get_dimm_info(dev_priv, >dimm_l,
+  channel, 'L', val & 0x);
+   skl_dram_get_dimm_info(dev_priv, >dimm_s,
+  channel, 'S', val >> 16);
 
if (ch->dimm_l.size == 0 && ch->dimm_s.size == 0) {
DRM_DEBUG_KMS("CH%d not populated\n", channel);
@@ -1172,12 +1208,12 @@ skl_dram_get_channels_info(struct drm_i915_private 
*dev_priv)
int ret;
 
val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
-   ret = skl_dram_get_channel_info(, 0, val);
+   ret = skl_dram_get_channel_info(dev_priv, , 0, val);
if (ret == 0)
dram_info->num_channels++;
 
val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
-   ret = skl_dram_get_channel_info(, 1, val);
+   ret = skl_dram_get_channel_info(dev_priv, , 1, val);
if (ret == 0)
dram_info->num_channels++;
 
@@ -1369,13 +1405,10 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) < 9)
return;
 
-   /* Need to calculate bandwidth only for Gen9 */
if (IS_GEN9_LP(dev_priv))
ret = bxt_get_dram_info(dev_priv);
-   else if (IS_GEN(dev_priv, 9))
-   ret = skl_get_dram_info(dev_priv);
else
-   ret = skl_dram_get_channels_info(dev_priv);
+   ret = skl_get_dram_info(dev_priv);
if (ret)
return;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 730bb1917fd1..b35b0220764f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9875,8 +9875,21 @@

[Intel-gfx] [PATCH 12/12] drm/i915: Read out memory type

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

We'll need to know the memory type in the system for some
bandwidth limitations and whatnot. Let's read that out on
gen9+.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 83 +++--
 drivers/gpu/drm/i915/i915_drv.h |  7 +++
 drivers/gpu/drm/i915/i915_reg.h | 13 ++
 3 files changed, 99 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 95361814b531..5f7e868b44f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,6 +1068,26 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
 }
 
+#define DRAM_TYPE_STR(type) [INTEL_DRAM_ ## type] = #type
+
+static const char *intel_dram_type_str(enum intel_dram_type type)
+{
+   static const char * const str[] = {
+   DRAM_TYPE_STR(UNKNOWN),
+   DRAM_TYPE_STR(DDR3),
+   DRAM_TYPE_STR(DDR4),
+   DRAM_TYPE_STR(LPDDR3),
+   DRAM_TYPE_STR(LPDDR4),
+   };
+
+   if (type >= ARRAY_SIZE(str))
+   type = INTEL_DRAM_UNKNOWN;
+
+   return str[type];
+}
+
+#undef DRAM_TYPE_STR
+
 static int skl_get_dimm_size(u16 val)
 {
return val & SKL_DRAM_SIZE_MASK;
@@ -1246,6 +1266,28 @@ skl_dram_get_channels_info(struct drm_i915_private 
*dev_priv)
return 0;
 }
 
+static enum intel_dram_type
+skl_get_dram_type(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   val = I915_READ(SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN);
+
+   switch (val & SKL_DRAM_DDR_TYPE_MASK) {
+   case SKL_DRAM_DDR_TYPE_DDR3:
+   return INTEL_DRAM_DDR3;
+   case SKL_DRAM_DDR_TYPE_DDR4:
+   return INTEL_DRAM_DDR4;
+   case SKL_DRAM_DDR_TYPE_LPDDR3:
+   return INTEL_DRAM_LPDDR3;
+   case SKL_DRAM_DDR_TYPE_LPDDR4:
+   return INTEL_DRAM_LPDDR4;
+   default:
+   MISSING_CASE(val);
+   return INTEL_DRAM_UNKNOWN;
+   }
+}
+
 static int
 skl_get_dram_info(struct drm_i915_private *dev_priv)
 {
@@ -1253,6 +1295,9 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
u32 mem_freq_khz, val;
int ret;
 
+   dram_info->type = skl_get_dram_type(dev_priv);
+   DRM_DEBUG_KMS("DRAM type: %s\n", intel_dram_type_str(dram_info->type));
+
ret = skl_dram_get_channels_info(dev_priv);
if (ret)
return ret;
@@ -1318,6 +1363,26 @@ static int bxt_get_dimm_ranks(u32 val)
}
 }
 
+static enum intel_dram_type bxt_get_dimm_type(u32 val)
+{
+   if (!bxt_get_dimm_size(val))
+   return INTEL_DRAM_UNKNOWN;
+
+   switch (val & BXT_DRAM_TYPE_MASK) {
+   case BXT_DRAM_TYPE_DDR3:
+   return INTEL_DRAM_DDR3;
+   case BXT_DRAM_TYPE_LPDDR3:
+   return INTEL_DRAM_LPDDR3;
+   case BXT_DRAM_TYPE_DDR4:
+   return INTEL_DRAM_DDR4;
+   case BXT_DRAM_TYPE_LPDDR4:
+   return INTEL_DRAM_LPDDR4;
+   default:
+   MISSING_CASE(val);
+   return INTEL_DRAM_UNKNOWN;
+   }
+}
+
 static int
 bxt_get_dram_info(struct drm_i915_private *dev_priv)
 {
@@ -1346,6 +1411,7 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
 * Now read each DUNIT8/9/10/11 to check the rank of each dimms.
 */
for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
+   enum intel_dram_type type;
u8 size, width, ranks;
 
val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
@@ -1357,6 +1423,7 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
size = bxt_get_dimm_size(val);
width = bxt_get_dimm_width(val);
ranks = bxt_get_dimm_ranks(val);
+   type = bxt_get_dimm_type(val);
 
/*
 * Size in register is Gb per DRAM device.
@@ -1365,9 +1432,13 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
 */
size = size * ranks * 8 / (width ?: 1);
 
-   DRM_DEBUG_KMS("CH%d DIMM size: %d GB, width: X%d, ranks: %d\n",
+   WARN_ON(type != INTEL_DRAM_UNKNOWN &&
+   dram_info->type != INTEL_DRAM_UNKNOWN &&
+   dram_info->type != type);
+
+   DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, ranks: %d, 
type: %s\n",
  i - BXT_D_CR_DRP0_DUNIT_START,
- size, width, ranks);
+ size, width, ranks, intel_dram_type_str(type));
 
/*
 * If any of the channel is single rank channel,
@@ -1378,10 +1449,14 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
dram_info->ranks = ranks;
else if (ranks == 1)
dram_info->ranks = 1;
+
+   if (type !=

[Intel-gfx] [PATCH 08/12] drm/i915: Generalize intel_is_dram_symmetric()

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Decouple intel_is_dram_symmetric() from the raw register values
by comparing just the dram_channel_info structs.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 28 
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3d6a08e907e3..9261bd0dccd6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1155,14 +1155,12 @@ skl_dram_get_channel_info(struct dram_channel_info *ch,
 }
 
 static bool
-intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
-   struct dram_channel_info *ch0)
+intel_is_dram_symmetric(const struct dram_channel_info *ch0,
+   const struct dram_channel_info *ch1)
 {
-   return (val_ch0 == val_ch1 &&
+   return !memcmp(ch0, ch1, sizeof(*ch0)) &&
(ch0->s_info.size == 0 ||
-(ch0->l_info.size == ch0->s_info.size &&
- ch0->l_info.width == ch0->s_info.width &&
- ch0->l_info.ranks == ch0->s_info.ranks)));
+!memcmp(>l_info, >s_info, sizeof(ch0->l_info)));
 }
 
 static int
@@ -1170,16 +1168,16 @@ skl_dram_get_channels_info(struct drm_i915_private 
*dev_priv)
 {
struct dram_info *dram_info = _priv->dram_info;
struct dram_channel_info ch0 = {}, ch1 = {};
-   u32 val_ch0, val_ch1;
+   u32 val;
int ret;
 
-   val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
-   ret = skl_dram_get_channel_info(, 0, val_ch0);
+   val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+   ret = skl_dram_get_channel_info(, 0, val);
if (ret == 0)
dram_info->num_channels++;
 
-   val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
-   ret = skl_dram_get_channel_info(, 1, val_ch1);
+   val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+   ret = skl_dram_get_channel_info(, 1, val);
if (ret == 0)
dram_info->num_channels++;
 
@@ -1205,12 +1203,10 @@ skl_dram_get_channels_info(struct drm_i915_private 
*dev_priv)
 
dram_info->is_16gb_dimm = ch0.is_16gb_dimm || ch1.is_16gb_dimm;
 
-   dev_priv->dram_info.symmetric_memory = intel_is_dram_symmetric(val_ch0,
-  val_ch1,
-  );
+   dram_info->symmetric_memory = intel_is_dram_symmetric(, );
 
-   DRM_DEBUG_KMS("memory configuration is %sSymmetric memory\n",
- dev_priv->dram_info.symmetric_memory ? "" : "not ");
+   DRM_DEBUG_KMS("Memory configuration is symmetric? %s\n",
+ yesno(dram_info->symmetric_memory));
return 0;
 }
 
-- 
2.19.2

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

[Intel-gfx] [PATCH 10/12] drm/i915: Clean up intel_get_dram_info() a bit

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Remove the pointless zero initialization of bunch of things
(the thing is kzalloc()ed).

Also throw out the mostly useless on-stack string. I think
it'll be clear enough from the logs that 0 means unknown.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 21413069a480..e3aafe2bf3b7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1357,14 +1357,8 @@ static void
 intel_get_dram_info(struct drm_i915_private *dev_priv)
 {
struct dram_info *dram_info = _priv->dram_info;
-   char bandwidth_str[32];
int ret;
 
-   dram_info->valid = false;
-   dram_info->ranks = 0;
-   dram_info->bandwidth_kbps = 0;
-   dram_info->num_channels = 0;
-
/*
 * Assume 16Gb DIMMs are present until proven otherwise.
 * This is only used for the level 0 watermark latency
@@ -1385,12 +1379,10 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
if (ret)
return;
 
-   if (dram_info->bandwidth_kbps)
-   sprintf(bandwidth_str, "%d KBps", dram_info->bandwidth_kbps);
-   else
-   sprintf(bandwidth_str, "unknown");
-   DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
- bandwidth_str, dram_info->num_channels);
+   DRM_DEBUG_KMS("DRAM bandwidth: %u kBps, channels: %u\n",
+ dram_info->bandwidth_kbps,
+ dram_info->num_channels);
+
DRM_DEBUG_KMS("DRAM ranks: %d, 16Gb DIMMs: %s\n",
  dram_info->ranks, yesno(dram_info->is_16gb_dimm));
 }
-- 
2.19.2

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

[Intel-gfx] [PATCH 07/12] drm/i915: Use dram_dimm_info more

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Reduce the code duplication a bit by sharing the same
code for parsing both DIMMs on a channel.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 44 ++---
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9c1ff3eb5775..3d6a08e907e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1112,25 +1112,30 @@ skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
return dimm->size * dimm->width / (8 * dimm->ranks ?: 1) == 16;
 }
 
-static int
-skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
+static void
+skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
+  int channel, char dimm_name, u16 val)
 {
-   u16 tmp_l, tmp_s;
+   dimm->size = skl_get_dimm_size(val);
+   dimm->width = skl_get_dimm_width(val);
+   dimm->ranks = skl_get_dimm_ranks(val);
 
-   tmp_l = val & 0x;
-   tmp_s = val >> 16;
+   DRM_DEBUG_KMS("CH%d DIMM %c size: %d GB, width: X%d, ranks: %d, 16Gb 
DIMMs: %s\n",
+ channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
+ yesno(skl_is_16gb_dimm(dimm)));
+}
 
-   ch->l_info.size = skl_get_dimm_size(tmp_l);
-   ch->s_info.size = skl_get_dimm_size(tmp_s);
+static int
+skl_dram_get_channel_info(struct dram_channel_info *ch,
+ int channel, u32 val)
+{
+   skl_dram_get_dimm_info(>l_info, channel, 'L', val & 0x);
+   skl_dram_get_dimm_info(>s_info, channel, 'S', val >> 16);
 
-   if (ch->l_info.size == 0 && ch->s_info.size == 0)
+   if (ch->l_info.size == 0 && ch->s_info.size == 0) {
+   DRM_DEBUG_KMS("CH%d not populated\n", channel);
return -EINVAL;
-
-   ch->l_info.width = skl_get_dimm_width(tmp_l);
-   ch->s_info.width = skl_get_dimm_width(tmp_s);
-
-   ch->l_info.ranks = skl_get_dimm_ranks(tmp_l);
-   ch->s_info.ranks = skl_get_dimm_ranks(tmp_s);
+   }
 
if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
ch->ranks = 2;
@@ -1143,9 +1148,8 @@ skl_dram_get_channel_info(struct dram_channel_info *ch, 
u32 val)
skl_is_16gb_dimm(>l_info) ||
skl_is_16gb_dimm(>s_info);
 
-   DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
- ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
- ch->s_info.size, ch->s_info.width, ch->s_info.ranks);
+   DRM_DEBUG_KMS("CH%d ranks: %d, 16Gb DIMMs: %s\n",
+ channel, ch->ranks, yesno(ch->is_16gb_dimm));
 
return 0;
 }
@@ -1165,17 +1169,17 @@ static int
 skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
 {
struct dram_info *dram_info = _priv->dram_info;
-   struct dram_channel_info ch0, ch1;
+   struct dram_channel_info ch0 = {}, ch1 = {};
u32 val_ch0, val_ch1;
int ret;
 
val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
-   ret = skl_dram_get_channel_info(, val_ch0);
+   ret = skl_dram_get_channel_info(, 0, val_ch0);
if (ret == 0)
dram_info->num_channels++;
 
val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
-   ret = skl_dram_get_channel_info(, val_ch1);
+   ret = skl_dram_get_channel_info(, 1, val_ch1);
if (ret == 0)
dram_info->num_channels++;
 
-- 
2.19.2

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

[Intel-gfx] [PATCH 04/12] drm/i915: Extract BXT DIMM helpers

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Polish the bxt DIMM parsing by extracting a few small helpers.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 79 ++---
 1 file changed, 52 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9d7fc2bc6593..1f4a966a9727 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1237,6 +1237,51 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
return 0;
 }
 
+static int bxt_get_dimm_size(u32 val)
+{
+   switch (val & BXT_DRAM_SIZE_MASK) {
+   case BXT_DRAM_SIZE_4GB:
+   return 4;
+   case BXT_DRAM_SIZE_6GB:
+   return 6;
+   case BXT_DRAM_SIZE_8GB:
+   return 8;
+   case BXT_DRAM_SIZE_12GB:
+   return 12;
+   case BXT_DRAM_SIZE_16GB:
+   return 16;
+   default:
+   MISSING_CASE(val);
+   return 0;
+   }
+}
+
+static int bxt_get_dimm_width(u32 val)
+{
+   if (!bxt_get_dimm_size(val))
+   return 0;
+
+   val = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
+
+   return 8 << val;
+}
+
+static int bxt_get_dimm_ranks(u32 val)
+{
+   if (!bxt_get_dimm_size(val))
+   return 0;
+
+   switch (val & BXT_DRAM_RANK_MASK) {
+   case BXT_DRAM_RANK_SINGLE:
+   return 1;
+   case BXT_DRAM_RANK_DUAL:
+   return 2;
+   default:
+   MISSING_CASE(val);
+   return 0;
+   }
+}
+
 static int
 bxt_get_dram_info(struct drm_i915_private *dev_priv)
 {
@@ -1266,39 +1311,19 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
 */
for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
u8 size, width, ranks;
-   u32 tmp;
 
val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
if (val == 0x)
continue;
 
dram_info->num_channels++;
-   tmp = val & BXT_DRAM_RANK_MASK;
-
-   if (tmp == BXT_DRAM_RANK_SINGLE)
-   ranks = 1;
-   else if (tmp == BXT_DRAM_RANK_DUAL)
-   ranks = 2;
-   else
-   ranks = 0;
-
-   tmp = val & BXT_DRAM_SIZE_MASK;
-   if (tmp == BXT_DRAM_SIZE_4GB)
-   size = 4;
-   else if (tmp == BXT_DRAM_SIZE_6GB)
-   size = 6;
-   else if (tmp == BXT_DRAM_SIZE_8GB)
-   size = 8;
-   else if (tmp == BXT_DRAM_SIZE_12GB)
-   size = 12;
-   else if (tmp == BXT_DRAM_SIZE_16GB)
-   size = 16;
-   else
-   size = 0;
-
-   tmp = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
-   width = (1 << tmp) * 8;
-   DRM_DEBUG_KMS("dram size:%dGB width:X%d ranks:%d\n",
+
+   size = bxt_get_dimm_size(val);
+   width = bxt_get_dimm_width(val);
+   ranks = bxt_get_dimm_ranks(val);
+
+   DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, ranks:%d\n",
+ i - BXT_D_CR_DRP0_DUNIT_START,
  size, width, ranks);
 
/*
-- 
2.19.2

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

[Intel-gfx] [PATCH 06/12] drm/i915: Extract DIMM info on GLK too

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

The BXT code for parsing DIMM info works for GLK too. Let's
dig it out even if we might not need it immediately.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c40a738dabd3..9c1ff3eb5775 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1372,11 +1372,11 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
 */
dram_info->is_16gb_dimm = !IS_GEN9_LP(dev_priv);
 
-   if (INTEL_GEN(dev_priv) < 9 || IS_GEMINILAKE(dev_priv))
+   if (INTEL_GEN(dev_priv) < 9)
return;
 
/* Need to calculate bandwidth only for Gen9 */
-   if (IS_BROXTON(dev_priv))
+   if (IS_GEN9_LP(dev_priv))
ret = bxt_get_dram_info(dev_priv);
else if (IS_GEN(dev_priv, 9))
ret = skl_get_dram_info(dev_priv);
-- 
2.19.2

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

[Intel-gfx] [PATCH 09/12] drm/i914: s/l_info/dimm_l/ etc.

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Rename the dimm info structs for clarity.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 18 +-
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9261bd0dccd6..21413069a480 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1129,24 +1129,24 @@ static int
 skl_dram_get_channel_info(struct dram_channel_info *ch,
  int channel, u32 val)
 {
-   skl_dram_get_dimm_info(>l_info, channel, 'L', val & 0x);
-   skl_dram_get_dimm_info(>s_info, channel, 'S', val >> 16);
+   skl_dram_get_dimm_info(>dimm_l, channel, 'L', val & 0x);
+   skl_dram_get_dimm_info(>dimm_s, channel, 'S', val >> 16);
 
-   if (ch->l_info.size == 0 && ch->s_info.size == 0) {
+   if (ch->dimm_l.size == 0 && ch->dimm_s.size == 0) {
DRM_DEBUG_KMS("CH%d not populated\n", channel);
return -EINVAL;
}
 
-   if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
+   if (ch->dimm_l.ranks == 2 || ch->dimm_s.ranks == 2)
ch->ranks = 2;
-   else if (ch->l_info.ranks == 1 && ch->s_info.ranks == 1)
+   else if (ch->dimm_l.ranks == 1 && ch->dimm_s.ranks == 1)
ch->ranks = 2;
else
ch->ranks = 1;
 
ch->is_16gb_dimm =
-   skl_is_16gb_dimm(>l_info) ||
-   skl_is_16gb_dimm(>s_info);
+   skl_is_16gb_dimm(>dimm_l) ||
+   skl_is_16gb_dimm(>dimm_s);
 
DRM_DEBUG_KMS("CH%d ranks: %d, 16Gb DIMMs: %s\n",
  channel, ch->ranks, yesno(ch->is_16gb_dimm));
@@ -1159,8 +1159,8 @@ intel_is_dram_symmetric(const struct dram_channel_info 
*ch0,
const struct dram_channel_info *ch1)
 {
return !memcmp(ch0, ch1, sizeof(*ch0)) &&
-   (ch0->s_info.size == 0 ||
-!memcmp(>l_info, >s_info, sizeof(ch0->l_info)));
+   (ch0->dimm_s.size == 0 ||
+!memcmp(>dimm_l, >dimm_s, sizeof(ch0->dimm_l)));
 }
 
 static int
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fcde09934bb5..89881b68dcb4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2070,7 +2070,7 @@ struct dram_dimm_info {
 };
 
 struct dram_channel_info {
-   struct dram_dimm_info l_info, s_info;
+   struct dram_dimm_info dimm_l, dimm_s;
u8 ranks;
bool is_16gb_dimm;
 };
-- 
2.19.2

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

[Intel-gfx] [PATCH 03/12] drm/i915: Polish skl_is_16gb_dimm()

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Pass the dimm struct to skl_is_16gb_dimm() rather than passing each
value separately. And let's replace the hardcoded set of values with
some simple arithmetic.

Also fix the byte vs. bit inconsistency in the debug message,
and polish the wording otherwise as well.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 22 ++
 drivers/gpu/drm/i915/i915_drv.h |  8 +---
 2 files changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b94bf475b04c..9d7fc2bc6593 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1107,18 +1107,9 @@ static int skl_get_dimm_ranks(u16 val)
 }
 
 static bool
-skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
+skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
 {
-   if (ranks == 1 && width == 8 && size == 16)
-   return true;
-   else if (ranks == 2 && width == 8 && size == 32)
-   return true;
-   else if (ranks == 1 && width == 16 && size == 8)
-   return true;
-   else if (ranks == 2 && width == 16 && size == 16)
-   return true;
-
-   return false;
+   return dimm->size * dimm->width / (8 * dimm->ranks ?: 1) == 16;
 }
 
 static int
@@ -1148,10 +1139,9 @@ skl_dram_get_channel_info(struct dram_channel_info *ch, 
u32 val)
else
ch->ranks = 1;
 
-   ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
-   ch->l_info.width) ||
-  skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
-   ch->s_info.width);
+   ch->is_16gb_dimm =
+   skl_is_16gb_dimm(>l_info) ||
+   skl_is_16gb_dimm(>s_info);
 
DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
  ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
@@ -1369,7 +1359,7 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
sprintf(bandwidth_str, "unknown");
DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
  bandwidth_str, dram_info->num_channels);
-   DRM_DEBUG_KMS("DRAM ranks: %d, 16GB-dimm:%s\n",
+   DRM_DEBUG_KMS("DRAM ranks: %d, 16Gb DIMMs: %s\n",
  dram_info->ranks, yesno(dram_info->is_16gb_dimm));
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9cb13a6edaf..fcde09934bb5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2065,10 +2065,12 @@ struct drm_i915_private {
 */
 };
 
+struct dram_dimm_info {
+   u8 size, width, ranks;
+};
+
 struct dram_channel_info {
-   struct info {
-   u8 size, width, ranks;
-   } l_info, s_info;
+   struct dram_dimm_info l_info, s_info;
u8 ranks;
bool is_16gb_dimm;
 };
-- 
2.19.2

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

[Intel-gfx] [PATCH 00/12] Polish DRAM information readout code

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Try to pimp up the DRAM information readut code a bit. This
is prep work for some DRAM bandwidth limit checks we'll be
needing.

Ville Syrjälä (12):
  drm/i915: Store DIMM rank information as a number
  drm/i915: Extract functions to derive SKL+ DIMM info
  drm/i915: Polish skl_is_16gb_dimm()
  drm/i915: Extract BXT DIMM helpers
  drm/i915: Fix DRAM size reporting for BXT
  drm/i915: Extract DIMM info on GLK too
  drm/i915: Use dram_dimm_info more
  drm/i915: Generalize intel_is_dram_symmetric()
  drm/i914: s/l_info/dimm_l/ etc.
  drm/i915: Clean up intel_get_dram_info() a bit
  drm/i915: Extract DIMM info on cnl+
  drm/i915: Read out memory type

 drivers/gpu/drm/i915/i915_drv.c | 408 +---
 drivers/gpu/drm/i915/i915_drv.h |  24 +-
 drivers/gpu/drm/i915/i915_reg.h |  30 ++-
 3 files changed, 312 insertions(+), 150 deletions(-)

-- 
2.19.2

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

[Intel-gfx] [PATCH 05/12] drm/i915: Fix DRAM size reporting for BXT

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

The BXT DUNIT register tells us the size of each DRAM device
in Gb. We want to report the size of the whole DIMM in GB, so
that it matches how we report it for non-LP platforms.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1f4a966a9727..c40a738dabd3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1322,7 +1322,14 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
width = bxt_get_dimm_width(val);
ranks = bxt_get_dimm_ranks(val);
 
-   DRM_DEBUG_KMS("CH%d DIMM size: % dGB, width: X%d, ranks:%d\n",
+   /*
+* Size in register is Gb per DRAM device.
+* Convert to total GB to match the way
+* we report this for non-LP platforms.
+*/
+   size = size * ranks * 8 / (width ?: 1);
+
+   DRM_DEBUG_KMS("CH%d DIMM size: %d GB, width: X%d, ranks: %d\n",
  i - BXT_D_CR_DRP0_DUNIT_START,
  size, width, ranks);
 
-- 
2.19.2

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

[Intel-gfx] [PATCH 02/12] drm/i915: Extract functions to derive SKL+ DIMM info

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Make the code less repetitive by extracting a few small helpers.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 68 +
 1 file changed, 43 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 48c6bc44072d..b94bf475b04c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,16 +1068,42 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
 }
 
-static int skl_get_dimm_ranks(u8 size, u32 rank)
+static int skl_get_dimm_size(u16 val)
 {
-   if (size == 0)
+   return val & SKL_DRAM_SIZE_MASK;
+}
+
+static int skl_get_dimm_width(u16 val)
+{
+   if (skl_get_dimm_size(val) == 0)
return 0;
-   if (rank == SKL_DRAM_RANK_SINGLE)
-   return 1;
-   else if (rank == SKL_DRAM_RANK_DUAL)
-   return 2;
 
-   return 0;
+   switch (val & SKL_DRAM_WIDTH_MASK) {
+   case SKL_DRAM_WIDTH_X8:
+   case SKL_DRAM_WIDTH_X16:
+   case SKL_DRAM_WIDTH_X32:
+   val = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
+   return 8 << val;
+   default:
+   MISSING_CASE(val);
+   return 0;
+   }
+}
+
+static int skl_get_dimm_ranks(u16 val)
+{
+   if (skl_get_dimm_size(val) == 0)
+   return 0;
+
+   switch (val & SKL_DRAM_RANK_MASK) {
+   case SKL_DRAM_RANK_SINGLE:
+   case SKL_DRAM_RANK_DUAL:
+   val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
+   return val + 1;
+   default:
+   MISSING_CASE(val);
+   return 0;
+   }
 }
 
 static bool
@@ -1098,30 +1124,22 @@ skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
 static int
 skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
 {
-   u32 tmp_l, tmp_s;
-   u32 s_val = val >> SKL_DRAM_S_SHIFT;
+   u16 tmp_l, tmp_s;
 
-   if (!val)
-   return -EINVAL;
+   tmp_l = val & 0x;
+   tmp_s = val >> 16;
 
-   tmp_l = val & SKL_DRAM_SIZE_MASK;
-   tmp_s = s_val & SKL_DRAM_SIZE_MASK;
+   ch->l_info.size = skl_get_dimm_size(tmp_l);
+   ch->s_info.size = skl_get_dimm_size(tmp_s);
 
-   if (tmp_l == 0 && tmp_s == 0)
+   if (ch->l_info.size == 0 && ch->s_info.size == 0)
return -EINVAL;
 
-   ch->l_info.size = tmp_l;
-   ch->s_info.size = tmp_s;
-
-   tmp_l = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
-   tmp_s = (s_val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
-   ch->l_info.width = (1 << tmp_l) * 8;
-   ch->s_info.width = (1 << tmp_s) * 8;
+   ch->l_info.width = skl_get_dimm_width(tmp_l);
+   ch->s_info.width = skl_get_dimm_width(tmp_s);
 
-   tmp_l = val & SKL_DRAM_RANK_MASK;
-   tmp_s = s_val & SKL_DRAM_RANK_MASK;
-   ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
-   ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
+   ch->l_info.ranks = skl_get_dimm_ranks(tmp_l);
+   ch->s_info.ranks = skl_get_dimm_ranks(tmp_s);
 
if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
ch->ranks = 2;
-- 
2.19.2

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

[Intel-gfx] [PATCH 01/12] drm/i915: Store DIMM rank information as a number

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Life will be easier later if we have the ranks stored
as a bare number.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c | 92 +++--
 drivers/gpu/drm/i915/i915_drv.h | 11 ++--
 2 files changed, 45 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c6354f6cdbdb..48c6bc44072d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,28 +1068,28 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
 }
 
-static enum dram_rank skl_get_dimm_rank(u8 size, u32 rank)
+static int skl_get_dimm_ranks(u8 size, u32 rank)
 {
if (size == 0)
-   return I915_DRAM_RANK_INVALID;
+   return 0;
if (rank == SKL_DRAM_RANK_SINGLE)
-   return I915_DRAM_RANK_SINGLE;
+   return 1;
else if (rank == SKL_DRAM_RANK_DUAL)
-   return I915_DRAM_RANK_DUAL;
+   return 2;
 
-   return I915_DRAM_RANK_INVALID;
+   return 0;
 }
 
 static bool
-skl_is_16gb_dimm(enum dram_rank rank, u8 size, u8 width)
+skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
 {
-   if (rank == I915_DRAM_RANK_SINGLE && width == 8 && size == 16)
+   if (ranks == 1 && width == 8 && size == 16)
return true;
-   else if (rank == I915_DRAM_RANK_DUAL && width == 8 && size == 32)
+   else if (ranks == 2 && width == 8 && size == 32)
return true;
-   else if (rank == SKL_DRAM_RANK_SINGLE && width == 16 && size == 8)
+   else if (ranks == 1 && width == 16 && size == 8)
return true;
-   else if (rank == SKL_DRAM_RANK_DUAL && width == 16 && size == 16)
+   else if (ranks == 2 && width == 16 && size == 16)
return true;
 
return false;
@@ -1120,28 +1120,24 @@ skl_dram_get_channel_info(struct dram_channel_info *ch, 
u32 val)
 
tmp_l = val & SKL_DRAM_RANK_MASK;
tmp_s = s_val & SKL_DRAM_RANK_MASK;
-   ch->l_info.rank = skl_get_dimm_rank(ch->l_info.size, tmp_l);
-   ch->s_info.rank = skl_get_dimm_rank(ch->s_info.size, tmp_s);
-
-   if (ch->l_info.rank == I915_DRAM_RANK_DUAL ||
-   ch->s_info.rank == I915_DRAM_RANK_DUAL)
-   ch->rank = I915_DRAM_RANK_DUAL;
-   else if (ch->l_info.rank == I915_DRAM_RANK_SINGLE &&
-ch->s_info.rank == I915_DRAM_RANK_SINGLE)
-   ch->rank = I915_DRAM_RANK_DUAL;
+   ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
+   ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
+
+   if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
+   ch->ranks = 2;
+   else if (ch->l_info.ranks == 1 && ch->s_info.ranks == 1)
+   ch->ranks = 2;
else
-   ch->rank = I915_DRAM_RANK_SINGLE;
+   ch->ranks = 1;
 
-   ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.rank, ch->l_info.size,
+   ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
ch->l_info.width) ||
-  skl_is_16gb_dimm(ch->s_info.rank, ch->s_info.size,
+  skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
ch->s_info.width);
 
-   DRM_DEBUG_KMS("(size:width:rank) L(%dGB:X%d:%s) S(%dGB:X%d:%s)\n",
- ch->l_info.size, ch->l_info.width,
- ch->l_info.rank ? "dual" : "single",
- ch->s_info.size, ch->s_info.width,
- ch->s_info.rank ? "dual" : "single");
+   DRM_DEBUG_KMS("(size:width:ranks) L(%dGB:X%d:%d) S(%dGB:X%d:%d)\n",
+ ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
+ ch->s_info.size, ch->s_info.width, ch->s_info.ranks);
 
return 0;
 }
@@ -1154,7 +1150,7 @@ intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
(ch0->s_info.size == 0 ||
 (ch0->l_info.size == ch0->s_info.size &&
  ch0->l_info.width == ch0->s_info.width &&
- ch0->l_info.rank == ch0->s_info.rank)));
+ ch0->l_info.ranks == ch0->s_info.ranks)));
 }
 
 static int
@@ -1185,13 +1181,12 @@ skl_dram_get_channels_info(struct drm_i915_private 
*dev_priv)
 * will be same as if single rank memory, so consider single rank
 * memory.
 */
-   if (ch0.rank == I915_DRAM_RANK_SINGLE ||
-   ch1.rank == I915_DRAM_RANK_SINGLE)
-   dram_info->rank = I915_DRAM_RANK_SINGLE;
+   if (ch0.ranks == 1 || ch1.ranks == 1)
+   dram_info->ranks = 1;
else
-   dram_info->rank = max(ch0.rank, ch1.rank);
+   dram_info->ranks = max(ch0.ranks, ch1.ranks);
 
-   if (dram_info->rank == I915_DRAM_RANK_INVALID) {
+   if

Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

2019-02-25 Thread Dave Airlie

On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
 wrote:
>
> + dri-devel mailing list, especially for the buddy allocator part
>
> Quoting Dave Airlie (2019-02-15 02:47:07)
> > On Fri, 15 Feb 2019 at 00:57, Matthew Auld  wrote:
> > >
> > > In preparation for upcoming devices with device local memory, introduce 
> > > the
> > > concept of different memory regions, and a simple buddy allocator to 
> > > manage
> > > them.
> >
> > This is missing the information on why it's not TTM.
> >
> > Nothing against extending i915 gem off into doing stuff we already
> > have examples off in tree, but before you do that it would be good to
> > have a why we can't use TTM discussion in public.
>
> Glad that you asked. It's my fault that it was not included in
> the cover letter. I anticipated the question, but was travelling
> for a couple of days at the time this was sent. I didn't want
> to write a hasty explanation and then disappear, leaving others to
> take the heat.
>
> So here goes the less-hasty version:
>
> We did an analysis on the effort needed vs benefit gained of using
> TTM when this was started initially. The conclusion was that we
> already share the interesting bits of code through core DRM, really.
>
> Re-writing the memory handling to TTM would buy us more fine-grained
> locking. But it's more a trait of rewriting the memory handling with
> the information we have learned, than rewriting it to use TTM :)
>
> And further, we've been getting rid of struct_mutex at a steady phase
> in the past years, so we have a clear path to the fine-grained locking
> already in the not-so-distant future. With all this we did not see
> much gained from converting over, as the code sharing is already
> substantial.
>
> We also wanted to have the buddy allocator instead of a for loop making
> drm_mm allocations to make sure we can keep the memory fragmentation
> at bay. The intent is to move the buddy allocator to core DRM, to the
> benefit of all the drivers, if there is interest from community. It has
> been written as a strictly separate component with that in mind.
>
> And if you take the buddy allocator out of the patch set, the rest is
> mostly just vfuncing things up to be able to have different backing
> storages for objects. We took the opportunity to move over to the more
> valgrind friendly mmap while touching things, but it's something we
> have been contemplating anyway. And yeah, loads of selftests.
>
> That's really all that needed adding, and most of it is internal to
> i915 and not to do with uAPI. This means porting over an userspace
> driver doesn't require a substantial rewrite, but adding new a few
> new IOCTLs to set the preferred backing storage placements.
>
> All the previous GEM abstractions keep applying, so we did not see
> a justification to rewrite the kernel driver and userspace drivers.
> It would have just to made things look like TTM, when we already
> have the important parts of the code shared with TTM drivers
> behind the GEM interfaces which all our drivers sit on top of.

a) you guys should be the community as well, if the buddy allocator is
useful in the core DRM get out there and try and see if anyone else
has a use case for it, like the GPU scheduler we have now (can i915
use that yet? :-)

b) however this last two paragraphs fill me with no confidence that
you've looked at TTM at all. It sounds like you took comments about
TTM made 10 years ago, and didn't update them. There should be no
major reason for a uapi change just because you adopt TTM. TTM hasn't
ever had a common uapi across drivers upstream, one was proposed
initially > 10 years ago. All the current TTM using drivers except
vmware use a GEM based API as well. TTM is an internal driver helper
for managing pools of RAM.

I'm just not sure what rebuilding a chunk of shared code inside the
i915 driver is buying you, except a transition path into divergence
from all the other discrete RAM drivers. Like the gallium aversion in
userspace, having a TTM aversion in kernel space is going to be the
wrong path, and I'd rather not have to clean it up in 5 years when you
guys eventually realise it.

The i915 GEM code get rewritten and refactored quite often and has a
bus factor of ickle, if he decided to go elsewhere, you will have a
pile of code that nobody gets, I think having a TTM backend would have
a better long term effect on your driver maintainability.

Dave.
___
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: Yet another if/else sort of newer to older platforms. (rev2)

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/i915: Yet another if/else sort of newer to older platforms. (rev2)
URL   : https://patchwork.freedesktop.org/series/57112/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12300


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57112/revisions/2/mbox/

Known issues


  Here are the changes found in Patchwork_12300 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   PASS -> SKIP [fdo#109271]

  * igt@i915_pm_rpm@basic-rte:
- fi-bsw-kefka:   PASS -> FAIL [fdo#108800]

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  PASS -> FAIL [fdo#103167]

  * igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: PASS -> FAIL [fdo#103182]

  
 Possible fixes 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-u2 fi-ctg-p8600 


Build changes
-

* Linux: CI_DRM_5659 -> Patchwork_12300

  CI_DRM_5659: bffea990c63087245e8501df82fd45f24ce6ad1f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12300: f7dba310f48d67552dc591d7f130fe3063c656d5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f7dba310f48d drm/i915: Yet another if/else sort of newer to older platforms.

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

2019-02-25 Thread Patchwork

== Series Details ==

Series: Propagate DP-over-Type-C hotplug events from Type-C subsys to 
drm-drivers
URL   : https://patchwork.freedesktop.org/series/57187/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5658_full -> Patchwork_12296_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_12296_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@preemptive-hang-bsd2:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] +32

  * igt@gem_softpin@noreloc-s3:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713] +1

  * igt@i915_pm_rpm@debugfs-forcewake-user:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724]

  * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking-fencing:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_busy@basic-modeset-e:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-snb:  NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl:  PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl:  PASS -> FAIL [fdo#103232] +4

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw:  PASS -> FAIL [fdo#105767]

  * igt@kms_flip_tiling@flip-to-y-tiled:
- shard-iclb: PASS -> FAIL [fdo#107931]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-apl:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk:  PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +1

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-kbl:  PASS -> FAIL [fdo#103191] / [fdo#108657]

  * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl:  PASS -> FAIL [fdo#108948]

  * igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk:  PASS -> FAIL [fdo#103166] +1
- shard-iclb: PASS -> FAIL [fdo#103166] +4

  * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-hsw:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_psr@no_drrs:
- shard-iclb: PASS -> FAIL [fdo#108341]

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  PASS -> FAIL [fdo#109016]

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  PASS -> DMESG-FAIL [fdo#105763]

  * igt@kms_sysfs_edid_timing:
- shard-iclb: PASS -> FAIL [fdo#100047]

  * igt@kms_vblank@pipe-a-ts-continuation-modeset-hang:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@perf@oa-exponents:
- shard-glk:  PASS -> FAIL [fdo#105483]

  * igt@perf_pmu@busy-check-all-vecs0:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +35

  * igt@prime_vgem@fence-write-hang:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +10

  
 Possible fixes 

  * igt@i915_pm_rpm@system-suspend-devices:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +4

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-iclb: DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl:  FAIL [fdo#106510] / [fdo#108145] -> PASS

  * igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-apl:  FAIL [fdo#103232] -> PASS +1

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  FAIL [fdo#104873] -> PASS

  * igt@kms_cursor_legacy@pipe-c-torture-bo:
- shard-hsw:  DMESG-WARN [fdo#107122] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: FAIL [fdo#103167] -> PASS +3

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk:  FAIL [fdo#103167] -> PASS +3

  * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-apl:  FAIL [fdo#108948] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-iclb: FAIL [fdo#103166] -> PASS

  * igt@tools_test@tools_test:
- shard-iclb: SKIP [fdo#109352] -> PASS

  
  [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#104873]:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: don't check internal state in PP_STATUS

2019-02-25 Thread Ville Syrjälä

On Fri, Feb 22, 2019 at 04:34:49PM -0800, Lucas De Marchi wrote:
> Instead of checking the bits that give the internal machine state we can
> simply rely on the information from the other bits: 1) on or off,
> 2) transitioning or not.
> 
> Bit 31 has the "Panel Power On Status"
> Bits 29:28 has the "Power Sequence Progress"
> 
> So, wait_panel_on() only needs to wait for bit 31 to indicate it's on
> and bits 29:28 to indicate there's no transition in progress.
> 
> From my limited test that includes the cycle delay, so we are safe with
> only checking those bits, like we do in wait_panel_off().

Is there a specific benefit to not checking the state?

> 
> Admittedly this needs more test, so let CI go through more platforms.

CI is probably not going to tell us if we break this and start angering
the panels.

The details of the state machine escape me right now, so can't remember
if there's some state which would somehow not be indicated quite right
by the other bits.

> 
> Cc: Clint Taylor 
> Cc: Rodrigo Vivi 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e1a051c0fbfe..9c16b69043cc 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2315,8 +2315,8 @@ static void intel_dp_prepare(struct intel_encoder 
> *encoder,
>   }
>  }
>  
> -#define IDLE_ON_MASK (PP_ON | PP_SEQUENCE_MASK | 0   
>   | PP_SEQUENCE_STATE_MASK)
> -#define IDLE_ON_VALUE(PP_ON | PP_SEQUENCE_NONE | 0   
>   | PP_SEQUENCE_STATE_ON_IDLE)
> +#define IDLE_ON_MASK (PP_ON | PP_SEQUENCE_MASK | 
> PP_CYCLE_DELAY_ACTIVE | 0)
> +#define IDLE_ON_VALUE(PP_ON | PP_SEQUENCE_NONE | 0   
>   | 0)
>  
>  #define IDLE_OFF_MASK(PP_ON | PP_SEQUENCE_MASK | 0   
>   | 0)
>  #define IDLE_OFF_VALUE   (0 | PP_SEQUENCE_NONE | 0   
>   | 0)
> -- 
> 2.20.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: remove unused bits from Panel Power Sequence State

2019-02-25 Thread Ville Syrjälä

On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:
> No change in behavior. Just removing the unused bits since it makes it
> easier to compare them on new platforms and one of them was wrong
> (PP_SEQUENCE_STATE_ON_S1_0 vs the supposedly correct name
> PP_SEQUENCE_STATE_ON_S1_1)
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 730bb1917fd1..e855dae978db 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4717,15 +4717,9 @@ enum {
>  #define   PP_SEQUENCE_SHIFT  28
>  #define   PP_CYCLE_DELAY_ACTIVE  (1 << 27)
>  #define   PP_SEQUENCE_STATE_MASK 0x000f
> -#define   PP_SEQUENCE_STATE_OFF_IDLE (0x0 << 0)
> -#define   PP_SEQUENCE_STATE_OFF_S0_1 (0x1 << 0)
> -#define   PP_SEQUENCE_STATE_OFF_S0_2 (0x2 << 0)
> -#define   PP_SEQUENCE_STATE_OFF_S0_3 (0x3 << 0)
> -#define   PP_SEQUENCE_STATE_ON_IDLE  (0x8 << 0)
> -#define   PP_SEQUENCE_STATE_ON_S1_0  (0x9 << 0)
> -#define   PP_SEQUENCE_STATE_ON_S1_2  (0xa << 0)
> -#define   PP_SEQUENCE_STATE_ON_S1_3  (0xb << 0)
> -#define   PP_SEQUENCE_STATE_RESET(0xf << 0)
> +#define   PP_SEQUENCE_STATE_OFF_IDLE 0x0
> +#define   PP_SEQUENCE_STATE_ON_IDLE  0x8
> +#define   PP_SEQUENCE_STATE_RESET0xf

But how am I supposed to remember what the register values mean?

>  
>  #define _PP_CONTROL  0x61204
>  #define PP_CONTROL(pps_idx)  _MMIO_PPS(pps_idx, _PP_CONTROL)
> -- 
> 2.20.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: extract AUX mask assignment to separate function

2019-02-25 Thread Ville Syrjälä

On Fri, Feb 22, 2019 at 03:59:54PM -0800, Lucas De Marchi wrote:
> No change in behavior, this only allows to more easily follow the flow
> of gen8_de_irq_handler without the mask assignments for each platform.
> This also re-organizes the branches a little bit, so the one-off case
> for CNL_WITH_PORT_F is separate from the generic gen >= 11.
> 
> Cc: Ville Syrjälä 
> Cc: Jose Souza 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 34 +++--
>  1 file changed, 20 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 7c7e84e86c6a..524caf168a01 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2676,6 +2676,25 @@ static void gen11_hpd_irq_handler(struct 
> drm_i915_private *dev_priv, u32 iir)
>   DRM_ERROR("Unexpected DE HPD interrupt 0x%08x\n", iir);
>  }
>  
> +static u32 de_port_iir_aux_mask(struct drm_i915_private *dev_priv)

I would drop the "iir" since this applies to all irq registers.
And maybe prefix with "gen8_" ?

Otherwise
Reviewed-by: Ville Syrjälä 

> +{
> + u32 mask = GEN8_AUX_CHANNEL_A;
> +
> + if (INTEL_GEN(dev_priv) >= 9)
> + mask |= GEN9_AUX_CHANNEL_B |
> + GEN9_AUX_CHANNEL_C |
> + GEN9_AUX_CHANNEL_D;
> +
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + mask |= CNL_AUX_CHANNEL_F;
> +
> + if (INTEL_GEN(dev_priv) >= 11)
> + mask |= ICL_AUX_CHANNEL_E |
> + CNL_AUX_CHANNEL_F;
> +
> + return mask;
> +}
> +
>  static irqreturn_t
>  gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
>  {
> @@ -2731,20 +2750,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   I915_WRITE(GEN8_DE_PORT_IIR, iir);
>   ret = IRQ_HANDLED;
>  
> - tmp_mask = GEN8_AUX_CHANNEL_A;
> - if (INTEL_GEN(dev_priv) >= 9)
> - tmp_mask |= GEN9_AUX_CHANNEL_B |
> - GEN9_AUX_CHANNEL_C |
> - GEN9_AUX_CHANNEL_D;
> -
> - if (INTEL_GEN(dev_priv) >= 11)
> - tmp_mask |= ICL_AUX_CHANNEL_E;
> -
> - if (IS_CNL_WITH_PORT_F(dev_priv) ||
> - INTEL_GEN(dev_priv) >= 11)
> - tmp_mask |= CNL_AUX_CHANNEL_F;
> -
> - if (iir & tmp_mask) {
> + if (iir & de_port_iir_aux_mask(dev_priv)) {
>   dp_aux_irq_handler(dev_priv);
>   found = true;
>   }
> -- 
> 2.20.0

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

[Intel-gfx] [PATCH] drm/i915: Yet another if/else sort of newer to older platforms.

2019-02-25 Thread Rodrigo Vivi

No functional change. Just a reorg to match the preferred
behavior.

When rebasing internal branch on top of latest sort I noticed
few more cases that needs to get reordered.

Let's do in a bundle this time and hoping there's no other
missing places.

v2: Check for HSW/BDW ULT before generic IS_HASWELL or
IS_BROADWELL or it doesn't work as pointed by Ville.
But also ULT came afterwards anyway.

Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Lucas De Marchi 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.c  | 20 
 drivers/gpu/drm/i915/i915_perf.c | 50 +-
 drivers/gpu/drm/i915/intel_cdclk.c   | 38 +++---
 drivers/gpu/drm/i915/intel_workarounds.c | 64 
 4 files changed, 86 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c6354f6cdbdb..ed48aac1487d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -219,20 +219,20 @@ intel_virt_detect_pch(const struct drm_i915_private 
*dev_priv)
 * make an educated guess as to which PCH is really there.
 */
 
-   if (IS_GEN(dev_priv, 5))
-   id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
-   else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
-   id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
+   if (IS_ICELAKE(dev_priv))
+   id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
+   else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
+   id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
+   else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+   id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
-   else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
-   id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
-   else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
-   id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
-   else if (IS_ICELAKE(dev_priv))
-   id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
+   else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
+   id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
+   else if (IS_GEN(dev_priv, 5))
+   id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
 
if (id)
DRM_DEBUG_KMS("Assuming PCH ID %04x\n", id);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9ebf99f3d8d3..72a9a35b40e2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2881,12 +2881,24 @@ void i915_perf_register(struct drm_i915_private 
*dev_priv)
 
sysfs_attr_init(_priv->perf.oa.test_config.sysfs_metric_id.attr);
 
-   if (IS_HASWELL(dev_priv)) {
-   i915_perf_load_test_config_hsw(dev_priv);
-   } else if (IS_BROADWELL(dev_priv)) {
-   i915_perf_load_test_config_bdw(dev_priv);
-   } else if (IS_CHERRYVIEW(dev_priv)) {
-   i915_perf_load_test_config_chv(dev_priv);
+   if (IS_ICELAKE(dev_priv)) {
+   i915_perf_load_test_config_icl(dev_priv);
+   } else if (IS_CANNONLAKE(dev_priv)) {
+   i915_perf_load_test_config_cnl(dev_priv);
+   } else if (IS_COFFEELAKE(dev_priv)) {
+   if (IS_CFL_GT2(dev_priv))
+   i915_perf_load_test_config_cflgt2(dev_priv);
+   if (IS_CFL_GT3(dev_priv))
+   i915_perf_load_test_config_cflgt3(dev_priv);
+   } else if (IS_GEMINILAKE(dev_priv)) {
+   i915_perf_load_test_config_glk(dev_priv);
+   } else if (IS_KABYLAKE(dev_priv)) {
+   if (IS_KBL_GT2(dev_priv))
+   i915_perf_load_test_config_kblgt2(dev_priv);
+   else if (IS_KBL_GT3(dev_priv))
+   i915_perf_load_test_config_kblgt3(dev_priv);
+   } else if (IS_BROXTON(dev_priv)) {
+   i915_perf_load_test_config_bxt(dev_priv);
} else if (IS_SKYLAKE(dev_priv)) {
if (IS_SKL_GT2(dev_priv))
i915_perf_load_test_config_sklgt2(dev_priv);
@@ -2894,25 +2906,13 @@ void i915_perf_register(struct drm_i915_private 
*dev_priv)
i915_perf_load_test_config_sklgt3(dev_priv);
else if (IS_SKL_GT4(dev_priv))
i915_perf_load_test_config_sklgt4(dev_priv);
-   } else if (IS_BROXTON(dev_priv)) {
-   i915_perf_load_test_config_bxt(dev_priv);
-   } else if (IS_KABYLAKE(dev_priv)) {
-   if (IS_KBL_GT2(dev_priv))
-   i915_perf_load_test_config_kblgt2(dev_priv);
-   else if (IS_KBL_GT3(dev_priv))
-   i915_perf_load_test_config_kblgt3(dev_priv);
-   } else if (IS_GEMINILAKE(dev_priv)) {
-

Re: [Intel-gfx] [PATCH] drm/i915: Yet another if/else sort of newer to older platforms.

2019-02-25 Thread Rodrigo Vivi

On Mon, Feb 25, 2019 at 06:32:51PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 22, 2019 at 02:11:12PM -0800, Rodrigo Vivi wrote:
> > No functional change. Just a reorg to match the preferred
> > behavior.
> > 
> > When rebasing internal branch on top of latest sort I noticed
> > few more cases that needs to get reordered.
> > 
> > Let's do in a bundle this time and hoping there's no other
> > missing places.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Cc: Lucas De Marchi 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c  | 24 -
> >  drivers/gpu/drm/i915/i915_perf.c | 50 +-
> >  drivers/gpu/drm/i915/intel_cdclk.c   | 38 +++---
> >  drivers/gpu/drm/i915/intel_workarounds.c | 64 
> >  4 files changed, 88 insertions(+), 88 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index c6354f6cdbdb..0e3d5cf2c4f8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -219,20 +219,20 @@ intel_virt_detect_pch(const struct drm_i915_private 
> > *dev_priv)
> >  * make an educated guess as to which PCH is really there.
> >  */
> >  
> > -   if (IS_GEN(dev_priv, 5))
> > -   id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
> > -   else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
> > -   id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
> > -   else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> > -   id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> > -   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> > -   id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> > -   else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> > -   id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
> > +   if (IS_ICELAKE(dev_priv))
> > +   id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
> > else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
> > id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
> > -   else if (IS_ICELAKE(dev_priv))
> > -   id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
> > +   else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> > +   id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
> > +   else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> > +   id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> > +   else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> > +   id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> 
> Generic match before the more specific one. That's not going to work.

ops, indeed... v2 is coming...

> 
> > +   else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
> > +   id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
> > +   else if (IS_GEN(dev_priv, 5))
> > +   id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
> >  
> > if (id)
> > DRM_DEBUG_KMS("Assuming PCH ID %04x\n", id);
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 9ebf99f3d8d3..72a9a35b40e2 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -2881,12 +2881,24 @@ void i915_perf_register(struct drm_i915_private 
> > *dev_priv)
> >  
> > sysfs_attr_init(_priv->perf.oa.test_config.sysfs_metric_id.attr);
> >  
> > -   if (IS_HASWELL(dev_priv)) {
> > -   i915_perf_load_test_config_hsw(dev_priv);
> > -   } else if (IS_BROADWELL(dev_priv)) {
> > -   i915_perf_load_test_config_bdw(dev_priv);
> > -   } else if (IS_CHERRYVIEW(dev_priv)) {
> > -   i915_perf_load_test_config_chv(dev_priv);
> > +   if (IS_ICELAKE(dev_priv)) {
> > +   i915_perf_load_test_config_icl(dev_priv);
> > +   } else if (IS_CANNONLAKE(dev_priv)) {
> > +   i915_perf_load_test_config_cnl(dev_priv);
> > +   } else if (IS_COFFEELAKE(dev_priv)) {
> > +   if (IS_CFL_GT2(dev_priv))
> > +   i915_perf_load_test_config_cflgt2(dev_priv);
> > +   if (IS_CFL_GT3(dev_priv))
> > +   i915_perf_load_test_config_cflgt3(dev_priv);
> > +   } else if (IS_GEMINILAKE(dev_priv)) {
> > +   i915_perf_load_test_config_glk(dev_priv);
> > +   } else if (IS_KABYLAKE(dev_priv)) {
> > +   if (IS_KBL_GT2(dev_priv))
> > +   i915_perf_load_test_config_kblgt2(dev_priv);
> > +   else if (IS_KBL_GT3(dev_priv))
> > +   i915_perf_load_test_config_kblgt3(dev_priv);
> > +   } else if (IS_BROXTON(dev_priv)) {
> > +   i915_perf_load_test_config_bxt(dev_priv);
> > } else if (IS_SKYLAKE(dev_priv)) {
> > if (IS_SKL_GT2(dev_priv))
> > i915_perf_load_test_config_sklgt2(dev_priv);
> > @@ -2894,25 +2906,13 @@ void i915_perf_register(struct drm_i915_private 
> > *dev_priv)
> > i915_perf_load_test_config_sklgt3(dev_priv);
> > else if (IS_SKL_GT4(dev_priv))
> > i915_perf_load_test_config_sklgt4(dev_priv);
> > -   } else if (IS_BROXTON(dev_priv)) {
> > -

Re: [Intel-gfx] [PATCH v2 3/3] drm/dsc: Split DSC PPS and SDP header initialisations

2019-02-25 Thread Manasi Navare

On Thu, Feb 21, 2019 at 03:20:01PM -0500, David Francis wrote:
> The DP 1.4 spec defines the SDP header and SDP contents for
> a Picture Parameter Set (PPS) that must be sent in advance
> of DSC transmission to define the encoding characteristics.
> 
> This was done in one struct, drm_dsc_pps_infoframe, which
> conatined the SDP header and PPS.  Because the PPS is
> a property of DSC over any connector, not just DP, and because
> drm drivers may have their own SDP structs they wish to use,
> make the functions that initialise SDP and PPS headers take
> the components they operate on, not drm_dsc_pps_infoframe,
> 
> Signed-off-by: David Francis 

The corresponding changes for the header init and payload init now
look good to me.

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/drm_dsc.c | 117 +++---
>  drivers/gpu/drm/i915/intel_vdsc.c |   4 +-
>  include/drm/drm_dsc.h |   4 +-
>  3 files changed, 62 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index d77570bf6ac4..77f4e5ae4197 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -32,66 +32,65 @@
>  /**
>   * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
>   * for DisplayPort as per the DP 1.4 spec.
> - * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
> - *   as defined in  drm_dsc_pps_infoframe
> + * @pps_header: Secondary data packet header for DSC Picture
> + *  Parameter Set as defined in  dp_sdp_header
>   *
>   * DP 1.4 spec defines the secondary data packet for sending the
>   * picture parameter infoframes from the source to the sink.
> - * This function populates the pps header defined in
> - *  drm_dsc_pps_infoframe as per the header bytes defined
> - * in  dp_sdp_header.
> + * This function populates the SDP header defined in
> + *  dp_sdp_header.
>   */
> -void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
> +void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header)
>  {
> - memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
> + memset(pps_header, 0, sizeof(*pps_header));
>  
> - pps_sdp->pps_header.HB1 = DP_SDP_PPS;
> - pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
> + pps_header->HB1 = DP_SDP_PPS;
> + pps_header->HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
>  }
>  EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
>  
>  /**
> - * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> + * drm_dsc_pps_payload_pack() - Populates the DSC PPS
>   *
> - * @pps_sdp:
> - * Secondary data packet for DSC Picture Parameter Set. This is defined
> - * by  drm_dsc_pps_infoframe
> + * @pps_payload:
> + * Bitwise struct for DSC Picture Parameter Set. This is defined
> + * by  drm_dsc_picture_parameter_set
>   * @dsc_cfg:
>   * DSC Configuration data filled by driver as defined by
>   *  drm_dsc_config
>   *
> - * DSC source device sends a secondary data packet filled with all the
> - * picture parameter set (PPS) information required by the sink to decode
> - * the compressed frame. Driver populates the dsC PPS infoframe using the DSC
> - * configuration parameters in the order expected by the DSC Display Sink
> - * device. For the DSC, the sink device expects the PPS payload in the big
> - * endian format for the fields that span more than 1 byte.
> + * DSC source device sends a picture parameter set (PPS) containing the
> + * information required by the sink to decode the compressed frame. Driver
> + * populates the DSC PPS struct using the DSC configuration parameters in
> + * the order expected by the DSC Display Sink device. For the DSC, the sink
> + * device expects the PPS payload in big endian format for fields
> + * that span more than 1 byte.
>   */
> -void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
> +void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set 
> *pps_payload,
>   const struct drm_dsc_config *dsc_cfg)
>  {
>   int i;
>  
>   /* Protect against someone accidently changing struct size */
> - BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
> + BUILD_BUG_ON(sizeof(*pps_payload) !=
>DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
>  
> - memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
> + memset(pps_payload, 0, sizeof(*pps_payload));
>  
>   /* PPS 0 */
> - pps_sdp->pps_payload.dsc_version =
> + pps_payload->dsc_version =
>   dsc_cfg->dsc_version_minor |
>   dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
>  
>   /* PPS 1, 2 is 0 */
>  
>   /* PPS 3 */
> - pps_sdp->pps_payload.pps_3 =
> + pps_payload->pps_3 =
>   dsc_cfg->line_buf_depth |
>   dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
>  
>   /* PPS 4 */
> - pps_sdp->pps_payload.pps_4 =
> +

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Chris Wilson

Quoting Tvrtko Ursulin (2019-02-25 17:59:40)
> 
> On 25/02/2019 16:23, Chris Wilson wrote:
> >   static inline struct i915_priolist *to_priolist(struct rb_node *rb)
> >   {
> >   return rb_entry(rb, struct i915_priolist, node);
> > @@ -2206,6 +2212,10 @@ static u32 *gen8_emit_fini_breadcrumb(struct 
> > i915_request *request, u32 *cs)
> > request->fence.seqno,
> > request->timeline->hwsp_offset);
> >   
> > + cs = gen8_emit_ggtt_write(cs,
> > +   
> > intel_engine_next_hangcheck_seqno(request->engine),
> > +   
> > intel_hws_hangcheck_address(request->engine));
> > +
> >   cs = gen8_emit_ggtt_write(cs,
> > request->global_seqno,
> > intel_hws_seqno_address(request->engine));
> > @@ -2230,6 +2240,11 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct 
> > i915_request *request, u32 *cs)
> > PIPE_CONTROL_FLUSH_ENABLE |
> > PIPE_CONTROL_CS_STALL);
> >   
> > + cs = gen8_emit_ggtt_write_rcs(cs,
> > +   
> > intel_engine_next_hangcheck_seqno(request->engine),
> > +   
> > intel_hws_hangcheck_address(request->engine),
> > +   PIPE_CONTROL_CS_STALL);
> 
> Are CS_STALL needed on two writes or only last one would be enough? Or 
> even, should all flushes be moved to the last pipe control?

The CS_STALL is overkill as there's no requirement for it to be before
the global_seqno, but the convenience and ease to reason over win.

> > +
> >   cs = gen8_emit_ggtt_write_rcs(cs,
> > request->global_seqno,
> > 
> > intel_hws_seqno_address(request->engine),
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 7f841dba87b3..870184bbd169 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -43,6 +43,12 @@
> >*/
> >   #define LEGACY_REQUEST_SIZE 200
> >   
> > +static inline u32 hws_hangcheck_address(struct intel_engine_cs *engine)
> > +{
> > + return (i915_ggtt_offset(engine->status_page.vma) +
> > + I915_GEM_HWS_HANGCHECK_ADDR);
> > +}
> > +
> 
> You can consolidate by putting the previous copy in a header.

Inline spaghetti means it didn't go where I wanted and I purposely moved
these address computation to their users so that I can kill them off,
one by one. As is the plan even for the new hangcheck seqno.
 
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > index 5d45ad4ecca9..2869aaa9d225 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > @@ -6,6 +6,7 @@
> >   
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   
> >   #include "i915_gem_batch_pool.h"
> > @@ -119,7 +120,8 @@ struct intel_instdone {
> >   
> >   struct intel_engine_hangcheck {
> >   u64 acthd;
> > - u32 seqno;
> > + u32 last_seqno;
> > + u32 next_seqno;
> 
> Reading the code I got the impression:
> 
> s/last_seqno/hangcheck_seqno/
> s/next_seqno/last_seqno/
> 
> Could be closer to reality. But your choice.

hangcheck.last_seqno,
hangcheck.next_seqno

hangcheck.hangcheck_seqno? Nah.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_switch: Use minimum qlen over all engines and measure switches

2019-02-25 Thread Chris Wilson

Quoting Caz Yokoyama (2019-02-25 18:28:34)
> Chris,
> By your patch, measure_qlen() reports how many gem_execbuf() can be
> executed(queue length) within timeout of the slowest engine, correct?

More or less, yes.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_switch: Use minimum qlen over all engines and measure switches

2019-02-25 Thread Caz Yokoyama

Chris,
By your patch, measure_qlen() reports how many gem_execbuf() can be
executed(queue length) within timeout of the slowest engine, correct?

Run time becomes 95 sec which is less than half.
-caz

On Sat, 2019-02-23 at 01:34 +, Chris Wilson wrote:
> Not all engines are created equal, and our weighting ends up
> favouring
> the many faster xCS rings at the expense of RCS. Our qlen estimation
> also failed to factor in the context switch overhead, which is a
> significant factor for nop batches. So we oversubscribe the number of
> batches submitted to RCS and end up waiting for those to complete at
> the
> end of our subtest timeslice.
> 
> Signed-off-by: Chris Wilson 
> Cc: Caz Yokoyama 
> ---
>  tests/i915/gem_ctx_switch.c | 39 +
> 
>  1 file changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/tests/i915/gem_ctx_switch.c
> b/tests/i915/gem_ctx_switch.c
> index 1208cb8d7..87e13b915 100644
> --- a/tests/i915/gem_ctx_switch.c
> +++ b/tests/i915/gem_ctx_switch.c
> @@ -26,6 +26,7 @@
>   */
>  
>  #include "igt.h"
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -58,29 +59,50 @@ static int measure_qlen(int fd,
>  {
>   const struct drm_i915_gem_exec_object2 * const obj =
>   (struct drm_i915_gem_exec_object2 *)(uintptr_t)execbuf-
> >buffers_ptr;
> - int qlen = 64;
> + uint32_t ctx[64];
> + int min = INT_MAX, max = 0;
> +
> + for (int i = 0; i < ARRAY_SIZE(ctx); i++)
> + ctx[i] = gem_context_create(fd);
>  
>   for (unsigned int n = 0; n < nengine; n++) {
>   uint64_t saved = execbuf->flags;
>   struct timespec tv = {};
> + int q;
>  
>   execbuf->flags |= engine[n];
>  
> - igt_nsec_elapsed();
> - for (int loop = 0; loop < qlen; loop++)
> + for (int i = 0; i < ARRAY_SIZE(ctx); i++) {
> + execbuf->rsvd1 = ctx[i];
>   gem_execbuf(fd, execbuf);
> + }
>   gem_sync(fd, obj->handle);
>  
> - execbuf->flags = saved;
> + igt_nsec_elapsed();
> + for (int i = 0; i < ARRAY_SIZE(ctx); i++) {
> + execbuf->rsvd1 = ctx[i];
> + gem_execbuf(fd, execbuf);
> + }
> + gem_sync(fd, obj->handle);
>  
>   /*
>* Be conservative and aim not to overshoot timeout, so
> scale
>* down by 8 for hopefully a max of 12.5% error.
>*/
> - qlen = qlen * timeout * 1e9 / igt_nsec_elapsed() / 8
> + 1;
> + q = ARRAY_SIZE(ctx) * timeout * 1e9 /
> igt_nsec_elapsed() / 8 + 1;
> + if (q < min)
> + min = q;
> + if (q > max)
> + max = q;
> +
> + execbuf->flags = saved;
>   }
>  
> - return qlen;
> + for (int i = 0; i < ARRAY_SIZE(ctx); i++)
> + gem_context_destroy(fd, ctx[i]);
> +
> + igt_debug("Estimated qlen: {min:%d, max:%d}\n", min, max);
> + return min;
>  }
>  
>  static void single(int fd, uint32_t handle,
> @@ -259,9 +281,10 @@ static void all(int fd, uint32_t handle,
> unsigned flags, int timeout)
>   clock_gettime(CLOCK_MONOTONIC, );
>   gem_close(fd, obj[0].handle);
>  
> - igt_info("[%d:%d] %s: %'u cycles:
> %.3fus%s\n",
> + igt_info("[%d:%d] %s: %'u cycles:
> %.3fus%s (elapsed: %.3fs)\n",
>nctx, child, name[child],
> count, elapsed(, )*1e6 / count,
> -  flags & INTERRUPTIBLE ? "
> (interruptible)" : "");
> +  flags & INTERRUPTIBLE ? "
> (interruptible)" : "",
> +  elapsed(, ));
>   }
>   igt_waitchildren();
>   }

___
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: Infoframe precompute/check (rev7)

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/i915: Infoframe precompute/check (rev7)
URL   : https://patchwork.freedesktop.org/series/49983/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12299


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/49983/revisions/7/mbox/

Known issues


  Here are the changes found in Patchwork_12299 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182] +1

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   PASS -> FAIL [fdo#109485]

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  PASS -> FAIL [fdo#103167]

  
 Possible fixes 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


Build changes
-

* Linux: CI_DRM_5659 -> Patchwork_12299

  CI_DRM_5659: bffea990c63087245e8501df82fd45f24ce6ad1f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12299: 228cad2fa0b96a2e4e48b9944f43554b8b958d7b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

228cad2fa0b9 drm/i915: Include infoframes in the crtc state dump
08d95fcdb6ea drm/i915: Check infoframe state in intel_pipe_config_compare()
3ad210dfb39b drm/i915/sdvo: Read out HDMI infoframes
ad8cf7975260 drm/i915/sdvo: Precompute HDMI infoframes
9fc2f454a7ed drm/i915: Read out HDMI infoframes
f16c369b24c9 drm/i915: Precompute HDMI infoframes
5de4323d1819 drm/i915: Store mask of enabled infoframes in the crtc state
30b2e77d815b drm/i915: Return the mask of enabled infoframes from 
->inforame_enabled()
f1e068bf9522 drm/i915: Add the missing HDMI gamut metadata packet stuff

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Make user contexts bannable again!

2019-02-25 Thread Sasha Levin

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 6095868a271d drm/i915: Complete kerneldoc for struct 
i915_gem_context.

The bot has tested the following trees: v4.20.11, v4.19.24, v4.14.102.

v4.20.11: Failed to apply! Possible dependencies:
7651a4452ddf ("drm/i915: Reserve some priority bits for internal use")

v4.19.24: Failed to apply! Possible dependencies:
7651a4452ddf ("drm/i915: Reserve some priority bits for internal use")

v4.14.102: Failed to apply! Possible dependencies:
0a53bc07f044 ("drm/i915/gvt: Separate cmd scan from request allocation")
0cce2823ed37 ("drm/i915/gvt: Refine error handling for 
prepare_execlist_workload")
1406a14b0ed9 ("drm/i915/gvt: Introduce intel_vgpu_submission")
1603660b3342 ("drm/i915/gvt: set max priority for gvt context")
465c403cb508 ("drm/i915: introduce simple gemfs")
54cff6479fd8 ("drm/i915/gvt: Make elsp_dwords in the right order")
7651a4452ddf ("drm/i915: Reserve some priority bits for internal use")
9a9829e9eb8b ("drm/i915/gvt: Move workload cache init/clean into 
intel_vgpu_{setup, clean}_submission()")
a3cfdca920b2 ("drm/i915/gvt: Add error handling for 
intel_gvt_scan_and_shadow_workload")
b7268c5eed0a ("drm/i915: Pack params to engine->schedule() into a struct")
d8235b5e5584 ("drm/i915/gvt: Move common workload preparation into 
prepare_workload()")
e61e0f51ba79 ("drm/i915: Rename drm_i915_gem_request to i915_request")
e91ef99b9543 ("drm/i915/selftests: Remember to create the fake preempt 
context")
f2880e04f3a5 ("drm/i915/gvt: Move request alloc to dispatch_workload path 
only")


How should we proceed with this patch?

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Infoframe precompute/check (rev7)

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/i915: Infoframe precompute/check (rev7)
URL   : https://patchwork.freedesktop.org/series/49983/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add the missing HDMI gamut metadata packet stuff
Okay!

Commit: drm/i915: Return the mask of enabled infoframes from 
->inforame_enabled()
Okay!

Commit: drm/i915: Store mask of enabled infoframes in the crtc state
Okay!

Commit: drm/i915: Precompute HDMI infoframes
Okay!

Commit: drm/i915: Read out HDMI infoframes
Okay!

Commit: drm/i915/sdvo: Precompute HDMI infoframes
Okay!

Commit: drm/i915/sdvo: Read out HDMI infoframes
+drivers/gpu/drm/i915/intel_sdvo.c:1020:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_sdvo.c:1020:21: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_sdvo.c:1026:47: warning: expression using 
sizeof(void)

Commit: drm/i915: Check infoframe state in intel_pipe_config_compare()
Okay!

Commit: drm/i915: Include infoframes in the crtc state dump
Okay!

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Infoframe precompute/check (rev7)

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/i915: Infoframe precompute/check (rev7)
URL   : https://patchwork.freedesktop.org/series/49983/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f1e068bf9522 drm/i915: Add the missing HDMI gamut metadata packet stuff
-:45: WARNING:LONG_LINE: line over 100 characters
#45: FILE: drivers/gpu/drm/i915/i915_reg.h:8141:
+#define HSW_TVIDEO_DIP_GMP_DATA(trans, i)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)

total: 0 errors, 1 warnings, 0 checks, 64 lines checked
30b2e77d815b drm/i915: Return the mask of enabled infoframes from 
->inforame_enabled()
5de4323d1819 drm/i915: Store mask of enabled infoframes in the crtc state
f16c369b24c9 drm/i915: Precompute HDMI infoframes
9fc2f454a7ed drm/i915: Read out HDMI infoframes
ad8cf7975260 drm/i915/sdvo: Precompute HDMI infoframes
3ad210dfb39b drm/i915/sdvo: Read out HDMI infoframes
08d95fcdb6ea drm/i915: Check infoframe state in intel_pipe_config_compare()
-:71: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible 
side-effects?
#71: FILE: drivers/gpu/drm/i915/intel_display.c:12093:
+#define PIPE_CONF_CHECK_INFOFRAME(name) do { \
+   if (!intel_compare_infoframe(_config->infoframes.name, \
+_config->infoframes.name)) { \
+   pipe_config_infoframe_err(dev_priv, adjust, __stringify(name), \
+ _config->infoframes.name, \
+ _config->infoframes.name); \
+   ret = false; \
+   } \
+} while (0)

total: 0 errors, 0 warnings, 1 checks, 67 lines checked
228cad2fa0b9 drm/i915: Include infoframes in the crtc state dump

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Tvrtko Ursulin



On 25/02/2019 16:23, Chris Wilson wrote:

To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests will then be completed, we use a primitive random number
generator instead (with a cycle long enough to not matter over an
interval of a few thousand requests between hangcheck samples).

The alternative to using a dedicated seqno on every request is to issue
a heartbeat request and query its progress through the system. Sadly
this requires us to reduce struct_mutex so that we can issue requests
without requiring that bkl.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_debugfs.c |  7 ++---
  drivers/gpu/drm/i915/intel_engine_cs.c  |  5 ++--
  drivers/gpu/drm/i915/intel_hangcheck.c  |  6 ++---
  drivers/gpu/drm/i915/intel_lrc.c| 15 +++
  drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
  drivers/gpu/drm/i915/intel_ringbuffer.h | 19 -
  6 files changed, 77 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 37175414ce89..545091a5180b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1295,7 +1295,7 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
with_intel_runtime_pm(dev_priv, wakeref) {
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
-   seqno[id] = intel_engine_get_seqno(engine);
+   seqno[id] = intel_engine_get_hangcheck_seqno(engine);
}
  
  		intel_engine_get_instdone(dev_priv->engine[RCS], );

@@ -1315,8 +1315,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
-  engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
+  engine->hangcheck.last_seqno,
+  seqno[id],
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies -

engine->hangcheck.action_timestamp));
  
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c

index 81b80f8fd9ea..57bc5c4fb3ff 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1497,10 +1497,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_reset_failed(engine->i915))
drm_printf(m, "*** WEDGED ***\n");
  
-	drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",

+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x/%x [%d ms]\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
-  engine->hangcheck.seqno,
+  engine->hangcheck.last_seqno,
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 9be033b6f4d2..f1d8dfc58049 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -133,21 +133,21 @@ static void hangcheck_load_sample(struct intel_engine_cs 
*engine,
  struct hangcheck *hc)
  {
hc->acthd = intel_engine_get_active_head(engine);
-   hc->seqno = intel_engine_get_seqno(engine);
+   hc->seqno = intel_engine_get_hangcheck_seqno(engine);
  }
  
  static void hangcheck_store_sample(struct intel_engine_cs *engine,

   const struct hangcheck *hc)
  {
engine->hangcheck.acthd = hc->acthd;
-   engine->hangcheck.seqno = hc->seqno;
+   engine->hangcheck.last_seqno = hc->seqno;
  }
  
  static enum intel_engine_hangcheck_action

  hangcheck_get_action(struct intel_engine_cs *engine,
 const struct hangcheck *hc)
  {
-   if (engine->hangcheck.seqno != hc->seqno)
+   if (engine->hangcheck.last_seqno != hc->seqno)
return ENGINE_ACTIVE_SEQNO;
  
  	if (intel_engine_is_idle(engine))

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 34a0866959c5..c134b3ca2df3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -178,6 +178,12 @@

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Patchwork

== Series Details ==

Series: series starting with [1/4] drm/i915: Replace global_seqno with a 
hangcheck heartbeat seqno
URL   : https://patchwork.freedesktop.org/series/57203/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12298


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57203/revisions/1/mbox/

Known issues


  Here are the changes found in Patchwork_12298 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  PASS -> FAIL [fdo#103167]

  
 Possible fixes 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


Build changes
-

* Linux: CI_DRM_5659 -> Patchwork_12298

  CI_DRM_5659: bffea990c63087245e8501df82fd45f24ce6ad1f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12298: 1acf3a7fbe863dd5b61ca34a8be20624f204a266 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1acf3a7fbe86 drm/i915/selftests: Exercise resetting during non-user payloads
1ed97126d8c7 drm/i915: Remove i915_request.global_seqno
23e70de4520a drm/i915: Remove access to global seqno in the HWSP
0e4e62c64045 drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

== Logs ==

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

Re: [Intel-gfx] [PATCH v15 00/16] drm/i915: Implement HDCP2.2

2019-02-25 Thread Daniel Vetter

On Mon, Feb 25, 2019 at 03:13:04PM +, Winkler, Tomas wrote:
> > On Mon, Feb 25, 2019 at 05:12:09AM +, C, Ramalingam wrote:
> > > Tomas,
> > >
> > > Lkp issue is complaining about the header
> > > drm/i915_mei_hdcp_interface.h, Which is already merged in drm-tip
> > > through below commit. So don’t think this is a genuine issue. May be
> > > this build was tried in different tree, where this commit is not added 
> > > yet?
> > 
> > Yeah our topic trees aren't pushed into linux-next, 0day can't find them.
> > Usually it will then fail to apply (and in that case it doesn't complain), 
> > but it
> > does complain if everything applies but doesn't build.
> > -Daniel
> > 
> > >
> > > commit 1626eab70ebc61d015e69a4bc3479d9228539343
> > > Author: Ramalingam C 
> > > Date:   Fri Feb 15 14:04:58 2019 +0530
> > >
> > > drm/i915: header for i915 - MEI_HDCP interface
> > >
> > > v15 is now part of github.
> 
> I'm okay to go with this.

Ok, merged all the 15 patches into a topic branch. Assuming nothing goes
wrong I'll send a pull to Greg tomorrow. And then it's up to him to take
it for 5.1 or delay for 5.2.

Thanks a lot for patches
-Daniel

> Thanks
> Tomas
> 
> > >
> > > Best Regards,
> > > Ramalingam C
> > >
> > >
> > > > -Original Message-
> > > > From: Winkler, Tomas
> > > > Sent: Monday, February 25, 2019 1:45 AM
> > > > To: C, Ramalingam ;
> > > > intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > > > daniel.vet...@ffwll.ch; Shankar, Uma 
> > > > Subject: RE: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
> > > >
> > > > Have you fixed the lkp issue?
> > > > I didn't see you pushed the code to github.
> > > > Thanks
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: C, Ramalingam
> > > > > Sent: Sunday, February 24, 2019 18:33
> > > > > To: intel-gfx@lists.freedesktop.org;
> > > > > dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Winkler,
> > > > > Tomas ; Shankar, Uma
> > > > > 
> > > > > Subject: Re: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
> > > > >
> > > > > Tomas,
> > > > >
> > > > > Could you please help to review and give final "Go" for the series?
> > > > >
> > > > > Thanks
> > > > > --Ram.
> > > > >
> > > > > On 2/21/2019 11:41 PM, Ramalingam C wrote:
> > > > > > This series enables the HDCP2.2 Type 0 for I915. The sequence
> > > > > > for
> > > > > > HDCP2.2 authentication and encryption is implemented as a
> > > > > > generic flow between HDMI and DP. Encoder specific
> > > > > > implementations are moved into hdcp_shim.
> > > > > >
> > > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series
> > > > > > introduces a client driver for mei bus, so that for HDCP2.2
> > > > > > authentication,
> > > > > > HDCP2.2 stack in I915 can avail the services from ME FW. To
> > > > > > enable this client driver set the config variable
> > CONFIG_INTEL_MEI_HDCP.
> > > > > >
> > > > > > Userspace interface remains unchanged as version agnostic. When
> > > > > > userspace request for HDCP enable, Kernel will detect the HDCP
> > > > > > source and sink's HDCP version(1.4/2.2)capability and enable the
> > > > > > best capable version for that combination.
> > > > > >
> > > > > > This series enables the HDCP2.2 for Type0 content streams.
> > > > > >
> > > > > > Test-with:
> > > > > > <1549566452-30175-1-git-send-email-ramalinga...@intel.com>
> > > > > > So that CP will be tested on BAT machine too.
> > > > > >
> > > > > > Major changes in v15
> > > > > >- All I915 patches are merged. So dropping them.
> > > > > >- Few minor suggestions are incorporated at mei changes.
> > > > > >
> > > > > > To ease the review process, series is hosted at
> > > > > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v15
> > > > > >
> > > > > > Ramalingam C (15):
> > > > > >misc/mei/hdcp: Client driver for HDCP application
> > > > > >misc/mei/hdcp: Define ME FW interface for HDCP2.2
> > > > > >misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> > > > > >misc/mei/hdcp: Verify Receiver Cert and prepare km
> > > > > >misc/mei/hdcp: Verify H_prime
> > > > > >misc/mei/hdcp: Store the HDCP Pairing info
> > > > > >misc/mei/hdcp: Initiate Locality check
> > > > > >misc/mei/hdcp: Verify L_prime
> > > > > >misc/mei/hdcp: Prepare Session Key
> > > > > >misc/mei/hdcp: Repeater topology verification and ack
> > > > > >misc/mei/hdcp: Verify M_prime
> > > > > >misc/mei/hdcp: Enabling the HDCP authentication
> > > > > >misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
> > > > > >misc/mei/hdcp: Component framework for I915 Interface
> > > > > >FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915
> > > > > >
> > > > > > Tomas Winkler (1):
> > > > > >mei: bus: whitelist hdcp client
> > > > > >
> > > > > >   drivers/misc/mei/Kconfig |  11 +
> > > > > >   drivers/misc/mei/Makefile|   2 +
> > > > > >   drivers/misc/mei/bus-fixup.c |  16 +
> > > > > >   drivers/misc/mei/hdcp/Makefile

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove i915_request.global_seqno

2019-02-25 Thread Tvrtko Ursulin



On 25/02/2019 16:23, Chris Wilson wrote:

Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gpu_error.c | 34 ++---
  drivers/gpu/drm/i915/i915_gpu_error.h |  2 -
  drivers/gpu/drm/i915/i915_request.c   | 34 ++---
  drivers/gpu/drm/i915/i915_request.h   | 32 
  drivers/gpu/drm/i915/i915_trace.h | 25 +++---
  drivers/gpu/drm/i915/intel_engine_cs.c|  5 +-
  drivers/gpu/drm/i915/intel_guc_submission.c   |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c  | 34 ++---
  drivers/gpu/drm/i915/intel_ringbuffer.c   | 50 +++
  drivers/gpu/drm/i915/intel_ringbuffer.h   |  2 -
  .../gpu/drm/i915/selftests/intel_hangcheck.c  |  5 +-
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  1 -
  12 files changed, 32 insertions(+), 194 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 061a767e3bed..fa86c60fb56c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -380,19 +380,16 @@ static void print_error_buffers(struct 
drm_i915_error_state_buf *m,
err_printf(m, "%s [%d]:\n", name, count);
  
  	while (count--) {

-   err_printf(m, "%08x_%08x %8u %02x %02x %02x",
+   err_printf(m, "%08x_%08x %8u %02x %02x",
   upper_32_bits(err->gtt_offset),
   lower_32_bits(err->gtt_offset),
   err->size,
   err->read_domains,
-  err->write_domain,
-  err->wseqno);
+  err->write_domain);
err_puts(m, tiling_flag(err->tiling));
err_puts(m, dirty_flag(err->dirty));
err_puts(m, purgeable_flag(err->purgeable));
err_puts(m, err->userptr ? " userptr" : "");
-   err_puts(m, err->engine != -1 ? " " : "");
-   err_puts(m, engine_name(m->i915, err->engine));
err_puts(m, i915_cache_level_str(m->i915, err->cache_level));
  
  		if (err->name)

@@ -1048,27 +1045,6 @@ i915_error_object_create(struct drm_i915_private *i915,
return dst;
  }
  
-/* The error capture is special as tries to run underneath the normal

- * locking rules - so we use the raw version of the i915_active_request lookup.
- */
-static inline u32
-__active_get_seqno(struct i915_active_request *active)
-{
-   struct i915_request *request;
-
-   request = __i915_active_request_peek(active);
-   return request ? request->global_seqno : 0;
-}
-
-static inline int
-__active_get_engine_id(struct i915_active_request *active)
-{
-   struct i915_request *request;
-
-   request = __i915_active_request_peek(active);
-   return request ? request->engine->id : -1;
-}
-
  static void capture_bo(struct drm_i915_error_buffer *err,
   struct i915_vma *vma)
  {
@@ -1077,9 +1053,6 @@ static void capture_bo(struct drm_i915_error_buffer *err,
err->size = obj->base.size;
err->name = obj->base.name;
  
-	err->wseqno = __active_get_seqno(>frontbuffer_write);

-   err->engine = __active_get_engine_id(>frontbuffer_write);
-
err->gtt_offset = vma->node.start;
err->read_domains = obj->read_domains;
err->write_domain = obj->write_domain;
@@ -1284,7 +1257,8 @@ static void record_request(struct i915_request *request,
struct i915_gem_context *ctx = request->gem_context;
  
  	erq->flags = request->fence.flags;

-   erq->context = ctx->hw_id;
+   erq->context = request->fence.context;
+   erq->seqno = request->fence.seqno;
erq->sched_attr = request->sched.attr;
erq->jiffies = request->emitted_jiffies;
erq->start = i915_ggtt_offset(request->ring->vma);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 19ac102afaff..8c1569c1830d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -164,7 +164,6 @@ struct i915_gpu_state {
struct drm_i915_error_buffer {
u32 size;
u32 name;
-   u32 wseqno;
u64 gtt_offset;
u32 read_domains;
u32 write_domain;
@@ -173,7 +172,6 @@ struct i915_gpu_state {
u32 dirty:1;
u32 purgeable:1;
u32 userptr:1;
-   s32 engine:4;
u32 cache_level:3;
} *active_bo[I915_NUM_ENGINES], *pinned_bo;
u32 active_bo_count[I915_NUM_ENGINES], pinned_bo_count;
diff --git a/drivers/gpu/drm/i915/i915_request.c

[Intel-gfx] [PATCH v3 3/9] drm/i915: Store mask of enabled infoframes in the crtc state

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Store the mask of enabled infoframes in the crtc state. We'll start
with just the readout for HDMI encoder, and we'll expand this
to compute the bitmask in .compute_config() later. SDVO will also
follow later.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 5 -
 drivers/gpu/drm/i915/intel_drv.h  | 4 
 drivers/gpu/drm/i915/intel_hdmi.c | 5 -
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e77cea3d5989..a5c6731c1e99 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3764,7 +3764,10 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->has_hdmi_sink = true;
intel_dig_port = enc_to_dig_port(>base);
 
-   if (intel_hdmi_infoframes_enabled(encoder, pipe_config))
+   pipe_config->infoframes.enable |=
+   intel_hdmi_infoframes_enabled(encoder, pipe_config);
+
+   if (pipe_config->infoframes.enable)
pipe_config->has_infoframe = true;
 
if (temp & TRANS_DDI_HDMI_SCRAMBLING)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 99abeab46f9d..ea8cd792657d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1031,6 +1031,10 @@ struct intel_crtc_state {
/* bitmask of planes that will be updated during the commit */
u8 update_planes;
 
+   struct {
+   u32 enable;
+   } infoframes;
+
/* HDMI scrambling status */
bool hdmi_scrambling;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 298e8ae9e2ad..be3f7fac4e44 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1509,7 +1509,10 @@ static void intel_hdmi_get_config(struct intel_encoder 
*encoder,
if (tmp & HDMI_MODE_SELECT_HDMI)
pipe_config->has_hdmi_sink = true;
 
-   if (intel_hdmi_infoframes_enabled(encoder, pipe_config))
+   pipe_config->infoframes.enable |=
+   intel_hdmi_infoframes_enabled(encoder, pipe_config);
+
+   if (pipe_config->infoframes.enable)
pipe_config->has_infoframe = true;
 
if (tmp & SDVO_AUDIO_ENABLE)
-- 
2.19.2

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

[Intel-gfx] [PATCH v3 8/9] drm/i915: Check infoframe state in intel_pipe_config_compare()

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Check the infoframes and infoframe enable state when comparing two
crtc states.

We'll use the infoframe logging functions from video/hdmi.c to
show the infoframes as part of the state dump.

TODO: Try to better integrate the infoframe dumps with
  drm state dumps

v2: drm_printk() is no more

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 49 +++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b1d63c32ca94..fe65d0f82652 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11876,6 +11876,37 @@ intel_compare_link_m_n(const struct intel_link_m_n 
*m_n,
return false;
 }
 
+static bool
+intel_compare_infoframe(const union hdmi_infoframe *a,
+   const union hdmi_infoframe *b)
+{
+   return memcmp(a, b, sizeof(*a)) == 0;
+}
+
+static void
+pipe_config_infoframe_err(struct drm_i915_private *dev_priv,
+ bool adjust, const char *name,
+ const union hdmi_infoframe *a,
+ const union hdmi_infoframe *b)
+{
+   if (adjust) {
+   if ((drm_debug & DRM_UT_KMS) == 0)
+   return;
+
+   drm_dbg(DRM_UT_KMS, "mismatch in %s infoframe", name);
+   drm_dbg(DRM_UT_KMS, "expected:");
+   hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, a);
+   drm_dbg(DRM_UT_KMS, "found");
+   hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, b);
+   } else {
+   drm_err("mismatch in %s infoframe", name);
+   drm_err("expected:");
+   hdmi_infoframe_log(KERN_ERR, dev_priv->drm.dev, a);
+   drm_err("found");
+   hdmi_infoframe_log(KERN_ERR, dev_priv->drm.dev, b);
+   }
+}
+
 static void __printf(3, 4)
 pipe_config_err(bool adjust, const char *name, const char *format, ...)
 {
@@ -12059,7 +12090,17 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
} \
 } while (0)
 
-#define PIPE_CONF_QUIRK(quirk) \
+#define PIPE_CONF_CHECK_INFOFRAME(name) do { \
+   if (!intel_compare_infoframe(_config->infoframes.name, \
+_config->infoframes.name)) { \
+   pipe_config_infoframe_err(dev_priv, adjust, __stringify(name), \
+ _config->infoframes.name, \
+ _config->infoframes.name); \
+   ret = false; \
+   } \
+} while (0)
+
+#define PIPE_CONF_QUIRK(quirk) \
((current_config->quirks | pipe_config->quirks) & (quirk))
 
PIPE_CONF_CHECK_I(cpu_transcoder);
@@ -12192,6 +12233,12 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
 
PIPE_CONF_CHECK_I(min_voltage_level);
 
+   PIPE_CONF_CHECK_X(infoframes.enable);
+   PIPE_CONF_CHECK_X(infoframes.gcp);
+   PIPE_CONF_CHECK_INFOFRAME(avi);
+   PIPE_CONF_CHECK_INFOFRAME(spd);
+   PIPE_CONF_CHECK_INFOFRAME(hdmi);
+
 #undef PIPE_CONF_CHECK_X
 #undef PIPE_CONF_CHECK_I
 #undef PIPE_CONF_CHECK_BOOL
-- 
2.19.2

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

[Intel-gfx] [PATCH v3 5/9] drm/i915: Read out HDMI infoframes

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Add code to read the infoframes from the video DIP and unpack them into
the crtc state.

v2: Make the read funcs return void (Daniel)
Drop the duplicate infoframe enabled checks (Daniel)
Add a FIXME for lspcon infoframe readout

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_ddi.c|  12 ++
 drivers/gpu/drm/i915/intel_drv.h|  14 +++
 drivers/gpu/drm/i915/intel_hdmi.c   | 172 
 drivers/gpu/drm/i915/intel_lspcon.c |   8 ++
 4 files changed, 206 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a5c6731c1e99..d918be927fc2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3831,6 +3831,18 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
bxt_ddi_phy_get_lane_lat_optim_mask(encoder);
 
intel_ddi_compute_min_voltage_level(dev_priv, pipe_config);
+
+   intel_hdmi_read_gcp_infoframe(encoder, pipe_config);
+
+   intel_read_infoframe(encoder, pipe_config,
+HDMI_INFOFRAME_TYPE_AVI,
+_config->infoframes.avi);
+   intel_read_infoframe(encoder, pipe_config,
+HDMI_INFOFRAME_TYPE_SPD,
+_config->infoframes.spd);
+   intel_read_infoframe(encoder, pipe_config,
+HDMI_INFOFRAME_TYPE_VENDOR,
+_config->infoframes.hdmi);
 }
 
 static enum intel_output_type
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 42b0c91f20d3..5412373e2f98 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1353,6 +1353,10 @@ struct intel_digital_port {
const struct intel_crtc_state *crtc_state,
unsigned int type,
const void *frame, ssize_t len);
+   void (*read_infoframe)(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  unsigned int type,
+  void *frame, ssize_t len);
void (*set_infoframes)(struct intel_encoder *encoder,
   bool enable,
   const struct intel_crtc_state *crtc_state,
@@ -2096,6 +2100,12 @@ void intel_infoframe_init(struct intel_digital_port 
*intel_dig_port);
 u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state);
 u32 intel_hdmi_infoframe_enable(unsigned int type);
+void intel_hdmi_read_gcp_infoframe(struct intel_encoder *encoder,
+  struct intel_crtc_state *crtc_state);
+void intel_read_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ enum hdmi_infoframe_type type,
+ union hdmi_infoframe *frame);
 
 /* intel_lvds.c */
 bool intel_lvds_port_enabled(struct drm_i915_private *dev_priv,
@@ -2509,6 +2519,10 @@ void lspcon_write_infoframe(struct intel_encoder 
*encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
const void *buf, ssize_t len);
+void lspcon_read_infoframe(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  unsigned int type,
+  void *frame, ssize_t len);
 void lspcon_set_infoframes(struct intel_encoder *encoder,
   bool enable,
   const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 76cd077d2924..cd422a7b4da0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -214,6 +214,26 @@ static void g4x_write_infoframe(struct intel_encoder 
*encoder,
POSTING_READ(VIDEO_DIP_CTL);
 }
 
+static void g4x_read_infoframe(struct intel_encoder *encoder,
+  const struct intel_crtc_state *crtc_state,
+  unsigned int type,
+  void *frame, ssize_t len)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   u32 val, *data = frame;
+   int i;
+
+   val = I915_READ(VIDEO_DIP_CTL);
+
+   val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
+   val |= g4x_infoframe_index(type);
+
+   I915_WRITE(VIDEO_DIP_CTL, val);
+
+   for (i = 0; i < len; i += 4)
+   *data++ = I915_READ(VIDEO_DIP_DATA);
+}
+
 static u32 g4x_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config)
 {

[Intel-gfx] [PATCH v3 4/9] drm/i915: Precompute HDMI infoframes

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Store the infoframes in the crtc state and precompute them in
.compute_config(). While precomputing we'll also fill out the
inforames.enable bitmask appropriately.

v2: Drop the null packet stuff (Daniel)
Add a FIXME for lspcon
v3: .compute_config() now returns int

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_drv.h|   5 +
 drivers/gpu/drm/i915/intel_hdmi.c   | 249 
 drivers/gpu/drm/i915/intel_lspcon.c |   2 +
 3 files changed, 186 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ea8cd792657d..42b0c91f20d3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1033,6 +1033,10 @@ struct intel_crtc_state {
 
struct {
u32 enable;
+   u32 gcp;
+   union hdmi_infoframe avi;
+   union hdmi_infoframe spd;
+   union hdmi_infoframe hdmi;
} infoframes;
 
/* HDMI scrambling status */
@@ -2091,6 +2095,7 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable);
 void intel_infoframe_init(struct intel_digital_port *intel_dig_port);
 u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state);
+u32 intel_hdmi_infoframe_enable(unsigned int type);
 
 /* intel_lvds.c */
 bool intel_lvds_port_enabled(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index be3f7fac4e44..76cd077d2924 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -457,6 +457,18 @@ static const u8 infoframe_type_to_idx[] = {
HDMI_INFOFRAME_TYPE_VENDOR,
 };
 
+u32 intel_hdmi_infoframe_enable(unsigned int type)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(infoframe_type_to_idx); i++) {
+   if (infoframe_type_to_idx[i] == type)
+   return BIT(i);
+   }
+
+   return 0;
+}
+
 u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state)
 {
@@ -502,15 +514,23 @@ u32 intel_hdmi_infoframes_enabled(struct intel_encoder 
*encoder,
  */
 static void intel_write_infoframe(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state,
- union hdmi_infoframe *frame)
+ enum hdmi_infoframe_type type,
+ const union hdmi_infoframe *frame)
 {
struct intel_digital_port *intel_dig_port = 
enc_to_dig_port(>base);
u8 buffer[VIDEO_DIP_DATA_SIZE];
ssize_t len;
 
+   if ((crtc_state->infoframes.enable &
+intel_hdmi_infoframe_enable(type)) == 0)
+   return;
+
+   if (WARN_ON(frame->any.type != type))
+   return;
+
/* see comment above for the reason for this offset */
-   len = hdmi_infoframe_pack(frame, buffer + 1, sizeof(buffer) - 1);
-   if (len < 0)
+   len = hdmi_infoframe_pack_only(frame, buffer + 1, sizeof(buffer) - 1);
+   if (WARN_ON(len < 0))
return;
 
/* Insert the 'hole' (see big comment above) at position 3 */
@@ -518,86 +538,112 @@ static void intel_write_infoframe(struct intel_encoder 
*encoder,
buffer[3] = 0;
len++;
 
-   intel_dig_port->write_infoframe(encoder,
-   crtc_state,
-   frame->any.type, buffer, len);
+   intel_dig_port->write_infoframe(encoder, crtc_state, type, buffer, len);
 }
 
-static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
-const struct intel_crtc_state 
*crtc_state,
-const struct drm_connector_state 
*conn_state)
+static bool
+intel_hdmi_compute_avi_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
 {
+   struct hdmi_avi_infoframe *frame = _state->infoframes.avi.avi;
const struct drm_display_mode *adjusted_mode =
_state->base.adjusted_mode;
-   union hdmi_infoframe frame;
+   struct drm_connector *connector = conn_state->connector;
int ret;
 
-   ret = drm_hdmi_avi_infoframe_from_display_mode(,
-  conn_state->connector,
+   if (!crtc_state->has_infoframe)
+   return true;
+
+   crtc_state->infoframes.enable |=
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+   ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector,

[Intel-gfx] [PATCH v3 7/9] drm/i915/sdvo: Read out HDMI infoframes

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Read the HDMI infoframes from the hbuf and unpack them into
the crtc state.

Well, actually just AVI infoframe for now but let's write the
infoframe readout code in a more generic fashion in case we
expand this later.

Note that Daniel was sceptical about the benefit if this and
also concerned about the potential for crappy sdvo encoders not
implementing the hbuf read commands. My (admittedly limited)
experience is that such encoders don't implement even the
get/set hdmi encoding commands and thus would always be treated
as dvi only. Hence I believe this is safe, and also IMO preferable
having quirks to deal with missing readout support. The readout
support is neatly isolated in the sdvo code whereas the quirk
would leak to other parts of the driver (state checker, fastboot,
etc.) thus complicating the lives of other people.

Signed-off-by: Ville Syrjälä 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 94 ++-
 1 file changed, 91 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 00551364d09e..68f497493d43 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -978,6 +978,58 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo 
*intel_sdvo,
_rate, 1);
 }
 
+static ssize_t intel_sdvo_read_infoframe(struct intel_sdvo *intel_sdvo,
+unsigned int if_index,
+u8 *data, unsigned int length)
+{
+   u8 set_buf_index[2] = { if_index, 0 };
+   u8 hbuf_size, tx_rate, av_split;
+   int i;
+
+   if (!intel_sdvo_get_value(intel_sdvo,
+ SDVO_CMD_GET_HBUF_AV_SPLIT,
+ _split, 1))
+   return -ENXIO;
+
+   if (av_split < if_index)
+   return 0;
+
+   if (!intel_sdvo_get_value(intel_sdvo,
+ SDVO_CMD_GET_HBUF_TXRATE,
+ _rate, 1))
+   return -ENXIO;
+
+   if (tx_rate == SDVO_HBUF_TX_DISABLED)
+   return 0;
+
+   if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_INDEX,
+ set_buf_index, 2))
+   return -ENXIO;
+
+   if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
+ _size, 1))
+   return -ENXIO;
+
+   /* Buffer size is 0 based, hooray! */
+   hbuf_size++;
+
+   DRM_DEBUG_KMS("reading sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
+ if_index, length, hbuf_size);
+
+   hbuf_size = min_t(unsigned int, length, hbuf_size);
+
+   for (i = 0; i < hbuf_size; i += 8) {
+   if (!intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HBUF_DATA, 
NULL, 0))
+   return -ENXIO;
+   if (!intel_sdvo_read_response(intel_sdvo, [i],
+ min_t(unsigned int, 8, hbuf_size 
- i)))
+   return -ENXIO;
+   }
+
+   return hbuf_size;
+}
+
 static bool intel_sdvo_compute_avi_infoframe(struct intel_sdvo *intel_sdvo,
 struct intel_crtc_state 
*crtc_state,
 struct drm_connector_state 
*conn_state)
@@ -1036,6 +1088,40 @@ static bool intel_sdvo_set_avi_infoframe(struct 
intel_sdvo *intel_sdvo,
  sdvo_data, sizeof(sdvo_data));
 }
 
+static void intel_sdvo_get_avi_infoframe(struct intel_sdvo *intel_sdvo,
+struct intel_crtc_state *crtc_state)
+{
+   u8 sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
+   union hdmi_infoframe *frame = _state->infoframes.avi;
+   ssize_t len;
+   int ret;
+
+   if (!crtc_state->has_hdmi_sink)
+   return;
+
+   len = intel_sdvo_read_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
+   sdvo_data, sizeof(sdvo_data));
+   if (len < 0) {
+   DRM_DEBUG_KMS("failed to read AVI infoframe\n");
+   return;
+   } else if (len == 0) {
+   return;
+   }
+
+   crtc_state->infoframes.enable |=
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+   ret = hdmi_infoframe_unpack(frame, sdvo_data, sizeof(sdvo_data));
+   if (ret) {
+   DRM_DEBUG_KMS("Failed to unpack AVI infoframe\n");
+   return;
+   }
+
+   if (frame->any.type != HDMI_INFOFRAME_TYPE_AVI)
+   DRM_DEBUG_KMS("Found the wrong infoframe type 0x%x (expected 
0x%02x)\n",
+ frame->any.type, HDMI_INFOFRAME_TYPE_AVI);
+}
+
 static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo,
 const struct

[Intel-gfx] [PATCH v3 9/9] drm/i915: Include infoframes in the crtc state dump

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Dump out the infoframes in the normal crtc state dump.

TODO: Try to better integrate the infoframe dumps with
  drm state dumps

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fe65d0f82652..7c5e84ef5171 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11406,6 +11406,16 @@ intel_dump_m_n_config(struct intel_crtc_state 
*pipe_config, char *id,
  m_n->link_m, m_n->link_n, m_n->tu);
 }
 
+static void
+intel_dump_infoframe(struct drm_i915_private *dev_priv,
+const union hdmi_infoframe *frame)
+{
+   if ((drm_debug & DRM_UT_KMS) == 0)
+   return;
+
+   hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
+}
+
 #define OUTPUT_TYPE(x) [INTEL_OUTPUT_ ## x] = #x
 
 static const char * const output_type_str[] = {
@@ -11509,6 +11519,22 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
DRM_DEBUG_KMS("audio: %i, infoframes: %i\n",
  pipe_config->has_audio, pipe_config->has_infoframe);
 
+   DRM_DEBUG_KMS("infoframes enabled: 0x%x\n",
+ pipe_config->infoframes.enable);
+
+   if (pipe_config->infoframes.enable &
+   intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GENERAL_CONTROL))
+   DRM_DEBUG_KMS("GCP: 0x%x\n", pipe_config->infoframes.gcp);
+   if (pipe_config->infoframes.enable &
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI))
+   intel_dump_infoframe(dev_priv, _config->infoframes.avi);
+   if (pipe_config->infoframes.enable &
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_SPD))
+   intel_dump_infoframe(dev_priv, _config->infoframes.spd);
+   if (pipe_config->infoframes.enable &
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_VENDOR))
+   intel_dump_infoframe(dev_priv, _config->infoframes.hdmi);
+
DRM_DEBUG_KMS("requested mode:\n");
drm_mode_debug_printmodeline(_config->base.mode);
DRM_DEBUG_KMS("adjusted mode:\n");
-- 
2.19.2

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

[Intel-gfx] [PATCH v3 6/9] drm/i915/sdvo: Precompute HDMI infoframes

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

As with regular HDMI encoders, let's precompute the infoframes
(actually just AVI infoframe for the time being) with SDVO HDMI
encoders.

v2: Drop the WARN_ON() from drm_hdmi_avi_infoframe_from_display_mode()
return since that could genuinely fail due to user asking
for incompatible aspect ratio
v3: .compute_config() now returns int

Signed-off-by: Ville Syrjälä 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 62 ++-
 1 file changed, 45 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index e7b0884ba5a5..00551364d09e 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -978,34 +978,57 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo 
*intel_sdvo,
_rate, 1);
 }
 
-static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
-const struct intel_crtc_state 
*pipe_config,
-const struct drm_connector_state 
*conn_state)
+static bool intel_sdvo_compute_avi_infoframe(struct intel_sdvo *intel_sdvo,
+struct intel_crtc_state 
*crtc_state,
+struct drm_connector_state 
*conn_state)
 {
+   struct hdmi_avi_infoframe *frame = _state->infoframes.avi.avi;
const struct drm_display_mode *adjusted_mode =
-   _config->base.adjusted_mode;
-   u8 sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
-   union hdmi_infoframe frame;
+   _state->base.adjusted_mode;
int ret;
-   ssize_t len;
 
-   ret = drm_hdmi_avi_infoframe_from_display_mode(,
+   if (!crtc_state->has_hdmi_sink)
+   return true;
+
+   crtc_state->infoframes.enable |=
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+   ret = drm_hdmi_avi_infoframe_from_display_mode(frame,
   conn_state->connector,
   adjusted_mode);
-   if (ret < 0) {
-   DRM_ERROR("couldn't fill AVI infoframe\n");
+   if (ret)
return false;
-   }
 
-   drm_hdmi_avi_infoframe_quant_range(,
+   drm_hdmi_avi_infoframe_quant_range(frame,
   conn_state->connector,
   adjusted_mode,
-  pipe_config->limited_color_range ?
+  crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
   HDMI_QUANTIZATION_RANGE_FULL);
 
-   len = hdmi_infoframe_pack(, sdvo_data, sizeof(sdvo_data));
-   if (len < 0)
+   ret = hdmi_avi_infoframe_check(frame);
+   if (WARN_ON(ret))
+   return false;
+
+   return true;
+}
+
+static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
+const struct intel_crtc_state 
*crtc_state)
+{
+   u8 sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
+   const union hdmi_infoframe *frame = _state->infoframes.avi;
+   ssize_t len;
+
+   if ((crtc_state->infoframes.enable &
+intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI)) == 0)
+   return true;
+
+   if (WARN_ON(frame->any.type != HDMI_INFOFRAME_TYPE_AVI))
+   return false;
+
+   len = hdmi_infoframe_pack_only(frame, sdvo_data, sizeof(sdvo_data));
+   if (WARN_ON(len < 0))
return false;
 
return intel_sdvo_write_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
@@ -1193,6 +1216,12 @@ static int intel_sdvo_compute_config(struct 
intel_encoder *encoder,
if (intel_sdvo_connector->is_hdmi)
adjusted_mode->picture_aspect_ratio = 
conn_state->picture_aspect_ratio;
 
+   if (!intel_sdvo_compute_avi_infoframe(intel_sdvo,
+ pipe_config, conn_state)) {
+   DRM_DEBUG_KMS("bad AVI infoframe\n");
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -1315,8 +1344,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder 
*intel_encoder,
intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_HDMI);
intel_sdvo_set_colorimetry(intel_sdvo,
   SDVO_COLORIMETRY_RGB256);
-   intel_sdvo_set_avi_infoframe(intel_sdvo,
-crtc_state, conn_state);
+   intel_sdvo_set_avi_infoframe(intel_sdvo, crtc_state);
} else
intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_DVI);
 
-- 
2.19.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH v3 2/9] drm/i915: Return the mask of enabled infoframes from ->inforame_enabled()

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

We want to start tracking which infoframes are enabled, so let's replace
the boolean flag with a bitmask.

We'll abstract the bitmask so that it's not platform dependent. That
will allow us to examine the bitmask later in platform independent code.

v2: Don't map VIDEO_DIP_ENABLE to the null packet (Daniel)
Put a FIXME in the lspcon function

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_ddi.c|  2 +-
 drivers/gpu/drm/i915/intel_drv.h|  6 ++-
 drivers/gpu/drm/i915/intel_hdmi.c   | 83 -
 drivers/gpu/drm/i915/intel_lspcon.c |  3 +-
 4 files changed, 65 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1355be8dec3b..e77cea3d5989 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3764,7 +3764,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->has_hdmi_sink = true;
intel_dig_port = enc_to_dig_port(>base);
 
-   if (intel_dig_port->infoframe_enabled(encoder, pipe_config))
+   if (intel_hdmi_infoframes_enabled(encoder, pipe_config))
pipe_config->has_infoframe = true;
 
if (temp & TRANS_DDI_HDMI_SCRAMBLING)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81ec73e4a083..99abeab46f9d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1349,7 +1349,7 @@ struct intel_digital_port {
   bool enable,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state);
-   bool (*infoframe_enabled)(struct intel_encoder *encoder,
+   u32 (*infoframes_enabled)(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config);
 };
 
@@ -2085,6 +2085,8 @@ bool intel_hdmi_handle_sink_scrambling(struct 
intel_encoder *encoder,
   bool scrambling);
 void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable);
 void intel_infoframe_init(struct intel_digital_port *intel_dig_port);
+u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state);
 
 /* intel_lvds.c */
 bool intel_lvds_port_enabled(struct drm_i915_private *dev_priv,
@@ -2502,7 +2504,7 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
   bool enable,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state);
-bool lspcon_infoframe_enabled(struct intel_encoder *encoder,
+u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config);
 void lspcon_ycbcr420_config(struct drm_connector *connector,
struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index b770d28cc5de..298e8ae9e2ad 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -103,6 +103,8 @@ static u32 g4x_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_GCP;
case HDMI_PACKET_TYPE_GAMUT_METADATA:
return VIDEO_DIP_ENABLE_GAMUT;
+   case DP_SDP_VSC:
+   return 0;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_ENABLE_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -212,17 +214,17 @@ static void g4x_write_infoframe(struct intel_encoder 
*encoder,
POSTING_READ(VIDEO_DIP_CTL);
 }
 
-static bool g4x_infoframe_enabled(struct intel_encoder *encoder,
+static u32 g4x_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 val = I915_READ(VIDEO_DIP_CTL);
 
if ((val & VIDEO_DIP_ENABLE) == 0)
-   return false;
+   return 0;
 
if ((val & VIDEO_DIP_PORT_MASK) != VIDEO_DIP_PORT(encoder->port))
-   return false;
+   return 0;
 
return val & (VIDEO_DIP_ENABLE_AVI |
  VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
@@ -267,7 +269,7 @@ static void ibx_write_infoframe(struct intel_encoder 
*encoder,
POSTING_READ(reg);
 }
 
-static bool ibx_infoframe_enabled(struct intel_encoder *encoder,
+static u32 ibx_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -276,10 +278,10 @@ static bool ibx_infoframe_enabled(struct

[Intel-gfx] [PATCH v3 1/9] drm/i915: Add the missing HDMI gamut metadata packet stuff

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

We have definitions and low level code for everything except the gamut
metadata HDMI packet. Add the missing bits.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_reg.h   |  8 +---
 drivers/gpu/drm/i915/intel_hdmi.c | 12 
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 730bb1917fd1..c9b482bc6433 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4649,13 +4649,14 @@ enum {
 #define   VIDEO_DIP_ENABLE (1 << 31)
 #define   VIDEO_DIP_PORT(port) ((port) << 29)
 #define   VIDEO_DIP_PORT_MASK  (3 << 29)
-#define   VIDEO_DIP_ENABLE_GCP (1 << 25)
+#define   VIDEO_DIP_ENABLE_GCP (1 << 25) /* ilk+ */
 #define   VIDEO_DIP_ENABLE_AVI (1 << 21)
 #define   VIDEO_DIP_ENABLE_VENDOR  (2 << 21)
-#define   VIDEO_DIP_ENABLE_GAMUT   (4 << 21)
+#define   VIDEO_DIP_ENABLE_GAMUT   (4 << 21) /* ilk+ */
 #define   VIDEO_DIP_ENABLE_SPD (8 << 21)
 #define   VIDEO_DIP_SELECT_AVI (0 << 19)
 #define   VIDEO_DIP_SELECT_VENDOR  (1 << 19)
+#define   VIDEO_DIP_SELECT_GAMUT   (2 << 19)
 #define   VIDEO_DIP_SELECT_SPD (3 << 19)
 #define   VIDEO_DIP_SELECT_MASK(3 << 19)
 #define   VIDEO_DIP_FREQ_ONCE  (0 << 16)
@@ -8133,10 +8134,11 @@ enum {
 #define _ICL_VIDEO_DIP_PPS_ECC_B   0x613D4
 
 #define HSW_TVIDEO_DIP_CTL(trans)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_CTL_A)
+#define HSW_TVIDEO_DIP_GCP(trans)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_GCP_A)
 #define HSW_TVIDEO_DIP_AVI_DATA(trans, i)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_AVI_DATA_A + (i) * 4)
 #define HSW_TVIDEO_DIP_VS_DATA(trans, i)   _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_VS_DATA_A + (i) * 4)
 #define HSW_TVIDEO_DIP_SPD_DATA(trans, i)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
-#define HSW_TVIDEO_DIP_GCP(trans)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_GCP_A)
+#define HSW_TVIDEO_DIP_GMP_DATA(trans, i)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
 #define HSW_TVIDEO_DIP_VSC_DATA(trans, i)  _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
 #define ICL_VIDEO_DIP_PPS_DATA(trans, i)   _MMIO_TRANS2(trans, 
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
 #define ICL_VIDEO_DIP_PPS_ECC(trans, i)_MMIO_TRANS2(trans, 
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6bd724c7a6de..b770d28cc5de 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -82,6 +82,8 @@ static struct intel_hdmi *intel_attached_hdmi(struct 
drm_connector *connector)
 static u32 g4x_infoframe_index(unsigned int type)
 {
switch (type) {
+   case HDMI_PACKET_TYPE_GAMUT_METADATA:
+   return VIDEO_DIP_SELECT_GAMUT;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_SELECT_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -97,6 +99,10 @@ static u32 g4x_infoframe_index(unsigned int type)
 static u32 g4x_infoframe_enable(unsigned int type)
 {
switch (type) {
+   case HDMI_PACKET_TYPE_GENERAL_CONTROL:
+   return VIDEO_DIP_ENABLE_GCP;
+   case HDMI_PACKET_TYPE_GAMUT_METADATA:
+   return VIDEO_DIP_ENABLE_GAMUT;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_ENABLE_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -112,6 +118,10 @@ static u32 g4x_infoframe_enable(unsigned int type)
 static u32 hsw_infoframe_enable(unsigned int type)
 {
switch (type) {
+   case HDMI_PACKET_TYPE_GENERAL_CONTROL:
+   return VIDEO_DIP_ENABLE_GCP_HSW;
+   case HDMI_PACKET_TYPE_GAMUT_METADATA:
+   return VIDEO_DIP_ENABLE_GMP_HSW;
case DP_SDP_VSC:
return VIDEO_DIP_ENABLE_VSC_HSW;
case DP_SDP_PPS:
@@ -135,6 +145,8 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
 int i)
 {
switch (type) {
+   case HDMI_PACKET_TYPE_GAMUT_METADATA:
+   return HSW_TVIDEO_DIP_GMP_DATA(cpu_transcoder, i);
case DP_SDP_VSC:
return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
case DP_SDP_PPS:
-- 
2.19.2

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

[Intel-gfx] [PATCH v3 0/9] drm/i915: Infoframe precompute/check

2019-02-25 Thread Ville Syrjala

From: Ville Syrjälä 

Simply a rebase on top of latest drm-tip. The one important
change was the adjustment of .compute_config() return value
from bool to int. All r-b'd/acked so should be good to land
if CI is still agreeable.

Ville Syrjälä (9):
  drm/i915: Add the missing HDMI gamut metadata packet stuff
  drm/i915: Return the mask of enabled infoframes from
->inforame_enabled()
  drm/i915: Store mask of enabled infoframes in the crtc state
  drm/i915: Precompute HDMI infoframes
  drm/i915: Read out HDMI infoframes
  drm/i915/sdvo: Precompute HDMI infoframes
  drm/i915/sdvo: Read out HDMI infoframes
  drm/i915: Check infoframe state in intel_pipe_config_compare()
  drm/i915: Include infoframes in the crtc state dump

 drivers/gpu/drm/i915/i915_reg.h  |   8 +-
 drivers/gpu/drm/i915/intel_ddi.c |  17 +-
 drivers/gpu/drm/i915/intel_display.c |  75 +++-
 drivers/gpu/drm/i915/intel_drv.h |  29 +-
 drivers/gpu/drm/i915/intel_hdmi.c| 519 ++-
 drivers/gpu/drm/i915/intel_lspcon.c  |  13 +-
 drivers/gpu/drm/i915/intel_sdvo.c| 156 ++--
 7 files changed, 694 insertions(+), 123 deletions(-)

-- 
2.19.2

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Patchwork

== Series Details ==

Series: series starting with [1/4] drm/i915: Replace global_seqno with a 
hangcheck heartbeat seqno
URL   : https://patchwork.freedesktop.org/series/57203/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0e4e62c64045 drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
23e70de4520a drm/i915: Remove access to global seqno in the HWSP
1ed97126d8c7 drm/i915: Remove i915_request.global_seqno
1acf3a7fbe86 drm/i915/selftests: Exercise resetting during non-user payloads
-:35: WARNING:LINE_SPACING: Missing a blank line after declarations
#35: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:427:
+   struct drm_file *file;
+   IGT_TIMEOUT(end_time);

-:154: WARNING:LINE_SPACING: Missing a blank line after declarations
#154: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:546:
+   unsigned int count;
+   IGT_TIMEOUT(end_time);

total: 0 errors, 2 warnings, 0 checks, 230 lines checked

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

Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl

2019-02-25 Thread Joonas Lahtinen

Quoting Lionel Landwerlin (2019-02-04 17:30:12)
> On 22/01/2019 16:25, Joonas Lahtinen wrote:
> > Quoting Lionel Landwerlin (2019-01-16 17:36:22)
> >> With the currently available parameters for the i915-perf stream,
> >> there are still situations that are not well covered :
> >>
> >> If an application opens the stream with polling disable or at very low
> >> frequency and OA interrupt enabled, no data will be available even
> >> though somewhere between nothing and half of the OA buffer worth of
> >> data might have landed in memory.
> >>
> >> To solve this issue we have a new flush ioctl on the perf stream that
> >> forces the i915-perf driver to look at the state of the buffer when
> >> called and makes any data available through both poll() & read() type
> >> syscalls.
> >>
> >> Signed-off-by: Lionel Landwerlin 
> > Link to userspace changes?
> >
> > Regards, Joonas
> 
> 
> Hey Joonas,
> 
> 
> I'm about to make the changes in gputop for the high frequency sampling 
> use case.
> 
> 
> One thing I would like to know is whether these new features should be 
> reported through a flag.
> 
> So far we haven't added any new option to the i915/perf driver since the 
> initial upstreaming series.
> 
> 
> The way I'm currently detecting newly added parameters is by using 
> trying to open the stream with a value that I know will report ENOENT 
> rather than EINVAL when the feature is not available :
> 
> https://github.com/djdeath/intel-gpu-tools/blob/wip/djdeath/oa-interrupts/tests/perf.c#L4345
> 
> Is there a better way to do this?

I think I already responded in IRC, but here goes for e-mail archives.

A GETPARAM with rolling i915/perf version would probably be a justified
versioning interface.

Regards, Joonas

> 
> 
> Thanks,
> 
> 
> -Lionel
> 
> 
> >
> >> ---
> >>   drivers/gpu/drm/i915/i915_perf.c | 17 +
> >>   include/uapi/drm/i915_drm.h  | 19 +++
> >>   2 files changed, 36 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> >> b/drivers/gpu/drm/i915/i915_perf.c
> >> index da721fce2543..6c98ffa2135e 100644
> >> --- a/drivers/gpu/drm/i915/i915_perf.c
> >> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >> @@ -2433,6 +2433,20 @@ static void i915_perf_disable_locked(struct 
> >> i915_perf_stream *stream)
> >>  stream->ops->disable(stream);
> >>   }
> >>   
> >> +/**
> >> + * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
> >> + * @stream: An enabled i915 perf stream
> >> + *
> >> + * The intention is to flush all the data available for reading from the 
> >> OA
> >> + * buffer
> >> + */
> >> +static void i915_perf_flush_data(struct i915_perf_stream *stream)
> >> +{
> >> +   struct drm_i915_private *dev_priv = stream->dev_priv;
> >> +
> >> +   dev_priv->perf.oa.pollin = oa_buffer_check(stream->dev_priv, true);
> >> +}
> >> +
> >>   /**
> >>* i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
> >>* @stream: An i915 perf stream
> >> @@ -2456,6 +2470,9 @@ static long i915_perf_ioctl_locked(struct 
> >> i915_perf_stream *stream,
> >>  case I915_PERF_IOCTL_DISABLE:
> >>  i915_perf_disable_locked(stream);
> >>  return 0;
> >> +   case I915_PERF_IOCTL_FLUSH_DATA:
> >> +   i915_perf_flush_data(stream);
> >> +   return 0;
> >>  }
> >>   
> >>  return -EINVAL;
> >> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> >> index b6db5e544a35..0f0d20080572 100644
> >> --- a/include/uapi/drm/i915_drm.h
> >> +++ b/include/uapi/drm/i915_drm.h
> >> @@ -1594,6 +1594,25 @@ struct drm_i915_perf_open_param {
> >>*/
> >>   #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
> >>   
> >> +/**
> >> + * Actively check the availability of data from a stream.
> >> + *
> >> + * A stream data availability can be driven by two types of events :
> >> + *
> >> + *   - if enabled, the kernel's hrtimer checking the amount of available 
> >> data
> >> + * in the OA buffer through head/tail registers.
> >> + *
> >> + *   - if enabled, the OA unit's interrupt mechanism
> >> + *
> >> + * The kernel hrtimer incur a cost of running callback at fixed time
> >> + * intervals, while the OA interrupt might only happen rarely. In the
> >> + * situation where the application has disabled the kernel's hrtimer and 
> >> only
> >> + * uses the OA interrupt to know about available data, the application can
> >> + * request an active check of the available OA data through this ioctl. 
> >> This
> >> + * will make any data in the OA buffer available with either poll() or 
> >> read().
> >> + */
> >> +#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x2)
> >> +
> >>   /**
> >>* Common to all i915 perf records
> >>*/
> >> -- 
> >> 2.20.1
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
>

Re: [Intel-gfx] [PATCH] drm/i915: Yet another if/else sort of newer to older platforms.

2019-02-25 Thread Ville Syrjälä

On Fri, Feb 22, 2019 at 02:11:12PM -0800, Rodrigo Vivi wrote:
> No functional change. Just a reorg to match the preferred
> behavior.
> 
> When rebasing internal branch on top of latest sort I noticed
> few more cases that needs to get reordered.
> 
> Let's do in a bundle this time and hoping there's no other
> missing places.
> 
> Cc: Ville Syrjälä 
> Cc: Chris Wilson 
> Cc: Lucas De Marchi 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  | 24 -
>  drivers/gpu/drm/i915/i915_perf.c | 50 +-
>  drivers/gpu/drm/i915/intel_cdclk.c   | 38 +++---
>  drivers/gpu/drm/i915/intel_workarounds.c | 64 
>  4 files changed, 88 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c6354f6cdbdb..0e3d5cf2c4f8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -219,20 +219,20 @@ intel_virt_detect_pch(const struct drm_i915_private 
> *dev_priv)
>* make an educated guess as to which PCH is really there.
>*/
>  
> - if (IS_GEN(dev_priv, 5))
> - id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
> - else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
> - id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
> - else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> - id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> - else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> - id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> - else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> - id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
> + if (IS_ICELAKE(dev_priv))
> + id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
>   else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
>   id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
> - else if (IS_ICELAKE(dev_priv))
> - id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
> + else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> + id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
> + else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> + else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> + id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;

Generic match before the more specific one. That's not going to work.

> + else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
> + id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
> + else if (IS_GEN(dev_priv, 5))
> + id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
>  
>   if (id)
>   DRM_DEBUG_KMS("Assuming PCH ID %04x\n", id);
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 9ebf99f3d8d3..72a9a35b40e2 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2881,12 +2881,24 @@ void i915_perf_register(struct drm_i915_private 
> *dev_priv)
>  
>   sysfs_attr_init(_priv->perf.oa.test_config.sysfs_metric_id.attr);
>  
> - if (IS_HASWELL(dev_priv)) {
> - i915_perf_load_test_config_hsw(dev_priv);
> - } else if (IS_BROADWELL(dev_priv)) {
> - i915_perf_load_test_config_bdw(dev_priv);
> - } else if (IS_CHERRYVIEW(dev_priv)) {
> - i915_perf_load_test_config_chv(dev_priv);
> + if (IS_ICELAKE(dev_priv)) {
> + i915_perf_load_test_config_icl(dev_priv);
> + } else if (IS_CANNONLAKE(dev_priv)) {
> + i915_perf_load_test_config_cnl(dev_priv);
> + } else if (IS_COFFEELAKE(dev_priv)) {
> + if (IS_CFL_GT2(dev_priv))
> + i915_perf_load_test_config_cflgt2(dev_priv);
> + if (IS_CFL_GT3(dev_priv))
> + i915_perf_load_test_config_cflgt3(dev_priv);
> + } else if (IS_GEMINILAKE(dev_priv)) {
> + i915_perf_load_test_config_glk(dev_priv);
> + } else if (IS_KABYLAKE(dev_priv)) {
> + if (IS_KBL_GT2(dev_priv))
> + i915_perf_load_test_config_kblgt2(dev_priv);
> + else if (IS_KBL_GT3(dev_priv))
> + i915_perf_load_test_config_kblgt3(dev_priv);
> + } else if (IS_BROXTON(dev_priv)) {
> + i915_perf_load_test_config_bxt(dev_priv);
>   } else if (IS_SKYLAKE(dev_priv)) {
>   if (IS_SKL_GT2(dev_priv))
>   i915_perf_load_test_config_sklgt2(dev_priv);
> @@ -2894,25 +2906,13 @@ void i915_perf_register(struct drm_i915_private 
> *dev_priv)
>   i915_perf_load_test_config_sklgt3(dev_priv);
>   else if (IS_SKL_GT4(dev_priv))
>   i915_perf_load_test_config_sklgt4(dev_priv);
> - } else if (IS_BROXTON(dev_priv)) {
> - i915_perf_load_test_config_bxt(dev_priv);
> - } else if (IS_KABYLAKE(dev_priv)) {
> - if (IS_KBL_GT2(dev_priv))
> - i915_perf_load_test_config_kblgt2(dev_priv);
> -

[Intel-gfx] [PATCH 2/4] drm/i915: Remove access to global seqno in the HWSP

2019-02-25 Thread Chris Wilson

Stop accessing the HWSP to read the global seqno, and stop tracking the
mirror in the engine's execution timeline -- it is unused.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gpu_error.c |  4 --
 drivers/gpu/drm/i915/i915_gpu_error.h |  3 --
 drivers/gpu/drm/i915/i915_request.c   | 27 +
 drivers/gpu/drm/i915/i915_reset.c |  1 -
 drivers/gpu/drm/i915/intel_engine_cs.c| 14 +--
 drivers/gpu/drm/i915/intel_lrc.c  | 21 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  7 +---
 drivers/gpu/drm/i915/intel_ringbuffer.h   | 40 ---
 drivers/gpu/drm/i915/selftests/i915_request.c |  3 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  3 --
 10 files changed, 19 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3f6eddb6f6de..061a767e3bed 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -526,8 +526,6 @@ static void error_print_engine(struct 
drm_i915_error_state_buf *m,
   ee->vm_info.pp_dir_base);
}
}
-   err_printf(m, "  seqno: 0x%08x\n", ee->seqno);
-   err_printf(m, "  last_seqno: 0x%08x\n", ee->last_seqno);
err_printf(m, "  ring->head: 0x%08x\n", ee->cpu_ring_head);
err_printf(m, "  ring->tail: 0x%08x\n", ee->cpu_ring_tail);
err_printf(m, "  hangcheck timestamp: %dms (%lu%s)\n",
@@ -1216,8 +1214,6 @@ static void error_record_engine_registers(struct 
i915_gpu_state *error,
 
ee->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
ee->acthd = intel_engine_get_active_head(engine);
-   ee->seqno = intel_engine_get_seqno(engine);
-   ee->last_seqno = intel_engine_last_submit(engine);
ee->start = I915_READ_START(engine);
ee->head = I915_READ_HEAD(engine);
ee->tail = I915_READ_TAIL(engine);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 94eaf8ab9051..19ac102afaff 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -94,8 +94,6 @@ struct i915_gpu_state {
u32 cpu_ring_head;
u32 cpu_ring_tail;
 
-   u32 last_seqno;
-
/* Register state */
u32 start;
u32 tail;
@@ -108,7 +106,6 @@ struct i915_gpu_state {
u32 bbstate;
u32 instpm;
u32 instps;
-   u32 seqno;
u64 bbaddr;
u64 acthd;
u32 fault_reg;
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 124b3e279c88..596183f35b78 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -179,12 +179,11 @@ static void free_capture_list(struct i915_request 
*request)
 static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
 {
-   GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
+   GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
  __func__, engine->name,
  rq->fence.context, rq->fence.seqno,
  rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(engine));
+ hwsp_seqno(rq));
 
GEM_BUG_ON(!i915_request_completed(rq));
 
@@ -243,12 +242,11 @@ static void i915_request_retire(struct i915_request 
*request)
 {
struct i915_active_request *active, *next;
 
-   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
  request->engine->name,
  request->fence.context, request->fence.seqno,
  request->global_seqno,
- hwsp_seqno(request),
- intel_engine_get_seqno(request->engine));
+ hwsp_seqno(request));
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
@@ -305,12 +303,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
 
-   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
+   GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
  rq->engine->name,
  rq->fence.context, rq->fence.seqno,
  rq->global_seqno,
- hwsp_seqno(rq),
- intel_engine_get_seqno(rq->engine));
+ hwsp_seqno(rq));
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_request_completed(rq));
@@ -354,12 +351,11 @@ void __i915_request_submit(struct i915_request *request)

[Intel-gfx] [PATCH 4/4] drm/i915/selftests: Exercise resetting during non-user payloads

2019-02-25 Thread Chris Wilson

In selftests/live_hangcheck, we have a lot of tests for resetting simple
spinners, but nothing quite prepared us for how the GPU reacted to
triggering a reset outside of the safe spinner. These two subtests fill
the ring with plain old empty, non-spinning requests, and then triggers
a reset. Without a user-payload to blame, these requests will exercise
the 'non-started' paths and mostly be replayed verbatim.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 .../gpu/drm/i915/selftests/intel_hangcheck.c  | 218 ++
 1 file changed, 218 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index fa02cf9ce0cf..12e047328ab8 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -415,6 +415,222 @@ static bool wait_for_idle(struct intel_engine_cs *engine)
return wait_for(intel_engine_is_idle(engine), IGT_IDLE_TIMEOUT) == 0;
 }
 
+static int igt_reset_nop(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct intel_engine_cs *engine;
+   struct i915_gem_context *ctx;
+   unsigned int reset_count, count;
+   enum intel_engine_id id;
+   intel_wakeref_t wakeref;
+   struct drm_file *file;
+   IGT_TIMEOUT(end_time);
+   int err = 0;
+
+   /* Check that we can reset during non-user portions of requests */
+
+   file = mock_file(i915);
+   if (IS_ERR(file))
+   return PTR_ERR(file);
+
+   mutex_lock(>drm.struct_mutex);
+   ctx = live_context(i915, file);
+   mutex_unlock(>drm.struct_mutex);
+   if (IS_ERR(ctx)) {
+   err = PTR_ERR(ctx);
+   goto out;
+   }
+
+   i915_gem_context_clear_bannable(ctx);
+   wakeref = intel_runtime_pm_get(i915);
+   reset_count = i915_reset_count(>gpu_error);
+   count = 0;
+   do {
+   mutex_lock(>drm.struct_mutex);
+   for_each_engine(engine, i915, id) {
+   int i;
+
+   for (i = 0; i < 16; i++) {
+   struct i915_request *rq;
+
+   rq = i915_request_alloc(engine, ctx);
+   if (IS_ERR(rq)) {
+   err = PTR_ERR(rq);
+   break;
+   }
+
+   i915_request_add(rq);
+   }
+   }
+   mutex_unlock(>drm.struct_mutex);
+
+   igt_global_reset_lock(i915);
+   i915_reset(i915, ALL_ENGINES, NULL);
+   igt_global_reset_unlock(i915);
+   if (i915_reset_failed(i915)) {
+   err = -EIO;
+   break;
+   }
+
+   if (i915_reset_count(>gpu_error) !=
+   reset_count + ++count) {
+   pr_err("Full GPU reset not recorded!\n");
+   err = -EINVAL;
+   break;
+   }
+
+   if (!i915_reset_flush(i915)) {
+   struct drm_printer p =
+   drm_info_printer(i915->drm.dev);
+
+   pr_err("%s failed to idle after reset\n",
+  engine->name);
+   intel_engine_dump(engine, ,
+ "%s\n", engine->name);
+
+   err = -EIO;
+   break;
+   }
+
+   err = igt_flush_test(i915, 0);
+   if (err)
+   break;
+   } while (time_before(jiffies, end_time));
+   pr_info("%s: %d resets\n", __func__, count);
+
+   mutex_lock(>drm.struct_mutex);
+   err = igt_flush_test(i915, I915_WAIT_LOCKED);
+   mutex_unlock(>drm.struct_mutex);
+
+   intel_runtime_pm_put(i915, wakeref);
+
+out:
+   mock_file_free(i915, file);
+   if (i915_reset_failed(i915))
+   err = -EIO;
+   return err;
+}
+
+static int igt_reset_nop_engine(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct intel_engine_cs *engine;
+   struct i915_gem_context *ctx;
+   enum intel_engine_id id;
+   intel_wakeref_t wakeref;
+   struct drm_file *file;
+   int err = 0;
+
+   /* Check that we can engine-reset during non-user portions */
+
+   if (!intel_has_reset_engine(i915))
+   return 0;
+
+   file = mock_file(i915);
+   if (IS_ERR(file))
+   return PTR_ERR(file);
+
+   mutex_lock(>drm.struct_mutex);
+   ctx = live_context(i915, file);
+   mutex_unlock(>drm.struct_mutex);
+   if (IS_ERR(ctx)) {
+   err = PTR_ERR(ctx);
+   goto out;
+   }
+
+   i915_gem_context_clear_bannable(ctx);
+   wakeref = intel_runtime_pm_get(i915);
+

[Intel-gfx] [PATCH 3/4] drm/i915: Remove i915_request.global_seqno

2019-02-25 Thread Chris Wilson

Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 34 ++---
 drivers/gpu/drm/i915/i915_gpu_error.h |  2 -
 drivers/gpu/drm/i915/i915_request.c   | 34 ++---
 drivers/gpu/drm/i915/i915_request.h   | 32 
 drivers/gpu/drm/i915/i915_trace.h | 25 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  5 +-
 drivers/gpu/drm/i915/intel_guc_submission.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c  | 34 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 50 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  2 -
 .../gpu/drm/i915/selftests/intel_hangcheck.c  |  5 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  1 -
 12 files changed, 32 insertions(+), 194 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 061a767e3bed..fa86c60fb56c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -380,19 +380,16 @@ static void print_error_buffers(struct 
drm_i915_error_state_buf *m,
err_printf(m, "%s [%d]:\n", name, count);
 
while (count--) {
-   err_printf(m, "%08x_%08x %8u %02x %02x %02x",
+   err_printf(m, "%08x_%08x %8u %02x %02x",
   upper_32_bits(err->gtt_offset),
   lower_32_bits(err->gtt_offset),
   err->size,
   err->read_domains,
-  err->write_domain,
-  err->wseqno);
+  err->write_domain);
err_puts(m, tiling_flag(err->tiling));
err_puts(m, dirty_flag(err->dirty));
err_puts(m, purgeable_flag(err->purgeable));
err_puts(m, err->userptr ? " userptr" : "");
-   err_puts(m, err->engine != -1 ? " " : "");
-   err_puts(m, engine_name(m->i915, err->engine));
err_puts(m, i915_cache_level_str(m->i915, err->cache_level));
 
if (err->name)
@@ -1048,27 +1045,6 @@ i915_error_object_create(struct drm_i915_private *i915,
return dst;
 }
 
-/* The error capture is special as tries to run underneath the normal
- * locking rules - so we use the raw version of the i915_active_request lookup.
- */
-static inline u32
-__active_get_seqno(struct i915_active_request *active)
-{
-   struct i915_request *request;
-
-   request = __i915_active_request_peek(active);
-   return request ? request->global_seqno : 0;
-}
-
-static inline int
-__active_get_engine_id(struct i915_active_request *active)
-{
-   struct i915_request *request;
-
-   request = __i915_active_request_peek(active);
-   return request ? request->engine->id : -1;
-}
-
 static void capture_bo(struct drm_i915_error_buffer *err,
   struct i915_vma *vma)
 {
@@ -1077,9 +1053,6 @@ static void capture_bo(struct drm_i915_error_buffer *err,
err->size = obj->base.size;
err->name = obj->base.name;
 
-   err->wseqno = __active_get_seqno(>frontbuffer_write);
-   err->engine = __active_get_engine_id(>frontbuffer_write);
-
err->gtt_offset = vma->node.start;
err->read_domains = obj->read_domains;
err->write_domain = obj->write_domain;
@@ -1284,7 +1257,8 @@ static void record_request(struct i915_request *request,
struct i915_gem_context *ctx = request->gem_context;
 
erq->flags = request->fence.flags;
-   erq->context = ctx->hw_id;
+   erq->context = request->fence.context;
+   erq->seqno = request->fence.seqno;
erq->sched_attr = request->sched.attr;
erq->jiffies = request->emitted_jiffies;
erq->start = i915_ggtt_offset(request->ring->vma);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 19ac102afaff..8c1569c1830d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -164,7 +164,6 @@ struct i915_gpu_state {
struct drm_i915_error_buffer {
u32 size;
u32 name;
-   u32 wseqno;
u64 gtt_offset;
u32 read_domains;
u32 write_domain;
@@ -173,7 +172,6 @@ struct i915_gpu_state {
u32 dirty:1;
u32 purgeable:1;
u32 userptr:1;
-   s32 engine:4;
u32 cache_level:3;
} *active_bo[I915_NUM_ENGINES], *pinned_bo;
u32 active_bo_count[I915_NUM_ENGINES], pinned_bo_count;
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index

[Intel-gfx] [PATCH 1/4] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno

2019-02-25 Thread Chris Wilson

To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests will then be completed, we use a primitive random number
generator instead (with a cycle long enough to not matter over an
interval of a few thousand requests between hangcheck samples).

The alternative to using a dedicated seqno on every request is to issue
a heartbeat request and query its progress through the system. Sadly
this requires us to reduce struct_mutex so that we can issue requests
without requiring that bkl.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 ++---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  5 ++--
 drivers/gpu/drm/i915/intel_hangcheck.c  |  6 ++---
 drivers/gpu/drm/i915/intel_lrc.c| 15 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 19 -
 6 files changed, 77 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 37175414ce89..545091a5180b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1295,7 +1295,7 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
with_intel_runtime_pm(dev_priv, wakeref) {
for_each_engine(engine, dev_priv, id) {
acthd[id] = intel_engine_get_active_head(engine);
-   seqno[id] = intel_engine_get_seqno(engine);
+   seqno[id] = intel_engine_get_hangcheck_seqno(engine);
}
 
intel_engine_get_instdone(dev_priv->engine[RCS], );
@@ -1315,8 +1315,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
for_each_engine(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
seq_printf(m, "\tseqno = %x [current %x, last %x], %dms ago\n",
-  engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
+  engine->hangcheck.last_seqno,
+  seqno[id],
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies -

engine->hangcheck.action_timestamp));
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 81b80f8fd9ea..57bc5c4fb3ff 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1497,10 +1497,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_reset_failed(engine->i915))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x/%x [%d ms]\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
-  engine->hangcheck.seqno,
+  engine->hangcheck.last_seqno,
+  engine->hangcheck.next_seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index 9be033b6f4d2..f1d8dfc58049 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -133,21 +133,21 @@ static void hangcheck_load_sample(struct intel_engine_cs 
*engine,
  struct hangcheck *hc)
 {
hc->acthd = intel_engine_get_active_head(engine);
-   hc->seqno = intel_engine_get_seqno(engine);
+   hc->seqno = intel_engine_get_hangcheck_seqno(engine);
 }
 
 static void hangcheck_store_sample(struct intel_engine_cs *engine,
   const struct hangcheck *hc)
 {
engine->hangcheck.acthd = hc->acthd;
-   engine->hangcheck.seqno = hc->seqno;
+   engine->hangcheck.last_seqno = hc->seqno;
 }
 
 static enum intel_engine_hangcheck_action
 hangcheck_get_action(struct intel_engine_cs *engine,
 const struct hangcheck *hc)
 {
-   if (engine->hangcheck.seqno != hc->seqno)
+   if (engine->hangcheck.last_seqno != hc->seqno)
return ENGINE_ACTIVE_SEQNO;
 
if (intel_engine_is_idle(engine))
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 34a0866959c5..c134b3ca2df3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -178,6 +178,12 @@ static inline u32

Re: [Intel-gfx] [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

2019-02-25 Thread Hans de Goede


Hi,

On 25-02-19 15:06, Greg Kroah-Hartman wrote:

On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:

Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load


s/load/let/ fixed in my tree.


drm/kms drivers know about DisplayPort over Type-C hotplug events.

Signed-off-by: Hans de Goede 
---
  drivers/usb/typec/altmodes/displayport.c | 34 
  1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/typec/altmodes/displayport.c 
b/drivers/usb/typec/altmodes/displayport.c
index 35161594e368..87760ea252d6 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define DP_HEADER(cmd)			(VDO(USB_TYPEC_DP_SID, 1, cmd) | \

 VDO_OPOS(USB_TYPEC_DP_MODE))
@@ -67,12 +68,23 @@ struct dp_altmode {
const struct typec_altmode *port;
  };
  
-static int dp_altmode_notify(struct dp_altmode *dp)

+static int dp_altmode_notify(struct dp_altmode *dp, unsigned long conf)
+{
+   int ret;
+
+   ret = typec_altmode_notify(dp->alt, conf, >data);
+   if (ret)
+   return ret;
+
+   drm_kms_call_oob_hotplug_notifier_chain(DRM_OOB_HOTPLUG_TYPE_C_DP);


Is this causing a build/run-time dependancy of the USB code on DRM now?
What about typec systems without DRM, is that a thing?


Good point, yes this adds a build/run-time dependancy on the drm-core
to the Type-C DisplayPort altmode driver (typec_displayport.ko). But
only to that driver, which can be enabled / disabled separately through
CONFIG_TYPEC_DP_ALTMODE and that specific Type-C altmode makes little
sense without having drm/kms support.

Your remark does make me realize that I have forgotten to add a Kconfig
dependency for this to the TYPEC_DP_ALTMODE Kconfig symbol, I will fix
this for v2.

Regards,

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Restrict SNB LP3+ disable to Thinkpad X220 tablet

2019-02-25 Thread Ville Syrjälä

On Mon, Feb 25, 2019 at 05:45:38PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 22, 2019 at 05:52:51PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > The only machine we know for sure to require the LP3+ disable
> > is the Lenovo Thinkpad X220 tablet. Originally in commit
> > 03981c6ebec4 ("drm/i915: Disable LP3 watermarks on all SNB
> > machines") I disabled LP3+ watermarks on all SNB machines,
> > partially for safety, and partially since I didn't want to
> > add a quirk. But since we now have another watermark quirk
> > anyway let's reduce the SNB LP3+ disable scope to the x220
> > tablet only.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 11 +++
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 2a4b5014f56e..b225461455c2 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3038,7 +3038,7 @@ static void ilk_wm_disable_quirk(struct 
> > drm_i915_private *dev_priv,
> > intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
> >  }
> >  
> > -static void snb_wm_lp3_irq_quirk(struct drm_i915_private *dev_priv)
> > +static void ilk_wm_disable_lp3(struct drm_i915_private *dev_priv)
> >  {
> > /*
> >  * On some SNB machines (Thinkpad X220 Tablet at least)
> > @@ -3060,6 +3060,11 @@ static void ilk_wm_disable_lp1_quirk(struct 
> > drm_i915_private *dev_priv)
> >  }
> >  
> >  static const struct intel_pci_quirk ilk_wm_quirks[] = {
> > +   /*
> > +* Lenovo ThinkPad X220 Tablet (snb)
> > +* CPU doesn't wake up for vblank interrupts with LP3.
> > +*/
> > +   { 0x0126, 0x17aa, 0x21db, ilk_wm_disable_lp3 },
> 
> Hmm. Somehow I had convinced myself that this would also cover the second
> bugreport (https://bugs.freedesktop.org/show_bug.cgi?id=101269) we had
> about this. But looks like we'd need another quirk entry here for that
> machine (a Thinkpad T420). I'll respin with. *hopefully* there aren't
> many more.

https://bugs.freedesktop.org/show_bug.cgi?id=104573#c5 suggests that a
Lifeboot T901 is also affected. I guess I'll just have to drop my
plans to reduce the scope of this quirk :(

> 
> > /*
> >  * Lenovo Thinkpad T431s (ivb)
> >  * Massive underruns with LP1+.
> > @@ -3084,10 +3089,8 @@ static void ilk_setup_wm_latency(struct 
> > drm_i915_private *dev_priv)
> > intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
> > intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
> >  
> > -   if (IS_GEN(dev_priv, 6)) {
> > +   if (IS_GEN(dev_priv, 6))
> > snb_wm_latency_quirk(dev_priv);
> > -   snb_wm_lp3_irq_quirk(dev_priv);
> > -   }
> >  
> > intel_apply_pci_quirks(dev_priv, ilk_wm_quirks);
> >  }
> > -- 
> > 2.19.2
> 
> -- 
> Ville Syrjälä
> Intel

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Restrict SNB LP3+ disable to Thinkpad X220 tablet

2019-02-25 Thread Ville Syrjälä

On Fri, Feb 22, 2019 at 05:52:51PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> The only machine we know for sure to require the LP3+ disable
> is the Lenovo Thinkpad X220 tablet. Originally in commit
> 03981c6ebec4 ("drm/i915: Disable LP3 watermarks on all SNB
> machines") I disabled LP3+ watermarks on all SNB machines,
> partially for safety, and partially since I didn't want to
> add a quirk. But since we now have another watermark quirk
> anyway let's reduce the SNB LP3+ disable scope to the x220
> tablet only.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2a4b5014f56e..b225461455c2 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3038,7 +3038,7 @@ static void ilk_wm_disable_quirk(struct 
> drm_i915_private *dev_priv,
>   intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
>  }
>  
> -static void snb_wm_lp3_irq_quirk(struct drm_i915_private *dev_priv)
> +static void ilk_wm_disable_lp3(struct drm_i915_private *dev_priv)
>  {
>   /*
>* On some SNB machines (Thinkpad X220 Tablet at least)
> @@ -3060,6 +3060,11 @@ static void ilk_wm_disable_lp1_quirk(struct 
> drm_i915_private *dev_priv)
>  }
>  
>  static const struct intel_pci_quirk ilk_wm_quirks[] = {
> + /*
> +  * Lenovo ThinkPad X220 Tablet (snb)
> +  * CPU doesn't wake up for vblank interrupts with LP3.
> +  */
> + { 0x0126, 0x17aa, 0x21db, ilk_wm_disable_lp3 },

Hmm. Somehow I had convinced myself that this would also cover the second
bugreport (https://bugs.freedesktop.org/show_bug.cgi?id=101269) we had
about this. But looks like we'd need another quirk entry here for that
machine (a Thinkpad T420). I'll respin with. *hopefully* there aren't
many more.

>   /*
>* Lenovo Thinkpad T431s (ivb)
>* Massive underruns with LP1+.
> @@ -3084,10 +3089,8 @@ static void ilk_setup_wm_latency(struct 
> drm_i915_private *dev_priv)
>   intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
>   intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
>  
> - if (IS_GEN(dev_priv, 6)) {
> + if (IS_GEN(dev_priv, 6))
>   snb_wm_latency_quirk(dev_priv);
> - snb_wm_lp3_irq_quirk(dev_priv);
> - }
>  
>   intel_apply_pci_quirks(dev_priv, ilk_wm_quirks);
>  }
> -- 
> 2.19.2

-- 
Ville Syrjälä
Intel
___
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/tinydrm: Remove tinydrm_device

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/tinydrm: Remove tinydrm_device
URL   : https://patchwork.freedesktop.org/series/57197/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5658 -> Patchwork_12297


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57197/revisions/1/mbox/

Known issues


  Here are the changes found in Patchwork_12297 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g:   NOTRUN -> FAIL [fdo#108094]

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  
 Possible fixes 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   DMESG-WARN [fdo#108965] -> PASS

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

  
 Warnings 

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569]

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
  [fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
  [fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (44 -> 40)
--

  Additional (1): fi-icl-y 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 


Build changes
-

* Linux: CI_DRM_5658 -> Patchwork_12297

  CI_DRM_5658: dc6f5e9c1239d7a4b77e31cfaca48873692d579f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12297: f0ad6397e686c6adebb480863a1acfc140266b72 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f0ad6397e686 drm/tinydrm: Use drm_dev_enter/exit()
39722f3c2a91 drm/tinydrm: Remove tinydrm_device
4b763346fbfd drm/tinydrm: Drop using tinydrm_device
a7e4739b705b drm/tinydrm/repaper: Drop using tinydrm_device
8691cebfab70 drm/drv: DOC: Add driver example code
979fb6bd33a0 drm: Add devm_drm_dev_init()
686f06d66ef6 drm/drv: Hold ref on parent device during drm_device lifetime

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12297/
___
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/2] tests/pm_rpm: Enable PC8+ residency test for ICL and GEN9.

2019-02-25 Thread Imre Deak

On Thu, Feb 21, 2019 at 10:37:57PM +0530, Anshuman Gupta wrote:
> Enabled has_pc8 global for ICL and Gen9.
> Added PC8+ residency test for display enabled case as well.
> 
> Signed-off-by: Anshuman Gupta 
> ---
>  tests/pm_rpm.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index be296f5..c84f199 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -686,7 +686,8 @@ static void setup_pc8(void)
>   has_pc8 = false;
>  
>   /* Only Haswell supports the PC8 feature. */
> - if (!IS_HASWELL(ms_data.devid) && !IS_BROADWELL(ms_data.devid))
> + if (!IS_HASWELL(ms_data.devid) && !IS_BROADWELL(ms_data.devid)
> + && !IS_GEN9(ms_data.devid) && !IS_ICELAKE(ms_data.devid))

Could be made future proof by

if (!HSW && !BDW && GEN<9)
return;

>   return;
>  
>   /* Make sure our Kernel supports MSR and the module is loaded. */
> @@ -806,11 +807,15 @@ static void pc8_residency_subtest(void)
>   igt_assert_f(pc8_plus_residency_changed(30),
>"Machine is not reaching PC8+ states, please check its "
>"configuration.\n");
> -
> - /* Make sure PC8+ residencies stop! */
>   enable_one_screen(_data);
> - igt_assert_f(!pc8_plus_residency_changed(10),
> + if (IS_HASWELL(ms_data.devid) && IS_BROADWELL(ms_data.devid)) {

Perhaps add a pc8_needs_screen_off flag? As it's also needed in the next
patch.

Since PC8 doesn't require the screen to be off on GEN9+ we may also need
a subtest for that case, but I'm not sure what's the exact requirement
to get into PC8 in that case (how many displays can be enabled, in what
resolution).

> + /* Make sure PC8+ residencies stop! */
> + igt_assert_f(!pc8_plus_residency_changed(10),
> +  "PC8+ residency didn't stop with screen enabled.\n");
> + } else {
> + igt_assert_f(pc8_plus_residency_changed(10),
>"PC8+ residency didn't stop with screen enabled.\n");
> + }
>  }
>  
>  static void modeset_subtest(enum screen_type type, int rounds, int 
> wait_flags)
> -- 
> 2.7.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v15 00/16] drm/i915: Implement HDCP2.2

2019-02-25 Thread Winkler, Tomas

> On Mon, Feb 25, 2019 at 05:12:09AM +, C, Ramalingam wrote:
> > Tomas,
> >
> > Lkp issue is complaining about the header
> > drm/i915_mei_hdcp_interface.h, Which is already merged in drm-tip
> > through below commit. So don’t think this is a genuine issue. May be
> > this build was tried in different tree, where this commit is not added yet?
> 
> Yeah our topic trees aren't pushed into linux-next, 0day can't find them.
> Usually it will then fail to apply (and in that case it doesn't complain), 
> but it
> does complain if everything applies but doesn't build.
> -Daniel
> 
> >
> > commit 1626eab70ebc61d015e69a4bc3479d9228539343
> > Author: Ramalingam C 
> > Date:   Fri Feb 15 14:04:58 2019 +0530
> >
> > drm/i915: header for i915 - MEI_HDCP interface
> >
> > v15 is now part of github.

I'm okay to go with this.
Thanks
Tomas

> >
> > Best Regards,
> > Ramalingam C
> >
> >
> > > -Original Message-
> > > From: Winkler, Tomas
> > > Sent: Monday, February 25, 2019 1:45 AM
> > > To: C, Ramalingam ;
> > > intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > > daniel.vet...@ffwll.ch; Shankar, Uma 
> > > Subject: RE: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
> > >
> > > Have you fixed the lkp issue?
> > > I didn't see you pushed the code to github.
> > > Thanks
> > >
> > >
> > > > -Original Message-
> > > > From: C, Ramalingam
> > > > Sent: Sunday, February 24, 2019 18:33
> > > > To: intel-gfx@lists.freedesktop.org;
> > > > dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Winkler,
> > > > Tomas ; Shankar, Uma
> > > > 
> > > > Subject: Re: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
> > > >
> > > > Tomas,
> > > >
> > > > Could you please help to review and give final "Go" for the series?
> > > >
> > > > Thanks
> > > > --Ram.
> > > >
> > > > On 2/21/2019 11:41 PM, Ramalingam C wrote:
> > > > > This series enables the HDCP2.2 Type 0 for I915. The sequence
> > > > > for
> > > > > HDCP2.2 authentication and encryption is implemented as a
> > > > > generic flow between HDMI and DP. Encoder specific
> > > > > implementations are moved into hdcp_shim.
> > > > >
> > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series
> > > > > introduces a client driver for mei bus, so that for HDCP2.2
> > > > > authentication,
> > > > > HDCP2.2 stack in I915 can avail the services from ME FW. To
> > > > > enable this client driver set the config variable
> CONFIG_INTEL_MEI_HDCP.
> > > > >
> > > > > Userspace interface remains unchanged as version agnostic. When
> > > > > userspace request for HDCP enable, Kernel will detect the HDCP
> > > > > source and sink's HDCP version(1.4/2.2)capability and enable the
> > > > > best capable version for that combination.
> > > > >
> > > > > This series enables the HDCP2.2 for Type0 content streams.
> > > > >
> > > > > Test-with:
> > > > > <1549566452-30175-1-git-send-email-ramalinga...@intel.com>
> > > > > So that CP will be tested on BAT machine too.
> > > > >
> > > > > Major changes in v15
> > > > >- All I915 patches are merged. So dropping them.
> > > > >- Few minor suggestions are incorporated at mei changes.
> > > > >
> > > > > To ease the review process, series is hosted at
> > > > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v15
> > > > >
> > > > > Ramalingam C (15):
> > > > >misc/mei/hdcp: Client driver for HDCP application
> > > > >misc/mei/hdcp: Define ME FW interface for HDCP2.2
> > > > >misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> > > > >misc/mei/hdcp: Verify Receiver Cert and prepare km
> > > > >misc/mei/hdcp: Verify H_prime
> > > > >misc/mei/hdcp: Store the HDCP Pairing info
> > > > >misc/mei/hdcp: Initiate Locality check
> > > > >misc/mei/hdcp: Verify L_prime
> > > > >misc/mei/hdcp: Prepare Session Key
> > > > >misc/mei/hdcp: Repeater topology verification and ack
> > > > >misc/mei/hdcp: Verify M_prime
> > > > >misc/mei/hdcp: Enabling the HDCP authentication
> > > > >misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
> > > > >misc/mei/hdcp: Component framework for I915 Interface
> > > > >FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915
> > > > >
> > > > > Tomas Winkler (1):
> > > > >mei: bus: whitelist hdcp client
> > > > >
> > > > >   drivers/misc/mei/Kconfig |  11 +
> > > > >   drivers/misc/mei/Makefile|   2 +
> > > > >   drivers/misc/mei/bus-fixup.c |  16 +
> > > > >   drivers/misc/mei/hdcp/Makefile   |   7 +
> > > > >   drivers/misc/mei/hdcp/mei_hdcp.c | 849
> > > > +++
> > > > >   drivers/misc/mei/hdcp/mei_hdcp.h | 377 +
> > > > >   6 files changed, 1262 insertions(+)
> > > > >   create mode 100644 drivers/misc/mei/hdcp/Makefile
> > > > >   create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
> > > > >   create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
> > > > >
> >
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH v2 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params

2019-02-25 Thread Jani Nikula

On Thu, 21 Feb 2019, David Francis  wrote:
> Native 420 and 422 transfer modes are new in DSC1.2
>
> In these modes, each two pixels of a slice are treated as one
> pixel, so the slice width is half as large (round down) for
> the purposes of calucating the groups per line and chunk size
> in bytes
>
> In native 422 mode, each pixel has four components, so the
> mux component of a group is larger by one additional mux word
> and one additional component
>
> Now that there is native 422 support, the configuration option
> previously called enable422 is renamed to simple_422 to avoid
> confusion
>
> Acked-by: Jani Nikula 

This was really for patch 1/3 where it actually matters.

BR,
Jani.

> Reviewed-by: Manasi Navare 
> Reviewed-by: Harry Wentland 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dsc.c | 33 ++-
>  drivers/gpu/drm/i915/intel_vdsc.c |  4 ++--
>  include/drm/drm_dsc.h |  4 ++--
>  3 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index b7f1903508a4..d77570bf6ac4 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -95,7 +95,7 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
>   dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> - dsc_cfg->enable422 << DSC_PPS_SIMPLE422_SHIFT |
> + dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
>   dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
>   dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>  
> @@ -249,7 +249,7 @@ EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
>  /**
>   * drm_dsc_compute_rc_parameters() - Write rate control
>   * parameters to the dsc configuration defined in
> - *  drm_dsc_config in accordance with the DSC 1.1
> + *  drm_dsc_config in accordance with the DSC 1.2
>   * specification. Some configuration fields must be present
>   * beforehand.
>   *
> @@ -266,19 +266,34 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
> *vdsc_cfg)
>   unsigned long final_scale = 0;
>   unsigned long rbs_min = 0;
>  
> - /* Number of groups used to code each line of a slice */
> - groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> -DSC_RC_PIXELS_PER_GROUP);
> + if (vdsc_cfg->native_420 || vdsc_cfg->native_422) {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width / 2,
> +DSC_RC_PIXELS_PER_GROUP);
>  
> - /* chunksize in Bytes */
> - vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> -   vdsc_cfg->bits_per_pixel,
> -   (8 * 16));
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> / 2 *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + } else {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + }
>  
>   if (vdsc_cfg->convert_rgb)
>   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> (4 * vdsc_cfg->bits_per_component + 4)
> - 2);
> + else if (vdsc_cfg->native_422)
> + num_extra_mux_bits = 4 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 3 * (4 * vdsc_cfg->bits_per_component) - 2;
>   else
>   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
>   (4 * vdsc_cfg->bits_per_component + 4) +
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index 2d059ebc9bd0..8c8d96157333 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -368,7 +368,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
>   DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
>  
>   /* Gen 11 does not support YCbCr */
> - vdsc_cfg->enable422 = false;
> + vdsc_cfg->simple_422 = false;
>   /* Gen 11 does not support VBR */
>

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/tinydrm: Remove tinydrm_device

2019-02-25 Thread Patchwork

== Series Details ==

Series: drm/tinydrm: Remove tinydrm_device
URL   : https://patchwork.freedesktop.org/series/57197/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
686f06d66ef6 drm/drv: Hold ref on parent device during drm_device lifetime
979fb6bd33a0 drm: Add devm_drm_dev_init()
8691cebfab70 drm/drv: DOC: Add driver example code
a7e4739b705b drm/tinydrm/repaper: Drop using tinydrm_device
4b763346fbfd drm/tinydrm: Drop using tinydrm_device
39722f3c2a91 drm/tinydrm: Remove tinydrm_device
-:24: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#24: FILE: Documentation/gpu/tinydrm.rst:1:
+

-:89: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#89: 
deleted file mode 100644

total: 0 errors, 2 warnings, 0 checks, 62 lines checked
f0ad6397e686 drm/tinydrm: Use drm_dev_enter/exit()

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

2019-02-25 Thread Patchwork

== Series Details ==

Series: Propagate DP-over-Type-C hotplug events from Type-C subsys to 
drm-drivers
URL   : https://patchwork.freedesktop.org/series/57187/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5658 -> Patchwork_12296


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/57187/revisions/1/mbox/

Known issues


  Here are the changes found in Patchwork_12296 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g:   NOTRUN -> FAIL [fdo#108094]

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   PASS -> FAIL [fdo#109485]

  
 Possible fixes 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   DMESG-WARN [fdo#108965] -> PASS

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   SKIP [fdo#109271] -> PASS +33

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
  [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
  [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
  [fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530


Participating hosts (44 -> 40)
--

  Additional (1): fi-icl-y 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 


Build changes
-

* Linux: CI_DRM_5658 -> Patchwork_12296

  CI_DRM_5658: dc6f5e9c1239d7a4b77e31cfaca48873692d579f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4854: 06b0830fb948b9b632342cd26100342aa01cbc79 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12296: b45fffb9e74f9183e1a43de2db1bcf3e226a0d79 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b45fffb9e74f usb: typec: altmodes/displayport: Notify drm subsys of hotplug 
events
78d0c0a26486 i915: Add support for out-of-bound hotplug events
88c00a57f29f drm: Add support for out-of-band hotplug notification

== Logs ==

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

Re: [Intel-gfx] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x79/0x80

2019-02-25 Thread Jani Nikula

On Mon, 25 Feb 2019, Hans Verkuil  wrote:
> Hi Jani,
>
> On 2/25/19 2:40 PM, Jani Nikula wrote:
>> On Fri, 22 Feb 2019, Randy Dunlap  wrote:
>>> This is 5.0-rc7 on an old Toshiba Portege laptop.
>>> No hdmi or other external video.
>>>
>>> Linux dragon.dunlab 5.0.0-rc7mod #3 SMP PREEMPT Wed Feb 20 00:05:17 PST 
>>> 2019 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> on openSUSE LEAP 15.0 distro.
>>>
>>> Full boot log is attached.
>> 
>> On a hunch, caused by 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to
>> intel_hdmi") referencing the encoder in connector destroy hook. We
>> should probably move the cec_notifier_put() call in the encoder destroy
>> hook.
>
> So the intel_encoder_destroy function is/can be called before the 
> intel_hdmi_destroy function? Sounds odd. I would expect that the 
> connectors are destroyed before the encoders.
>
> In any case, I am happy to try it in another destroy hook, but I need
> advice which hook I should use and how I get to the cec_notifier from
> whatever structure pointer I have in that destroy hook.
>
> I tried to figure it out, but I became very confused :-)

It's... hairy.

Looks like in this case the destroy hook gets called via
drm_connector_free_work_fn() and __drm_connector_put_safe() the
documentation of which says, "Should only be used from the
connector_iter functions, where we never really expect to actually
release the connector when dropping our final reference."

Can and does happen anyway it seems. :/

BR,
Jani.

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

Re: [Intel-gfx] [PATCH v2 0/3] Make DRM DSC helpers more generally usable

2019-02-25 Thread Christian König


Am 21.02.19 um 21:19 schrieb David Francis:

drm_dsc could use some work so that drm drivers other than
i915 can make use of it their own DSC implementations

Move rc compute, a function that forms part of the DSC spec,
into drm. Update it to DSC 1.2. Also split the PPS packing and
SDP header init functions, to allow for drivers with
their own SDP struct headers

Re-sending due to Mail Delivery System errors


I have to admit that I know absolutely nothing about the technical 
background of the implemented spec.


But from a high level view it makes complete sense to have stuff which 
implements a spec in common code. Additional to that coding style etc 
seems to be ok on first glance.


So series is Acked-by: Christian König 

Regards,
Christian.



v2:
Rebase onto drm-next
Refactor drm_dsc_dp_pps_header_init
Clean up documentation on new drm function

David Francis (3):
   drm/i915: Move dsc rate params compute into drm
   drm/dsc: Add native 420 and 422 support to compute_rc_params
   drm/dsc: Split DSC PPS and SDP header initialisations

  drivers/gpu/drm/drm_dsc.c | 269 +++---
  drivers/gpu/drm/i915/intel_vdsc.c | 133 +--
  include/drm/drm_dsc.h |   9 +-
  3 files changed, 219 insertions(+), 192 deletions(-)



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

1 2 >

1 - 100 of 148 matches

Mail list logo