Re: [Intel-gfx] [PATCH v2 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

[Sagar Arun Kamble]

On 3/8/2018 9:16 PM, Michał Winiarski wrote:

Currently, we're treating relay and mapping of GuC log as a separate
concepts. We're also using inconsistent locking, sometimes using
relay_lock, sometimes using struct mutex.
Let's correct that. Anything touching the runtime is now serialized
using runtime.lock, while we're still using struct mutex as inner lock
for mapping.
We're still racy in setting the log level - but we'll take care of that
in the following patches.

v2: Tidy locking (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_guc_log.c | 113 +++
  drivers/gpu/drm/i915/intel_guc_log.h |   3 +-
  2 files changed, 36 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 89cb3939467f..4eb3ebd8d6c3 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -155,10 +155,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc)
struct dentry *log_dir;
int ret;
  
-	if (!i915_modparams.guc_log_level)

-   return 0;
-
-   mutex_lock(>log.runtime.relay_lock);
+   lockdep_assert_held(>log.runtime.lock);
  
  	/* For now create the log file in /sys/kernel/debug/dri/0 dir */

log_dir = dev_priv->drm.primary->debugfs_root;
@@ -177,28 +174,16 @@ static int guc_log_relay_file_create(struct intel_guc 
*guc)
 */
if (!log_dir) {
DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
-   ret = -ENODEV;
-   goto out_unlock;
+   return -ENODEV;
}
  
  	ret = relay_late_setup_files(guc->log.runtime.relay_chan, "guc_log", log_dir);

if (ret < 0 && ret != -EEXIST) {
DRM_ERROR("Couldn't associate relay chan with file %d\n", ret);
-   goto out_unlock;
+   return ret;
}
  
-	ret = 0;

-
-out_unlock:
-   mutex_unlock(>log.runtime.relay_lock);
-   return ret;
-}
-
-static bool guc_log_has_relay(struct intel_guc *guc)
-{
-   lockdep_assert_held(>log.runtime.relay_lock);
-
-   return guc->log.runtime.relay_chan != NULL;
+   return 0;
  }
  
  static void guc_move_to_next_buf(struct intel_guc *guc)

@@ -209,9 +194,6 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
 */
smp_wmb();
  
-	if (!guc_log_has_relay(guc))

-   return;
-
/* All data has been written, so now move the offset of sub buffer. */
relay_reserve(guc->log.runtime.relay_chan, 
guc->log.vma->obj->base.size);
  
@@ -221,9 +203,6 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
  
  static void *guc_get_write_buffer(struct intel_guc *guc)

  {
-   if (!guc_log_has_relay(guc))
-   return NULL;
-
/*
 * Just get the base address of a new sub buffer and copy data into it
 * ourselves. NULL will be returned in no-overwrite mode, if all sub
@@ -284,13 +263,14 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
void *src_data, *dst_data;
bool new_overflow;
  
+	mutex_lock(>log.runtime.lock);

+
if (WARN_ON(!guc->log.runtime.buf_addr))
-   return;
+   goto out_unlock;
  
  	/* Get the pointer to shared GuC log buffer */

log_buf_state = src_data = guc->log.runtime.buf_addr;
  
-	mutex_lock(>log.runtime.relay_lock);
  
  	/* Get the pointer to local buffer to store the logs */

log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);
@@ -302,9 +282,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 */
DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
guc->log.capture_miss_count++;
-   mutex_unlock(>log.runtime.relay_lock);
  
-		return;

+   goto out_unlock;
}
  
  	/* Actual logs are present from the 2nd page */

@@ -375,7 +354,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
  
  	guc_move_to_next_buf(guc);
  
-	mutex_unlock(>log.runtime.relay_lock);

+out_unlock:
+   mutex_unlock(>log.runtime.lock);
  }
  
  static void capture_logs_work(struct work_struct *work)

@@ -391,20 +371,20 @@ static bool guc_log_has_runtime(struct intel_guc *guc)
return guc->log.runtime.buf_addr != NULL;
  }
  
-static int guc_log_runtime_create(struct intel_guc *guc)

+static int guc_log_map(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
void *vaddr;
int ret;
  
-	lockdep_assert_held(_priv->drm.struct_mutex);

+   lockdep_assert_held(>log.runtime.lock);
  
  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Do not set the eDP link rate/lane count to max

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Do not set the eDP link rate/lane count to max
URL   : https://patchwork.freedesktop.org/series/39662/
State : success

== Summary ==

Series 39662v1 drm/i915/dp: Do not set the eDP link rate/lane count to max
https://patchwork.freedesktop.org/api/1.0/series/39662/revisions/1/mbox/

 Known issues:

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:367s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:486s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:470s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:422s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:469s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:523s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:536s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:512s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
80276b812f47 drm/i915/dp: Do not set the eDP link rate/lane count to max

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

[Manasi Navare]

On Thu, Mar 08, 2018 at 06:41:22PM -0500, Lyude Paul wrote:
> While having the modeset_retry_work in intel_connector makes sense with
> SST, this paradigm doesn't make a whole ton of sense when it comes to
> MST since we have to deal with multiple connectors. In most cases, it's
> more useful to just use the intel_dp struct since it indicates whether
> or not we're dealing with an MST device, along with being able to easily
> trace the intel_dp struct back to it's respective connector (if there is
> any). So, move the modeset_retry_work function out of the
> intel_connector struct and into intel_dp.
> 
> V2:
>  - Remove accidental duplicate modeset_retry_work in intel_connector
> 
> Signed-off-by: Lyude Paul 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 23 +--
>  drivers/gpu/drm/i915/intel_dp.c   | 10 --
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
>  4 files changed, 29 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f424fff477f6..85d5af4e4f5b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15394,16 +15394,35 @@ static void intel_hpd_poll_fini(struct drm_device 
> *dev)
>  {
>   struct intel_connector *connector;
>   struct drm_connector_list_iter conn_iter;
> + struct work_struct *work;
>  
>   /* Kill all the work that may have been queued by hpd. */
>   drm_connector_list_iter_begin(dev, _iter);
>   for_each_intel_connector_iter(connector, _iter) {
> - if (connector->modeset_retry_work.func)
> - cancel_work_sync(>modeset_retry_work);
>   if (connector->hdcp_shim) {
>   cancel_delayed_work_sync(>hdcp_check_work);
>   cancel_work_sync(>hdcp_prop_work);
>   }
> +
> + if (connector->base.connector_type !=
> + DRM_MODE_CONNECTOR_DisplayPort)

I know we dont fallback on eDP now but since link training is a common code 
between
eDP and DP, this modeset retry can also be called from eDP. So we should check 
against
DRM_MODE_CONNECTOR_eDP type as well.

Other than that, I agree that it is better for this work function to be part of 
intel_dp struct
as opposed to intel_connector. 

So after this change,

Reviewed-by: Manasi Navare 

Manasi

> + continue;
> +
> + if (connector->mst_port) {
> + work = >mst_port->modeset_retry_work;
> + } else {
> + struct intel_encoder *intel_encoder =
> + connector->encoder;
> + struct intel_dp *intel_dp;
> +
> + if (!intel_encoder)
> + continue;
> +
> + intel_dp = enc_to_intel_dp(_encoder->base);
> + work = _dp->modeset_retry_work;
> + }
> +
> + cancel_work_sync(work);
>   }
>   drm_connector_list_iter_end(_iter);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4dd1b2287dd6..5abf0c95725a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp 
> *intel_dp,
>  
>  static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
>  {
> - struct intel_connector *intel_connector;
> - struct drm_connector *connector;
> + struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
> +  modeset_retry_work);
> + struct drm_connector *connector = _dp->attached_connector->base;
>  
> - intel_connector = container_of(work, typeof(*intel_connector),
> -modeset_retry_work);
> - connector = _connector->base;
>   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> connector->name);
>  
> @@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port 
> *intel_dig_port,
>   int type;
>  
>   /* Initialize the work for modeset in case of link train failure */
> - INIT_WORK(_connector->modeset_retry_work,
> + INIT_WORK(_dp->modeset_retry_work,
> intel_dp_modeset_retry_work_fn);
>  
>   if (WARN(intel_dig_port->max_lanes < 1,
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index f59b59bb0a21..2cfa58ce1f95 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>   

Re: [Intel-gfx] [PATCH v2 03/15] drm/i915/guc: Move GuC notification handling to separate function

[Sagar Arun Kamble]

On 3/8/2018 9:16 PM, Michał Winiarski wrote:

From: Michal Wajdeczko 

To allow future code reuse. While here, fix comment style.

v2: Notifications are a separate thing - rename the handler (Sagar)

Suggested-by: Oscar Mateo 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
I am suggesting update to the comments below since it is not clear the 
reason for clearing. Please check and incorporate in this patch

itself if you feel it is right. Otherwise change looks good to me.
Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_irq.c  | 33 ++---
  drivers/gpu/drm/i915/intel_guc.c | 37 +
  drivers/gpu/drm/i915/intel_guc.h |  1 +
  3 files changed, 40 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 633c18785c1e..6b0cd6bc83f8 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1766,37 +1766,8 @@ static void gen6_rps_irq_handler(struct drm_i915_private 
*dev_priv, u32 pm_iir)
  
  static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir)

  {
-   if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
-   /* Sample the log buffer flush related bits & clear them out now
-* itself from the message identity register to minimize the
-* probability of losing a flush interrupt, when there are back
-* to back flush interrupts.
-* There can be a new flush interrupt, for different log buffer
-* type (like for ISR), whilst Host is handling one (for DPC).
-* Since same bit is used in message register for ISR & DPC, it
-* could happen that GuC sets the bit for 2nd interrupt but Host
-* clears out the bit on handling the 1st interrupt.
-*/
-   u32 msg, flush;
-
-   msg = I915_READ(SOFT_SCRATCH(15));
-   flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED |
-  INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER);
-   if (flush) {
-   /* Clear the message bits that are handled */
-   I915_WRITE(SOFT_SCRATCH(15), msg & ~flush);
-
-   /* Handle flush interrupt in bottom half */
-   queue_work(dev_priv->guc.log.runtime.flush_wq,
-  _priv->guc.log.runtime.flush_work);
-
-   dev_priv->guc.log.flush_interrupt_count++;
-   } else {
-   /* Not clearing of unhandled event bits won't result in
-* re-triggering of the interrupt.
-*/
-   }
-   }
+   if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT)
+   intel_guc_to_host_event_handler(_priv->guc);
  }
  
  static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ff08ea0ebf49..25f92291fd40 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -364,6 +364,43 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
return ret;
  }
  
+void intel_guc_to_host_event_handler(struct intel_guc *guc)

+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   u32 msg, flush;
+
+   /*
+* Sample the log buffer flush related bits & clear them out now
+* itself from the message identity register to minimize the
+* probability of losing a flush interrupt, when there are back
+* to back flush interrupts.

This paragraph is updated as:

                    /*
                 * Note: Logging protocol is, GuC will set the bit 
in message identity register and raise the GuC to Host
                 * interrupt and then Host will read the bit, clear 
it, copy the logs and send ack.
                 * If bits are cleared after sending ack, i915 
might lose next log flush interrupt if Host clear operation
                 * happens post GuC's update to message identity 
register corresponding to next interrupt.
                 * Hence, sample the log buffer flush related bits 
and clear them out now
                 * itself from the message identity register before 
sending ack to GuC about

                 * flush completion through guc_log_flush_complete.
                 */

and may be we can additionally include below paragraph to explain the 
scenario.

+* There can be a new 

[Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max

[Manasi Navare]

The panels are generally designed to support only a single
clock and lane configuration, and typically these values
correspond to the native resolution of the panel. But some
panels advertise the MAX_LINK_RATE in DPCD higher than what
is required to support the native resolution.
So optimize and set the link rate and lane count to the
least values required by the panel to support the native
resolution. This will also be an effective power saving
for such eDP panels.

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8d1d7af..ba1114b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1812,15 +1812,14 @@ intel_dp_compute_config(struct intel_encoder *encoder,
bpp = dev_priv->vbt.edp.bpp;
}
 
-   /*
-* Use the maximum clock and number of lanes the eDP panel
-* advertizes being capable of. The panels are generally
-* designed to support only a single clock and lane
-* configuration, and typically these values correspond to the
-* native resolution of the panel.
+   /* The panels are generally designed to support only a single
+* clock and lane configuration, and typically these values
+* correspond to the native resolution of the panel. But some
+* panels advertise higher link rates that might not be required
+* for the native resolution of the panel. So use the least
+* required link rate/lane count for the panel's native
+* resolution.
 */
-   min_lane_count = max_lane_count;
-   min_clock = max_clock;
}
 
for (; bpp >= 6*3; bpp -= 2*3) {
-- 
2.7.4

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Push irq_shift from 
gen8_cs_irq_handler() to caller (rev2)
URL   : https://patchwork.freedesktop.org/series/39651/
State : warning

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-c-query-busy-hang:
pass   -> DMESG-WARN (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341 +1
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

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

shard-apltotal:3381 pass:1779 dwarn:1   dfail:0   fail:8   skip:1591 
time:11740s
shard-hswtotal:3381 pass:1728 dwarn:2   dfail:0   fail:1   skip:1648 
time:11177s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6904s
Blacklisted hosts:
shard-kbltotal:3308 pass:1859 dwarn:1   dfail:0   fail:9   skip:1437 
time:8741s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

[Manasi Navare]

On Thu, Mar 08, 2018 at 06:24:15PM -0500, Lyude Paul wrote:
> Signed-off-by: Lyude Paul 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 

Reviewed-by: Manasi Navare 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9a4a51e79fa1..4dd1b2287dd6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -43,7 +43,6 @@
>  #include 
>  #include "i915_drv.h"
>  
> -#define DP_LINK_CHECK_TIMEOUT(10 * 1000)
>  #define DP_DPRX_ESI_LEN 14
>  
>  /* Compliance test status bits  */
> -- 
> 2.14.3
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 02/15] drm/i915/guc: Create common entry points for log register/unregister

[Sagar Arun Kamble]

On 3/8/2018 9:16 PM, Michał Winiarski wrote:

We have many functions responsible for allocating different parts of
GuC log runtime called from multiple places. Let's stick with keeping
everything in guc_log_register instead.

v2: Use more generic intel_uc_register name, keep using "misc" suffix (Michał)
 s/dev_priv/i915 (Sagar)
 Make guc_log_relay_* static (sparse)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_drv.c  |   6 +-
  drivers/gpu/drm/i915/intel_guc_log.c | 156 ++-
  drivers/gpu/drm/i915/intel_guc_log.h |   6 +-
  drivers/gpu/drm/i915/intel_uc.c  |  41 +
  drivers/gpu/drm/i915/intel_uc.h  |   2 +
  5 files changed, 95 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d7c4de45644d..987c6770d1a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1238,9 +1238,11 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
-   i915_guc_log_register(dev_priv);
i915_setup_sysfs(dev_priv);
  
+		/* Depends on debugfs having been initialized */

+   intel_uc_register(dev_priv);
+
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
} else
@@ -1298,7 +1300,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_pmu_unregister(dev_priv);
  
  	i915_teardown_sysfs(dev_priv);

-   i915_guc_log_unregister(dev_priv);
+   intel_uc_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
  
  	i915_gem_shrinker_unregister(dev_priv);

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7e59fb07b06b..90b395f34808 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -443,7 +443,7 @@ void intel_guc_log_init_early(struct intel_guc *guc)
INIT_WORK(>log.runtime.flush_work, capture_logs_work);
  }
  
-int intel_guc_log_relay_create(struct intel_guc *guc)

+static int guc_log_relay_create(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
@@ -496,7 +496,7 @@ int intel_guc_log_relay_create(struct intel_guc *guc)
return ret;
  }
  
-void intel_guc_log_relay_destroy(struct intel_guc *guc)

+static void guc_log_relay_destroy(struct intel_guc *guc)
  {
mutex_lock(>log.runtime.relay_lock);
  
@@ -514,49 +514,6 @@ void intel_guc_log_relay_destroy(struct intel_guc *guc)

mutex_unlock(>log.runtime.relay_lock);
  }
  
-static int guc_log_late_setup(struct intel_guc *guc)

-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   int ret;
-
-   if (!guc_log_has_runtime(guc)) {
-   /*
-* If log was disabled at boot time, then setup needed to handle
-* log buffer flush interrupts would not have been done yet, so
-* do that now.
-*/
-   ret = intel_guc_log_relay_create(guc);
-   if (ret)
-   goto err;
-
-   mutex_lock(_priv->drm.struct_mutex);
-   intel_runtime_pm_get(dev_priv);
-   ret = guc_log_runtime_create(guc);
-   intel_runtime_pm_put(dev_priv);
-   mutex_unlock(_priv->drm.struct_mutex);
-
-   if (ret)
-   goto err_relay;
-   }
-
-   ret = guc_log_relay_file_create(guc);
-   if (ret)
-   goto err_runtime;
-
-   return 0;
-
-err_runtime:
-   mutex_lock(_priv->drm.struct_mutex);
-   guc_log_runtime_destroy(guc);
-   mutex_unlock(_priv->drm.struct_mutex);
-err_relay:
-   intel_guc_log_relay_destroy(guc);
-err:
-   /* logging will remain off */
-   i915_modparams.guc_log_level = 0;
-   return ret;
-}
-
  static void guc_log_capture_logs(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -576,16 +533,6 @@ static void guc_flush_logs(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
  
-	if (!USES_GUC_SUBMISSION(dev_priv) || !i915_modparams.guc_log_level)

-   return;
-
-   /* First disable the interrupts, will be renabled afterwards */
-   mutex_lock(_priv->drm.struct_mutex);
-   intel_runtime_pm_get(dev_priv);
-   gen9_disable_guc_interrupts(dev_priv);
-   

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: make edp optimize config

[Patchwork]

== Series Details ==

Series: drm/i915: make edp optimize config
URL   : https://patchwork.freedesktop.org/series/39652/
State : warning

== Summary ==

 Possible new issues:

Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-a:
pass   -> SKIP   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
pass   -> SKIP   (shard-snb)
Subgroup pipe-a-wait-busy-hang:
pass   -> SKIP   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-apltotal:3381 pass:1779 dwarn:1   dfail:0   fail:9   skip:1591 
time:11672s
shard-hswtotal:3383 pass:1724 dwarn:1   dfail:0   fail:0   skip:1656 
time:11145s
shard-snbtotal:3467 pass:1360 dwarn:1   dfail:0   fail:2   skip:2104 
time:6846s
Blacklisted hosts:
shard-kbltotal:3308 pass:1857 dwarn:1   dfail:0   fail:9   skip:1439 
time:8635s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)
URL   : https://patchwork.freedesktop.org/series/39647/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions:
pass   -> FAIL   (shard-apl) fdo#103207
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> FAIL   (shard-apl) fdo#104164
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
fdo#104164 https://bugs.freedesktop.org/show_bug.cgi?id=104164
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3381 pass:1777 dwarn:1   dfail:0   fail:11  skip:1591 
time:11729s
shard-hswtotal:3467 pass:1772 dwarn:1   dfail:0   fail:2   skip:1691 
time:11741s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6860s
Blacklisted hosts:
shard-kbltotal:3381 pass:1898 dwarn:1   dfail:0   fail:9   skip:1472 
time:9034s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 01/15] drm/i915/guc: Tidy guc_log_control

[Sagar Arun Kamble]

On 3/8/2018 9:16 PM, Michał Winiarski wrote:

We plan to decouple log runtime (mapping + relay) from verbosity control.
Let's tidy the code now to reduce the churn in the following patches.

v2: Tidy macros, keep debug messages, use helper var for enable,
 correct typo (Michał)
 Fix incorrect input validaction (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_debugfs.c  | 11 ++---
  drivers/gpu/drm/i915/intel_guc_log.c | 80 +---
  drivers/gpu/drm/i915/intel_guc_log.h |  3 +-
  3 files changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 89f7ff2c652e..fa0755fe10d0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2500,13 +2500,10 @@ static int i915_guc_log_control_get(void *data, u64 
*val)
  {
struct drm_i915_private *dev_priv = data;
  
-	if (!HAS_GUC(dev_priv))

+   if (!USES_GUC(dev_priv))
return -ENODEV;
  
-	if (!dev_priv->guc.log.vma)

-   return -EINVAL;
-
-   *val = i915_modparams.guc_log_level;
+   *val = intel_guc_log_control_get(_priv->guc);
  
  	return 0;

  }
@@ -2515,10 +2512,10 @@ static int i915_guc_log_control_set(void *data, u64 val)
  {
struct drm_i915_private *dev_priv = data;
  
-	if (!HAS_GUC(dev_priv))

+   if (!USES_GUC(dev_priv))
return -ENODEV;
  
-	return intel_guc_log_control(_priv->guc, val);

+   return intel_guc_log_control_set(_priv->guc, val);
  }
  
  DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index c0c2e7d1c7d7..7e59fb07b06b 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -659,51 +659,63 @@ void intel_guc_log_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(>log.vma);
  }
  
-int intel_guc_log_control(struct intel_guc *guc, u64 control_val)

+int intel_guc_log_control_get(struct intel_guc *guc)
+{
+   GEM_BUG_ON(!guc->log.vma);
+   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
+
+   return i915_modparams.guc_log_level;
+}
+
+#define GUC_LOG_LEVEL_DISABLED 0
+#define LOG_LEVEL_TO_ENABLED(x)((x) > 0)
+#define LOG_LEVEL_TO_VERBOSITY(x) ({   \
+   typeof(x) _x = (x); \
+   LOG_LEVEL_TO_ENABLED(_x) ? _x - 1 : 0;  \
+})
+#define VERBOSITY_TO_LOG_LEVEL(x)  ((x) + 1)
+int intel_guc_log_control_set(struct intel_guc *guc, u64 val)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   bool enable_logging = control_val > 0;
-   u32 verbosity;
+   bool enabled = LOG_LEVEL_TO_ENABLED(val);
int ret;
  
-	if (!guc->log.vma)

-   return -ENODEV;
+   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
+   GEM_BUG_ON(!guc->log.vma);
+   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
  
-	BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);

-   if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
+   /*
+* GuC is recognizing log levels starting from 0 to max, we're using 0
+* as indication that logging should be disabled.
+*/
+   if (val < GUC_LOG_LEVEL_DISABLED ||
+   val > VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX))
return -EINVAL;
  
-	/* This combination doesn't make sense & won't have any effect */

-   if (!enable_logging && !i915_modparams.guc_log_level)
-   return 0;
+   mutex_lock(_priv->drm.struct_mutex);
  
-	verbosity = enable_logging ? control_val - 1 : 0;

+   if (i915_modparams.guc_log_level == val) {
+   ret = 0;
+   goto out_unlock;
+   }
  
-	ret = mutex_lock_interruptible(_priv->drm.struct_mutex);

