Re: [Intel-gfx] [2/9] drm/doc: Polish kerneldoc for encoders

[Pandiyan, Dhinakaran]

I guess it's too late for review now. But, I want to send this anyway.

On Mon, 2016-08-29 at 10:27 +0200, Daniel Vetter wrote:
> - Move missing bits into struct drm_encoder docs.
> - Explain that encoders are 95% internal and only 5% uapi, and that in
>   general the uapi part is broken.
> - Remove verbose comments for functions not exposed to drivers.
> 
> v2: Review from Archit:
> - Appease checkpatch in the moved code.
> - Make it clearer that bridges are not exposed to userspace.
> 
> Reviewed-by: Archit Taneja 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms.rst | 46 
>  drivers/gpu/drm/drm_encoder.c | 48 ++---
>  include/drm/drm_encoder.h | 70 
> +++
>  3 files changed, 101 insertions(+), 63 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 7f788caebea3..47c2835b7c2d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -128,6 +128,12 @@ Connector Functions Reference
>  Encoder Abstraction
>  ===
>  
> +.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
> +   :doc: overview
> +
> +Encoder Functions Reference
> +---
> +
>  .. kernel-doc:: include/drm/drm_encoder.h
> :internal:
>  
> @@ -207,46 +213,6 @@ future); drivers that do not wish to provide special 
> handling for
>  primary planes may make use of the helper functions described in ? to
>  create and register a primary plane with standard capabilities.
>  
> -Encoders (:c:type:`struct drm_encoder `)
> --
> -
> -An encoder takes pixel data from a CRTC and converts it to a format
> -suitable for any attached connectors. On some devices, it may be
> -possible to have a CRTC send data to more than one encoder. In that
> -case, both encoders would receive data from the same scanout buffer,
> -resulting in a "cloned" display configuration across the connectors
> -attached to each encoder.
> -
> -Encoder Initialization
> -~~
> -
> -As for CRTCs, a KMS driver must create, initialize and register at least
> -one :c:type:`struct drm_encoder ` instance. The
> -instance is allocated and zeroed by the driver, possibly as part of a
> -larger structure.
> -
> -Drivers must initialize the :c:type:`struct drm_encoder
> -` possible_crtcs and possible_clones fields before
> -registering the encoder. Both fields are bitmasks of respectively the
> -CRTCs that the encoder can be connected to, and sibling encoders
> -candidate for cloning.
> -
> -After being initialized, the encoder must be registered with a call to
> -:c:func:`drm_encoder_init()`. The function takes a pointer to the
> -encoder functions and an encoder type. Supported types are
> -
> --  DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
> --  DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
> --  DRM_MODE_ENCODER_LVDS for display panels
> --  DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
> -   Component, SCART)
> --  DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
> -
> -Encoders must be attached to a CRTC to be used. DRM drivers leave
> -encoders unattached at initialization time. Applications (or the fbdev
> -compatibility layer when implemented) are responsible for attaching the
> -encoders they want to use to a CRTC.
> -
>  Cleanup
>  ---
>  
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index bce781b7bb5f..998a6743a586 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -26,6 +26,30 @@
>  
>  #include "drm_crtc_internal.h"
>  
> +/**
> + * DOC: overview
> + *
> + * Encoders represent the connecting element between the CRTC (as the overall
> + * pixel pipeline, represented by struct _crtc) and the connectors (as 
> the
> + * generic sink entity, represented by struct _connector). Encoders are

Doesn't really say what encoders actually do apart being in between crtc
and connector. This line could have been useful here - "An encoder takes
pixel data from a CRTC and converts it to a format suitable for any
attached connectors." 

> + * objects exposed to userspace, originally to allow userspace to infer 
> cloning
> + * and connector/CRTC restrictions. Unfortunately almost all drivers get this
> + * wrong, making the uabi pretty much useless. On top of that the exposed
> + * restrictions are too simple for todays hardware, and the recommend way to
> + * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the
> + * atomic IOCTL.
> + *
> + * Otherwise encoders aren't used in the uapi at all (any modeset request 
> from
> + * userspace directly connects a connector with a CRTC), drivers are 
> therefore
> + * free to use them however they wish. Modeset helper libraries make strong 
> use
> + * of encoders to facilitate 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Prep. for DP audio MST support (rev10)

[Patchwork]

== Series Details ==

Series: Prep. for DP audio MST support (rev10)
URL   : https://patchwork.freedesktop.org/series/11129/
State : failure

== Summary ==

Series 11129v10 Prep. for DP audio MST support
https://patchwork.freedesktop.org/api/1.0/series/11129/revisions/10/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-c:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-FAIL (fi-skl-6700k)
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-rte:
skip   -> PASS   (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:218  dwarn:1   dfail:1   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m 

Re: [Intel-gfx] [PATCH v2] drm/i915: Standardize port type for DVO encoders

[Pandiyan, Dhinakaran]

This version of the patch has been included in the series "Prep. for DP
audio MST support" since the helper is used by the patch that stores
port in struct intel_encoder.

On Wed, 2016-09-14 at 14:03 -0700, Dhinakaran Pandiyan wrote:
> Changing the return type from 'char' to 'enum port' in
> intel_dvo_port_name() makes it easier to later move the port information to
> intel_encoder. In addition, the port type conforms to what we have
> elsewhere.
> 
> Removing the last conditional that handles invalid port because dvo_reg is
> intialized to valid values for all DVO devices at definition.
> 
> v2: Changed return type, for real (Jani)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dvo.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 2e452c5..6489755 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -412,16 +412,14 @@ intel_dvo_get_current_mode(struct drm_connector 
> *connector)
>   return mode;
>  }
>  
> -static char intel_dvo_port_name(i915_reg_t dvo_reg)
> +static enum port intel_dvo_port(i915_reg_t dvo_reg)
>  {
>   if (i915_mmio_reg_equal(dvo_reg, DVOA))
> - return 'A';
> + return PORT_A;
>   else if (i915_mmio_reg_equal(dvo_reg, DVOB))
> - return 'B';
> - else if (i915_mmio_reg_equal(dvo_reg, DVOC))
> - return 'C';
> + return PORT_B;
>   else
> - return '?';
> + return PORT_C;
>  }
>  
>  void intel_dvo_init(struct drm_device *dev)
> @@ -464,6 +462,7 @@ void intel_dvo_init(struct drm_device *dev)
>   bool dvoinit;
>   enum pipe pipe;
>   uint32_t dpll[I915_MAX_PIPES];
> + enum port port;
>  
>   /* Allow the I2C driver info to specify the GPIO to be used in
>* special cases, but otherwise default to what's defined
> @@ -511,9 +510,10 @@ void intel_dvo_init(struct drm_device *dev)
>   if (!dvoinit)
>   continue;
>  
> + port = intel_dvo_port(dvo->dvo_reg);
>   drm_encoder_init(dev, _encoder->base,
>_dvo_enc_funcs, encoder_type,
> -  "DVO %c", intel_dvo_port_name(dvo->dvo_reg));
> +  "DVO %c", port_name(port));
>  
>   intel_encoder->type = INTEL_OUTPUT_DVO;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1);

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

[Intel-gfx] [PATCH v6 5/5] drm/i915: start adding dp mst audio

[Dhinakaran Pandiyan]

From: Libin Yang 

(This patch is developed by Dave Airlie  originally)

This patch adds support for DP MST audio in i915.

Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.

Another separated patches to support DP MST audio will be implemented
in audio driver.

v2:
Rebased.

Signed-off-by: Libin Yang 
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Lyude 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
 drivers/gpu/drm/i915/intel_ddi.c| 20 +++-
 drivers/gpu/drm/i915/intel_dp_mst.c | 18 ++
 drivers/gpu/drm/i915/intel_drv.h|  2 ++
 4 files changed, 53 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 64702cc..fe1a158 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2862,6 +2862,20 @@ static void intel_dp_info(struct seq_file *m,
intel_panel_info(m, _connector->panel);
 }
 
+static void intel_dp_mst_info(struct seq_file *m,
+ struct intel_connector *intel_connector)
+{
+   struct intel_encoder *intel_encoder = intel_connector->encoder;
+   struct intel_dp_mst_encoder *intel_mst =
+   enc_to_mst(_encoder->base);
+   struct intel_digital_port *intel_dig_port = intel_mst->primary;
+   struct intel_dp *intel_dp = _dig_port->dp;
+   bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr,
+   intel_connector->port);
+
+   seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
+}
+
 static void intel_hdmi_info(struct seq_file *m,
struct intel_connector *intel_connector)
 {
@@ -2904,7 +2918,10 @@ static void intel_connector_info(struct seq_file *m,
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DisplayPort:
case DRM_MODE_CONNECTOR_eDP:
-   intel_dp_info(m, intel_connector);
+   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
+   intel_dp_mst_info(m, intel_connector);
+   else
+   intel_dp_info(m, intel_connector);
break;
case DRM_MODE_CONNECTOR_LVDS:
if (intel_encoder->type == INTEL_OUTPUT_LVDS)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 672f71c..467bef5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2230,6 +2230,19 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
*intel_dp)
udelay(600);
 }
 
+bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
+struct intel_crtc *intel_crtc)
+{
+   u32 temp;
+
+   if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
+   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
+   return true;
+   }
+   return false;
+}
+
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config)
 {
@@ -2295,11 +2308,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}
 
-   if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
-   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
-   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
-   pipe_config->has_audio = true;
-   }
+   pipe_config->has_audio =
+   intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
 
if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp &&
pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..2fc9f81 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -37,6 +37,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(>base);
struct intel_digital_port *intel_dig_port = intel_mst->primary;
struct intel_dp *intel_dp = _dig_port->dp;
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
struct drm_atomic_state *state;
int bpp;
int lane_count, slots;
@@ -59,6 +61,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
 
state = pipe_config->base.state;
 
+   if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
+   pipe_config->has_audio = true;
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
 

[Intel-gfx] [PATCH v6 4/5] drm/i915: Move audio_connector to intel_encoder

[Dhinakaran Pandiyan]

With DP MST, a digital_port can carry more than one audio stream. Hence,
more than one audio_connector needs to be attached to intel_digital_port in
such cases. However, each stream is associated with an unique encoder. So,
instead of creating an array of audio_connectors per port, move
audio_connector from struct intel_digital_port to struct intel_encoder.
This also simplifies access to the right audio_connector from codec
functions in intel_audio.c that receive intel_encoder.

v2: Removed locals that are not needed anymore.

v3: No code change except for minor change in context.

Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Lyude 
---
 drivers/gpu/drm/i915/intel_audio.c | 12 
 drivers/gpu/drm/i915/intel_drv.h   |  4 ++--
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 8f5c685..40fbdd8 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -490,7 +490,6 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
struct drm_connector *connector;
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
-   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
enum port port = intel_encoder->port;
 
connector = drm_select_eld(encoder);
@@ -515,7 +514,7 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
 adjusted_mode);
 
mutex_lock(_priv->av_mutex);
-   intel_dig_port->audio_connector = connector;
+   intel_encoder->audio_connector = connector;
/* referred in audio callbacks */
dev_priv->dig_port_map[port] = intel_encoder;
mutex_unlock(_priv->av_mutex);
@@ -536,14 +535,13 @@ void intel_audio_codec_disable(struct intel_encoder 
*intel_encoder)
struct drm_encoder *encoder = _encoder->base;
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
-   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
enum port port = intel_encoder->port;
 
if (dev_priv->display.audio_codec_disable)
dev_priv->display.audio_codec_disable(intel_encoder);
 
mutex_lock(_priv->av_mutex);
-   intel_dig_port->audio_connector = NULL;
+   intel_encoder->audio_connector = NULL;
dev_priv->dig_port_map[port] = NULL;
mutex_unlock(_priv->av_mutex);
 