-   if (ret)
-   return ret;
intel_runtime_pm_get(dev_priv);
-   ret = guc_log_control(guc, enable_logging, verbosity);
+   ret = guc_log_control(guc, enabled, LOG_LEVEL_TO_VERBOSITY(val));
intel_runtime_pm_put(dev_priv);
-   mutex_unlock(_priv->drm.struct_mutex);
-
-   if (ret < 0) {
-   DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
-   return ret;
+   if (ret) {
+   DRM_DEBUG_DRIVER("guc_log_control action failed %d\n", ret);
+   goto out_unlock;
}
  
-	if (enable_logging) {

-   i915_modparams.guc_log_level = 1 + verbosity;
+   i915_modparams.guc_log_level = val;
  
-		/*

-* If log was disabled at boot time, then the relay channel file
-* wouldn't have been created by now 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.
URL   : https://patchwork.freedesktop.org/series/39648/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

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

shard-apltotal:3381 pass:1779 dwarn:1   dfail:0   fail:8   skip:1591 
time:11773s
shard-hswtotal:3467 pass:1771 dwarn:1   dfail:0   fail:3   skip:1691 
time:11651s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6889s
Blacklisted hosts:
shard-kbltotal:3308 pass:1858 dwarn:1   dfail:0   fail:9   skip:1438 
time:8648s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

[Patchwork]

== Series Details ==

Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
URL   : https://patchwork.freedesktop.org/series/39647/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-hsw) fdo#105341 +1
Test gem_softpin:
Subgroup noreloc-s3:
skip   -> PASS   (shard-snb) fdo#103375 +1
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
fail   -> PASS   (shard-apl) fdo#101623
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

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

shard-apltotal:3394 pass:1786 dwarn:1   dfail:0   fail:8   skip:1597 
time:11772s
shard-hswtotal:3343 pass:1707 dwarn:1   dfail:0   fail:3   skip:1629 
time:10659s
shard-snbtotal:3467 pass:1363 dwarn:2   dfail:0   fail:2   skip:2100 
time:6925s
Blacklisted hosts:
shard-kbltotal:3381 pass:1899 dwarn:1   dfail:0   fail:9   skip:1471 
time:8899s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

[Benson Leung]

Hi Matt,

Minor commit message nits.

On Thu, Mar 08, 2018 at 05:17:38PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> Previously it was assumed that eDP panels would advertise the lowest link
> rate required for their singular mode to function. With the introduction
> of more advanced features there are advantages to a panel advertising a
> higher rate then
s/then/than

> it needs for a its given mode. 

Don't need "its" here.

> For panels that did, the
> driver previously used a higher rate then necessary for that mode.
>
s/then/than

 
> Signed-off-by: Matt Atwood 

Tested-by: Benson Leung 

Tested this on a panel and system with the following source and sink rates:


[1.623225] [drm:intel_dp_print_rates] source rates: 162000, 216000, 27, 
324000, 432000, 54
[1.623230] [drm:intel_dp_print_rates] sink rates: 162000, 216000, 243000, 
27, 324000, 432000, 54
[1.623234] [drm:intel_dp_print_rates] common rates: 162000, 216000, 27, 
324000, 432000, 54

Prior to this patch, the driver would pick and train at 54:
[2.865653] [drm:intel_dp_start_link_train] [CONNECTOR:76:eDP-1] Link 
Training Passed at Link Rate = 54, Lane count = 4

After this patch, the driver picks and trains at 324000, which is enough
for the panel's native mode:
[5.359499] [drm:intel_dp_start_link_train] [CONNECTOR:76:eDP-1] Link 
Training Passed at Link Rate = 324000, Lane count = 4

Thanks!
Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature
___
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 [v2,1/3] drm/i915: store all mmio bases in intel_engines

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: store all mmio bases in 
intel_engines
URL   : https://patchwork.freedesktop.org/series/39644/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

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

shard-apltotal:3382 pass:1780 dwarn:1   dfail:0   fail:8   skip:1591 
time:11735s
shard-hswtotal:3468 pass:1772 dwarn:1   dfail:0   fail:3   skip:1691 
time:11645s
shard-snbtotal:3468 pass:1364 dwarn:1   dfail:0   fail:2   skip:2101 
time:6894s
Blacklisted hosts:
shard-kbltotal:3382 pass:1900 dwarn:1   dfail:0   fail:9   skip:1471 
time:8998s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Push irq_shift from 
gen8_cs_irq_handler() to caller (rev2)
URL   : https://patchwork.freedesktop.org/series/39651/
State : success

== Summary ==

Series 39651v2 series starting with [1/2] drm/i915: Push irq_shift from 
gen8_cs_irq_handler() to caller
https://patchwork.freedesktop.org/api/1.0/series/39651/revisions/2/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:466s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:576s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:472s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:504s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:518s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
70282c9ebe14 drm/i915: Trim gen11_gt_irq_handler
ba501078ebb6 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make edp optimize config

[Patchwork]

== Series Details ==

Series: drm/i915: make edp optimize config
URL   : https://patchwork.freedesktop.org/series/39652/
State : success

== Summary ==

Series 39652v1 drm/i915: make edp optimize config
https://patchwork.freedesktop.org/api/1.0/series/39652/revisions/1/mbox/

 Known issues:

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:477s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:464s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:518s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:420s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:470s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:502s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:504s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
955496d81a15 drm/i915: make edp optimize config

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uc: Sanitize uC

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Sanitize uC
URL   : https://patchwork.freedesktop.org/series/39634/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
incomplete -> PASS   (shard-snb)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_selftest:
Subgroup live_gtt:
incomplete -> PASS   (shard-apl) fdo#103927
Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +2
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
pass   -> FAIL   (shard-apl) fdo#103167
Subgroup fbc-suspend:
pass   -> FAIL   (shard-apl) fdo#101623
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3394 pass:1777 dwarn:2   dfail:0   fail:15  skip:1598 
time:11855s
shard-hswtotal:3467 pass:1770 dwarn:1   dfail:0   fail:4   skip:1691 
time:11626s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6881s
Blacklisted hosts:
shard-kbltotal:3152 pass:1697 dwarn:57  dfail:1   fail:17  skip:1374 
time:7710s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Kill scheduled work for Core platforms.

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Kill scheduled work for Core platforms.
URL   : https://patchwork.freedesktop.org/series/39650/
State : failure

== Summary ==

Applying: drm/i915/psr: Kill scheduled work for Core platforms.
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_psr.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/psr: Kill scheduled work for Core platforms.
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)
URL   : https://patchwork.freedesktop.org/series/39647/
State : success

== Summary ==

Series 39647v2 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
https://patchwork.freedesktop.org/api/1.0/series/39647/revisions/2/mbox/

 Known issues:

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:504s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:472s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:574s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:523s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:500s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:512s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
976ac989162d drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

[Chris Wilson]

Quoting Chris Wilson (2018-03-09 01:33:08)
>  gen11_gt_engine_intr(struct drm_i915_private * const i915,
>  const unsigned int bank, const unsigned int bit)
> @@ -2836,10 +2798,23 @@ static void
>  gen11_gt_irq_handler(struct drm_i915_private * const i915,
>  const u32 master_ctl)
>  {
> +   static const u8 bank0_map[] = {
> +   [GEN11_RCS0] = RCS,
> +   [GEN11_BCS]  = BCS,

Is there a reason why its RCS0 but BCS? And the multi-instance classes
actually use VCS(x)?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

[Chris Wilson]

Give the compiler a helping hand in mapping (bank,bit) to our struct
intel_engine_cs by trading object code size for data cache:

add/remove: 2/0 grow/shrink: 0/1 up/down: 48/-135 (-87)
Function old new   delta
bank1_map  -  32 +32
bank0_map  -  16 +16
gen11_irq_handler706 571-135

v2: u8 arrays for tighter packing

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_irq.c | 53 +++--
 1 file changed, 14 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c8c29d8ecbab..e423ec58e5d2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2762,44 +2762,6 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915; \
 __fini_wedge((W)))
 
-static void
-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-   const unsigned int bank,
-   const unsigned int engine_n,
-   const u16 iir)
-{
-   struct intel_engine_cs ** const engine = i915->engine;
-
-   switch (bank) {
-   case 0:
-   switch (engine_n) {
-
-   case GEN11_RCS0:
-   return gen8_cs_irq_handler(engine[RCS], iir);
-
-   case GEN11_BCS:
-   return gen8_cs_irq_handler(engine[BCS], iir);
-   }
-   case 1:
-   switch (engine_n) {
-
-   case GEN11_VCS(0):
-   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-   case GEN11_VCS(1):
-   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-   case GEN11_VCS(2):
-   return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-   case GEN11_VCS(3):
-   return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-   case GEN11_VECS(0):
-   return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-   case GEN11_VECS(1):
-   return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-   }
-   }
-}
-
 static u32
 gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
@@ -2836,10 +2798,23 @@ static void
 gen11_gt_irq_handler(struct drm_i915_private * const i915,
 const u32 master_ctl)
 {
+   static const u8 bank0_map[] = {
+   [GEN11_RCS0] = RCS,
+   [GEN11_BCS]  = BCS,
+   };
+   static const u8 bank1_map[] = {
+   [GEN11_VCS(0)]  = _VCS(0),
+   [GEN11_VCS(1)]  = _VCS(1),
+   [GEN11_VCS(2)]  = _VCS(2),
+   [GEN11_VCS(3)]  = _VCS(3),
+   [GEN11_VECS(0)] = _VECS(0),
+   [GEN11_VECS(1)] = _VECS(1),
+   };
void __iomem * const regs = i915->regs;
unsigned int bank;
 
for (bank = 0; bank < 2; bank++) {
+   const u8 *map = bank ? bank1_map : bank0_map;
unsigned long intr_dw;
unsigned int bit;
 
@@ -2859,7 +2834,7 @@ gen11_gt_irq_handler(struct drm_i915_private * const i915,
if (unlikely(!iir))
continue;
 
-   gen11_gt_engine_irq_handler(i915, bank, bit, iir);
+   gen8_cs_irq_handler(i915->engine[map[bit]], iir);
}
 
/* Clear must be after shared has been served for engine */
-- 
2.16.2

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

[Intel-gfx] [PATCH] drm/i915: make edp optimize config

[matthew . s . atwood]

From: Matt Atwood 

Previously it was assumed that eDP panels would advertise the lowest link
rate required for their singular mode to function. With the introduction
of more advanced features there are advantages to a panel advertising a
higher rate then it needs for a its given mode. For panels that did, the
driver previously used a higher rate then necessary for that mode.

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/i915/intel_dp.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a2eeede..aa6d77d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
  dev_priv->vbt.edp.bpp);
bpp = dev_priv->vbt.edp.bpp;
}
-
-   /*
-* Use the maximum clock and number of lanes the eDP panel
-* advertizes being capable of. The panels are generally
-* designed to support only a single clock and lane
-* configuration, and typically these values correspond to the
-* native resolution of the panel.
-*/
-   min_lane_count = max_lane_count;
-   min_clock = max_clock;
}
 
for (; bpp >= 6*3; bpp -= 2*3) {
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/2] drm/i915: Trim gen11_gt_irq_handler

[Chris Wilson]

Give the compiler a helping hand in mapping (bank,bit) to our struct
intel_engine_cs by trading object code size for data cache:

add/remove: 2/0 grow/shrink: 0/1 up/down: 192/-135 (57)
Function old new   delta
bank1_map  - 128+128
bank0_map  -  64 +64
gen11_irq_handler706 571-135

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_irq.c | 53 +++--
 1 file changed, 14 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c8c29d8ecbab..5a42d8a63677 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2762,44 +2762,6 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915; \
 __fini_wedge((W)))
 
-static void
-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-   const unsigned int bank,
-   const unsigned int engine_n,
-   const u16 iir)
-{
-   struct intel_engine_cs ** const engine = i915->engine;
-
-   switch (bank) {
-   case 0:
-   switch (engine_n) {
-
-   case GEN11_RCS0:
-   return gen8_cs_irq_handler(engine[RCS], iir);
-
-   case GEN11_BCS:
-   return gen8_cs_irq_handler(engine[BCS], iir);
-   }
-   case 1:
-   switch (engine_n) {
-
-   case GEN11_VCS(0):
-   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-   case GEN11_VCS(1):
-   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-   case GEN11_VCS(2):
-   return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-   case GEN11_VCS(3):
-   return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-   case GEN11_VECS(0):
-   return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-   case GEN11_VECS(1):
-   return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-   }
-   }
-}
-
 static u32
 gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
@@ -2836,10 +2798,23 @@ static void
 gen11_gt_irq_handler(struct drm_i915_private * const i915,
 const u32 master_ctl)
 {
+   static const int bank0_map[] = {
+   [GEN11_RCS0] = RCS,
+   [GEN11_BCS] = BCS,
+   };
+   static const int bank1_map[] = {
+   [GEN11_VCS(0)]  = _VCS(0),
+   [GEN11_VCS(1)]  = _VCS(1),
+   [GEN11_VCS(2)]  = _VCS(2),
+   [GEN11_VCS(3)]  = _VCS(3),
+   [GEN11_VECS(0)] = _VECS(0),
+   [GEN11_VECS(1)] = _VECS(1),
+   };
void __iomem * const regs = i915->regs;
unsigned int bank;
 
for (bank = 0; bank < 2; bank++) {
+   const int *map = bank ? bank1_map : bank0_map;
unsigned long intr_dw;
unsigned int bit;
 
@@ -2859,7 +2834,7 @@ gen11_gt_irq_handler(struct drm_i915_private * const i915,
if (unlikely(!iir))
continue;
 
-   gen11_gt_engine_irq_handler(i915, bank, bit, iir);
+   gen8_cs_irq_handler(i915->engine[map[bit]], iir);
}
 
/* Clear must be after shared has been served for engine */
-- 
2.16.2

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

[Intel-gfx] [PATCH 1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

[Chris Wilson]

Originally we were inlining gen8_cs_irq_handler() and so expected the
compiler to constant-fold away the irq_shift (so we had hardcoded it as
opposed to use engine->irq_shift). However, we dropped the inline given
the proliferation of gen8_cs_irq_handler()s. If we pull the shifting
of the iir into the caller, we can shrink the code still further:

add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34)
Function old new   delta
gen8_cs_irq_handler  123 118  -5
gen8_gt_irq_handler  261 248 -13
gen11_irq_handler722 706 -16

v2: Drop gen11_cs_irq_handler now that it is a simple
stub around gen8_cs_irq_handler (Daniele)

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_irq.c | 38 --
 1 file changed, 16 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index babf81cf668b..c8c29d8ecbab 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private 
*dev_priv,
 }
 
 static void
-gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
+gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
 {
struct intel_engine_execlists * const execlists = >execlists;
bool tasklet = false;
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
+   if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
if (READ_ONCE(engine->execlists.active)) {
__set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
tasklet = true;
}
}
 
-   if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
+   if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
tasklet |= USES_GUC_SUBMISSION(engine->i915);
}
@@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private 
*i915,
 {
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
gen8_cs_irq_handler(i915->engine[RCS],
-   gt_iir[0], GEN8_RCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_RCS_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[BCS],
-   gt_iir[0], GEN8_BCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_BCS_IRQ_SHIFT);
}
 
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
gen8_cs_irq_handler(i915->engine[VCS],
-   gt_iir[1], GEN8_VCS1_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[VCS2],
-   gt_iir[1], GEN8_VCS2_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
 
if (master_ctl & GEN8_GT_VECS_IRQ) {
gen8_cs_irq_handler(i915->engine[VECS],
-   gt_iir[3], GEN8_VECS_IRQ_SHIFT);
+   gt_iir[3] >> GEN8_VECS_IRQ_SHIFT);
}
 
if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
@@ -2762,12 +2762,6 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915; \
 __fini_wedge((W)))
 
-static __always_inline void
-gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir)
-{
-   gen8_cs_irq_handler(engine, iir, 0);
-}
-
 static void
 gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
const unsigned int bank,
@@ -2781,27 +2775,27 @@ gen11_gt_engine_irq_handler(struct drm_i915_private * 
const i915,
switch (engine_n) {
 
case GEN11_RCS0:
-   return gen11_cs_irq_handler(engine[RCS], iir);
+   return gen8_cs_irq_handler(engine[RCS], iir);
 
case GEN11_BCS:
-   return gen11_cs_irq_handler(engine[BCS], iir);
+   return gen8_cs_irq_handler(engine[BCS], iir);
}
case 1:
switch (engine_n) {
 
case GEN11_VCS(0):
-   return gen11_cs_irq_handler(engine[_VCS(0)], iir);
+   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
case GEN11_VCS(1):
-   return gen11_cs_irq_handler(engine[_VCS(1)], iir);
+   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
case 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.
URL   : https://patchwork.freedesktop.org/series/39648/
State : success

== Summary ==

Series 39648v1 drm/i915/psr: Display WA 0884 applied broadly for more HW 
tracking.
https://patchwork.freedesktop.org/api/1.0/series/39648/revisions/1/mbox/

 Known issues:

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:486s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:465s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:585s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:518s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:502s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:508s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
1888eb10d023 drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915: Disable preemption and sleeping 
while using the punit sideband (rev2)
URL   : https://patchwork.freedesktop.org/series/39555/
State : success

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
incomplete -> PASS   (shard-snb)

 Known issues:

Test drv_selftest:
Subgroup live_gtt:
incomplete -> PASS   (shard-apl) fdo#103927
Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
pass   -> FAIL   (shard-apl) fdo#101623
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test pm_lpsp:
Subgroup screens-disabled:
pass   -> FAIL   (shard-hsw) fdo#104941

fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3467 pass:1825 dwarn:1   dfail:0   fail:9   skip:1632 
time:12161s
shard-hswtotal:3429 pass:1754 dwarn:1   dfail:0   fail:2   skip:1670 
time:11059s
shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
time:6890s
Blacklisted hosts:
shard-kbltotal:3467 pass:1930 dwarn:15  dfail:1   fail:9   skip:1512 
time:9173s

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/psr: Kill scheduled work for Core platforms.

[Rodrigo Vivi]

The immediate enabling is actually not an issue for the
HW perspective for core platforms that have HW tracking.
HW will wait few identical idle frames before transitioning
to actual psr active anyways.

Note that this patch also remove the delayed activation
on HSW and BDW introduced by commit 'd0ac896a477d
("drm/i915: Delay first PSR activation.")'. This was
introduced to fix a blank screen on VLV/CHV and also
masked some frozen screens on other core platforms.
Probably the same that we are now properly hunting and fixing.

Furthermore, if we stop using delayed activation on core
platforms we will be able, on following up patches,
to use available workarounds to make HW tracking properly
exit PSR instead of the big nuke of disabling psr and
re-enable on exit and activate respectively.
At least on few reliable cases.

v2:(DK): Remove unnecessary WARN_ONs and make some other
 VLV | CHV more readable.
v3: Do it regardless the timer rework.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 17 +
 drivers/gpu/drm/i915/intel_psr.c| 22 ++
 2 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e838c765b251..2fd6f98364d3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2572,15 +2572,11 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
   dev_priv->psr.busy_frontbuffer_bits);
-   seq_printf(m, "Re-enable work scheduled: %s\n",
-  yesno(work_busy(_priv->psr.work.work)));
 
-   if (HAS_DDI(dev_priv)) {
-   if (dev_priv->psr.psr2_support)
-   enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
-   else
-   enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
-   } else {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   seq_printf(m, "Re-enable work scheduled: %s\n",
+  yesno(work_busy(_priv->psr.work.work)));
+
for_each_pipe(dev_priv, pipe) {
enum transcoder cpu_transcoder =
intel_pipe_to_cpu_transcoder(dev_priv, pipe);
@@ -2599,6 +2595,11 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
 
intel_display_power_put(dev_priv, power_domain);
}
+   } else {
+   if (dev_priv->psr.psr2_support)
+   enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
+   else
+   enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
}
 
seq_printf(m, "Main link in standby mode: %s\n",
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b0286722a72f..9705d89c5ebf 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -652,9 +652,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
dev_priv->psr.enable_source(intel_dp, crtc_state);
dev_priv->psr.enabled = intel_dp;
 
-   if (INTEL_GEN(dev_priv) >= 9) {
-   intel_psr_activate(intel_dp);
-   } else {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
/*
 * FIXME: Activation should happen immediately since this
 * function is just called after pipe is fully trained and
@@ -667,6 +665,8 @@ void intel_psr_enable(struct intel_dp *intel_dp,
 */
schedule_delayed_work(_priv->psr.work,
  
msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
+   } else {
+   intel_psr_activate(intel_dp);
}
 
 unlock:
@@ -1045,10 +1045,15 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
}
}
 
-   if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
-   if (!work_busy(_priv->psr.work.work))
-   schedule_delayed_work(_priv->psr.work,
- msecs_to_jiffies(100));
+   if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   if (!work_busy(_priv->psr.work.work))
+   schedule_delayed_work(_priv->psr.work,
+ msecs_to_jiffies(100));
+   } else {
+   intel_psr_activate(dev_priv->psr.enabled);
+   }
+   }
mutex_unlock(_priv->psr.lock);
 }
 
@@ -1095,7 +1100,8 @@ void intel_psr_init(struct drm_i915_private 

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 04:21:53PM -0800, Pandiyan, Dhinakaran wrote:
> On Wed, 2018-03-07 at 15:43 -0800, Rodrigo Vivi wrote:
> > On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote:
> > > On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > > > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > > > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > > > > plane MMIOs are written to. But this flush should not be necessary 
> > > > > > for
> > > > > > PSR as hardware tracking triggers PSR exit when MMIOs are written. 
> > > > > > As
> > > > > > for FBC, the spec says "Flips or changes to plane size and panning" 
> > > > > > cause
> > > > > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can 
> > > > > > ignore
> > > > > > cursor updates in their frontbuffer_flush implementations.
> > > > > > 
> > > > > >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > > > > > "Compressing: yes" when I move the cursor around.
> > > > > > 
> > > > > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush 
> > > > > > frontbuffer.
> > > > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > > > > 
> > > > > > Cc: Paulo Zanoni 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Cc: Chris Wilson 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > > index 91ce8a0522a3..18b08e263ee1 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane 
> > > > > > *plane,
> > > > > > if (ret)
> > > > > > goto out_unlock;
> > > > > >  
> > > > > > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > > > > > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> > > > > 
> > > > > What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> > > > > aiui.
> > > > > -Chris
> > > > 
> > > > 
> > > > That was the idea but there's a problem with not knowing if PSR exit is
> > > > fully complete before we begin updating the plane registers in
> > > > pipe_update_start().
> > > > 
> > > > Let's say PSR was active and display is in DC6. A flip comes in, without
> > > > _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
> > > > enabling that happens in pipe_update_start. We immediately follow that
> > > > with programming the plane MMIO's without checking if PSR fully exited.
> > > > If PSR and DC6 happen to exit while we were in the middle of programming
> > > > plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
> > > > partially programmed registers. _flush(DIRTYFB) gives us an opportunity
> > > > to exit PSR fully by starting early.
> > > > 
> > > > As for legacy_cursor_update(), since there is no vblank enabling
> > > > involved, we avoid updating the MMIO's in the midst of PSR exit
> > > 
> > > I don't believe you will be ever in a case that you write to any register
> > > and get any flip or anything without exiting DC6 before that happens.
> > > 
> > > Or the CSR mechanism of DC6 will be simply wrong.
> > > 
> > > Would this be enough?
> > 
> > ok... just ignore my previous comment...
> > I believe we can move with the safest side and maybe revisit this later.
> > 
> > From what I remember of the FBC nuke needs as well I believe this is
> > the right move.
> > 
> > Although I'm asking myself now if we are not changing the meaning of the
> > ORIGINS here. Shouldn't we add a new origin and update the handling?
> > 
> > of "flip" is a good description for this call?
> > 
> 
> The action taken for this frontbuffer_flush() is the same as origin ==
> FLIP. I think it is better to add a new one when we want the features
> (psr,fbc) to distinguish and react differently. 

Maybe we could change the names from ORIGIN_something to something more
meaninful about the operation to be performed then...

Anyways I don't want to force increase the number of origins and duplicate
the code on a niptic and I don't have better suggestions for names...

So I guess we move fwd with this for now...


Reviewed-by: Rodrigo Vivi 




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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-07 at 15:34 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > plane MMIOs are written to. But this flush should not be necessary for
> > > PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> > > for FBC, the spec says "Flips or changes to plane size and panning" cause
> > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> > > cursor updates in their frontbuffer_flush implementations.
> > > 
> > >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > > "Compressing: yes" when I move the cursor around.
> > > 
> > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer.
> > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > 
> > > Cc: Paulo Zanoni 
> > > Cc: Ville Syrjälä 
> > > Cc: Chris Wilson 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 91ce8a0522a3..18b08e263ee1 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane 
> > > *plane,
> > > if (ret)
> > > goto out_unlock;
> > >  
> > > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> > 
> > What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> > aiui.
> > -Chris
> 
> 
> That was the idea but there's a problem with not knowing if PSR exit is
> fully complete before we begin updating the plane registers in
> pipe_update_start().
> 
> Let's say PSR was active and display is in DC6. A flip comes in, without
> _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
> enabling that happens in pipe_update_start.

Correction, _flush(DIRTYFB) in prepare_plane_fb() has no effect because
the gem object has no frontbuffer bits set. We should just remove that
misleading call.

>  We immediately follow that
> with programming the plane MMIO's without checking if PSR fully exited.
> If PSR and DC6 happen to exit while we were in the middle of programming
> plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
> partially programmed registers. _flush(DIRTYFB) gives us an opportunity
> to exit PSR fully by starting early.
> 
> As for legacy_cursor_update(), since there is no vblank enabling
> involved, we avoid updating the MMIO's in the midst of PSR exit
> 
> 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

[Chris Wilson]

Originally we were inlining gen8_cs_irq_handler() and so expected the
compiler to constant-fold away the irq_shift (so we had hardcoded it as
opposed to use engine->irq_shift). However, we dropped the inline given
the proliferation of gen8_cs_irq_handler()s. If we pull the shifting
of the iir into the caller, we can shrink the code still further:

add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34)
Function old new   delta
gen8_cs_irq_handler  123 118  -5
gen8_gt_irq_handler  261 248 -13
gen11_irq_handler722 706 -16

v2: Drop gen11_cs_irq_handler now that it is a simple
stub around gen8_cs_irq_handler (Daniele)

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_irq.c | 38 --
 1 file changed, 16 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index babf81cf668b..c8c29d8ecbab 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private 
*dev_priv,
 }
 
 static void
-gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
+gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
 {
struct intel_engine_execlists * const execlists = >execlists;
bool tasklet = false;
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
+   if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
if (READ_ONCE(engine->execlists.active)) {
__set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
tasklet = true;
}
}
 
-   if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
+   if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
tasklet |= USES_GUC_SUBMISSION(engine->i915);
}
@@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private 
*i915,
 {
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
gen8_cs_irq_handler(i915->engine[RCS],
-   gt_iir[0], GEN8_RCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_RCS_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[BCS],
-   gt_iir[0], GEN8_BCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_BCS_IRQ_SHIFT);
}
 
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
gen8_cs_irq_handler(i915->engine[VCS],
-   gt_iir[1], GEN8_VCS1_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[VCS2],
-   gt_iir[1], GEN8_VCS2_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
 
if (master_ctl & GEN8_GT_VECS_IRQ) {
gen8_cs_irq_handler(i915->engine[VECS],
-   gt_iir[3], GEN8_VECS_IRQ_SHIFT);
+   gt_iir[3] >> GEN8_VECS_IRQ_SHIFT);
}
 
if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
@@ -2762,12 +2762,6 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915; \
 __fini_wedge((W)))
 
-static __always_inline void
-gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir)
-{
-   gen8_cs_irq_handler(engine, iir, 0);
-}
-
 static void
 gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
const unsigned int bank,
@@ -2781,27 +2775,27 @@ gen11_gt_engine_irq_handler(struct drm_i915_private * 
const i915,
switch (engine_n) {
 
case GEN11_RCS0:
-   return gen11_cs_irq_handler(engine[RCS], iir);
+   return gen8_cs_irq_handler(engine[RCS], iir);
 
case GEN11_BCS:
-   return gen11_cs_irq_handler(engine[BCS], iir);
+   return gen8_cs_irq_handler(engine[BCS], iir);
}
case 1:
switch (engine_n) {
 
case GEN11_VCS(0):
-   return gen11_cs_irq_handler(engine[_VCS(0)], iir);
+   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
case GEN11_VCS(1):
-   return gen11_cs_irq_handler(engine[_VCS(1)], iir);
+   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
case 

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Quoting Antonio Argenziano (2018-03-09 00:45:42)
> 
> 
> On 08/03/18 09:13, Chris Wilson wrote:
> > Exercise some new API that allows applications to request that
> > individual contexts are executed within a desired frequency range.
> > 
> > v2: Split single/continuous set_freq subtests
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Paneri, Praveen 
> > Cc: Kamble, Sagar A 
> > Cc: Antonio Argenziano 
> > ---
> >   tests/Makefile.am  |   1 +
> >   tests/Makefile.sources |   1 +
> >   tests/gem_ctx_freq.c   | 604 
> > +
> >   tests/meson.build  |   1 +
> >   4 files changed, 607 insertions(+)
> >   create mode 100644 tests/gem_ctx_freq.c
> > 
> 
> > +static void single(int fd, const struct intel_execution_engine *e)
> > +{
> > + const unsigned int engine = e->exec_id | e->flags;
> > + uint32_t ctx = gem_context_create(fd);
> > + uint32_t min, max;
> > + double measured;
> > + igt_spin_t *spin;
> > + int pmu;
> > +
> > + get_freq(fd, ctx, , );
> > + igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
> > +
> > + pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
> > + igt_require(pmu >= 0);
> > +
> > + for (uint32_t freq = min + 50; freq <= max; freq += 100) {
> 
> Although it is done in the smoke test, it would be interesting if freq's 
> values were a bit randomized.

It was intentionally increment only originally because the
implementation was fast to upclock and slow to downclock. Given the
challenge of the smoketest, I've shelved that laziness until it can pass
that not particularly challenging test.

I did have in mind doing an up/down ramp. We should also check that
changing min while keeping max fixed should not affect a 100% load like
the spinners.
 
> > + uint32_t cur, discard;
> > +
> > + set_freq(fd, ctx, freq, freq);
> > + get_freq(fd, ctx, , );
> 
> igt_assert_eq(freq, cur)?

Not quite. The trick is that the interface is not strictly idempotent,
since we pass in MHz, the driver converts that into freq bins and spits
it back out to the nearest MHz. So cur is not strictly freq, it just
happens that 50MHz is the bin size on gen9.

The idea here is that we grab the adjusted freq from the driver to
validate with.

> > +
> > + gem_quiescent_gpu(fd);
> > + spin = __igt_spin_batch_new(fd, ctx, engine, 0);
> > + usleep(1);
> 
> I guess here we wait for the frequency changes to take effect, maybe a 
> small comment would help.

And for the batch to be submitted. Asynchronous interfaces make it hard
to pinpoint when things occur. We keep muttering about extending
igt_spin_t to have an option for wait-for-exec (basically have it write
out a dword that we can spin on)

usleep(1); /* wait for execution + freq change */

> > +static void sandwich(int fd)
> > +{
> > + uint32_t ctx = gem_context_create(fd);
> > + unsigned int engine;
> > + uint32_t min, max;
> > + igt_spin_t *spin;
> > + int pmu;
> > +
> > + pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
> > + igt_require(pmu >= 0);
> > +
> > + spin = igt_spin_batch_new(fd, ctx, 0, 0);
> > + get_freq(fd, ctx, , );
> > + set_freq(fd, ctx, min, min);
> > + for_each_physical_engine(fd, engine) {
> > + struct drm_i915_gem_exec_object2 obj = {
> > + .handle = spin->handle,
> > + };
> > + struct drm_i915_gem_execbuffer2 eb = {
> > + .buffer_count = 1,
> > + .buffers_ptr = to_user_pointer(),
> > + .flags = engine,
> > + .rsvd1 = ctx,
> > + };
> > + uint32_t cur, discard;
> > + double measured;
> > +
> > + min += 50;
> > + if (min > max)
> > + break;
> > +
> > + set_freq(fd, ctx, min, min);
> > + get_freq(fd, ctx, , );
> > +
> > + gem_execbuf(fd, );
> > + usleep(1);
> > +
> > + measured = measure_frequency(pmu, SAMPLE_PERIOD);
> > + igt_debugfs_dump(fd, "i915_rps_boost_info");
> > +
> > + igt_info("Measured %.1fMHz, expected %dMhz\n", measured, cur);
> > + igt_assert(measured > cur - 100 && measured < cur + 100);
> 
> Does the frequency change after each execbuf?

Yes. This turned into just an exercise across engines, bumping the
desired freq. I wanted to try and validate the min/max bounds, but ran
into the challenge that the gpu is only running at the highest frequency
it can get because of the busy spinner :)

> > +static void smoketest(int fd, int timeout)
> > +{
> > + unsigned int engines[16];
> 
> use a macro instead of magic number 16.

#define 

[Intel-gfx] [PATCH] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Rodrigo Vivi]

WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
the CPU host modify writes may not get updated on the Display
as expected.
WA: Write 0x to CUR_SURFLIVE_A with every CPU
host modify write to trigger PSR exit."

We can also find on spec other cases where they describe
bogus writes to cursor registers to force PSR exit with
HW tracking. And it was confirmed by HW engineers that
this Wa can be safely applied for any frontbuffer activity.

So let's use this more and more here instead of forcibly
disable and re-enable PSR everytime that we have a simple
reliable flush case.

Other commits improve the fbcon/fbdev use a lot, but this
approach is the only when where we can get a fully reliable
console with no slowness or missed frames and PSR still
enabled and active.

v2: - Rebase on drm-tip
- (DK) Add a comment to explain that WA
tells about writing 0 to CUR_SURFLIVE_A but we write to
CUR_SURFLIVE(pipe).
v3: Wa doesn't work on PSR2.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_psr.c | 19 +--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..abdc513a9edd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6032,6 +6032,9 @@ enum {
 #define IVB_CURSOR_B_OFFSET 0x71080
 #define IVB_CURSOR_C_OFFSET 0x72080
 
+#define _CUR_SURLIVE   0x700AC
+#define CUR_SURLIVE(pipe)  _CURSOR2(pipe, _CUR_SURLIVE)
+
 /* Display A control */
 #define _DSPACNTR  0x70180
 #define   DISPLAY_PLANE_ENABLE (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 30932527e663..b0286722a72f 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1027,8 +1027,23 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
 
/* By definition flush = invalidate + flush */
-   if (frontbuffer_bits)
-   intel_psr_exit(dev_priv);
+   if (frontbuffer_bits) {
+   if (dev_priv->psr.psr2_support ||
+   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   intel_psr_exit(dev_priv);
+   } else {
+   /*
+* Display WA #0884: all
+* This documented WA for bxt can be safely applied
+* broadly so we can force HW tracking to exit PSR
+* instead of disabling and re-enabling.
+* Workaround tells us to write 0 to CUR_SURLIVE_A,
+* but it makes more sense write to the current active
+* pipe.
+*/
+   I915_WRITE(CUR_SURLIVE(pipe), 0);
+   }
+   }
 
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
if (!work_busy(_priv->psr.work.work))
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: add a selftest for the mmio_bases table

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:28)
> Check that the entries are in reverse gen order and that the first entry
> and all the following entries with gen > 0 have an mmio base set.
> 
> Suggested-by: Chris Wilson 
> Cc: Chris Wilson 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c |  1 +
>  .../gpu/drm/i915/selftests/i915_mock_selftests.h   |  1 +
>  drivers/gpu/drm/i915/selftests/intel_engine_cs.c   | 48 
> ++
>  3 files changed, 50 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/selftests/intel_engine_cs.c
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 08711665061c..a33171d82aee 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -2131,4 +2131,5 @@ void intel_disable_engine_stats(struct intel_engine_cs 
> *engine)
>  
>  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
>  #include "selftests/mock_engine.c"
> +#include "selftests/intel_engine_cs.c"
>  #endif
> diff --git a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h 
> b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
> index 9a48aa441743..2842f93ca29e 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
> +++ b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
> @@ -23,3 +23,4 @@ selftest(vma, i915_vma_mock_selftests)
>  selftest(evict, i915_gem_evict_mock_selftests)
>  selftest(gtt, i915_gem_gtt_mock_selftests)
>  selftest(hugepages, i915_gem_huge_page_mock_selftests)
> +selftest(engine, intel_engine_cs_mock_selftests)

Plonk this after uncore. It's a lowlevel sanity check that should come
before we start looking at features.

> diff --git a/drivers/gpu/drm/i915/selftests/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c
> new file mode 100644
> index ..8ef453905520
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c
> @@ -0,0 +1,48 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright © 2018 Intel Corporation
> + */
> +
> +#include "../i915_selftest.h"
> +
> +static int intel_mmio_bases_check(void)
> +{
> +   const struct engine_info *info;
> +   int i, j;
> +   u32 gen;
> +   s32 prev;
> +
> +   for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
> +   info = _engines[i];
> +
> +   for (prev = -1, j = MAX_MMIO_BASES -1; j >= 0; j--) {
> +   gen = info->mmio_bases[j].gen;
> +
> +   if (prev >= (s32)gen) {
> +   pr_err("%s: engine[%d]: mmio base for gen %x "
> +   "is before the one for gen %x\n",
> +  __func__, i, gen, prev);
> +   return -EINVAL;
> +   }
> +
> +   if ((j == 0 || gen > 0) && !info->mmio_bases[j].base) 
> {

Ok, setting gen=0 upset us. Make that gen=1 in the previous patch.

Looping backwards here definitely seems to make it harder than it needs
to be. We only need to validate the array as seen by the algorithm so,

u8 prev = U8_MAX;
for (j = 0; j < MAX_MMIO_BASES; j++) {
u8 gen = info->mmio_bases[j].gen;

if (gen >= prev) {
...
return -EINVAL;

}

if (gen == 0)
break;

if (!info->mmio.bases[j].base) {
...
return -EINVAL;
}

prev = gen;
}
pr_info("%s: min gen supported for %s = %d\n", __func__, magic_engine_name(i), 
prev);

I'm not sure how we could automate that check (not without hardcoding
the same information twice), so just print it.

> +
> +int intel_engine_cs_mock_selftests(void)
> +{
> +   return intel_mmio_bases_check();

I'd stick this in a
static const struct i915_subtest tests[] = {
SUBTEST(mmio_bases_check),
};

return i915_subtests(tests, NULL);
just for the convenience of adding more.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Antonio Argenziano]

On 08/03/18 09:13, Chris Wilson wrote:

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
  tests/Makefile.am  |   1 +
  tests/Makefile.sources |   1 +
  tests/gem_ctx_freq.c   | 604 +
  tests/meson.build  |   1 +
  4 files changed, 607 insertions(+)
  create mode 100644 tests/gem_ctx_freq.c




+static void single(int fd, const struct intel_execution_engine *e)
+{
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 0);
+
+   for (uint32_t freq = min + 50; freq <= max; freq += 100) {


Although it is done in the smoke test, it would be interesting if freq's 
values were a bit randomized.



+   uint32_t cur, discard;
+
+   set_freq(fd, ctx, freq, freq);
+   get_freq(fd, ctx, , );


igt_assert_eq(freq, cur)?


+
+   gem_quiescent_gpu(fd);
+   spin = __igt_spin_batch_new(fd, ctx, engine, 0);
+   usleep(1);


I guess here we wait for the frequency changes to take effect, maybe a 
small comment would help.



+
+   measured = measure_frequency(pmu, SAMPLE_PERIOD);
+   igt_debugfs_dump(fd, "i915_rps_boost_info");
+
+   igt_spin_batch_free(fd, spin);
+   igt_info("%s(single): Measured %.1fMHz, expected %dMhz\n",
+e->name, measured, cur);
+   igt_assert(measured > cur - 100 && measured < cur + 100);
+   }
+   gem_quiescent_gpu(fd);
+
+   close(pmu);
+   gem_context_destroy(fd, ctx);
+}
+



+
+static void sandwich(int fd)
+{
+   uint32_t ctx = gem_context_create(fd);
+   unsigned int engine;
+   uint32_t min, max;
+   igt_spin_t *spin;
+   int pmu;
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 0);
+
+   spin = igt_spin_batch_new(fd, ctx, 0, 0);
+   get_freq(fd, ctx, , );
+   set_freq(fd, ctx, min, min);
+   for_each_physical_engine(fd, engine) {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .flags = engine,
+   .rsvd1 = ctx,
+   };
+   uint32_t cur, discard;
+   double measured;
+
+   min += 50;
+   if (min > max)
+   break;
+
+   set_freq(fd, ctx, min, min);
+   get_freq(fd, ctx, , );
+
+   gem_execbuf(fd, );
+   usleep(1);
+
+   measured = measure_frequency(pmu, SAMPLE_PERIOD);
+   igt_debugfs_dump(fd, "i915_rps_boost_info");
+
+   igt_info("Measured %.1fMHz, expected %dMhz\n", measured, cur);
+   igt_assert(measured > cur - 100 && measured < cur + 100);


Does the frequency change after each execbuf?


+   }
+   igt_spin_batch_free(fd, spin);
+   gem_quiescent_gpu(fd);
+
+   gem_context_destroy(fd, ctx);
+   close(pmu);
+}
+
+static void pwm(int fd, unsigned int *engines, unsigned int nengine, int link)
+{
+   uint32_t ctx[nengine];
+
+   fcntl(link, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK);
+
+   for (unsigned int n = 0; n < nengine; n++)
+   ctx[n] = gem_context_create(fd);
+
+   do {
+   igt_spin_t *spin;
+   struct {
+   uint32_t engine;
+   uint32_t min;
+   uint32_t max;
+   } req;
+
+   while (read(link, , sizeof(req)) > 0) {
+   if ((req.engine | req.min | req.max) == 0)
+   goto out;
+
+   igt_assert(req.engine < nengine);
+   set_freq(fd, ctx[req.engine], req.min, req.max);
+   }
+
+   /* Create a 20% load using busy spinners */
+   spin = __igt_spin_batch_new(fd, ctx[0], engines[0], 0);
+   for (unsigned int n = 1; n < nengine; n++) {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

[Patchwork]

== Series Details ==

Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
URL   : https://patchwork.freedesktop.org/series/39647/
State : success

== Summary ==

Series 39647v1 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
https://patchwork.freedesktop.org/api/1.0/series/39647/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:377s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:520s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:467s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:420s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:523s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:507s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
2239b752c241 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: store all mmio bases in intel_engines

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:27)
> The mmio bases we're currently storing in the intel_engines array are
> only valid for a subset of gens, so we need to ignore them and use
> different values in some cases. Instead of doing that, we can have a
> table of [starting gen, mmio base] pairs for each engine in
> intel_engines and select the correct one based on the gen we're running
> on in a consistent way.
> 
> v2: document that the list goes in reverse order, update starting gen
> for render (Chris)
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
> +static u32 __engine_mmio_base(struct drm_i915_private *i915,
> + const struct engine_mmio_base* bases)
> +{
> +   int i;
> +
> +   for (i = 0; i < MAX_MMIO_BASES; i++)
> +   if (INTEL_GEN(i915) >= bases[i].gen)
> +   break;
> +
> +   GEM_BUG_ON(i == MAX_MMIO_BASES);
> +   GEM_BUG_ON(!bases[i].base);

Idly contemplating

do {
if (INTEL_GEN(i915) >= bases->gen)
return bases->base;

bases++;
} while(1);

given the selftest for validating adding new gen.

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

Re: [Intel-gfx] [PATCH] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

[Daniele Ceraolo Spurio]

On 08/03/18 16:16, Chris Wilson wrote:

Originally we were inlining gen8_cs_irq_handler() and so expected the
compiler to constant-fold away the irq_shift (so we had hardcoded it as
opposed to use engine->irq_shift). However, we dropped the inline given
the proliferation of gen8_cs_irq_handler()s. If we pull the shifting
of the iir into the caller, we can shrink the code still further:

add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34)
Function old new   delta
gen8_cs_irq_handler  123 118  -5
gen8_gt_irq_handler  261 248 -13
gen11_irq_handler722 706 -16

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/i915_irq.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index babf81cf668b..84c0043e1637 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private 
*dev_priv,
  }
  
  static void

-gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
+gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
  {
struct intel_engine_execlists * const execlists = >execlists;
bool tasklet = false;
  
-	if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {

+   if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
if (READ_ONCE(engine->execlists.active)) {
__set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
tasklet = true;
}
}
  
-	if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {

+   if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
tasklet |= USES_GUC_SUBMISSION(engine->i915);
}
@@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private 
*i915,
  {
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
gen8_cs_irq_handler(i915->engine[RCS],
-   gt_iir[0], GEN8_RCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_RCS_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[BCS],
-   gt_iir[0], GEN8_BCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_BCS_IRQ_SHIFT);
}
  
  	if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {

gen8_cs_irq_handler(i915->engine[VCS],
-   gt_iir[1], GEN8_VCS1_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[VCS2],
-   gt_iir[1], GEN8_VCS2_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
  
  	if (master_ctl & GEN8_GT_VECS_IRQ) {

gen8_cs_irq_handler(i915->engine[VECS],
-   gt_iir[3], GEN8_VECS_IRQ_SHIFT);
+   gt_iir[3] >> GEN8_VECS_IRQ_SHIFT);
}
  
  	if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {

@@ -2765,7 +2765,7 @@ static void __fini_wedge(struct wedge_me *w)
  static __always_inline void
  gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir)
  {
-   gen8_cs_irq_handler(engine, iir, 0);
+   gen8_cs_irq_handler(engine, iir);


Could potentially drop gen11_cs_irq_handler entirely since now it is 
identical to gen8_cs_irq_handler, but either way:


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


  }
  
  static void



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

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: move gen8 irq shifts to intel_lrc.c

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:29)
> The only usage outside the intel_lrc.c file is in the ringbuffer
> init, but the irq mask calculated there is then overwritten for
> all engines that have a non-zero shift, so we can drop it.
> 
> This change is not aimed at code saving but at removing from
> intel_engines information that does not apply to all gens that have
> the engine. When checking without the temporary WARN_ON, code size
> is basically unchanged:
> 
> add/remove: 1/0 grow/shrink: 3/4 up/down: 70/-67 (3)
> Function old new   delta
> logical_ring_setup   315 343 +28
> irq_shifts -  28 +28
> intel_init_render_ring_buffer258 268 +10
> reset_common_ring704 708  +4
> intel_engine_init_cmd_parser10641058  -6
> intel_engines_init_mmio 12641256  -8
> intel_ring_default_vfuncs584 563 -21
> intel_engines224 192 -32
> Total: Before=1479719, After=1479722, chg +0.00%
> 
> Suggested-by: Michel Thierry 
> Signed-off-by: Daniele Ceraolo Spurio 

With the missing static const,
Reviewed-by: Chris Wilson 

I had a look at restoring the use of engine->irq_shift in the irq
handlers, and while that does shrink the code abit, rearranging the code
brought even more savings. So I don't see a need to keep
engine->irq_shift around, and we can always bring it back but unlikely
if future gen do not need it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: store all mmio bases in 
intel_engines
URL   : https://patchwork.freedesktop.org/series/39644/
State : success

== Summary ==

Series 39644v1 series starting with [v2,1/3] drm/i915: store all mmio bases in 
intel_engines
https://patchwork.freedesktop.org/api/1.0/series/39644/revisions/1/mbox/

 Known issues:

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:481s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:466s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:394s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:402s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:467s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:527s

469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC 
integration manifest
b70c67929415 drm/i915: move gen8 irq shifts to intel_lrc.c
879b9440fc97 drm/i915: add a selftest for the mmio_bases table
ef4f215557ee drm/i915: store all mmio bases in intel_engines

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

[Chris Wilson]

Originally we were inlining gen8_cs_irq_handler() and so expected the
compiler to constant-fold away the irq_shift (so we had hardcoded it as
opposed to use engine->irq_shift). However, we dropped the inline given
the proliferation of gen8_cs_irq_handler()s. If we pull the shifting
of the iir into the caller, we can shrink the code still further:

add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34)
Function old new   delta
gen8_cs_irq_handler  123 118  -5
gen8_gt_irq_handler  261 248 -13
gen11_irq_handler722 706 -16

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_irq.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index babf81cf668b..84c0043e1637 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private 
*dev_priv,
 }
 
 static void
-gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
+gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
 {
struct intel_engine_execlists * const execlists = >execlists;
bool tasklet = false;
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
+   if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
if (READ_ONCE(engine->execlists.active)) {
__set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
tasklet = true;
}
}
 
-   if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
+   if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
tasklet |= USES_GUC_SUBMISSION(engine->i915);
}
@@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private 
*i915,
 {
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
gen8_cs_irq_handler(i915->engine[RCS],
-   gt_iir[0], GEN8_RCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_RCS_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[BCS],
-   gt_iir[0], GEN8_BCS_IRQ_SHIFT);
+   gt_iir[0] >> GEN8_BCS_IRQ_SHIFT);
}
 
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
gen8_cs_irq_handler(i915->engine[VCS],
-   gt_iir[1], GEN8_VCS1_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT);
gen8_cs_irq_handler(i915->engine[VCS2],
-   gt_iir[1], GEN8_VCS2_IRQ_SHIFT);
+   gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
 
if (master_ctl & GEN8_GT_VECS_IRQ) {
gen8_cs_irq_handler(i915->engine[VECS],
-   gt_iir[3], GEN8_VECS_IRQ_SHIFT);
+   gt_iir[3] >> GEN8_VECS_IRQ_SHIFT);
}
 
if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
@@ -2765,7 +2765,7 @@ static void __fini_wedge(struct wedge_me *w)
 static __always_inline void
 gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir)
 {
-   gen8_cs_irq_handler(engine, iir, 0);
+   gen8_cs_irq_handler(engine, iir);
 }
 
 static void
-- 
2.16.2

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: store all mmio bases in 
intel_engines
URL   : https://patchwork.freedesktop.org/series/39644/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: store all mmio bases in intel_engines
Okay!

Commit: drm/i915: add a selftest for the mmio_bases table
Okay!

Commit: drm/i915: move gen8 irq shifts to intel_lrc.c
+drivers/gpu/drm/i915/intel_lrc.c:1581:14: warning: symbol 'irq_shifts' was not 
declared. Should it be static?

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

[Intel-gfx] [PATCH v2 2/3] drm/i915: add a selftest for the mmio_bases table

[Daniele Ceraolo Spurio]

Check that the entries are in reverse gen order and that the first entry
and all the following entries with gen > 0 have an mmio base set.

Suggested-by: Chris Wilson 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_engine_cs.c |  1 +
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |  1 +
 drivers/gpu/drm/i915/selftests/intel_engine_cs.c   | 48 ++
 3 files changed, 50 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/selftests/intel_engine_cs.c

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 08711665061c..a33171d82aee 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -2131,4 +2131,5 @@ void intel_disable_engine_stats(struct intel_engine_cs 
*engine)
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_engine.c"
+#include "selftests/intel_engine_cs.c"
 #endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h 
b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
index 9a48aa441743..2842f93ca29e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
@@ -23,3 +23,4 @@ selftest(vma, i915_vma_mock_selftests)
 selftest(evict, i915_gem_evict_mock_selftests)
 selftest(gtt, i915_gem_gtt_mock_selftests)
 selftest(hugepages, i915_gem_huge_page_mock_selftests)
+selftest(engine, intel_engine_cs_mock_selftests)
diff --git a/drivers/gpu/drm/i915/selftests/intel_engine_cs.c 
b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c
new file mode 100644
index ..8ef453905520
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c
@@ -0,0 +1,48 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include "../i915_selftest.h"
+
+static int intel_mmio_bases_check(void)
+{
+   const struct engine_info *info;
+   int i, j;
+   u32 gen;
+   s32 prev;
+
+   for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
+   info = _engines[i];
+
+   for (prev = -1, j = MAX_MMIO_BASES -1; j >= 0; j--) {
+   gen = info->mmio_bases[j].gen;
+
+   if (prev >= (s32)gen) {
+   pr_err("%s: engine[%d]: mmio base for gen %x "
+   "is before the one for gen %x\n",
+  __func__, i, gen, prev);
+   return -EINVAL;
+   }
+
+   if ((j == 0 || gen > 0) && !info->mmio_bases[j].base) {
+   pr_err("%s: engine[%d]: invalid mmio base (%x) "
+   "for gen %x at entry %u\n",
+  __func__, i, info->mmio_bases[j].base, 
gen, j);
+   return -EINVAL;
+   }
+
+   /* we can have multiple empty entries in a row */
+   if (gen > 0)
+   prev = gen;
+   }
+   }
+
+   return 0;
+}
+
+int intel_engine_cs_mock_selftests(void)
+{
+   return intel_mmio_bases_check();
+}
-- 
2.16.2

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