@@ -704,7 +702,6 @@ static int i915_audio_component_get_eld(struct device 
*kdev, int port,
 {
struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
struct intel_encoder *intel_encoder;
-   struct intel_digital_port *intel_dig_port;
const u8 *eld;
int ret = -EINVAL;
 
@@ -713,10 +710,9 @@ static int i915_audio_component_get_eld(struct device 
*kdev, int port,
/* intel_encoder might be NULL for DP MST */
if (intel_encoder) {
ret = 0;
-   intel_dig_port = enc_to_dig_port(_encoder->base);
-   *enabled = intel_dig_port->audio_connector != NULL;
+   *enabled = intel_encoder->audio_connector != NULL;
if (*enabled) {
-   eld = intel_dig_port->audio_connector->eld;
+   eld = intel_encoder->audio_connector->eld;
ret = drm_eld_size(eld);
memcpy(buf, eld, min(max_bytes, ret));
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a26f08b..89b7064 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -244,6 +244,8 @@ struct intel_encoder {
void (*suspend)(struct intel_encoder *);
int crtc_mask;
enum hpd_pin hpd_pin;
+   /* for communication with audio component; protected by av_mutex */
+   const struct drm_connector *audio_connector;
 };
 
 struct intel_panel {
@@ -955,8 +957,6 @@ struct intel_digital_port {
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
uint8_t max_lanes;
-   /* for communication with audio component; protected by av_mutex */
-   const struct drm_connector *audio_connector;
 };
 
 struct intel_dp_mst_encoder {
-- 
2.5.0

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

[Intel-gfx] [PATCH v6 1/5] drm/i915: Standardize port type for DVO encoders

[Dhinakaran Pandiyan]

Changing the return type from 'char' to 'enum port' in
intel_dvo_port_name() makes it easier to later move the port information to
intel_encoder. In addition, the port type conforms to what we have
elsewhere.

Removing the last conditional that handles invalid port because dvo_reg is
intialized to valid values for all DVO devices at definition.

v2: Changed return type, for real (Jani)

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dvo.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 2e452c5..6489755 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -412,16 +412,14 @@ intel_dvo_get_current_mode(struct drm_connector 
*connector)
return mode;
 }
 
-static char intel_dvo_port_name(i915_reg_t dvo_reg)
+static enum port intel_dvo_port(i915_reg_t dvo_reg)
 {
if (i915_mmio_reg_equal(dvo_reg, DVOA))
-   return 'A';
+   return PORT_A;
else if (i915_mmio_reg_equal(dvo_reg, DVOB))
-   return 'B';
-   else if (i915_mmio_reg_equal(dvo_reg, DVOC))
-   return 'C';
+   return PORT_B;
else
-   return '?';
+   return PORT_C;
 }
 
 void intel_dvo_init(struct drm_device *dev)
@@ -464,6 +462,7 @@ void intel_dvo_init(struct drm_device *dev)
bool dvoinit;
enum pipe pipe;
uint32_t dpll[I915_MAX_PIPES];
+   enum port port;
 
/* Allow the I2C driver info to specify the GPIO to be used in
 * special cases, but otherwise default to what's defined
@@ -511,9 +510,10 @@ void intel_dvo_init(struct drm_device *dev)
if (!dvoinit)
continue;
 
+   port = intel_dvo_port(dvo->dvo_reg);
drm_encoder_init(dev, _encoder->base,
 _dvo_enc_funcs, encoder_type,
-"DVO %c", intel_dvo_port_name(dvo->dvo_reg));
+"DVO %c", port_name(port));
 
intel_encoder->type = INTEL_OUTPUT_DVO;
intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
-- 
2.5.0

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

[Intel-gfx] [PATCH v6 3/5] drm/i915: Switch to using port stored in intel_encoder

[Dhinakaran Pandiyan]

Now that we have the port enum stored in intel_encoder, use that instead of
dereferencing intel_dig_port. Saves us a few locals.

struct intel_encoder variables have been renamed to be consistent and
convey type information.

v2:
Fix incorrect 'enum port' member names - s/attached_port/port

Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Lyude 
---
 drivers/gpu/drm/i915/intel_audio.c | 32 ++--
 1 file changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 6c70a5b..8f5c685 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -276,17 +276,15 @@ static void hsw_audio_codec_disable(struct intel_encoder 
*encoder)
 }
 
 static void hsw_audio_codec_enable(struct drm_connector *connector,
-  struct intel_encoder *encoder,
+  struct intel_encoder *intel_encoder,
   const struct drm_display_mode *adjusted_mode)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
enum pipe pipe = intel_crtc->pipe;
+   enum port port = intel_encoder->port;
struct i915_audio_component *acomp = dev_priv->audio_component;
const uint8_t *eld = connector->eld;
-   struct intel_digital_port *intel_dig_port =
-   enc_to_dig_port(>base);
-   enum port port = intel_dig_port->port;
uint32_t tmp;
int len, i;
int n, rate;
@@ -355,12 +353,12 @@ static void hsw_audio_codec_enable(struct drm_connector 
*connector,
mutex_unlock(_priv->av_mutex);
 }
 
-static void ilk_audio_codec_disable(struct intel_encoder *encoder)
+static void ilk_audio_codec_disable(struct intel_encoder *intel_encoder)
 {
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
-   enum port port = enc_to_dig_port(>base)->port;
+   struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
enum pipe pipe = intel_crtc->pipe;
+   enum port port = intel_encoder->port;
uint32_t tmp, eldv;
i915_reg_t aud_config, aud_cntrl_st2;
 
@@ -400,13 +398,13 @@ static void ilk_audio_codec_disable(struct intel_encoder 
*encoder)
 }
 
 static void ilk_audio_codec_enable(struct drm_connector *connector,
-  struct intel_encoder *encoder,
+  struct intel_encoder *intel_encoder,
   const struct drm_display_mode *adjusted_mode)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
-   enum port port = enc_to_dig_port(>base)->port;
+   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
enum pipe pipe = intel_crtc->pipe;
+   enum port port = intel_encoder->port;
uint8_t *eld = connector->eld;
uint32_t tmp, eldv;
int len, i;
@@ -490,11 +488,10 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
struct drm_connector *connector;
-   struct drm_device *dev = encoder->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
-   enum port port = intel_dig_port->port;
+   enum port port = intel_encoder->port;
 
connector = drm_select_eld(encoder);
if (!connector)
@@ -537,11 +534,10 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
 void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
 {
struct drm_encoder *encoder = _encoder->base;
-   struct drm_device *dev = encoder->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
-   enum port port = intel_dig_port->port;
+   enum port port = intel_encoder->port;
 
if (dev_priv->display.audio_codec_disable)
dev_priv->display.audio_codec_disable(intel_encoder);
-- 
2.5.0

___
Intel-gfx mailing list

[Intel-gfx] [PATCH v6 2/5] drm/i915: Store port enum in intel_encoder

[Dhinakaran Pandiyan]

Storing the port enum in intel_encoder makes it convenient to know the
port attached to an encoder. Moving the port information up from
intel_digital_port to intel_encoder avoids unecessary intel_digital_port
access and handles MST encoders cleanly without requiring conditional
checks for them (thanks danvet).

v2:
Renamed the port enum member from 'attached_port' to 'port' (danvet)
Fixed missing initialization of port in intel_sdvo.c (danvet)

v3:
Fixed missing initialization of port in intel_crt.c (Ville)

v4:
Storing port for DVO encoders too.

Signed-off-by: Dhinakaran Pandiyan 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/i915/intel_crt.c| 2 ++
 drivers/gpu/drm/i915/intel_ddi.c| 1 +
 drivers/gpu/drm/i915/intel_dp.c | 1 +
 drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_dsi.c| 1 +
 drivers/gpu/drm/i915/intel_dvo.c| 2 ++
 drivers/gpu/drm/i915/intel_hdmi.c   | 1 +
 drivers/gpu/drm/i915/intel_lvds.c   | 3 ++-
 drivers/gpu/drm/i915/intel_sdvo.c   | 1 +
 drivers/gpu/drm/i915/intel_tv.c | 2 ++
 12 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..3a2c9e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -185,6 +185,7 @@ enum plane {
 #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 'A')
 
 enum port {
+   PORT_NONE = -1,
PORT_A = 0,
PORT_B,
PORT_C,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index dfbcf16..88ebbdd 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -917,10 +917,12 @@ void intel_crt_init(struct drm_device *dev)
if (I915_HAS_HOTPLUG(dev))
crt->base.hpd_pin = HPD_CRT;
if (HAS_DDI(dev)) {
+   crt->base.port = PORT_E;
crt->base.get_config = hsw_crt_get_config;
crt->base.get_hw_state = intel_ddi_get_hw_state;
crt->base.post_disable = hsw_post_disable_crt;
} else {
+   crt->base.port = PORT_NONE;
crt->base.get_config = intel_crt_get_config;
crt->base.get_hw_state = intel_crt_get_hw_state;
}
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8280548..672f71c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2523,6 +2523,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_dig_port->max_lanes = max_lanes;
 
intel_encoder->type = INTEL_OUTPUT_UNKNOWN;
+   intel_encoder->port = port;
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 75ac62f..e0dda78 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5752,6 +5752,7 @@ bool intel_dp_init(struct drm_device *dev,
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
}
intel_encoder->cloneable = 0;
+   intel_encoder->port = port;
 
intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
dev_priv->hotplug.irq_port[port] = intel_dig_port;
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 54a9d76..3ffbd69 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -523,6 +523,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port 
*intel_dig_port, enum
 DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe));
 
intel_encoder->type = INTEL_OUTPUT_DP_MST;
+   intel_encoder->port = intel_dig_port->port;
intel_encoder->crtc_mask = 0x7;
intel_encoder->cloneable = 0;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index abe7a4d..a26f08b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -202,6 +202,7 @@ struct intel_encoder {
struct drm_encoder base;
 
enum intel_output_type type;
+   enum port port;
unsigned int cloneable;
void (*hot_plug)(struct intel_encoder *);
bool (*compute_config)(struct intel_encoder *,
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b2e3d3a..727adaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1488,6 +1488,7 @@ void intel_dsi_init(struct drm_device *dev)
 
intel_connector->get_hw_state = intel_connector_get_hw_state;
 
+   intel_encoder->port = port;
/*
 * On BYT/CHV, pipe 

[Intel-gfx] [PATCH v6 0/5] Prep. for DP audio MST support

[Dhinakaran Pandiyan]

This series lays the groundwork for more DP MST audio work that will
follow.

v2:
Different solution replacing the enc_to_dig_port() fix (Ville, Lyude).
No changes to MST audio enabling and move audio_connector patches.
Reordered the patches (Lyude)

v3:
Different solution to get port from encoder (danvet).
Removed locals that are not needed any more.
Minor variable renaming clean up.
Rebased on dinq.
Retained r-b for "start adding dp mst audio" as it does not change.

v4:
Fixed missing port initialization in intel_sdvo.c
Renamed the port enum member from 'attached_port' to 'port'
Fixed commit message typos.

v5:
Really renamed the port enum member from 'attached_port' to 'port'
Rebased on atomic changes.

v6:
Modified the return type for a helper that returns port in intel_dvo.c

Dhinakaran Pandiyan (4):
  drm/i915: Standardize port type for DVO encoders
  drm/i915: Store port enum in intel_encoder
  drm/i915: Switch to using port stored in intel_encoder
  drm/i915: Move audio_connector to intel_encoder

Libin Yang (1):
  drm/i915: start adding dp mst audio

 drivers/gpu/drm/i915/i915_debugfs.c | 19 +++-
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_audio.c  | 44 +++--
 drivers/gpu/drm/i915/intel_crt.c|  2 ++
 drivers/gpu/drm/i915/intel_ddi.c| 21 +-
 drivers/gpu/drm/i915/intel_dp.c |  1 +
 drivers/gpu/drm/i915/intel_dp_mst.c | 19 
 drivers/gpu/drm/i915/intel_drv.h|  7 --
 drivers/gpu/drm/i915/intel_dsi.c|  1 +
 drivers/gpu/drm/i915/intel_dvo.c| 16 --
 drivers/gpu/drm/i915/intel_hdmi.c   |  1 +
 drivers/gpu/drm/i915/intel_lvds.c   |  3 ++-
 drivers/gpu/drm/i915/intel_sdvo.c   |  1 +
 drivers/gpu/drm/i915/intel_tv.c |  2 ++
 14 files changed, 96 insertions(+), 42 deletions(-)

-- 
2.5.0

___
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: Standardize port type for DVO encoders (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Standardize port type for DVO encoders (rev2)
URL   : https://patchwork.freedesktop.org/series/12418/
State : failure

== Summary ==

Series 12418v2 drm/i915: Standardize port type for DVO encoders
https://patchwork.freedesktop.org/api/1.0/series/12418/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-c:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-rte:
skip   -> PASS   (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  

[Intel-gfx] [PATCH v2] drm/i915: Standardize port type for DVO encoders

[Dhinakaran Pandiyan]

Changing the return type from 'char' to 'enum port' in
intel_dvo_port_name() makes it easier to later move the port information to
intel_encoder. In addition, the port type conforms to what we have
elsewhere.

Removing the last conditional that handles invalid port because dvo_reg is
intialized to valid values for all DVO devices at definition.

v2: Changed return type, for real (Jani)

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dvo.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 2e452c5..6489755 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -412,16 +412,14 @@ intel_dvo_get_current_mode(struct drm_connector 
*connector)
return mode;
 }
 
-static char intel_dvo_port_name(i915_reg_t dvo_reg)
+static enum port intel_dvo_port(i915_reg_t dvo_reg)
 {
if (i915_mmio_reg_equal(dvo_reg, DVOA))
-   return 'A';
+   return PORT_A;
else if (i915_mmio_reg_equal(dvo_reg, DVOB))
-   return 'B';
-   else if (i915_mmio_reg_equal(dvo_reg, DVOC))
-   return 'C';
+   return PORT_B;
else
-   return '?';
+   return PORT_C;
 }
 
 void intel_dvo_init(struct drm_device *dev)
@@ -464,6 +462,7 @@ void intel_dvo_init(struct drm_device *dev)
bool dvoinit;
enum pipe pipe;
uint32_t dpll[I915_MAX_PIPES];
+   enum port port;
 
/* Allow the I2C driver info to specify the GPIO to be used in
 * special cases, but otherwise default to what's defined
@@ -511,9 +510,10 @@ void intel_dvo_init(struct drm_device *dev)
if (!dvoinit)
continue;
 
+   port = intel_dvo_port(dvo->dvo_reg);
drm_encoder_init(dev, _encoder->base,
 _dvo_enc_funcs, encoder_type,
-"DVO %c", intel_dvo_port_name(dvo->dvo_reg));
+"DVO %c", port_name(port));
 
intel_encoder->type = INTEL_OUTPUT_DVO;
intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

[Paulo Zanoni]

Em Qua, 2016-09-14 às 13:10 +0100, Dave Gordon escreveu:
> Commentary from Chris Wilson's original version:
> 
> > 
> > I was looking at some wait_for() timeouts on a slow system, with
> > lots of
> > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> > mishandling the timeout, I tried to ensure that we loop at least
> > once
> > after first testing COND. However, the double test of COND either
> > side
> > of the timeout check makes that unlikely. But we can do an
> > equivalent
> > loop, that keeps the COND check after testing for timeout (required
> > so
> > that we are not preempted between testing COND and then testing for
> > a
> > timeout) without expanding COND twice.
> > 
> > The advantage of only expanding COND once is a dramatic reduction
> > in
> > code size:
> > 
> >    text    data bss dec hex
> >    1308733     5184    1152 1315069  141
> > 0fd before
> >    1305341     5184    1152 1311677  140
> > 3bd after
> 
> but it turned out that due to a missing iniitialiser, gcc had "gone
> wild trimming undefined code" :( This version acheives a rather more
> modest (but still worthwhile) gain of ~550 bytes.
> 
> Signed-off-by: Dave Gordon 
> Original-idea-by: Chris Wilson 
> Cc: Chris Wilson 
> Cc: Zanoni, Paulo R 

Reviewed-by: Paulo Zanoni 

> ---
>  drivers/gpu/drm/i915/intel_drv.h | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index abe7a4d..8fd16ad 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -52,11 +52,15 @@
>   */
>  #define _wait_for(COND, US, W) ({ \
>   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) +
> 1;\
> - int ret__ = 0;  
>   \
> - while (!(COND)) {   
> \
> - if (time_after(jiffies, timeout__)) {   
>   \
> - if (!(COND))
> \
> - ret__ = -ETIMEDOUT; 
> \
> + int ret__;  
> \
> + for (;;) {  
> \
> + bool expired__ = time_after(jiffies, timeout__);
> \
> + if (COND) { 
> \
> + ret__ = 0;  
> \
> + break;  
>   \
> + }   
> \
> + if (expired__) {
> \
> + ret__ = -ETIMEDOUT; 
> \
>   break;  
>   \
>   }   
> \
>   if ((W) && drm_can_sleep()) {   
>   \
___
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: Queue page flip work with high priority (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Queue page flip work with high priority (rev2)
URL   : https://patchwork.freedesktop.org/series/12336/
State : failure

== Summary ==

Series 12336v2 drm/i915: Queue page flip work with high priority
https://patchwork.freedesktop.org/api/1.0/series/12336/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-c:
pass   -> DMESG-WARN (fi-skl-6700k)
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (fi-hsw-4770r)
skip   -> PASS   (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-rte:
skip   -> PASS   (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:221  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:218  dwarn:2   dfail:0   fail:0   skip:24 

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

[Chris Wilson]

On Wed, Sep 14, 2016 at 12:44:04PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > -static inline bool
> > -i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
> > -     int engine)
> > -{
> > -   return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
> > +   return obj->active_count;
> 
> our type is bool, so !!obj->active_count;

That's the beauty of using bool, !! is implied on the (bool)integer
conversion.
-Chris

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

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

[Chris Wilson]

On Wed, Sep 14, 2016 at 02:30:20PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/09/2016 07:52, Chris Wilson wrote:
> >In the next patch, we will use deferred request emission. That requires
> >reserving sufficient space in the ringbuffer to emit the request, which
> >first requires us to know how large the request is.
> >
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_gem_request.c |  1 +
> >  drivers/gpu/drm/i915/intel_lrc.c|  6 ++
> >  drivers/gpu/drm/i915/intel_ringbuffer.c | 29 +++--
> >  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
> >  4 files changed, 35 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index ebc2feba3e50..9a735e2d5aea 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >@@ -425,6 +425,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
> >  * away, e.g. because a GPU scheduler has deferred it.
> >  */
> > req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
> >+GEM_BUG_ON(req->reserved_space < engine->emit_request_sz);
> > if (i915.enable_execlists)
> > ret = intel_logical_ring_alloc_request_extras(req);
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 00fcf36ba919..7e944a0acc10 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -1572,6 +1572,8 @@ static int gen8_emit_request(struct 
> >drm_i915_gem_request *request)
> > return intel_logical_ring_advance(request);
> >  }
> >+static const int gen8_emit_request_sz = 6 + WA_TAIL_DWORDS;
> >+
> >  static int gen8_emit_request_render(struct drm_i915_gem_request *request)
> >  {
> > struct intel_ring *ring = request->ring;
> >@@ -1603,6 +1605,8 @@ static int gen8_emit_request_render(struct 
> >drm_i915_gem_request *request)
> > return intel_logical_ring_advance(request);
> >  }
> >+static const int gen8_emit_request_render_sz = 8 + WA_TAIL_DWORDS;
> >+
> >  static int gen8_init_rcs_context(struct drm_i915_gem_request *req)
> >  {
> > int ret;
> >@@ -1677,6 +1681,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
> >*engine)
> > engine->reset_hw = reset_common_ring;
> > engine->emit_flush = gen8_emit_flush;
> > engine->emit_request = gen8_emit_request;
> >+engine->emit_request_sz = gen8_emit_request_sz;
> > engine->submit_request = execlists_submit_request;
> > engine->irq_enable = gen8_logical_ring_enable_irq;
> >@@ -1799,6 +1804,7 @@ int logical_render_ring_init(struct intel_engine_cs 
> >*engine)
> > engine->init_context = gen8_init_rcs_context;
> > engine->emit_flush = gen8_emit_flush_render;
> > engine->emit_request = gen8_emit_request_render;
> >+engine->emit_request_sz = gen8_emit_request_render_sz;
> > ret = intel_engine_create_scratch(engine, 4096);
> > if (ret)
> >diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> >b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >index 597e35c9b699..c8c9ad40fd93 100644
> >--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >@@ -1405,6 +1405,8 @@ static int i9xx_emit_request(struct 
> >drm_i915_gem_request *req)
> > return 0;
> >  }
> >+static const int i9xx_emit_request_sz = 4;
> >+
> >  /**
> >   * gen6_sema_emit_request - Update the semaphore mailbox registers
> >   *
> >@@ -1458,6 +1460,8 @@ static int gen8_render_emit_request(struct 
> >drm_i915_gem_request *req)
> > return 0;
> >  }
> >+static const int gen8_render_emit_request_sz = 8;
> >+
> >  /**
> >   * intel_ring_sync - sync the waiter to the signaller on seqno
> >   *
> >@@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct 
> >drm_i915_private *dev_priv,
> > engine->reset_hw = reset_ring_common;
> > engine->emit_request = i9xx_emit_request;
> >-if (i915.semaphores)
> >+engine->emit_request_sz = i9xx_emit_request_sz;
> >+if (i915.semaphores) {
> >+int num_rings;
> >+
> > engine->emit_request = gen6_sema_emit_request;
> >+
> >+num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1;
> 
> You can use INTEL_INFO(dev_priv)->num_rings instead of hweight32.

I thought info->num_rings was set afterwards? (And num_rings may be an
overestimate here :(
-Chris

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

[Intel-gfx] [PATCH v2] drm/i915: Queue page flip work via a low latency, unbound workqueue

[Imre Deak]

While user space has control over the scheduling priority of its page
flipping thread, the corresponding work the driver schedules for MMIO
flips always runs from the generic system workqueue which has some
scheduling overhead due it being CPU bound. This would hinder an
application that wants more stringent guarantees over flip timing (to
avoid missing a flip at the next frame count).

Fix this by scheduling the work from a dedicated, unbound workqueue
which provides for minimal scheduling latency.

v2:
- Use an unbound workqueue instead of a high-prio one. (Tvrtko, Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97775
Testcase: igt/kms_cursor_legacy
CC: Chris Wilson 
CC: Maarten Lankhorst 
CC: Tvrtko Ursulin 
Signed-off-by: Imre Deak 
Reviewed-by: Tvrtko Ursulin  (v1)
---
 drivers/gpu/drm/i915/i915_drv.c  | 7 +++
 drivers/gpu/drm/i915/i915_drv.h  | 4 
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..b5445a1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -755,8 +755,14 @@ static int i915_workqueues_init(struct drm_i915_private 
*dev_priv)
if (dev_priv->hotplug.dp_wq == NULL)
goto out_free_wq;
 
+   dev_priv->flip_wq = alloc_workqueue("i915-flip", WQ_UNBOUND, 0);
+   if (dev_priv->flip_wq == NULL)
+   goto out_free_dp_wq;
+
return 0;
 
+out_free_dp_wq:
+   destroy_workqueue(dev_priv->hotplug.dp_wq);
 out_free_wq:
destroy_workqueue(dev_priv->wq);
 out_err:
@@ -767,6 +773,7 @@ out_err:
 
 static void i915_workqueues_cleanup(struct drm_i915_private *dev_priv)
 {
+   destroy_workqueue(dev_priv->flip_wq);
destroy_workqueue(dev_priv->hotplug.dp_wq);
destroy_workqueue(dev_priv->wq);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d60ade9..cdd835b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1859,6 +1859,10 @@ struct drm_i915_private {
 * result in deadlocks.
 */
struct workqueue_struct *wq;
+   /**
+* flip_wq - Low latency, unordered flip workqueue.
+*/
+   struct workqueue_struct *flip_wq;
 
/* Display functions */
struct drm_i915_display_funcs display;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7bb7874..7728c18 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12266,7 +12266,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
 
work->flip_queued_req = i915_gem_active_get(>last_write,

>base.dev->struct_mutex);
-   schedule_work(>mmio_work);
+   queue_work(dev_priv->flip_wq, >mmio_work);
} else {
request = i915_gem_request_alloc(engine, engine->last_context);
if (IS_ERR(request)) {
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

[Dave Gordon]

On 14/09/16 16:22, Tvrtko Ursulin wrote:


On 12/09/2016 21:19, Dave Gordon wrote:

Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 63
+++---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
  3 files changed, 34 insertions(+), 33 deletions(-)



[snip]


  int i915_guc_submission_init(struct drm_i915_private *dev_priv)
  {
+const size_t ctxsize = sizeof(struct guc_context_desc);
+const size_t poolsize = GUC_MAX_GPU_CONTEXTS * ctxsize;
+const size_t gemsize = round_up(poolsize, PAGE_SIZE);
  struct intel_guc *guc = _priv->guc;
  struct i915_vma *vma;
-u32 size;
/* Wipe bitmap & delete client in case of reinitialisation */
  bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
@@ -985,15 +987,14 @@ int i915_guc_submission_init(struct
drm_i915_private *dev_priv)
  if (guc->ctx_pool_vma)
  return 0; /* already allocated */
  -size = PAGE_ALIGN(GUC_MAX_GPU_CONTEXTS*sizeof(struct
guc_context_desc));
-vma = guc_allocate_vma(guc, size);
+vma = guc_allocate_vma(guc, gemsize);


PAGE_ALIGN lost - lower layers do that for us? I don't have easy access
to the tree at the moment to check and I kind of can't remember right now.


PAGE_ALIGN here is replaced by using round_up(..., PAGE_SIZE) at the 
point where the constant is defined a few lines above. I think 
round_up() is clearer, because "align" could equally well mean round 
down. Anyway "align" (up or down) is something you do to addresses or 
offsets, not sizes.


.Dave.


  if (IS_ERR(vma))
  return PTR_ERR(vma);
guc->ctx_pool_vma = vma;
  ida_init(>ctx_ids);
-guc_create_log(guc);
-guc_create_ads(guc);
+guc_log_create(guc);
+guc_addon_create(guc);
return 0;
  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 4678459..b1ba869 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -159,7 +159,7 @@ extern int intel_guc_resume(struct drm_device *dev);
  /* i915_guc_submission.c */
  int i915_guc_submission_init(struct drm_i915_private *dev_priv);
  int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
-int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
+int i915_guc_wq_reserve(struct drm_i915_gem_request *rq);
  void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
  void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
  diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 16d7cdd..25114336 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -627,7 +627,7 @@ int intel_logical_ring_alloc_request_extras(struct
drm_i915_gem_request *request
   * going any further, as the i915_add_request() call
   * later on mustn't fail ...
   */
-ret = i915_guc_wq_check_space(request);
+ret = i915_guc_wq_reserve(request);
  if (ret)
  return ret;
  }


Name changes make sense. Just the PAGE_ALIGN question above.

Regards,

Tvrtko


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev4)

[Patchwork]

== Series Details ==

Series: Enable i915 perf stream for Haswell OA unit (rev4)
URL   : https://patchwork.freedesktop.org/series/11295/
State : failure

== Summary ==

Series 11295v4 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/11295/revisions/4/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-6260u)
Test gem_exec_parse:
Subgroup basic-rejected:
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-hsw-4770k)
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-hsw-4770r)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-c:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-rte:
skip   -> PASS   (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:210  dwarn:1   dfail:0   fail:2   skip:31 
fi-hsw-4770k total:244  pass:225  dwarn:0   dfail:0   fail:1   skip:18 
fi-hsw-4770r total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:218  dwarn:0   dfail:0   fail:1   skip:25 
fi-ivb-3770  total:244  pass:206  dwarn:0   dfail:0   fail:1   skip:37 
fi-skl-6260u total:244  pass:229  

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Combine seqno + tracking into a global timeline struct

[Joonas Lahtinen]

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
>  i915_next_seqno_get(void *data, u64 *val)
>  {
>   struct drm_i915_private *dev_priv = data;
> - int ret;
> -
> - ret = mutex_lock_interruptible(_priv->drm.struct_mutex);
> - if (ret)
> - return ret;
> -
> - *val = dev_priv->next_seqno;
> - mutex_unlock(_priv->drm.struct_mutex);
>  
> + *val = dev_priv->gt.global_timeline.next_seqno;

This should be marked as unlocked access somehow.

> +static int wait_for_timeline(struct i915_gem_timeline *tl, unsigned int 
> flags)
>  {
> - struct intel_engine_cs *engine;
> - int ret;
> + int ret, i;
>  
> - for_each_engine(engine, dev_priv) {
> - if (engine->last_context == NULL)
> - continue;
> + for (i = 0; i < ARRAY_SIZE(tl->engine); i++) {

Lets untangle them headers and not manually roll these loops?

> @@ -4475,13 +4489,24 @@ i915_gem_load_init(struct drm_device *dev)
>     SLAB_RECLAIM_ACCOUNT |
>     SLAB_DESTROY_BY_RCU,
>     NULL);
> + if (!dev_priv->requests) {
> + err = -ENOMEM;
> + goto err_vmas;
> + }
> +
> + mutex_lock(_priv->drm.struct_mutex);

Hngg, locking in initializer, maybe we should have our own variant for
assert_held_struct_mutex (or as you suggested have no struct_mutex!)

> + INIT_LIST_HEAD(_priv->gt.timelines);
> + err = i915_gem_timeline_init(dev_priv,
> +  _priv->gt.global_timeline,
> +  "[execution]");

"[global]" would not be clearer to give better mapping between
code/debug?

> 
> -static int i915_gem_get_seqno(struct drm_i915_private *dev_priv, u32 *seqno)
> +static int i915_gem_get_global_seqno(struct drm_i915_private *dev_priv,
> +  u32 *seqno)
>  {
> + struct i915_gem_timeline *tl = _priv->gt.global_timeline;

*gtl? to indicate the global one.

> +struct intel_timeline {
> + u64 fence_context;
> + u32 last_submitted_seqno;
> +
> + /**
> +  * List of breadcrumbs associated with GPU requests currently
> +  * outstanding.
> +  */
> + struct list_head requests;
> +
> + /* An RCU guarded pointer to the last request. No reference is
> +  * held to the request, users must carefully acquire a reference to
> +  * the request using i915_gem_active_get_request_rcu(), or hold the
> +  * struct_mutex.
> +  */
> + struct i915_gem_active last_request;

RCU guarded pointer sounds off when we're speaking of an object.
 
> 
> @@ -217,8 +217,7 @@ void intel_engine_init_hangcheck(struct intel_engine_cs 
> *engine)
>  
>  static void intel_engine_init_requests(struct intel_engine_cs *engine)
>  {
> - init_request_active(>last_request, NULL);
> - INIT_LIST_HEAD(>request_list);
> + engine->timeline = >i915->gt.global_timeline.engine[engine->id];

function name is not very current, please update.

> @@ -141,7 +142,6 @@ struct intel_engine_cs {
>   VCS2,   /* Keep instances of the same type engine together. */
>   VECS
>   } id;
> -#define I915_NUM_ENGINES 5
>  #define _VCS(n) (VCS + (n))
>   unsigned int exec_id;
>   enum intel_engine_hw_id {
> @@ -152,10 +152,10 @@ struct intel_engine_cs {
>   VCS2_HW
>   } hw_id;
>   enum intel_engine_hw_id guc_id; /* XXX same as hw_id? */
> - u64 fence_context;
>   u32 mmio_base;
>   unsigned int irq_shift;
>   struct intel_ring *buffer;
> + struct intel_timeline *timeline;

I don't see why not as a non-pointer member?

Again a rather big patch, with above addressed;

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

v4:
s/DRM_IORW/DRM_IOR/ - Emil Velikov
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v2:
use i915_gem_context_get() - Chris Wilson

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_drv.c  |   4 +
 drivers/gpu/drm/i915/i915_drv.h  |  91 
 drivers/gpu/drm/i915/i915_perf.c | 448 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 613 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a998c2b..d991781 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -110,6 +110,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o
 
+# perf code
+i915-y += i915_perf.o
+
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..14f22fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -838,6 +838,8 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
intel_device_info_dump(dev_priv);
 
+   i915_perf_init(dev_priv);
+
/* Not all pre-production machines fall into this category, only the
 * very first ones. Almost everything should work, except for maybe
 * suspend/resume. And we don't implement workarounds that affect only
@@ -859,6 +861,7 @@ err_workqueues:
  */
 static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
 {
+   i915_perf_fini(dev_priv);
i915_gem_load_cleanup(_priv->drm);
i915_workqueues_cleanup(dev_priv);
 }
@@ -2560,6 +2563,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..0f5cd8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,84 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

[Tvrtko Ursulin]

On 12/09/2016 21:19, Dave Gordon wrote:

Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 63 +++---
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   |  2 +-
  3 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 279a4d0..43358e1 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -59,7 +59,7 @@
   * WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
   * represents in-order queue. The kernel driver packs ring tail pointer and an
   * ELSP context descriptor dword into Work Item.
- * See guc_add_workqueue_item()
+ * See guc_wq_item_append()
   *
   */
  
@@ -288,7 +288,7 @@ static uint32_t select_doorbell_cacheline(struct intel_guc *guc)

  /*
   * Initialise the process descriptor shared with the GuC firmware.
   */
-static void guc_init_proc_desc(struct intel_guc *guc,
+static void guc_proc_desc_init(struct intel_guc *guc,
   struct i915_guc_client *client)
  {
struct guc_process_desc *desc;
@@ -320,7 +320,7 @@ static void guc_init_proc_desc(struct intel_guc *guc,
   * write queue, etc).
   */
  
-static void guc_init_ctx_desc(struct intel_guc *guc,

+static void guc_ctx_desc_init(struct intel_guc *guc,
  struct i915_guc_client *client)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -399,7 +399,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 sizeof(desc) * client->ctx_index);
  }
  
-static void guc_fini_ctx_desc(struct intel_guc *guc,

+static void guc_ctx_desc_fini(struct intel_guc *guc,
  struct i915_guc_client *client)
  {
struct guc_context_desc desc;
@@ -413,7 +413,7 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
  }
  
  /**

- * i915_guc_wq_check_space() - check that the GuC can accept a request
+ * i915_guc_wq_reserve() - reserve space in the GuC's workqueue
   * @request:  request associated with the commands
   *
   * Return:0 if space is available
@@ -421,14 +421,14 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
   *
   * This function must be called (and must return 0) before a request
   * is submitted to the GuC via i915_guc_submit() below. Once a result
- * of 0 has been returned, it remains valid until (but only until)
- * the next call to submit().
+ * of 0 has been returned, it must be balanced by a corresponding
+ * call to submit().
   *
- * This precheck allows the caller to determine in advance that space
+ * Reservation allows the caller to determine in advance that space
   * will be available for the next submission before committing resources
   * to it, and helps avoid late failures with complicated recovery paths.
   */
-int i915_guc_wq_check_space(struct drm_i915_gem_request *request)
+int i915_guc_wq_reserve(struct drm_i915_gem_request *request)
  {
const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
@@ -451,8 +451,9 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request 
*request)
return ret;
  }
  
-static void guc_add_workqueue_item(struct i915_guc_client *gc,

-  struct drm_i915_gem_request *rq)
+/* Construct a Work Item and append it to the GuC's Work Queue */
+static void guc_wq_item_append(struct i915_guc_client *gc,
+  struct drm_i915_gem_request *rq)
  {
/* wqi_len is in DWords, and does not include the one-word header */
const size_t wqi_size = sizeof(struct guc_wq_item);
@@ -465,7 +466,7 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
  
  	desc = gc->client_base + gc->proc_desc_offset;
  
-	/* Free space is guaranteed, see i915_guc_wq_check_space() above */

+   /* Free space is guaranteed, see i915_guc_wq_reserve() above */
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
GEM_BUG_ON(freespace < wqi_size);
  
@@ -575,14 +576,13 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)

   * Return:0 on success, otherwise an errno.
   *(Note: nonzero really shouldn't happen!)
   *
- * The caller must have already called i915_guc_wq_check_space() above
- * with a result of 0 (success) since the last request submission. This
- * guarantees that there is space in the work queue for the new request,
- * so enqueuing the item cannot fail.
+ * The caller must have already called i915_guc_wq_reserve() above with
+ * a result of 0 (success), guaranteeing that there is space in the work
+ * queue for the new request, so 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty() 
(rev2)
URL   : https://patchwork.freedesktop.org/series/12262/
State : failure

== Summary ==

Series 12262v2 drm/i915: introduce & use i915_gem_object_{set, clear, 
is}_dirty()
https://patchwork.freedesktop.org/api/1.0/series/12262/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-c:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-rte:
skip   -> PASS   (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:227  dwarn:2   dfail:0   fail:1   skip:14 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: general tidying up (loader)

[Tvrtko Ursulin]

On 12/09/2016 21:19, Dave Gordon wrote:

Renaming to more consistent scheme, delete unused definitions

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_reg.h |  3 ---
  drivers/gpu/drm/i915/intel_guc_loader.c | 27 ---
  2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index cf5a65b..a47e1e4 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -103,9 +103,6 @@
  #define HOST2GUC_INTERRUPT_MMIO(0xc4c8)
  #define   HOST2GUC_TRIGGER  (1<<0)
  
-#define DRBMISC1			0x1984

-#define   DOORBELL_ENABLE(1<<0)
-
  #define GEN8_DRBREGL(x)   _MMIO(0x1000 + (x) * 8)
  #define   GEN8_DRB_VALID(1<<0)
  #define GEN8_DRBREGU(x)   _MMIO(0x1000 + (x) * 8 + 4)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 0021748..6fd39ef 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -97,7 +97,7 @@ const char *intel_guc_fw_status_repr(enum intel_guc_fw_status 
status)
}
  };
  
-static void direct_interrupts_to_host(struct drm_i915_private *dev_priv)

+static void guc_interrupts_release(struct drm_i915_private *dev_priv)
  {
struct intel_engine_cs *engine;
int irqs;
@@ -114,7 +114,7 @@ static void direct_interrupts_to_host(struct 
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, 0);
  }
  
-static void direct_interrupts_to_guc(struct drm_i915_private *dev_priv)

+static void guc_interrupts_capture(struct drm_i915_private *dev_priv)
  {
struct intel_engine_cs *engine;
int irqs;
@@ -179,7 +179,12 @@ static u32 get_core_family(struct drm_i915_private 
*dev_priv)
}
  }
  
-static void set_guc_init_params(struct drm_i915_private *dev_priv)

+/*
+ * Initialise the GuC parameter block before starting the firmware
+ * transfer. These parameters are read by the firmware on startup
+ * and cannot be changed thereafter.
+ */
+static void guc_params_init(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
u32 params[GUC_CTL_MAX_DWORDS];
@@ -392,11 +397,11 @@ static int guc_ucode_xfer(struct drm_i915_private 
*dev_priv)
I915_WRITE(GEN7_MISCCPCTL, (GEN8_DOP_CLOCK_GATE_GUC_ENABLE |
I915_READ(GEN7_MISCCPCTL)));
  
-		/* allows for 5us before GT can go to RC6 */

+   /* allows for 5us (in 10ns units) before GT can go to RC6 */
I915_WRITE(GUC_ARAT_C6DIS, 0x1FF);
}
  
-	set_guc_init_params(dev_priv);

+   guc_params_init(dev_priv);
  
  	ret = guc_ucode_xfer_dma(dev_priv, vma);
  
@@ -411,7 +416,7 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)

return ret;
  }
  
-static int i915_reset_guc(struct drm_i915_private *dev_priv)

+static int guc_hw_reset(struct drm_i915_private *dev_priv)
  {
int ret;
u32 guc_status;
@@ -478,7 +483,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
}
  
-	direct_interrupts_to_host(dev_priv);

+   guc_interrupts_release(dev_priv);
  
  	guc_fw->guc_fw_load_status = GUC_FIRMWARE_PENDING;
  
@@ -501,7 +506,7 @@ int intel_guc_setup(struct drm_device *dev)

 * Always reset the GuC just before (re)loading, so
 * that the state and timing are fairly predictable
 */
-   err = i915_reset_guc(dev_priv);
+   err = guc_hw_reset(dev_priv);
if (err)
goto fail;
  
@@ -526,7 +531,7 @@ int intel_guc_setup(struct drm_device *dev)

err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
-   direct_interrupts_to_guc(dev_priv);
+   guc_interrupts_capture(dev_priv);
}
  
  	return 0;

@@ -535,7 +540,7 @@ int intel_guc_setup(struct drm_device *dev)
if (guc_fw->guc_fw_load_status == GUC_FIRMWARE_PENDING)
guc_fw->guc_fw_load_status = GUC_FIRMWARE_FAIL;
  
-	direct_interrupts_to_host(dev_priv);

+   guc_interrupts_release(dev_priv);
i915_guc_submission_disable(dev_priv);
i915_guc_submission_fini(dev_priv);
  
@@ -768,7 +773,7 @@ void intel_guc_fini(struct drm_device *dev)

struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
  
  	mutex_lock(>struct_mutex);

-   direct_interrupts_to_host(dev_priv);
+   guc_interrupts_release(dev_priv);
i915_guc_submission_disable(dev_priv);
i915_guc_submission_fini(dev_priv);
  


I liked the direct interrupts naming more, but it is not that critical. 
The rest is OK.


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 1/3] drm/i915: clarify PMINTRMSK/pm_intr_keep usage

[Tvrtko Ursulin]

On 12/09/2016 21:19, Dave Gordon wrote:

No functional changes; just renaming a bit, tweaking a datatype,
prettifying layout, and adding comments, in particular in the
GuC setup code that touches this data.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/i915_irq.c |  4 ++--
  drivers/gpu/drm/i915/i915_reg.h |  2 +-
  drivers/gpu/drm/i915/intel_guc_loader.c | 27 +--
  4 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..d01a50e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1184,6 +1184,7 @@ struct intel_gen6_power_mgmt {
bool interrupts_enabled;
u32 pm_iir;
  
+	/* PM interrupt bits that should never be masked */

u32 pm_intr_keep;
  
  	/* Frequencies are stored in potentially platform dependent multiples.

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8462817..c128fdb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -371,7 +371,7 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
spin_lock_irq(_priv->irq_lock);
dev_priv->rps.interrupts_enabled = false;
  
-	I915_WRITE(GEN6_PMINTRMSK, gen6_sanitize_rps_pm_mask(dev_priv, ~0));

+   I915_WRITE(GEN6_PMINTRMSK, gen6_sanitize_rps_pm_mask(dev_priv, ~0u));
  
  	__gen6_disable_pm_irq(dev_priv, dev_priv->pm_rps_events);

I915_WRITE(gen6_pm_ier(dev_priv), I915_READ(gen6_pm_ier(dev_priv)) &
@@ -4500,7 +4500,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev_priv->rps.pm_intr_keep |= GEN6_PM_RP_UP_EI_EXPIRED;
  
  	if (INTEL_INFO(dev_priv)->gen >= 8)

-   dev_priv->rps.pm_intr_keep |= GEN8_PMINTR_REDIRECT_TO_NON_DISP;
+   dev_priv->rps.pm_intr_keep |= GEN8_PMINTR_REDIRECT_TO_GUC;
  
  	INIT_DELAYED_WORK(_priv->gpu_error.hangcheck_work,

  i915_hangcheck_elapsed);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a29d707..70d9616 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7067,7 +7067,7 @@ enum {
  #define VLV_RCEDATA   _MMIO(0xA0BC)
  #define GEN6_RC6pp_THRESHOLD  _MMIO(0xA0C0)
  #define GEN6_PMINTRMSK_MMIO(0xA168)
-#define   GEN8_PMINTR_REDIRECT_TO_NON_DISP (1<<31)
+#define   GEN8_PMINTR_REDIRECT_TO_GUC(1<<31)
  #define GEN8_MISC_CTRL0   _MMIO(0xA180)
  #define VLV_PWRDWNUPCTL   _MMIO(0xA294)
  #define GEN9_MEDIA_PG_IDLE_HYSTERESIS _MMIO(0xA0C4)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 853928f..0021748 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -134,13 +134,28 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, ~irqs);
  
  	/*

-* If GuC has routed PM interrupts to itself, don't keep it.
-* and keep other interrupts those are unmasked by GuC.
-   */
+* The REDIRECT_TO_GUC bit of the PMINTRMSK register directs all
+* (unmasked) PM interrupts to the GuC. All other bits of this
+* register *disable* generation of a specific interrupt.
+*
+* 'pm_intr_keep' indicates bits that are NOT to be set when
+* writing to the PM interrupt mask register, i.e. interrupts
+* that must not be disabled.
+*
+* If the GuC is handling these interrupts, then we must not let
+* the PM code disable ANY interrupt that the GuC is expecting.
+* So for each ENABLED (0) bit in this register, we must SET the
+* bit in pm_intr_keep so that it's left enabled for the GuC.
+*
+* OTOH the REDIRECT_TO_GUC bit is initially SET in pm_intr_keep
+* (so interrupts go to the DISPLAY unit at first); but here we
+* need to CLEAR that bit, which will result in the register bit
+* being left SET!
+*/
tmp = I915_READ(GEN6_PMINTRMSK);
-   if (tmp & GEN8_PMINTR_REDIRECT_TO_NON_DISP) {
-   dev_priv->rps.pm_intr_keep |= ~(tmp & 
~GEN8_PMINTR_REDIRECT_TO_NON_DISP);
-   dev_priv->rps.pm_intr_keep &= ~GEN8_PMINTR_REDIRECT_TO_NON_DISP;
+   if (tmp & GEN8_PMINTR_REDIRECT_TO_GUC) {
+   dev_priv->rps.pm_intr_keep |= ~tmp;
+   dev_priv->rps.pm_intr_keep &= ~GEN8_PMINTR_REDIRECT_TO_GUC;
}
  }
  


More comments is always good and the cleanup just above obviously good 
as well.


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

___
Intel-gfx 

[Intel-gfx] [PATCH i-g-t v4 13/13] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

[robert . foss]

From: Robert Foss 

This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 139 
 1 file changed, 139 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 9ec2dc2..1af9a6b 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -447,6 +447,142 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static int test_mspc_wait_on_fence(int fence)
+{
+   int error, active;
+
+   do {
+   error = sw_sync_fence_count_status(fence,
+  SW_SYNC_FENCE_STATUS_ERROR);
+   igt_assert_f(error == 0, "Error occurred on fence\n");
+   active = sw_sync_fence_count_status(fence,
+   
SW_SYNC_FENCE_STATUS_ACTIVE);
+   } while (active);
+
+   return 0;
+}
+
+static struct {
+   int iterations;
+   int threads;
+   int counter;
+   int cons_timeline;
+   int *prod_timeline;
+   pthread_mutex_t lock;
+} test_mpsc_data;
+
+static int mpsc_producer_thread(void *d)
+{
+   int id = (long)d;
+   int fence, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+
+   for (i = 0; i < iterations; i++) {
+   fence = sw_sync_fence_create(cons_timeline, i);
+
+   /* Wait for the consumer to finish. Use alternate
+* means of waiting on the fence
+*/
+   if ((iterations + id) % 8 != 0) {
+   igt_assert_f(sw_sync_wait(fence, -1) > 0,
+"Failure waiting on fence\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   /* Every producer increments the counter, the consumer
+* checks and erases it
+*/
+   pthread_mutex_lock(_mpsc_data.lock);
+   test_mpsc_data.counter++;
+   pthread_mutex_unlock(_mpsc_data.lock);
+
+   sw_sync_timeline_inc(prod_timeline[id], 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+static int mpsc_consumer_thread(void)
+{
+   int fence, merged, tmp, it, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+   int n = test_mpsc_data.threads;
+
+   for (it = 1; it <= iterations; it++) {
+   fence = sw_sync_fence_create(prod_timeline[0], it);
+   for (i = 1; i < n; i++) {
+   tmp = sw_sync_fence_create(prod_timeline[i], it);
+   merged = sw_sync_merge(tmp, fence);
+   close(tmp);
+   close(fence);
+   fence = merged;
+   }
+
+   /* Make sure we see an increment from every producer thread.
+* Vary the means by which we wait.
+*/
+   if (iterations % 8 != 0) {
+   igt_assert_f(sw_sync_wait(fence, -1) == 0,
+   "Producers did not increment as 
expected\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   igt_assert_f(test_mpsc_data.counter == n * it,
+"Counter value mismatch\n");
+
+   /* Release the producer threads */
+   sw_sync_timeline_inc(cons_timeline, 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+/* IMPORTANT NOTE: if you see this test failing on your system, it may be
+ * due to a shortage of file descriptors. Please ensure your system has
+ * a sensible limit for this test to finish correctly.
+ */
+static void test_sync_multi_producer_single_consumer(void)
+{
+   int iterations = 1 << 12;
+   int n = 5;
+   int prod_timeline[n];
+   int cons_timeline;
+   pthread_t threads[n];
+   long i;
+
+   cons_timeline = sw_sync_timeline_create();
+   for (i = 0; i < n; i++)
+   prod_timeline[i] = sw_sync_timeline_create();
+
+   test_mpsc_data.prod_timeline = prod_timeline;
+   test_mpsc_data.cons_timeline = cons_timeline;
+   test_mpsc_data.iterations = iterations;
+   test_mpsc_data.threads = n;
+   test_mpsc_data.counter = 0;
+   

[Intel-gfx] [PATCH i-g-t v4 04/13] tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline

[robert . foss]

From: Robert Foss 

This subtests tests that creating fences on negative timelines fail.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 8f6208b..75bd471 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -56,6 +56,10 @@ static void test_alloc_fence(void)
close(timeline);
 }
 
+static void test_alloc_fence_invalid_timeline(void)
+{
+   igt_assert(__sw_sync_fence_create(-1, 0) < 0);
+}
 
 igt_main
 {
@@ -64,5 +68,8 @@ igt_main
 
igt_subtest("alloc_fence")
test_alloc_fence();
+
+   igt_subtest("alloc_fence_invalid_timeline")
+   test_alloc_fence_invalid_timeline();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 12/13] tests/sw_sync: Add subtest test_sync_multi_timeline_wait

[robert . foss]

From: Robert Foss 

This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 66 +
 1 file changed, 66 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index bd86111..9ec2dc2 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -215,6 +215,69 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+static void test_sync_multi_timeline_wait(void)
+{
+   int timeline[3];
+   int in_fence[3];
+   int fence_merge;
+   int active, signaled, ret;
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+   timeline[2] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 5);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 5);
+   in_fence[2] = sw_sync_fence_create(timeline[2], 5);
+
+   fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sw_sync_merge(in_fence[2], fence_merge);
+
+   /* Confirm fence isn't signaled */
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 3, "Fence signaled too early\n");
+
+   ret = sw_sync_wait(fence_merge, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+   sw_sync_timeline_inc(timeline[0], 5);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 2 && signaled == 1,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[1], 5);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 1 && signaled == 2,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[2], 5);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 0 && signaled == 3,
+"Fence did not signal properly\n");
+
+   /* confirm you can successfully wait */
+   ret = sw_sync_wait(fence_merge, 100);
+   igt_assert_f(ret > 0, "Failure waiting on signaled fence\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+   close(timeline[2]);
+}
+
 static void * test_sync_multi_consumer_thread(void *arg)
 {
data_t *data = arg;
@@ -477,6 +540,9 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
 
+   igt_subtest("sync_multi_timeline_wait")
+   test_sync_multi_timeline_wait();
+
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 08/13] tests/sw_sync: Add subtest test_sync_merge_same

[robert . foss]

From: Robert Foss 

This subtest verifies merging a fence with itself does not fail.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 26226bd..ff87cfe 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -173,11 +173,35 @@ static void test_sync_merge(void)
igt_assert_f(active == 0 && signaled == 1,
 "fence_merge did not signal\n");
 
-   sw_sync_fence_destroy(in_fence[0]);
-   sw_sync_fence_destroy(in_fence[1]);
-   sw_sync_fence_destroy(in_fence[2]);
-   sw_sync_fence_destroy(fence_merge);
-   sw_sync_timeline_destroy(timeline);
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline);
+}
+
+static void test_sync_merge_same(void)
+{
+   int in_fence[2];
+   int timeline;
+   int signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sw_sync_merge(in_fence[0], in_fence[0]);
+
+   signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 0, "fence signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "fence did not signal\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(timeline);
 }
 
 igt_main
@@ -199,5 +223,8 @@ igt_main
 
igt_subtest("sync_merge")
test_sync_merge();
+
+   igt_subtest("sync_merge_same")
+   test_sync_merge_same();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 09/13] tests/sw_sync: Add subtest test_sync_multi_consumer

[robert . foss]

From: Robert Foss 

This subtest verifies the access ordering of multiple consumer threads.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index ff87cfe..e607b75 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -27,6 +27,8 @@
  *Robert Foss 
  */
 
+#include 
+#include 
 #include 
 #include 
 
@@ -36,6 +38,15 @@
 
 IGT_TEST_DESCRIPTION("Test SW Sync Framework");
 
+typedef struct {
+   int timeline;
+   uint32_t thread_id;
+   uint32_t nbr_threads;
+   uint32_t nbr_iterations;
+   volatile uint32_t * volatile counter;
+   sem_t *sem;
+} data_t;
+
 static void test_alloc_timeline(void)
 {
int timeline;
@@ -204,6 +215,95 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+static void * test_sync_multi_consumer_thread(void *arg)
+{
+   data_t *data = arg;
+   int thread_id = data->thread_id;
+   int nbr_threads = data->nbr_threads;
+   int timeline = data->timeline;
+   int iterations = data->nbr_iterations;
+   int ret, i;
+
+   for (i = 0; i < iterations; i++) {
+   int next_point = i * nbr_threads + thread_id;
+   int fence = sw_sync_fence_create(timeline, next_point);
+
+   ret = sw_sync_wait(fence, 1000);
+   if (ret <= 0)
+   {
+   return (void *) 1;
+   }
+
+   if (*(data->counter) != next_point)
+   {
+   return (void *) 1;
+   }
+
+   sem_post(data->sem);
+   close(fence);
+   }
+   return NULL;
+}
+
+static void test_sync_multi_consumer(void)
+{
+   const uint32_t nbr_threads = 8;
+   const uint32_t nbr_iterations = 1 << 14;
+   data_t data_arr[nbr_threads];
+   pthread_t thread_arr[nbr_threads];
+   sem_t sem;
+   int timeline;
+   volatile uint32_t counter = 0;
+   uintptr_t thread_ret = 0;
+   data_t data;
+   int i, ret;
+
+   sem_init(, 0, 0);
+   timeline = sw_sync_timeline_create();
+
+   data.nbr_iterations = nbr_iterations;
+   data.nbr_threads = nbr_threads;
+   data.counter = 
+   data.timeline = timeline;
+   data.sem = 
+
+   /* Start sync threads. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   data_arr[i] = data;
+   data_arr[i].thread_id = i;
+   ret = pthread_create(_arr[i], NULL,
+test_sync_multi_consumer_thread,
+(void *) &(data_arr[i]));
+   igt_assert_eq(ret, 0);
+   }
+
+   /* Produce 'content'. */
+   for (i = 0; i < nbr_threads * nbr_iterations; i++)
+   {
+   sem_wait();
+
+   counter++;
+   sw_sync_timeline_inc(timeline, 1);
+   }
+
+   /* Wait for threads to complete. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   uintptr_t local_thread_ret;
+   pthread_join(thread_arr[i], (void **)_thread_ret);
+   thread_ret |= local_thread_ret;
+   }
+
+   close(timeline);
+   sem_destroy();
+
+   igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+   igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -226,5 +326,8 @@ igt_main
 
igt_subtest("sync_merge_same")
test_sync_merge_same();
+
+   igt_subtest("sync_multi_consumer")
+   test_sync_multi_consumer();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 11/13] tests/sw_sync: Add subtest test_sync_random_merge

[robert . foss]

From: Robert Foss 

This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 73 +
 1 file changed, 73 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 13a5643..bd86111 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -384,6 +384,76 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static void test_sync_random_merge(void)
+{
+   int i, size, ret;
+   const int nbr_timeline = 32;
+   const int nbr_merge = 1024;
+   int fence_map[nbr_timeline];
+   int timeline_arr[nbr_timeline];
+   int fence, tmpfence, merged;
+   int timeline, timeline_offset, sync_pt;
+
+   srand(time(NULL));
+
+   for (i = 0; i < nbr_timeline; i++) {
+   timeline_arr[i] = sw_sync_timeline_create();
+   fence_map[i] = -1;
+   }
+
+   sync_pt = rand();
+   fence = sw_sync_fence_create(timeline_arr[0], sync_pt);
+
+   fence_map[0] = sync_pt;
+
+   /* Randomly create syncpoints out of a fixed set of timelines,
+* and merge them together.
+*/
+   for (i = 0; i < nbr_merge; i++) {
+   /* Generate syncpoint. */
+   timeline_offset = rand() % nbr_timeline;
+   timeline = timeline_arr[timeline_offset];
+   sync_pt = rand();
+
+   /* Keep track of the latest sync_pt in each timeline. */
+   if (fence_map[timeline_offset] == -1)
+   fence_map[timeline_offset] = sync_pt;
+   else if (fence_map[timeline_offset] < sync_pt)
+   fence_map[timeline_offset] = sync_pt;
+
+   /* Merge. */
+   tmpfence = sw_sync_fence_create(timeline, sync_pt);
+   merged = sw_sync_merge(tmpfence, fence);
+   close(tmpfence);
+   close(fence);
+   fence = merged;
+   }
+
+   size = 0;
+   for (i = 0; i < nbr_timeline; i++)
+   if (fence_map[i] != -1)
+   size++;
+
+   /* Trigger the merged fence. */
+   for (i = 0; i < nbr_timeline; i++) {
+   if (fence_map[i] != -1) {
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0,
+   "Failure waiting on fence until timeout\n");
+   /* Increment the timeline to the last sync_pt */
+   sw_sync_timeline_inc(timeline_arr[i], fence_map[i]);
+   }
+   }
+
+   /* Check that the fence is triggered. */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure triggering fence\n");
+
+   close(fence);
+   for (i = 0; i < nbr_timeline; i++)
+   close(timeline_arr[i]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -412,5 +482,8 @@ igt_main
 
igt_subtest("sync_multi_consumer_producer")
test_sync_multi_consumer_producer();
+
+   igt_subtest("sync_random_merge")
+   test_sync_random_merge();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 07/13] tests/sw_sync: Add subtest test_sync_merge

[robert . foss]

From: Robert Foss 

Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 3061279..26226bd 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -116,6 +116,70 @@ static void test_sync_wait(void)
close(timeline);
 }
 
+static void test_sync_merge(void)
+{
+   int in_fence[3];
+   int fence_merge;
+   int timeline;
+   int active, signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sw_sync_fence_create(timeline, 2);
+   in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+   fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sw_sync_merge(in_fence[2], fence_merge);
+
+   /* confirm all fences have one active point (even d) */
+   active = sw_sync_fence_count_status(in_fence[0],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+   active = sw_sync_fence_count_status(in_fence[1],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+   active = sw_sync_fence_count_status(in_fence[2],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+   /* confirm that fence_merge is not signaled until the max of fence 
0,1,2 */
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sw_sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+   signaled = sw_sync_fence_count_status(fence_merge,
+  SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sw_sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");
+
+   sw_sync_fence_destroy(in_fence[0]);
+   sw_sync_fence_destroy(in_fence[1]);
+   sw_sync_fence_destroy(in_fence[2]);
+   sw_sync_fence_destroy(fence_merge);
+   sw_sync_timeline_destroy(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -132,5 +196,8 @@ igt_main
 
igt_subtest("sync_wait")
test_sync_wait();
+
+   igt_subtest("sync_merge")
+   test_sync_merge();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 03/13] tests/sw_sync: Add subtest test_alloc_fence

[robert . foss]

From: Robert Foss 

Add subtest alloc_fence that verifies that it's possible to allocate a fence
on a timeline.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 47e2dfa..8f6208b 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -44,9 +44,25 @@ static void test_alloc_timeline(void)
close(timeline);
 }
 
+static void test_alloc_fence(void)
+{
+   int in_fence;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   in_fence = sw_sync_fence_create(timeline, 0);
+
+   close(in_fence);
+   close(timeline);
+}
+
+
 igt_main
 {
igt_subtest("alloc_timeline")
test_alloc_timeline();
+
+   igt_subtest("alloc_fence")
+   test_alloc_fence();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

[robert . foss]

From: Robert Foss 

Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destroy timelines and fences.

Signed-off-by: Robert Foss 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Engestrom 
---
 lib/Makefile.sources |   2 +
 lib/sw_sync.c| 190 +++
 lib/sw_sync.h|  48 +
 3 files changed, 240 insertions(+)
 create mode 100644 lib/sw_sync.c
 create mode 100644 lib/sw_sync.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index bac9a7f..3dc7c3c 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -61,6 +61,8 @@ lib_source_list = \
rendercopy_gen8.c   \
rendercopy_gen9.c   \
rendercopy.h\
+   sw_sync.c   \
+   sw_sync.h   \
intel_reg_map.c \
intel_iosf.c\
igt_kms.c   \
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
new file mode 100644
index 000..4e64837
--- /dev/null
+++ b/lib/sw_sync.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * 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.
+ *
+ * Authors:
+ *Robert Foss 
+ */
+
+#ifndef ANDROID
+#define _GNU_SOURCE
+#else
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sw_sync.h"
+#include "drmtest.h"
+#include "ioctl_wrappers.h"
+
+#ifndef SW_SYNC_IOC_INC
+struct sw_sync_create_fence_data {
+   __u32   value;
+   charname[32];
+   __s32   fence;
+};
+
+#define SW_SYNC_IOC_MAGIC  'W'
+#define SW_SYNC_IOC_CREATE_FENCE   _IOWR(SW_SYNC_IOC_MAGIC, 0,\
+   struct 
sw_sync_create_fence_data)
+#define SW_SYNC_IOC_INC_IOW(SW_SYNC_IOC_MAGIC, 1, 
__u32)
+#endif
+
+#define DEVFS_SW_SYNC   "/dev/sw_sync"
+#define DEBUGFS_SW_SYNC "/sys/kernel/debug/sync/sw_sync"
+
+
+int sw_sync_fd_is_valid(int fd)
+{
+   int status;
+
+   if (fd < 0)
+   return 0;
+
+   status = fcntl(fd, F_GETFD, 0);
+   return status >= 0;
+}
+
+int sw_sync_timeline_create(void)
+{
+   int fd = open(DEVFS_SW_SYNC, O_RDWR);
+
+   if (fd < 0)
+   fd = open(DEBUGFS_SW_SYNC, O_RDWR);
+
+   igt_assert(sw_sync_fd_is_valid(fd));
+
+   return fd;
+}
+
+int __sw_sync_fence_create(int fd, uint32_t seqno)
+{
+
+   struct sw_sync_create_fence_data data;
+
+   memset(, 0, sizeof(data));
+   data.value = seqno;
+
+   if (igt_ioctl(fd, SW_SYNC_IOC_CREATE_FENCE, ))
+   return -errno;
+
+   return data.fence;
+}
+
+int sw_sync_fence_create(int fd, uint32_t seqno)
+{
+   int fence = __sw_sync_fence_create(fd, seqno);
+   igt_assert(fence >= 0);
+   return fence;
+}
+
+void sw_sync_timeline_inc(int fd, uint32_t count)
+{
+   uint32_t arg = count;
+
+   if (fd == 0)
+   return;
+
+   do_ioctl(fd, SW_SYNC_IOC_INC, );
+}
+
+int sw_sync_merge(int fd1, int fd2)
+{
+   struct sync_merge_data data = {};
+   int err;
+
+   data.fd2 = fd2;
+
+   err = ioctl(fd1, SYNC_IOC_MERGE, );
+   if (err < 0)
+   return -errno;
+
+   sw_sync_fd_is_valid(data.fence);
+
+   return data.fence;
+}
+
+int sw_sync_wait(int fence, int timeout)
+{
+   struct pollfd fds;
+   int ret;
+
+   fds.fd = fence;
+   fds.events = POLLIN | POLLERR;
+
+   ret = poll(, 1, timeout);
+
+   return ret;
+}
+
+int sw_sync_fence_count(int fd)
+{
+   struct sync_file_info info;
+
+   memset(, 0, 

[Intel-gfx] [PATCH i-g-t v4 02/13] tests/sw_sync: Add sw_sync test

[robert . foss]

From: Robert Foss 

Add initial tests for sw_sync.

Signed-off-by: Robert Foss 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Engestrom 
---
 tests/Makefile.sources |  1 +
 tests/sw_sync.c| 52 ++
 2 files changed, 53 insertions(+)
 create mode 100644 tests/sw_sync.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 72a58ad..0ba769f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -125,6 +125,7 @@ TESTS_progs_M = \
prime_mmap_kms \
prime_self_import \
prime_vgem \
+   sw_sync \
template \
vgem_basic \
vgem_slow \
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
new file mode 100644
index 000..47e2dfa
--- /dev/null
+++ b/tests/sw_sync.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * 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.
+ *
+ * Authors:
+ *Robert Foss 
+ */
+
+#include 
+#include 
+
+#include "sw_sync.h"
+#include "igt.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+
+static void test_alloc_timeline(void)
+{
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   close(timeline);
+}
+
+igt_main
+{
+   igt_subtest("alloc_timeline")
+   test_alloc_timeline();
+}
+
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 10/13] tests/sw_sync: Add subtest test_sync_multi_consumer_producer

[robert . foss]

From: Robert Foss 

This test verifies that stressing the kernel by creating multiple
consumer/producer threads that wait on a single timeline to be incremented
by another conumer/producer thread does not fail.
And that the order amongst the threads is maintained.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 83 +
 1 file changed, 83 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index e607b75..13a5643 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -304,6 +304,86 @@ static void test_sync_multi_consumer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static void * test_sync_multi_consumer_producer_thread(void *arg)
+{
+   data_t *data = arg;
+   int thread_id = data->thread_id;
+   int nbr_threads = data->nbr_threads;
+   int timeline = data->timeline;
+   int iterations = data->nbr_iterations;
+   int ret, i;
+
+   for (i = 0; i < iterations; i++) {
+   int next_point = i * nbr_threads + thread_id;
+   int fence = sw_sync_fence_create(timeline, next_point);
+
+   ret = sw_sync_wait(fence, 1000);
+   if (ret <= 0)
+   {
+   return (void *) 1;
+   }
+
+   if (*(data->counter) != next_point)
+   {
+   return (void *) 1;
+   }
+
+   (*data->counter)++;
+
+   /* Kick off the next thread. */
+   sw_sync_timeline_inc(timeline, 1);
+
+   close(fence);
+   }
+   return NULL;
+}
+
+static void test_sync_multi_consumer_producer(void)
+{
+   const uint32_t nbr_threads = 8;
+   const uint32_t nbr_iterations = 1 << 14;
+   data_t data_arr[nbr_threads];
+   pthread_t thread_arr[nbr_threads];
+   int timeline;
+   volatile uint32_t counter = 0;
+   uintptr_t thread_ret = 0;
+   data_t data;
+   int i, ret;
+
+   timeline = sw_sync_timeline_create();
+
+   data.nbr_iterations = nbr_iterations;
+   data.nbr_threads = nbr_threads;
+   data.counter = 
+   data.timeline = timeline;
+
+   /* Start consumer threads. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   data_arr[i] = data;
+   data_arr[i].thread_id = i;
+   ret = pthread_create(_arr[i], NULL,
+test_sync_multi_consumer_producer_thread,
+(void *) &(data_arr[i]));
+   igt_assert_eq(ret, 0);
+   }
+
+   /* Wait for threads to complete. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   uintptr_t local_thread_ret;
+   pthread_join(thread_arr[i], (void **)_thread_ret);
+   thread_ret |= local_thread_ret;
+   }
+
+   close(timeline);
+
+   igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+   igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -329,5 +409,8 @@ igt_main
 
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
+
+   igt_subtest("sync_multi_consumer_producer")
+   test_sync_multi_consumer_producer();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 05/13] tests/sw_sync: Add subtest test_alloc_merge_fence

[robert . foss]

From: Robert Foss 

This subtest verifies that merging two fences works in the simples possible
case.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 75bd471..fcb2f57 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -61,6 +61,26 @@ static void test_alloc_fence_invalid_timeline(void)
igt_assert(__sw_sync_fence_create(-1, 0) < 0);
 }
 
+static void test_alloc_merge_fence(void)
+{
+   int in_fence[2];
+   int fence_merge;
+   int timeline[2];
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 1);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 1);
+   fence_merge = sw_sync_merge(in_fence[1], in_fence[0]);
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -71,5 +91,8 @@ igt_main
 
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
+
+   igt_subtest("alloc_merge_fence")
+   test_alloc_merge_fence();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 06/13] tests/sw_sync: Add subtest test_sync_wait

[robert . foss]

From: Robert Foss 

This subtest verifies that waiting on fences works properly.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index fcb2f57..3061279 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -81,6 +81,41 @@ static void test_alloc_merge_fence(void)
close(timeline[1]);
 }
 
+static void test_sync_wait(void)
+{
+   int fence, ret;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 5);
+
+   /* Wait on fence until timeout */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(timeline, 1);
+
+   /* Wait on fence until timeout */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+   /* Signal the fence */
+   sw_sync_timeline_inc(timeline, 4);
+
+   /* Wait successfully */
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure waiting on fence\n");
+
+   /* Go even further, and confirm wait still succeeds */
+   sw_sync_timeline_inc(timeline, 10);
+   ret = sw_sync_wait(fence, 0);
+   igt_assert_f(ret > 0, "Failure waiting ahead\n");
+
+   close(fence);
+   close(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -94,5 +129,8 @@ igt_main
 
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
+
+   igt_subtest("sync_wait")
+   test_sync_wait();
 }
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v4 00/13] Implement sw_sync test

[robert . foss]

From: Robert Foss 

s series implements the sw_sync test and the lib/sw_sync helper functions for
said test.

Gustavo Padovans sw_sync series was just de-staged in
gregkh-staging/staging-next [1], and this test is targeted at verifying the
functionality implemented in that series.

The sw_sync subtests range from very basic tests of the sw_sync functionality,
to stress testing and randomized tests.

[1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/

Changes since v1:
Added "Reviewed-by: Eric Engestrom " tag

  lib/sw_sync:
  - Fixed fd value checking
  - Fixed fd validity check in sw_sync_fd_close()
  - Moved sw_sync related paths to define
  - Switched from malloc+memset to calloc in sync_file_info()
  - Switched sizeof to dereferenced ptr

  tests/sw_sync:
  - Moved lib/sw_sync related code to lib/sw_sync commit
  - Replaced memset with assignment in loop


Changes since v2:

  lib/sw_sync:
  - Replaced fd validity check in sw_sync_timeline_create()
  - Replace sw_sync_XXX_destroy() functions with close()
  - Simplified sw_sync_timeline_inc() comparison
  - Changed sw_sync_merge() return value to -errno
  - Changed name of sw_sync_fence_size() to sw_sync_fence_count()
  - Reworked implementation of sw_sync_fence_count()
  - Reworked implementation of sw_sync_fence_count_status()

  tests/sw_sync:
  - Replace sw_sync_XXX_destroy() functions with close()


Changes since v3:

  lib/sw_sync:
  - Changed sw_sync_fence_create() to take uint32_t seqno
  - Added raw __sw_sync_fence_create() and failure check sw_sync_fence_create()

  tests/sw_sync:
  - Switch to using __sw_sync_fence_create() for failure cases

Robert Foss (13):
  lib/sw_sync: Add helper functions for managing synchronization
primitives
  tests/sw_sync: Add sw_sync test
  tests/sw_sync: Add subtest test_alloc_fence
  tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline
  tests/sw_sync: Add subtest test_alloc_merge_fence
  tests/sw_sync: Add subtest test_sync_wait
  tests/sw_sync: Add subtest test_sync_merge
  tests/sw_sync: Add subtest test_sync_merge_same
  tests/sw_sync: Add subtest test_sync_multi_consumer
  tests/sw_sync: Add subtest test_sync_multi_consumer_producer
  tests/sw_sync: Add subtest test_sync_random_merge
  tests/sw_sync: Add subtest test_sync_multi_timeline_wait
  tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

 lib/Makefile.sources   |   2 +
 lib/sw_sync.c  | 190 ++
 lib/sw_sync.h  |  48 
 tests/Makefile.sources |   1 +
 tests/sw_sync.c| 694 +
 5 files changed, 935 insertions(+)
 create mode 100644 lib/sw_sync.c
 create mode 100644 lib/sw_sync.h
 create mode 100644 tests/sw_sync.c

-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

On Wed, Sep 14, 2016 at 3:42 PM, Emil Velikov 
wrote:

> Hi Robert,
>
> I think I've spotted one interesting, yet trivial bit.
>
> On 14 September 2016 at 15:19, Robert Bragg  wrote:
> > Adds base i915 perf infrastructure for Gen performance metrics.
> >
> > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> > properties to configure a stream of metrics and returns a new fd usable
> > with standard VFS system calls including read() to read typed and sized
> > records; ioctl() to enable or disable capture and poll() to wait for
> > data.
> >
> > A stream is opened something like:
> >
> >   uint64_t properties[] = {
> >   /* Single context sampling */
> >   DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> >
> >   /* Include OA reports in samples */
> >   DRM_I915_PERF_PROP_SAMPLE_OA, true,
> >
> >   /* OA unit configuration */
> >   DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
> >   DRM_I915_PERF_PROP_OA_FORMAT, report_format,
> >   DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
> >};
> >struct drm_i915_perf_open_param parm = {
> >   .flags = I915_PERF_FLAG_FD_CLOEXEC |
> >I915_PERF_FLAG_FD_NONBLOCK |
> >I915_PERF_FLAG_DISABLED,
> >   .properties_ptr = (uint64_t)properties,
> >   .num_properties = sizeof(properties) / 16,
> >};
> >int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );
> >
> > Records read all start with a common { type, size } header with
> > DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> > contain an extensible number of fields and it's the
> > DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> > determine what's included in every sample.
> >
> If I'm understanding the above correctly the ioctl can only read user
> data and does not write to params, correct ?
>
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
>
> > +#define DRM_IOCTL_I915_PERF_OPEN   DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
>
> If so, we seems to have a one letter too much in DRM_IOWR - should one
> use DRM_IOW/DRM_IOR ? Then again I'm not sure how many ioctls bother,
> so please don't read too much into my suggestion :-)
>

Ah, yep, good catch, I don't write back to the param struct any more.

The first iteration of this interface was even more closely modeled on the
core linux perf interface where the param struct starts with a size member
and in a case where userspace passes a structure that's smaller than
expected the kernel returns an error but also writes back the expected size
to inform userspace.

i915 perf moved to taking an array of u64 properties and no longer writes
back a size member in the param struct like perf.

Thanks,
- Robert



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

Re: [Intel-gfx] [PATCH i-g-t v2 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

[Robert Foss]

On 2016-09-14 08:18 AM, Chris Wilson wrote:

On Tue, Sep 13, 2016 at 11:40:18AM -0400, Robert Foss wrote:



On 2016-09-13 07:03 AM, Chris Wilson wrote:

Try:

int __sw_sync_fence_create(int fd, int32_t seqno) /* int32_t not unsigned ? */
{

struct sw_sync_create_fence_data data;

memset(, 0, sizeof(data));
data.value = seqno;

if (igt_ioctl(fd, SW_SYNC_IOCT_CREATE_FENCE, ))
return -errno;

return data.fence;
}

int sw_sync_fence_create(int fd, int32_t seqno)
{
int fence = __sw_sync_fence_create(fd, seqno);
igt_assert(fence >= 0);
return fence;
}

Then only in the test code do you send garbage and check for the
expected errno.



What would the corresponding negative test code look like?
A call to __sw_sync_fence_create? Then __sw_sync_fence_create would
have to be made accessible outside of lib/sw_sync.

Or maybe creating a second user of __sw_sync_fence_create along the
lines of sw_sync_fence_create_fail with an inverted igt_assert check
is what you're suggesting.


Exactly. Make the raw unchecked version available to tests. We have been
using __gem_foo() and gem_foo() to identify the difference. __gem_foo()
reports the error to the caller (so that they can feed in different
values of garbage and check for different errno, or maybe used as a
probe to see if the kernel supports such a function) and gem_foo() for
everyone else where we want to just focus on writing a test and hide the
error handling clutter.

Try not to put the error handling tests in the library itself.


Thanks!
Coming up in v4.


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev3)

[Patchwork]

== Series Details ==

Series: Enable i915 perf stream for Haswell OA unit (rev3)
URL   : https://patchwork.freedesktop.org/series/11295/
State : failure

== Summary ==

Series 11295v3 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/11295/revisions/3/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_parse:
Subgroup basic-rejected:
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-byt-n2820)
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-hsw-4770r)
pass   -> FAIL   (fi-hsw-4770k)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-c:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-rte:
skip   -> DMESG-WARN (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:209  dwarn:2   dfail:0   fail:2   skip:31 
fi-byt-n2820 total:244  pass:207  dwarn:0   dfail:0   fail:2   skip:35 
fi-hsw-4770k total:244  pass:225  dwarn:0   dfail:0   fail:1   skip:18 
fi-hsw-4770r total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:218  dwarn:0   dfail:0   fail:1   skip:25 
fi-ivb-3770  total:244  pass:206  dwarn:0   dfail:0   fail:1   skip:37 
fi-skl-6260u 

[Intel-gfx] [PATCH v3] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

[Dave Gordon]

This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely. The
flag is renamed to emphasise that it is private to the GEM memory-
management code and ensure that no legacy code continues to use it
directly.

v2:
Use Chris Wilson's preferred names for flag-related functions

v3:
Remove a couple of changes left over from a prototype version

Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 22 +-
 drivers/gpu/drm/i915/i915_gem.c| 23 ---
 drivers/gpu/drm/i915/i915_gem_context.c|  6 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_userptr.c| 12 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 29 -
 8 files changed, 63 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 64702cc..8acf281 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -160,7 +160,7 @@ static u64 i915_gem_obj_total_ggtt_size(struct 
drm_i915_gem_object *obj)
   i915_gem_active_get_seqno(>last_write,
 >base.dev->struct_mutex),
   i915_cache_level_str(dev_priv, obj->cache_level),
-  obj->dirty ? " dirty" : "",
+  i915_gem_object_is_dirty(obj) ? " dirty" : "",
   obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
if (obj->base.name)
seq_printf(m, " (name: %d)", obj->base.name);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..3fed004 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2212,7 +2212,7 @@ struct drm_i915_gem_object {
 * This is set if the object has been written to since last bound
 * to the GTT
 */
-   unsigned int dirty:1;
+   unsigned int __dirty:1;
 
/**
 * Advice: are the backing pages purgeable?
@@ -3159,6 +3159,26 @@ static inline void i915_gem_object_pin_pages(struct 
drm_i915_gem_object *obj)
obj->pages_pin_count++;
 }
 
+/*
+ * Flag the object content as having changed since the last call to
+ * i915_gem_object_pin_pages() above, so that the new content is not
+ * lost after the next call to i915_gem_object_unpin_pages() below
+ */
+static inline void i915_gem_object_set_dirty(struct drm_i915_gem_object *obj)
+{
+   obj->__dirty = true;
+}
+
+static inline void i915_gem_object_clear_dirty(struct drm_i915_gem_object *obj)
+{
+   obj->__dirty = false;
+}
+
+static inline bool i915_gem_object_is_dirty(struct drm_i915_gem_object *obj)
+{
+   return obj->__dirty;
+}
+
 static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
 {
BUG_ON(obj->pages_pin_count == 0);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c8bd022..08c8f6b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -234,9 +234,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
}
 
if (obj->madv == I915_MADV_DONTNEED)
-   obj->dirty = 0;
-
-   if (obj->dirty) {
+   i915_gem_object_clear_dirty(obj);
+   else if (i915_gem_object_is_dirty(obj)) {
struct address_space *mapping = obj->base.filp->f_mapping;
char *vaddr = obj->phys_handle->vaddr;
int i;
@@ -260,7 +259,7 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
put_page(page);
vaddr += PAGE_SIZE;
}
-   obj->dirty = 0;
+   i915_gem_object_clear_dirty(obj);
}
 
sg_free_table(obj->pages);
@@ -704,7 +703,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
obj->cache_dirty = true;
 
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-   obj->dirty = 1;
+   i915_gem_object_set_dirty(obj);
/* return with the pages pinned */
return 0;
 
@@ -1157,7 +1156,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
goto out_unpin;
 
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-   obj->dirty = true;
+   i915_gem_object_set_dirty(obj);
 
user_data = u64_to_user_ptr(args->data_ptr);
offset = args->offset;
@@ -2134,6 +2133,7 @@ static void i915_gem_object_free_mmap_offset(struct 
drm_i915_gem_object *obj)
 {
struct sgt_iter sgt_iter;
struct page 

Re: [Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

[Emil Velikov]

Hi Robert,

I think I've spotted one interesting, yet trivial bit.

On 14 September 2016 at 15:19, Robert Bragg  wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system calls including read() to read typed and sized
> records; ioctl() to enable or disable capture and poll() to wait for
> data.
>
> A stream is opened something like:
>
>   uint64_t properties[] = {
>   /* Single context sampling */
>   DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
>
>   /* Include OA reports in samples */
>   DRM_I915_PERF_PROP_SAMPLE_OA, true,
>
>   /* OA unit configuration */
>   DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
>   DRM_I915_PERF_PROP_OA_FORMAT, report_format,
>   DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
>};
>struct drm_i915_perf_open_param parm = {
>   .flags = I915_PERF_FLAG_FD_CLOEXEC |
>I915_PERF_FLAG_FD_NONBLOCK |
>I915_PERF_FLAG_DISABLED,
>   .properties_ptr = (uint64_t)properties,
>   .num_properties = sizeof(properties) / 16,
>};
>int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );
>
> Records read all start with a common { type, size } header with
> DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> contain an extensible number of fields and it's the
> DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> determine what's included in every sample.
>
If I'm understanding the above correctly the ioctl can only read user
data and does not write to params, correct ?

> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h

> +#define DRM_IOCTL_I915_PERF_OPEN   DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)

If so, we seems to have a one letter too much in DRM_IOWR - should one
use DRM_IOW/DRM_IOR ? Then again I'm not sure how many ioctls bother,
so please don't read too much into my suggestion :-)

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

Re: [Intel-gfx] [PATCH] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

[Dave Gordon]

On 12/09/16 16:48, Tvrtko Ursulin wrote:


Hi,

On 09/09/16 20:48, Dave Gordon wrote:

This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely. The
flag is renamed to emphasise that it is private to the GEM memory-
management code and ensure that no legacy code continues to use it
directly.

v2:
   Use Chris Wilson's preferred names for flag-related functions

Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html
Cc: Chris Wilson 
Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
  drivers/gpu/drm/i915/i915_drv.h| 22 +-
  drivers/gpu/drm/i915/i915_gem.c| 25
++---
  drivers/gpu/drm/i915/i915_gem_context.c|  7 +--
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
  drivers/gpu/drm/i915/i915_gem_userptr.c| 12 +++-
  drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   | 29
-
  8 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02b627e..b77fc27 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -160,7 +160,7 @@ static u64 i915_gem_obj_total_ggtt_size(struct
drm_i915_gem_object *obj)
 i915_gem_active_get_seqno(>last_write,
   >base.dev->struct_mutex),
 i915_cache_level_str(dev_priv, obj->cache_level),
-   obj->dirty ? " dirty" : "",
+   i915_gem_object_is_dirty(obj) ? " dirty" : "",
 obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
  if (obj->base.name)
  seq_printf(m, " (name: %d)", obj->base.name);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index f39bede..333e21b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2209,7 +2209,7 @@ struct drm_i915_gem_object {
   * This is set if the object has been written to since last bound
   * to the GTT
   */
-unsigned int dirty:1;
+unsigned int __dirty:1;

  /**
   * Advice: are the backing pages purgeable?
@@ -3156,6 +3156,26 @@ static inline void
i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
  obj->pages_pin_count++;
  }

+/*
+ * Flag the object content as having changed since the last call to
+ * i915_gem_object_pin_pages() above, so that the new content is not
+ * lost after the next call to i915_gem_object_unpin_pages() below
+ */
+static inline void i915_gem_object_set_dirty(struct
drm_i915_gem_object *obj)
+{
+obj->__dirty = true;
+}
+
+static inline void i915_gem_object_clear_dirty(struct
drm_i915_gem_object *obj)
+{
+obj->__dirty = false;
+}
+
+static inline bool i915_gem_object_is_dirty(struct
drm_i915_gem_object *obj)
+{
+return obj->__dirty;
+}
+
  static inline void i915_gem_object_unpin_pages(struct
drm_i915_gem_object *obj)
  {
  BUG_ON(obj->pages_pin_count == 0);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 2401818..f571a02 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -234,9 +234,8 @@ int i915_mutex_lock_interruptible(struct
drm_device *dev)
  }

  if (obj->madv == I915_MADV_DONTNEED)
-obj->dirty = 0;
-
-if (obj->dirty) {
+i915_gem_object_clear_dirty(obj);
+else if (i915_gem_object_is_dirty(obj)) {
  struct address_space *mapping = obj->base.filp->f_mapping;
  char *vaddr = obj->phys_handle->vaddr;
  int i;
@@ -260,7 +259,7 @@ int i915_mutex_lock_interruptible(struct
drm_device *dev)
  put_page(page);
  vaddr += PAGE_SIZE;
  }
-obj->dirty = 0;
+i915_gem_object_clear_dirty(obj);
  }

  sg_free_table(obj->pages);
@@ -703,7 +702,7 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
  obj->cache_dirty = true;

  intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-obj->dirty = 1;
+i915_gem_object_set_dirty(obj);
  /* return with the pages pinned */
  return 0;

@@ -1156,7 +1155,7 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
  goto out_unpin;


I wonder why diff got so confused with this one, because this isn't
i915_gem_obj_prepare_shmem_write any longer.


It has to do with functions containing labels. A workaround that 
sometimes works is to tell git-diff that it's C++ code rather than C, as 
it then handles labels slightly differently, in a way that usually 
happens to fix the misidentification of which function the code is in.



  intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-obj->dirty = true;
+i915_gem_object_set_dirty(obj);

  user_data = u64_to_user_ptr(args->data_ptr);
  offset = 

[Intel-gfx] [PATCH v2 0/5] drm: clean up several wrapper functions

[Masahiro Yamada]

Changes in v2:
  - Split per-driver
  - Remove i915_driver_open()
  - Fix dce_virtual_hw_init() as well

Masahiro Yamada (5):
  drm/amdgpu: squash lines for simple wrapper functions
  drm/radeon: squash lines for simple wrapper functions
  drm/bridge: squash lines for simple wrapper functions
  drm/qxl: squash lines for simple wrapper functions
  drm/i915: use i915_gem_open() directly instead of i915_driver_open()

 drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c|  6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c|  6 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 
 drivers/gpu/drm/i915/i915_drv.c   | 13 +
 drivers/gpu/drm/qxl/qxl_draw.c|  7 ++-
 drivers/gpu/drm/qxl/qxl_release.c |  7 ++-
 drivers/gpu/drm/radeon/cik.c  |  6 +-
 drivers/gpu/drm/radeon/r100.c |  6 +-
 drivers/gpu/drm/radeon/r600.c |  6 +-
 10 files changed, 15 insertions(+), 68 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v2 5/5] drm/i915: use i915_gem_open() directly instead of i915_driver_open()

[Masahiro Yamada]

i915_driver_open() is equivalent to i915_gem_open().  Replace the
i915_driver_open with the direct use of i915_gem_open().

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/i915/i915_drv.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..d3a33c4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1322,17 +1322,6 @@ void i915_driver_unload(struct drm_device *dev)
i915_driver_cleanup_early(dev_priv);
 }
 
-static int i915_driver_open(struct drm_device *dev, struct drm_file *file)
-{
-   int ret;
-
-   ret = i915_gem_open(dev, file);
-   if (ret)
-   return ret;
-
-   return 0;
-}
-
 /**
  * i915_driver_lastclose - clean up after all DRM clients have exited
  * @dev: DRM device
@@ -2569,7 +2558,7 @@ static int intel_runtime_resume(struct device *kdev)
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
DRIVER_RENDER | DRIVER_MODESET,
-   .open = i915_driver_open,
+   .open = i915_gem_open,
.lastclose = i915_driver_lastclose,
.preclose = i915_driver_preclose,
.postclose = i915_driver_postclose,
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 03/11] drm/i915: return EACCES for check_cmd() failures

[Robert Bragg]

check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.

The distinction makes the difference between allowing the buffer to be
executed as an unprivileged batch buffer or returning an EINVAL error to
userspace without executing anything.

In a case where userspace may want to test whether it can successfully
write to a register that needs privileges the distinction may be
important and an EINVAL error may be considered fatal.

In particular this is currently true for Mesa, which includes a test for
whether OACONTROL can be written too, but Mesa treats any error when
flushing a batch buffer as fatal, calling exit(1).

As it is currently Mesa can gracefully handle a failure to write to
OACONTROL if the command parser is disabled, but if we were to remove
OACONTROL from the parser's whitelist then the returned EINVAL would
break Mesa applications as they attempt an OACONTROL write.

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

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7269fe8..5ad02dc 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1272,7 +1272,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 
if (!check_cmd(engine, desc, cmd, length, is_master,
   _set)) {
-   ret = -EINVAL;
+   ret = -EACCES;
break;
}
 
-- 
2.9.2

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

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

[Robert Bragg]

Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  72 ++-
 drivers/gpu/drm/i915/i915_gem_context.c |  22 +-
 drivers/gpu/drm/i915/i915_perf.c| 998 +++-
 drivers/gpu/drm/i915/i915_reg.h | 338 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c |  10 +-
 include/uapi/drm/i915_drm.h |  70 ++-
 6 files changed, 1477 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fad018..551f078 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_oa_format {
+   u32 format;
+   int size;
+};
+
 struct i915_oa_reg {
i915_reg_t addr;
u32 value;
@@ -1760,11 +1765,6 @@ struct i915_perf_stream_ops {
 */
void (*disable)(struct i915_perf_stream *stream);
 
-   /* Return: true if any i915 perf records are ready to read()
-* for this stream.
-*/
-   bool (*can_read)(struct i915_perf_stream *stream);
-
/* Call poll_wait, passing a wait queue that will be woken
 * once there is something ready to read() for the stream
 */
@@ -1774,9 +1774,7 @@ struct i915_perf_stream_ops {
 
/* For handling a blocking read, wait until there is something
 * to ready to read() for the stream. E.g. wait on the same
-* wait queue that would be passed to poll_wait() until
-* ->can_read() returns true (if its safe to call ->can_read()
-* without the i915 perf lock held).
+* wait queue that would be passed to poll_wait().
 */
int (*wait_unlocked)(struct i915_perf_stream *stream);
 
@@ -1816,11 +1814,28 @@ struct i915_perf_stream {
struct list_head link;
 
u32 sample_flags;
+   int sample_size;
 
struct i915_gem_context *ctx;
bool enabled;
 
-   struct i915_perf_stream_ops *ops;
+   const struct i915_perf_stream_ops *ops;
+};
+
+struct i915_oa_ops {
+   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
+   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
+   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
+   u32 ctx_id);
+   int (*read)(struct i915_perf_stream *stream,
+   char __user *buf,
+   size_t count,
+   size_t *offset);
+   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
 };
 
 struct drm_i915_private {
@@ -2125,16 +2140,48 @@ struct drm_i915_private {
 
struct {
bool initialized;
+
struct mutex lock;
struct list_head streams;
 
+   spinlock_t hook_lock;
+
struct {
-   u32 metrics_set;
+   struct i915_perf_stream *exclusive_stream;
+
+   u32 specific_ctx_id;
+
+   struct hrtimer poll_check_timer;
+   wait_queue_head_t poll_wq;
+   atomic_t pollin;
+
+   bool periodic;
+   int period_exponent;
+   int timestamp_frequency;
+
+   int tail_margin;
+
+   int metrics_set;
 
const struct i915_oa_reg *mux_regs;
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+
+   struct {
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   u32 gtt_offset;
+   u8 *addr;
+   int format;
+   int format_size;
+   } oa_buffer;
+
+   u32 gen7_latched_oastatus1;
+
+   struct i915_oa_ops ops;
+   const struct i915_oa_format *oa_formats;
+   int n_builtin_sets;
} oa;
} perf;
 
@@ -3499,6 +3546,9 @@ struct drm_i915_gem_object *
 i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
 struct 

[Intel-gfx] [PATCH v5 10/11] drm/i915: Add more Haswell OA metric sets

[Robert Bragg]

This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.

The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:

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

 $ make -C gputop-data -f Makefile.xml

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

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 656334d..7906a26 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -30,9 +30,14 @@
 
 enum metric_set_id {
METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_SAMPLER_BALANCE,
 };
 
-int i915_oa_n_builtin_metric_sets_hsw = 1;
+int i915_oa_n_builtin_metric_sets_hsw = 6;
 
 static const struct i915_oa_reg b_counter_config_render_basic[] = {
{ _MMIO(0x2724), 0x0080 },
@@ -111,6 +116,298 @@ get_render_basic_mux_config(struct drm_i915_private 
*dev_priv,
return mux_config_render_basic;
 }
 
+static const struct i915_oa_reg b_counter_config_compute_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2718), 0x },
+   { _MMIO(0x271c), 0x },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2728), 0x },
+   { _MMIO(0x272c), 0x },
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x },
+   { _MMIO(0x2748), 0x },
+   { _MMIO(0x274c), 0x },
+   { _MMIO(0x2750), 0x },
+   { _MMIO(0x2754), 0x },
+   { _MMIO(0x2758), 0x },
+   { _MMIO(0x275c), 0x },
+   { _MMIO(0x236c), 0x },
+};
+
+static const struct i915_oa_reg mux_config_compute_basic[] = {
+   { _MMIO(0x253a4), 0x },
+   { _MMIO(0x2681c), 0x01f00800 },
+   { _MMIO(0x26820), 0x1000 },
+   { _MMIO(0x2781c), 0x01f00800 },
+   { _MMIO(0x26520), 0x0007 },
+   { _MMIO(0x265a0), 0x0007 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538c), 0x0030 },
+   { _MMIO(0x25384), 0xaa8a },
+   { _MMIO(0x25404), 0x },
+   { _MMIO(0x26800), 0x4202 },
+   { _MMIO(0x26808), 0x00605817 },
+   { _MMIO(0x2680c), 0x10001005 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x27800), 0x0102 },
+   { _MMIO(0x27808), 0x0c0701e0 },
+   { _MMIO(0x2780c), 0x000200a0 },
+   { _MMIO(0x27804), 0x },
+   { _MMIO(0x26484), 0x4400 },
+   { _MMIO(0x26704), 0x4400 },
+   { _MMIO(0x26500), 0x0006 },
+   { _MMIO(0x26510), 0x0001 },
+   { _MMIO(0x26504), 0x8800 },
+   { _MMIO(0x26580), 0x0006 },
+   { _MMIO(0x26590), 0x0020 },
+   { _MMIO(0x26584), 0x },
+   { _MMIO(0x26104), 0x5582 },
+   { _MMIO(0x26184), 0xaa86 },
+   { _MMIO(0x25420), 0x08320c83 },
+   { _MMIO(0x25424), 0x06820c83 },
+   { _MMIO(0x2541c), 0x },
+   { _MMIO(0x25428), 0x0c03 },
+};
+
+static const struct i915_oa_reg *
+get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
+int *len)
+{
+   *len = ARRAY_SIZE(mux_config_compute_basic);
+   return mux_config_compute_basic;
+}
+
+static const struct i915_oa_reg b_counter_config_compute_extended[] = {
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2770), 0x0007fe2a },
+   { _MMIO(0x2774), 0xff00 },
+   { _MMIO(0x2778), 0x0007fe6a },
+   { _MMIO(0x277c), 0xff00 },
+   { _MMIO(0x2780), 0x0007fe92 },
+   { _MMIO(0x2784), 0xff00 },
+   { _MMIO(0x2788), 0x0007fea2 },
+   { _MMIO(0x278c), 0xff00 },
+   { _MMIO(0x2790), 0x0007fe32 },
+   { _MMIO(0x2794), 0xff00 },
+   { _MMIO(0x2798), 0x0007fe9a },
+   { _MMIO(0x279c), 0xff00 },
+   { _MMIO(0x27a0), 0x0007ff23 },
+   { _MMIO(0x27a4), 0xff00 },
+   { _MMIO(0x27a8), 0x0007fff3 },
+   { _MMIO(0x27ac), 0xfffe },
+};
+
+static const struct i915_oa_reg mux_config_compute_extended[] = {
+   { _MMIO(0x2681c), 0x3eb00800 },
+   { _MMIO(0x26820), 0x0090 },
+   { _MMIO(0x25384), 0x02aa },
+   { _MMIO(0x25404), 0x03ff },
+   { _MMIO(0x26800), 0x00142284 },
+   { _MMIO(0x26808), 0x0e629062 },
+   { _MMIO(0x2680c), 0x3f6f55cb },
+   { _MMIO(0x26810), 0x0014 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x26104), 

[Intel-gfx] [PATCH v5 07/11] drm/i915: advertise available metrics via sysfs

[Robert Bragg]

Each metric set is given a sysfs entry like:

/sys/class/drm/card0/metrics//id

This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
specific OA unit register configuration that can be reliably used by
userspace as a key to lookup corresponding counter meta data and
normalization equations.

The guid registry is currently maintained as part of gputop along with
the XML metric set descriptions and code generation scripts, ref:

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

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

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.c|  5 
 drivers/gpu/drm/i915/i915_drv.h|  4 +++
 drivers/gpu/drm/i915/i915_oa_hsw.c | 51 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  4 +++
 drivers/gpu/drm/i915/i915_perf.c   | 52 ++
 5 files changed, 116 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 14f22fc..8965df2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1125,6 +1125,9 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
+
+   /* Depends on sysfs having been initialized */
+   i915_perf_register(dev_priv);
} else
DRM_ERROR("Failed to register driver for userspace access!\n");
 
@@ -1161,6 +1164,8 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
acpi_video_unregister();
intel_opregion_unregister(dev_priv);
 
+   i915_perf_unregister(dev_priv);
+
i915_teardown_sysfs(dev_priv);
i915_debugfs_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 551f078..f5ddf70 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2141,6 +2141,8 @@ struct drm_i915_private {
struct {
bool initialized;
 
+   struct kobject *metrics_kobj;
+
struct mutex lock;
struct list_head streams;
 
@@ -3711,6 +3713,8 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 /* i915_perf.c */
 extern void i915_perf_init(struct drm_i915_private *dev_priv);
 extern void i915_perf_fini(struct drm_i915_private *dev_priv);
+extern void i915_perf_register(struct drm_i915_private *dev_priv);
+extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
 
 /* i915_suspend.c */
 extern int i915_save_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index eb5ceca..656334d 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -24,6 +24,8 @@
  *
  */
 
+#include 
+
 #include "i915_drv.h"
 
 enum metric_set_id {
@@ -141,3 +143,52 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
}
 }
+
+static ssize_t
+show_render_basic_id(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC);
+}
+
+static struct device_attribute dev_attr_render_basic_id = {
+   .attr = { .name = "id", .mode = S_IRUGO },
+   .show = show_render_basic_id,
+   .store = NULL,
+};
+
+static struct attribute *attrs_render_basic[] = {
+   _attr_render_basic_id.attr,
+   NULL,
+};
+
+static struct attribute_group group_render_basic = {
+   .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
+   .attrs =  attrs_render_basic,
+};
+
+int
+i915_perf_register_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int mux_len;
+   int ret = 0;
+
+   if (get_render_basic_mux_config(dev_priv, _len)) {
+   ret = sysfs_create_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+   if (ret)
+   goto error_render_basic;
+   }
+
+   return 0;
+
+error_render_basic:
+   return ret;
+}
+
+void
+i915_perf_unregister_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int mux_len;
+
+   if (get_render_basic_mux_config(dev_priv, _len))
+   sysfs_remove_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+}
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h 
b/drivers/gpu/drm/i915/i915_oa_hsw.h
index b618a1f..429a229 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.h
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.h
@@ -31,4 +31,8 @@ extern int 

[Intel-gfx] [PATCH v5 08/11] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

[Robert Bragg]

Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f5ddf70..eaba7a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2142,6 +2142,7 @@ struct drm_i915_private {
bool initialized;
 
struct kobject *metrics_kobj;
+   struct ctl_table_header *sysctl_header;
 
struct mutex lock;
struct list_head streams;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e890c38..38b13fa 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -62,6 +62,8 @@
 #define POLL_FREQUENCY 200
 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
 
+static u32 i915_perf_stream_paranoid = true;
+
 /* The maximum exponent the hardware accepts is 63 (essentially it selects one
  * of the 64bit timestamp bits to trigger reports from) but there's currently
  * no known use case for sampling as infrequently as once per 47 thousand 
years.
@@ -1170,7 +1172,13 @@ int i915_perf_open_ioctl_locked(struct drm_device *dev,
}
}
 
-   if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
+   /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
+* we check a dev.i915.perf_stream_paranoid sysctl option
+* to determine if it's ok to access system wide OA counters
+* without CAP_SYS_ADMIN privileges.
+*/
+   if (!specific_ctx &&
+   i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
DRM_ERROR("Insufficient privileges to open system-wide i915 
perf stream\n");
ret = -EACCES;
goto err_ctx;
@@ -1417,6 +1425,37 @@ void i915_perf_unregister(struct drm_i915_private 
*dev_priv)
dev_priv->perf.metrics_kobj = NULL;
 }
 
+static struct ctl_table oa_table[] = {
+   {
+.procname = "perf_stream_paranoid",
+.data = _perf_stream_paranoid,
+.maxlen = sizeof(i915_perf_stream_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec,
+},
+   {}
+};
+
+static struct ctl_table i915_root[] = {
+   {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+   {}
+};
+
+static struct ctl_table dev_root[] = {
+   {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+   {}
+};
+
 void i915_perf_init(struct drm_i915_private *dev_priv)
 {
if (!IS_HASWELL(dev_priv))
@@ -1449,6 +1488,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_hsw;
 
+   dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
+
dev_priv->perf.initialized = true;
 }
 
@@ -1457,6 +1498,8 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
if (!dev_priv->perf.initialized)
return;
 
+   unregister_sysctl_table(dev_priv->perf.sysctl_header);
+
memset(_priv->perf.oa.ops, 0, sizeof(dev_priv->perf.oa.ops));
dev_priv->perf.initialized = false;
 }
-- 
2.9.2

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

[Intel-gfx] [PATCH v5 09/11] drm/i915: add oa_event_min_timer_exponent sysctl

[Robert Bragg]

The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.

Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.

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

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 38b13fa..a7a248b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -74,6 +74,23 @@ static u32 i915_perf_stream_paranoid = true;
  */
 #define OA_EXPONENT_MAX 31
 
+/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
+static int zero;
+static int oa_exponent_max = OA_EXPONENT_MAX;
+
+/* Theoretically we can program the OA unit to sample every 160ns but don't
+ * allow that by default unless root...
+ *
+ * The period is derived from the exponent as:
+ *
+ *   period = 80ns * 2^(exponent + 1)
+ *
+ * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
+ * (10 by default); with an OA exponent of 6 we get a period of 10.240
+ * microseconds - just under 10Hz
+ */
+static u32 i915_oa_min_timer_exponent = 6;
+
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
  * be used as a mask to align the OA tail pointer.
@@ -1315,21 +1332,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}
 
-   /* NB: The exponent represents a period as follows:
-*
-*   80ns * 2^(period_exponent + 1)
-*
-* Theoretically we can program the OA unit to sample
+   /* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* Referring to perf's
-* kernel.perf_event_max_sample_rate for a precedent
-* (10 by default); with an OA exponent of 6 we get
-* a period of 10.240 microseconds -just under 10Hz
 */
-   if (value < 6 && !capable(CAP_SYS_ADMIN)) {
-   DRM_ERROR("Sampling period too high without 
root privileges\n");
+   if (value < i915_oa_min_timer_exponent &&
+   !capable(CAP_SYS_ADMIN)) {
+   DRM_ERROR("OA timer exponent too low without 
root privileges\n");
return -EACCES;
}
 
@@ -1433,6 +1442,15 @@ static struct ctl_table oa_table[] = {
 .mode = 0644,
 .proc_handler = proc_dointvec,
 },
+   {
+.procname = "oa_min_timer_exponent",
+.data = _oa_min_timer_exponent,
+.maxlen = sizeof(i915_oa_min_timer_exponent),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = ,
+.extra2 = _exponent_max,
+},
{}
 };
 
-- 
2.9.2

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

[Intel-gfx] [PATCH v5 05/11] drm/i915: Add 'render basic' Haswell OA unit config

[Robert Bragg]

Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:

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

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

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h|  14 
 drivers/gpu/drm/i915/i915_oa_hsw.c | 143 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  34 +
 4 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d991781..6cb25dd 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -111,7 +111,8 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_vgpu.o
 
 # perf code
-i915-y += i915_perf.o
+i915-y += i915_perf.o \
+ i915_oa_hsw.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f5cd8f..5fad018 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_oa_reg {
+   i915_reg_t addr;
+   u32 value;
+};
+
 struct i915_perf_stream;
 
 struct i915_perf_stream_ops {
@@ -2122,6 +2127,15 @@ struct drm_i915_private {
bool initialized;
struct mutex lock;
struct list_head streams;
+
+   struct {
+   u32 metrics_set;
+
+   const struct i915_oa_reg *mux_regs;
+   int mux_regs_len;
+   const struct i915_oa_reg *b_counter_regs;
+   int b_counter_regs_len;
+   } oa;
} perf;
 
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
new file mode 100644
index 000..eb5ceca
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -0,0 +1,143 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "i915_drv.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_hsw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2710), 0x },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+   { _MMIO(0x253a4), 0x0160 },
+   { _MMIO(0x25440), 0x0010 },
+   { _MMIO(0x25128), 0x },
+   { _MMIO(0x2691c), 0x0800 },
+   { _MMIO(0x26aa0), 0x0150 },
+   { _MMIO(0x26b9c), 0x6000 },
+   { _MMIO(0x2791c), 0x0800 },
+   { _MMIO(0x27aa0), 0x0150 },
+   { _MMIO(0x27b9c), 0x6000 },
+   { _MMIO(0x2641c), 0x0400 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538c), 0x },
+   { _MMIO(0x25384), 0x0800 },
+   { _MMIO(0x25400), 0x0004 },
+   { _MMIO(0x2540c), 0x06029000 },
+   { _MMIO(0x25410), 0x0002 },
+   { _MMIO(0x25404), 0x5c30 },
+   { _MMIO(0x25100), 0x0016 },
+   { _MMIO(0x25110), 0x0400 },
+   { _MMIO(0x25104), 0x },
+   { _MMIO(0x26804), 0x1211 },
+   { _MMIO(0x26884), 0x0100 },
+   { _MMIO(0x26900), 0x0002 },
+   { _MMIO(0x26908), 0x0070 },
+   { 

[Intel-gfx] [PATCH v5 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

[Robert Bragg]

In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 163 +++
 1 file changed, 163 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a7a248b..891efe6 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -24,6 +24,169 @@
  *   Robert Bragg 
  */
 
+
+/**
+ * DOC: i915 Perf, streaming API for GPU metrics
+ *
+ * Gen graphics supports a large number of performance counters that can help
+ * driver and application developers understand and optimize their use of the
+ * GPU.
+ *
+ * This i915 perf interface enables userspace to configure and open a file
+ * descriptor representing a stream of GPU metrics which can then be read() as
+ * a stream of sample records.
+ *
+ * The interface is particularly suited to exposing buffered metrics that are
+ * captured by DMA from the GPU, unsynchronized with and unrelated to the CPU.
+ *
+ * Streams representing a single context are accessible to applications with a
+ * corresponding drm file descriptor, such that OpenGL can use the interface
+ * without special privileges. Access to system-wide metrics requires root
+ * privileges by default, unless changed via the dev.i915.perf_event_paranoid
+ * sysctl option.
+ *
+ *
+ * The interface was initially inspired by the core Perf infrastructure but
+ * some notable differences are:
+ *
+ * i915 perf file descriptors represent a "stream" instead of an "event"; where
+ * a perf event primarily corresponds to a single 64bit value, while a stream
+ * might sample sets of tightly-coupled counters, depending on the
+ * configuration.  For example the Gen OA unit isn't designed to support
+ * orthogonal configurations of individual counters; it's configured for a set
+ * of related counters. Samples for an i915 perf stream capturing OA metrics
+ * will include a set of counter values packed in a compact HW specific format.
+ * The OA unit supports a number of different packing formats which can be
+ * selected by the user opening the stream. Perf has support for grouping
+ * events, but each event in the group is configured, validated and
+ * authenticated individually with separate system calls.
+ *
+ * i915 perf stream configurations are provided as an array of u64 (key,value)
+ * pairs, instead of a fixed struct with multiple miscellaneous config members,
+ * interleaved with event-type specific members.
+ *
+ * i915 perf doesn't support exposing metrics via an mmap'd circular buffer.
+ * The supported metrics are being written to memory by the GPU unsynchronized
+ * with the CPU, using HW specific packing formats for counter sets. Sometimes
+ * the constraints on HW configuration require reports to be filtered before it
+ * would be acceptable to expose them to unprivileged applications - to hide
+ * the metrics of other processes/contexts. For these use cases a read() based
+ * interface is a good fit, and provides an opportunity to filter data as it
+ * gets copied from the GPU mapped buffers to userspace buffers.
+ *
+ *
+ * Some notes regarding Linux Perf:
+ * 
+ *
+ * The first prototype of this driver was based on the core perf
+ * infrastructure, and while we did make that mostly work, with some changes to
+ * perf, we found we were breaking or working around too many assumptions baked
+ * into perf's currently cpu centric design.
+ *
+ * In the end we didn't see a clear benefit to making perf's implementation and
+ * interface more complex by changing design assumptions while we knew we still
+ * wouldn't be able to use any existing perf based userspace tools.
+ *
+ * Also considering the Gen specific nature of the Observability hardware and
+ * how userspace will sometimes need to combine i915 perf OA metrics with
+ * side-band OA data captured via MI_REPORT_PERF_COUNT commands; we're
+ * expecting the interface to be used by a platform specific userspace such as
+ * OpenGL or tools. This is to say; we aren't inherently missing out on having
+ * a standard vendor/architecture agnostic interface by not using perf.
+ *
+ *
+ * For posterity, in case we might re-visit trying to adapt core perf to be
+ * better suited to exposing i915 metrics these were the main pain points we
+ * hit:
+ *
+ * - The perf based OA PMU driver broke some significant design assumptions:
+ *
+ *   Existing perf pmus are used for profiling work on a cpu and we were
+ *   introducing the idea of _IS_DEVICE pmus with different security
+ *   implications, the need to fake cpu-related data (such as user/kernel
+ *   registers) to fit with perf's current design, and adding _DEVICE records
+ *   as a way 

[Intel-gfx] [PATCH v5 04/11] drm/i915: don't whitelist oacontrol in cmd parser

[Robert Bragg]

Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

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

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5ad02dc..bdee590 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct intel_engine_cs 
*engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_SKIP)
return true;
@@ -1099,31 +1097,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}
 
/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_REG) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRR to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1214,7 +1187,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
u32 *cmd, *batch_end;
struct drm_i915_cmd_descriptor default_desc = noop_desc;
const struct drm_i915_cmd_descriptor *desc = _desc;
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
bool needs_clflush_after = false;
int ret = 0;
 
@@ -1270,8 +1242,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
break;
}
 
-   if (!check_cmd(engine, desc, cmd, length, is_master,
-  _set)) {
+   if (!check_cmd(engine, desc, cmd, length, is_master)) {
ret = -EACCES;
break;
}
@@ -1279,11 +1250,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
cmd += length;
}
 
- 

[Intel-gfx] [PATCH v5 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

[Robert Bragg]

OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 3c72b3b..7269fe8 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,7 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */
+   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1108,7 +1108,7 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
 * to the register. Hence, limit OACONTROL writes to
 * only MI_LOAD_REGISTER_IMM commands.
 */
-   if (reg_addr == i915_mmio_reg_offset(OACONTROL)) {
+   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a29d707..90756b2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -616,7 +616,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define HSW_CS_GPR(n)   _MMIO(0x2600 + (n) * 8)
 #define HSW_CS_GPR_UDW(n)   _MMIO(0x2600 + (n) * 8 + 4)
 
-#define OACONTROL _MMIO(0x2360)
+#define GEN7_OACONTROL _MMIO(0x2360)
 
 #define _GEN7_PIPEA_DE_LOAD_SL 0x70068
 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068
-- 
2.9.2

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

[Intel-gfx] [PATCH v5 00/11] Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

This just rebases my i915 perf series on a recent drm-intel-nightly.

Considering now that this series has been reviewed a number of times by Chris,
and I think I've responded to his feedback: I wonder if this series is ready
to be added to drm-intel-nightly soon?

I think most of the effort for this series at the moment is just keeping up
with rebasing on nightlies.

Regards,
- Robert

Robert Bragg (11):
  drm/i915: Add i915 perf infrastructure
  drm/i915: rename OACONTROL GEN7_OACONTROL
  drm/i915: return EACCES for check_cmd() failures
  drm/i915: don't whitelist oacontrol in cmd parser
  drm/i915: Add 'render basic' Haswell OA unit config
  drm/i915: Enable i915 perf stream for Haswell OA unit
  drm/i915: advertise available metrics via sysfs
  drm/i915: Add dev.i915.perf_event_paranoid sysctl option
  drm/i915: add oa_event_min_timer_exponent sysctl
  drm/i915: Add more Haswell OA metric sets
  drm/i915: Add a kerneldoc summary for i915_perf.c

 drivers/gpu/drm/i915/Makefile   |4 +
 drivers/gpu/drm/i915/i915_cmd_parser.c  |   40 +-
 drivers/gpu/drm/i915/i915_drv.c |9 +
 drivers/gpu/drm/i915/i915_drv.h |  162 +++
 drivers/gpu/drm/i915/i915_gem_context.c |   22 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c  |  751 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h  |   38 +
 drivers/gpu/drm/i915/i915_perf.c| 1686 +++
 drivers/gpu/drm/i915/i915_reg.h |  340 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   10 +-
 include/uapi/drm/i915_drm.h |  133 +++
 11 files changed, 3154 insertions(+), 41 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

-- 
2.9.2

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

[Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_drv.c  |   4 +
 drivers/gpu/drm/i915/i915_drv.h  |  91 
 drivers/gpu/drm/i915/i915_perf.c | 448 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 613 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a998c2b..d991781 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -110,6 +110,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o
 
+# perf code
+i915-y += i915_perf.o
+
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..14f22fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -838,6 +838,8 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
intel_device_info_dump(dev_priv);
 
+   i915_perf_init(dev_priv);
+
/* Not all pre-production machines fall into this category, only the
 * very first ones. Almost everything should work, except for maybe
 * suspend/resume. And we don't implement workarounds that affect only
@@ -859,6 +861,7 @@ err_workqueues:
  */
 static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
 {
+   i915_perf_fini(dev_priv);
i915_gem_load_cleanup(_priv->drm);
i915_workqueues_cleanup(dev_priv);
 }
@@ -2560,6 +2563,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..0f5cd8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1740,6 +1740,84 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the stream
+*/
+   void (*poll_wait)(struct i915_perf_stream *stream,
+ struct file *file,
+ poll_table *wait);
+
+   /* For handling a 

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

[Zanoni, Paulo R]

Em Qua, 2016-09-14 às 10:22 +0100, Chris Wilson escreveu:
> On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote:
> > 
> > I was looking at some wait_for() timeouts on a slow system, with
> > lots of
> > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> > mishandling the timeout, I tried to ensure that we loop at least
> > once
> > after first testing COND. However, the double test of COND either
> > side
> > of the timeout check makes that unlikely. But we can do an
> > equivalent
> > loop, that keeps the COND check after testing for timeout (required
> > so
> > that we are not preempted between testing COND and then testing for
> > a
> > timeout) without expanding COND twice.
> > 
> > The advantage of only expanding COND once is a dramatic reduction
> > in
> > code size:
> > 
> >    text    data bss dec hex
> > 1308733    5184    1152 1315069  1410fd
> > before
> > 1305341    5184    1152 1311677  1403bd
> > after
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index cb99a2540863..597899d71df9 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -52,13 +52,16 @@
> >   */
> >  #define _wait_for(COND, US, W) ({ \
> >     unsigned long timeout__ = jiffies + usecs_to_jiffies(US) +
> > 1;  \
> > -   int ret__ = 0;  
> > \
> > -   while (!(COND)) {   
> > \
> > -   if (time_after(jiffies, timeout__)) {   
> > \
> > -   if (!(COND))
> > \
> > -   ret__ = -ETIMEDOUT; 
> > \
> > +   int ret__;  
> > \
> 
> Ok, this is the magic. Missed initializer, gcc goes wild trimming
> undefined code. Patch is completely bogus.

IMHO, expanding a macro argument only once is an improvement on its
own, even if the resulting binary is not smaller, since it makes the
code a little safer.

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

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

[Zanoni, Paulo R]

Em Qua, 2016-09-14 às 12:59 +0300, Jani Nikula escreveu:
> On Tue, 13 Sep 2016, "Zanoni, Paulo R" 
> wrote:
> > 
> > I got confirmation from the Hardware guys that KBL does need to run
> > the
> > SAGV code, and it has the same latency as SKL. Also, all SKL
> > production
> > steppings need to run the SAGV code.
> 
> Can you get confirmation what's the first shipped production
> stepping?

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl
-vol04-configurations.pdf#page=15

But I have to admit that I still have pre-prod machines and it would be
very convenient to me if they keep working :)

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

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

[Tvrtko Ursulin]

On 14/09/2016 07:52, Chris Wilson wrote:

In the next patch, we will use deferred request emission. That requires
reserving sufficient space in the ringbuffer to emit the request, which
first requires us to know how large the request is.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_request.c |  1 +
  drivers/gpu/drm/i915/intel_lrc.c|  6 ++
  drivers/gpu/drm/i915/intel_ringbuffer.c | 29 +++--
  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
  4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index ebc2feba3e50..9a735e2d5aea 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -425,6 +425,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 * away, e.g. because a GPU scheduler has deferred it.
 */
req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
+   GEM_BUG_ON(req->reserved_space < engine->emit_request_sz);
  
  	if (i915.enable_execlists)

ret = intel_logical_ring_alloc_request_extras(req);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 00fcf36ba919..7e944a0acc10 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1572,6 +1572,8 @@ static int gen8_emit_request(struct drm_i915_gem_request 
*request)
return intel_logical_ring_advance(request);
  }
  
+static const int gen8_emit_request_sz = 6 + WA_TAIL_DWORDS;

+
  static int gen8_emit_request_render(struct drm_i915_gem_request *request)
  {
struct intel_ring *ring = request->ring;
@@ -1603,6 +1605,8 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
return intel_logical_ring_advance(request);
  }
  
+static const int gen8_emit_request_render_sz = 8 + WA_TAIL_DWORDS;

+
  static int gen8_init_rcs_context(struct drm_i915_gem_request *req)
  {
int ret;
@@ -1677,6 +1681,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
*engine)
engine->reset_hw = reset_common_ring;
engine->emit_flush = gen8_emit_flush;
engine->emit_request = gen8_emit_request;
+   engine->emit_request_sz = gen8_emit_request_sz;
engine->submit_request = execlists_submit_request;
  
  	engine->irq_enable = gen8_logical_ring_enable_irq;

@@ -1799,6 +1804,7 @@ int logical_render_ring_init(struct intel_engine_cs 
*engine)
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_request = gen8_emit_request_render;
+   engine->emit_request_sz = gen8_emit_request_render_sz;
  
  	ret = intel_engine_create_scratch(engine, 4096);

if (ret)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 597e35c9b699..c8c9ad40fd93 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1405,6 +1405,8 @@ static int i9xx_emit_request(struct drm_i915_gem_request 
*req)
return 0;
  }
  
+static const int i9xx_emit_request_sz = 4;

+
  /**
   * gen6_sema_emit_request - Update the semaphore mailbox registers
   *
@@ -1458,6 +1460,8 @@ static int gen8_render_emit_request(struct 
drm_i915_gem_request *req)
return 0;
  }
  
+static const int gen8_render_emit_request_sz = 8;

+
  /**
   * intel_ring_sync - sync the waiter to the signaller on seqno
   *
@@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct 
drm_i915_private *dev_priv,
engine->reset_hw = reset_ring_common;
  
  	engine->emit_request = i9xx_emit_request;

-   if (i915.semaphores)
+   engine->emit_request_sz = i9xx_emit_request_sz;
+   if (i915.semaphores) {
+   int num_rings;
+
engine->emit_request = gen6_sema_emit_request;
+
+   num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1;


You can use INTEL_INFO(dev_priv)->num_rings instead of hweight32.


+   if (INTEL_GEN(dev_priv) >= 8) {
+   engine->emit_request_sz += num_rings * 6;
+   } else {
+   engine->emit_request_sz += num_rings * 3;
+   if (num_rings & 1)
+   engine->emit_request_sz++;
+   }
+   }
engine->submit_request = i9xx_submit_request;
  
  	if (INTEL_GEN(dev_priv) >= 8)

@@ -2706,9 +2723,17 @@ int intel_init_render_ring_buffer(struct intel_engine_cs 
*engine)
if (INTEL_GEN(dev_priv) >= 8) {
engine->init_context = intel_rcs_ctx_init;
engine->emit_request = gen8_render_emit_request;
+   engine->emit_request_sz = gen8_render_emit_request_sz;
engine->emit_flush = gen8_render_ring_flush;
-   if (i915.semaphores)
+   if (i915.semaphores) {
+  

Re: [Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

[Zanoni, Paulo R]

Em Qua, 2016-09-14 às 12:34 +0300, Jani Nikula escreveu:
> On Wed, 14 Sep 2016, Paulo Zanoni  wrote:
> > 
> > Hi
> > 
> > Here's the series with the reviews implemented. There's a new
> > patch,
> > based on the additional issue spotted by Lyude.
> 
> There's a bunch of cc: stable patches mixed with non cc: stable
> patches
> in the series. Do the cc: stable fixes work and backport cleanly
> without
> the the other non cc: stable patches? If not, can you arrange the
> series
> to not depend on the other patches?

Yeah, my bad. I was just pasting the output of "dim fixes" without
considering this aspect. I think the best thing is probably to backport
everything to stable and hope it works, considering the current
complaints we're seeing about screen flickering on SKL. Agree?

I suppose I don't need to resend the series just for these new tags.
I'll add them when it's time to merge.

> 
> BR,
> Jani.
> 
> 
> > 
> > 
> > Thanks for all the reviews,
> > Paulo
> > 
> > Paulo Zanoni (9):
> >   drm/i915: SAGV is not SKL-only, so rename a few things
> >   drm/i915: introduce intel_has_sagv()
> >   drm/i915/kbl: KBL also needs to run the SAGV code
> >   drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
> >   drm/i915/gen9: minimum scanlines for Y tile is not always 4
> >   drm/i915/gen9: fix plane_blocks_per_line on watermarks
> > calculations
> >   drm/i915/gen9: fix the watermark res_blocks value
> >   drm/i915/gen9: implement missing case for SKL watermarks
> > calculation
> >   drm/i915/gen9: fail the modeset instead of WARNing on unsuported
> > config
> > 
> >  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
> >  drivers/gpu/drm/i915/intel_display.c |   9 +-
> >  drivers/gpu/drm/i915/intel_drv.h |   6 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 186 ---
> > 
> >  4 files changed, 118 insertions(+), 93 deletions(-)
> 
___
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: Only expand COND once in wait_for() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Only expand COND once in wait_for() (rev2)
URL   : https://patchwork.freedesktop.org/series/12403/
State : failure

== Summary ==

Series 12403v2 drm/i915: Only expand COND once in wait_for()
https://patchwork.freedesktop.org/api/1.0/series/12403/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_busy:
Subgroup basic-flip-default-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-default-c:
skip   -> PASS   (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> FAIL   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-skl-6770hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-rte:
skip   -> PASS   (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:211  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0 

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

On 14/09/16 13:32, Dave Gordon wrote:

On 13/09/16 10:10, Jani Nikula wrote:

On Sat, 10 Sep 2016, Dave Gordon  wrote:

Thanks, the other things I was thinking of fixing in the remaining files
were generally things like

   if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))


Is that a real or a made up example? IS_G33() would be redundant. But
I'd like to see the semantic patch to fix that! ;)

BR,
Jani.


That particular one was made up. The full series is now on the list in
three patches. Part 1 is this one and already has Chris' R-b, part 2 is
all the nontrivial ones such as the above and part 3 is intel_display.c
all on its own 'cos it's the biggest file and the biggest user of this
construct. Both of the latter have various boolean combinations of
INTEL_GEN() with IS_X() or HAS_X() so it might be worth checking them
for redundancies.


I should have pointed out that the full series is not part of this 
thread, it's a separate patchset beginning with


[PATCH 0/3] drm/i915: use INTEL_GEN(dev_priv) wherever possible​

https://lists.freedesktop.org/archives/intel-gfx/2016-September/106338.html

.Dave.


If you make up a table of redundant comparisons I'm sure it can be
turned into a Cocci script :)

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


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

Re: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

[Mahesh Kumar]

Hi,
There was an issue with transition WM, it was getting enabled & causing 
fifo underrun.
I fixed the condition, After that tested kms_plane & not getting any 
underrun.

Please let me know if you see any other issue.

Regards,
-Mahesh

On Tuesday 13 September 2016 06:10 PM, Maarten Lankhorst wrote:

Op 13-09-16 om 14:15 schreef Kumar, Mahesh:

From: Mahesh Kumar 

This patch implements new DDB allocation algorithm as per HW team
suggestion. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
plane, for efficient power saving.

Changes since v1:
  - Rebase on top of Paulo's patch series

Changes since v2:
  - Fix the for loop condition to enable WM

Signed-off-by: Mahesh Kumar 

I'm still getting underrun issues when running the entire patch series against 
kms_atomic_transition and kms_plane.
Can you confirm?

~Maarten


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

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

On 13/09/16 10:10, Jani Nikula wrote:

On Sat, 10 Sep 2016, Dave Gordon  wrote:

Thanks, the other things I was thinking of fixing in the remaining files
were generally things like

   if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))


Is that a real or a made up example? IS_G33() would be redundant. But
I'd like to see the semantic patch to fix that! ;)

BR,
Jani.


That particular one was made up. The full series is now on the list in 
three patches. Part 1 is this one and already has Chris' R-b, part 2 is 
all the nontrivial ones such as the above and part 3 is intel_display.c 
all on its own 'cos it's the biggest file and the biggest user of this 
construct. Both of the latter have various boolean combinations of 
INTEL_GEN() with IS_X() or HAS_X() so it might be worth checking them 
for redundancies.


If you make up a table of redundant comparisons I'm sure it can be 
turned into a Cocci script :)


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

Re: [Intel-gfx] [PATCH i-g-t v2 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

[Chris Wilson]

On Tue, Sep 13, 2016 at 11:40:18AM -0400, Robert Foss wrote:
> 
> 
> On 2016-09-13 07:03 AM, Chris Wilson wrote:
> >Try:
> >
> >int __sw_sync_fence_create(int fd, int32_t seqno) /* int32_t not unsigned ? 
> >*/
> >{
> >
> > struct sw_sync_create_fence_data data;
> >
> > memset(, 0, sizeof(data));
> > data.value = seqno;
> >
> > if (igt_ioctl(fd, SW_SYNC_IOCT_CREATE_FENCE, ))
> > return -errno;
> > 
> > return data.fence;
> >}
> >
> >int sw_sync_fence_create(int fd, int32_t seqno)
> >{
> > int fence = __sw_sync_fence_create(fd, seqno);
> > igt_assert(fence >= 0);
> > return fence;
> >}
> >
> >Then only in the test code do you send garbage and check for the
> >expected errno.
> >
> 
> What would the corresponding negative test code look like?
> A call to __sw_sync_fence_create? Then __sw_sync_fence_create would
> have to be made accessible outside of lib/sw_sync.
> 
> Or maybe creating a second user of __sw_sync_fence_create along the
> lines of sw_sync_fence_create_fail with an inverted igt_assert check
> is what you're suggesting.

Exactly. Make the raw unchecked version available to tests. We have been
using __gem_foo() and gem_foo() to identify the difference. __gem_foo()
reports the error to the caller (so that they can feed in different
values of garbage and check for different errno, or maybe used as a
probe to see if the kernel supports such a function) and gem_foo() for
everyone else where we want to just focus on writing a test and hide the
error handling clutter.

Try not to put the error handling tests in the library itself.
-Chris

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

[Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

[Dave Gordon]

Commentary from Chris Wilson's original version:

> I was looking at some wait_for() timeouts on a slow system, with lots of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing COND. However, the double test of COND either side
> of the timeout check makes that unlikely. But we can do an equivalent
> loop, that keeps the COND check after testing for timeout (required so
> that we are not preempted between testing COND and then testing for a
> timeout) without expanding COND twice.
> 
> The advantage of only expanding COND once is a dramatic reduction in
> code size:
> 
>text  data bss dec hex
>1308733   51841152 1315069  1410fd before
>1305341   51841152 1311677  1403bd after

but it turned out that due to a missing iniitialiser, gcc had "gone
wild trimming undefined code" :( This version acheives a rather more
modest (but still worthwhile) gain of ~550 bytes.

Signed-off-by: Dave Gordon 
Original-idea-by: Chris Wilson 
Cc: Chris Wilson 
Cc: Zanoni, Paulo R 
---
 drivers/gpu/drm/i915/intel_drv.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index abe7a4d..8fd16ad 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -52,11 +52,15 @@
  */
 #define _wait_for(COND, US, W) ({ \
unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
-   int ret__ = 0;  \
-   while (!(COND)) {   \
-   if (time_after(jiffies, timeout__)) {   \
-   if (!(COND))\
-   ret__ = -ETIMEDOUT; \
+   int ret__;  \
+   for (;;) {  \
+   bool expired__ = time_after(jiffies, timeout__);\
+   if (COND) { \
+   ret__ = 0;  \
+   break;  \
+   }   \
+   if (expired__) {\
+   ret__ = -ETIMEDOUT; \
break;  \
}   \
if ((W) && drm_can_sleep()) {   \
-- 
1.9.1

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

[Intel-gfx] [PATCH v4] drm/i915/bxt: Implement Transition WM

[Kumar, Mahesh]

From: Mahesh Kumar 

This patch enables Transition WM for SKL+ platforms.

Transition WM are used if IPC is enabled, to decide, number of blocks
to be fetched before reducing the priority of display to fetch from
memory.

Changes since v1:
 - Don't enable transition WM for GEN9 (Art/Paulo)
 - Rebase to use fixed point 16.16 calculation
 - Fix the use of selected result from latency level-0

Changes since v2:
 - Fix transition WM enable condition

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 60 ++---
 1 file changed, 57 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index de2e738..4814a1a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2862,6 +2862,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
 
 #define SKL_DDB_SIZE   896 /* in blocks */
 #define BXT_DDB_SIZE   512
+#define SKL_TRANS_WM_AMOUNT10  /* tunable value */
+#define SKL_TRANS_WM_MIN   14
 #define SKL_SAGV_BLOCK_TIME30 /* µs */
 
 /*
@@ -3583,6 +3585,48 @@ static uint32_t skl_adjusted_plane_pixel_rate(const 
struct intel_crtc_state *cst
return pixel_rate;
 }
 
+static void skl_compute_plane_trans_wm(const struct drm_i915_private *dev_priv,
+   struct skl_pipe_wm *pipe_wm,
+   struct intel_plane_state *intel_pstate,
+   uint32_t selected_result,
+   uint32_t y_tile_min,
+   bool y_tile)
+{
+   struct drm_plane_state *pstate = _pstate->base;
+   int id = skl_wm_plane_id(to_intel_plane(pstate->plane));
+   uint16_t *out_blocks = _wm->trans_wm.plane_res_b[id];
+   uint8_t *out_lines = _wm->trans_wm.plane_res_l[id];
+   uint32_t trans_min = 0, trans_offset_blocks;
+   uint32_t trans_y_tile_min = 0, res_blocks = 0;
+   uint16_t trans_res_blocks = 0;
+
+   /* Keep Trans WM disabled for GEN9 */
+   if (IS_GEN9(dev_priv))
+   goto exit;
+
+   trans_min = SKL_TRANS_WM_MIN;
+
+   trans_offset_blocks = (trans_min + SKL_TRANS_WM_AMOUNT) << 16;
+
+   if (y_tile) {
+   trans_y_tile_min = 2 * y_tile_min;
+   res_blocks = max(trans_y_tile_min, selected_result) +
+   trans_offset_blocks;
+   } else {
+   res_blocks = selected_result + trans_offset_blocks;
+   }
+
+   trans_res_blocks = DIV_ROUND_UP(res_blocks, 1 << 16) + 1;
+
+   /* WA BUG:1938466 add one block for non y-tile planes */
+   if (!y_tile)
+   trans_res_blocks += 1;
+exit:
+   *out_blocks = trans_res_blocks;
+   *out_lines = 0;
+}
+
+
 static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
struct intel_plane_state *intel_pstate,
@@ -3709,6 +3753,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
*out_blocks = res_blocks;
*out_lines = res_lines;
 
+   if (level == 0)
+   skl_compute_plane_trans_wm(dev_priv, pipe_wm, intel_pstate,
+   selected_result, y_tile_minimum, y_tiled);
return 0;
 }
 
@@ -3778,11 +3825,13 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
 }
 
 static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
- struct skl_wm_level *trans_wm /* out */)
+ struct skl_wm_level *trans_wm, /* out */
+ struct skl_ddb_allocation *ddb)
 {
struct drm_crtc *crtc = cstate->base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_plane *intel_plane;
+   enum pipe pipe = to_intel_crtc(crtc)->pipe;
 
if (!cstate->base.active)
return;
@@ -3790,8 +3839,13 @@ static void skl_compute_transition_wm(struct 
intel_crtc_state *cstate,
/* Until we know more, just disable transition WMs */
for_each_intel_plane_on_crtc(crtc->dev, intel_crtc, intel_plane) {
int i = skl_wm_plane_id(intel_plane);
+   uint16_t plane_ddb = skl_ddb_entry_size(>plane[pipe][i]);
+   uint16_t trans_res_blocks = trans_wm->plane_res_b[i];
 
-   trans_wm->plane_en[i] = false;
+   if ((trans_res_blocks > 0) && (trans_res_blocks <= plane_ddb))
+   trans_wm->plane_en[i] = true;
+   else
+   trans_wm->plane_en[i] = false;
}
 }
 
@@ -3822,7 +3876,7 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
 
pipe_wm->linetime = skl_compute_linetime_wm(cstate);
 
-   skl_compute_transition_wm(cstate, 

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Martin Steigerwald]

Am Mittwoch, 14. September 2016, 12:17:53 CEST schrieb Jani Nikula:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
> > For the "sometimes need xrandr after resume": I don't think I can
> > bisect that. It only happens sometimes :-(. But there's something
> > helpful in the logs:
> > 
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> > invalid, remainder is 130
> > [ 1856.218863] Raw EDID:
> > [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
> 
> Pavel, Martin, do you always see this when the display fails to resume?
> Is it HDMI/DVI for both of you?

According to zgrep "EDID" /var/log/kern* I don´t have any EDID related error 
messages. I am using DisplayPort cable via ThinkPad Minidock Plus (dock for 
ThinkPad T520) or what it was named.

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

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Jani Nikula  wrote:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
>> For the "sometimes need xrandr after resume": I don't think I can
>> bisect that. It only happens sometimes :-(. But there's something
>> helpful in the logs:
>
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>> invalid, remainder is 130
>> [ 1856.218863] Raw EDID:
>> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
>
> Pavel, Martin, do you always see this when the display fails to resume?
> Is it HDMI/DVI for both of you?

Please try this patch, backported from our next.

BR,
Jani.

From c5cec7b2df1a518a632998aecd6f73f3fefe59ec Mon Sep 17 00:00:00 2001
From: David Weinehall 
Date: Wed, 17 Aug 2016 15:47:48 +0300
Subject: [PATCH] Revert "drm/i915: Check live status before reading edid"
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula 

This reverts commit 237ed86c693d8a8e4db476976aeb30df4deac74b.

Our current implementation of live status check (repeat 9 times
with 10ms delays between each attempt as a workaround for
buggy displays) imposes a rather serious penalty, time wise,
on intel_hdmi_detect().  Since we we already skip live status
checks on platforms before gen 7, and since we seem to have
coped quite well before the live status check was introduced
for newer platforms too, the previous behaviour is probably
preferable, at least unless someone can point to a use-case
that the live status check improves (apart from "Bspec says so".)

Signed-off-by: David Weinehall 
Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
Fixes: f8d03ea0053b ("drm/i915: increase the tries for HDMI hotplug live status 
checking")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97139
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94014
Acked-by: Chris Wilson 
Cc: sta...@vger.kernel.org # v4.4+
Signed-off-by: Jani Nikula 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20160817124748.31208-1-david.weineh...@linux.intel.com

Conflicts:
drivers/gpu/drm/i915/intel_drv.h
---
 drivers/gpu/drm/i915/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  2 --
 

Re: [Intel-gfx] [PATCH] drm/i915: Queue page flip work with high priority

[Imre Deak]

On ti, 2016-09-13 at 12:12 +0100, Tvrtko Ursulin wrote:
> On 13/09/16 11:31, Imre Deak wrote:
> > On ti, 2016-09-13 at 11:24 +0100, Tvrtko Ursulin wrote:
> > > On 12/09/16 15:09, Imre Deak wrote:
> > > > While user space has control over the scheduling priority of
> > > > its
> > > > page
> > > > flipping thread, the corresponding work the driver schedules
> > > > for
> > > > MMIO
> > > > flips always runs with normal scheduling priority. This would
> > > > hinder an
> > > > application that wants more stringent guarantees over flip
> > > > timing
> > > > (to
> > > > avoid missing a flip at the next frame count).
> > > > 
> > > > Fix this by scheduling the work with high priority, meaning
> > > > normal
> > > > scheduling policy with -20 nice level.
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97775
> > > > Testcase: igt/kms_cursor_legacy
> > > > CC: Chris Wilson 
> > > > CC: Maarten Lankhorst 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >    drivers/gpu/drm/i915/i915_drv.c  | 7 +++
> > > >    drivers/gpu/drm/i915/i915_drv.h  | 4 
> > > >    drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > >    3 files changed, 12 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 02c34d6..381ef23 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -756,8 +756,14 @@ static int i915_workqueues_init(struct
> > > > drm_i915_private *dev_priv)
> > > >     if (dev_priv->hotplug.dp_wq == NULL)
> > > >     goto out_free_wq;
> > > > 
> > > > +   dev_priv->flip_wq = alloc_workqueue("i915-flip",
> > > > WQ_HIGHPRI, 0);
> > > > +   if (dev_priv->flip_wq == NULL)
> > > > +   goto out_free_dp_wq;
> > > > +
> > > >     return 0;
> > > > 
> > > > +out_free_dp_wq:
> > > > +   destroy_workqueue(dev_priv->hotplug.dp_wq);
> > > >    out_free_wq:
> > > >     destroy_workqueue(dev_priv->wq);
> > > >    out_err:
> > > > @@ -768,6 +774,7 @@ out_err:
> > > > 
> > > >    static void i915_workqueues_cleanup(struct drm_i915_private
> > > > *dev_priv)
> > > >    {
> > > > +   destroy_workqueue(dev_priv->flip_wq);
> > > >     destroy_workqueue(dev_priv->hotplug.dp_wq);
> > > >     destroy_workqueue(dev_priv->wq);
> > > >    }
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index f499fa5..3653ce4 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1844,6 +1844,10 @@ struct drm_i915_private {
> > > >      * result in deadlocks.
> > > >      */
> > > >     struct workqueue_struct *wq;
> > > > +   /**
> > > > +    * flip_wq - High priority flip workqueue.
> > > > +    */
> > > > +   struct workqueue_struct *flip_wq;
> > > > 
> > > >     /* Display functions */
> > > >     struct drm_i915_display_funcs display;
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 3c367d0..48433e1 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -12278,7 +12278,7 @@ static int intel_crtc_page_flip(struct
> > > > drm_crtc *crtc,
> > > > 
> > > >     work->flip_queued_req =
> > > > i915_gem_active_get(
> > > > > last_write,
> > > >     
> > > > 
> > > > > base.dev->struct_mutex);
> > > > -   schedule_work(>mmio_work);
> > > > +   queue_work(dev_priv->flip_wq, 
> > > > >mmio_work);
> > > >     } else {
> > > >     request = i915_gem_request_alloc(engine,
> > > > engine-
> > > > > last_context);
> > > >     if (IS_ERR(request)) {
> > > > 
> > > 
> > > I am curious if just a dedicated wq would be enough, or you have
> > > found
> > > that it has to be a high-prio one?
> > 
> > I haven't tried a dedicated normal-prio wq. Right, another work in
> > the
> > queue could also hold up this one, but the system_wq is unordered,
> > so
> > that kind of dependency shouldn't be a problem if that's what you
> > meant.
> 
> Yes, I've suspicious whether the problem is work start latency and
> not 
> actually the worker priority. Since the flip work item mostly does 
> waiting and little CPU activity, I though the former sounded like
> more 
> likely.

Hm, testing it with a WQ_UNBOUND dedicated queue I couldn't reproduce
the problem either. The fact that the system_wq is not WQ_UNBOUND could
explain the extra latency. So I can resend this with that change.

--Imre
___
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: Unlock PPS registers after GPU reset

[Patchwork]

== Series Details ==

Series: drm/i915: Unlock PPS registers after GPU reset
URL   : https://patchwork.freedesktop.org/series/12446/
State : success

== Summary ==

Series 12446v1 drm/i915: Unlock PPS registers after GPU reset
https://patchwork.freedesktop.org/api/1.0/series/12446/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> PASS   (fi-hsw-4770k)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:244  pass:212  dwarn:0   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2530/

9aa8c0cdbc076bcc0486d7a31922a0f77c032fe7 drm-intel-nightly: 
2016y-09m-14d-09h-19m-25s UTC integration manifest
424c774 drm/i915: Unlock PPS registers after GPU reset

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

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Chris Wilson]

On Tue, Sep 13, 2016 at 11:04:37PM +0200, Pavel Machek wrote:
> Hi!
> 
> > I have
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (rev 03)
> > 
> > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> > in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> > powersave) and all windows move to secondary monitor (VGA). Running
> > "xrandr" fixes that.
> > 
> > I'll update to newer rc and see if it happens again, but if you have
> > any ideas, now would be good time.
> 
> Ok. With -rc6, X are completely broken. I got notification "could not
> restore CRTC config for screen 63" or something like that, and window
> manager just does not start.
> 
> X log is attached as delme, kernel log as delme2. Nothing too
> suspicious :-(.

[   234.547] (EE) intel(0): failed to set mode: Permission denied
upon resume.

There is a VT switch so there should be a DropMaster, SetMaster combo
across resume, but that didn't flag any errors. I couldn't see any sign
of logind (so no revocation), so just some breakage in the setmaster
reauthentication?
-Chris

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

[Intel-gfx] [PATCH] drm/i915: Unlock PPS registers after GPU reset

[Imre Deak]

Reapply the PPS register unlock workaround after GPU reset on platforms
where the reset clobbers the display HW state. This at least gets rid of
the related WARN during LVDS encoder enabling on PNV.

Fixes: ed6143b8f75 ("drm/i915/lvds: Restore initial HW state during encoder 
enabling")
Reported-by: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 48433e1..8bcffdd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3629,6 +3629,7 @@ void intel_finish_reset(struct drm_i915_private *dev_priv)
intel_runtime_pm_disable_interrupts(dev_priv);
intel_runtime_pm_enable_interrupts(dev_priv);
 
+   intel_pps_unlock_regs_wa(dev_priv);
intel_modeset_init_hw(dev);
 
spin_lock_irq(_priv->irq_lock);
-- 
2.5.0

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

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Pavel Machek  wrote:
> Intel folks, any ideas? Can you reproduce it?

It's possible (but not confirmed yet) we've seen this in our CI, but has
slipped through because it's sporadic.

BR,
Jani.


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

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

[Jani Nikula]

On Tue, 13 Sep 2016, "Zanoni, Paulo R"  wrote:
> I got confirmation from the Hardware guys that KBL does need to run the
> SAGV code, and it has the same latency as SKL. Also, all SKL production
> steppings need to run the SAGV code.

Can you get confirmation what's the first shipped production stepping?

BR,
Jani.


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

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

[Joonas Lahtinen]

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> In preparation to support many distinct timelines, we need to expand the
> activity tracking on the GEM object to handle more than just a request
> per engine. We already use the struct reservation_object on the dma-buf
> to handle many fence contexts, so integrating that into the GEM object
> itself is the preferred solution. (For example, we can now share the same
> reservation_object between every consumer/producer using this buffer and
> skip the manual import/export via dma-buf.)
> 
> Caveats:

I'd make comments which patch in the series addresses each introduced
problem, which are fixable in future and which are taken as "a
permanent hit" for achieving multiple timelines. With a bit of
reasoning for each (now only a few points include some of this).

>  static inline struct drm_i915_gem_object *
> @@ -2347,35 +2341,10 @@ i915_gem_object_has_struct_page(const struct 
> drm_i915_gem_object *obj)
>   return obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE;
>  }
>  
> -static inline unsigned long
> -i915_gem_object_get_active(const struct drm_i915_gem_object *obj)
> -{
> - return (obj->flags >> I915_BO_ACTIVE_SHIFT) & I915_BO_ACTIVE_MASK;
> -}
> -
>  static inline bool
>  i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
>  {
> - return i915_gem_object_get_active(obj);
> -}
> -
> -static inline void
> -i915_gem_object_set_active(struct drm_i915_gem_object *obj, int engine)
> -{
> - obj->flags |= BIT(engine + I915_BO_ACTIVE_SHIFT);
> -}
> -
> -static inline void
> -i915_gem_object_clear_active(struct drm_i915_gem_object *obj, int engine)
> -{
> - obj->flags &= ~BIT(engine + I915_BO_ACTIVE_SHIFT);
> -}
> -
> -static inline bool
> -i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
> -   int engine)
> -{
> - return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
> + return obj->active_count;

our type is bool, so !!obj->active_count;

>  }
> 



> 
>  static int
>  i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
>   struct list_head *vmas)
>  {
> - const unsigned int other_rings = eb_other_engines(req);
>   struct i915_vma *vma;
>   int ret;
>  
>   list_for_each_entry(vma, vmas, exec_list) {
>   struct drm_i915_gem_object *obj = vma->obj;
> - struct reservation_object *resv;
> -
> - if (obj->flags & other_rings) {
> - ret = i915_gem_request_await_object
> - (req, obj, obj->base.pending_write_domain);
> - if (ret)
> - return ret;
> - }
>  
> - resv = i915_gem_object_get_dmabuf_resv(obj);
> - if (resv) {
> - ret = i915_sw_fence_await_reservation
> - (>submit, resv, _fence_ops,
> -  obj->base.pending_write_domain, 10*HZ,
> -  GFP_KERNEL | __GFP_NOWARN);
> - if (ret < 0)
> - return ret;
> - }
> + ret = i915_gem_request_await_object
> + (req, obj, obj->base.pending_write_domain);

I know it was previously like this, but I'm not sure I agree on this
style at all.

> @@ -11935,17 +11932,8 @@ static bool use_mmio_flip(struct intel_engine_cs 
> *engine,
>  
>   if (i915.use_mmio_flip < 0)
>   return false;
> - else if (i915.use_mmio_flip > 0)
> - return true;
> - else if (i915.enable_execlists)
> - return true;
>  
> - resv = i915_gem_object_get_dmabuf_resv(obj);
> - if (resv && !reservation_object_test_signaled_rcu(resv, false))
> - return true;
> -
> - return engine != i915_gem_active_get_engine(>last_write,
> - 
> >base.dev->struct_mutex);
> + return true;

return i915_use_mmio_flip >= 0; // ?

> @@ -860,39 +860,6 @@ struct drm_i915_gem_busy {
>    * long as no new GPU commands are executed upon it). Due to the
>    * asynchronous nature of the hardware, an object reported
>    * as busy may become idle before the ioctl is completed.
> -  *
> -  * Furthermore, if the object is busy, which engine is busy is only
> -  * provided as a guide. There are race conditions which prevent the
> -  * report of which engines are busy from being always accurate.
> -  * However, the converse is not true. If the object is idle, the
> -  * result of the ioctl, that all engines are idle, is accurate.
> -  *
> -  * The returned dword is split into two fields to indicate both
> -  * the engines on which the object is being read, and the
> -  * engine on which it is currently being written (if any).
> -  *
> -  * The low word (bits 0:15) indicate if the object is being written

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Mon, 20 Jun 2016, James Bottomley  
wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
>> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > > > > I guess we'll need the bisect on this one to make progress.
>> > > > > 
>> > > > > Sigh, I was afraid that might be the next step.
>> > > > 
>> > > > OK, I have a curious data point.  I assumed the problem would
>> > > > be
>> > > > somewhere in the drm update, so I started bisecting that at the
>> > > > top. 
>> > > >  However, the top most commit:
>> > > > 
>> > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> > > > Merge: 1f40c49 a39ed68
>> > > > Author: Linus Torvalds 
>> > > > Date:   Mon May 23 11:48:48 2016 -0700
>> > > > 
>> > > > Merge branch 'drm-next' of
>> > > > git://people.freedesktop.org/~airlied/linux
>> > > > 
>> > > > Isn't actually bad.  There's no flicker here, so whatever
>> > > > caused
>> > > > the
>> > > > problem came from some update after this.
>> > > 
>> > > There was a fixes pull after this. Might be worth it to restrict
>> > > to
>> > > just
>> > > the i915 changes, which are just
>> > > 5b4fd5bb1230cd037..157d2c7fad0863222
>> > > 
>> > > Looking at those nothing seems to stick out which might explain
>> > > what's
>> > > happening for you.
>> 
>> OK, so just on the firmware, the system seems less flickery with the
>> new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
>> issue.  The flicker isn't gone for good, but seems to be reboot 
>> dependent (it's there in some boots, but gone on a reboot).
>> 
>> > This should be easy enough to try before bisecting:
>> > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git
>> > -s
>> > end-email-mika.kah...@intel.com
>> 
>> Applying this didn't seem to make a difference: still there on some 
>> and gone on other reboots.
>
> OK, my candidate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It is,
> however, early days because the flicker can hide for long periods, so I
> 'll wait until Monday evening and a few reboots before declaring
> victory.

Fixed by

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639
Author: Ville Syrjälä 
Date:   Tue Sep 13 12:22:19 2016 +0300

drm/i915: Ignore OpRegion panel type except on select machines

in drm-intel-fixes, headed upstream soon-ish.

BR,
Jani.


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

Re: [Intel-gfx] intel_opregion_get_panel_type potential bug fix

[Jani Nikula]

On Mon, 29 Aug 2016, Sean Greenslade  wrote:
> In investigating the issue myself, I discovered that the root of the
> problem seemed to be that the new code for getting the panel type from
> the opregion seems to believe it is getting good data, but it is not.
> The function intel_opregion_get_panel_type (introduced in commit
> a05628195a0d, the one my bisect says caused this issue) seems to do some
> checks for validity, but apparently not enough.

Fixed by

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639
Author: Ville Syrjälä 
Date:   Tue Sep 13 12:22:19 2016 +0300

drm/i915: Ignore OpRegion panel type except on select machines

in drm-intel-fixes.

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

Re: [Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

[Jani Nikula]

On Wed, 14 Sep 2016, Paulo Zanoni  wrote:
> Hi
>
> Here's the series with the reviews implemented. There's a new patch,
> based on the additional issue spotted by Lyude.

There's a bunch of cc: stable patches mixed with non cc: stable patches
in the series. Do the cc: stable fixes work and backport cleanly without
the the other non cc: stable patches? If not, can you arrange the series
to not depend on the other patches?

BR,
Jani.


>
> Thanks for all the reviews,
> Paulo
>
> Paulo Zanoni (9):
>   drm/i915: SAGV is not SKL-only, so rename a few things
>   drm/i915: introduce intel_has_sagv()
>   drm/i915/kbl: KBL also needs to run the SAGV code
>   drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
>   drm/i915/gen9: minimum scanlines for Y tile is not always 4
>   drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
>   drm/i915/gen9: fix the watermark res_blocks value
>   drm/i915/gen9: implement missing case for SKL watermarks calculation
>   drm/i915/gen9: fail the modeset instead of WARNing on unsuported
> config
>
>  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
>  drivers/gpu/drm/i915/intel_display.c |   9 +-
>  drivers/gpu/drm/i915/intel_drv.h |   6 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 186 
> ---
>  4 files changed, 118 insertions(+), 93 deletions(-)

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

Re: [Intel-gfx] [PATCH] drm/i915: Standardize port type for DVO encoders

[Jani Nikula]

On Wed, 14 Sep 2016, Dhinakaran Pandiyan  wrote:
> Changing the return type from 'char' to 'enum port' in
> intel_dvo_port_name() makes it easier to later move the port information to
> intel_encoder. In addition, the port type conforms to what we have
> elsewhere.
>
> Removing the last conditional that handles invalid port because dvo_reg is
> intialized to valid values for all DVO devices at definition.
>
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dvo.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 2e452c5..1ea2627 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -412,16 +412,14 @@ intel_dvo_get_current_mode(struct drm_connector 
> *connector)
>   return mode;
>  }
>  
> -static char intel_dvo_port_name(i915_reg_t dvo_reg)
> +static char intel_dvo_port(i915_reg_t dvo_reg)

You haven't actually changed the return type to enum port.

BR,
Jani.

>  {
>   if (i915_mmio_reg_equal(dvo_reg, DVOA))
> - return 'A';
> + return PORT_A;
>   else if (i915_mmio_reg_equal(dvo_reg, DVOB))
> - return 'B';
> - else if (i915_mmio_reg_equal(dvo_reg, DVOC))
> - return 'C';
> + return PORT_B;
>   else
> - return '?';
> + return PORT_C;
>  }
>  
>  void intel_dvo_init(struct drm_device *dev)
> @@ -464,6 +462,7 @@ void intel_dvo_init(struct drm_device *dev)
>   bool dvoinit;
>   enum pipe pipe;
>   uint32_t dpll[I915_MAX_PIPES];
> + enum port port;
>  
>   /* Allow the I2C driver info to specify the GPIO to be used in
>* special cases, but otherwise default to what's defined
> @@ -511,9 +510,10 @@ void intel_dvo_init(struct drm_device *dev)
>   if (!dvoinit)
>   continue;
>  
> + port = intel_dvo_port(dvo->dvo_reg);
>   drm_encoder_init(dev, _encoder->base,
>_dvo_enc_funcs, encoder_type,
> -  "DVO %c", intel_dvo_port_name(dvo->dvo_reg));
> +  "DVO %c", port_name(port));
>  
>   intel_encoder->type = INTEL_OUTPUT_DVO;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1);

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

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

[Chris Wilson]

On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote:
> I was looking at some wait_for() timeouts on a slow system, with lots of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing COND. However, the double test of COND either side
> of the timeout check makes that unlikely. But we can do an equivalent
> loop, that keeps the COND check after testing for timeout (required so
> that we are not preempted between testing COND and then testing for a
> timeout) without expanding COND twice.
> 
> The advantage of only expanding COND once is a dramatic reduction in
> code size:
> 
>text  data bss dec hex
> 1308733  51841152 1315069  1410fd before
> 1305341  51841152 1311677  1403bd after
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index cb99a2540863..597899d71df9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -52,13 +52,16 @@
>   */
>  #define _wait_for(COND, US, W) ({ \
>   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
> - int ret__ = 0;  \
> - while (!(COND)) {   \
> - if (time_after(jiffies, timeout__)) {   \
> - if (!(COND))\
> - ret__ = -ETIMEDOUT; \
> + int ret__;  \

Ok, this is the magic. Missed initializer, gcc goes wild trimming
undefined code. Patch is completely bogus.
-Chris

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

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Pavel Machek  wrote:
> For the "sometimes need xrandr after resume": I don't think I can
> bisect that. It only happens sometimes :-(. But there's something
> helpful in the logs:

> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
> [ 1856.218863] Raw EDID:
> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.

Pavel, Martin, do you always see this when the display fails to resume?
Is it HDMI/DVI for both of you?


BR,
Jani.


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/18] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

[Patchwork]

== Series Details ==

Series: series starting with [01/18] drm/i915: Support asynchronous waits on 
struct fence from i915_gem_request
URL   : https://patchwork.freedesktop.org/series/12433/
State : failure

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-b:
skip   -> INCOMPLETE (fi-ivb-3770)

fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:202  pass:171  dwarn:0   dfail:0   fail:0   skip:30 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2528/

208290026552464713d3897ab5d649f4445d5513 drm-intel-nightly: 
2016y-09m-13d-14h-45m-32s UTC integration manifest
422c489 drm/i915: Support explicit fencing for execbuf
f78943a drm/i915: Enable userspace to opt-out of implicit fencing
93acb19 drm/i915: Enable multiple timelines
7b8232a drm/i915: Reserve space in the global seqno during request allocation
c972275 drm/i915: Create a unique name for the context
6c8fa4a drm/i915: Move the global sync optimisation to the timeline
27f5fd8 drm/i915: Defer request emission
e0e3346 drm/i915: Record space required for request emission
6cbf7e2 drm/i915: Introduce a global_seqno for each request
279611d drm/i915: Wait first for submission, before waiting for request 
completion
ec2ccb1 drm/i915: Combine seqno + tracking into a global timeline struct
c5ca7a3 drm/i915: Restore nonblocking awaits for modesetting
435dc25 drm: Add reference counting to drm_atomic_state
bc1da87 drm/i915: Move GEM activity tracking into a common struct 
reservation_object
354aa03 drm/i915: Remove unused i915_gem_active_wait() in favour of _unlocked()
39f214d drm/i915: Rearrange i915_wait_request() accounting with callers
459763e drm/i915: Allow i915_sw_fence_await_sw_fence() to allocate
83aaab6 drm/i915: Support asynchronous waits on struct fence from 
i915_gem_request

___
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: Add ddb size field to device info structure (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Add ddb size field to device info structure (rev2)
URL   : https://patchwork.freedesktop.org/series/12427/
State : success

== Summary ==

Series 12427v2 drm/i915: Add ddb size field to device info structure
https://patchwork.freedesktop.org/api/1.0/series/12427/revisions/2/mbox/


fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-hsw-4770k total:244  pass:226  dwarn:0   dfail:0   fail:0   skip:18 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:183  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2529/

0c7c6ebb924db723ecabc2521e2afa71beeec471 drm-intel-nightly: 
2016y-09m-14d-07h-41m-42s UTC integration manifest
67b040a drm/i915: Add ddb size field to device info structure

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

Re: [Intel-gfx] [PATCH 04/18] drm/i915: Remove unused i915_gem_active_wait() in favour of _unlocked()

[Joonas Lahtinen]

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> Since we only use the more generic unlocked variant, just rename it as
> the normal i915_gem_active_wait(). The temporary cost is that we need to
> always acquire the reference in a RCU safe manner, but the benefit is
> that we will combine the common paths.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 03/18] drm/i915: Rearrange i915_wait_request() accounting with callers

[Joonas Lahtinen]

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +int
> +i915_gem_object_wait(struct drm_i915_gem_object *obj,
> +  unsigned int flags,
> +  long timeout,
> +  struct intel_rps_client *rps)
>  {
>  

[...]

> - return 0;
> + resv = i915_gem_object_get_dmabuf_resv(obj);
> + if (resv)
> + timeout = i915_gem_object_wait_reservation(resv,
> +    flags, timeout,
> +    rps);
> + return timeout < 0 ? timeout : timeout > 0 ? 0 : -ETIME;

Format this in a more readable manner eg.;

return timeout == 0 ? -ETIME :
       timeout < 0 ? timeout :
       0;

>  
>  static struct intel_rps_client *to_rps_client(struct drm_file *file)
> @@ -454,7 +542,13 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
>   /* We manually control the domain here and pretend that it
>    * remains coherent i.e. in the GTT domain, like shmem_pwrite.
>    */
> - ret = i915_gem_object_wait_rendering(obj, false);
> + lockdep_assert_held(>base.dev->struct_mutex);

Bump this before the comment to the beginning of function like
elsehwere.

> @@ -2804,17 +2923,21 @@ i915_gem_wait_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *file)
>   if (!obj)
>   return -ENOENT;
>  
> - active = __I915_BO_ACTIVE(obj);
> - for_each_active(active, idx) {
> - s64 *timeout = args->timeout_ns >= 0 ? >timeout_ns : NULL;
> - ret = i915_gem_active_wait_unlocked(>last_read[idx],
> - I915_WAIT_INTERRUPTIBLE,
> - timeout, rps);
> - if (ret)
> - break;
> + start = ktime_get();
> +
> + ret = i915_gem_object_wait(obj,
> +    I915_WAIT_INTERRUPTIBLE | I915_WAIT_ALL,
> +    args->timeout_ns < 0 ? MAX_SCHEDULE_TIMEOUT 
> : nsecs_to_jiffies(args->timeout_ns),

Do break this line, plz.

Maybe just have long timeout = MAX_SCHEDULE_TIMEOUT; in the beginning
of file, then do if (args->timeout_ns >= 0) before the function, it
matches the after function if nicely.


> +    to_rps_client(file));
> +
> + if (args->timeout_ns > 0) {

And as we have this.

> + args->timeout_ns -= ktime_to_ns(ktime_sub(ktime_get(), start));
> + if (args->timeout_ns < 0)
> + args->timeout_ns = 0;
>   }
>  
>   i915_gem_object_put_unlocked(obj);
> +
>   return ret;
>  }
> 



> 
> @@ -3598,7 +3732,13 @@ i915_gem_object_set_to_cpu_domain(struct 
> drm_i915_gem_object *obj, bool write)
>   uint32_t old_write_domain, old_read_domains;
>   int ret;
>  
> - ret = i915_gem_object_wait_rendering(obj, !write);
> + lockdep_assert_held(>base.dev->struct_mutex);

I'd add a newline here like elsewhere.

> + ret = i915_gem_object_wait(obj,
> +    I915_WAIT_INTERRUPTIBLE |
> +    I915_WAIT_LOCKED |
> +    (write ? I915_WAIT_ALL : 0),
> +    MAX_SCHEDULE_TIMEOUT,
> +    NULL);
>   if (ret)
>   return ret;
>  
> @@ -3654,11 +3794,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct 
> drm_file *file)
>   struct drm_i915_file_private *file_priv = file->driver_priv;
>   unsigned long recent_enough = jiffies - DRM_I915_THROTTLE_JIFFIES;
>   struct drm_i915_gem_request *request, *target = NULL;
> - int ret;
> -
> - ret = i915_gem_wait_for_error(_priv->gpu_error);
> - if (ret)
> - return ret;

Unsure how this is related to the changes, need to explain in commit
message or I nominate this a lost hunk.

With those addressed,

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Allow i915_sw_fence_await_sw_fence() to allocate

[Chris Wilson]

On Wed, Sep 14, 2016 at 10:51:12AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > @@ -678,7 +678,7 @@ void __i915_add_request(struct drm_i915_gem_request 
> > *request, bool flush_caches)
> >        >i915->drm.struct_mutex);
> >     if (prev)
> >     i915_sw_fence_await_sw_fence(>submit, >submit,
> > -    >submitq);
> > +    >submitq, GFP_NOWAIT);
> 
> Wrt commit message, why do we pass both here? If one was to run
> statistic analysis, !wq is never true if you pass  here.

Only because GFP_NOWAIT was descriptive, and cleaner than say
(__force gfp_t)0

> > @@ -135,6 +135,8 @@ static int i915_sw_fence_wake(wait_queue_t *wq, 
> > unsigned mode, int flags, void *
> >     list_del(>task_list);
> >     __i915_sw_fence_complete(wq->private, key);
> >     i915_sw_fence_put(wq->private);
> > +   if (wq->flags)
> > +   kfree(wq);
> 
> This is confusing without a comment or proper flag #define.
> 
> >     INIT_LIST_HEAD(>task_list);
> > -   wq->flags = 0;
> > +   wq->flags = pending;
> 
> Why not make this look proper by using I915_SW_FENCE_FLAG_FOO name.
> 
> > +static inline void i915_sw_fence_wait(struct i915_sw_fence *fence)
> > +{
> > +   wait_event(fence->wait, i915_sw_fence_done(fence));
> > +}
> > +
> 
> This seems to be a lost-in-rebasing hunk.

I snuck in a use along the oom path to justify it here (and avoid having
to magic it out of nowhere later).
-Chris

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

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

[ch...@chris-wilson.co.uk]

On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote:
> Mika Kuoppala  writes:
> > "Zanoni, Paulo R"  writes:
> >>> +#if IS_ENABLED(CONFIG_LOCKDEP)
> >>> + GEM_BUG_ON(!!lockdep_is_held(>i915->drm.struct_mutex)
> >>> !=
> >>> +    !!(flags & I915_WAIT_LOCKED));
> >>> +#endif
> >>
> >> I'm hitting this on my SKL. It usually happens right after the login,
> >> when I click the terminal icon on the toolbar in order to open it (on
> >> Cinnamon). When it doesn't happen at that time, I just open a browser
> >> and browse for like 30 seconds until it happens.
> >>
> >> I did manual reverts of this series up to this patch and obviously the
> >> problem goes away (no more GEM_BUG_ON to hit). I didn't try to do a
> >> real bisect to check if this is the first bad commit or if it's
> >> something later on the series. It could even be an older problem that
> >> just got exposed by the new BUG(). I'm available to test patches, just
> >> send them to me.
> >
> > No patches yet but there is a comment on 
> > intel_prepare_plane_fb() that says that it must be called with mutex
> > held.
> >
> > Quite likely the new GEM_BUG_ON catches this not being true.
> >
> 
> As Chris pointed out in irc, its about the reverse. Waiting
> with mutex when you shouldn't.

Fwiw, the fix is now on the list.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Ignore OpRegion panel type except on select machines

[James Hogan]

On 13 September 2016 at 10:22,   wrote:
> From: Ville Syrjälä 
>
> Turns out
> commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
> details") has regressed quite a few machines. So it looks like we
> can't use the panel type from OpRegion on all systems, and yet we
> absolutely must use it on some specific systems.
>
> Despite trying, I was unable to find any automagic way to determine
> if the OpRegion panel type is respectable or not. The only glimmer
> of hope I had was bit 8 in the SCIC response, but that turned out to
> not work either (it was always 0 on both types of systems).
>
> So, to fix the regressions without breaking the machine we know to need
> the OpRegion panel type, let's just add a quirk for this. Only specific
> machines known to require the OpRegion panel type will therefore use
> it. Everyone else will fall bck to the VBT panel type.
>
> The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
> subsystem ID on this machine is just a generic 8086:2a42, so of no use.
> Instead we'll go with a DMI match.
>
> I suspect we can now also revert
> commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
> but let's leave that to a separate patch.
>
> v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
> gets populated too late
>
> Cc: Rob Kramer 
> Cc: Martin van Es 
> Cc: Andrea Arcangeli 
> Cc: Dave Airlie 
> Cc: Marco Krüger 
> Cc: Sean Greenslade 
> Cc: Trudy Tective 
> Cc: Robin Müller 
> Cc: Alexander Kobel 
> Cc: Alexey Shumitsky 
> Cc: Emil Andersen Lauridsen 
> Cc: oceans...@gmail.com
> Cc: James Hogan 
> Cc: James Bottomley 
> Cc: sta...@vger.kernel.org
> References: 
> https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
> References: 
> https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
> References: 
> https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363
> Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details")
> Tested-by: Marco Krüger 
> Tested-by: Alexey Shumitsky 
> Tested-by: Sean Greenslade 
> Tested-by: Emil Andersen Lauridsen 
> Tested-by: Robin Müller 
> Tested-by: oceans...@gmail.com
> Signed-off-by: Ville Syrjälä 

That works for me too on XPS13. Flickering screen brightness gone, and
using acpi backlight rather than intel backlight, like before
a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details").

Tested-by: James Hogan 

Thanks!
James

> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index adca262d591a..7acbbbf97833 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1047,6 +1047,23 @@ err_out:
> return err;
>  }
>
> +static int intel_use_opregion_panel_type_callback(const struct dmi_system_id 
> *id)
> +{
> +   DRM_INFO("Using panel type from OpRegion on %s\n", id->ident);
> +   return 1;
> +}
> +
> +static const struct dmi_system_id intel_use_opregion_panel_type[] = {
> +   {
> +   .callback = intel_use_opregion_panel_type_callback,
> +   .ident = "Conrac GmbH IX45GM2",
> +   .matches = {DMI_MATCH(DMI_SYS_VENDOR, "Conrac GmbH"),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "IX45GM2"),
> +   },
> +   },
> +   { }
> +};
> +
>  int
>  intel_opregion_get_panel_type(struct drm_i915_private *dev_priv)
>  {
> @@ -1073,6 +1090,16 @@ intel_opregion_get_panel_type(struct drm_i915_private 
> *dev_priv)
> }
>
> /*
> +* So far we know that some machined must use it, others must not use 
> it.
> +* There doesn't seem to be any way to determine which way to go, 
> except
> +* via a quirk list :(
> +*/
> +   if (!dmi_check_system(intel_use_opregion_panel_type)) {
> +   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> +   return -ENODEV;
> +   }
> +
> +   /*
>  * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
>  * low vswing for eDP, 

[Intel-gfx] [PATCH] drm/i915: Add ddb size field to device info structure

[Deepak M]

Adding the ddb size into the devide info will avoid
platform checks while computing wm.

v2: Added comment and WARN_ON if ddb size is zero.(Jani)

Suggested-by: Ander Conselvan de Oliveira 

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_pci.c |  5 +
 drivers/gpu/drm/i915/intel_pm.c | 15 +++
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e2dda8..6014c3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -710,6 +710,7 @@ struct intel_device_info {
u8 ring_mask; /* Rings supported by the HW */
u8 num_rings;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
+   u16 ddb_size; /* in blocks */
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
int trans_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d771870d..687c768 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -328,6 +328,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
@@ -336,6 +337,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
@@ -358,6 +360,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_hw_contexts = 1,
.has_logical_ring_contexts = 1,
.has_guc = 1,
+   .ddb_size = 512,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
@@ -369,6 +372,7 @@ static const struct intel_device_info intel_kabylake_info = 
{
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
 };
 
 static const struct intel_device_info intel_kabylake_gt3_info = {
@@ -377,6 +381,7 @@ static const struct intel_device_info 
intel_kabylake_gt3_info = {
.gen = 9,
.has_csr = 1,
.has_guc = 1,
+   .ddb_size = 896,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6af438f..9c5861e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2853,13 +2853,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
 }
 
-/*
- * On gen9, we need to allocate Display Data Buffer (DDB) portions to the
- * different active planes.
- */
-
-#define SKL_DDB_SIZE   896 /* in blocks */
-#define BXT_DDB_SIZE   512
 #define SKL_SAGV_BLOCK_TIME30 /* µs */
 
 /*
@@ -3057,13 +3050,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
*dev,
else
*num_active = hweight32(dev_priv->active_crtcs);
 
-   if (IS_BROXTON(dev))
-   ddb_size = BXT_DDB_SIZE;
-   else
-   ddb_size = SKL_DDB_SIZE;
-
+   ddb_size = INTEL_INFO(dev_priv)->ddb_size;
ddb_size -= 4; /* 4 blocks for bypass path allocation */
 
+   WARN_ON(ddb_size == 0);
+
/*
 * If the state doesn't change the active CRTC's, then there's
 * no need to recalculate; the existing pipe allocation limits
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Fallback to lower link rate and lane count during link training

[Mika Kahola]

On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> According to the DisplayPort Spec, in case of Clock Recovery failure
> the link training sequence should fall back to the lower link rate
> followed by lower lane count until CR succeeds.
> On CR success, the sequence proceeds with Channel EQ.
> In case of Channel EQ failures, it should fallback to
> lower link rate and lane count and start the CR phase again.
> 
> v5:
> * Reset the link rate index to the max link rate index
> before lowering the lane count (Jani Nikula)
> * Use the paradigm for loop in intel_dp_link_rate_index
> v4:
> * Fixed the link rate fallback loop (Manasi Navare)
> v3:
> * Fixed some rebase issues (Mika Kahola)
> v2:
> * Add a helper function to return index of requested link rate
> into common_rates array
> * Changed the link rate fallback loop to make use
> of common_rates array (Mika Kahola)
> * Changed INTEL_INFO to INTEL_GEN (David Weinehall)
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 112
> +++---
>  drivers/gpu/drm/i915/intel_dp.c   |  15 
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
>  drivers/gpu/drm/i915/intel_drv.h  |   6 +-
>  4 files changed, 131 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8065a5f..4d3a931 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1637,19 +1637,18 @@ void intel_ddi_clk_select(struct
> intel_encoder *encoder,
>   }
>  }
>  
> -static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> +static void intel_ddi_pre_enable_edp(struct intel_encoder *encoder,
>   int link_rate, uint32_t
> lane_count,
> - struct intel_shared_dpll *pll,
> - bool link_mst)
> + struct intel_shared_dpll *pll)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
>  
>   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> -  link_mst);
> - if (encoder->type == INTEL_OUTPUT_EDP)
> - intel_edp_panel_on(intel_dp);
> +  false);
> +
> + intel_edp_panel_on(intel_dp);
>  
>   intel_ddi_clk_select(encoder, pll);
>   intel_prepare_dp_ddi_buffers(encoder);
> @@ -1660,6 +1659,28 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>   intel_dp_stop_link_train(intel_dp);
>  }
>  
> +static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> + int link_rate, uint32_t
> lane_count,
> + struct intel_shared_dpll *pll,
> + bool link_mst)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> + struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
> + struct intel_shared_dpll_config tmp_pll_config;
> +
> + /* Disable the PLL and obtain the PLL for Link Training
> +  * that starts with highest link rate and lane count.
> +  */
> + tmp_pll_config = pll->config;
> + pll->funcs.disable(dev_priv, pll);
> + pll->config.crtc_mask = 0;
> +
> + /* If Link Training fails, send a uevent to generate a
> hotplug */
> + if (!intel_ddi_link_train(intel_dp, link_rate, lane_count,
> link_mst))
> + drm_kms_helper_hotplug_event(encoder->base.dev);
> + pll->config = tmp_pll_config;
> +}
> +
>  static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
>     bool has_hdmi_sink,
>     struct drm_display_mode
> *adjusted_mode,
> @@ -1693,20 +1714,26 @@ static void intel_ddi_pre_enable(struct
> intel_encoder *intel_encoder,
>   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>   int type = intel_encoder->type;
>  
> - if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> + if (type == INTEL_OUTPUT_EDP)
> + intel_ddi_pre_enable_edp(intel_encoder,
> + crtc->config->port_clock,
> + crtc->config->lane_count,
> + crtc->config->shared_dpll);
> +
> + if (type == INTEL_OUTPUT_DP)
>   intel_ddi_pre_enable_dp(intel_encoder,
>   crtc->config->port_clock,
>   crtc->config->lane_count,
>   crtc->config->shared_dpll,
>   intel_crtc_has_type(crtc-
> >config,
>   INTEL_OU
> TPUT_DP_MST));
> 

Re: [Intel-gfx] [PATCH] drm/i915: Add ddb size field to device info structure

[Jani Nikula]

On Wed, 14 Sep 2016, Deepak M  wrote:
> Adding the ddb size into the devide info will avoid
> platform checks while computing wm.
>
> Suggested-by: Ander Conselvan de Oliveira 
> 
> Signed-off-by: Deepak M 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_pci.c |  5 +
>  drivers/gpu/drm/i915/intel_pm.c | 13 +
>  3 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1e2dda8..4518ef3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -710,6 +710,7 @@ struct intel_device_info {
>   u8 ring_mask; /* Rings supported by the HW */
>   u8 num_rings;
>   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> + u16 ddb_size;

This could use the /* in blocks */ comment.

>   /* Register offsets for the various display pipes and transcoders */
>   int pipe_offsets[I915_MAX_TRANSCODERS];
>   int trans_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index d771870d..687c768 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -328,6 +328,7 @@ static const struct intel_device_info intel_skylake_info 
> = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>  };
>  
>  static const struct intel_device_info intel_skylake_gt3_info = {
> @@ -336,6 +337,7 @@ static const struct intel_device_info 
> intel_skylake_gt3_info = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> @@ -358,6 +360,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_hw_contexts = 1,
>   .has_logical_ring_contexts = 1,
>   .has_guc = 1,
> + .ddb_size = 512,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
>   BDW_COLORS,
> @@ -369,6 +372,7 @@ static const struct intel_device_info intel_kabylake_info 
> = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>  };
>  
>  static const struct intel_device_info intel_kabylake_gt3_info = {
> @@ -377,6 +381,7 @@ static const struct intel_device_info 
> intel_kabylake_gt3_info = {
>   .gen = 9,
>   .has_csr = 1,
>   .has_guc = 1,
> + .ddb_size = 896,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6af438f..7eeb73b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2853,13 +2853,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
>   return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
>  }
>  
> -/*
> - * On gen9, we need to allocate Display Data Buffer (DDB) portions to the
> - * different active planes.
> - */
> -
> -#define SKL_DDB_SIZE 896 /* in blocks */
> -#define BXT_DDB_SIZE 512
>  #define SKL_SAGV_BLOCK_TIME  30 /* µs */
>  
>  /*
> @@ -3057,11 +3050,7 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   else
>   *num_active = hweight32(dev_priv->active_crtcs);
>  
> - if (IS_BROXTON(dev))
> - ddb_size = BXT_DDB_SIZE;
> - else
> - ddb_size = SKL_DDB_SIZE;
> -
> + ddb_size = INTEL_INFO(dev_priv)->ddb_size;

I'd perhaps stick a WARN_ON(ddb_size == 0) here.

With those fixed,

Reviewed-by: Jani Nikula 


>   ddb_size -= 4; /* 4 blocks for bypass path allocation */
>  
>   /*

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

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Pavel Machek]

On Wed 2016-09-14 10:38:18, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
> > Hi!
> >
> >> I have
> >> 
> >> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> >> Integrated Graphics Controller (rev 03)
> >> 
> >> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> >> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> >> powersave) and all windows move to secondary monitor (VGA). Running
> >> "xrandr" fixes that.
> >> 
> >> I'll update to newer rc and see if it happens again, but if you have
> >> any ideas, now would be good time.
> >
> > Ok. With -rc6, X are completely broken. I got notification "could not
> > restore CRTC config for screen 63" or something like that, and window
> > manager just does not start.
> 
> Ugh. Can you bisect from v4.7, assuming it worked? That's probably the
> fastest way to resolve this.

The "completely broken" part -- something broke in my userland, as
booting to the old kernel does not fix it. I'll have to figure it out.

For the "sometimes need xrandr after resume": I don't think I can
bisect that. It only happens sometimes :-(. But there's something
helpful in the logs:

Best regards,
Pavel

[ 1856.213154] CPU1 is up
[ 1856.213167] ACPI: Waking up from system sleep state S3
[ 1856.217998] clocksource: Switched to clocksource hpet
[ 1856.218170] uhci_hcd :00:1d.0: System wakeup disabled by ACPI
[ 1856.218470] uhci_hcd :00:1d.2: System wakeup disabled by ACPI
[ 1856.218656] uhci_hcd :00:1d.1: System wakeup disabled by ACPI
[ 1856.218665] uhci_hcd :00:1d.3: System wakeup disabled by ACPI
[ 1856.218863] ehci-pci :00:1d.7: System wakeup disabled by ACPI
[ 1856.218863] PM: noirq resume of devices complete after 19.597 msecs
[ 1856.218863] PM: early resume of devices complete after 1.092 msecs
[ 1856.218863] usb usb2: root hub lost power or was reset
[ 1856.218863] usb usb3: root hub lost power or was reset
[ 1856.218863] usb usb4: root hub lost power or was reset
[ 1856.218863] usb usb5: root hub lost power or was reset
[ 1856.218863] pcieport :00:1c.1: System wakeup disabled by ACPI
[ 1856.218863] serial 00:03: activated
[ 1856.218863] parport_pc 00:04: activated
[ 1856.218863] rtc_cmos 00:05: System wakeup disabled by ACPI
[ 1856.218863] ata2: port disabled--ignoring
[ 1856.218863] r8169 :03:00.0 eth0: link down
[ 1856.218863] sd 2:0:0:0: [sda] Starting disk
[ 1856.218863] sd 2:0:1:0: [sdb] Starting disk
[ 1856.218863] ata4.01: NODEV after polling detection
[ 1856.218863] ata3.01: ACPI cmd ef/03:45:00:00:00:b0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.01: ACPI cmd ef/03:0c:00:00:00:b0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.01: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE
LOCK) filtered out
[ 1856.218863] ata3.00: ACPI cmd ef/03:45:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata3.00: ACPI cmd c6/00:10:00:00:00:a0 (SET MULTIPLE
MODE) succeeded
[ 1856.218863] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE
LOCK) filtered out
[ 1856.218863] ata3.00: configured for UDMA/133
[ 1856.218863] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES)
filtered out
[ 1856.218863] ata4.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE
LOCK) filtered out
[ 1856.218863] ata3.01: configured for UDMA/133
[ 1856.218863] ata4.00: configured for UDMA/133
[ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
[ 1856.218863] Raw EDID:
[ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
[ 1856.218863] Raw EDID:
[ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 1856.218863] 

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Allow i915_sw_fence_await_sw_fence() to allocate

[Joonas Lahtinen]

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -678,7 +678,7 @@ void __i915_add_request(struct drm_i915_gem_request 
> *request, bool flush_caches)
>      >i915->drm.struct_mutex);
>   if (prev)
>   i915_sw_fence_await_sw_fence(>submit, >submit,
> -  >submitq);
> +  >submitq, GFP_NOWAIT);

Wrt commit message, why do we pass both here? If one was to run
statistic analysis, !wq is never true if you pass  here.

> @@ -135,6 +135,8 @@ static int i915_sw_fence_wake(wait_queue_t *wq, unsigned 
> mode, int flags, void *
>   list_del(>task_list);
>   __i915_sw_fence_complete(wq->private, key);
>   i915_sw_fence_put(wq->private);
> + if (wq->flags)
> + kfree(wq);

This is confusing without a comment or proper flag #define.

>   INIT_LIST_HEAD(>task_list);
> - wq->flags = 0;
> + wq->flags = pending;

Why not make this look proper by using I915_SW_FENCE_FLAG_FOO name.

> +static inline void i915_sw_fence_wait(struct i915_sw_fence *fence)
> +{
> + wait_event(fence->wait, i915_sw_fence_done(fence));
> +}
> +

This seems to be a lost-in-rebasing hunk.

Above addressed;

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Jani Nikula  wrote:
> On Wed, 14 Sep 2016, Pavel Machek  wrote:
>> Hi!
>>
>>> I have
>>> 
>>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>>> Integrated Graphics Controller (rev 03)
>>> 
>>> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
>>> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
>>> powersave) and all windows move to secondary monitor (VGA). Running
>>> "xrandr" fixes that.
>>> 
>>> I'll update to newer rc and see if it happens again, but if you have
>>> any ideas, now would be good time.
>>
>> Ok. With -rc6, X are completely broken. I got notification "could not
>> restore CRTC config for screen 63" or something like that, and window
>> manager just does not start.
>
> Ugh. Can you bisect from v4.7, assuming it worked? That's probably the
> fastest way to resolve this.

Also, if you don't mind, please file a bug at [1], attaching the logs
there. It'll be easier for me to direct attention and priority to the
bug, which will help you too in the end.

Thanks,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel

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

Re: [Intel-gfx] [PATCH] drm/i915: Ignore OpRegion panel type except on select machines

[Ville Syrjälä]

On Tue, Sep 13, 2016 at 12:37:16PM +0300, Jani Nikula wrote:
> On Tue, 13 Sep 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Turns out
> > commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
> > details") has regressed quite a few machines. So it looks like we
> > can't use the panel type from OpRegion on all systems, and yet we
> > absolutely must use it on some specific systems.
> >
> > Despite trying, I was unable to find any automagic way to determine
> > if the OpRegion panel type is respectable or not. The only glimmer
> > of hope I had was bit 8 in the SCIC response, but that turned out to
> > not work either (it was always 0 on both types of systems).
> >
> > So, to fix the regressions without breaking the machine we know to need
> > the OpRegion panel type, let's just add a quirk for this. Only specific
> > machines known to require the OpRegion panel type will therefore use
> > it. Everyone else will fall bck to the VBT panel type.
> >
> > The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
> > subsystem ID on this machine is just a generic 8086:2a42, so of no use.
> > Instead we'll go with a DMI match.
> >
> > I suspect we can now also revert
> > commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
> > but let's leave that to a separate patch.
> >
> > v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
> > gets populated too late
> >
> > Cc: Rob Kramer 
> > Cc: Martin van Es 
> > Cc: Andrea Arcangeli 
> > Cc: Dave Airlie 
> > Cc: Marco Krüger 
> > Cc: Sean Greenslade 
> > Cc: Trudy Tective 
> > Cc: Robin Müller 
> > Cc: Alexander Kobel 
> > Cc: Alexey Shumitsky 
> > Cc: Emil Andersen Lauridsen 
> > Cc: oceans...@gmail.com
> > Cc: James Hogan 
> > Cc: James Bottomley 
> > Cc: sta...@vger.kernel.org
> > References: 
> > https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
> > References: 
> > https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
> > References: 
> > https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
> 
> References: 
> http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienve...@gmail.com
> 
> Acked-by: Jani Nikula 
> 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363
> > Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details")
> > Tested-by: Marco Krüger 
> > Tested-by: Alexey Shumitsky 
> > Tested-by: Sean Greenslade 
> > Tested-by: Emil Andersen Lauridsen 
> > Tested-by: Robin Müller 
> > Tested-by: oceans...@gmail.com
> > Signed-off-by: Ville Syrjälä 

Slapped on another tested-by and pushed to dinq. Thanks for the broad
testing, everyone.

> > ---
> >  drivers/gpu/drm/i915/intel_opregion.c | 27 +++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> > b/drivers/gpu/drm/i915/intel_opregion.c
> > index adca262d591a..7acbbbf97833 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -1047,6 +1047,23 @@ err_out:
> > return err;
> >  }
> >  
> > +static int intel_use_opregion_panel_type_callback(const struct 
> > dmi_system_id *id)
> > +{
> > +   DRM_INFO("Using panel type from OpRegion on %s\n", id->ident);
> > +   return 1;
> > +}
> > +
> > +static const struct dmi_system_id intel_use_opregion_panel_type[] = {
> > +   {
> > +   .callback = intel_use_opregion_panel_type_callback,
> > +   .ident = "Conrac GmbH IX45GM2",
> > +   .matches = {DMI_MATCH(DMI_SYS_VENDOR, "Conrac GmbH"),
> > +   DMI_MATCH(DMI_PRODUCT_NAME, "IX45GM2"),
> > +   },
> > +   },
> > +   { }
> > +};
> > +
> >  int
> >  intel_opregion_get_panel_type(struct drm_i915_private *dev_priv)
> >  {
> > @@ -1073,6 +1090,16 @@ intel_opregion_get_panel_type(struct 
> > drm_i915_private *dev_priv)
> > }
> >  
> > /*
> > +* So far we know that some machined must use it, others must not use 
> > it.
> > +* There doesn't seem to be any way to determine which way to go, except
> > +* via a quirk list :(
> > +*/
> > +   if (!dmi_check_system(intel_use_opregion_panel_type)) {
> > +   DRM_DEBUG_KMS("Ignoring OpRegion panel type 

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Pavel Machek]

On Tue 2016-09-13 22:38:45, Martin Steigerwald wrote:
> Hi.
> 
> Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek: 
> > I have
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (rev 03)
> 
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation 
> Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
> 
> Phoronix Test Suite system-info:

...
> > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> > in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> > powersave) and all windows move to secondary monitor (VGA). Running
> > "xrandr" fixes that.
> 
> I have seen this in 4.8 up to rc5 as well. I am not sure yet about rc6 which 
> I 
> am currently running.

Ok, it happened again today, with yesterdays version of 4.8-rc6. I'm
glad I'm not the only one.

Intel folks, any ideas? Can you reproduce it?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Jani Nikula]

On Wed, 14 Sep 2016, Pavel Machek  wrote:
> Hi!
>
>> I have
>> 
>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>> Integrated Graphics Controller (rev 03)
>> 
>> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
>> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
>> powersave) and all windows move to secondary monitor (VGA). Running
>> "xrandr" fixes that.
>> 
>> I'll update to newer rc and see if it happens again, but if you have
>> any ideas, now would be good time.
>
> Ok. With -rc6, X are completely broken. I got notification "could not
> restore CRTC config for screen 63" or something like that, and window
> manager just does not start.

Ugh. Can you bisect from v4.7, assuming it worked? That's probably the
fastest way to resolve this.

BR,
Jani.

>
> X log is attached as delme, kernel log as delme2. Nothing too
> suspicious :-(.
>
>   Pavel

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