[Intel-gfx] [PATCH v2 3/3] drm/i915: move gen8 irq shifts to intel_lrc.c

[Daniele Ceraolo Spurio]

The only usage outside the intel_lrc.c file is in the ringbuffer
init, but the irq mask calculated there is then overwritten for
all engines that have a non-zero shift, so we can drop it.

This change is not aimed at code saving but at removing from
intel_engines information that does not apply to all gens that have
the engine. When checking without the temporary WARN_ON, code size
is basically unchanged:

add/remove: 1/0 grow/shrink: 3/4 up/down: 70/-67 (3)
Function old new   delta
logical_ring_setup   315 343 +28
irq_shifts -  28 +28
intel_init_render_ring_buffer258 268 +10
reset_common_ring704 708  +4
intel_engine_init_cmd_parser10641058  -6
intel_engines_init_mmio 12641256  -8
intel_ring_default_vfuncs584 563 -21
intel_engines224 192 -32
Total: Before=1479719, After=1479722, chg +0.00%

Suggested-by: Michel Thierry 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 10 --
 drivers/gpu/drm/i915/intel_lrc.c| 22 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c |  4 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
 4 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a33171d82aee..dbfeff6c46a8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -92,7 +92,6 @@ struct engine_info {
u32 gen : 8;
u32 base : 24;
} mmio_bases[MAX_MMIO_BASES];
-   unsigned irq_shift;
 };
 
 static const struct engine_info intel_engines[] = {
@@ -104,7 +103,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 0, .base = RENDER_RING_BASE }
},
-   .irq_shift = GEN8_RCS_IRQ_SHIFT,
},
[BCS] = {
.hw_id = BCS_HW,
@@ -114,7 +112,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 6, .base = BLT_RING_BASE }
},
-   .irq_shift = GEN8_BCS_IRQ_SHIFT,
},
[VCS] = {
.hw_id = VCS_HW,
@@ -126,7 +123,6 @@ static const struct engine_info intel_engines[] = {
{ .gen = 6, .base = GEN6_BSD_RING_BASE },
{ .gen = 4, .base = BSD_RING_BASE }
},
-   .irq_shift = GEN8_VCS1_IRQ_SHIFT,
},
[VCS2] = {
.hw_id = VCS2_HW,
@@ -137,7 +133,6 @@ static const struct engine_info intel_engines[] = {
{ .gen = 11, .base = GEN11_BSD2_RING_BASE },
{ .gen = 8, .base = GEN8_BSD2_RING_BASE }
},
-   .irq_shift = GEN8_VCS2_IRQ_SHIFT,
},
[VCS3] = {
.hw_id = VCS3_HW,
@@ -147,7 +142,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD3_RING_BASE }
},
-   .irq_shift = 0, /* not used */
},
[VCS4] = {
.hw_id = VCS4_HW,
@@ -157,7 +151,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD4_RING_BASE }
},
-   .irq_shift = 0, /* not used */
},
[VECS] = {
.hw_id = VECS_HW,
@@ -168,7 +161,6 @@ static const struct engine_info intel_engines[] = {
{ .gen = 11, .base = GEN11_VEBOX_RING_BASE },
{ .gen = 7, .base = VEBOX_RING_BASE }
},
-   .irq_shift = GEN8_VECS_IRQ_SHIFT,
},
[VECS2] = {
.hw_id = VECS2_HW,
@@ -178,7 +170,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 11, .base = GEN11_VEBOX2_RING_BASE }
},
-   .irq_shift = 0, /* not used */
},
 };
 
@@ -298,7 +289,6 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
sizeof(engine->name));
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
-   engine->irq_shift = info->irq_shift;
engine->class = info->class;
engine->instance = info->instance;
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 999d5f2539d4..1bf8e16d7fa3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1573,6 

[Intel-gfx] [PATCH v2 1/3] drm/i915: store all mmio bases in intel_engines

[Daniele Ceraolo Spurio]

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.

v2: document that the list goes in reverse order, update starting gen
for render (Chris)

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 78 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
 2 files changed, 50 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..08711665061c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,17 @@ static const struct engine_class_info 
intel_engine_classes[] = {
},
 };
 
+#define MAX_MMIO_BASES 3
 struct engine_info {
unsigned int hw_id;
unsigned int uabi_id;
u8 class;
u8 instance;
-   u32 mmio_base;
+   /* mmio bases table *must* be sorted in reverse gen order */
+   struct engine_mmio_base {
+   u32 gen : 8;
+   u32 base : 24;
+   } mmio_bases[MAX_MMIO_BASES];
unsigned irq_shift;
 };
 
@@ -96,7 +101,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
.instance = 0,
-   .mmio_base = RENDER_RING_BASE,
+   .mmio_bases = {
+   { .gen = 0, .base = RENDER_RING_BASE }
+   },
.irq_shift = GEN8_RCS_IRQ_SHIFT,
},
[BCS] = {
@@ -104,7 +111,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
.instance = 0,
-   .mmio_base = BLT_RING_BASE,
+   .mmio_bases = {
+   { .gen = 6, .base = BLT_RING_BASE }
+   },
.irq_shift = GEN8_BCS_IRQ_SHIFT,
},
[VCS] = {
@@ -112,7 +121,11 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 0,
-   .mmio_base = GEN6_BSD_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD_RING_BASE },
+   { .gen = 6, .base = GEN6_BSD_RING_BASE },
+   { .gen = 4, .base = BSD_RING_BASE }
+   },
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
},
[VCS2] = {
@@ -120,7 +133,10 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 1,
-   .mmio_base = GEN8_BSD2_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD2_RING_BASE },
+   { .gen = 8, .base = GEN8_BSD2_RING_BASE }
+   },
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
},
[VCS3] = {
@@ -128,7 +144,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 2,
-   .mmio_base = GEN11_BSD3_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD3_RING_BASE }
+   },
.irq_shift = 0, /* not used */
},
[VCS4] = {
@@ -136,7 +154,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 3,
-   .mmio_base = GEN11_BSD4_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD4_RING_BASE }
+   },
.irq_shift = 0, /* not used */
},
[VECS] = {
@@ -144,7 +164,10 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
.instance = 0,
-   .mmio_base = VEBOX_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_VEBOX_RING_BASE },
+   { .gen = 7, .base = VEBOX_RING_BASE }
+   },
.irq_shift = GEN8_VECS_IRQ_SHIFT,
},
[VECS2] = {
@@ -152,7 +175,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = 

[Intel-gfx] [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

[Lyude Paul]

While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.

V2:
 - Remove accidental duplicate modeset_retry_work in intel_connector

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c  | 23 +--
 drivers/gpu/drm/i915/intel_dp.c   | 10 --
 drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
 4 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f424fff477f6..85d5af4e4f5b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15394,16 +15394,35 @@ static void intel_hpd_poll_fini(struct drm_device 
*dev)
 {
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+   struct work_struct *work;
 
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, _iter);
for_each_intel_connector_iter(connector, _iter) {
-   if (connector->modeset_retry_work.func)
-   cancel_work_sync(>modeset_retry_work);
if (connector->hdcp_shim) {
cancel_delayed_work_sync(>hdcp_check_work);
cancel_work_sync(>hdcp_prop_work);
}
+
+   if (connector->base.connector_type !=
+   DRM_MODE_CONNECTOR_DisplayPort)
+   continue;
+
+   if (connector->mst_port) {
+   work = >mst_port->modeset_retry_work;
+   } else {
+   struct intel_encoder *intel_encoder =
+   connector->encoder;
+   struct intel_dp *intel_dp;
+
+   if (!intel_encoder)
+   continue;
+
+   intel_dp = enc_to_intel_dp(_encoder->base);
+   work = _dp->modeset_retry_work;
+   }
+
+   cancel_work_sync(work);
}
drm_connector_list_iter_end(_iter);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4dd1b2287dd6..5abf0c95725a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 
 static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
 {
-   struct intel_connector *intel_connector;
-   struct drm_connector *connector;
+   struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+   struct drm_connector *connector = _dp->attached_connector->base;
 
-   intel_connector = container_of(work, typeof(*intel_connector),
-  modeset_retry_work);
-   connector = _connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
  connector->name);
 
@@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
int type;
 
/* Initialize the work for modeset in case of link train failure */
-   INIT_WORK(_connector->modeset_retry_work,
+   INIT_WORK(_dp->modeset_retry_work,
  intel_dp_modeset_retry_work_fn);
 
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 
intel_dp->link_rate,
 
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start 
modeset */
-   schedule_work(_connector->modeset_retry_work);
+   schedule_work(_dp->modeset_retry_work);
} else {
DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
= %d, lane count = %d",
  intel_connector->base.base.id,
diff --git 

[Intel-gfx] [PATCH 3/6] drm/i915: Only use one link bw config for MST topologies

[Lyude Paul]

When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if the sink changes it's RX caps after we've already set up
an MST link and we attempt to add or remove another sink from the
topology, we could put ourselves into an invalid state where we've tried
to configure different sinks on the same MST topology with different
link rates. We could also run into this situation if a sink reports a
higher link rate after suspend, usually from us having trained it with a
fallback bw configuration before suspending.

So: "lock" the bw config by only using the max DP link rate/lane count
on the first modeset for an MST topology. For every modeset following,
we instead use the last configured link bw for this topology. We only
unlock the bw config when we've detected a new MST sink.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 11 +--
 drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++---
 drivers/gpu/drm/i915/intel_drv.h|  6 ++
 3 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5abf0c95725a..5645a194de92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
 static void
 intel_dp_configure_mst(struct intel_dp *intel_dp)
 {
+   bool was_mst;
+
if (!i915_modparams.enable_dp_mst)
return;
 
if (!intel_dp->can_mst)
return;
 
+   was_mst = intel_dp->is_mst;
intel_dp->is_mst = intel_dp_can_mst(intel_dp);
 
-   if (intel_dp->is_mst)
+   if (intel_dp->is_mst) {
DRM_DEBUG_KMS("Sink is MST capable\n");
-   else
+
+   if (!was_mst)
+   intel_dp->mst_bw_locked = false;
+   } else {
DRM_DEBUG_KMS("Sink is not MST capable\n");
+   }
 
drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
intel_dp->is_mst);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..c0553456b18e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
-   int lane_count, slots;
+   int lane_count, link_rate, slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
@@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
  bpp);
}
/*
-* for MST we always configure max link bw - the spec doesn't
-* seem to suggest we should do otherwise.
+* for MST we always configure max link bw if we don't know better -
+* the spec doesn't seem to suggest we should do otherwise. But,
+* ensure it always stays consistent with the rest of this hub's
+* state.
 */
-   lane_count = intel_dp_max_lane_count(intel_dp);
+   if (intel_dp->mst_bw_locked) {
+   lane_count = intel_dp->lane_count;
+   link_rate = intel_dp->link_rate;
+   } else {
+   lane_count = intel_dp_max_lane_count(intel_dp);
+   link_rate = intel_dp_max_link_rate(intel_dp);
+   }
 
pipe_config->lane_count = lane_count;
-
pipe_config->pipe_bpp = bpp;
-
-   pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
+   pipe_config->port_clock = link_rate;
 
if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
@@ -221,6 +227,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
connector->encoder = encoder;
intel_mst->connector = connector;
 
+   intel_dp->mst_bw_locked = true;
+
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3700fcfddb1f..e5d3ef6754a5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1110,6 +1110,12 @@ struct intel_dp {
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
+   /* Set when we've already decided 

[Intel-gfx] [PATCH 5/6] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()

[Lyude Paul]

Retraining MST is rather difficult. In order to do it properly while
guaranteeing that we'll never run into a spot where we commit a
physically impossible configuration, we have to do a lot of checks on
atomic commits which affect MST topologies. All of this work is going to
need to be repeated for every driver at some point, so let's save
ourselves some trouble and just implement these atomic checks as
a single helper.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 223 ++
 include/drm/drm_dp_mst_helper.h   |   2 +
 2 files changed, 225 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d6604500b29..c4a91b1ba61b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2167,6 +2167,229 @@ int drm_dp_mst_topology_mgr_lower_link_rate(struct 
drm_dp_mst_topology_mgr *mgr,
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_lower_link_rate);
 
+static bool drm_atomic_dp_mst_state_only_disables_mstbs(struct 
drm_atomic_state *state,
+   struct 
drm_dp_mst_topology_mgr *mgr,
+   struct 
drm_dp_mst_branch *mstb)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_state_only_disables_mstbs(
+   state, mgr, rmstb);
+   drm_dp_put_mst_branch_device(rmstb);
+   if (!ret)
+   return false;
+   }
+
+   connector = port->connector;
+   if (!connector)
+   continue;
+
+   conn_state = drm_atomic_get_new_connector_state(
+   state, connector);
+   if (!conn_state)
+   continue;
+
+   crtc = conn_state->crtc;
+   if (!crtc)
+   continue;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   continue;
+
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   return true;
+}
+
+static int drm_atomic_dp_mst_all_mstbs_disabled(struct drm_atomic_state *state,
+   struct drm_dp_mst_topology_mgr 
*mgr,
+   struct drm_dp_mst_branch *mstb)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_all_mstbs_disabled(
+   state, mgr, rmstb);
+   drm_dp_put_mst_branch_device(rmstb);
+   if (ret <= 0)
+   return ret;
+   }
+
+   connector = port->connector;
+   if (!connector)
+   continue;
+
+   conn_state = drm_atomic_get_connector_state(
+   state, connector);
+   if (IS_ERR(conn_state))
+   return PTR_ERR(conn_state);
+
+   if (conn_state->crtc)
+   return false;
+   }
+
+   /* No enabled CRTCs found */
+   return true;
+}
+
+static int drm_atomic_dp_mst_retrain_mstb(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ bool full_modeset)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int ret;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   ret = drm_atomic_dp_mst_retrain_mstb(
+   state, mgr, rmstb, full_modeset);
+   drm_dp_put_mst_branch_device(rmstb);
+ 

[Intel-gfx] [PATCH 4/6] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()

[Lyude Paul]

Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps that must be taken in order to properly retrain the
entire topology under a lower link rate. Since the VCID allocations for
each mstb is determined based off the link rate for the top of the
topology, we also have to recalculate all of the VCID allocations for
the downstream ports as well to ensure that we still have enough link
bandwidth to drive each mstb.

Additionally, since we have multiple downstream connectors per port,
setting the link status of the parent mstb's port to bad isn't enough:
all of the downstream mstb ports have to have their link status set to
bad.

This basically follows the same paradigm that our DP link status logic
in DRM does, in that we simply tell userspace that all of the mstb ports
need retraining and additionally applying the new lower bandwidth
constraints to all of the atomic commits on the topology that follow.

Since the work of figuring out which connectors live downstream on an
MST topology and updating their link status is something that any driver
supporting MST is going to need to do in order to retrain MST links
properly, we add the drm_dp_mst_topology_mgr_lower_link_rate() helper
which simply recalculates the pbn_div for a given mst topology, then
marks the link status of all connectors living in that topology as bad.
We'll make use of it in i915 later in this series.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 73 ++-
 include/drm/drm_dp_mst_helper.h   |  3 ++
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6fac4129e6a2..0d6604500b29 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2076,7 +2076,7 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
 {
switch (dp_link_bw) {
default:
-   DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: 
%d)\n",
+   DRM_DEBUG_KMS("invalid link bandwidth: %x (link count: %d)\n",
  dp_link_bw, dp_link_count);
return false;
 
@@ -2096,6 +2096,77 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
return true;
 }
 
+static void drm_dp_set_mstb_link_status(struct drm_dp_mst_branch *mstb,
+   enum drm_link_status status)
+{
+   struct drm_dp_mst_branch *rmstb;
+   struct drm_dp_mst_port *port;
+
+   list_for_each_entry(port, >ports, next) {
+   rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+   if (rmstb) {
+   drm_dp_set_mstb_link_status(rmstb, status);
+   drm_dp_put_mst_branch_device(rmstb);
+   }
+
+   if (port->connector)
+   port->connector->state->link_status = status;
+   }
+}
+
+/**
+ * drm_dp_mst_topology_mgr_lower_link_rate() - Override the DP link bw/count
+ * for all connectors in a given MST topology
+ * @mgr: manager to set state for
+ * @dp_link_bw: The new DP link bandwidth
+ * @dp_link_count: The new DP link count
+ *
+ * This is called by the driver when it detects that the current DP link for
+ * the given topology manager is unstable, and needs to be retrained at a
+ * lower link rate.
+ *
+ * This takes care of updating the link status on all downstream connectors
+ * along with recalculating the VC payloads. The driver should send a hotplug
+ * event after calling this function to notify userspace of the link status
+ * change.
+ *
+ * RETURNS:
+ *
+ * True for success, or negative error code on failure.
+ */
+int drm_dp_mst_topology_mgr_lower_link_rate(struct drm_dp_mst_topology_mgr 
*mgr,
+   int dp_link_bw, int dp_link_count)
+{
+   struct drm_device *dev = mgr->dev;
+   struct drm_dp_mst_branch *mst_primary;
+   int new_pbn_div;
+   int ret = 0;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+
+   if (!drm_dp_get_vc_payload_bw(drm_dp_link_rate_to_bw_code(dp_link_bw),
+ dp_link_count, _pbn_div)) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   mst_primary = drm_dp_get_validated_mstb_ref(mgr, mgr->mst_primary);
+   if (!mst_primary)
+   goto out;
+
+   DRM_DEBUG_KMS("MST link failed to retrain, lowering pbn_div to %d\n",
+ new_pbn_div);
+   mgr->pbn_div = new_pbn_div;
+
+   drm_dp_set_mstb_link_status(mst_primary, 

[Intel-gfx] [PATCH 0/6] Implement proper MST fallback retraining in i915

[Lyude Paul]

This is the first version of my patch series to implement MST fallback
retraining in i915, along with improving the stability of i915's mst
retraining in general. Additionally, it also introduces helpers into DRM
to help with correctly handling MST fallback retraining so that other
drivers may also implement it. If your driver has a homegrown
implementation of this, you should convert it to these helpers to ensure
that the behavior of atomic commits and connector's link status
properties in the event of requiring retraining on an MST topology
remains consistent between DRM drivers.

Additionally, this lets me use the DisplayPort on my dock so I can
finally free up the thunderbolt 3 connector on it for more useful
things. At long last :).

Cc: Manasi Navare 
Cc: Ville Syrjälä 

Lyude Paul (6):
  drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT
  drm/i915: Move DP modeset retry work into intel_dp
  drm/i915: Only use one link bw config for MST topologies
  drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()
  drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()
  drm/i915: Implement proper fallback training for MST

 drivers/gpu/drm/drm_dp_mst_topology.c | 296 -
 drivers/gpu/drm/i915/intel_display.c  |  23 +-
 drivers/gpu/drm/i915/intel_dp.c   | 360 +++---
 drivers/gpu/drm/i915/intel_dp_link_training.c |   2 +-
 drivers/gpu/drm/i915/intel_dp_mst.c   |  64 +++--
 drivers/gpu/drm/i915/intel_drv.h  |  23 +-
 include/drm/drm_dp_mst_helper.h   |   5 +
 7 files changed, 662 insertions(+), 111 deletions(-)

-- 
2.14.3

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

[Intel-gfx] [PATCH 2/6] drm/i915: Move DP modeset retry work into intel_dp

[Lyude Paul]

While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c  | 23 +--
 drivers/gpu/drm/i915/intel_dp.c   | 10 --
 drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  9 ++---
 4 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f424fff477f6..85d5af4e4f5b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15394,16 +15394,35 @@ static void intel_hpd_poll_fini(struct drm_device 
*dev)
 {
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+   struct work_struct *work;
 
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, _iter);
for_each_intel_connector_iter(connector, _iter) {
-   if (connector->modeset_retry_work.func)
-   cancel_work_sync(>modeset_retry_work);
if (connector->hdcp_shim) {
cancel_delayed_work_sync(>hdcp_check_work);
cancel_work_sync(>hdcp_prop_work);
}
+
+   if (connector->base.connector_type !=
+   DRM_MODE_CONNECTOR_DisplayPort)
+   continue;
+
+   if (connector->mst_port) {
+   work = >mst_port->modeset_retry_work;
+   } else {
+   struct intel_encoder *intel_encoder =
+   connector->encoder;
+   struct intel_dp *intel_dp;
+
+   if (!intel_encoder)
+   continue;
+
+   intel_dp = enc_to_intel_dp(_encoder->base);
+   work = _dp->modeset_retry_work;
+   }
+
+   cancel_work_sync(work);
}
drm_connector_list_iter_end(_iter);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4dd1b2287dd6..5abf0c95725a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 
 static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
 {
-   struct intel_connector *intel_connector;
-   struct drm_connector *connector;
+   struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+   struct drm_connector *connector = _dp->attached_connector->base;
 
-   intel_connector = container_of(work, typeof(*intel_connector),
-  modeset_retry_work);
-   connector = _connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
  connector->name);
 
@@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
int type;
 
/* Initialize the work for modeset in case of link train failure */
-   INIT_WORK(_connector->modeset_retry_work,
+   INIT_WORK(_dp->modeset_retry_work,
  intel_dp_modeset_retry_work_fn);
 
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 
intel_dp->link_rate,
 
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start 
modeset */
-   schedule_work(_connector->modeset_retry_work);
+   schedule_work(_dp->modeset_retry_work);
} else {
DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
= %d, lane count = %d",
  intel_connector->base.base.id,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 

[Intel-gfx] [PATCH 6/6] drm/i915: Implement proper fallback training for MST

[Lyude Paul]

For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.

MST retraining is somewhat different then SST retraining. While it's
possible during the normal link retraining sequence for a hub to indicate
bad link status, it's also possible for a hub to only indicate this
status through ESI messages and it's possible for this to happen after
the initial link training succeeds. This can lead to a pattern that
looks like this:

- Train MST link
- Training completes successfully
- MST hub sets Channel EQ failed bit in ESI
- Retraining starts
- Retraining completes successfully
- MST hub sets Channel EQ failed bit in ESI again
- Rinse and repeat

In these situations, we need to be able to actually trigger fallback
link training from the ESI handler as well, along with using the ESI
handler during retraining to figure out whether or not our retraining
actually succeeded.

This gets a bit more complicated since we have to ensure that we don't
block the ESI handler at all while doing retraining. If we do, due to
DisplayPort's general issues with being sensitive to IRQ latency most
MST hubs will just stop responding to us if their interrupts aren't
handled in a timely manner.

So: move retraining into it's own seperate handler. Running in a
seperate handler allows us to avoid stalling the ESI during link
retraining, and we can have the ESI signal that the channel EQ bit was
cleared through a simple completion struct. Additionally, we take care
to stick as much of this into the SST retraining path as possible since
sharing is caring.

Signed-off-by: Lyude Paul 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 342 +++-
 drivers/gpu/drm/i915/intel_dp_mst.c |  42 -
 drivers/gpu/drm/i915/intel_drv.h|   8 +
 3 files changed, 302 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5645a194de92..7626652732b6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -45,6 +45,8 @@
 
 #define DP_DPRX_ESI_LEN 14
 
+#define DP_MST_RETRAIN_TIMEOUT (msecs_to_jiffies(100))
+
 /* Compliance test status bits  */
 #define INTEL_DP_RESOLUTION_SHIFT_MASK 0
 #define INTEL_DP_RESOLUTION_PREFERRED  (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
@@ -4224,6 +4226,118 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("Could not write test response to sink\n");
 }
 
+/* Get a mask of the CRTCs that are running on the given intel_dp struct. For
+ * MST, this returns a crtc mask containing all of the CRTCs driving
+ * downstream sinks, for SST it just returns a mask of the attached
+ * connector's CRTC.
+ */
+int
+intel_dp_get_crtc_mask(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct intel_connector *intel_connector;
+   struct drm_crtc *crtc;
+   int crtc_mask = 0;
+
+   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+
+   if (intel_dp->is_mst) {
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   for_each_intel_connector_iter(intel_connector, _iter) {
+   if (intel_connector->mst_port != intel_dp)
+   continue;
+
+   conn_state = intel_connector->base.state;
+   if (!conn_state->crtc)
+   continue;
+
+   crtc_mask |= drm_crtc_mask(conn_state->crtc);
+   }
+   drm_connector_list_iter_end(_iter);
+   } else {
+   connector = _dp->attached_connector->base;
+   crtc = connector->state->crtc;
+
+   if (crtc)
+   crtc_mask |= drm_crtc_mask(crtc);
+   }
+
+   return crtc_mask;
+}
+
+static bool
+intel_dp_needs_link_retrain(struct intel_dp *intel_dp,
+   const u8 esi[DP_DPRX_ESI_LEN])
+{
+   u8 buf[max(DP_LINK_STATUS_SIZE, DP_DPRX_ESI_LEN)];
+   const u8 *link_status = NULL;
+
+   if (intel_dp->is_mst) {
+   if (!intel_dp->active_mst_links)
+   return false;
+   if (intel_dp->mst_link_is_bad)
+   return false;
+
+   if (esi) {
+   link_status = [10];
+   } else {
+   /* We're not running from the ESI handler, so wait a
+* little bit to see if the ESI handler lets us know
+   

[Intel-gfx] [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

[Lyude Paul]

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9a4a51e79fa1..4dd1b2287dd6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -43,7 +43,6 @@
 #include 
 #include "i915_drv.h"
 
-#define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
 #define DP_DPRX_ESI_LEN 14
 
 /* Compliance test status bits  */
-- 
2.14.3

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

[Daniele Ceraolo Spurio]

On 08/03/18 13:00, Michal Wajdeczko wrote:

Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem.c|  2 ++
  drivers/gpu/drm/i915/intel_guc.h   |  6 ++
  drivers/gpu/drm/i915/intel_huc.h   |  6 ++
  drivers/gpu/drm/i915/intel_uc.c| 18 ++
  drivers/gpu/drm/i915/intel_uc.h|  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca5..49c81ae 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4892,6 +4892,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 */
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+
+   intel_uc_sanitize(i915);
  }
  
  int i915_gem_suspend(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..ec8569f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
  u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  
+static inline int intel_guc_sanitize(struct intel_guc *guc)

+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..b185850 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,10 @@ struct intel_huc {
  void intel_huc_init_early(struct intel_huc *huc);
  int intel_huc_auth(struct intel_huc *huc);
  
+static inline int intel_huc_sanitize(struct intel_huc *huc)

+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
  #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
  }
  
+void intel_uc_sanitize(struct drm_i915_private *i915)

+{
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   guc_disable_communication(guc);


If you want to do this here for CT buffers you need to call this before 
resetting the GPU otherwise GuC will already be reset and won't be able 
to unregister the buffers. We can also just wipe the shared memory where 
the CT buffer info is stored but that doesn't sound too clean, although 
we might have to add the code for it anyway if we want to support the 
(unlikely) case where GuC dies on some error.


Might also be interesting to release doorbells here to sync that state 
as well, but that's a task for a another time ;)


BTW, are you planning to call this in the i915_reset flow as well or is 
the plan to add another dedicated function?


Thanks,
Daniele


+
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+
+   __intel_uc_reset_hw(i915);
+}
+
  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
  void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
  int intel_uc_init_misc(struct drm_i915_private *dev_priv);
  void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
  int intel_uc_init_hw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
  }
  
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)

+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
  void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Sanitize uC

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Sanitize uC
URL   : https://patchwork.freedesktop.org/series/39634/
State : success

== Summary ==

Series 39634v1 drm/i915/uc: Sanitize uC
https://patchwork.freedesktop.org/api/1.0/series/39634/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:501s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:467s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:19  
time:524s

87ad36f3fa700da980f764c4e4184a38e1296560 drm-tip: 2018y-03m-08d-19h-40m-42s UTC 
integration manifest
c250a776a2f9 HAX: Enable GuC for CI
e27f9d79e311 drm/i915/uc: Sanitize uC together with GEM
3c79e5c3be57 drm/i915/uc: Sanitize uC options early

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

[Chris Wilson]

Quoting Michal Wajdeczko (2018-03-08 21:00:35)
> Instead of dancing around uC on reset/suspend/resume scenarios,
> explicitly sanitize uC when we sanitize GEM to force uC reload
> and start from known beginning.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Daniele Ceraolo Spurio 
> Cc: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Cc: Michel Thierry 

Lgtm,
Reviewed-by: Chris Wilson 

Second opinions are welcome.
> ---
>  drivers/gpu/drm/i915/i915_gem.c|  2 ++
>  drivers/gpu/drm/i915/intel_guc.h   |  6 ++
>  drivers/gpu/drm/i915/intel_huc.h   |  6 ++
>  drivers/gpu/drm/i915/intel_uc.c| 18 ++
>  drivers/gpu/drm/i915/intel_uc.h|  1 +
>  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
>  6 files changed, 39 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ab88ca5..49c81ae 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4892,6 +4892,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
>  */
> if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
> WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));

I think we can say that our reset works for gen3+ well enough to use
everywhere. (Certainly gen3/gen4 are no worse than gen5!)
Future task for the brave.
-Chris
___
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/uc: Sanitize uC options early

[Chris Wilson]

Quoting Michal Wajdeczko (2018-03-08 21:00:34)
> We are sanitizing uC related modparams together with other driver
> modparams in intel_sanitize_options called from i915_driver_init_hw,
> but this is too late for us as we will want to use USES_GUC/USES_HUC
> macros at earlier stage. Since our sanitizing does not require any
> MMIO access, we can do it in intel_uc_init_early right after we resolve
> firmware names.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Sagar Arun Kamble 
> Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915/uc: Sanitize uC options early

[Michal Wajdeczko]

We are sanitizing uC related modparams together with other driver
modparams in intel_sanitize_options called from i915_driver_init_hw,
but this is too late for us as we will want to use USES_GUC/USES_HUC
macros at earlier stage. Since our sanitizing does not require any
MMIO access, we can do it in intel_uc_init_early right after we resolve
firmware names.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 --
 drivers/gpu/drm/i915/intel_uc.c | 6 --
 drivers/gpu/drm/i915/intel_uc.h | 1 -
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d7c4de4..5ba6d6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1074,8 +1074,6 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
i915_modparams.enable_ppgtt);
DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915_modparams.enable_ppgtt);
 
-   intel_uc_sanitize_options(dev_priv);
-
intel_gvt_sanitize_options(dev_priv);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e5bf0d3..a45171c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -83,7 +83,7 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
 }
 
 /**
- * intel_uc_sanitize_options - sanitize uC related modparam options
+ * sanitize_options_early - sanitize uC related modparam options
  * @dev_priv: device private
  *
  * In case of "enable_guc" option this function will attempt to modify
@@ -99,7 +99,7 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
  * unless GuC is enabled on given platform and the driver is compiled with
  * debug config when this modparam will default to "enable(1..4)".
  */
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+static void sanitize_options_early(struct drm_i915_private *dev_priv)
 {
struct intel_uc_fw *guc_fw = _priv->guc.fw;
struct intel_uc_fw *huc_fw = _priv->huc.fw;
@@ -163,6 +163,8 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
 {
intel_guc_init_early(_priv->guc);
intel_huc_init_early(_priv->huc);
+
+   sanitize_options_early(dev_priv);
 }
 
 void intel_uc_init_fw(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index f76d51d..dce4813 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -28,7 +28,6 @@
 #include "intel_huc.h"
 #include "i915_params.h"
 
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
 void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
 void intel_uc_init_fw(struct drm_i915_private *dev_priv);
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

[Michal Wajdeczko]

Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_gem.c|  2 ++
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_huc.h   |  6 ++
 drivers/gpu/drm/i915/intel_uc.c| 18 ++
 drivers/gpu/drm/i915/intel_uc.h|  1 +
 drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
 6 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab88ca5..49c81ae 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4892,6 +4892,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 */
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+
+   intel_uc_sanitize(i915);
 }
 
 int i915_gem_suspend(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b9424ac..ec8569f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
 u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
 
+static inline int intel_guc_sanitize(struct intel_guc *guc)
+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 5d6e804..b185850 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -38,4 +38,10 @@ struct intel_huc {
 void intel_huc_init_early(struct intel_huc *huc);
 int intel_huc_auth(struct intel_huc *huc);
 
+static inline int intel_huc_sanitize(struct intel_huc *huc)
+{
+   intel_uc_fw_sanitize(>fw);
+   return 0;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a45171c..abd1f7b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
 }
 
+void intel_uc_sanitize(struct drm_i915_private *i915)
+{
+   struct intel_guc *guc = >guc;
+   struct intel_huc *huc = >huc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(i915));
+
+   guc_disable_communication(guc);
+
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+
+   __intel_uc_reset_hw(i915);
+}
+
 int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index dce4813..937e611 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -34,6 +34,7 @@
 void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
 int intel_uc_init_misc(struct drm_i915_private *dev_priv);
 void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
+void intel_uc_sanitize(struct drm_i915_private *dev_priv);
 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
 int intel_uc_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 
b/drivers/gpu/drm/i915/intel_uc_fw.h
index d5fd460..2601521 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct 
intel_uc_fw *uc_fw)
return uc_fw->path != NULL;
 }
 
+static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw)
+{
+   if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
+   uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
+}
+
 void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
   struct intel_uc_fw *uc_fw);
 int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
-- 
1.9.1

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

[Intel-gfx] [PATCH 0/3] drm/i915/uc: Sanitize uC

[Michal Wajdeczko]

Attempt to sanitize uC for better alignment with rest of GEM driver.

Michal Wajdeczko (3):
  drm/i915/uc: Sanitize uC options early
  drm/i915/uc: Sanitize uC together with GEM
  HAX: Enable GuC for CI

 drivers/gpu/drm/i915/i915_drv.c|  2 --
 drivers/gpu/drm/i915/i915_gem.c|  2 ++
 drivers/gpu/drm/i915/i915_params.h |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_huc.h   |  6 ++
 drivers/gpu/drm/i915/intel_uc.c| 26 --
 drivers/gpu/drm/i915/intel_uc.h|  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
 8 files changed, 46 insertions(+), 6 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 3/3] HAX: Enable GuC for CI

[Michal Wajdeczko]

v2: except running with HYPERVISOR

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index abd1f7b..cb77b0e 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
1.9.1

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

Re: [Intel-gfx] [patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue

[Andrew Morton]

On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula  
wrote:

> On Wed, 07 Mar 2018, a...@linux-foundation.org wrote:
> > From: Andrew Morton 
> > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union 
> > initializer issue
> >
> > gcc-4.4.4 has problems with initalizers of anon unions.
> >
> > drivers/gpu/drm/i915/intel_guc_log.c: In function 'guc_log_control':
> > drivers/gpu/drm/i915/intel_guc_log.c:64: error: unknown field 
> > 'logging_enabled' specified in initializer
> >
> > Work around this.
> 
> Thanks for the patch, pushed to drm-intel-next-queued.
> 
> That said, how long do we have to care about old compilers? I thought we
> were converging on at the very least GCC 4.5 being required.

Yes, I've seen some talk about that and it is about time for us to do
it.  I'm not sure what stage things are at though.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39614/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
fail   -> PASS   (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#105341
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +3
Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
pass   -> FAIL   (shard-apl) fdo#103167
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

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

shard-apltotal:3394 pass:1777 dwarn:2   dfail:0   fail:15  skip:1598 
time:12071s
shard-hswtotal:3467 pass:1773 dwarn:1   dfail:0   fail:1   skip:1691 
time:11960s
shard-snbtotal:3467 pass:1361 dwarn:3   dfail:0   fail:2   skip:2101 
time:7012s
Blacklisted hosts:
shard-kbltotal:3397 pass:1875 dwarn:16  dfail:2   fail:16  skip:1486 
time:9003s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915: Disable preemption and sleeping 
while using the punit sideband (rev2)
URL   : https://patchwork.freedesktop.org/series/39555/
State : success

== Summary ==

Series 39555v2 series starting with [01/10] drm/i915: Disable preemption and 
sleeping while using the punit sideband
https://patchwork.freedesktop.org/api/1.0/series/39555/revisions/2/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#103841

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:501s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:468s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:292s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:1   fail:0   skip:24  
time:467s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:594s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:523s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:498s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-cnl-drrs  total:288  pass:255  dwarn:3   dfail:0   fail:2   skip:19  
time:485s
fi-cnl-y3 failed to collect. IGT log at Patchwork_8277/fi-cnl-y3/run0.log

87ad36f3fa700da980f764c4e4184a38e1296560 drm-tip: 2018y-03m-08d-19h-40m-42s UTC 
integration manifest
86da0206b71d drm/i915: Move sandybride pcode access to intel_sideband.c
80f90fac4da3 drm/i915: Merge sandybridge_pcode_(read|write)
ec3612434469 drm/i915: Merge sbi read/write into a single accessor
ce521d082fb6 drm/i915: Separate sideband declarations to intel_sideband.h
2c8be91bb1d3 drm/i915: Replace pcu_lock with sb_lock
c07dbad89274 Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail 
v3"
a76499db62c2 drm/i915: Reduce RPS update frequency on Valleyview/Cherryview
219d9d8c740e drm/i915: Lift sideband locking for vlv_punit_(read|write)
4dcb1da3ab87 drm/i915: Lift acquiring the vlv punit magic to a common sb-get
0bd6e0467372 drm/i915: Disable preemption and sleeping while using the punit 
sideband

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Replace pcu_lock with sb_lock

[Chris Wilson]

We now have two locks for sideband access. The general one covering
sideband access across all generation, sb_lock, and a specific one
covering sideband access via the punit on vlv/chv. After lifting the
sb_lock around the punit into the callers, the pcu_lock is now redudant
and can be separated from its other use to regulate RPS (essentially
giving RPS a lock all of its own).

v2: Extract a couple of minor bug fixes.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  47 
 drivers/gpu/drm/i915/i915_drv.h |  10 +--
 drivers/gpu/drm/i915/i915_irq.c |   4 +-
 drivers/gpu/drm/i915/i915_sysfs.c   |  32 +++-
 drivers/gpu/drm/i915/intel_cdclk.c  |  28 ---
 drivers/gpu/drm/i915/intel_display.c|   6 --
 drivers/gpu/drm/i915/intel_hdcp.c   |   2 -
 drivers/gpu/drm/i915/intel_pm.c | 127 +++-
 drivers/gpu/drm/i915/intel_runtime_pm.c |   8 --
 drivers/gpu/drm/i915/intel_sideband.c   |   4 -
 10 files changed, 93 insertions(+), 175 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8e7820f94358..97053e0afe63 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1074,8 +1074,6 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
u32 rpmodectl, freq_sts;
 
-   mutex_lock(_priv->pcu_lock);
-
rpmodectl = I915_READ(GEN6_RP_CONTROL);
seq_printf(m, "Video Turbo Mode: %s\n",
   yesno(rpmodectl & GEN6_RP_MEDIA_TURBO));
@@ -1110,7 +1108,6 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m,
   "efficient (RPe) frequency: %d MHz\n",
   intel_gpu_freq(dev_priv, rps->efficient_freq));
-   mutex_unlock(_priv->pcu_lock);
} else if (INTEL_GEN(dev_priv) >= 6) {
u32 rp_state_limits;
u32 gt_perf_status;
@@ -1525,12 +1522,9 @@ static int gen6_drpc_info(struct seq_file *m)
gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
}
 
-   if (INTEL_GEN(dev_priv) <= 7) {
-   mutex_lock(_priv->pcu_lock);
+   if (INTEL_GEN(dev_priv) <= 7)
sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
   );
-   mutex_unlock(_priv->pcu_lock);
-   }
 
seq_printf(m, "RC1e Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
@@ -1801,17 +1795,10 @@ static int i915_ring_freq_table(struct seq_file *m, 
void *unused)
struct intel_rps *rps = _priv->gt_pm.rps;
unsigned int max_gpu_freq, min_gpu_freq;
int gpu_freq, ia_freq;
-   int ret;
 
if (!HAS_LLC(dev_priv))
return -ENODEV;
 
-   intel_runtime_pm_get(dev_priv);
-
-   ret = mutex_lock_interruptible(_priv->pcu_lock);
-   if (ret)
-   goto out;
-
min_gpu_freq = rps->min_freq;
max_gpu_freq = rps->max_freq;
if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
@@ -1822,6 +1809,7 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)
 
seq_puts(m, "GPU freq (MHz)\tEffective CPU freq (MHz)\tEffective Ring 
freq (MHz)\n");
 
+   intel_runtime_pm_get(dev_priv);
for (gpu_freq = min_gpu_freq; gpu_freq <= max_gpu_freq; gpu_freq++) {
ia_freq = gpu_freq;
sandybridge_pcode_read(dev_priv,
@@ -1835,12 +1823,9 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)
   ((ia_freq >> 0) & 0xff) * 100,
   ((ia_freq >> 8) & 0xff) * 100);
}
-
-   mutex_unlock(_priv->pcu_lock);
-
-out:
intel_runtime_pm_put(dev_priv);
-   return ret;
+
+   return 0;
 }
 
 static int i915_opregion(struct seq_file *m, void *unused)
@@ -4178,7 +4163,7 @@ i915_max_freq_set(void *data, u64 val)
 
DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val);
 
-   ret = mutex_lock_interruptible(_priv->pcu_lock);
+   ret = mutex_lock_interruptible(>lock);
if (ret)
return ret;
 
@@ -4191,8 +4176,8 @@ i915_max_freq_set(void *data, u64 val)
hw_min = rps->min_freq;
 
if (val < hw_min || val > hw_max || val < rps->min_freq_softlimit) {
-   mutex_unlock(_priv->pcu_lock);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto unlock;
}
 
rps->max_freq_softlimit = val;
@@ -4200,9 +4185,9 @@ i915_max_freq_set(void *data, u64 val)
if (intel_set_rps(dev_priv, val))
DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n");
 
-   mutex_unlock(_priv->pcu_lock);
-
-   return 0;

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency

[Chris Wilson]

Quoting Patchwork (2018-03-08 19:32:29)
> == Series Details ==
> 
> Series: series starting with [CI,1/2] drm/i915: Kick the rps worker when 
> changing the boost frequency
> URL   : https://patchwork.freedesktop.org/series/39607/
> State : success
> 
> == Summary ==
> 
>  Possible new issues:
> 
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
> fail   -> PASS   (shard-apl)
> 
>  Known issues:
> 
> Test gem_eio:
> Subgroup in-flight-contexts:
> pass   -> INCOMPLETE (shard-apl) fdo#105341 +1
> Test kms_flip:
> Subgroup flip-vs-expired-vblank:
> pass   -> FAIL   (shard-hsw) fdo#102887 +2
> Subgroup plain-flip-fb-recreate-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#100368
> Test kms_rotation_crc:
> Subgroup primary-rotation-180:
> fail   -> PASS   (shard-snb) fdo#103925
> Subgroup sprite-rotation-90-pos-100-0:
> fail   -> PASS   (shard-apl) fdo#105185 +3
> Test pm_lpsp:
> Subgroup screens-disabled:
> fail   -> PASS   (shard-hsw) fdo#104941

Much better. Thanks for the review, pushed and back to the main series.
-Chris
___
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 [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Kick the rps worker when 
changing the boost frequency
URL   : https://patchwork.freedesktop.org/series/39607/
State : success

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
fail   -> PASS   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887 +2
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Subgroup sprite-rotation-90-pos-100-0:
fail   -> PASS   (shard-apl) fdo#105185 +3
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3308 pass:1739 dwarn:1   dfail:0   fail:9   skip:1556 
time:11399s
shard-hswtotal:3467 pass:1769 dwarn:1   dfail:0   fail:5   skip:1691 
time:11820s
shard-snbtotal:3380 pass:1325 dwarn:2   dfail:0   fail:1   skip:2051 
time:6805s
Blacklisted hosts:
shard-kbltotal:3308 pass:1829 dwarn:28  dfail:2   fail:9   skip:1438 
time:8525s

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

[Matt Roper]

On Thu, Mar 08, 2018 at 06:55:34PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2018-03-08 18:48:51)
> > Quoting Matt Roper (2018-03-08 18:22:06)
> > >  * Option 2:  Allow priority offset to be set in a much larger range
> > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]).  This allows cgroups to have
> > >effective priority ranges that don't overlap.  cgroup ranges can also
> > >be intentionally set above I915_PRIORITY_DISPLAY to allow us to
> > >define classes of applications whose work is more important than
> > >maintaining a stable framerate on the display.  We'd also probably
> > >need to shift the kernel idle context down to something like INT_MIN
> > >instead of using -1024.
> > 
> > INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.)
> > 
> > Something to bear in mind is that I want to reserve the low 8 bits of
> > ctx->priority for internal use (heuristic adjustments by the scheduler).
> > Can shrink that to say 3 bits in the current scheme.
> > 
> > 3bits for internal adjustment
> > 20bits for user priority.
> > 8bits for cgroup offset.
> > signbit.
> > 
> > Nothing prohibits us from moving to 64b if required. But 32b should be
> > enough range for plenty of clients and cgroups, imo. Reducing cgroup
> > offset to 6 bits would be nice :)
> 
> Forgot to comment on the policy decision of I915_PRIORITY_DISPLAY.
> It's naughty that it's a magic constant that isn't exposed to the
> sysadmin, so I would still set it to the maximum priority possible under
> the extended scheme (i.e. INT_MAX), but allow for it to be adjusted.
> I915_SETPARAM *shivers* Maybe that's a topic for cgroup as well if we can
> associate the pageflip with a process and find its interactivity settings.
> 
> Can I expose just about any random policy decision through cgroup?
> -Chris

If the policy applies to a cgroup of processes, then we can deal with
pretty much any kind of policy as long as we stick to the driver ioctl
approach in this series.  E.g., we could add a cgroup setting "eligible
for display boost" so that only specific processes are eligible for a
display boost.

If we want to control a single overall system value (e.g., "set the
display boost fixed value") we could technically do that by having such
parameters set on the v2 hierarchy's root cgroup, but that seems a bit
counterintuitive and I'm not sure if there's a benefit to doing so.
Using a more general interface like I915_SETPARAM or sysfs or something
seems more appropriate in that case.


Matt

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Rodrigo Vivi]

On Thu, Mar 08, 2018 at 10:07:05AM -0800, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote:
> > Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran:
> > >
> > >
> > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
> > >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> > >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
> >  Similar to enable_fbc, enable_psr was ignored at runtime if it was
> >  changed. The easiest fix is to pretend enable_psr is ignored at
> >  configure time, and never activate it for !enable_psr, so both cases
> >  are handled without modesets.
> > >>> What about cases where psr_flush() is not called and consequently the
> > >>> module parameter is not checked? With HW tracking, PSR is
> > >>> enabled/disabled during modeset and the hardware is expected to exit and
> > >>> activate PSR without driver intervention.
> > >> It looks like intel_frontbuffer_flush always calls intel_psr_flush,
> > >> so we at least get a PSR toggle after every atomic commit?
> > > I have a patch to remove flush() from legacy_cursor_update(). We end up
> > > with an inconsistent behavior when that patch gets merged,
> > > cursor moves -> trigger psr exit but don't read module parameter
> > > commits -> trigger psr exit but read module parameter
> > Legacy cursor updates are special, I don't mind them not changing PSR.
> > > Eventually, when we get to removing flush() from commits, then this
> > > patch won't really be useful. And tests disabling/enabling PSR at
> > > runtime will probably fail.
> > Could we transition to debugfs for changing it at runtime?
> 
> That does sound like a better idea.

+1

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Remove support for legacy debugfs crc interface (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove support for legacy debugfs crc interface (rev2)
URL   : https://patchwork.freedesktop.org/series/33053/
State : warning

== Summary ==

Series 33053v2 drm/i915: Remove support for legacy debugfs crc interface
https://patchwork.freedesktop.org/api/1.0/series/33053/revisions/2/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-bxt-dsi)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cfl-8700k)
pass   -> SKIP   (fi-cfl-s2)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-glk-1)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7567u)
pass   -> SKIP   (fi-kbl-r)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6600u)
pass   -> SKIP   (fi-skl-6700hq)
pass   -> SKIP   (fi-skl-6700k2)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-guc)
pass   -> SKIP   (fi-snb-2600)
Subgroup bad-nb-words-3:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-bxt-dsi)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cfl-8700k)
pass   -> SKIP   (fi-cfl-s2)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-glk-1)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7567u)
pass   -> SKIP   (fi-kbl-r)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6600u)
pass   -> SKIP   (fi-skl-6700hq)
pass   -> SKIP   (fi-skl-6700k2)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-guc)
pass   -> SKIP   (fi-snb-2600)
Subgroup bad-pipe:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-bxt-dsi)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-cfl-8700k)
pass   -> SKIP   (fi-cfl-s2)
pass   -> SKIP   (fi-cnl-y3)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-glk-1)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7567u)
pass   -> SKIP   (fi-kbl-r)

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling

[Patchwork]

== Series Details ==

Series: drm/i915: Remove the impedance mismatch around 
intel_engine_enable_signaling
URL   : https://patchwork.freedesktop.org/series/39605/
State : success

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
fail   -> PASS   (shard-apl)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-top-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +4
Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

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

shard-apltotal:3467 pass:1824 dwarn:1   dfail:0   fail:9   skip:1632 
time:12318s
shard-hswtotal:3448 pass:1761 dwarn:1   dfail:0   fail:1   skip:1683 
time:11697s
shard-snbtotal:3467 pass:1361 dwarn:3   dfail:0   fail:2   skip:2101 
time:7033s
Blacklisted hosts:
shard-kbltotal:3381 pass:1871 dwarn:27  dfail:2   fail:9   skip:1471 
time:9014s

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

[Chris Wilson]

Quoting Chris Wilson (2018-03-08 18:48:51)
> Quoting Matt Roper (2018-03-08 18:22:06)
> >  * Option 2:  Allow priority offset to be set in a much larger range
> >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]).  This allows cgroups to have
> >effective priority ranges that don't overlap.  cgroup ranges can also
> >be intentionally set above I915_PRIORITY_DISPLAY to allow us to
> >define classes of applications whose work is more important than
> >maintaining a stable framerate on the display.  We'd also probably
> >need to shift the kernel idle context down to something like INT_MIN
> >instead of using -1024.
> 
> INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.)
> 
> Something to bear in mind is that I want to reserve the low 8 bits of
> ctx->priority for internal use (heuristic adjustments by the scheduler).
> Can shrink that to say 3 bits in the current scheme.
> 
> 3bits for internal adjustment
> 20bits for user priority.
> 8bits for cgroup offset.
> signbit.
> 
> Nothing prohibits us from moving to 64b if required. But 32b should be
> enough range for plenty of clients and cgroups, imo. Reducing cgroup
> offset to 6 bits would be nice :)

Forgot to comment on the policy decision of I915_PRIORITY_DISPLAY.
It's naughty that it's a magic constant that isn't exposed to the
sysadmin, so I would still set it to the maximum priority possible under
the extended scheme (i.e. INT_MAX), but allow for it to be adjusted.
I915_SETPARAM *shivers* Maybe that's a topic for cgroup as well if we can
associate the pageflip with a process and find its interactivity settings.

Can I expose just about any random policy decision through cgroup?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

[Chris Wilson]

Quoting Matt Roper (2018-03-08 18:22:06)
> On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-03-08 11:32:04)
> > > Quoting Matt Roper (2018-03-06 23:46:59)
> > > > There are cases where a system integrator may wish to raise/lower the
> > > > priority of GPU workloads being submitted by specific OS process(es),
> > > > independently of how the software self-classifies its own priority.
> > > > Exposing "priority offset" as an i915-specific cgroup parameter will
> > > > enable such system-level configuration.
> > > > 
> > > > Normally GPU contexts start with a priority value of 0
> > > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from
> > > > there via other mechanisms.  We'd like to provide a system-level input
> > > > to the priority decision that will be taken into consideration, even
> > > > when userspace later attempts to set an absolute priority value via
> > > > I915_CONTEXT_PARAM_PRIORITY.  The priority offset introduced here
> > > > provides a base value that will always be added to (or subtracted from)
> > > > the software's self-assigned priority value.
> > > > 
> > > > This patch makes priority offset a cgroup-specific value; contexts will
> > > > be created with a priority offset based on the cgroup membership of the
> > > > process creating the context at the time the context is created.  Note
> > > > that priority offset is assigned at context creation time; migrating a
> > > > process to a different cgroup or changing the offset associated with a
> > > > cgroup will only affect new context creation and will not alter the
> > > > behavior of existing contexts previously created by the process.
> > > > 
> > > > v2:
> > > >  - Rebase onto new cgroup_priv API
> > > >  - Use current instead of drm_file->pid to determine which process to
> > > >lookup priority for. (Chris)
> > > >  - Don't forget to subtract priority offset in context_getparam ioctl to
> > > >make it match setparam behavior. (Chris)
> > > > 
> > > > Signed-off-by: Matt Roper 
> > > 
> > > For ctx->priority/ctx->priority_offset
> > > Reviewed-by: Chris Wilson 
> > 
> > As a reminder, we do have the question of how to bound ctx->priority +
> > ctx->priority_offset. Currently, outside of the user range is privileged
> > space reserved for the kernel (both above and below). Now we can move
> > those even further to accommodate multiple non-overlapping cgroups.
> 
> Yep, I mentioned this as an open question in the series coverletter.
> 
> My understanding is that today we limit userspace-assigned priorities to
> [1023,1023] and that the kernel can use the userspace range plus -1024
> (for the kernel idle context), 1024 (for boosting contexts the display
> is waiting on), and INT_MAX (for the preempt context).  Are there any
> other special values we use today that I'm overlooking?
> 
> I think we have the following options with how to proceed:
> 
>  * Option 1:  Silently limit (priority+priority offset) to the existing
>[-1023,1023] range.  That means that if, for example, a user context
>had a priority offset of 600 and tried to manually boost its context
>priority to 600, it would simply be treated as a 1023 for scheduling
>purposes.  This approach is simple, but doesn't allow us to force
>contexts in different cgroups into non-overlapping priority ranges
>(i.e., lowest possible priority in one cgroup is still higher than
>the highest possible priority in another cgroup).  It also isn't
>possible to define a class of applications as "more important than
>display" via cgroup, which I think might be useful in some cases.

Agreed, non-overlapping seems to be a useful property (apply the usual
disclaimer for the rudimentary scheduler).

>  * Option 2:  Allow priority offset to be set in a much larger range
>(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]).  This allows cgroups to have
>effective priority ranges that don't overlap.  cgroup ranges can also
>be intentionally set above I915_PRIORITY_DISPLAY to allow us to
>define classes of applications whose work is more important than
>maintaining a stable framerate on the display.  We'd also probably
>need to shift the kernel idle context down to something like INT_MIN
>instead of using -1024.

INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.)

Something to bear in mind is that I want to reserve the low 8 bits of
ctx->priority for internal use (heuristic adjustments by the scheduler).
Can shrink that to say 3 bits in the current scheme.

3bits for internal adjustment
20bits for user priority.
8bits for cgroup offset.
signbit.

Nothing prohibits us from moving to 64b if required. But 32b should be
enough range for plenty of clients and cgroups, imo. Reducing cgroup
offset to 6 bits would be nice :)

>  * Option 3: No limits, leave behavior as it stands now in this patch
>series (unrestricted 

Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

[Daniele Ceraolo Spurio]

On 08/03/18 01:31, Tvrtko Ursulin wrote:


On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote:

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.

Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_engine_cs.c  | 77 
+

  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
  2 files changed, 49 insertions(+), 29 deletions(-)

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

index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info 
intel_engine_classes[] = {

  },
  };
+#define MAX_MMIO_BASES 3
  struct engine_info {
  unsigned int hw_id;
  unsigned int uabi_id;
  u8 class;
  u8 instance;
-    u32 mmio_base;
+    struct engine_mmio_base {
+    u32 gen : 8;
+    u32 base : 24;
+    } mmio_bases[MAX_MMIO_BASES];
  unsigned irq_shift;
  };


It's not bad, but I am just wondering if it is too complicated versus 
simply duplicating the tables.


Duplicated tables would certainly be much less code and complexity, but 
what about the size of pure data?


In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * 
sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times 
NUM_ENGINES equals 240 bytes for intel_engines[] array with this scheme.




we remove a u32 (the old mmio base) so we only grow 8 per engine, but 
the compiler rounds up to a multiple of u32 so 28 per engine, for a 
total of 224.



Separate tables per gens would be:

sizeof(struct engine_info) is 18 bytes.

For < gen6 we'd need 3 engines * 18 = 54
< gen11 = 5 engines * 18 = 90
 >= gen11 = 8 engines * 18 = 144

54 + 90 + 144 = 288 bytes

So a little bit bigger. Hm. Plus we would need to refactor so 
intel_engines[] is not indexed by engine->id but is contiguous array 
with engine->id in the elements. Code to lookup the compact array should 
be simpler than combined new code from this patch, especially if you add 
the test as Chris suggested. So separate engine info arrays would win I 
think overall - when considering size of text + size of data + size of 
source code.




Not sure. I would exclude the selftest, which is usually not compiled 
for released kernels, which leads to:


add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93)
Function old new   delta
intel_engines160 224 +64
__func__   13891   13910 +19
intel_engines_init_mmio 12471264 +17
intel_init_bsd_ring_buffer   142 135  -7
Total: Before=1479626, After=1479719, chg +0.01%

Total growth is 93, which is less then your estimation for the growth 
introduced by replicating the table.


But on the other hand your solution might be more future proof. So I 
don't know. Use the crystal ball to decide? :)




I think we should expect that the total engine count could grow with 
future gens. In this case to me adding a new entry to a unified table 
seems much cleaner (and uses less data) than adding a completely new 
table each time.


Daniele


Regards,

Tvrtko



@@ -96,7 +100,9 @@ static const struct engine_info intel_engines[] = {
  .uabi_id = I915_EXEC_RENDER,
  .class = RENDER_CLASS,
  .instance = 0,
-    .mmio_base = RENDER_RING_BASE,
+    .mmio_bases = {
+    { .gen = 1, .base = RENDER_RING_BASE }
+    },
  .irq_shift = GEN8_RCS_IRQ_SHIFT,
  },
  [BCS] = {
@@ -104,7 +110,9 @@ static const struct engine_info intel_engines[] = {
  .uabi_id = I915_EXEC_BLT,
  .class = COPY_ENGINE_CLASS,
  .instance = 0,
-    .mmio_base = BLT_RING_BASE,
+    .mmio_bases = {
+    { .gen = 6, .base = BLT_RING_BASE }
+    },
  .irq_shift = GEN8_BCS_IRQ_SHIFT,
  },
  [VCS] = {
@@ -112,7 +120,11 @@ static const struct engine_info intel_engines[] = {
  .uabi_id = I915_EXEC_BSD,
  .class = VIDEO_DECODE_CLASS,
  .instance = 0,
-    .mmio_base = GEN6_BSD_RING_BASE,
+    .mmio_bases = {
+    { .gen = 11, .base = GEN11_BSD_RING_BASE },
+    { .gen = 6, .base = GEN6_BSD_RING_BASE },
+    { .gen = 4, .base = BSD_RING_BASE }
+    },
  .irq_shift = GEN8_VCS1_IRQ_SHIFT,
  },
  [VCS2] = {
@@ -120,7 +132,10 @@ static const struct engine_info intel_engines[] = {
  

[Intel-gfx] [PATCH] drm/i915: Remove support for legacy debugfs crc interface

[Maarten Lankhorst]

This interface is deprecated, and has been replaced by the upstream
drm crc interface.

Signed-off-by: Maarten Lankhorst 
Cc: Tomi Sarvela 
Cc: Petri Latvala 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Acked-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |  11 +-
 drivers/gpu/drm/i915/i915_irq.c   |  79 ++
 drivers/gpu/drm/i915/intel_drv.h  |   2 -
 drivers/gpu/drm/i915/intel_pipe_crc.c | 446 --
 5 files changed, 24 insertions(+), 521 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 89f7ff2c652e..8f0570def4c8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4771,7 +4771,6 @@ static const struct i915_debugfs_files {
{"i915_gpu_info", _gpu_info_fops},
 #endif
{"i915_next_seqno", _next_seqno_fops},
-   {"i915_display_crc_ctl", _display_crc_ctl_fops},
{"i915_pri_wm_latency", _pri_wm_latency_fops},
{"i915_spr_wm_latency", _spr_wm_latency_fops},
{"i915_cur_wm_latency", _cur_wm_latency_fops},
@@ -4789,7 +4788,7 @@ int i915_debugfs_register(struct drm_i915_private 
*dev_priv)
 {
struct drm_minor *minor = dev_priv->drm.primary;
struct dentry *ent;
-   int ret, i;
+   int i;
 
ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
  minor->debugfs_root, to_i915(minor->dev),
@@ -4797,10 +4796,6 @@ int i915_debugfs_register(struct drm_i915_private 
*dev_priv)
if (!ent)
return -ENOMEM;
 
-   ret = intel_pipe_crc_create(minor);
-   if (ret)
-   return ret;
-
for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
ent = debugfs_create_file(i915_debugfs_files[i].name,
  S_IRUGO | S_IWUSR,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6e740f6fe33f..0a51eae8ce27 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1525,20 +1525,11 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_MAX,
 };
 
-struct intel_pipe_crc_entry {
-   uint32_t frame;
-   uint32_t crc[5];
-};
-
 #define INTEL_PIPE_CRC_ENTRIES_NR  128
 struct intel_pipe_crc {
spinlock_t lock;
-   bool opened;/* exclusive access to the result file */
-   struct intel_pipe_crc_entry *entries;
-   enum intel_pipe_crc_source source;
-   int head, tail;
-   wait_queue_head_t wq;
int skipped;
+   enum intel_pipe_crc_source source;
 };
 
 struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index babf81cf668b..26c1014eb1f7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1620,69 +1620,34 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
 uint32_t crc4)
 {
struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[pipe];
-   struct intel_pipe_crc_entry *entry;
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
-   struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
-   int head, tail;
 
spin_lock(_crc->lock);
-   if (pipe_crc->source && !crtc->base.crc.opened) {
-   if (!pipe_crc->entries) {
-   spin_unlock(_crc->lock);
-   DRM_DEBUG_KMS("spurious interrupt\n");
-   return;
-   }
-
-   head = pipe_crc->head;
-   tail = pipe_crc->tail;
-
-   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
-   spin_unlock(_crc->lock);
-   DRM_ERROR("CRC buffer overflowing\n");
-   return;
-   }
-
-   entry = _crc->entries[head];
-
-   entry->frame = driver->get_vblank_counter(_priv->drm, pipe);
-   entry->crc[0] = crc0;
-   entry->crc[1] = crc1;
-   entry->crc[2] = crc2;
-   entry->crc[3] = crc3;
-   entry->crc[4] = crc4;
-
-   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
-   pipe_crc->head = head;
-
-   spin_unlock(_crc->lock);
-
-   wake_up_interruptible(_crc->wq);
-   } else {
-   /*
-* For some not yet identified reason, the first CRC is
-* bonkers. So let's just wait for the next vblank and read
-* out the buggy result.
-*
-* On GEN8+ sometimes the second CRC is bonkers as well, so
-   

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

[Matt Roper]

On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2018-03-08 11:32:04)
> > Quoting Matt Roper (2018-03-06 23:46:59)
> > > There are cases where a system integrator may wish to raise/lower the
> > > priority of GPU workloads being submitted by specific OS process(es),
> > > independently of how the software self-classifies its own priority.
> > > Exposing "priority offset" as an i915-specific cgroup parameter will
> > > enable such system-level configuration.
> > > 
> > > Normally GPU contexts start with a priority value of 0
> > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from
> > > there via other mechanisms.  We'd like to provide a system-level input
> > > to the priority decision that will be taken into consideration, even
> > > when userspace later attempts to set an absolute priority value via
> > > I915_CONTEXT_PARAM_PRIORITY.  The priority offset introduced here
> > > provides a base value that will always be added to (or subtracted from)
> > > the software's self-assigned priority value.
> > > 
> > > This patch makes priority offset a cgroup-specific value; contexts will
> > > be created with a priority offset based on the cgroup membership of the
> > > process creating the context at the time the context is created.  Note
> > > that priority offset is assigned at context creation time; migrating a
> > > process to a different cgroup or changing the offset associated with a
> > > cgroup will only affect new context creation and will not alter the
> > > behavior of existing contexts previously created by the process.
> > > 
> > > v2:
> > >  - Rebase onto new cgroup_priv API
> > >  - Use current instead of drm_file->pid to determine which process to
> > >lookup priority for. (Chris)
> > >  - Don't forget to subtract priority offset in context_getparam ioctl to
> > >make it match setparam behavior. (Chris)
> > > 
> > > Signed-off-by: Matt Roper 
> > 
> > For ctx->priority/ctx->priority_offset
> > Reviewed-by: Chris Wilson 
> 
> As a reminder, we do have the question of how to bound ctx->priority +
> ctx->priority_offset. Currently, outside of the user range is privileged
> space reserved for the kernel (both above and below). Now we can move
> those even further to accommodate multiple non-overlapping cgroups.

Yep, I mentioned this as an open question in the series coverletter.

My understanding is that today we limit userspace-assigned priorities to
[1023,1023] and that the kernel can use the userspace range plus -1024
(for the kernel idle context), 1024 (for boosting contexts the display
is waiting on), and INT_MAX (for the preempt context).  Are there any
other special values we use today that I'm overlooking?

I think we have the following options with how to proceed:

 * Option 1:  Silently limit (priority+priority offset) to the existing
   [-1023,1023] range.  That means that if, for example, a user context
   had a priority offset of 600 and tried to manually boost its context
   priority to 600, it would simply be treated as a 1023 for scheduling
   purposes.  This approach is simple, but doesn't allow us to force
   contexts in different cgroups into non-overlapping priority ranges
   (i.e., lowest possible priority in one cgroup is still higher than
   the highest possible priority in another cgroup).  It also isn't
   possible to define a class of applications as "more important than
   display" via cgroup, which I think might be useful in some cases.

 * Option 2:  Allow priority offset to be set in a much larger range
   (e.g., [SHRT_MIN+1023,SHRT_MAX-1023]).  This allows cgroups to have
   effective priority ranges that don't overlap.  cgroup ranges can also
   be intentionally set above I915_PRIORITY_DISPLAY to allow us to
   define classes of applications whose work is more important than
   maintaining a stable framerate on the display.  We'd also probably
   need to shift the kernel idle context down to something like INT_MIN
   instead of using -1024.

 * Option 3: No limits, leave behavior as it stands now in this patch
   series (unrestricted range).  If you're privileged enough to define
   the cgroup settings for a system and you decide to shoot yourself in
   the foot by setting them to nonsense values, that's your own fault.

Thoughts?  Any other options to consider?

> We also have the presumption that only privileged processes can raise a
> priority, but I presume the cgroup property itself is protected.
> -Chris

The way the code is written write now, anyone who has write access to
the cgroup itself (i.e., can migrate processes into/out of the cgroup)
is allowed to adjust the i915-specific cgroup settings.  So this depends
on how the cgroups-v2 filesystem was initially mounted and/or how the
filesystem permissions were adjusted after the fact; the details may
vary from system to system depending on the policy decisions of the
system integrator / system 

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Check that the error state does hold the expected state

[Chris Wilson]

Quoting Antonio Argenziano (2018-03-05 19:10:37)
> 
> 
> On 05/03/18 02:09, Chris Wilson wrote:
> > Actually check the error state exists (!"No error state captured") and
> > that it contains the expected engine dump.
> > 
> > v2: Throw in some debug clues.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   tests/drv_hangman.c | 12 
> >   1 file changed, 12 insertions(+)
> > 
> > diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
> > index 38cb20c3..fa7becf5 100644
> > --- a/tests/drv_hangman.c
> > +++ b/tests/drv_hangman.c
> > @@ -129,6 +129,14 @@ static void check_error_state(const char 
> > *expected_ring_name,
> >   FILE *file = open_error();
> >   char *line = NULL;
> >   size_t line_size = 0;
> > + bool found = false;
> > +
> > + igt_debug("%s(expected ring name=%s, expected offset=%"PRIx64")\n",
> > +   __func__, expected_ring_name, expected_offset);
> > + igt_debugfs_dump(device, "i915_error_state");
> > +
> > + getline(, _size, file);
> > + igt_assert(strcasecmp(line, "No error state captured"));
> >   
> >   while (getline(, _size, file) > 0) {
> >   char *dashes;
> > @@ -168,12 +176,16 @@ static void check_error_state(const char 
> > *expected_ring_name,
> >4*i, batch[i]);
> >   igt_assert(strstr(line, expected_line));
> >   }
> > +
> > + found = true;
> >   break;
> >   }
> >   }
> >   
> >   free(line);
> >   fclose(file);
> > +
> > + igt_assert(found);
> 
> Test changes look fine to me, failures on CI seems to be caused by the 
> test not waiting for reset to happen only before we would have not 
> caught it.
> 
> Reviwed-by: Antonio Argenziano 

Fixed the kernel bug, clearing the way for this patch to land.

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote:
> Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran:
> >
> >
> > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
> >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
>  Similar to enable_fbc, enable_psr was ignored at runtime if it was
>  changed. The easiest fix is to pretend enable_psr is ignored at
>  configure time, and never activate it for !enable_psr, so both cases
>  are handled without modesets.
> >>> What about cases where psr_flush() is not called and consequently the
> >>> module parameter is not checked? With HW tracking, PSR is
> >>> enabled/disabled during modeset and the hardware is expected to exit and
> >>> activate PSR without driver intervention.
> >> It looks like intel_frontbuffer_flush always calls intel_psr_flush,
> >> so we at least get a PSR toggle after every atomic commit?
> > I have a patch to remove flush() from legacy_cursor_update(). We end up
> > with an inconsistent behavior when that patch gets merged,
> > cursor moves -> trigger psr exit but don't read module parameter
> > commits -> trigger psr exit but read module parameter
> Legacy cursor updates are special, I don't mind them not changing PSR.
> > Eventually, when we get to removing flush() from commits, then this
> > patch won't really be useful. And tests disabling/enabling PSR at
> > runtime will probably fail.
> Could we transition to debugfs for changing it at runtime?

That does sound like a better idea.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all

[Chris Wilson]

Quoting Matthew Auld (2018-03-08 17:48:48)
> On 7 March 2018 at 17:13, Chris Wilson  wrote:
> > Currently, we only allow ourselves to prune the fences so long as
> > all the waits completed (i.e. all the fences we checked were signaled),
> > and that the reservation snapshot did not change across the wait.
> > However, if we only waited for a subset of the reservation object, i.e.
> > just waiting for the last writer to complete as opposed to all readers
> > as well, then we would erroneously conclude we could prune the fences as
> > indeed although all of our waits were successful, they did not represent
> > the totality of the reservation object.
> >
> > v2: We only need to check the shared fences due to construction (i.e.
> > all of the shared fences will be later than the exclusive fence, if
> > any).
> >
> > Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait")
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index a5bd07338b46..9b48b5101357 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -433,20 +433,28 @@ i915_gem_object_wait_reservation(struct 
> > reservation_object *resv,
> > dma_fence_put(shared[i]);
> > kfree(shared);
> >
> > +   /*
> > +* If both shared fences and an exclusive fence exist,
> > +* then by construction the shared fences must be later
> > +* than the exclusive fence. If we successfully wait for
> > +* all the shared fences, we know that the exclusive fence
> > +* must all be signaled. If all the shared fences are
> > +* signaled, we can prune the array and recover the
> > +* floating references on the fences/requests.
> > +*/
> > prune_fences = count && timeout >= 0;
> > } else {
> > excl = reservation_object_get_excl_rcu(resv);
> > }
> >
> > -   if (excl && timeout >= 0) {
> > +   if (excl && timeout >= 0)
> > timeout = i915_gem_object_wait_fence(excl, flags, timeout,
> >  rps_client);
> > -   prune_fences = timeout >= 0;
> > -   }
> >
> > dma_fence_put(excl);
> >
> > -   /* Oportunistically prune the fences iff we know they have *all* 
> > been
> > +   /*
> > +* Oportunistically prune the fences iff we know they have *all* 
> > been
> Opportunistically
> 
> Reviewed-by: Matthew Auld 

And a bonus spelling fix, thank you!
Pushed,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Maarten Lankhorst]

Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran:
>
>
> On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
>> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
>>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
 Similar to enable_fbc, enable_psr was ignored at runtime if it was
 changed. The easiest fix is to pretend enable_psr is ignored at
 configure time, and never activate it for !enable_psr, so both cases
 are handled without modesets.
>>> What about cases where psr_flush() is not called and consequently the
>>> module parameter is not checked? With HW tracking, PSR is
>>> enabled/disabled during modeset and the hardware is expected to exit and
>>> activate PSR without driver intervention.
>> It looks like intel_frontbuffer_flush always calls intel_psr_flush,
>> so we at least get a PSR toggle after every atomic commit?
> I have a patch to remove flush() from legacy_cursor_update(). We end up
> with an inconsistent behavior when that patch gets merged,
> cursor moves -> trigger psr exit but don't read module parameter
> commits -> trigger psr exit but read module parameter
Legacy cursor updates are special, I don't mind them not changing PSR.
> Eventually, when we get to removing flush() from commits, then this
> patch won't really be useful. And tests disabling/enabling PSR at
> runtime will probably fail.
Could we transition to debugfs for changing it at runtime?

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all

[Matthew Auld]

On 7 March 2018 at 17:13, Chris Wilson  wrote:
> Currently, we only allow ourselves to prune the fences so long as
> all the waits completed (i.e. all the fences we checked were signaled),
> and that the reservation snapshot did not change across the wait.
> However, if we only waited for a subset of the reservation object, i.e.
> just waiting for the last writer to complete as opposed to all readers
> as well, then we would erroneously conclude we could prune the fences as
> indeed although all of our waits were successful, they did not represent
> the totality of the reservation object.
>
> v2: We only need to check the shared fences due to construction (i.e.
> all of the shared fences will be later than the exclusive fence, if
> any).
>
> Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a5bd07338b46..9b48b5101357 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -433,20 +433,28 @@ i915_gem_object_wait_reservation(struct 
> reservation_object *resv,
> dma_fence_put(shared[i]);
> kfree(shared);
>
> +   /*
> +* If both shared fences and an exclusive fence exist,
> +* then by construction the shared fences must be later
> +* than the exclusive fence. If we successfully wait for
> +* all the shared fences, we know that the exclusive fence
> +* must all be signaled. If all the shared fences are
> +* signaled, we can prune the array and recover the
> +* floating references on the fences/requests.
> +*/
> prune_fences = count && timeout >= 0;
> } else {
> excl = reservation_object_get_excl_rcu(resv);
> }
>
> -   if (excl && timeout >= 0) {
> +   if (excl && timeout >= 0)
> timeout = i915_gem_object_wait_fence(excl, flags, timeout,
>  rps_client);
> -   prune_fences = timeout >= 0;
> -   }
>
> dma_fence_put(excl);
>
> -   /* Oportunistically prune the fences iff we know they have *all* been
> +   /*
> +* Oportunistically prune the fences iff we know they have *all* been
Opportunistically

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> > On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
> >> Similar to enable_fbc, enable_psr was ignored at runtime if it was
> >> changed. The easiest fix is to pretend enable_psr is ignored at
> >> configure time, and never activate it for !enable_psr, so both cases
> >> are handled without modesets.
> > What about cases where psr_flush() is not called and consequently the
> > module parameter is not checked? With HW tracking, PSR is
> > enabled/disabled during modeset and the hardware is expected to exit and
> > activate PSR without driver intervention.
> It looks like intel_frontbuffer_flush always calls intel_psr_flush,
> so we at least get a PSR toggle after every atomic commit?

I have a patch to remove flush() from legacy_cursor_update(). We end up
with an inconsistent behavior when that patch gets merged,
cursor moves -> trigger psr exit but don't read module parameter
commits -> trigger psr exit but read module parameter

Eventually, when we get to removing flush() from commits, then this
patch won't really be useful. And tests disabling/enabling PSR at
runtime will probably fail.


> 
> ~Maarten
> 
> >> Signed-off-by: Maarten Lankhorst 
> >> Tested-by: Benjamin Berg 
> >> Cc: Benjamin Berg 
> >> ---
> >>  drivers/gpu/drm/i915/intel_psr.c | 19 ++-
> >>  1 file changed, 10 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> >> b/drivers/gpu/drm/i915/intel_psr.c
> >> index 23175c5c4a50..ac3ce7a1c2a7 100644
> >> --- a/drivers/gpu/drm/i915/intel_psr.c
> >> +++ b/drivers/gpu/drm/i915/intel_psr.c
> >> @@ -502,11 +502,6 @@ void intel_psr_compute_config(struct intel_dp 
> >> *intel_dp,
> >>if (!CAN_PSR(dev_priv))
> >>return;
> >>  
> >> -  if (!i915_modparams.enable_psr) {
> >> -  DRM_DEBUG_KMS("PSR disable by flag\n");
> >> -  return;
> >> -  }
> >> -
> >>/*
> >> * HSW spec explicitly says PSR is tied to port A.
> >> * BDW+ platforms with DDI implementation of PSR have different
> >> @@ -559,7 +554,10 @@ void intel_psr_compute_config(struct intel_dp 
> >> *intel_dp,
> >>  
> >>crtc_state->has_psr = true;
> >>crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
> >> -  DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
> >> +  if (i915_modparams.enable_psr)
> >> +  DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : 
> >> "");
> >> +  else
> >> +  DRM_DEBUG_KMS("PSR disable by flag\n");
> >>  }
> >>  
> >>  static void intel_psr_activate(struct intel_dp *intel_dp)
> >> @@ -652,7 +650,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> >>dev_priv->psr.enable_source(intel_dp, crtc_state);
> >>dev_priv->psr.enabled = intel_dp;
> >>  
> >> -  if (INTEL_GEN(dev_priv) >= 9) {
> >> +  if (!i915_modparams.enable_psr) {
> >> +  DRM_DEBUG_KMS("PSR disable by flag\n");
> >> +  } else if (INTEL_GEN(dev_priv) >= 9) {
> >>intel_psr_activate(intel_dp);
> >>} else {
> >>/*
> >> @@ -843,7 +843,7 @@ static void intel_psr_work(struct work_struct *work)
> >> * recheck. Since psr_flush first clears this and then reschedules we
> >> * won't ever miss a flush when bailing out here.
> >> */
> >> -  if (dev_priv->psr.busy_frontbuffer_bits)
> >> +  if (dev_priv->psr.busy_frontbuffer_bits || !i915_modparams.enable_psr)
> >>goto unlock;
> >>  
> >>intel_psr_activate(intel_dp);
> >> @@ -1015,7 +1015,8 @@ void intel_psr_flush(struct drm_i915_private 
> >> *dev_priv,
> >>return;
> >>  
> >>mutex_lock(_priv->psr.lock);
> >> -  if (!dev_priv->psr.enabled) {
> >> +  if (!dev_priv->psr.enabled || !i915_modparams.enable_psr) {
> >> +  intel_psr_exit(dev_priv);
> >>mutex_unlock(_priv->psr.lock);
> >>return;
> >>}
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Quoting Antonio Argenziano (2018-03-08 17:33:11)
> 
> 
> On 07/03/18 17:18, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-03-08 00:55:47)
> >>
> >>
> >> On 07/03/18 14:49, Chris Wilson wrote:
> >>> + gem_quiescent_gpu(fd);
> >>
> >> Check frequency has gone back to ~min.
> > 
> > It's not that interesting a test (covered already by pmu) as we
> > essentially lie anyway over idle.
> 
> Agreed.

I should mention somewhere the reason for all the gem_quiescent_gpu()
spam here is because I want to make sure that no stray waitboosts affect
the measurements.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Kill the remaining CHV HBR2 leftovers

[Pandiyan, Dhinakaran]

On Thu, 2018-03-08 at 14:58 +0200, Ville Syrjälä wrote:
> On Wed, Mar 07, 2018 at 09:41:06PM +, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > AFAIK CHV was supposed to have HBR2 originally, but in the end the feature
> > > was dropped. We still have some code leftovers from those early days.
> > > Eliminate them.
> > > 
> > 
> > Not much in the spec about HBR2 other than the support for TP3. Since we
> > don't support HBR2 on CHV, removing the unused TPS3 bits looks correct.
> > 
> > 
> > 
> > > The extra bit for the training pattern seems to be dead in the hardware.
> > > I can set it (in fact I can set almost any reserved bit in the
> > > registers) but it doesn't seem to interfere with the operation of the
> > > hardware. Either that or I'm very lucky that my displays complete link
> > > training with the incorrect pattern being sent out.
> > > 
> > 
> > I don't think I follow this, are you saying there's no need to clear the
> > TPS3 bit? Isn't it better to have the mask include 1 << 14, so that
> > _intel_dp_set_link_train() clears the bit?
> 
> I'm saying the bit doesn't actually seem to exist in hardware. In fact
> most of my specs don't list it either. Looks like only the "K0" specs
> have it.
> 

Thanks for clarifying.

Reviewed-by: Dhinakaran Pandiyan 

> > 
> > 
> > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h |  2 --
> > >  drivers/gpu/drm/i915/intel_dp.c | 20 
> > >  2 files changed, 4 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 95a2e51ecbb0..f3efc242df2d 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5250,8 +5250,6 @@ enum {
> > >  #define   DP_LINK_TRAIN_OFF  (3 << 28)
> > >  #define   DP_LINK_TRAIN_MASK (3 << 28)
> > >  #define   DP_LINK_TRAIN_SHIFT28
> > > -#define   DP_LINK_TRAIN_PAT_3_CHV(1 << 14)
> > > -#define   DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
> > >  
> > >  /* CPT Link training mode */
> > >  #define   DP_LINK_TRAIN_PAT_1_CPT(0 << 8)
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index aba2f45819d8..df1772044208 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -92,8 +92,6 @@ static const struct dp_link_dpll chv_dpll[] = {
> > >   { .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } },
> > >   { 27,   /* m2_int = 27, m2_fraction = 0 */
> > >   { .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } },
> > > - { 54,   /* m2_int = 27, m2_fraction = 0 */
> > > - { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
> > >  };
> > >  
> > >  /**
> > > @@ -2908,10 +2906,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > >   }
> > >  
> > >   } else {
> > > - if (IS_CHERRYVIEW(dev_priv))
> > > - *DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > - else
> > > - *DP &= ~DP_LINK_TRAIN_MASK;
> > > + *DP &= ~DP_LINK_TRAIN_MASK;
> > >  
> > >   switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> > >   case DP_TRAINING_PATTERN_DISABLE:
> > > @@ -2924,12 +2919,8 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > >   *DP |= DP_LINK_TRAIN_PAT_2;
> > >   break;
> > >   case DP_TRAINING_PATTERN_3:
> > > - if (IS_CHERRYVIEW(dev_priv)) {
> > > - *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> > > - } else {
> > > - DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
> > > instead\n");
> > > - *DP |= DP_LINK_TRAIN_PAT_2;
> > > - }
> > > + DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
> > > instead\n");
> > > + *DP |= DP_LINK_TRAIN_PAT_2;
> > >   break;
> > >   }
> > >   }
> > > @@ -3668,10 +3659,7 @@ intel_dp_link_down(struct intel_encoder *encoder,
> > >   DP &= ~DP_LINK_TRAIN_MASK_CPT;
> > >   DP |= DP_LINK_TRAIN_PAT_IDLE_CPT;
> > >   } else {
> > > - if (IS_CHERRYVIEW(dev_priv))
> > > - DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > - else
> > > - DP &= ~DP_LINK_TRAIN_MASK;
> > > + DP &= ~DP_LINK_TRAIN_MASK;
> > >   DP |= DP_LINK_TRAIN_PAT_IDLE;
> > >   }
> > >   I915_WRITE(intel_dp->output_reg, DP);
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Antonio Argenziano]

On 07/03/18 17:18, Chris Wilson wrote:

Quoting Antonio Argenziano (2018-03-08 00:55:47)



On 07/03/18 14:49, Chris Wilson wrote:

+static void single(int fd, const struct intel_execution_engine *e)
+{
+ const unsigned int engine = e->exec_id | e->flags;
+ uint32_t ctx = gem_context_create(fd);
+ uint32_t min, max;
+ double measured;
+ igt_spin_t *spin;
+ int pmu;
+
+ get_freq(fd, ctx, , );
+ igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+ pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+ igt_require(pmu >= 0);
+
+ gem_quiescent_gpu(fd);
+ measured = measure_frequency(pmu, 1);
+ igt_info("Initial (idle) freq: %.1fMHz\n",measured);
+ igt_require(measured >= min - 50 && measured <= min + 50);
+
+ for (uint32_t freq = min + 50; freq <= max; freq += 100) {
+ set_freq(fd, ctx, freq, freq);
+
+ gem_quiescent_gpu(fd);
+ spin = __igt_spin_batch_new(fd, ctx, engine, 0);
+ usleep(1);
+
+ measured = measure_frequency(pmu, 5);
+ igt_debugfs_dump(fd, "i915_rps_boost_info");
+
+ igt_spin_batch_free(fd, spin);
+ igt_info("%s(single): Measured %.1fMHz, expected %dMhz\n",
+  e->name, measured, freq);
+ igt_assert(measured > freq - 100 && measured < freq + 100);
+ }
+ gem_quiescent_gpu(fd);


Check frequency has gone back to ~min.


It's not that interesting a test (covered already by pmu) as we
essentially lie anyway over idle.


Agreed.




I would suggest to split here into two sub-tests.


+ spin = __igt_spin_batch_new(fd, ctx, engine, 0);
+ for (uint32_t freq = min + 50; freq <= max; freq += 100) {
+ igt_spin_t *kick;
+
+ set_freq(fd, ctx, freq, freq);
+
+ /*
+  * When requesting a new frequency on the currently
+  * executing context, it does not take effect until the
+  * next context switch. In this case, we trigger a lite
+  * restore.


Is this enforced by the ABI?


Enforced? No. The comment is precisely because it's not checked on
calling whether the context is currently on the HW and trying hard to be
sure that no one expects us to do that check. i.e. that set_freq()
doesn't change frequency itself, but doesn't rule it out either as it
may appear to have that effect due to many external factors.


That is what I thought :).

I see that you had a new version with more tests, I'll have a look at that.

Thanks,
Antonio


-Chris


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

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

v2: Split single/continuous set_freq subtests

Signed-off-by: Chris Wilson 
Cc: Paneri, Praveen 
Cc: Kamble, Sagar A 
Cc: Antonio Argenziano 
---
 tests/Makefile.am  |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 604 +
 tests/meson.build  |   1 +
 4 files changed, 607 insertions(+)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..f7e79ac3
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,604 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 8
+
+#define SAMPLE_PERIOD (USEC_PER_SEC / 10)
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   return __gem_context_set_param(fd, );
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int period_us)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(period_us);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 0);
+
+   for (uint32_t freq = min + 50; freq <= max; freq += 100) {
+   uint32_t cur, discard;
+
+

Re: [Intel-gfx] [RFC v3 09/12] drm: Add API for in-kernel clients

[Noralf Trønnes]

Den 06.03.2018 09.56, skrev Daniel Vetter:

On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Trønnes wrote:

This adds an API for writing in-kernel clients.

TODO:
- Flesh out and complete documentation.
- Cloned displays is not tested.
- Complete tiled display support and test it.
- Test plug/unplug different monitors.
- A runtime knob to prevent clients from attaching for debugging purposes.
- Maybe a way to unbind individual client instances.
- Maybe take the sysrq support in drm_fb_helper and move it here somehow.
- Add suspend/resume callbacks.
   Does anyone know why fbdev requires suspend/resume?

Signed-off-by: Noralf Trønnes 

The core client api I like. Some of the opens I'm seeing:

- If we go with using the internal kms api directly instead of IOCTL
   wrappers then a huge pile of the functions you have here aren't needed
   (e.g. all the event stuff we can just directly use vblank events instead
   of all the wrapping). I'm leaning ever more into that direction, since
   much less code to add.


Looking at drm_fb_helper once again I now see an opportunity to simplify
the modesetting code by nuking drm_fb_helper_connector and stop
maintaining an array of connectors. It looks to be possible to just
create an array temporarily in drm_setup_crtcs() for the duration of the
function. The connectors we care about are ref counted and attached to
modesets. This would remove the need for drm_fb_helper_add_one_connector().

So I might be able to do struct drm_fb_helper_crtc -> drm_client_crtc
and let the client API take over drm_setup_crtcs(). I'll give it a try.

There is one challenge I see upfront and that's the i915 fb_helper
callback in drm_setup_crtcs().


- The register/unregister model needs more thought. Allowing both clients
   to register whenever they want to, and drm_device instances to come and
   go is what fbcon has done, and the resulting locking is a horror show.

   I think if we require that all in-kernel drm_clients are registers when
   loading drm.ko (and enabled/disabled only per module options and
   Kconfig), then we can throw out all the locking. That avoids a lot of
   the headaches.

   2nd, if the list of clients is static over the lifetime of drm.ko, we
   also don't need to iterate existing drivers. Which avoids me having to
   review the iterator patch (that's the other aspect where fbcon totally
   falls over and essentially just ignores a bunch of races).


Are you talking about linking the clients into drm.ko?

drivers/gpu/drm/Makefile:

drm-$(CONFIG_DRM_CLIENT_BOOTSPLASH) += client/drm_bootsplash.o

drivers/gpu/drm/drm_drv.c:

 static int __init drm_core_init(void)
 {
+    drm_bootsplash_register();
+    drm_fbdev_register();
 }

drivers/gpu/drm/drm_internal.h:

#ifdef DRM_CLIENT_BOOTSPLASH
void drm_bootsplash_register(void);
#else
static inline void drm_bootsplash_register(void)
{
}
#endif

drivers/gpu/drm/client/drm_bootsplash.c:

static const struct drm_client_funcs drm_bootsplash_funcs = {
    .name        = "drm_bootsplash",
    .new        = drm_bootsplash_new,
    .remove        = drm_bootsplash_remove,
    .hotplug    = drm_bootsplash_hotplug,
};

void drm_bootsplash_register(void)
{
    drm_client_register(_bootsplash_funcs);
}

drivers/gpu/drm/drm_client.c:

static LIST_HEAD(drm_client_funcs_list);

void drm_client_register(const struct drm_client_funcs *funcs)
{
    struct drm_client_funcs_entry *funcs_entry;

    funcs_entry = kzalloc(sizeof(*funcs_entry), GFP_KERNEL);
    if (!funcs_entry) {
        DRM_ERROR("Failed to register: %s\n", funcs->name);
        return;
    }

    funcs_entry->funcs = funcs;

    list_add(_entry->list, _client_funcs_list);

    DRM_DEBUG_KMS("%s\n", funcs->name);
}


And each client having a runtime enable/disable knob:

drivers/gpu/drm/client/drm_bootsplash.c:

static bool drm_bootsplash_enabled = true;
module_param_named(bootsplash_enabled, drm_bootsplash_enabled, bool, 0600);
MODULE_PARM_DESC(bootsplash_enabled, "Enable bootsplash client 
[default=true]");



Simple USB Display
A few months back while looking at the udl shmem code, I got the idea
that I could turn a Raspberry Pi Zero into a $5 USB to HDMI/DSI/DPI/DBI/TV
adapter. The host side would be a simple tinydrm driver using the kernel
compression lib to speed up transfers. The gadget/device side would be a
userspace app decompressing the buffer into an exported dumb buffer.

While working with this client API I realized that I could use it and
write a kernel gadget driver instead avoiding the challenge of going
back and forth to userspace with the framebuffer. For such a client I
would have preferred it to be a loadable module not linked into drm.ko
to increase the chance that distributions would enable it.

Noralf.


---
  drivers/gpu/drm/Kconfig |2 +
  drivers/gpu/drm/Makefile|3 +-
  drivers/gpu/drm/client/Kconfig  |4 +
  drivers/gpu/drm/client/Makefile |1 +
  

Re: [Intel-gfx] vlv punit and sideband tidy

[Chris Wilson]

Quoting Rogozhkin, Dmitry V (2018-03-07 20:39:16)
> On Wed, 2018-03-07 at 19:41 +, Chris Wilson wrote:
> > Mika
> > believes that if we keep the cpu in C0 whilst the gpu is busy, then
> > it
> > behaves much better -- but that is a very tough sell
> 
> Chris, Mika, I wonder does i915 driver tries to keep CPU in C0 at the
> moment already or you just consider this? 

That is what Mika looked at, setting C0 while the GPU is marked busy.
Iirc, he was satisfied with the result, I just objected on the grounds
that keeping the CPU at max frequency was unlikely to win any friends in
HTPC. (Although, maybe my gut feeling here is backwards and killawatt
reports differently.)

> CPU while gpu is busy, could you, please, clarify what exactly and
> point me to the code/key patches? Please, answer from BDW/SKL gen
> perspective rather than VLV.

Basically you do pm_qos_update_request() from i915_request::mark_busy().
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Maarten Lankhorst]

Op 08-03-18 om 17:21 schreef Ville Syrjälä:
> On Thu, Mar 08, 2018 at 05:02:38PM +0100, Maarten Lankhorst wrote:
>> Op 08-03-18 om 16:22 schreef Ville Syrjälä:
>>> On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote:
 This will get rid of the following error:
 [   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
 [   74.730311] Modules linked in: vgem snd_hda_codec_hdmi 
 snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal 
 intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec 
 crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core 
 bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei prime_numbers
 [   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
 4.16.0-rc2-CI-CI_DRM_3822+ #1
 [   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
 10/17/2011
 [   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
 [   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
 [   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 
 0001
 [   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 
 82068cea
 [   74.730369] RBP: 88022fb03d70 R08:  R09: 
 815d26d0
 [   74.730371] R10:  R11: a0161ca0 R12: 
 0001
 [   74.730373] R13: 880212448008 R14: 880212448330 R15: 
 
 [   74.730376] FS:  () GS:88022fb0() 
 knlGS:
 [   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
 [   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 
 000606e0
 [   74.730382] Call Trace:
 [   74.730385]  
 [   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
 [   74.730401]  drm_update_vblank_count+0x64/0x240
 [   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
 [   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
 [   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
 [   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
 [   74.730548]  __handle_irq_event_percpu+0x3c/0x340
 [   74.730556]  handle_irq_event_percpu+0x1b/0x50
 [   74.730561]  handle_irq_event+0x2f/0x50
 [   74.730566]  handle_edge_irq+0xe4/0x1b0
 [   74.730572]  handle_irq+0x11/0x20
 [   74.730576]  do_IRQ+0x5e/0x120
 [   74.730584]  common_interrupt+0x84/0x84
 [   74.730586]  
 [   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
 [   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
 ffde
 [   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 
 0001
 [   74.730599] RDX:  RSI: 8210fb59 RDI: 
 820c02e7
 [   74.730601] RBP: 0004 R08: 40af R09: 
 0018
 [   74.730603] R10:  R11:  R12: 
 0004
 [   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 
 82294460
 [   74.730621]  ? cpuidle_enter_state+0xa6/0x350
 [   74.730629]  do_idle+0x188/0x1d0
 [   74.730636]  cpu_startup_entry+0x14/0x20
 [   74.730641]  start_secondary+0x129/0x160
 [   74.730646]  secondary_startup_64+0xa5/0xb0
 [   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 
 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff 
 <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
 [   74.730754] ---[ end trace 14b1345705b68565 ]---

 Changes since v1:
 - Don't try to apply CRC workaround when enabling pipe, it should already 
 be enabled.
 Changes since v2:
 - Make crc functions for !DEBUGFS case inline.
 - Pass intel_crtc to crc functions.
 - Add comments to callsites.
 Changes since v3:
 - Cache selected source to pipe_crc->source.
 - Set pipe_crc->skipped to MIN_INT during disable to close a race 
 condition.
 Changes since v4:
 - Handle fallout from setting pipe_crc->source in irq handler.

 Cc: Marta Löfstedt 
 Reported-by: Marta Löfstedt 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/i915_irq.c   |  4 +--
  drivers/gpu/drm/i915/intel_display.c  | 10 +++
  drivers/gpu/drm/i915/intel_drv.h  |  9 ++
  drivers/gpu/drm/i915/intel_pipe_crc.c | 53 
 ++-
  4 files changed, 67 insertions(+), 9 deletions(-)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39614/
State : success

== Summary ==

Series 39614v1 series starting with [v2,01/15] drm/i915/guc: Tidy 
guc_log_control
https://patchwork.freedesktop.org/api/1.0/series/39614/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-cnl-y3) fdo#103167

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:506s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:480s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:585s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:518s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:424s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
fi-cfl-u failed to collect. IGT log at Patchwork_8275/fi-cfl-u/run0.log

da319f89899feb1b6206d7092b10189a926a893c drm-tip: 2018y-03m-08d-12h-49m-27s UTC 
integration manifest
379600aecf1b HAX enable guc for CI
561313bdbb69 drm/i915/guc: Default to non-verbose GuC logging
9919f3c4ef62 drm/i915/guc: Allow user to control default GuC logging
7688a3d6c706 drm/i915/guc: Don't print out relay statistics when relay is 
disabled
4df6319cba38 drm/i915/guc: Always print log stats in i915_guc_info when using 
GuC
d8d5b88cd0af drm/i915/guc: Get rid of GuC log runtime
c6076d262079 drm/i915/guc: Move check for fast memcpy_wc to relay creation
b39b496589fa drm/i915/guc: Split relay control and GuC log level
b75cfe289828 drm/i915/guc: Flush directly in log unregister
538047832dbe drm/i915/guc: Merge log relay file and channel creation
1756525f1bea drm/i915/guc: Log runtime should consist of both mapping and relay
db07f9ade606 drm/i915/guc: Keep GuC interrupts enabled when using GuC
b1de17c10c7f drm/i915/guc: Move GuC notification handling to separate function
aa0d71c08bab drm/i915/guc: Create common entry points for log 
register/unregister
8f3d72331b9e drm/i915/guc: Tidy guc_log_control

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Ville Syrjälä]

On Thu, Mar 08, 2018 at 05:02:38PM +0100, Maarten Lankhorst wrote:
> Op 08-03-18 om 16:22 schreef Ville Syrjälä:
> > On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote:
> >> This will get rid of the following error:
> >> [   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
> >> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> >> [   74.730311] Modules linked in: vgem snd_hda_codec_hdmi 
> >> snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal 
> >> intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec 
> >> crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core 
> >> bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei prime_numbers
> >> [   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
> >> 4.16.0-rc2-CI-CI_DRM_3822+ #1
> >> [   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
> >> 10/17/2011
> >> [   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> >> [   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
> >> [   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 
> >> 0001
> >> [   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 
> >> 82068cea
> >> [   74.730369] RBP: 88022fb03d70 R08:  R09: 
> >> 815d26d0
> >> [   74.730371] R10:  R11: a0161ca0 R12: 
> >> 0001
> >> [   74.730373] R13: 880212448008 R14: 880212448330 R15: 
> >> 
> >> [   74.730376] FS:  () GS:88022fb0() 
> >> knlGS:
> >> [   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
> >> [   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 
> >> 000606e0
> >> [   74.730382] Call Trace:
> >> [   74.730385]  
> >> [   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
> >> [   74.730401]  drm_update_vblank_count+0x64/0x240
> >> [   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
> >> [   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
> >> [   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
> >> [   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
> >> [   74.730548]  __handle_irq_event_percpu+0x3c/0x340
> >> [   74.730556]  handle_irq_event_percpu+0x1b/0x50
> >> [   74.730561]  handle_irq_event+0x2f/0x50
> >> [   74.730566]  handle_edge_irq+0xe4/0x1b0
> >> [   74.730572]  handle_irq+0x11/0x20
> >> [   74.730576]  do_IRQ+0x5e/0x120
> >> [   74.730584]  common_interrupt+0x84/0x84
> >> [   74.730586]  
> >> [   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
> >> [   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
> >> ffde
> >> [   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 
> >> 0001
> >> [   74.730599] RDX:  RSI: 8210fb59 RDI: 
> >> 820c02e7
> >> [   74.730601] RBP: 0004 R08: 40af R09: 
> >> 0018
> >> [   74.730603] R10:  R11:  R12: 
> >> 0004
> >> [   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 
> >> 82294460
> >> [   74.730621]  ? cpuidle_enter_state+0xa6/0x350
> >> [   74.730629]  do_idle+0x188/0x1d0
> >> [   74.730636]  cpu_startup_entry+0x14/0x20
> >> [   74.730641]  start_secondary+0x129/0x160
> >> [   74.730646]  secondary_startup_64+0xa5/0xb0
> >> [   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 
> >> 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff 
> >> <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
> >> [   74.730754] ---[ end trace 14b1345705b68565 ]---
> >>
> >> Changes since v1:
> >> - Don't try to apply CRC workaround when enabling pipe, it should already 
> >> be enabled.
> >> Changes since v2:
> >> - Make crc functions for !DEBUGFS case inline.
> >> - Pass intel_crtc to crc functions.
> >> - Add comments to callsites.
> >> Changes since v3:
> >> - Cache selected source to pipe_crc->source.
> >> - Set pipe_crc->skipped to MIN_INT during disable to close a race 
> >> condition.
> >> Changes since v4:
> >> - Handle fallout from setting pipe_crc->source in irq handler.
> >>
> >> Cc: Marta Löfstedt 
> >> Reported-by: Marta Löfstedt 
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/i915_irq.c   |  4 +--
> >>  drivers/gpu/drm/i915/intel_display.c  | 10 +++
> >>  drivers/gpu/drm/i915/intel_drv.h  |  9 ++
> >>  drivers/gpu/drm/i915/intel_pipe_crc.c | 53 
> >> ++-
> >>  4 files changed, 67 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index ce16003ef048..7807488084fe 100644
> >> --- 

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Maarten Lankhorst]

Op 08-03-18 om 16:22 schreef Ville Syrjälä:
> On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote:
>> This will get rid of the following error:
>> [   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
>> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
>> [   74.730311] Modules linked in: vgem snd_hda_codec_hdmi 
>> snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal 
>> intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec 
>> crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib 
>> snd_pcm tg3 lpc_ich mei_me mei prime_numbers
>> [   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
>> 4.16.0-rc2-CI-CI_DRM_3822+ #1
>> [   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
>> 10/17/2011
>> [   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
>> [   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
>> [   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 
>> 0001
>> [   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 
>> 82068cea
>> [   74.730369] RBP: 88022fb03d70 R08:  R09: 
>> 815d26d0
>> [   74.730371] R10:  R11: a0161ca0 R12: 
>> 0001
>> [   74.730373] R13: 880212448008 R14: 880212448330 R15: 
>> 
>> [   74.730376] FS:  () GS:88022fb0() 
>> knlGS:
>> [   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
>> [   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 
>> 000606e0
>> [   74.730382] Call Trace:
>> [   74.730385]  
>> [   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
>> [   74.730401]  drm_update_vblank_count+0x64/0x240
>> [   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
>> [   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
>> [   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
>> [   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
>> [   74.730548]  __handle_irq_event_percpu+0x3c/0x340
>> [   74.730556]  handle_irq_event_percpu+0x1b/0x50
>> [   74.730561]  handle_irq_event+0x2f/0x50
>> [   74.730566]  handle_edge_irq+0xe4/0x1b0
>> [   74.730572]  handle_irq+0x11/0x20
>> [   74.730576]  do_IRQ+0x5e/0x120
>> [   74.730584]  common_interrupt+0x84/0x84
>> [   74.730586]  
>> [   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
>> [   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
>> ffde
>> [   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 
>> 0001
>> [   74.730599] RDX:  RSI: 8210fb59 RDI: 
>> 820c02e7
>> [   74.730601] RBP: 0004 R08: 40af R09: 
>> 0018
>> [   74.730603] R10:  R11:  R12: 
>> 0004
>> [   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 
>> 82294460
>> [   74.730621]  ? cpuidle_enter_state+0xa6/0x350
>> [   74.730629]  do_idle+0x188/0x1d0
>> [   74.730636]  cpu_startup_entry+0x14/0x20
>> [   74.730641]  start_secondary+0x129/0x160
>> [   74.730646]  secondary_startup_64+0xa5/0xb0
>> [   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 
>> 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff 
>> <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
>> [   74.730754] ---[ end trace 14b1345705b68565 ]---
>>
>> Changes since v1:
>> - Don't try to apply CRC workaround when enabling pipe, it should already be 
>> enabled.
>> Changes since v2:
>> - Make crc functions for !DEBUGFS case inline.
>> - Pass intel_crtc to crc functions.
>> - Add comments to callsites.
>> Changes since v3:
>> - Cache selected source to pipe_crc->source.
>> - Set pipe_crc->skipped to MIN_INT during disable to close a race condition.
>> Changes since v4:
>> - Handle fallout from setting pipe_crc->source in irq handler.
>>
>> Cc: Marta Löfstedt 
>> Reported-by: Marta Löfstedt 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c   |  4 +--
>>  drivers/gpu/drm/i915/intel_display.c  | 10 +++
>>  drivers/gpu/drm/i915/intel_drv.h  |  9 ++
>>  drivers/gpu/drm/i915/intel_pipe_crc.c | 53 
>> ++-
>>  4 files changed, 67 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index ce16003ef048..7807488084fe 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1626,7 +1626,7 @@ static void display_pipe_crc_irq_handler(struct 
>> drm_i915_private *dev_priv,
>>  int head, tail;
>>  
>>  spin_lock(_crc->lock);
>> -if (pipe_crc->source) {
>> +if 

[Intel-gfx] [PATCH v2 13/15] drm/i915/guc: Allow user to control default GuC logging

[Michał Winiarski]

While both naming and actual log enable logic in GuC interface are
confusing, we can simply expose the default log as yet another log
level.
GuC logic aside, from i915 point of view we now have the following GuC
log levels:
0 Log disabled
1 Non-verbose log
2-5 Verbose log

v2: Adjust naming after rebase.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_guc.c  | 21 -
 drivers/gpu/drm/i915/intel_guc_fwif.h |  5 +++--
 drivers/gpu/drm/i915/intel_guc_log.c  | 18 +++---
 drivers/gpu/drm/i915/intel_guc_log.h  | 15 +++
 drivers/gpu/drm/i915/intel_uc.c   | 14 +-
 5 files changed, 46 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 3e2f0f8503ed..fc21135e2a54 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -221,17 +221,20 @@ static u32 get_core_family(struct drm_i915_private 
*dev_priv)
}
 }
 
-static u32 get_log_verbosity_flags(void)
+static u32 get_log_control_flags(void)
 {
-   if (i915_modparams.guc_log_level > 0) {
-   u32 verbosity = i915_modparams.guc_log_level - 1;
+   u32 level = i915_modparams.guc_log_level;
+   u32 flags = 0;
 
-   GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX);
-   return verbosity << GUC_LOG_VERBOSITY_SHIFT;
-   }
+   GEM_BUG_ON(level < 0);
+
+   if (!GUC_LOG_LEVEL_TO_ENABLED(level))
+   flags = GUC_LOG_DEFAULT_DISABLED | GUC_LOG_DISABLED;
+   else if (GUC_LOG_LEVEL_TO_VERBOSE(level))
+   flags = GUC_LOG_LEVEL_TO_VERBOSITY(level) <<
+   GUC_LOG_VERBOSITY_SHIFT;
 
-   GEM_BUG_ON(i915_modparams.enable_guc < 0);
-   return GUC_LOG_DISABLED;
+   return flags;
 }
 
 /*
@@ -266,7 +269,7 @@ void intel_guc_init_params(struct intel_guc *guc)
 
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
 
-   params[GUC_CTL_DEBUG] = get_log_verbosity_flags();
+   params[GUC_CTL_DEBUG] = get_log_control_flags();
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..4971685a2ea8 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -127,7 +127,7 @@
 #define   GUC_PROFILE_ENABLED  (1 << 7)
 #define   GUC_WQ_TRACK_ENABLED (1 << 8)
 #define   GUC_ADS_ENABLED  (1 << 9)
-#define   GUC_DEBUG_RESERVED   (1 << 10)
+#define   GUC_LOG_DEFAULT_DISABLED (1 << 10)
 #define   GUC_ADS_ADDR_SHIFT   11
 #define   GUC_ADS_ADDR_MASK0xf800
 
@@ -539,7 +539,8 @@ union guc_log_control {
u32 logging_enabled:1;
u32 reserved1:3;
u32 verbosity:4;
-   u32 reserved2:24;
+   u32 default_logging:1;
+   u32 reserved2:23;
};
u32 value;
 } __packed;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index a72fe4a369f4..decada3cf496 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -58,12 +58,14 @@ static int guc_log_flush(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
 
-static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
+static int guc_log_control(struct intel_guc *guc, bool enable,
+  bool default_logging, u32 verbosity)
 {
union guc_log_control control_val = {
{
.logging_enabled = enable,
.verbosity = verbosity,
+   .default_logging = default_logging,
},
};
u32 action[] = {
@@ -501,13 +503,6 @@ int intel_guc_log_level_get(struct intel_guc *guc)
return i915_modparams.guc_log_level;
 }
 
-#define GUC_LOG_LEVEL_DISABLED 0
-#define LOG_LEVEL_TO_ENABLED(x)((x) > 0)
-#define LOG_LEVEL_TO_VERBOSITY(x) ({   \
-   typeof(x) _x = (x); \
-   LOG_LEVEL_TO_ENABLED(_x) ? _x - 1 : 0;  \
-})
-#define VERBOSITY_TO_LOG_LEVEL(x)  ((x) + 1)
 int intel_guc_log_level_set(struct intel_guc *guc, u64 val)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -522,7 +517,7 @@ int intel_guc_log_level_set(struct intel_guc *guc, u64 val)
 * as indication that logging should be disabled.
 */
if (val < GUC_LOG_LEVEL_DISABLED ||
-   val > 

[Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Default to non-verbose GuC logging

[Michał Winiarski]

Now that we've decoupled logging from relay, GuC log level is only
controlling the GuC behavior - there shouldn't be any impact on i915
behaviour. We're only going to see a single extra interrupt when log
will get half full.
That, and the fact that we're seeing igt/gem_exec_nop/basic-series
failing with non-verbose logging being disabled.

v2: Bring back the "auto" guc_log_level, now that we fixed the log

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Reviewed-by: Sagar Arun Kamble  (v1)
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..c96360398072 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -48,7 +48,7 @@ struct drm_printer;
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
param(int, enable_guc, 0) \
-   param(int, guc_log_level, 0) \
+   param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
param(int, mmio_debug, 0) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 3fb5f75aa7c9..2f579fff58cd 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -69,7 +69,7 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
 
 static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)
 {
-   int guc_log_level = 0; /* disabled */
+   int guc_log_level = 1; /* non-verbose */
 
/* Enable if we're running on platform with GuC and debug config */
if (HAS_GUC(dev_priv) && intel_uc_is_using_guc() &&
-- 
2.14.3

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

[Intel-gfx] [PATCH 15/15] HAX enable guc for CI

[Michał Winiarski]

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

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c96360398072..53037b5eff22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.14.3

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

[Intel-gfx] [PATCH v2 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

[Michał Winiarski]

If nobody has enabled the relay, we're not comunicating with GuC, which
means that the stats don't have any meaning. Let's also remove interrupt
counter and tidy the debugfs formatting.

v2: Correct stats accounting (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 45 
 drivers/gpu/drm/i915/intel_guc.c |  5 +---
 drivers/gpu/drm/i915/intel_guc_log.c | 22 +-
 drivers/gpu/drm/i915/intel_guc_log.h | 10 
 4 files changed, 48 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d29bacb1f308..94516ab4eaed 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2326,30 +2326,45 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)
return 0;
 }
 
+static const char *
+stringify_guc_log_type(enum guc_log_buffer_type type)
+{
+   switch (type) {
+   case GUC_ISR_LOG_BUFFER:
+   return "ISR";
+   case GUC_DPC_LOG_BUFFER:
+   return "DPC";
+   case GUC_CRASH_DUMP_LOG_BUFFER:
+   return "CRASH";
+   default:
+   MISSING_CASE(type);
+   }
+
+   return "";
+}
+
 static void i915_guc_log_info(struct seq_file *m,
  struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
+   enum guc_log_buffer_type type;
 
-   seq_puts(m, "GuC logging stats:\n");
-
-   seq_printf(m, "\tISR:   flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_ISR_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
-
-   seq_printf(m, "\tDPC:   flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_DPC_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
-
-   seq_printf(m, "\tCRASH: flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
+   if (!intel_guc_log_relay_enabled(guc)) {
+   seq_puts(m, "GuC log relay disabled\n");
+   return;
+   }
 
-   seq_printf(m, "\tTotal flush interrupt count: %u\n",
-  guc->log.flush_interrupt_count);
+   seq_puts(m, "GuC logging stats:\n");
 
seq_printf(m, "\tRelay full count: %u\n",
   guc->log.relay.full_count);
+
+   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   seq_printf(m, "\t%s:\tflush count %10u, overflow count %10u\n",
+  stringify_guc_log_type(type),
+  guc->log.stats[type].flush,
+  guc->log.stats[type].overflow);
+   }
 }
 
 static void i915_guc_client_info(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index cab158e42577..3e2f0f8503ed 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -388,12 +388,9 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc)
spin_unlock(>irq_lock);
 
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
-  INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
+  INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
queue_work(guc->log.relay.flush_wq,
   >log.relay.flush_work);
-
-   guc->log.flush_interrupt_count++;
-   }
 }
 
 int intel_guc_sample_forcewake(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7c4339dae534..a72fe4a369f4 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -171,22 +171,22 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
return relay_reserve(guc->log.relay.channel, 0);
 }
 
-static bool guc_check_log_buf_overflow(struct intel_guc *guc,
+static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
   enum guc_log_buffer_type type,
   unsigned int full_cnt)
 {
-   unsigned int prev_full_cnt = guc->log.prev_overflow_count[type];
+   unsigned int prev_full_cnt = log->stats[type].sampled_overflow;
bool overflow = false;
 
if (full_cnt != prev_full_cnt) {
overflow = true;
 
-   guc->log.prev_overflow_count[type] = full_cnt;
-   guc->log.total_overflow_count[type] += full_cnt - prev_full_cnt;
+   log->stats[type].overflow = full_cnt;
+   

[Intel-gfx] [PATCH 11/15] drm/i915/guc: Always print log stats in i915_guc_info when using GuC

[Michał Winiarski]

While some of the content in this file is related to GuC submission
only, that's not the case with log related statistics.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d7c0bf6facf6..d29bacb1f308 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2331,7 +2331,7 @@ static void i915_guc_log_info(struct seq_file *m,
 {
struct intel_guc *guc = _priv->guc;
 
-   seq_puts(m, "\nGuC logging stats:\n");
+   seq_puts(m, "GuC logging stats:\n");
 
seq_printf(m, "\tISR:   flush count %10u, overflow count %10u\n",
   guc->log.flush_count[GUC_ISR_LOG_BUFFER],
@@ -2379,14 +2379,19 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const struct intel_guc *guc = _priv->guc;
 
-   if (!USES_GUC_SUBMISSION(dev_priv))
+   if (!USES_GUC(dev_priv))
return -ENODEV;
 
+   i915_guc_log_info(m, dev_priv);
+
+   if (!USES_GUC_SUBMISSION(dev_priv))
+   return 0;
+
GEM_BUG_ON(!guc->execbuf_client);
 
-   seq_printf(m, "Doorbell map:\n");
+   seq_printf(m, "\nDoorbell map:\n");
seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
-   seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc->db_cacheline);
+   seq_printf(m, "Doorbell next cacheline: 0x%x\n", guc->db_cacheline);
 
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
@@ -2396,8 +2401,6 @@ static int i915_guc_info(struct seq_file *m, void *data)
i915_guc_client_info(m, dev_priv, guc->preempt_client);
}
 
-   i915_guc_log_info(m, dev_priv);
-
/* Add more as required ... */
 
return 0;
-- 
2.14.3

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

[Intel-gfx] [PATCH v2 10/15] drm/i915/guc: Get rid of GuC log runtime

[Michał Winiarski]

Runtime is not a very good name. Let's also move counting relay
overflows inside relay struct.

v2: Rename things rather than remove the struct (Chris)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  4 +--
 drivers/gpu/drm/i915/intel_guc.c | 12 +++
 drivers/gpu/drm/i915/intel_guc_log.c | 66 ++--
 drivers/gpu/drm/i915/intel_guc_log.h |  7 ++--
 4 files changed, 44 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f99fe9910634..d7c0bf6facf6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2348,8 +2348,8 @@ static void i915_guc_log_info(struct seq_file *m,
seq_printf(m, "\tTotal flush interrupt count: %u\n",
   guc->log.flush_interrupt_count);
 
-   seq_printf(m, "\tCapture miss count: %u\n",
-  guc->log.capture_miss_count);
+   seq_printf(m, "\tRelay full count: %u\n",
+  guc->log.relay.full_count);
 }
 
 static void i915_guc_client_info(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 0d92caf6a83f..cab158e42577 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -87,9 +87,9 @@ int intel_guc_init_wq(struct intel_guc *guc)
 * or scheduled later on resume. This way the handling of work
 * item can be kept same between system suspend & rpm suspend.
 */
-   guc->log.runtime.flush_wq = alloc_ordered_workqueue("i915-guc_log",
+   guc->log.relay.flush_wq = alloc_ordered_workqueue("i915-guc_log",
WQ_HIGHPRI | WQ_FREEZABLE);
-   if (!guc->log.runtime.flush_wq) {
+   if (!guc->log.relay.flush_wq) {
DRM_ERROR("Couldn't allocate workqueue for GuC log\n");
return -ENOMEM;
}
@@ -112,7 +112,7 @@ int intel_guc_init_wq(struct intel_guc *guc)
guc->preempt_wq = alloc_ordered_workqueue("i915-guc_preempt",
  WQ_HIGHPRI);
if (!guc->preempt_wq) {
-   destroy_workqueue(guc->log.runtime.flush_wq);
+   destroy_workqueue(guc->log.relay.flush_wq);
DRM_ERROR("Couldn't allocate workqueue for GuC "
  "preemption\n");
return -ENOMEM;
@@ -130,7 +130,7 @@ void intel_guc_fini_wq(struct intel_guc *guc)
USES_GUC_SUBMISSION(dev_priv))
destroy_workqueue(guc->preempt_wq);
 
-   destroy_workqueue(guc->log.runtime.flush_wq);
+   destroy_workqueue(guc->log.relay.flush_wq);
 }
 
 static int guc_shared_data_create(struct intel_guc *guc)
@@ -389,8 +389,8 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc)
 
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
-   queue_work(guc->log.runtime.flush_wq,
-  >log.runtime.flush_work);
+   queue_work(guc->log.relay.flush_wq,
+  >log.relay.flush_work);
 
guc->log.flush_interrupt_count++;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 92a7bf0fd729..7c4339dae534 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -151,10 +151,10 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
smp_wmb();
 
/* All data has been written, so now move the offset of sub buffer. */
-   relay_reserve(guc->log.runtime.relay_chan, 
guc->log.vma->obj->base.size);
+   relay_reserve(guc->log.relay.channel, guc->log.vma->obj->base.size);
 
/* Switch to the next sub buffer */
-   relay_flush(guc->log.runtime.relay_chan);
+   relay_flush(guc->log.relay.channel);
 }
 
 static void *guc_get_write_buffer(struct intel_guc *guc)
@@ -168,7 +168,7 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
 * done without using relay_reserve() along with relay_write(). So its
 * better to use relay_reserve() alone.
 */
-   return relay_reserve(guc->log.runtime.relay_chan, 0);
+   return relay_reserve(guc->log.relay.channel, 0);
 }
 
 static bool guc_check_log_buf_overflow(struct intel_guc *guc,
@@ -219,13 +219,13 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
void *src_data, *dst_data;
bool new_overflow;
 
-   mutex_lock(>log.runtime.lock);
+   mutex_lock(>log.relay.lock);
 
-   if (WARN_ON(!guc->log.runtime.buf_addr))
+   

[Intel-gfx] [PATCH v2 07/15] drm/i915/guc: Flush directly in log unregister

[Michał Winiarski]

Having both guc_flush_logs and guc_log_flush functions is confusing.
While we could just rename things, guc_flush_logs implementation is
quite simple. Let's get rid of it and move its content to unregister.

v2: s/dev_priv/i915 (Sagar)

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 34 ++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index ee0981f5a208..5ff4b510569a 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -443,25 +443,6 @@ static void guc_log_capture_logs(struct intel_guc *guc)
intel_runtime_pm_put(dev_priv);
 }
 
-static void guc_flush_logs(struct intel_guc *guc)
-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
-   /*
-* Before initiating the forceful flush, wait for any pending/ongoing
-* flush to complete otherwise forceful flush may not actually happen.
-*/
-   flush_work(>log.runtime.flush_work);
-
-   /* Ask GuC to update the log buffer state */
-   intel_runtime_pm_get(dev_priv);
-   guc_log_flush(guc);
-   intel_runtime_pm_put(dev_priv);
-
-   /* GuC would have updated log buffer by now, so capture it */
-   guc_log_capture_logs(guc);
-}
-
 int intel_guc_log_create(struct intel_guc *guc)
 {
struct i915_vma *vma;
@@ -630,15 +611,28 @@ int intel_guc_log_register(struct intel_guc *guc)
 
 void intel_guc_log_unregister(struct intel_guc *guc)
 {
+   struct drm_i915_private *i915 = guc_to_i915(guc);
+
guc_log_flush_irq_disable(guc);
 
+   /*
+* Before initiating the forceful flush, wait for any pending/ongoing
+* flush to complete otherwise forceful flush may not actually happen.
+*/
+   flush_work(>log.runtime.flush_work);
+
/*
 * Once logging is disabled, GuC won't generate logs & send an
 * interrupt. But there could be some data in the log buffer
 * which is yet to be captured. So request GuC to update the log
 * buffer state and then collect the left over logs.
 */
-   guc_flush_logs(guc);
+   intel_runtime_pm_get(i915);
+   guc_log_flush(guc);
+   intel_runtime_pm_put(i915);
+
+   /* GuC would have updated log buffer by now, so capture it */
+   guc_log_capture_logs(guc);
 
mutex_lock(>log.runtime.lock);
 
-- 
2.14.3

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

[Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

[Michał Winiarski]

Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.

v2: Don't touch guc_log_level on relay creation error, adjust locking
after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
Use struct_mutex rather than runtime.lock for set_log_level

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 56 ++
 drivers/gpu/drm/i915/i915_drv.c  |  4 --
 drivers/gpu/drm/i915/intel_guc_log.c | 77 +++-
 drivers/gpu/drm/i915/intel_guc_log.h |  9 +++--
 drivers/gpu/drm/i915/intel_uc.c  | 22 ---
 drivers/gpu/drm/i915/intel_uc.h  |  2 -
 6 files changed, 85 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index fa0755fe10d0..f99fe9910634 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2496,32 +2496,73 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
return 0;
 }
 
-static int i915_guc_log_control_get(void *data, u64 *val)
+static int i915_guc_log_level_get(void *data, u64 *val)
 {
struct drm_i915_private *dev_priv = data;
 
if (!USES_GUC(dev_priv))
return -ENODEV;
 
-   *val = intel_guc_log_control_get(_priv->guc);
+   *val = intel_guc_log_level_get(_priv->guc);
 
return 0;
 }
 
-static int i915_guc_log_control_set(void *data, u64 val)
+static int i915_guc_log_level_set(void *data, u64 val)
 {
struct drm_i915_private *dev_priv = data;
 
if (!USES_GUC(dev_priv))
return -ENODEV;
 
-   return intel_guc_log_control_set(_priv->guc, val);
+   return intel_guc_log_level_set(_priv->guc, val);
 }
 
-DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
-   i915_guc_log_control_get, i915_guc_log_control_set,
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_level_fops,
+   i915_guc_log_level_get, i915_guc_log_level_set,
"%lld\n");
 
+static int i915_guc_log_relay_open(struct inode *inode, struct file *file)
+{
+   struct drm_i915_private *dev_priv = inode->i_private;
+
+   if (!USES_GUC(dev_priv))
+   return -ENODEV;
+
+   file->private_data = _priv->guc;
+
+   return intel_guc_log_relay_open(_priv->guc);
+}
+
+static ssize_t
+i915_guc_log_relay_write(struct file *filp,
+const char __user *ubuf,
+size_t cnt,
+loff_t *ppos)
+{
+   struct intel_guc *guc = filp->private_data;
+
+   intel_guc_log_relay_flush(guc);
+
+   return cnt;
+}
+
+static int i915_guc_log_relay_release(struct inode *inode, struct file *file)
+{
+   struct drm_i915_private *dev_priv = inode->i_private;
+
+   intel_guc_log_relay_close(_priv->guc);
+
+   return 0;
+}
+
+static const struct file_operations i915_guc_log_relay_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_guc_log_relay_open,
+   .write = i915_guc_log_relay_write,
+   .release = i915_guc_log_relay_release,
+};
+
 static const char *psr2_live_status(u32 val)
 {
static const char * const live_status[] = {
@@ -4776,7 +4817,8 @@ static const struct i915_debugfs_files {
{"i915_dp_test_data", _displayport_test_data_fops},
{"i915_dp_test_type", _displayport_test_type_fops},
{"i915_dp_test_active", _displayport_test_active_fops},
-   {"i915_guc_log_control", _guc_log_control_fops},
+   {"i915_guc_log_level", _guc_log_level_fops},
+   {"i915_guc_log_relay", _guc_log_relay_fops},
{"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
{"i915_ipc_status", _ipc_status_fops},
{"i915_drrs_ctl", _drrs_ctl_fops}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 987c6770d1a6..0a238e3ed5b6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1240,9 +1240,6 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
 
-   /* Depends on debugfs having been initialized */
-   intel_uc_register(dev_priv);
-
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
} else
@@ -1300,7 +1297,6 @@ static void