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

2016-09-19 Thread Patchwork
== Series Details ==

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

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
pass   -> SKIP   (fi-hsw-4770r)
Subgroup read-crc-pipe-b:
pass   -> SKIP   (fi-hsw-4770r)

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-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:220  dwarn:0   dfail:0   fail:0   skip:24 
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   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_2558/

4c518aef024daa0223692124baa2d7399f54dd97 drm-intel-nightly: 
2016y-09m-19d-20h-40m-51s UTC integration manifest
cf4f6db drm/i915: start adding dp mst audio
35f6d98 drm/i915: Move audio_connector to intel_encoder
99dc209 drm/i915: Switch to using port stored in intel_encoder
2ff487f drm/i915: Store port enum in intel_encoder
909c816 drm/i915: Standardize port type for DVO encoders

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


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

2016-09-19 Thread 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 27b0e34..1384da5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2865,6 +2865,20 @@ static void intel_dp_info(struct seq_file *m,
_dp->aux);
 }
 
+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)
 {
@@ -2907,7 +2921,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 daf3adb..24275e9 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);
 
pipe_config->pbn = 

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

2016-09-19 Thread Dhinakaran Pandiyan
From: "Pandiyan, Dhinakaran" 

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 
Reviewed-by: Lyude 
---
 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 v7 3/5] drm/i915: Switch to using port stored in intel_encoder

2016-09-19 Thread Dhinakaran Pandiyan
From: "Pandiyan, Dhinakaran" 

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] [PATCH v7 4/5] drm/i915: Move audio_connector to intel_encoder

2016-09-19 Thread Dhinakaran Pandiyan
From: "Pandiyan, Dhinakaran" 

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 972040a..cf92bc0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -248,6 +248,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 {
@@ -959,8 +961,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 v7 2/5] drm/i915: Store port enum in intel_encoder

2016-09-19 Thread Dhinakaran Pandiyan
From: "Pandiyan, Dhinakaran" 

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 
Reviewed-by: Lyude 
---
 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 4dd307e..270543c 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 8065a5f..daf3adb 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 acd0c51..0568fb5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5832,6 +5832,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 8fd16ad..972040a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -206,6 +206,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-gfx] [PATCH v7 0/5] Prep. for DP audio MST support

2016-09-19 Thread Dhinakaran Pandiyan
This series lays the groundwork for more DP MST audio work that will
follow.

v7:
Added R-B tags and rebased.

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

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

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

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.

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)

Pandiyan, Dhinakaran (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] [PATCH] tests/kms_psr_sink_crc: commit before querying mode

2016-09-19 Thread Rodrigo Vivi
From: Mika Kuoppala 

Commit to a mode before querying it.

Tested-by: Rodrigo Vivi 
References: https://bugs.freedesktop.org/show_bug.cgi?id=97172
Cc: Maarten Lankhorst 
Signed-off-by: Mika Kuoppala 
Signed-off-by: Rodrigo Vivi 
---
 tests/kms_psr_sink_crc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 8aafedb..68310d8 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -112,6 +112,14 @@ static void setup_output(data_t *data)
continue;
 
igt_output_set_pipe(output, pipe);
+   igt_display_commit(display);
+
+   if (!output->valid) {
+   igt_output_set_pipe(output, PIPE_ANY);
+   igt_display_commit(display);
+   continue;
+   }
+
data->crtc_id = output->config.crtc->crtc_id;
data->output = output;
data->mode = igt_output_get_mode(output);
-- 
1.9.1

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Fix typo in encoder docs

2016-09-19 Thread Patchwork
== Series Details ==

Series: drm: Fix typo in encoder docs
URL   : https://patchwork.freedesktop.org/series/12666/
State : warning

== Summary ==

Series 12666v1 drm: Fix typo in encoder docs
https://patchwork.freedesktop.org/api/1.0/series/12666/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> SKIP   (fi-hsw-4770r)

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-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: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   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_2557/

4c518aef024daa0223692124baa2d7399f54dd97 drm-intel-nightly: 
2016y-09m-19d-20h-40m-51s UTC integration manifest
991a333 drm: Fix typo in encoder docs

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


[Intel-gfx] [PATCH] drm: Fix typo in encoder docs

2016-09-19 Thread Dhinakaran Pandiyan
Corrected typo in bridge and encoder comparison. Also, added a one-line
encoder description from the previous documentation.

Cc: Daniel Vetter 
Cc: Archit Taneja 

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_encoder.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 998a674..5c06771 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -31,20 +31,21 @@
  *
  * 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
- * 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.
+ * generic sink entity, represented by struct _connector). An encoder takes
+ * pixel data from a CRTC and converts it to a format suitable for any attached
+ * connector. Encoders are 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 today's hardware, 
and
+ * the recommended 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 code sharing. But for more complex settings it is
  * usually better to move shared code into a separate _bridge. Compared to
- * encoders bridges also have the benefit of not being purely an internal
+ * encoders, bridges also have the benefit of being purely an internal
  * abstraction since they are not exposed to userspace at all.
  *
  * Encoders are initialized with drm_encoder_init() and cleaned up using
-- 
2.5.0

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


Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Decode system memory bandwidth

2016-09-19 Thread Paulo Zanoni
Hi

Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar 
> 
> This patch adds support to decode system memory bandwidth
> which will be used for arbitrated display memory percentage
> calculation in GEN9 based system.

This is not a complete review of this patch since I can't find the
documentation for the registers used by the patch, but I'll try to
provide some early feedback. Most of it is about styling, so feel free
to provide counter arguments if you disagree.

> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 96
> +
>  drivers/gpu/drm/i915/i915_drv.h | 18 
>  drivers/gpu/drm/i915/i915_reg.h | 25 +++
>  3 files changed, 139 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 02c34d6..0a4f18d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -973,6 +973,96 @@ static void intel_sanitize_options(struct
> drm_i915_private *dev_priv)
>   DRM_DEBUG_DRIVER("use GPU sempahores? %s\n",
> yesno(i915.semaphores));
>  }
>  
> +static void
> +intel_get_memdev_info(struct drm_device *dev)

In our current standards we prefer that you use drm_i915_private as the
parameter here. And the new function doesn't even use drm_device for
anything, so that reinforces the argument.


> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + uint32_t val = 0;
> + uint32_t mem_speed = 0;
> + uint8_t dram_type;
> + uint32_t dram_channel;
> + uint8_t num_channel;
> + bool rank_valid = false;

We generally don't zero-initialize things that don't need to be zero-
initialized, like these 3 variables. I know this is an eternal
discussion and each side has pros and cons, but following the already
used coding style usually wins.


Also, please just add this:

struct memdev_info *memdev_info = _priv->memdev_info;

All those "dev_priv->memdev_info" statements below are already making
my fingers hurt, and I didn't even type them :)


> +
> + if (!IS_GEN9(dev_priv))
> + goto exit;

If you just set memdev_info.valid to false right at the beginning of
the function then you can just return here and below without using the
goto. IMHO it will look better. Or you could even rely on the fact that
we used kzalloc anyway.


> +
> + val = I915_READ(P_CR_MC_BIOS_REQ_0_0_0);
> + mem_speed = div_u64((uint64_t) (val & REQ_DATA_MASK) *
> + MEMORY_FREQ_MULTIPLIER, 1000);
> +
> + if (mem_speed == 0)
> + goto exit;

Perhaps a DRM_DEBUG_KMS("something something memory data is not valid")
would be useful here too.


> +
> + dev_priv->memdev_info.valid = true;
> + dev_priv->memdev_info.mem_speed = mem_speed;
> + dram_type = (val >> DRAM_TYPE_SHIFT) & DRAM_TYPE_MASK;
> + dram_channel = (val >> DRAM_CHANNEL_SHIFT) &
> DRAM_CHANNEL_MASK;
> + num_channel = hweight32(dram_channel);
> +
> + /*
> +  * The lpddr3 and lpddr4 technologies can have 1-4 channels
> and the
> +  * channels are 32bits wide; while ddr3l technologies can
> have 1-2
> +  * channels and the channels are 64 bits wide. But SV team
> found that in
> +  * case of single 64 bit wide DDR3L dimms two bits were set
> and system
> +  * with two DDR3L 64bit dimm all four bits were set.
> +  */

I still don't have access to the spec, but this comment suggests the
spec doesn't match the SV team findings. So can't the SV team request
the specs to reflect their findings? As an outsider, I see this as the
SV team's word against the HW team's words, and I don't know who made
the mistake: the SV engineer or the HW engineer. So I expect a
discussion between the two and the conclusions being reflected on the
specification :). Errata knowledge shouldn't go straight to the
drivers, that's a recipe for eternal doubt to the future people
maintaining this code.


> +
> + switch (dram_type) {
> + case DRAM_TYPE_LPDDR3:
> + case DRAM_TYPE_LPDDR4:
> + dev_priv->memdev_info.data_width = 4;
> + dev_priv->memdev_info.num_channel = num_channel;
> + break;
> + case DRAM_TYPE_DDR3L:
> + dev_priv->memdev_info.data_width = 8;
> + dev_priv->memdev_info.num_channel = num_channel / 2;
> + break;
> + default:

Again, no access to the spec here, but shouldn't this case reset
memdev_info.valid to false and then return (possibly with a
DRM_DEBUG_KMS)?


> + dev_priv->memdev_info.data_width = 4;
> + dev_priv->memdev_info.num_channel = num_channel;
> + }
> +
> + /*
> +  * Now read each DUNIT8/9/10/11 to check the rank of each
> dimms.
> +  * all the dimms should have same rank as in first valid
> Dimm
> +  */
> 
> +#define D_CR_DRP0_DUNIT_INVALID  0x

I'm not a huge fan of these mid-file 

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

2016-09-19 Thread Maarten Maathuis
I checked both monitors, on displayport they work, on HDMI they share the
same trouble.

An interesting observation is that when plug the monitor into another
system which has an older nvidia card using nouveau (only HDMI is
available, card is too old for displayport).
It seems that the i2c connection is unreliable, sometimes more or less data
is retrieved, but never all of it seems, and sometimes none.

I wonder if there is some sensitivity to i2c speed.

My general observation of these monitors is that they are slow to turn on
on displayport (locking in a mode takes some time), but on hdmi it is
faster, is there some kind of throttling going on the displayport side that
is being ignored on the HDMI side?

[768542.009520] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 254
[768542.009561] Raw EDID:
[768542.009575]   00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30
[768542.009593]   20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25
[768542.009610]   0c 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00
[768542.009626]   a9 c0 b3 00 01 01 08 e8 00 30 f2 70 5a 80 b0 58
[768542.009642]   8a 00 09 25 21 00 00 1e 00 00 00 fd 00 18 4b 1e
[768542.009658]   87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 55
[768542.009678]   32 34 45 38 35 30 0a 20 20 20 20 20 00 00 00 ff
[768542.009694]   00 48 54 48 47 38 30 30 30 30 35 0a 20 20 07 ff
[768542.010899] nouveau :01:00.0: DRM: DDC responded, but no EDID for
HDMI-A-1
[768578.474150] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 157
[768578.474171] Raw EDID:
[768578.474178]   00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30
[768578.474187]   20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25
[768578.474195]   0c 50 54 bf ef ff ff ff ff ff ff ff ff ff ff ff
[768578.474202]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474210]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474218]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474225]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474233]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.475264] nouveau :01:00.0: DRM: DDC responded, but no EDID for
HDMI-A-1
[768590.904774] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 181
[768590.904813] Raw EDID:
[768590.904826]   00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30
[768590.904843]   20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25
[768590.904860]   0c 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00
[768590.904876]   a9 c0 b3 00 01 01 08 e8 00 30 f2 70 5a 80 b0 58
[768590.904892]   8a 00 09 25 21 00 00 1e 00 00 00 fd 00 18 4b 1e
[768590.904908]   87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 55
[768590.904924]   32 34 45 38 35 30 0a 20 20 20 20 20 00 00 00 ff
[768590.904940]   00 48 54 48 47 38 30 30 30 30 35 0b ff ff ff ff
[768590.906012] nouveau :01:00.0: DRM: DDC responded, but no EDID for
HDMI-A-1

On Mon, Sep 19, 2016 at 9:50 PM, Maarten Maathuis 
wrote:

> The previous messages are about using the HDMI connection of my monitor on
> the HDMI 2.0->DP bridge (whatever the formal name may be) of my motherboard,
>
> Using the HDMI 1.4 connection of my motherboard:
>
> [   55.744581] [drm:intel_get_hpd_pins] hotplug event received, stat
> 0x0040, dig 0x10101210, pins 0x0040
> [   55.744589] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
> PIN 6 - cnt: 0
> [   55.744620] [drm:i915_hotplug_work_func] running encoder hotplug
> functions
> [   55.744625] [drm:i915_hotplug_work_func] Connector HDMI-A-2 (pin 6)
> received hotplug event.
> [   55.744629] [drm:intel_hdmi_detect] [CONNECTOR:46:HDMI-A-2]
> [   55.744915] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0050 w(1)
> [   55.744922] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first
> message, retry
> [   55.745190] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0050 w(1)
> [   55.745199] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent
> adapter i915 gmbus dpc
> [   55.745469] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0040 w(1)
> [   55.745476] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first
> message, retry
> [   55.745744] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0040 w(1)
>
> As for my OS, i run archlinux:
> Linux main 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016
> x86_64 GNU/Linux
>
> The requested VBT information is somewhere in here, I couldn't filter it
> since i couldn't see an end marker:
>
> [2.394379] [drm:intel_detect_pch] Found SunrisePoint PCH
> [2.394380] [drm:get_allowed_dc_mask] Allowed DC state mask 03
> [2.394768] [drm:i915_dump_device_info] i915 device info: gen=9,
> pciid=0x1912 rev=0x06 flags=need_gfx_hws,is_skylake,
> has_fbc,has_hotplug,has_llc,has_ddi,has_fpga_dbg,
> [2.394768] [drm:intel_device_info_runtime_init] slice total: 1
> [2.394769] [drm:intel_device_info_runtime_init] subslice total: 3
> [

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets

2016-09-19 Thread Chris Wilson
On Mon, Sep 19, 2016 at 04:30:13PM +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com" 
> 
> In preparation for engine reset work update this parameter to handle more
> than one type of reset. Default at the moment is still full gpu reset.

This is not ready yet. Please try integrating into the direct reset and
request recovery. When done properly we won't even need a module option
since it will safely fallback.
-Chris

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


Re: [Intel-gfx] [PATCH 3/7] drm/i915/tdr: Add support for per engine reset recovery

2016-09-19 Thread Chris Wilson
On Mon, Sep 19, 2016 at 04:30:15PM +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com" 
> 
> This change implements support for per-engine reset as an initial, less
> intrusive hang recovery option to be attempted before falling back to the
> legacy full GPU reset recovery mode if necessary. This is only supported
> from Gen8 onwards.
> 
> Hangchecker determines which engines are hung and invokes error handler to
> recover from it. Error handler schedules recovery for each of those engines
> that are hung. The recovery procedure is as follows,
>  - identifies the request that caused the hang and it is dropped
>  - force engine to idle: this is done by issuing a reset request
>  - reset and re-init engine
>  - restart submissions to the engine
> 
> If engine reset fails then we fall back to heavy weight full gpu reset
> which resets all engines and reinitiazes complete state of HW and SW.
> 
> v2
>   - rebase
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Tomas Elf 
> Signed-off-by: Arun Siluvery 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 59 
> +
>  drivers/gpu/drm/i915/i915_drv.h |  3 ++
>  drivers/gpu/drm/i915/i915_gem.c |  2 +-
>  drivers/gpu/drm/i915/intel_lrc.c| 10 +++
>  drivers/gpu/drm/i915/intel_lrc.h|  1 +
>  drivers/gpu/drm/i915/intel_uncore.c | 41 +++---
>  6 files changed, 105 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 99fa690..8625207 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1812,21 +1812,68 @@ error:
>   * Returns zero on successful reset or otherwise an error code.
>   *
>   * Procedure is fairly simple:
> - *  - force engine to idle
> - *  - save current state which includes head and current request
> - *  - reset engine
> - *  - restore saved state and resubmit context
> + *- identifies the request that caused the hang and it is dropped
> + *- force engine to idle: this is done by issuing a reset request
> + *- reset engine
> + *- restart submissions to the engine
>   */
>  int i915_reset_engine(struct intel_engine_cs *engine)
>  {
>   int ret;
>   struct drm_i915_private *dev_priv = engine->i915;
>  
> - /* FIXME: replace me with engine reset sequence */
> - ret = -ENODEV;
> + /*
> +  * We need to first idle the engine by issuing a reset request,
> +  * then perform soft reset and re-initialize hw state, for all of
> +  * this GT power need to be awake so ensure it does throughout the
> +  * process
> +  */
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> +
> + /*
> +  * the request that caused the hang is stuck on elsp, identify the
> +  * active request and drop it, adjust head to skip the offending
> +  * request to resume executing remaining requests in the queue.
> +  */
> + i915_gem_reset_engine(engine);
> +
> + ret = intel_engine_reset_begin(engine);
> + if (ret) {
> + DRM_ERROR("Failed to disable %s\n", engine->name);
> + goto error;
> + }
> +
> + ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine));
> + if (ret) {
> + DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret);
> + intel_engine_reset_cancel(engine);
> + goto error;
> + }

Ordering is still broken.

> +
> + ret = engine->init_hw(engine);
> + if (ret)
> + goto error;
> +
> + intel_engine_reset_cancel(engine);
> + intel_execlists_restart_submission(engine);

This is broken.
-Chris

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


Re: [Intel-gfx] [PATCH 2/7] drm/i915/tdr: Modify error handler for per engine hang recovery

2016-09-19 Thread Chris Wilson
On Mon, Sep 19, 2016 at 04:30:14PM +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com" 
> 
> This is a preparatory patch which modifies error handler to do per engine
> hang recovery. The actual patch which implements this sequence follows
> later in the series. The aim is to prepare existing recovery function to
> adapt to this new function where applicable (which fails at this point
> because core implementation is lacking) and continue recovery using legacy
> full gpu reset.
> 
> A helper function is also added to query the availability of engine
> reset.
> 
> The error events behaviour that are used to notify user of reset are
> adapted to engine reset such that it doesn't break users listening to these
> events. In legacy we report an error event, a reset event before resetting
> the gpu and a reset done event marking the completion of reset. The same
> behaviour is adapted but reset event is only dispatched once even when
> multiple engines are hung. Finally once reset is complete we send reset
> done event as usual.
> 
> v2
>   - rework slightly
>   - prefer INTEL_GEN
>   - document engine_mask param
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Ian Lister 
> Signed-off-by: Tomas Elf 
> Signed-off-by: Arun Siluvery 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 26 +++
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/i915_irq.c | 50 
> +
>  drivers/gpu/drm/i915/intel_uncore.c |  5 
>  4 files changed, 78 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 7f4e8ad..99fa690 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1804,6 +1804,32 @@ error:
>   goto wakeup;
>  }
>  
> +/**
> + * i915_reset_engine - reset GPU engine to recover from a hang
> + * @engine: engine to reset
> + *
> + * Reset a specific GPU engine. Useful if a hang is detected.
> + * Returns zero on successful reset or otherwise an error code.
> + *
> + * Procedure is fairly simple:
> + *  - force engine to idle
> + *  - save current state which includes head and current request
> + *  - reset engine
> + *  - restore saved state and resubmit context
> + */
> +int i915_reset_engine(struct intel_engine_cs *engine)
> +{
> + int ret;
> + struct drm_i915_private *dev_priv = engine->i915;
> +
> + /* FIXME: replace me with engine reset sequence */
> + ret = -ENODEV;
> +
> + set_bit(I915_RESET_IN_PROGRESS, _priv->gpu_error.flags);
> +
> + return ret;
> +}
> +
>  static int i915_pm_suspend(struct device *kdev)
>  {
>   struct pci_dev *pdev = to_pci_dev(kdev);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4dd307e..79de74d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2888,6 +2888,8 @@ extern long i915_compat_ioctl(struct file *filp, 
> unsigned int cmd,
>  extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 
> engine_mask);
>  extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
>  extern void i915_reset(struct drm_i915_private *dev_priv);
> +extern bool intel_has_engine_reset(struct drm_i915_private *dev_priv);
> +extern int i915_reset_engine(struct intel_engine_cs *engine);
>  extern int intel_guc_reset(struct drm_i915_private *dev_priv);
>  extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
>  extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index c128fdb..45c5a26 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2487,11 +2487,13 @@ static void i915_error_wake_up(struct 
> drm_i915_private *dev_priv)
>  /**
>   * i915_reset_and_wakeup - do process context error handling work
>   * @dev_priv: i915 device private
> + * @engine_mask: engines which are marked as hung
>   *
>   * Fire an error uevent so userspace can see that a hang or error
>   * was detected.
>   */
> -static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv)
> +static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv,
> +   u32 engine_mask)
>  {
>   struct kobject *kobj = _priv->drm.primary->kdev->kobj;
>   char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
> @@ -2501,6 +2503,15 @@ static void i915_reset_and_wakeup(struct 
> drm_i915_private *dev_priv)
>   kobject_uevent_env(kobj, KOBJ_CHANGE, error_event);
>  
>   DRM_DEBUG_DRIVER("resetting chip\n");
> + /*
> +  * This event needs to be sent before performing gpu reset. When
> +  * engine 

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

2016-09-19 Thread Maarten Maathuis
The previous messages are about using the HDMI connection of my monitor on
the HDMI 2.0->DP bridge (whatever the formal name may be) of my motherboard,

Using the HDMI 1.4 connection of my motherboard:

[   55.744581] [drm:intel_get_hpd_pins] hotplug event received, stat
0x0040, dig 0x10101210, pins 0x0040
[   55.744589] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
PIN 6 - cnt: 0
[   55.744620] [drm:i915_hotplug_work_func] running encoder hotplug
functions
[   55.744625] [drm:i915_hotplug_work_func] Connector HDMI-A-2 (pin 6)
received hotplug event.
[   55.744629] [drm:intel_hdmi_detect] [CONNECTOR:46:HDMI-A-2]
[   55.744915] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
0050 w(1)
[   55.744922] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first
message, retry
[   55.745190] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
0050 w(1)
[   55.745199] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent
adapter i915 gmbus dpc
[   55.745469] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
0040 w(1)
[   55.745476] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first
message, retry
[   55.745744] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
0040 w(1)

As for my OS, i run archlinux:
Linux main 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64
GNU/Linux

The requested VBT information is somewhere in here, I couldn't filter it
since i couldn't see an end marker:

[2.394379] [drm:intel_detect_pch] Found SunrisePoint PCH
[2.394380] [drm:get_allowed_dc_mask] Allowed DC state mask 03
[2.394768] [drm:i915_dump_device_info] i915 device info: gen=9,
pciid=0x1912 rev=0x06
flags=need_gfx_hws,is_skylake,has_fbc,has_hotplug,has_llc,has_ddi,has_fpga_dbg,
[2.394768] [drm:intel_device_info_runtime_init] slice total: 1
[2.394769] [drm:intel_device_info_runtime_init] subslice total: 3
[2.394769] [drm:intel_device_info_runtime_init] subslice per slice: 3
[2.394770] [drm:intel_device_info_runtime_init] EU total: 24
[2.394770] [drm:intel_device_info_runtime_init] EU per subslice: 8
[2.394770] [drm:intel_device_info_runtime_init] has slice power gating:
n
[2.394771] [drm:intel_device_info_runtime_init] has subslice power
gating: n
[2.394771] [drm:intel_device_info_runtime_init] has EU power gating: y
[2.394815] [drm:i915_gem_init_stolen] Memory reserved for graphics
device: 262144K, usable: 261120K
[2.394815] [drm] Memory usable by graphics device = 4096M
[2.394816] [drm:i915_ggtt_init_hw] GMADR size = 256M
[2.394816] [drm:i915_ggtt_init_hw] GTT stolen size = 256M
[2.394817] [drm:i915_ggtt_init_hw] ppgtt mode: 3
[2.394818] checking generic (c000 1fb) vs hw (c000 1000)
[2.394818] fb: switching to inteldrmfb from EFI VGA
[2.403811] Console: switching to colour dummy device 80x25
[2.403875] [drm] Replacing VGA console driver
[2.404199] [drm:intel_opregion_setup] graphic opregion physical addr:
0x77f83018
[2.404207] [drm:intel_opregion_setup] Public ACPI methods supported
[2.404208] [drm:intel_opregion_setup] SWSCI supported
[2.409161] [drm:swsci_setup] SWSCI GBDA callbacks 0cb3, SBCB
callbacks 00300483
[2.409163] [drm:intel_opregion_setup] ASLE supported
[2.409164] [drm:intel_opregion_setup] ASLE extension supported
[2.409165] [drm:intel_opregion_setup] Found valid VBT in ACPI OpRegion
(Mailbox #4)
[2.409230] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.409231] [drm] Driver supports precise vblank timestamp query.
[2.409233] [drm:init_vbt_defaults] Set default to SSC at 12 kHz
[2.409234] [drm:intel_bios_init] VBT signature "$VBT SKYLAKE",
BDB version 205
[2.409236] [drm:parse_general_features] BDB_GENERAL_FEATURES
int_tv_support 0 int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 12
display_clock_mode 1 fdi_rx_polarity_inverted 0
[2.409237] [drm:parse_general_definitions] crt_ddc_bus_pin: 2
[2.411255] [drm:intel_opregion_get_panel_type] Ignoring OpRegion panel
type (0)
[2.411257] [drm:parse_lfp_panel_data] Panel type: 2 (VBT)
[2.411258] [drm:parse_lfp_panel_data] DRRS supported mode is static
[2.411260] [drm:parse_lfp_panel_data] Found panel mode in BIOS VBT
tables:
[2.411262] [drm:drm_mode_debug_printmodeline] Modeline 0:"1024x768" 0
65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa
[2.411263] [drm:parse_lfp_panel_data] VBT initial LVDS value 300
[2.411264] [drm:parse_lfp_backlight] VBT backlight PWM modulation
frequency 200 Hz, active high, min brightness 0, level 255
[2.411265] [drm:parse_sdvo_device_mapping] Unsupported child device
size for SDVO mapping.
[2.411266] [drm:parse_device_mapping] Expected child device config size
for VBT version 205 not known; assuming 38
[2.411267] [drm:parse_driver_features] DRRS State Enabled:1
[2.411268] [drm:parse_ddi_port] Port B VBT info: DP:1 HDMI:1 DVI:1
EDP:0 CRT:0
[2.411269] 

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-09-19 Thread James Bottomley
On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote:
> On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote:
> > Hi! James & Paulo: What's the current status of this?
> 
> No, the only interaction has been the suggestion below for a revert,
> which didn't fix the problem.
> 
> >  Was this issue discussed elsewhere or even fixed in between? Just 
> > asking, because this issue is on the list of regressions for 4.8.
> 
> 
> I'm just about to try out -rc7, but it's not fixed so far.

OK, with -rc7 and the i915 fixes, there seems to be a marked
improvement.  I can no longer crash the crtc by using lots of xrandr
switches, which was the principal problem.

I've so far only got one of these in the logs

[14858.635035] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR*
CPU pipe B FIFO underrun

And the only residual problem seems to be that the monitor goes blank
periodically, but this can be fixed by switching resolution a couple of
times.

I haven't seen any of the link training errors so far and I've run
through my usual battery of be nasty to the external monitor tests.

James



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


Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

2016-09-19 Thread Navare, Manasi D
Hi Maarten,

Is this the Debug message when you are connected to the external DP Port or the 
HDMI port? I want to know if the problem is with the native DP connector or 
LSPCON?
Also could you send the log that has the Video Bios Table information (VBT) 
information?

Manasi

From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Maarten Maathuis
Sent: Monday, September 19, 2016 11:39 AM
To: intel-gfx 
Subject: [Intel-gfx] [i915] monitor is not detected unless it was active during 
boot

Hi,

I have a monitor, that when connected a skylake system, doesn't ever come up 
when hotplugging or after resume. The "bios" seems to not have problems 
bringing it up, even at the native 3840x2160 resolution, and when it works, all 
modes are correctly read (checked via xrandr).

I tried both the HMDI 1.4 port, as well as the DP 1.2 -> HDMI 2.0 built in 
conversion chip.

This is the dmesg output I have when plugging in this monitor, the DP-2 
connector is the one that should be detected.

Any advice on how to proceed?

Please be aware I am not subscribed to this mailing list, so please reply to me 
directly as well.

Maarten.

[ 1634.666165] [drm:intel_get_hpd_pins] hotplug event received, stat 
0x0080, dig 0x10121010, pins 0x0080
[ 1634.666179] [drm:intel_hpd_irq_handler] digital hpd port D - long
[ 1634.666183] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 7 
- cnt: 0
[ 1634.666229] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long
[ 1634.666253] [drm:i915_hotplug_work_func] running encoder hotplug functions
[ 1634.666258] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received 
hotplug event.
[ 1634.666261] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[ 1634.666273] [drm:i915_hotplug_work_func] Connector HDMI-A-3 (pin 7) received 
hotplug event.
[ 1634.666284] [drm:intel_hdmi_detect] [CONNECTOR:52:HDMI-A-3]
[ 1634.769941] [drm:intel_hdmi_detect] HDMI live status down
[ 1640.748356] [drm:intel_get_hpd_pins] hotplug event received, stat 
0x0080, dig 0x10121010, pins 0x0080
[ 1640.748369] [drm:intel_hpd_irq_handler] digital hpd port D - long
[ 1640.748373] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 7 
- cnt: 0
[ 1640.748416] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long
[ 1640.756938] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.765400] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.773936] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.782410] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.790910] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.799389] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.807907] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.816409] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.824895] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.833427] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.841915] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.850426] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.858919] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.867423] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.875924] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.884424] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.892899] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.901454] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.910008] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.918494] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.926994] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.935486] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.943982] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.952461] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.960971] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.969459] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.978003] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.986482] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.994973] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.003497] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.011986] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.020504] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.020506] [drm:drm_dp_dpcd_access] too many retries, giving up
[ 1641.020528] [drm:i915_hotplug_work_func] running encoder hotplug functions
[ 1641.020529] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received 
hotplug event.
[ 1641.020530] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[ 1641.029054] [drm:intel_dp_aux_ch] 

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

2016-09-19 Thread Maarten Maathuis
And the normal output at bootup:

[2.826131] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:48:DP-2]
[2.826135] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[2.826645] [drm:intel_dp_get_dpcd] DPCD: 12 14 c4 01 01 15 00 01 00 00
04 00 0f 00 00
[2.827032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source
yes, sink yes
[2.827038] [drm:intel_dp_print_rates] source rates: 162000, 216000,
27, 324000, 432000, 54
[2.827043] [drm:intel_dp_print_rates] sink rates: 162000, 27, 54
[2.827047] [drm:intel_dp_print_rates] common rates: 162000, 27,
54
[2.827905] [drm:intel_dp_probe_mst] Sink is not MST capable
[2.828350] [drm:drm_dp_i2c_do_msg] native defer
[2.829760] [drm:drm_dp_i2c_do_msg] native defer
[2.831102] [drm:drm_dp_i2c_do_msg] native defer
[2.832462] [drm:drm_dp_i2c_do_msg] native defer
[2.833887] [drm:drm_dp_i2c_do_msg] native defer
[2.835215] [drm:drm_dp_i2c_do_msg] native defer
[2.836834] [drm:drm_dp_i2c_do_msg] native defer
[2.838207] [drm:drm_dp_i2c_do_msg] native defer
[2.839592] [drm:drm_dp_i2c_do_msg] native defer
[2.841003] [drm:drm_dp_i2c_do_msg] native defer
[2.842434] [drm:drm_dp_i2c_do_msg] native defer
[2.843871] [drm:drm_dp_i2c_do_msg] native defer
[2.845284] [drm:drm_dp_i2c_do_msg] native defer
[2.846771] [drm:drm_dp_i2c_do_msg] native defer
[2.848228] [drm:drm_dp_i2c_do_msg] native defer
[2.849683] [drm:drm_dp_i2c_do_msg] native defer
[2.851073] [drm:drm_dp_i2c_do_msg] native defer
[2.852430] [drm:drm_dp_i2c_do_msg] native defer
[2.853824] [drm:drm_dp_i2c_do_msg] native defer
[2.855163] [drm:drm_dp_i2c_do_msg] native defer
[2.856661] [drm:drm_dp_i2c_do_msg] native defer
[2.858053] [drm:drm_dp_i2c_do_msg] native defer
[2.859543] [drm:drm_dp_i2c_do_msg] native defer
[2.860923] [drm:drm_dp_i2c_do_msg] native defer
[2.862372] [drm:drm_dp_i2c_do_msg] native defer
[2.863839] [drm:drm_dp_i2c_do_msg] native defer
[2.865228] [drm:drm_dp_i2c_do_msg] native defer
[2.866830] [drm:drm_dp_i2c_do_msg] native defer
[2.868279] [drm:drm_dp_i2c_do_msg] native defer
[2.869180] [drm:drm_detect_monitor_audio] Monitor has basic audio
support
[2.869975] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:48:DP-2] status updated from unknown to connected
[2.870173] [drm:drm_edid_to_eld] ELD monitor U24E850
[2.870180] [drm:parse_hdmi_vsdb] HDMI: DVI dual 0, max TMDS clock 300,
latency present 0 0, video latency 16 1, audio latency 96 2
[2.870184] [drm:drm_edid_to_eld] ELD size 32, SAD count 1
[2.870273] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:48:DP-2] probed modes :
[2.870279] [drm:drm_mode_debug_printmodeline] Modeline 74:"3840x2160"
60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x48 0x5
[2.870285] [drm:drm_mode_debug_printmodeline] Modeline 108:"3840x2160"
30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
[2.870290] [drm:drm_mode_debug_printmodeline] Modeline 119:"3840x2160"
30 296703 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5
[2.870294] [drm:drm_mode_debug_printmodeline] Modeline 109:"3840x2160"
25 297000 3840 4896 4984 5280 2160 2168 2178 2250 0x40 0x5
[2.870299] [drm:drm_mode_debug_printmodeline] Modeline 110:"3840x2160"
24 297000 3840 5116 5204 5500 2160 2168 2178 2250 0x40 0x5
[2.870304] [drm:drm_mode_debug_printmodeline] Modeline 120:"3840x2160"
24 296703 3840 5116 5204 5500 2160 2168 2178 2250 0x40 0x5
[2.870309] [drm:drm_mode_debug_printmodeline] Modeline 78:"2560x1440"
60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x40 0x9
[2.870314] [drm:drm_mode_debug_printmodeline] Modeline 75:"1920x1080"
60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[2.870318] [drm:drm_mode_debug_printmodeline] Modeline 111:"1920x1080"
60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[2.870323] [drm:drm_mode_debug_printmodeline] Modeline 76:"1920x1080"
50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
[2.870328] [drm:drm_mode_debug_printmodeline] Modeline 105:"1920x1080"
30 74250 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[2.870333] [drm:drm_mode_debug_printmodeline] Modeline 117:"1920x1080"
30 74176 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[2.870338] [drm:drm_mode_debug_printmodeline] Modeline 104:"1920x1080"
24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5
[2.870343] [drm:drm_mode_debug_printmodeline] Modeline 116:"1920x1080"
24 74176 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5
[2.870348] [drm:drm_mode_debug_printmodeline] Modeline 84:"1680x1050"
60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40 0x9
[2.870356] [drm:drm_mode_debug_printmodeline] Modeline 83:"1600x900" 60
108000 1600 1624 1704 1800 900 901 904 1000 0x40 0x5
[2.870360] [drm:drm_mode_debug_printmodeline] Modeline 92:"1280x1024"
75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[

[Intel-gfx] [i915] monitor is not detected unless it was active during boot

2016-09-19 Thread Maarten Maathuis
Hi,

I have a monitor, that when connected a skylake system, doesn't ever come
up when hotplugging or after resume. The "bios" seems to not have problems
bringing it up, even at the native 3840x2160 resolution, and when it works,
all modes are correctly read (checked via xrandr).

I tried both the HMDI 1.4 port, as well as the DP 1.2 -> HDMI 2.0 built in
conversion chip.

This is the dmesg output I have when plugging in this monitor, the DP-2
connector is the one that should be detected.

Any advice on how to proceed?

Please be aware I am not subscribed to this mailing list, so please reply
to me directly as well.

Maarten.

[ 1634.666165] [drm:intel_get_hpd_pins] hotplug event received, stat
0x0080, dig 0x10121010, pins 0x0080
[ 1634.666179] [drm:intel_hpd_irq_handler] digital hpd port D - long
[ 1634.666183] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
PIN 7 - cnt: 0
[ 1634.666229] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long
[ 1634.666253] [drm:i915_hotplug_work_func] running encoder hotplug
functions
[ 1634.666258] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received
hotplug event.
[ 1634.666261] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[ 1634.666273] [drm:i915_hotplug_work_func] Connector HDMI-A-3 (pin 7)
received hotplug event.
[ 1634.666284] [drm:intel_hdmi_detect] [CONNECTOR:52:HDMI-A-3]
[ 1634.769941] [drm:intel_hdmi_detect] HDMI live status down
[ 1640.748356] [drm:intel_get_hpd_pins] hotplug event received, stat
0x0080, dig 0x10121010, pins 0x0080
[ 1640.748369] [drm:intel_hpd_irq_handler] digital hpd port D - long
[ 1640.748373] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
PIN 7 - cnt: 0
[ 1640.748416] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long
[ 1640.756938] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.765400] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.773936] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.782410] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.790910] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.799389] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.807907] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.816409] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.824895] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.833427] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.841915] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.850426] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.858919] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.867423] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.875924] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.884424] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.892899] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.901454] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.910008] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.918494] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.926994] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.935486] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.943982] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.952461] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.960971] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.969459] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.978003] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.986482] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.994973] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.003497] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.011986] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.020504] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.020506] [drm:drm_dp_dpcd_access] too many retries, giving up
[ 1641.020528] [drm:i915_hotplug_work_func] running encoder hotplug
functions
[ 1641.020529] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received
hotplug event.
[ 1641.020530] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[ 1641.029054] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.037563] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.046092] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.054583] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.063076] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.071567] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.080094] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.088568] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.097054] 

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size

2016-09-19 Thread Zanoni, Paulo R
Em Seg, 2016-09-19 às 15:19 -0300, Paulo Zanoni escreveu:
> Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu:
> > 
> > From: Mahesh Kumar 
> > 
> > This patch make changes to use linetime latency instead of
> > allocated
> > DDB size during plane watermark calculation in switch case, This is
> > required to implement new DDB allocation algorithm.
> > 
> > In New Algorithm DDB is allocated based on WM values, because of
> > which
> > number of DDB blocks will not be available during WM calculation,
> > So this "linetime latency" is suggested by SV/HW team to use during
> > switch-case for WM blocks selection.
> 
> Why is this not part of BSpec? If there's some problem with the
> current
> algorithm and we need a new one, why is it not part of our spec?
> 
> > 
> > 
> > Changes since v1:
> >  - Rebase on top of Paulo's patch series
> > 
> > Signed-off-by: Mahesh Kumar 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 3fdec4d..cfd9b7d1 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3622,10 +3622,15 @@ static int skl_compute_plane_wm(const
> > struct
> > drm_i915_private *dev_priv,
> >     fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> >     selected_result = max(method2, y_tile_minimum);
> >     } else {
> > +   uint32_t linetime_us = 0;
> > +
> > +   linetime_us = DIV_ROUND_UP(width * 1000,
> > +   skl_pipe_pixel_rate(cstate));

Also, shouldn't this be width * 8 * 1000?

> > +
> >     if ((cpp * cstate->base.adjusted_mode.crtc_htotal
> > /
> > 512 < 1) &&
> >     (plane_bytes_per_line / 512 < 1))
> >     selected_result = method2;
> > -   else if ((ddb_allocation / plane_blocks_per_line)
> > >=
> > 1)
> > +   if (latency >= linetime_us)
> >     selected_result = min(method1, method2);
> >     else
> >     selected_result = method1;
> ___
> 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 v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size

2016-09-19 Thread Paulo Zanoni
Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar 
> 
> This patch make changes to use linetime latency instead of allocated
> DDB size during plane watermark calculation in switch case, This is
> required to implement new DDB allocation algorithm.
> 
> In New Algorithm DDB is allocated based on WM values, because of
> which
> number of DDB blocks will not be available during WM calculation,
> So this "linetime latency" is suggested by SV/HW team to use during
> switch-case for WM blocks selection.

Why is this not part of BSpec? If there's some problem with the current
algorithm and we need a new one, why is it not part of our spec?

> 
> Changes since v1:
>  - Rebase on top of Paulo's patch series
> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 3fdec4d..cfd9b7d1 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3622,10 +3622,15 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>   fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
>   selected_result = max(method2, y_tile_minimum);
>   } else {
> + uint32_t linetime_us = 0;
> +
> + linetime_us = DIV_ROUND_UP(width * 1000,
> + skl_pipe_pixel_rate(cstate));
> +
>   if ((cpp * cstate->base.adjusted_mode.crtc_htotal /
> 512 < 1) &&
>   (plane_bytes_per_line / 512 < 1))
>   selected_result = method2;
> - else if ((ddb_allocation / plane_blocks_per_line) >=
> 1)
> + if (latency >= linetime_us)
>   selected_result = min(method1, method2);
>   else
>   selected_result = method1;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Broxton decoupled MMIO (rev2)

2016-09-19 Thread Patchwork
== Series Details ==

Series: drm/i915/bxt: Broxton decoupled MMIO (rev2)
URL   : https://patchwork.freedesktop.org/series/12028/
State : warning

== Summary ==

Series 12028v2 drm/i915/bxt: Broxton decoupled MMIO
https://patchwork.freedesktop.org/api/1.0/series/12028/revisions/2/mbox/

Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> SKIP   (fi-hsw-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k)

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-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: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   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_2556/

0e34cb5b35f0f837219495c402073141481b1b90 drm-intel-nightly: 
2016y-09m-19d-15h-38m-53s UTC integration manifest
7261225 drm/i915/bxt: Broxton decoupled MMIO

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


Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

2016-09-19 Thread Manasi Navare
On Mon, Sep 19, 2016 at 10:03:29AM -0700, Jim Bride wrote:
> On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote:
> > On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote:
> > > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> > > > From: Jim Bride 
> > > > 
> > > > Add upfront link training to intel_dp_mst_mode_valid() so that we know
> > > > topology constraints before we validate the legality of modes to be
> > > > checked.
> > > > 
> > > 
> > > The patch seems to do a lot more things than just what is described
> > > here. I guess, it would be better to split this into multiple patches or
> > > at least provide adequate description here.
> > > 
> > 
> > I think the only other thing its doing is making some functions
> > non static so they can be used for MST upfront enabling.
> > But I think that can be in the same patch since it is done in order
> > to enable upfront for MST.
> > Jim, any thoughts?
> 
> This is exactly the case.
> 
> Jim

I have already resubmitted a newer version of the patch with the description
more coherent to what the patch is doing.

Manasi
> 
> > 
> > > > v3:
> > > > * Reset the upfront values but dont unset the EDID for MST. (Manasi)
> > > > v2:
> > > > * Rebased on new revision of link training patch. (Manasi)
> > > > 
> > > > Signed-off-by: Manasi Navare 
> > > > Signed-off-by: Jim Bride 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 15 
> > > >  drivers/gpu/drm/i915/intel_dp_mst.c | 74 
> > > > +++--
> > > >  drivers/gpu/drm/i915/intel_drv.h|  3 ++
> > > >  3 files changed, 64 insertions(+), 28 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 9042d28..635830e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct 
> > > > drm_device *dev,
> > > >   enum pipe pipe);
> > > >  static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > > >  
> > > > -static int
> > > > +int
> > > >  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
> > > >  {
> > > > int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
> > > > @@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp  *intel_dp)
> > > > return max_link_bw;
> > > >  }
> > > >  
> > > > -static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > > > +u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > > >  {
> > > > struct intel_digital_port *intel_dig_port = 
> > > > dp_to_dig_port(intel_dp);
> > > > u8 temp, source_max, sink_max;
> > > > @@ -296,8 +296,7 @@ static int intersect_rates(const int *source_rates, 
> > > > int source_len,
> > > > return k;
> > > >  }
> > > >  
> > > > -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> > > > -int *common_rates)
> > > > +int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates)
> > > >  {
> > > > const int *source_rates, *sink_rates;
> > > > int source_len, sink_len;
> > > > @@ -321,7 +320,7 @@ static int intel_dp_common_rates(struct intel_dp 
> > > > *intel_dp,
> > > >common_rates);
> > > >  }
> > > >  
> > > > -static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> > > > +bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> > > >  {
> > > > struct intel_digital_port *intel_dig_port = 
> > > > dp_to_dig_port(intel_dp);
> > > > struct intel_encoder *intel_encoder = _dig_port->base;
> > > > @@ -4545,12 +4544,12 @@ intel_dp_long_pulse(struct intel_connector 
> > > > *intel_connector)
> > > > }
> > > >  
> > > >  out:
> > > > -   if ((status != connector_status_connected) &&
> > > > -   (intel_dp->is_mst == false)) {
> > > > -   intel_dp_unset_edid(intel_dp);
> > > > +   if (status != connector_status_connected) {
> > > > intel_dp->upfront_done = false;
> > > > intel_dp->max_lanes_upfront = 0;
> > > > intel_dp->max_link_rate_upfront = 0;
> > > > +   if (intel_dp->is_mst == false)
> > > > +   intel_dp_unset_edid(intel_dp);
> > > > }
> > > >  
> > > > intel_display_power_put(to_i915(dev), power_domain);
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > index 54a9d76..98d45a4 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > @@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct 
> > > > intel_encoder *encoder,
> > > > int bpp;
> > > > int lane_count, slots;
> > > > const struct drm_display_mode 

[Intel-gfx] [PATCH v2] drm/i915/bxt: Broxton decoupled MMIO

2016-09-19 Thread Praveen Paneri
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles and avoids frequent software
forcewake.

v2:
- Moved platform check out of the function and got rid of duplicate
functions to find out decoupled power domain.
- Added a check for forcewake already held and skipped decoupled access
- Skipped writing 64 bit register through decoupled MMIO

Signed-off-by: Zhe Wang 
Signed-off-by: Damien Lespiau 
Signed-off-by: Ankitprasad Sharma 
Signed-off-by: Praveen Paneri 
---
 drivers/gpu/drm/i915/i915_drv.h |  11 
 drivers/gpu/drm/i915/i915_reg.h |   7 +++
 drivers/gpu/drm/i915/intel_uncore.c | 118 +++-
 3 files changed, 134 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4dd307e..065247b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -558,6 +558,16 @@ enum forcewake_domains {
 #define FW_REG_READ  (1)
 #define FW_REG_WRITE (2)
 
+enum power_domains {
+   GEN9_DECOUPLED_PD_BLITTER = 0,
+   GEN9_DECOUPLED_PD_RENDER,
+   GEN9_DECOUPLED_PD_MEDIA,
+   GEN9_DECOUPLED_PD_ALL
+};
+
+#define GEN9_DECOUPLED_OP_WRITE (0)
+#define GEN9_DECOUPLED_OP_READ (1)
+
 enum forcewake_domains
 intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
   i915_reg_t reg, unsigned int op);
@@ -2854,6 +2864,7 @@ struct drm_i915_cmd_table {
 #define GT_FREQUENCY_MULTIPLIER 50
 #define GEN9_FREQ_SCALER 3
 
+#define HAS_DECOUPLED_MMIO(dev_priv) (IS_BROXTON(dev_priv) && 
IS_BXT_REVID(dev_priv, BXT_REVID_C0, REVID_FOREVER))
 #include "i915_trace.h"
 
 static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private 
*dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 70d9616..be59803 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7394,6 +7394,13 @@ enum {
 #define  SKL_FUSE_PG1_DIST_STATUS  (1<<26)
 #define  SKL_FUSE_PG2_DIST_STATUS  (1<<25)
 
+/* Decoupled MMIO register pair for kernel driver */
+#define GEN9_DECOUPLED_REG0_DW0_MMIO(0xF00)
+#define GEN9_DECOUPLED_REG0_DW1_MMIO(0xF04)
+#define GEN9_DECOUPLED_DW1_GO  (1<<31)
+#define GEN9_DECOUPLED_PD_SHIFT28
+#define GEN9_DECOUPLED_OP_SHIFT24
+
 /* Per-pipe DDI Function Control */
 #define _TRANS_DDI_FUNC_CTL_A  0x60400
 #define _TRANS_DDI_FUNC_CTL_B  0x61400
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index a9b6c93..06fffba 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -816,6 +816,42 @@ unclaimed_reg_debug(struct drm_i915_private *dev_priv,
__unclaimed_reg_debug(dev_priv, reg, read, before);
 }
 
+/*
+ * Decoupled MMIO access for only 1 DWORD
+ */
+static void __gen9_decoupled_mmio_access(struct drm_i915_private *dev_priv,
+uint32_t reg, u32 *ptr_data,
+enum forcewake_domains fw_engine, int 
operation)
+{
+   enum power_domains pd_engine;
+   u32 ctrl_reg_data = 0;
+
+   if (operation == GEN9_DECOUPLED_OP_WRITE)
+   __raw_i915_write32(dev_priv,
+   GEN9_DECOUPLED_REG0_DW0,
+   *ptr_data);
+
+   pd_engine = (fw_engine == (FORCEWAKE_RENDER || FORCEWAKE_BLITTER)) ? \
+!(fw_engine >> 1) : (fw_engine >> 1); \
+
+   ctrl_reg_data |= reg;
+   ctrl_reg_data |= (operation << GEN9_DECOUPLED_OP_SHIFT);
+   ctrl_reg_data |= (pd_engine << GEN9_DECOUPLED_PD_SHIFT);
+   __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data);
+
+   ctrl_reg_data |= GEN9_DECOUPLED_DW1_GO;
+   __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data);
+
+   if (wait_for_atomic((__raw_i915_read32(dev_priv,
+   GEN9_DECOUPLED_REG0_DW1) & GEN9_DECOUPLED_DW1_GO) == 0,
+   FORCEWAKE_ACK_TIMEOUT_MS))
+   DRM_ERROR("Decoupled MMIO wait timed out\n");
+
+   if (operation == GEN9_DECOUPLED_OP_READ)
+   *ptr_data = __raw_i915_read32(dev_priv,
+   GEN9_DECOUPLED_REG0_DW0);
+}
+
 #define GEN2_READ_HEADER(x) \
u##x val = 0; \
assert_rpm_wakelock_held(dev_priv);
@@ -892,6 +928,20 @@ static inline void __force_wake_auto(struct 
drm_i915_private *dev_priv,
dev_priv->uncore.funcs.force_wake_get(dev_priv, fw_domains);
 }
 
+static inline bool __is_forcewake_active(struct drm_i915_private *dev_priv,
+enum forcewake_domains fw_domains)
+{
+   struct 

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

2016-09-19 Thread Jim Bride
On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote:
> On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote:
> > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> > > From: Jim Bride 
> > > 
> > > Add upfront link training to intel_dp_mst_mode_valid() so that we know
> > > topology constraints before we validate the legality of modes to be
> > > checked.
> > > 
> > 
> > The patch seems to do a lot more things than just what is described
> > here. I guess, it would be better to split this into multiple patches or
> > at least provide adequate description here.
> > 
> 
> I think the only other thing its doing is making some functions
> non static so they can be used for MST upfront enabling.
> But I think that can be in the same patch since it is done in order
> to enable upfront for MST.
> Jim, any thoughts?

This is exactly the case.

Jim

> 
> > > v3:
> > > * Reset the upfront values but dont unset the EDID for MST. (Manasi)
> > > v2:
> > > * Rebased on new revision of link training patch. (Manasi)
> > > 
> > > Signed-off-by: Manasi Navare 
> > > Signed-off-by: Jim Bride 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 15 
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 74 
> > > +++--
> > >  drivers/gpu/drm/i915/intel_drv.h|  3 ++
> > >  3 files changed, 64 insertions(+), 28 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 9042d28..635830e 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct 
> > > drm_device *dev,
> > > enum pipe pipe);
> > >  static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > >  
> > > -static int
> > > +int
> > >  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
> > >  {
> > >   int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
> > > @@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp  *intel_dp)
> > >   return max_link_bw;
> > >  }
> > >  
> > > -static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > > +u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > >  {
> > >   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > >   u8 temp, source_max, sink_max;
> > > @@ -296,8 +296,7 @@ static int intersect_rates(const int *source_rates, 
> > > int source_len,
> > >   return k;
> > >  }
> > >  
> > > -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> > > -  int *common_rates)
> > > +int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates)
> > >  {
> > >   const int *source_rates, *sink_rates;
> > >   int source_len, sink_len;
> > > @@ -321,7 +320,7 @@ static int intel_dp_common_rates(struct intel_dp 
> > > *intel_dp,
> > >  common_rates);
> > >  }
> > >  
> > > -static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> > > +bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> > >  {
> > >   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > >   struct intel_encoder *intel_encoder = _dig_port->base;
> > > @@ -4545,12 +4544,12 @@ intel_dp_long_pulse(struct intel_connector 
> > > *intel_connector)
> > >   }
> > >  
> > >  out:
> > > - if ((status != connector_status_connected) &&
> > > - (intel_dp->is_mst == false)) {
> > > - intel_dp_unset_edid(intel_dp);
> > > + if (status != connector_status_connected) {
> > >   intel_dp->upfront_done = false;
> > >   intel_dp->max_lanes_upfront = 0;
> > >   intel_dp->max_link_rate_upfront = 0;
> > > + if (intel_dp->is_mst == false)
> > > + intel_dp_unset_edid(intel_dp);
> > >   }
> > >  
> > >   intel_display_power_put(to_i915(dev), power_domain);
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 54a9d76..98d45a4 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct 
> > > intel_encoder *encoder,
> > >   int bpp;
> > >   int lane_count, slots;
> > >   const struct drm_display_mode *adjusted_mode = 
> > > _config->base.adjusted_mode;
> > > - int mst_pbn;
> > > + int mst_pbn, common_len;
> > > + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> > >  
> > >   pipe_config->dp_encoder_is_mst = true;
> > >   pipe_config->has_pch_encoder = false;
> > > - bpp = 24;
> > > +
> > >   /*
> > > -  * for MST we always configure max link bw - the spec doesn't
> > > -  * seem to suggest we should do otherwise.
> > > +  * For MST we always configure for the maximum trainable link bw -
> > > +  * the spec doesn't seem to suggest we should do otherwise.  The
> > > +  * calls to 

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Broxton decoupled MMIO

2016-09-19 Thread Praveen Paneri



On Tuesday 06 September 2016 12:06 PM, Chris Wilson wrote:

On Tue, Sep 06, 2016 at 10:54:14AM +0530, Praveen Paneri wrote:

Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles and avoids frequent software
forcewake.


How about when forcewake is already held? You'll note that we still
Will try to add the same check (for domain->wake_count) in decoupled 
MMIO path as well and do a direct register access if forcewake is 
already held.

require irq-spinlocks so the mmio access is still not great. And we
still will have to frequently take forcewake manually, apparently.

Do you have any statistics to say that we do reduce grabing the fw
wakelock and that the busywait you add instead is negligible. You are
still using a 50ms timeout, so there is some doubt about "less cycles".

Sorry didn't find any such statistics with Windows folks.
But can do an exercise myself to measure the actual benefit of Decoupled 
MMIO. Please can you suggest some method to do that.


The feature definitely helps HW for synchronization as the cycles are
internally serialized in GT and eliminates the risk of hitting certain
hangs which exist in theory.



+/*
+ * Decoupled MMIO access for only 1 DWORD
+ */
+static void __gen9_decoupled_mmio_access(struct drm_i915_private *dev_priv,
+uint32_t reg, u32 *ptr_data,
+enum power_domains pd, int operation)
+{
+   u32 ctrl_reg_data = 0;
+
+   if (operation == GEN9_DECOUPLED_OP_WRITE)
+   __raw_i915_write32(dev_priv,
+   GEN9_DECOUPLED_REG0_DW0,
+   *ptr_data);
+
+   ctrl_reg_data |= reg;
+   ctrl_reg_data |= (operation << GEN9_DECOUPLED_OP_SHIFT);
+   ctrl_reg_data |= (pd << GEN9_DECOUPLED_PD_SHIFT);
+   __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data);
+
+   ctrl_reg_data |= GEN9_DECOUPLED_DW1_GO;
+   __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data);
+
+   if (wait_for_atomic((__raw_i915_read32(dev_priv,
+   GEN9_DECOUPLED_REG0_DW1) & GEN9_DECOUPLED_DW1_GO) == 0,
+   FORCEWAKE_ACK_TIMEOUT_MS))
+   DRM_ERROR("Decoupled MMIO wait timed out\n");
+
+   if (operation == GEN9_DECOUPLED_OP_READ)
+   *ptr_data = __raw_i915_read32(dev_priv,
+   GEN9_DECOUPLED_REG0_DW0);
+}
+
  #define GEN2_READ_HEADER(x) \
u##x val = 0; \
assert_rpm_wakelock_held(dev_priv);
@@ -932,12 +997,27 @@ chv_read##x(struct drm_i915_private *dev_priv, i915_reg_t 
reg, bool trace) { \
  static u##x \
  gen9_read##x(struct drm_i915_private *dev_priv, i915_reg_t reg, bool trace) { 
\
enum forcewake_domains fw_engine; \
+   enum power_domains pd_engine; \
GEN6_READ_HEADER(x); \
-   fw_engine = __gen9_reg_read_fw_domains(offset); \
-   if (fw_engine) \
-   __force_wake_auto(dev_priv, fw_engine); \
-   val = __raw_i915_read##x(dev_priv, reg); \
-   GEN6_READ_FOOTER; \
+   pd_engine = __gen9_reg_read_power_domains(offset); \
+   if (HAS_DECOUPLED_MMIO(dev_priv) && pd_engine && x%32 == 0) { \


Move the platform test out of here (since it is already a per-platform
vfunc) and then skip the duplicated gen9 functions.


+   u32 *ptr_data = (u32 *)  \
+   unsigned i = 0; \
+   for (i = 0; i < x/32; i++) { \


And tidy up the reassignments.


+   __gen9_decoupled_mmio_access(dev_priv, \
+   (offset + i*4), \
+   ptr_data + i, \
+   pd_engine, \
+   GEN9_DECOUPLED_OP_READ); \
+   ptr_data++; \
+   } \
+   } else { \
+   fw_engine = __gen9_reg_read_fw_domains(offset); \
+   if (fw_engine) \
+   __force_wake_auto(dev_priv, fw_engine); \
+   val = __raw_i915_read##x(dev_priv, reg); \
+   } \
+   GEN6_READ_FOOTER; \


Misleading indentation.


  }

  __gen9_read(8)
@@ -1101,11 +1181,26 @@ static void \
  gen9_write##x(struct drm_i915_private *dev_priv, i915_reg_t reg, u##x val, \
bool trace) { \
enum forcewake_domains fw_engine; \
+   enum power_domains pd_engine; \
GEN6_WRITE_HEADER; \
-   fw_engine = __gen9_reg_write_fw_domains(offset); \




-   if (fw_engine) \
-   __force_wake_auto(dev_priv, fw_engine); \
-   __raw_i915_write##x(dev_priv, reg, val); \
+   pd_engine = __gen9_reg_write_power_domains(offset); \
+   if (HAS_DECOUPLED_MMIO(dev_priv) && pd_engine && x%32 == 0) { \
+   u32 *ptr_data = (u32 *)  \
+   unsigned i = 0; \
+   for (i = 0; i < x/32; i++) { \
+   

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Update i915.reset to handle engine resets

2016-09-19 Thread Patchwork
== Series Details ==

Series: series starting with [1/7] drm/i915: Update i915.reset to handle engine 
resets
URL   : https://patchwork.freedesktop.org/series/12651/
State : failure

== Summary ==

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

Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k)
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-hsw-4770k)

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-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770k total:208  pass:191  dwarn:0   dfail:0   fail:0   skip:16 
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   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_2555/

0e34cb5b35f0f837219495c402073141481b1b90 drm-intel-nightly: 
2016y-09m-19d-15h-38m-53s UTC integration manifest
63084e5 drm/i915/tdr: Enable Engine reset and recovery support
803d39e drm/i915/tdr: Export reset count info to debugfs
c13c4dc drm/i915/tdr: Add engine reset count to error state
1f33769 drm/i915: Skip reset request if there is one already
412f59f drm/i915/tdr: Add support for per engine reset recovery
d95b6e3 drm/i915/tdr: Modify error handler for per engine hang recovery
5768c16 drm/i915: Update i915.reset to handle engine resets

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


Re: [Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, Lionel Landwerlin  wrote:
> Some of the Intel platforms have odd numbers of LUT entries and we
> need to tests a couple of values around the expected result. Bring
> back the CRC equal function we need that doesn't trigger an assert
> right away, while we still assert if we can't find a correct result in
> the outter loop.
>
> bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97691
> Fixes: 582ce4cd19c627606047b1a8fdd987c4dc07353c

We might as well stick to kernel style for Fixes: tags:

Fixes: 582ce4cd19c6 ("lib/debugs: nuke igt_crc_equal again")

You can get that with:

$ git log -1 582ce4cd19c627606047b1a8fdd987c4dc07353c --pretty="format:Fixes: 
%h (\"%s\")"

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] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests

2016-09-19 Thread Lionel Landwerlin
Some of the Intel platforms have odd numbers of LUT entries and we
need to tests a couple of values around the expected result. Bring
back the CRC equal function we need that doesn't trigger an assert
right away, while we still assert if we can't find a correct result in
the outter loop.

bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97691
Fixes: 582ce4cd19c627606047b1a8fdd987c4dc07353c
Cc: Daniel Vetter 
Cc: Christophe Prigent 
---
 tests/kms_pipe_color.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
index b0a2f07..ebfceab 100644
--- a/tests/kms_pipe_color.c
+++ b/tests/kms_pipe_color.c
@@ -652,6 +652,16 @@ static void test_pipe_legacy_gamma_reset(data_t *data,
free(gamma_zero);
 }
 
+static bool crc_equal(igt_crc_t *a, igt_crc_t *b)
+{
+  int i;
+
+  for (i = 0; i < a->n_words; i++)
+if (a->crc[i] != b->crc[i])
+  return false;
+  return true;
+}
+
 /*
  * Draw 3 rectangles using before colors with the ctm matrix apply and verify
  * the CRC is equal to using after colors with an identify ctm matrix.
@@ -724,7 +734,7 @@ static bool test_pipe_ctm(data_t *data,
/* Verify that the CRC of the software computed output is
 * equal to the CRC of the CTM matrix transformation output.
 */
-   igt_assert_crc_equal(_software, _hardware);
+   ret &= crc_equal(_software, _hardware);
 
igt_output_set_pipe(output, PIPE_ANY);
}
-- 
2.8.1

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


Re: [Intel-gfx] [PATCH 3/6] drm/i915: keep declarations in i915_drv.h

2016-09-19 Thread Joonas Lahtinen
On to, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
> Fix sparse warnings:
> 
> drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol
> 'i915_driver_load' was not declared. Should it be static?
> 
> drivers/gpu/drm/i915/i915_drv.c:1267:6: warning: symbol
> 'i915_driver_unload' was not declared. Should it be static?
> 
> drivers/gpu/drm/i915/i915_drv.c:2444:25: warning: symbol 'i915_pm_ops'
> was not declared. Should it be static?
> 

Hmm, Chris, were not these change in the middle of a series, did the
cleanup patches just fall off?

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 11/18] drm/i915: Record space required for request emission

2016-09-19 Thread Joonas Lahtinen
On ma, 2016-09-19 at 12:32 +0100, Chris Wilson wrote:
> On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote:
> > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > > @@ -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;
> > 
> > 'initialized_rings' to differentiate as suggested by Tvrtko too.
> 
> Tvrtko wasn't referring to this. The point is that we don't know
> initialized_rings here, just the declared set of rings we think
> the hardware is supposed to have.

Can't we afford to calculate this to the info struct anyway?

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 15/18] drm/i915: Reserve space in the global seqno during request allocation

2016-09-19 Thread Joonas Lahtinen
On ma, 2016-09-19 at 18:35 +0300, Jani Nikula wrote:
> > On Mon, 19 Sep 2016, Joonas Lahtinen  
> > wrote:
> > 
> > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > > 
> > > +static int reserve_global_seqno(struct drm_i915_private *i915)
> > >  {
> > > - struct i915_gem_timeline *tl = _priv->gt.global_timeline;
> > > + struct i915_gem_timeline *tl = >gt.global_timeline;
> > > + u32 next_seqno = atomic_read(>next_seqno);
> > >  
> > > - /* reserve 0 for non-seqno */
> > > - if (unlikely(tl->next_seqno == 0)) {
> > 
> > Meh, do not hide the ++i915->gt.active_requests in if (unlikely(...)).
> 
> *shudder* it doesn't get any better by removing unlikely!
> 

Well, it gets twice as bad by adding it, though :P

My below recommendation would be preferred by lifting the increment
before the if ().

> > > 
> > > + if (unlikely(next_seqno + ++i915->gt.active_requests <= next_seqno)) {
> > >   int ret;
> > >  
> > 
> > Why not if (likely(next_seqno + active_requests > next_seqno))
> > > > return 0;

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 07/18] drm/i915: Restore nonblocking awaits for modesetting

2016-09-19 Thread Joonas Lahtinen
Maarten, could you give this a look?

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> After combining the dma-buf reservation object and the GEM reservation
> object, we lost the ability to do a nonblocking wait on the i915 request
> (as we blocked upon the reservation object during prepare_fb). We can
> instead convert the reservation object into a fence upon which we can
> asynchronously wait (including a forced timeout in case the DMA fence is
> never signaled).
> 
> > Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 78 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>  2 files changed, 51 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 5c0ea08dddb3..294df122f7c6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14383,12 +14383,33 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>  static void intel_atomic_commit_work(struct work_struct *work)
>  {
> > -   struct drm_atomic_state *state = container_of(work,
> > -     struct drm_atomic_state,
> > -     commit_work);
> > +   struct drm_atomic_state *state =
> > +   container_of(work, struct drm_atomic_state, commit_work);
> +
> >     intel_atomic_commit_tail(state);
>  }
>  
> +static int __i915_sw_fence_call
> +intel_atomic_commit_ready(struct i915_sw_fence *fence,
> > +     enum i915_sw_fence_notify notify)
> +{
> > +   struct intel_atomic_state *state =
> > +   container_of(fence, struct intel_atomic_state, commit_ready);
> +
> > +   switch (notify) {
> > +   case FENCE_COMPLETE:
> > +   if (state->base.commit_work.func)
> > +   queue_work(system_unbound_wq, >base.commit_work);
> > +   break;
> +
> > +   case FENCE_FREE:
> > +   drm_atomic_state_put(>base);
> > +   break;
> > +   }
> +
> > +   return NOTIFY_DONE;
> +}
> +
>  static void intel_atomic_track_fbs(struct drm_atomic_state *state)
>  {
> >     struct drm_plane_state *old_plane_state;
> @@ -14434,11 +14455,14 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
> >     if (ret)
> >     return ret;
>  
> > -   INIT_WORK(>commit_work, intel_atomic_commit_work);
> > +   drm_atomic_state_get(state);
> > +   i915_sw_fence_init(_state->commit_ready,
> > +      intel_atomic_commit_ready);
>  
> >     ret = intel_atomic_prepare_commit(dev, state);
> >     if (ret) {
> >     DRM_DEBUG_ATOMIC("Preparing state failed with %i\n", ret);
> > +   i915_sw_fence_commit(_state->commit_ready);
> >     return ret;
> >     }
>  
> @@ -14449,10 +14473,14 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
> >     intel_atomic_track_fbs(state);
>  
> >     drm_atomic_state_get(state);
> > -   if (nonblock)
> > -   queue_work(system_unbound_wq, >commit_work);
> > -   else
> > +   INIT_WORK(>commit_work,
> > +     nonblock ? intel_atomic_commit_work : NULL);
> +
> > +   i915_sw_fence_commit(_state->commit_ready);
> > +   if (!nonblock) {
> > +   i915_sw_fence_wait(_state->commit_ready);
> >     intel_atomic_commit_tail(state);
> > +   }
>  
> >     return 0;
>  }
> @@ -14568,8 +14596,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> >     struct drm_framebuffer *fb = new_state->fb;
> >     struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> >     struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
> > -   long lret;
> > -   int ret = 0;
> > +   int ret;
>  
> >     if (!obj && !old_obj)
> >     return 0;
> @@ -14577,7 +14604,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> >     if (old_obj) {
> >     struct drm_crtc_state *crtc_state =
> >     drm_atomic_get_existing_crtc_state(new_state->state, 
> > plane->state->crtc);
> > -   long timeout = 0;
>  
> >     /* Big Hammer, we also need to ensure that any pending
> >      * MI_WAIT_FOR_EVENT inside a user batch buffer on the
> @@ -14590,31 +14616,25 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> >      * This should only fail upon a hung GPU, in which case we
> >      * can safely continue.
> >      */
> > -   if (needs_modeset(crtc_state))
> > -   timeout = i915_gem_object_wait(old_obj,
> > -      I915_WAIT_INTERRUPTIBLE |
> > -      I915_WAIT_LOCKED,
> > -      MAX_SCHEDULE_TIMEOUT,
> > -      NULL);
> > -   if (timeout < 0) {
> > -   /* GPU hangs should have been swallowed by the wait */
> > -   

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets

2016-09-19 Thread Joonas Lahtinen
On ma, 2016-09-19 at 16:30 +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com" 
> 

I assume "From:" needs to be properly formatted just like
"Signed-off-by:". So in all patches;

From: Arun Siluvery 

Cover letters are also gaining popularity, and remember to use
--reroll-count=N when submitting new iterations of the same series,
will help people and Patchwork :)

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 16/18] drm/i915: Enable multiple timelines

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -315,17 +304,42 @@ submit_notify(struct i915_sw_fence *fence, enum 
> i915_sw_fence_notify state)
>  {
>   struct drm_i915_gem_request *request =
>   container_of(fence, typeof(*request), submit);
> + struct intel_timeline *timeline;
> + struct intel_engine_cs *engine = request->engine;
> + unsigned long flags;
> + u32 seqno;
>  
>   /* Will be called from irq-context when using foreign DMA fences */
>  
> - switch (state) {
> - case FENCE_COMPLETE:
> - request->engine->submit_request(request);
> - break;
> + if (state != FENCE_COMPLETE)
> + return NOTIFY_DONE;
>  
> - case FENCE_FREE:
> - break;
> - }
> + timeline = engine->timeline;
> + GEM_BUG_ON(timeline == request->timeline);

Umm, why this BUG_ON?

> +
> + spin_lock_irqsave(>lock, flags);
> +
> + seqno = timeline_get_seqno(>i915->gt.global_timeline);
> + GEM_BUG_ON(seqno == 0);
> +
> + request->previous_seqno = timeline->last_submitted_seqno;
> + timeline->last_submitted_seqno = seqno;
> +
> + spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);

A comment might be in place for the nested locking.

> + request->global_seqno = seqno;
> + if (test_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
> + intel_engine_enable_signaling(request);
> + spin_unlock(>lock);
> +
> + engine->emit_request(request, request->ring->vaddr + request->postfix);

Is it just me or does this look very strange, let's "emit the request"
at "vaddr + request->postfix" offset. Makes no sense. Maybe reconsider
refreshing the vfunc name.

> +
> + spin_lock_nested(>timeline->lock, SINGLE_DEPTH_NESTING);
> + list_move_tail(>link, >requests);
> + spin_unlock(>timeline->lock);
> +
> + engine->submit_request(request);
> +
> + spin_unlock_irqrestore(>lock, flags);
>  
>   return NOTIFY_DONE;
>  }
> 

> @@ -685,12 +697,15 @@ void __i915_add_request(struct drm_i915_gem_request 
> *request, bool flush_caches)
> 
>   i915_sw_fence_await_sw_fence(>submit, >submit,
>    >submitq, GFP_NOWAIT);
>  
> - request->emitted_jiffies = jiffies;
> - request->previous_seqno = timeline->last_submitted_seqno;
> + spin_lock_irq(>lock);
> + list_add_tail(>link, >requests);
> + spin_unlock_irq(>lock);
> +
>   timeline->last_submitted_seqno = request->fence.seqno;
>   i915_gem_active_set(>last_request, request);
> - list_add_tail(>link, >requests);
> +
>   list_add_tail(>ring_link, >request_list);
> + request->emitted_jiffies = jiffies;

Is this assigment really worth delaying here?

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 v2 0/7] drm/i915: clean up dsi sequences

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, Ville Syrjälä  wrote:
> On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote:
>> v2 of an old series, addressing issues pointed out by Ville.
>
> Entire series looks reasonable. Spec is vague, so hard to be 100% sure.

We're about to find out, I pushed the lot. Thanks for the review.

BR,
Jani.


>
> Reviewed-by: Ville Syrjälä 
>
>> 
>> BR,
>> Jani.
>> 
>> Jani Nikula (7):
>>   drm/i915/dsi: don't debug log "missing" sequences
>>   drm/i915/dsi: add debug logging to element execution
>>   drm/i915/dsi: add skip functions for spi and pmic elements
>>   drm/i915/dsi: update reset and power sequences in panel
>> prepare/unprepare hooks
>>   drm/i915/dsi: run backlight on/off sequences in panel enable/disable
>> hooks
>>   drm/i915/bios: log about presence of DSI sequences we do not run
>>   drm/i915/dsi: double check element parsing against size if present
>> 
>>  drivers/gpu/drm/i915/intel_bios.c  |  4 +++
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 48 
>> +-
>>  2 files changed, 45 insertions(+), 7 deletions(-)
>> 
>> -- 
>> 2.1.4

-- 
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 15/18] drm/i915: Reserve space in the global seqno during request allocation

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, Joonas Lahtinen  wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
>> +static int reserve_global_seqno(struct drm_i915_private *i915)
>>  {
>> -struct i915_gem_timeline *tl = _priv->gt.global_timeline;
>> +struct i915_gem_timeline *tl = >gt.global_timeline;
>> +u32 next_seqno = atomic_read(>next_seqno);
>>  
>> -/* reserve 0 for non-seqno */
>> -if (unlikely(tl->next_seqno == 0)) {
>
> Meh, do not hide the ++i915->gt.active_requests in if (unlikely(...)).

*shudder* it doesn't get any better by removing unlikely!

BR,
Jani.

>
>> +if (unlikely(next_seqno + ++i915->gt.active_requests <= next_seqno)) {
>>  int ret;
>>  
>
> Why not if (likely(next_seqno + active_requests > next_seqno))
>   return 0;
>
>> -ret = i915_gem_init_global_seqno(dev_priv, 0);
>> -if (ret)
>> +ret = i915_gem_init_global_seqno(i915, 0);
>> +if (ret) {
>> +i915->gt.active_requests--;
>>  return ret;
>
> With above change the built-in teardown becomes OK. Otherwise split.
>
>> -
>> -tl->next_seqno = 1;
>> +}
>>  }
>>  
>> -*seqno = tl->next_seqno++;
>>  return 0;
>>  }
>>  
>> +static u32 timeline_get_seqno(struct i915_gem_timeline *tl)
>> +{
>> +return atomic_inc_return(>next_seqno);
>> +}
>> +
>
> How about u32 timeline_peek_seqno(), as you have quite a few
> atomic_reads on it. Also, lockdep_assert_held would be useful sprinkled
> ni the functions.
>
> Reviewed-by: Joonas Lahtinen 
>
> Regards, Joonas

-- 
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] [PATCH 5/7] drm/i915/tdr: Add engine reset count to error state

2016-09-19 Thread Matthew Auld
From: "arun.siluv...@linux.intel.com" 

Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.

v2
  - rebase

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c   | 1 +
 drivers/gpu/drm/i915/i915_drv.h   | 9 +
 drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8625207..0017ab5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1857,6 +1857,7 @@ int i915_reset_engine(struct intel_engine_cs *engine)
intel_engine_reset_cancel(engine);
intel_execlists_restart_submission(engine);
 
+   dev_priv->gpu_error.engine_reset_count[engine->id]++;
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return 0;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3dcf3f6..722aea3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -774,6 +774,7 @@ struct drm_i915_error_state {
enum intel_engine_hangcheck_action hangcheck_action;
struct i915_address_space *vm;
int num_requests;
+   u32 reset_count;
 
/* our own tracking of ring head and tail */
u32 cpu_ring_head;
@@ -1431,6 +1432,8 @@ struct i915_gpu_error {
 #define I915_RESET_IN_PROGRESS 0
 #define I915_WEDGED(BITS_PER_LONG - 1)
 
+   unsigned long engine_reset_count[I915_NUM_ENGINES];
+
/**
 * Waitqueue to signal when a hang is detected. Used to for waiters
 * to release the struct_mutex for the reset to procede.
@@ -3268,6 +3271,12 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return READ_ONCE(error->reset_count);
 }
 
+static inline u32 i915_engine_reset_count(struct i915_gpu_error *error,
+ struct intel_engine_cs *engine)
+{
+   return READ_ONCE(error->engine_reset_count[engine->id]);
+}
+
 void i915_gem_reset(struct drm_i915_private *dev_priv);
 void i915_gem_set_wedged(struct drm_i915_private *dev_priv);
 void i915_gem_reset_engine(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 334f15d..905b649 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -296,6 +296,7 @@ static void error_print_engine(struct 
drm_i915_error_state_buf *m,
err_printf(m, "  hangcheck: %s [%d]\n",
   hangcheck_action_to_str(ee->hangcheck_action),
   ee->hangcheck_score);
+   err_printf(m, "  engine reset count: %u\n", ee->reset_count);
 }
 
 void i915_error_printf(struct drm_i915_error_state_buf *e, const char *f, ...)
@@ -1056,6 +1057,8 @@ static void error_record_engine_registers(struct 
drm_i915_error_state *error,
 
ee->hangcheck_score = engine->hangcheck.score;
ee->hangcheck_action = engine->hangcheck.action;
+   ee->reset_count = i915_engine_reset_count(_priv->gpu_error,
+ engine);
 
if (USES_PPGTT(dev_priv)) {
int i;
-- 
2.7.4

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


[Intel-gfx] [PATCH 3/7] drm/i915/tdr: Add support for per engine reset recovery

2016-09-19 Thread Matthew Auld
From: "arun.siluv...@linux.intel.com" 

This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported
from Gen8 onwards.

Hangchecker determines which engines are hung and invokes error handler to
recover from it. Error handler schedules recovery for each of those engines
that are hung. The recovery procedure is as follows,
 - identifies the request that caused the hang and it is dropped
 - force engine to idle: this is done by issuing a reset request
 - reset and re-init engine
 - restart submissions to the engine

If engine reset fails then we fall back to heavy weight full gpu reset
which resets all engines and reinitiazes complete state of HW and SW.

v2
  - rebase

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c | 59 +
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 10 +++
 drivers/gpu/drm/i915/intel_lrc.h|  1 +
 drivers/gpu/drm/i915/intel_uncore.c | 41 +++---
 6 files changed, 105 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 99fa690..8625207 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1812,21 +1812,68 @@ error:
  * Returns zero on successful reset or otherwise an error code.
  *
  * Procedure is fairly simple:
- *  - force engine to idle
- *  - save current state which includes head and current request
- *  - reset engine
- *  - restore saved state and resubmit context
+ *- identifies the request that caused the hang and it is dropped
+ *- force engine to idle: this is done by issuing a reset request
+ *- reset engine
+ *- restart submissions to the engine
  */
 int i915_reset_engine(struct intel_engine_cs *engine)
 {
int ret;
struct drm_i915_private *dev_priv = engine->i915;
 
-   /* FIXME: replace me with engine reset sequence */
-   ret = -ENODEV;
+   /*
+* We need to first idle the engine by issuing a reset request,
+* then perform soft reset and re-initialize hw state, for all of
+* this GT power need to be awake so ensure it does throughout the
+* process
+*/
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+   /*
+* the request that caused the hang is stuck on elsp, identify the
+* active request and drop it, adjust head to skip the offending
+* request to resume executing remaining requests in the queue.
+*/
+   i915_gem_reset_engine(engine);
+
+   ret = intel_engine_reset_begin(engine);
+   if (ret) {
+   DRM_ERROR("Failed to disable %s\n", engine->name);
+   goto error;
+   }
+
+   ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine));
+   if (ret) {
+   DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret);
+   intel_engine_reset_cancel(engine);
+   goto error;
+   }
+
+   ret = engine->init_hw(engine);
+   if (ret)
+   goto error;
+
+   intel_engine_reset_cancel(engine);
+   intel_execlists_restart_submission(engine);
 
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+   return 0;
+
+error:
+   /* use full gpu reset to recover on error */
set_bit(I915_RESET_IN_PROGRESS, _priv->gpu_error.flags);
 
+   /* Engine reset is performed without taking struct_mutex, since it
+* failed we now fallback to full gpu reset. Wakeup any waiters
+* which should now see the reset_in_progress and release
+* struct_mutex for us to continue recovery.
+*/
+   rcu_read_lock();
+   intel_engine_wakeup(engine);
+   rcu_read_unlock();
+
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 79de74d..3dcf3f6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2889,6 +2889,8 @@ extern int intel_gpu_reset(struct drm_i915_private 
*dev_priv, u32 engine_mask);
 extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
 extern void i915_reset(struct drm_i915_private *dev_priv);
 extern bool intel_has_engine_reset(struct drm_i915_private *dev_priv);
+extern int intel_engine_reset_begin(struct intel_engine_cs *engine);
+extern int intel_engine_reset_cancel(struct intel_engine_cs *engine);
 extern int i915_reset_engine(struct intel_engine_cs 

[Intel-gfx] [PATCH 6/7] drm/i915/tdr: Export reset count info to debugfs

2016-09-19 Thread Matthew Auld
From: "arun.siluv...@linux.intel.com" 

A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they areexpected to trigger reset; these counts are checked before
and after the test to ensure the same.

v2
  - rebase

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 27b0e34..83c8b02 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1354,6 +1354,24 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_reset_info(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct i915_gpu_error *error = _priv->gpu_error;
+   struct intel_engine_cs *engine;
+
+   seq_printf(m, "full gpu reset = %u\n", i915_reset_count(error));
+
+   for_each_engine(engine, dev_priv) {
+   seq_printf(m, "%s = %u\n", engine->name,
+  i915_engine_reset_count(error, engine));
+   }
+
+   return 0;
+}
+
 static int ironlake_drpc_info(struct seq_file *m)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -5263,6 +5281,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_guc_log_dump", i915_guc_log_dump, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
+   {"i915_reset_info", i915_reset_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
{"i915_emon_status", i915_emon_status, 0},
{"i915_ring_freq_table", i915_ring_freq_table, 0},
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/7] drm/i915/tdr: Modify error handler for per engine hang recovery

2016-09-19 Thread Matthew Auld
From: "arun.siluv...@linux.intel.com" 

This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicable (which fails at this point
because core implementation is lacking) and continue recovery using legacy
full gpu reset.

A helper function is also added to query the availability of engine
reset.

The error events behaviour that are used to notify user of reset are
adapted to engine reset such that it doesn't break users listening to these
events. In legacy we report an error event, a reset event before resetting
the gpu and a reset done event marking the completion of reset. The same
behaviour is adapted but reset event is only dispatched once even when
multiple engines are hung. Finally once reset is complete we send reset
done event as usual.

v2
  - rework slightly
  - prefer INTEL_GEN
  - document engine_mask param

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Ian Lister 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c | 26 +++
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_irq.c | 50 +
 drivers/gpu/drm/i915/intel_uncore.c |  5 
 4 files changed, 78 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f4e8ad..99fa690 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1804,6 +1804,32 @@ error:
goto wakeup;
 }
 
+/**
+ * i915_reset_engine - reset GPU engine to recover from a hang
+ * @engine: engine to reset
+ *
+ * Reset a specific GPU engine. Useful if a hang is detected.
+ * Returns zero on successful reset or otherwise an error code.
+ *
+ * Procedure is fairly simple:
+ *  - force engine to idle
+ *  - save current state which includes head and current request
+ *  - reset engine
+ *  - restore saved state and resubmit context
+ */
+int i915_reset_engine(struct intel_engine_cs *engine)
+{
+   int ret;
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   /* FIXME: replace me with engine reset sequence */
+   ret = -ENODEV;
+
+   set_bit(I915_RESET_IN_PROGRESS, _priv->gpu_error.flags);
+
+   return ret;
+}
+
 static int i915_pm_suspend(struct device *kdev)
 {
struct pci_dev *pdev = to_pci_dev(kdev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4dd307e..79de74d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2888,6 +2888,8 @@ extern long i915_compat_ioctl(struct file *filp, unsigned 
int cmd,
 extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
 extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
 extern void i915_reset(struct drm_i915_private *dev_priv);
+extern bool intel_has_engine_reset(struct drm_i915_private *dev_priv);
+extern int i915_reset_engine(struct intel_engine_cs *engine);
 extern int intel_guc_reset(struct drm_i915_private *dev_priv);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c128fdb..45c5a26 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2487,11 +2487,13 @@ static void i915_error_wake_up(struct drm_i915_private 
*dev_priv)
 /**
  * i915_reset_and_wakeup - do process context error handling work
  * @dev_priv: i915 device private
+ * @engine_mask: engines which are marked as hung
  *
  * Fire an error uevent so userspace can see that a hang or error
  * was detected.
  */
-static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv)
+static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv,
+ u32 engine_mask)
 {
struct kobject *kobj = _priv->drm.primary->kdev->kobj;
char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
@@ -2501,6 +2503,15 @@ static void i915_reset_and_wakeup(struct 
drm_i915_private *dev_priv)
kobject_uevent_env(kobj, KOBJ_CHANGE, error_event);
 
DRM_DEBUG_DRIVER("resetting chip\n");
+   /*
+* This event needs to be sent before performing gpu reset. When
+* engine resets are supported we iterate through all engines and
+* reset hung engines individually. To keep the event dispatch
+* mechanism consistent with full gpu reset, this is only sent once
+* even when multiple engines are hung. It is also safe to 

[Intel-gfx] [PATCH 4/7] drm/i915: Skip reset request if there is one already

2016-09-19 Thread Matthew Auld
From: Mika Kuoppala 

To perform engine reset we first disable engine to capture its state. This
is done by issuing a reset request. Because we are reusing existing
infrastructure, again when we actually reset an engine, reset function
checks engine mask and issues reset request again which is unnecessary. To
avoid this we check if the engine is already prepared, if so we just exit
from that point.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/intel_uncore.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 0738ac7..34f1658 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1679,10 +1679,15 @@ int intel_wait_for_register(struct drm_i915_private 
*dev_priv,
 static int gen8_engine_reset_begin(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
+   const i915_reg_t reset_ctrl = RING_RESET_CTL(engine->mmio_base);
+   const u32 ready = RESET_CTL_REQUEST_RESET | RESET_CTL_READY_TO_RESET;
int ret;
 
-   I915_WRITE_FW(RING_RESET_CTL(engine->mmio_base),
- _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET));
+   /* If engine has been already prepared, we can shortcut here */
+   if ((I915_READ_FW(reset_ctrl) & ready) == ready)
+   return 0;
+
+   I915_WRITE_FW(reset_ctrl, _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET));
 
ret = intel_wait_for_register_fw(dev_priv,
 RING_RESET_CTL(engine->mmio_base),
-- 
2.7.4

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


[Intel-gfx] [PATCH 7/7] drm/i915/tdr: Enable Engine reset and recovery support

2016-09-19 Thread Matthew Auld
From: "arun.siluv...@linux.intel.com" 

This feature is made available only from Gen8, for previous gen devices
driver uses legacy full gpu reset.

v2
  - rebase

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index a945ec1..d2a6e83 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,7 @@ struct i915_params i915 __read_mostly = {
.prefault_disable = 0,
.load_detect_test = 0,
.force_reset_modeset_test = 0,
-   .reset = 1,
+   .reset = 2,
.invert_brightness = 0,
.disable_display = 0,
.enable_cmd_parser = 1,
@@ -113,7 +113,7 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
 module_param_named_unsafe(reset, i915.reset, int, 0600);
-MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset 
[default], 2=engine reset)");
+MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, 
2=engine reset [default])");
 
 module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644);
 MODULE_PARM_DESC(enable_hangcheck,
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets

2016-09-19 Thread Matthew Auld
From: "arun.siluv...@linux.intel.com" 

In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.

v2
  - rebase

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Arun Siluvery 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_params.c | 6 +++---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..a945ec1 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,7 @@ struct i915_params i915 __read_mostly = {
.prefault_disable = 0,
.load_detect_test = 0,
.force_reset_modeset_test = 0,
-   .reset = true,
+   .reset = 1,
.invert_brightness = 0,
.disable_display = 0,
.enable_cmd_parser = 1,
@@ -112,8 +112,8 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-module_param_named_unsafe(reset, i915.reset, bool, 0600);
-MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
+module_param_named_unsafe(reset, i915.reset, int, 0600);
+MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset 
[default], 2=engine reset)");
 
 module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 0644);
 MODULE_PARM_DESC(enable_hangcheck,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 3a0dd78..2f188bb 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -34,6 +34,7 @@ struct i915_params {
int lvds_channel_mode;
int panel_use_ssc;
int vbt_sdvo_panel_type;
+   int reset;
int enable_rc6;
int enable_dc;
int enable_fbc;
@@ -58,7 +59,6 @@ struct i915_params {
bool prefault_disable;
bool load_detect_test;
bool force_reset_modeset_test;
-   bool reset;
bool disable_display;
bool verbose_state_checks;
bool nuclear_pageflip;
-- 
2.7.4

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


Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-09-19 Thread James Bottomley
On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote:
> Hi! James & Paulo: What's the current status of this?

No, the only interaction has been the suggestion below for a revert,
which didn't fix the problem.

>  Was this issue discussed elsewhere or even fixed in between? Just 
> asking, because this issue is on the list of regressions for 4.8.


I'm just about to try out -rc7, but it's not fixed so far.

James


> Ciao, Thorsten
> 
> On 01.09.2016 00:25, James Bottomley wrote:
> > On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote:
> > > Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
> > > > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> > > > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > > > > > We seem to have an xrandr regression with skylake now. 
> > > > > >  What's
> > > > > > happening is that I can get output on to a projector, but
> > > > > > the 
> > > > > > system is losing video when I change the xrandr sessions
> > > > > > (like 
> > > > > > going from a --above b to a --same-as b).  The main screen
> > > > > > goes
> > > > > > blank, which is basically a reboot situation. 
> > > > > >  Unfortunately, I
> > > > > > can't seem to get the logs out of systemd to see if there
> > > > > > was a
> > > > > > dump to dmesg (the system was definitely responding).
> > > > > > 
> > > > > > I fell back to 4.6.2 which worked perfectly, so this is
> > > > > > definitely 
> > > > > > some sort of regression.  I'll be able to debug more fully
> > > > > > when
> > > > > > I 
> > > > > > get back home from the Linux Security Summit.
> > > > > 
> > > > > I'm home now.  Unfortunately, my monitor isn't as problematic
> > > > > as
> > > > > the
> > > > > projector, but by flipping between various modes and
> > > > > separating
> > > > > and
> > > > > overlaying the panels with --above and --same-as (xrandr), I
> > > > > can
> > > > > eventually get it to the point where the main LCD panel goes
> > > > > black 
> > > > > and can only be restarted by specifying a different mode.
> > > > > 
> > > > > This seems to be associated with these lines in the X
> > > > > 
> > > > > [ 14714.389] (EE) intel(0): failed to set mode: Invalid
> > > > > argument
> > > > > [22]
> > > > > 
> > > > > But the curious thing is that even if this fails with the
> > > > > error 
> > > > > message once, it may succeed a second time, so it looks to be
> > > > > a 
> > > > > transient error translation problem from the kernel driver.
> > > > > 
> > > > > I've attached the full log below.
> > > > > 
> > > > > This is only with a VGA output.  I currently don't have a
> > > > > HDMI 
> > > > > dongle, but I'm in the process of acquiring one.
> > > > 
> > > > After more playing around, I'm getting thousands of these in
> > > > the
> > > > kernel
> > > > log (possibly millions: the log wraps very fast):
> > > > 
> > > > [23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR*
> > > > failed
> > > > to train DP, aborting
> > > > 
> > > > And then finally it gives up with 
> > > > 
> > > > [25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> > > > *ERROR* CPU pipe B FIFO underrun
> > > > [25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> > > > *ERROR* CPU pipe A FIFO underrun
> > > > 
> > > > And the crtc for the VGA output becomes non-responsive to any
> > > > configuration command.  This requires a reboot and sometimes a
> > > > UEFI
> > > > variable reset before it comes back.
> > > 
> > > Please see this discussion:
> > > https://patchwork.freedesktop.org/patch/103237/
> > > 
> > > Do you have this patch on your tree? Does the problem go away if
> > > you
> > > revert it?
> > 
> > Yes, I've got it, it went in in 4.8-rc3 according to git:
> > 
> > commit 58e311b09c319183254d9220c50a533e7157c9ab
> > Author: Matt Roper 
> > Date:   Thu Aug 4 14:08:00 2016 -0700
> > 
> > drm/i915/gen9: Give one extra block per line for SKL plane WM
> > calculations
> > 
> > Reverting it causes the secondary display not to sync pretty much
> > at
> > all.  However, in the flickers I can see, it does work OK and
> > doesn't
> > now crash switching from --same-as to --above and back
> > 
> > I also still get the logs filling up with the link training errors.
> > 
> > On balance, although the behaviour is different, it's not an
> > improvement because if I can't sync with the projector, I can't
> > really
> > use this as a fix.
> > 
> > James
> 

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


Re: [Intel-gfx] [PATCH] drm: fix implicit declaration build error on ia64

2016-09-19 Thread Daniel Vetter
On Fri, Sep 16, 2016 at 01:06:36PM +0300, Jani Nikula wrote:
>drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_downstream_debug':
> >> drivers/gpu/drm/drm_dp_helper.c:551:2: error: implicit declaration of
> >> function 'seq_printf' [-Werror=implicit-function-declaration]
>  seq_printf(m, "\tDP branch device present: %s\n",
>  ^
> >> drivers/gpu/drm/drm_dp_helper.c:559:3: error: implicit declaration of
> >> function 'seq_puts' [-Werror=implicit-function-declaration]
>  seq_puts(m, "\t\tType: DisplayPort\n");
>  ^
> 
> Reported-by: kbuild test robot 
> References: 
> https://lists.freedesktop.org/archives/intel-gfx/2016-September/106638.html
> Fixes: 80209e5f2c42 ("drm: Add DP branch device info on debugfs")
> Cc: Mika Kahola 
> Signed-off-by: Jani Nikula 

Applied to drm-misc (yeah wrong branch, but easier that way ...).

Thanks, Daniel

> 
> ---
> 
> The commit being fixed is only in drm-intel tree. I failed at actually
> testing this, but I presume this is the fix...
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index a5365142cdba..894a6ac6f6e7 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 03/10] drm: Move all decl for drm_edid.c to drm_edid.h

2016-09-19 Thread Daniel Vetter
On Tue, Sep 06, 2016 at 12:59:39PM -0400, Sean Paul wrote:
> On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
> wrote:
> > Some were still left in drm_crtc.h. Also include drm_edid.h in the
> > rst files.
> >
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Sean Paul 

Merged up to this patch, thanks for the review.
-Daniel

> 
> > ---
> >  Documentation/gpu/drm-kms-helpers.rst |  3 +++
> >  include/drm/drm_crtc.h| 30 +-
> >  include/drm/drm_edid.h| 30 ++
> >  3 files changed, 34 insertions(+), 29 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 48fc5a96bf95..bb4254d19cbb 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -208,6 +208,9 @@ Output Probing Helper Functions Reference
> >  EDID Helper Functions Reference
> >  ===
> >
> > +.. kernel-doc:: include/drm/drm_edid.h
> > +   :internal:
> > +
> >  .. kernel-doc:: drivers/gpu/drm/drm_edid.c
> > :export:
> >
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index bf9ee1b97c26..7bb3aa87a8be 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -43,6 +43,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  struct drm_device;
> >  struct drm_mode_set;
> > @@ -1992,33 +1993,4 @@ assert_drm_connector_list_read_locked(struct 
> > drm_mode_config *mode_config)
> > !drm_modeset_is_locked(_config->connection_mutex));
> >  }
> >
> > -/* drm_edid.c */
> > -bool drm_probe_ddc(struct i2c_adapter *adapter);
> > -struct edid *drm_get_edid(struct drm_connector *connector,
> > - struct i2c_adapter *adapter);
> > -struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> > -struct i2c_adapter *adapter);
> > -struct edid *drm_edid_duplicate(const struct edid *edid);
> > -int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
> > -
> > -u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> > -enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
> > -bool drm_detect_hdmi_monitor(struct edid *edid);
> > -bool drm_detect_monitor_audio(struct edid *edid);
> > -bool drm_rgb_quant_range_selectable(struct edid *edid);
> > -int drm_add_modes_noedid(struct drm_connector *connector,
> > -int hdisplay, int vdisplay);
> > -void drm_set_preferred_mode(struct drm_connector *connector,
> > -   int hpref, int vpref);
> > -
> > -int drm_edid_header_is_valid(const u8 *raw_edid);
> > -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
> > - bool *edid_corrupt);
> > -bool drm_edid_is_valid(struct edid *edid);
> > -void drm_edid_get_monitor_name(struct edid *edid, char *name,
> > -  int buflen);
> > -struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
> > -  int hsize, int vsize, int fresh,
> > -  bool rb);
> > -
> >  #endif /* __DRM_CRTC_H__ */
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 919933d1beb4..c3a7d440bc11 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -25,6 +25,9 @@
> >
> >  #include 
> >
> > +struct drm_device;
> > +struct i2c_adapter;
> > +
> >  #define EDID_LENGTH 128
> >  #define DDC_ADDR 0x50
> >  #define DDC_ADDR2 0x52 /* E-DDC 1.2 - where DisplayID can hide */
> > @@ -423,9 +426,36 @@ static inline u8 drm_eld_get_conn_type(const uint8_t 
> > *eld)
> > return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
> >  }
> >
> > +bool drm_probe_ddc(struct i2c_adapter *adapter);
> >  struct edid *drm_do_get_edid(struct drm_connector *connector,
> > int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
> >   size_t len),
> > void *data);
> > +struct edid *drm_get_edid(struct drm_connector *connector,
> > + struct i2c_adapter *adapter);
> > +struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> > +struct i2c_adapter *adapter);
> > +struct edid *drm_edid_duplicate(const struct edid *edid);
> > +int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
> > +
> > +u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> > +enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
> > +bool drm_detect_hdmi_monitor(struct edid *edid);
> > +bool drm_detect_monitor_audio(struct edid *edid);
> > +bool drm_rgb_quant_range_selectable(struct edid *edid);
> > +int drm_add_modes_noedid(struct drm_connector 

Re: [Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences

2016-09-19 Thread Ville Syrjälä
On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote:
> v2 of an old series, addressing issues pointed out by Ville.

Entire series looks reasonable. Spec is vague, so hard to be 100% sure.

Reviewed-by: Ville Syrjälä 

> 
> BR,
> Jani.
> 
> Jani Nikula (7):
>   drm/i915/dsi: don't debug log "missing" sequences
>   drm/i915/dsi: add debug logging to element execution
>   drm/i915/dsi: add skip functions for spi and pmic elements
>   drm/i915/dsi: update reset and power sequences in panel
> prepare/unprepare hooks
>   drm/i915/dsi: run backlight on/off sequences in panel enable/disable
> hooks
>   drm/i915/bios: log about presence of DSI sequences we do not run
>   drm/i915/dsi: double check element parsing against size if present
> 
>  drivers/gpu/drm/i915/intel_bios.c  |  4 +++
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 48 
> +-
>  2 files changed, 45 insertions(+), 7 deletions(-)
> 
> -- 
> 2.1.4

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


Re: [Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +static int reserve_global_seqno(struct drm_i915_private *i915)
>  {
> - struct i915_gem_timeline *tl = _priv->gt.global_timeline;
> + struct i915_gem_timeline *tl = >gt.global_timeline;
> + u32 next_seqno = atomic_read(>next_seqno);
>  
> - /* reserve 0 for non-seqno */
> - if (unlikely(tl->next_seqno == 0)) {

Meh, do not hide the ++i915->gt.active_requests in if (unlikely(...)).

> + if (unlikely(next_seqno + ++i915->gt.active_requests <= next_seqno)) {
>   int ret;
>  

Why not if (likely(next_seqno + active_requests > next_seqno))
return 0;

> - ret = i915_gem_init_global_seqno(dev_priv, 0);
> - if (ret)
> + ret = i915_gem_init_global_seqno(i915, 0);
> + if (ret) {
> + i915->gt.active_requests--;
>   return ret;

With above change the built-in teardown becomes OK. Otherwise split.

> -
> - tl->next_seqno = 1;
> + }
>   }
>  
> - *seqno = tl->next_seqno++;
>   return 0;
>  }
>  
> +static u32 timeline_get_seqno(struct i915_gem_timeline *tl)
> +{
> + return atomic_inc_return(>next_seqno);
> +}
> +

How about u32 timeline_peek_seqno(), as you have quite a few
atomic_reads on it. Also, lockdep_assert_held would be useful sprinkled
ni the functions.

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 14/18] drm/i915: Create a unique name for the context

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -310,12 +311,21 @@ __create_hw_context(struct drm_device *dev,
>   goto err_out;
>   } else
>   ret = DEFAULT_CONTEXT_HANDLE;

Confusing indent, so add braces to above else and a newline here.

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 13/18] drm/i915: Move the global sync optimisation to the timeline

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -262,6 +263,12 @@ static int i915_gem_init_global_seqno(struct 
> drm_i915_private *dev_priv,
>   for_each_engine(engine, dev_priv)
>   intel_engine_init_global_seqno(engine, seqno);
>  
> + list_for_each_entry(tl, _priv->gt.timelines, link) {
> + for (i = 0; i < ARRAY_SIZE(tl->engine); i++)
> + memset(tl->engine[i].sync_seqno, 0,
> +    sizeof(tl->engine[i].sync_seqno));
> + }
> +

I think have braces in both loops or neither, looks extremely odd
otherwise.

> @@ -454,7 +461,7 @@ static int
>  i915_gem_request_await_request(struct drm_i915_gem_request *to,
> >        struct drm_i915_gem_request *from)
>  {
> > -   int idx, ret;
> > +   int ret;
>  
> >     GEM_BUG_ON(to == from);
>  
> @@ -474,8 +481,7 @@ i915_gem_request_await_request(struct 
> drm_i915_gem_request *to,
>   return ret < 0 ? ret : 0;
>   }
>  
> - idx = intel_engine_sync_index(from->engine, to->engine);

You remove this here, and the only place it remains used
is i915_gpu_error.c, maybe make it static in there?

> @@ -263,16 +263,13 @@ static void error_print_engine(struct 
> drm_i915_error_state_buf *m,
>   if (INTEL_GEN(m->i915) >= 6) {
>   err_printf(m, "  RC PSMI: 0x%08x\n", ee->rc_psmi);
>   err_printf(m, "  FAULT_REG: 0x%08x\n", ee->fault_reg);
> - err_printf(m, "  SYNC_0: 0x%08x [last synced 0x%08x]\n",
> -    ee->semaphore_mboxes[0],
> -    ee->semaphore_seqno[0]);
> - err_printf(m, "  SYNC_1: 0x%08x [last synced 0x%08x]\n",
> -    ee->semaphore_mboxes[1],
> -    ee->semaphore_seqno[1]);
> + err_printf(m, "  SYNC_0: 0x%08x\n",
> +    ee->semaphore_mboxes[0]);
> + err_printf(m, "  SYNC_1: 0x%08x\n",
> +    ee->semaphore_mboxes[1]);
>   if (HAS_VEBOX(m->i915)) {
> - err_printf(m, "  SYNC_2: 0x%08x [last synced 0x%08x]\n",
> -    ee->semaphore_mboxes[2],
> -    ee->semaphore_seqno[2]);
> + err_printf(m, "  SYNC_2: 0x%08x\n",
> +    ee->semaphore_mboxes[2]);
>   }

You can drop these braces too.

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 05/10] drm/doc: Polish for drm_plane.[hc]

2016-09-19 Thread Daniel Vetter
On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote:
> 
> 
> On 8/31/2016 9:39 PM, Daniel Vetter wrote:
> > Big thing is untangling and carefully documenting the different uapi
> > types of planes. I also sprinkled a few more cross references around
> > to make this easier to discover.
> > 
> > As usual, remove the kerneldoc for internal functions which are not
> > exported. Aside: We should probably go OCD on all the ioctl handlers
> > and consistenly give them an _ioctl postfix.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >   Documentation/gpu/drm-kms.rst |  47 +--
> >   drivers/gpu/drm/drm_crtc.c|   6 +-
> >   drivers/gpu/drm/drm_plane.c   | 132 
> > --
> >   include/drm/drm_plane.h   |  57 +-
> >   4 files changed, 86 insertions(+), 156 deletions(-)
> > 
> 
> 
> > +/**
> > + * enum drm_plane_type - uapi plane type enumeration
> > + *
> > + * For historical reasons not all planes are made the same. This 
> > enumeration is
> > + * used to tell the different types of planes apart to implement the 
> > different
> > + * uapi semantics for them. For userspace which is universal plane aware 
> > and
> > + * which is using that atomic IOCTL there's no difference between these 
> > planes
> > + * (beyong what the driver and hardware can support of course).
> > + *
> > + * For compatibility with legacy userspace, only overlay planes are made
> > + * available to userspace by default. Userspace clients may set the
> > + * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that 
> > they
> > + * wish to receive a universal plane list containing all plane types. See 
> > also
> > + * drm_for_each_legacy_plane().
> > + */
> >   enum drm_plane_type {
> > -   DRM_PLANE_TYPE_OVERLAY,
> 
> Any reason why you moved this down? I guess there is no harm, but people
> might be printing plane type while debugging, and they'd assume
> DRM_PLANE_TYPE_OVERLAY=0

I think starting out with 0 for the primary plane makes a lot more sense,
and since it's an internal thing we can change it however we want. I also
think from a documentation pov it reads better if the 2 special planes
(primary and cursor) are first.

But I'm happy to shuffle it back if you feel strongly the other way round.
-Daniel

> 
> Thanks,
> Archit
> 
> > +   /**
> > +* @DRM_PLANE_TYPE_PRIMARY:
> > +*
> > +* Primary planes represent a "main" plane for a CRTC.  Primary planes
> > +* are the planes operated upon by CRTC modesetting and flipping
> > +* operations described in the page_flip and set_config hooks in struct
> > +* _crtc_funcs.
> > +*/
> > DRM_PLANE_TYPE_PRIMARY,
> > +
> > +   /**
> > +* @DRM_PLANE_TYPE_CURSOR:
> > +*
> > +* Cursor planes represent a "cursor" plane for a CRTC.  Cursor planes
> > +* are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
> > +* DRM_IOCTL_MODE_CURSOR2 IOCTLs.
> > +*/
> > DRM_PLANE_TYPE_CURSOR,
> > +
> > +   /**
> > +* @DRM_PLANE_TYPE_OVERLAY:
> > +*
> > +* Overlay planes represent all non-primary, non-cursor planes. Some
> > +* drivers refer to these types of planes as "sprites" internally.
> > +*/
> > +   DRM_PLANE_TYPE_OVERLAY,
> >   };
> > 
> > 
> > @@ -458,11 +496,26 @@ static inline struct drm_plane *drm_plane_find(struct 
> > drm_device *dev,
> > list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
> > for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))
> > 
> > -/* Plane list iterator for legacy (overlay only) planes. */
> > +/**
> > + * drm_for_each_legacy_plane - iterate over all planes for legacy userspace
> > + * @plane: the loop cursor
> > + * @dev: the DRM device
> > + *
> > + * Iterate over all legacy planes of @dev, excluding primary and cursor 
> > planes.
> > + * This is useful for implementing userspace apis when userspace is not
> > + * universal plane aware. See also enum _plane_type.
> > + */
> >   #define drm_for_each_legacy_plane(plane, dev) \
> > list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) \
> > for_each_if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> > 
> > +/**
> > + * drm_for_each_plane - iterate over all planes
> > + * @plane: the loop cursor
> > + * @dev: the DRM device
> > + *
> > + * Iterate over all planes of @dev, include primary and cursor planes.
> > + */
> >   #define drm_for_each_plane(plane, dev) \
> > list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
> > 
> > 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

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


Re: [Intel-gfx] [PATCH 04/10] drm: Extract drm_plane.[hc]

2016-09-19 Thread Daniel Vetter
On Tue, Sep 06, 2016 at 12:59:31PM -0400, Sean Paul wrote:
> On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
> wrote:
> > Just pure code movement, cleanup and polish will happen in later
> > patches.
> >
> > v2: Don't forget all the ioctl! To extract those cleanly I decided to
> > put check_src_coords into drm_framebuffer.c (and give it a
> > drm_framebuffer_ prefix), since that just checks framebuffer
> > constraints.
> >
> > Signed-off-by: Daniel Vetter 
> > ---
> >  Documentation/gpu/drm-kms.rst   |  12 +
> >  drivers/gpu/drm/Makefile|   3 +-
> >  drivers/gpu/drm/drm_crtc.c  | 939 
> > +---
> >  drivers/gpu/drm/drm_crtc_internal.h |  38 +-
> >  drivers/gpu/drm/drm_framebuffer.c   |  26 +
> >  drivers/gpu/drm/drm_plane.c | 937 
> > +++
> >  include/drm/drm_atomic.h| 154 ++
> >  include/drm/drm_crtc.h  | 583 +-
> >  include/drm/drm_plane.h | 470 ++
> >  9 files changed, 1628 insertions(+), 1534 deletions(-)
> >  create mode 100644 drivers/gpu/drm/drm_plane.c
> >  create mode 100644 include/drm/drm_plane.h
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index f9a991bb87d4..33181be97151 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -110,6 +110,18 @@ Note that dumb objects may not be used for gpu 
> > acceleration, as has been
> >  attempted on some ARM embedded platforms. Such drivers really must have
> >  a hardware-specific ioctl to allocate suitable buffer objects.
> >
> > +Plane Abstraction
> > +=
> > +
> > +Plane Functions Reference
> > +-
> > +
> > +.. kernel-doc:: include/drm/drm_plane.h
> > +   :internal:
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > +   :export:
> > +
> >  Display Modes Function Reference
> >  
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 439d89b25ae0..8eeb07a35798 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -14,7 +14,8 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> > drm_rect.o drm_vma_manager.o drm_flip_work.o \
> > drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> > drm_framebuffer.o drm_connector.o drm_blend.o \
> > -   drm_encoder.o drm_mode_object.o drm_property.o
> > +   drm_encoder.o drm_mode_object.o drm_property.o \
> > +   drm_plane.o
> >
> >  drm-$(CONFIG_COMPAT) += drm_ioc32.o
> >  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 0fad433f4d2d..513ab4729683 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> 
> 
> 
> > -
> > -static int check_src_coords(uint32_t src_x, uint32_t src_y,
> > -   uint32_t src_w, uint32_t src_h,
> > -   const struct drm_framebuffer *fb)
> > -{
> > -   unsigned int fb_width, fb_height;
> > -
> > -   fb_width = fb->width << 16;
> > -   fb_height = fb->height << 16;
> > -
> > -   /* Make sure source coordinates are inside the fb. */
> > -   if (src_w > fb_width ||
> > -   src_x > fb_width - src_w ||
> > -   src_h > fb_height ||
> > -   src_y > fb_height - src_h) {
> > -   DRM_DEBUG_KMS("Invalid source coordinates "
> > - "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
> > - src_w >> 16, ((src_w & 0x) * 15625) >> 10,
> > - src_h >> 16, ((src_h & 0x) * 15625) >> 10,
> > - src_x >> 16, ((src_x & 0x) * 15625) >> 10,
> > - src_y >> 16, ((src_y & 0x) * 15625) >> 
> > 10);
> > -   return -ENOSPC;
> > -   }
> > -
> > -   return 0;
> > -}
> 
> I'm good with this change, but I'd argue that it probably belongs in
> its own patch.

Except for moving the function + giving it a prefix (since it's no longer
static) there's no change here.
> 
> 
> 
> 
> >  /**
> > - * drm_mode_page_flip_ioctl - schedule an asynchronous fb update
> > - * @dev: DRM device
> > - * @data: ioctl data
> > - * @file_priv: DRM file info
> > - *
> > - * This schedules an asynchronous update on a given CRTC, called page flip.
> > - * Optionally a drm event is generated to signal the completion of the 
> > event.
> > - * Generic drivers cannot assume that a pageflip with changed framebuffer
> > - * properties (including driver specific metadata like tiling layout) will 
> > work,
> > - * but some drivers support e.g. pixel format changes through the pageflip
> > - * ioctl.
> > - *
> > - * Called by the user via ioctl.
> > - *
> > - * Returns:

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: clean up dsi sequences

2016-09-19 Thread Patchwork
== Series Details ==

Series: drm/i915: clean up dsi sequences
URL   : https://patchwork.freedesktop.org/series/12640/
State : warning

== Summary ==

Series 12640v1 drm/i915: clean up dsi sequences
https://patchwork.freedesktop.org/api/1.0/series/12640/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> SKIP   (fi-hsw-4770r)

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-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-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   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_2554/

0d6fa72a8c18ec6ab4dbabf5202b8d1cad840e04 drm-intel-nightly: 
2016y-09m-19d-09h-28m-11s UTC integration manifest
13c9cdf drm/i915/dsi: double check element parsing against size if present
57a905b drm/i915/bios: log about presence of DSI sequences we do not run
c979437 drm/i915/dsi: run backlight on/off sequences in panel enable/disable 
hooks
248085c drm/i915/dsi: update reset and power sequences in panel 
prepare/unprepare hooks
c34bc49 drm/i915/dsi: add skip functions for spi and pmic elements
c82ca7c2 drm/i915/dsi: add debug logging to element execution
b23a5c0 drm/i915/dsi: don't debug log "missing" sequences

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze

2016-09-19 Thread Joonas Lahtinen
On ma, 2016-09-19 at 09:38 +0100, Chris Wilson wrote:
> On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote:
> > 
> > On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
> > > 
> > >  int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
> > >  {
> > > > 
> > > > > > > >     struct drm_i915_gem_object *obj;
> > > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private 
> > > *dev_priv)
> > > > 
> > > > > > > >      * the objects as well.
> > > > > > > >      */
> > >  
> > > > 
> > > > > > > > -   i915_gem_shrink_all(dev_priv);
> > > > > > +   mutex_lock(_priv->drm.struct_mutex);
> > 
> > Previously the shrinking here was without a mutex. And the new
> > shrinking during _freeze is also mutex protected, any specific reason?
> 
> Silencing lockdep. We know we are single threaded here, but lockdep
> doesn't. This version of i915_gem_shrink() doesn't automagically take
> the struct_mutex (later versions do).

Throw the info to commit message. Then all good.

Regards, Joonas

> -Chris
> 
-- 
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 12/18] drm/i915: Defer request emission

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +static void gen8_emit_wa_tail(struct drm_i915_gem_request *request, u32 *out)
>  {
> - struct intel_ring *ring = request->ring;
> - int ret;
> -
> - ret = intel_ring_begin(request, 6 + WA_TAIL_DWORDS);
> - if (ret)
> - return ret;
> + out[0] = MI_NOOP;
> + out[1] = MI_NOOP;

How about storing 'out' on the request and still using the emit
wrapper? I assume passing a separate variable might end up rather
fragile.

> -static int gen8_rcs_signal(struct drm_i915_gem_request *req)
> +static u32 *gen8_rcs_signal(struct drm_i915_gem_request *req, u32 *out)
>  {
> - struct intel_ring *ring = req->ring;
>   struct drm_i915_private *dev_priv = req->i915;
>   struct intel_engine_cs *waiter;
>   enum intel_engine_id id;
> - int ret, num_rings;
> -
> - num_rings = INTEL_INFO(dev_priv)->num_rings;
> - ret = intel_ring_begin(req, (num_rings-1) * 8);
> - if (ret)
> - return ret;
>  
>   for_each_engine_id(waiter, dev_priv, id) {
>   u64 gtt_offset = req->engine->semaphore.signal_ggtt[id];
>   if (gtt_offset == MI_SEMAPHORE_SYNC_INVALID)
>   continue;
>  
> - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
> - intel_ring_emit(ring,
> - PIPE_CONTROL_GLOBAL_GTT_IVB |
> - PIPE_CONTROL_QW_WRITE |
> - PIPE_CONTROL_CS_STALL);
> - intel_ring_emit(ring, lower_32_bits(gtt_offset));
> - intel_ring_emit(ring, upper_32_bits(gtt_offset));
> - intel_ring_emit(ring, req->global_seqno);
> - intel_ring_emit(ring, 0);
> - intel_ring_emit(ring,
> - MI_SEMAPHORE_SIGNAL |
> - MI_SEMAPHORE_TARGET(waiter->hw_id));
> - intel_ring_emit(ring, 0);
> + *out++ = GFX_OP_PIPE_CONTROL(6);
> + *out++ = (PIPE_CONTROL_GLOBAL_GTT_IVB |
> +   PIPE_CONTROL_QW_WRITE |
> +   PIPE_CONTROL_CS_STALL);
> + *out++ = lower_32_bits(gtt_offset);
> + *out++ = upper_32_bits(gtt_offset);
> + *out++ = req->global_seqno;
> + *out++ = 0;
> + *out++ = (MI_SEMAPHORE_SIGNAL |
> +   MI_SEMAPHORE_TARGET(waiter->hw_id));
> + *out++ = 0;

And this is mixing a different approach in... Pick one and convert
others to it. I like having the wrapper for easier grepping of emitted
commands, but YMMV.

> +static void gen6_sema_emit_request(struct drm_i915_gem_request *req,
> +    u32 *out)
>  {
> - int ret;
> -
> - ret = req->engine->semaphore.signal(req);
> - if (ret)
> - return ret;
> -
> - return i9xx_emit_request(req);
> + return i9xx_emit_request(req, req->engine->semaphore.signal(req, out));

Not sure if this chaining is beautiful, I'd split signal to its own
line of "out = ...".

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


[Intel-gfx] [PATCH v2 6/7] drm/i915/bios: log about presence of DSI sequences we do not run

2016-09-19 Thread Jani Nikula
Leave behind some debugging clues in case some panels don't work
properly.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_bios.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index c6e69e4cfa83..83667e8cdd6b 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -996,6 +996,10 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv,
goto err;
}
 
+   /* Log about presence of sequences we won't run. */
+   if (seq_id == MIPI_SEQ_TEAR_ON || seq_id == MIPI_SEQ_TEAR_OFF)
+   DRM_DEBUG_KMS("Unsupported sequence %u\n", seq_id);
+
dev_priv->vbt.dsi.sequence[seq_id] = data + index;
 
if (sequence->version >= 3)
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 5/7] drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks

2016-09-19 Thread Jani Nikula
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 2c5d14eb7851..24953f9f7e1d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -477,12 +477,14 @@ static int vbt_panel_unprepare(struct drm_panel *panel)
 static int vbt_panel_enable(struct drm_panel *panel)
 {
generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_ON);
+   generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_ON);
 
return 0;
 }
 
 static int vbt_panel_disable(struct drm_panel *panel)
 {
+   generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_OFF);
generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_OFF);
 
return 0;
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 4/7] drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks

2016-09-19 Thread Jani Nikula
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add power on/off sequences where they
feel logical and update assert/deassert reset. The drm panel hooks don't
currently offer us more granularity anyway.

v2: update assert/deassert reset as well (Ville)

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 29156995a265..2c5d14eb7851 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -459,6 +459,8 @@ static void generic_exec_sequence(struct drm_panel *panel, 
enum mipi_seq seq_id)
 static int vbt_panel_prepare(struct drm_panel *panel)
 {
generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET);
+   generic_exec_sequence(panel, MIPI_SEQ_POWER_ON);
+   generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET);
generic_exec_sequence(panel, MIPI_SEQ_INIT_OTP);
 
return 0;
@@ -466,7 +468,8 @@ static int vbt_panel_prepare(struct drm_panel *panel)
 
 static int vbt_panel_unprepare(struct drm_panel *panel)
 {
-   generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET);
+   generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET);
+   generic_exec_sequence(panel, MIPI_SEQ_POWER_OFF);
 
return 0;
 }
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 7/7] drm/i915/dsi: double check element parsing against size if present

2016-09-19 Thread Jani Nikula
Be a little paranoid in case the specs change or something.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 24953f9f7e1d..9f279a3d0f74 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -441,7 +441,15 @@ static void generic_exec_sequence(struct drm_panel *panel, 
enum mipi_seq seq_id)
operation_size = *data++;
 
if (mipi_elem_exec) {
+   const u8 *next = data + operation_size;
+
data = mipi_elem_exec(intel_dsi, data);
+
+   /* Consistency check if we have size. */
+   if (operation_size && data != next) {
+   DRM_ERROR("Inconsistent operation size\n");
+   return;
+   }
} else if (operation_size) {
/* We have size, skip. */
DRM_DEBUG_KMS("Unsupported MIPI operation byte %u\n",
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 2/7] drm/i915/dsi: add debug logging to element execution

2016-09-19 Thread Jani Nikula
Just simple breadcrumbs for now. While at it, rename the i2c skip
function.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a537c71cdcc6..89f77a142521 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -126,6 +126,8 @@ static const u8 *mipi_exec_send_packet(struct intel_dsi 
*intel_dsi,
u16 len;
enum port port;
 
+   DRM_DEBUG_KMS("\n");
+
flags = *data++;
type = *data++;
 
@@ -199,6 +201,8 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
*intel_dsi, const u8 *data)
 {
u32 delay = *((const u32 *) data);
 
+   DRM_DEBUG_KMS("\n");
+
usleep_range(delay, delay + 10);
data += 4;
 
@@ -307,6 +311,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
u8 gpio_source, gpio_index;
bool value;
 
+   DRM_DEBUG_KMS("\n");
+
if (dev_priv->vbt.dsi.seq_version >= 3)
data++;
 
@@ -331,8 +337,10 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
return data;
 }
 
-static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8 
*data)
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
 {
+   DRM_DEBUG_KMS("Skipping I2C element execution\n");
+
return data + *(data + 6) + 7;
 }
 
@@ -342,7 +350,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
-   [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip,
+   [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
 };
 
 /*
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 3/7] drm/i915/dsi: add skip functions for spi and pmic elements

2016-09-19 Thread Jani Nikula
In sequence block v3 these are gracefully skipped anyway, but add the
functions so we can have some debug breadcrumbs.

v2: the pmic block is 15 bytes (Ville)

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 89f77a142521..29156995a265 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -344,6 +344,20 @@ static const u8 *mipi_exec_i2c(struct intel_dsi 
*intel_dsi, const u8 *data)
return data + *(data + 6) + 7;
 }
 
+static const u8 *mipi_exec_spi(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   DRM_DEBUG_KMS("Skipping SPI element execution\n");
+
+   return data + *(data + 5) + 6;
+}
+
+static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+
+   return data + 15;
+}
+
 typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
const u8 *data);
 static const fn_mipi_elem_exec exec_elem[] = {
@@ -351,6 +365,8 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
[MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
+   [MIPI_SEQ_ELEM_SPI] = mipi_exec_spi,
+   [MIPI_SEQ_ELEM_PMIC] = mipi_exec_pmic,
 };
 
 /*
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 1/7] drm/i915/dsi: don't debug log "missing" sequences

2016-09-19 Thread Jani Nikula
This is not interesting. They are not "missing", they are just not part
of the VBT sequences for the panel.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index cd154ce6b6c1..a537c71cdcc6 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -385,11 +385,8 @@ static void generic_exec_sequence(struct drm_panel *panel, 
enum mipi_seq seq_id)
return;
 
data = dev_priv->vbt.dsi.sequence[seq_id];
-   if (!data) {
-   DRM_DEBUG_KMS("MIPI sequence %d - %s not available\n",
- seq_id, sequence_name(seq_id));
+   if (!data)
return;
-   }
 
WARN_ON(*data != seq_id);
 
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences

2016-09-19 Thread Jani Nikula
v2 of an old series, addressing issues pointed out by Ville.

BR,
Jani.

Jani Nikula (7):
  drm/i915/dsi: don't debug log "missing" sequences
  drm/i915/dsi: add debug logging to element execution
  drm/i915/dsi: add skip functions for spi and pmic elements
  drm/i915/dsi: update reset and power sequences in panel
prepare/unprepare hooks
  drm/i915/dsi: run backlight on/off sequences in panel enable/disable
hooks
  drm/i915/bios: log about presence of DSI sequences we do not run
  drm/i915/dsi: double check element parsing against size if present

 drivers/gpu/drm/i915/intel_bios.c  |  4 +++
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 48 +-
 2 files changed, 45 insertions(+), 7 deletions(-)

-- 
2.1.4

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


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

2016-09-19 Thread Chris Wilson
On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > @@ -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;
> 
> 'initialized_rings' to differentiate as suggested by Tvrtko too.

Tvrtko wasn't referring to this. The point is that we don't know
initialized_rings here, just the declared set of rings we think
the hardware is supposed to have.
-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 01/18] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

2016-09-19 Thread Chris Wilson
On Wed, Sep 14, 2016 at 10:37:18AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > +   array = to_fence_array(fence);
> > +   for (i = 0; i < array->num_fences; i++) {
> > +   struct fence *child = array->fences[i];
> > +
> > +   if (fence_is_i915(child))
> > +   ret = i915_gem_request_await_request(req,
> > +    to_request(child));
> > +   else
> > +   ret = i915_sw_fence_await_dma_fence(>submit,
> > +   child, 10*HZ,
> > +   GFP_KERNEL);
> 
> This chunk repeats from above, make it a small
> __i915_gem_request_await_fence function.

It's not a repeat. If it were, we could just recurse. Except we don't
know how deep the fence-array could go.

> > +   if (ret < 0)
> > +   return ret;
> 
> How about the failure case when we're half bound, no need to tear down?

We submit the partial request that doesn't execute anything more than
the context setup. The next request in the timeline with then inherit
the context setup from this request. Same rule as everything else
handling errors during request construction.
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: fix pwm increment setup

2016-09-19 Thread Patchwork
== Series Details ==

Series: drm/i915: fix pwm increment setup
URL   : https://patchwork.freedesktop.org/series/12636/
State : warning

== Summary ==

Series 12636v1 drm/i915: fix pwm increment setup
https://patchwork.freedesktop.org/api/1.0/series/12636/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k)
Test pm_rpm:
Subgroup basic-rte:
pass   -> SKIP   (fi-hsw-4770r)

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-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: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   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_2553/

0d6fa72a8c18ec6ab4dbabf5202b8d1cad840e04 drm-intel-nightly: 
2016y-09m-19d-09h-28m-11s UTC integration manifest
67275e3 drm/i915/backlight: setup backlight pwm alternate increment on 
backlight enable
aeef3b5 drm/i915/backlight: setup and cache pwm alternate increment value

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


Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread kbuild test robot
Hi Shawn,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.8-rc7 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x012-201638 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/intel_drv.h:32:0,
from drivers/gpu/drm/i915/intel_panel.c:36:
   drivers/gpu/drm/i915/intel_panel.c: In function 'lpt_enable_backlight':
>> drivers/gpu/drm/i915/intel_panel.c:874:78: error: left shift count >= width 
>> of type [-Werror=shift-count-overflow]
  I915_WRITE(SOUTH_CHICKEN2, mul | 
(panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));

 ^
   drivers/gpu/drm/i915/i915_drv.h:3735:83: note: in definition of macro 
'I915_WRITE'
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv, 
(reg), (val), true)

  ^~~
   cc1: all warnings being treated as errors

vim +874 drivers/gpu/drm/i915/intel_panel.c

   868  /* This won't stick until the above enable. */
   869  intel_panel_actually_set_backlight(connector, 
panel->backlight.level);
   870  
   871  if (HAS_PCH_LPT(dev_priv)) {
   872  mul = I915_READ(SOUTH_CHICKEN2);
   873  mul &= ~LPT_PWM_GRANULARITY;
 > 874  I915_WRITE(SOUTH_CHICKEN2, mul | 
 > (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));
   875  } else {
   876  mul = I915_READ(SOUTH_CHICKEN1);
   877  mul &= ~SPT_PWM_GRANULARITY;

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


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


Re: [Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

2016-09-19 Thread kbuild test robot
Hi Shawn,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.8-rc7 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-backlight-setup-backlight-pwm-alternate-increment-on-backlight-enable/20160919-181342
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x008-201638 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_panel.c: In function 'lpt_enable_backlight':
>> drivers/gpu/drm/i915/intel_panel.c:855:23: error: 'struct ' has 
>> no member named 'alternate_pwm_increment'
  if (panel->backlight.alternate_pwm_increment)
  ^
   drivers/gpu/drm/i915/intel_panel.c:862:23: error: 'struct ' has 
no member named 'alternate_pwm_increment'
  if (panel->backlight.alternate_pwm_increment)
  ^

vim +855 drivers/gpu/drm/i915/intel_panel.c

   849  pch_ctl1 &= ~BLM_PCH_PWM_ENABLE;
   850  I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1);
   851  }
   852  
   853  if (HAS_PCH_LPT(dev_priv)) {
   854  schicken = I915_READ(SOUTH_CHICKEN2);
 > 855  if (panel->backlight.alternate_pwm_increment)
   856  schicken |= LPT_PWM_GRANULARITY;
   857  else
   858  schicken &= ~LPT_PWM_GRANULARITY;

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


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


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

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -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;

Could argue these to be #define by current convention.

> @@ -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;

This assignment would then stand out better too, now it looks like a
bunch of function assignments.

> @@ -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;

'initialized_rings' to differentiate as suggested by Tvrtko too.

> +
>   engine->emit_request = gen6_sema_emit_request;
> +
> + num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1;
> + 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++;

Please do add a comment explaining this.

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 10/18] drm/i915: Introduce a global_seqno for each request

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -465,8 +466,15 @@ i915_gem_request_await_request(struct
> drm_i915_gem_request *to,
>   return ret < 0 ? ret : 0;
>   }
>  
> + if (from->global_seqno == 0) {

Just use (!from->global_seqno) here too, for consistency.

Might be worth adding to the commit message that currently global_seqno
is still immediately assigned at creation.

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 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

2016-09-19 Thread Jani Nikula
This will also be needed later on when setting up the alternate
increment in backlight enable.

Cc: Shawn Lee 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_panel.c | 14 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fd16adf069b..c3e65e515c9d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -263,6 +263,7 @@ struct intel_panel {
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
+   bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
bool util_pin_active_low;   /* bxt+ */
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c10e9b0405e8..8bc43205d6a0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
  */
 static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
u32 mul;
 
-   if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY)
+   if (panel->backlight.alternate_pwm_increment)
mul = 128;
else
mul = 16;
@@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
 static u32 lpt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
u32 mul, clock;
 
-   if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY)
+   if (panel->backlight.alternate_pwm_increment)
mul = 16;
else
mul = 128;
@@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector 
*connector, enum pipe unus
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
u32 pch_ctl1, pch_ctl2, val;
+   bool alt;
+
+   if (HAS_PCH_LPT(dev_priv))
+   alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
+   else
+   alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
+   panel->backlight.alternate_pwm_increment = alt;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
-- 
2.1.4

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


[Intel-gfx] [PATCH 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

2016-09-19 Thread Jani Nikula
From: Shawn Lee 

Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.

v2 by Jani, rebase on the patch caching alt increment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
Cc: Cooper Chiou 
Cc: Wei Shun Chen 
Cc: Gary C Wang 
Cc: sta...@vger.kernel.org
Signed-off-by: Shawn Lee 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_panel.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 8bc43205d6a0..be4b4d546fd9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2;
+   u32 pch_ctl1, pch_ctl2, schicken;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
@@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1);
}
 
+   if (HAS_PCH_LPT(dev_priv)) {
+   schicken = I915_READ(SOUTH_CHICKEN2);
+   if (panel->backlight.alternate_pwm_increment)
+   schicken |= LPT_PWM_GRANULARITY;
+   else
+   schicken &= ~LPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN2, schicken);
+   } else {
+   schicken = I915_READ(SOUTH_CHICKEN1);
+   if (panel->backlight.alternate_pwm_increment)
+   schicken |= SPT_PWM_GRANULARITY;
+   else
+   schicken &= ~SPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN1, schicken);
+   }
+
pch_ctl2 = panel->backlight.max << 16;
I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2);
 
-- 
2.1.4

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


[Intel-gfx] [PATCH 0/2] drm/i915: fix pwm increment setup

2016-09-19 Thread Jani Nikula
CI got confused by all the patches flowing in the earlier thread, so
resend. No changes.

BR,
Jani.

Jani Nikula (1):
  drm/i915/backlight: setup and cache pwm alternate increment value

Shawn Lee (1):
  drm/i915/backlight: setup backlight pwm alternate increment on
backlight enable

 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_panel.c | 32 
 2 files changed, 29 insertions(+), 4 deletions(-)

-- 
2.1.4

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


Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread kbuild test robot
Hi Shawn,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.8-rc7 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x008-201638 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/intel_drv.h:32:0,
from drivers/gpu/drm/i915/intel_panel.c:36:
   drivers/gpu/drm/i915/intel_panel.c: In function 'lpt_enable_backlight':
>> drivers/gpu/drm/i915/intel_panel.c:874:78: warning: left shift count >= 
>> width of type [-Wshift-count-overflow]
  I915_WRITE(SOUTH_CHICKEN2, mul | 
(panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));

 ^
   drivers/gpu/drm/i915/i915_drv.h:3735:83: note: in definition of macro 
'I915_WRITE'
#define I915_WRITE(reg, val) dev_priv->uncore.funcs.mmio_writel(dev_priv, 
(reg), (val), true)

  ^~~

vim +874 drivers/gpu/drm/i915/intel_panel.c

   858  pch_ctl1 |= BLM_PCH_POLARITY;
   859  
   860  /* After LPT, override is the default. */
   861  if (HAS_PCH_LPT(dev_priv))
   862  pch_ctl1 |= BLM_PCH_OVERRIDE_ENABLE;
   863  
   864  I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1);
   865  POSTING_READ(BLC_PWM_PCH_CTL1);
   866  I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1 | BLM_PCH_PWM_ENABLE);
   867  
   868  /* This won't stick until the above enable. */
   869  intel_panel_actually_set_backlight(connector, 
panel->backlight.level);
   870  
   871  if (HAS_PCH_LPT(dev_priv)) {
   872  mul = I915_READ(SOUTH_CHICKEN2);
   873  mul &= ~LPT_PWM_GRANULARITY;
 > 874  I915_WRITE(SOUTH_CHICKEN2, mul | 
 > (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));
   875  } else {
   876  mul = I915_READ(SOUTH_CHICKEN1);
   877  mul &= ~SPT_PWM_GRANULARITY;
   878  I915_WRITE(SOUTH_CHICKEN1, mul | 
(panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY));
   879  }
   880  }
   881  
   882  static void pch_enable_backlight(struct intel_connector *connector)

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


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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915 : Restore PWM_GRANULARITY after resume (rev3)

2016-09-19 Thread Patchwork
== Series Details ==

Series: drm/i915 : Restore PWM_GRANULARITY after resume (rev3)
URL   : https://patchwork.freedesktop.org/series/12165/
State : success

== Summary ==

Series 12165v3 drm/i915 : Restore PWM_GRANULARITY after resume
https://patchwork.freedesktop.org/api/1.0/series/12165/revisions/3/mbox/

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700k)

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-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   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_2552/

0d6fa72a8c18ec6ab4dbabf5202b8d1cad840e04 drm-intel-nightly: 
2016y-09m-19d-09h-28m-11s UTC integration manifest
887b9f7 drm/i915 : Restore PWM_GRANULARITY after resume

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


Re: [Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread Lee, Shawn C

Understood. Thanks!

-Original Message-
From: Nikula, Jani 
Sent: Monday, September 19, 2016 5:43 PM
To: Lee, Shawn C ; intel-gfx@lists.freedesktop.org
Cc: Lee, Shawn C 
Subject: Re: [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

On Mon, 19 Sep 2016, "Lee, Shawn C"  wrote:
> From: "Lee, Shawn C" 
>
> SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity 
> (minimum increment) of the PWM backlight control counter. PWM 
> frequency adjustment on 128 clock increments when this bit was 1. And 
> 16 clock increments when it was 0.
>
> PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to 
> SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save
> SOUTH_CHICKEN1 register value before suspend. And will restore it 
> after i915 resume.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486

Shawn, I already updated the patch. Perhaps I jumped the gun but I was 
expecting an update and didn't get one and wanted to move this forward.
That patch still has your authorship [1]. This one still has issues.

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1474273457-31680-2-git-send-email-jani.nik...@intel.com

>
> Cc: Jani Nikula 
> Reviewed-by: Cooper Chiou 
> Reviewed-by: Wei Shun Chen 
> Reviewed-by: Gary C Wang 
> Signed-off-by: Shawn Lee 
> ---
>  drivers/gpu/drm/i915/intel_drv.h   |1 +
>  drivers/gpu/drm/i915/intel_panel.c |   30 --
>  2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 570a7ca..c4bc690 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -256,6 +256,7 @@ struct intel_panel {
>   u32 level;
>   u32 min;
>   u32 max;
> + bool pwm_alternate_increment;
>   bool enabled;
>   bool combination_mode;  /* gen 2/4 only */
>   bool active_low_pwm;
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index c10e9b0..6f8469b 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct 
> intel_connector *connector)  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2;
> + u32 pch_ctl1, pch_ctl2, mul;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   if (pch_ctl1 & BLM_PCH_PWM_ENABLE) { @@ -867,6 +867,22 @@ static 
> void lpt_enable_backlight(struct intel_connector *connector)
>  
>   /* This won't stick until the above enable. */
>   intel_panel_actually_set_backlight(connector, 
> panel->backlight.level);
> + 
> + if (HAS_PCH_LPT(dev_priv)) {
> + mul = I915_READ(SOUTH_CHICKEN2);
> + if (panel->backlight.pwm_alternate_increment)
> + mul |= LPT_PWM_GRANULARITY;
> + else
> + mul &= ~LPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN2, mul);
> + } else {
> + mul = I915_READ(SOUTH_CHICKEN1);
> + if (panel->backlight.pwm_alternate_increment)
> + mul |= SPT_PWM_GRANULARITY;
> + else
> + mul &= ~SPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN1, mul);
> + }
>  }
>  
>  static void pch_enable_backlight(struct intel_connector *connector) 
> @@ -1413,7 +1429,7 @@ static int lpt_setup_backlight(struct 
> intel_connector *connector, enum pipe unus  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2, val;
> + u32 pch_ctl1, pch_ctl2, val, mul;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY; @@ 
> -1436,6 +1452,16 @@ static int lpt_setup_backlight(struct 
> intel_connector *connector, enum pipe unus
>  
>   panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
>  
> + if (HAS_PCH_LPT(dev_priv))
> + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> + else
> + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
> +
> + if ( mul )
> + panel->backlight.pwm_alternate_increment = true;
> + else
> + panel->backlight.pwm_alternate_increment = false;
> +
>   return 0;
>  }

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


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

2016-09-19 Thread Maarten Lankhorst
Op 14-09-16 om 14:36 schreef 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
>
Found it..

During the test run:
# cat /sys/kernel/debug/dri/0/i915_ddb_info 
  Start EndSize
Pipe A
  Plane1  0   0   0
  Plane2 30 890 860
  Cursor860 892  32

Pretty sure the start value here is bogus, and plane2 wm's end up overlapping 
with cursor.

~Maarten

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


Re: [Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, "Lee, Shawn C"  wrote:
> From: "Lee, Shawn C" 
>
> SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
> (minimum increment) of the PWM backlight control counter. PWM frequency
> adjustment on 128 clock increments when this bit was 1. And 16 clock
> increments when it was 0.
>
> PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to
> SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save
> SOUTH_CHICKEN1 register value before suspend. And will restore
> it after i915 resume.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486

Shawn, I already updated the patch. Perhaps I jumped the gun but I was
expecting an update and didn't get one and wanted to move this forward.
That patch still has your authorship [1]. This one still has issues.

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1474273457-31680-2-git-send-email-jani.nik...@intel.com

>
> Cc: Jani Nikula 
> Reviewed-by: Cooper Chiou 
> Reviewed-by: Wei Shun Chen 
> Reviewed-by: Gary C Wang 
> Signed-off-by: Shawn Lee 
> ---
>  drivers/gpu/drm/i915/intel_drv.h   |1 +
>  drivers/gpu/drm/i915/intel_panel.c |   30 --
>  2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 570a7ca..c4bc690 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -256,6 +256,7 @@ struct intel_panel {
>   u32 level;
>   u32 min;
>   u32 max;
> + bool pwm_alternate_increment;
>   bool enabled;
>   bool combination_mode;  /* gen 2/4 only */
>   bool active_low_pwm;
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index c10e9b0..6f8469b 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
> *connector)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2;
> + u32 pch_ctl1, pch_ctl2, mul;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
> @@ -867,6 +867,22 @@ static void lpt_enable_backlight(struct intel_connector 
> *connector)
>  
>   /* This won't stick until the above enable. */
>   intel_panel_actually_set_backlight(connector, panel->backlight.level);
> + 
> + if (HAS_PCH_LPT(dev_priv)) {
> + mul = I915_READ(SOUTH_CHICKEN2);
> + if (panel->backlight.pwm_alternate_increment)
> + mul |= LPT_PWM_GRANULARITY;
> + else
> + mul &= ~LPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN2, mul);
> + } else {
> + mul = I915_READ(SOUTH_CHICKEN1);
> + if (panel->backlight.pwm_alternate_increment)
> + mul |= SPT_PWM_GRANULARITY;
> + else
> + mul &= ~SPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN1, mul);
> + }
>  }
>  
>  static void pch_enable_backlight(struct intel_connector *connector)
> @@ -1413,7 +1429,7 @@ static int lpt_setup_backlight(struct intel_connector 
> *connector, enum pipe unus
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2, val;
> + u32 pch_ctl1, pch_ctl2, val, mul;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
> @@ -1436,6 +1452,16 @@ static int lpt_setup_backlight(struct intel_connector 
> *connector, enum pipe unus
>  
>   panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
>  
> + if (HAS_PCH_LPT(dev_priv))
> + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> + else
> + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
> +
> + if ( mul )
> + panel->backlight.pwm_alternate_increment = true;
> + else
> + panel->backlight.pwm_alternate_increment = false;
> +
>   return 0;
>  }

-- 
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] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread Lee, Shawn C
From: "Lee, Shawn C" 

SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
(minimum increment) of the PWM backlight control counter. PWM frequency
adjustment on 128 clock increments when this bit was 1. And 16 clock
increments when it was 0.

PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to
SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save
SOUTH_CHICKEN1 register value before suspend. And will restore
it after i915 resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486

Cc: Jani Nikula 
Reviewed-by: Cooper Chiou 
Reviewed-by: Wei Shun Chen 
Reviewed-by: Gary C Wang 
Signed-off-by: Shawn Lee 
---
 drivers/gpu/drm/i915/intel_drv.h   |1 +
 drivers/gpu/drm/i915/intel_panel.c |   30 --
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 570a7ca..c4bc690 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -256,6 +256,7 @@ struct intel_panel {
u32 level;
u32 min;
u32 max;
+   bool pwm_alternate_increment;
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c10e9b0..6f8469b 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2;
+   u32 pch_ctl1, pch_ctl2, mul;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
@@ -867,6 +867,22 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
 
/* This won't stick until the above enable. */
intel_panel_actually_set_backlight(connector, panel->backlight.level);
+   
+   if (HAS_PCH_LPT(dev_priv)) {
+   mul = I915_READ(SOUTH_CHICKEN2);
+   if (panel->backlight.pwm_alternate_increment)
+   mul |= LPT_PWM_GRANULARITY;
+   else
+   mul &= ~LPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN2, mul);
+   } else {
+   mul = I915_READ(SOUTH_CHICKEN1);
+   if (panel->backlight.pwm_alternate_increment)
+   mul |= SPT_PWM_GRANULARITY;
+   else
+   mul &= ~SPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN1, mul);
+   }
 }
 
 static void pch_enable_backlight(struct intel_connector *connector)
@@ -1413,7 +1429,7 @@ static int lpt_setup_backlight(struct intel_connector 
*connector, enum pipe unus
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2, val;
+   u32 pch_ctl1, pch_ctl2, val, mul;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
@@ -1436,6 +1452,16 @@ static int lpt_setup_backlight(struct intel_connector 
*connector, enum pipe unus
 
panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
 
+   if (HAS_PCH_LPT(dev_priv))
+   mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
+   else
+   mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
+
+   if ( mul )
+   panel->backlight.pwm_alternate_increment = true;
+   else
+   panel->backlight.pwm_alternate_increment = false;
+
return 0;
 }
 
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, "Lee, Shawn C"  wrote:
> PWM was enabled in bios. i915 driver will save max duty to 
> panel->backlight.max.
> So *_hz_to_pwm will not be called if backlight.max not zero. 

And what difference does it make?

BR,
Jani.

>
>   pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2);
>   panel->backlight.max = pch_ctl2 >> 16;
>
>   if (!panel->backlight.max)
>   panel->backlight.max = get_backlight_max_vbt(connector);
>
> -Original Message-
> From: Nikula, Jani 
> Sent: Monday, September 19, 2016 4:24 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Lee, Shawn C 
> Subject: [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate 
> increment value
>
> This will also be needed later on when setting up the alternate increment in 
> backlight enable.
>
> Cc: Shawn Lee 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_panel.c | 14 +++---
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8fd16adf069b..c3e65e515c9d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -263,6 +263,7 @@ struct intel_panel {
>   bool enabled;
>   bool combination_mode;  /* gen 2/4 only */
>   bool active_low_pwm;
> + bool alternate_pwm_increment;   /* lpt+ */
>  
>   /* PWM chip */
>   bool util_pin_active_low;   /* bxt+ */
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index c10e9b0405e8..8bc43205d6a0 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector 
> *connector, u32 pwm_freq_hz)
>   */
>  static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz) 
>  {
> - struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_panel *panel = >panel;
>   u32 mul;
>  
> - if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY)
> + if (panel->backlight.alternate_pwm_increment)
>   mul = 128;
>   else
>   mul = 16;
> @@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector 
> *connector, u32 pwm_freq_hz)  static u32 lpt_hz_to_pwm(struct intel_connector 
> *connector, u32 pwm_freq_hz)  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_panel *panel = >panel;
>   u32 mul, clock;
>  
> - if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY)
> + if (panel->backlight.alternate_pwm_increment)
>   mul = 16;
>   else
>   mul = 128;
> @@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector 
> *connector, enum pipe unus
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
>   u32 pch_ctl1, pch_ctl2, val;
> + bool alt;
> +
> + if (HAS_PCH_LPT(dev_priv))
> + alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> + else
> + alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
> + panel->backlight.alternate_pwm_increment = alt;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
> --
> 2.1.4
>

-- 
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 v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

2016-09-19 Thread Lee, Shawn C
PWM was enabled in bios. i915 driver will save max duty to panel->backlight.max.
So *_hz_to_pwm will not be called if backlight.max not zero. 

pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2);
panel->backlight.max = pch_ctl2 >> 16;

if (!panel->backlight.max)
panel->backlight.max = get_backlight_max_vbt(connector);

-Original Message-
From: Nikula, Jani 
Sent: Monday, September 19, 2016 4:24 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani ; Lee, Shawn C 
Subject: [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate 
increment value

This will also be needed later on when setting up the alternate increment in 
backlight enable.

Cc: Shawn Lee 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_panel.c | 14 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fd16adf069b..c3e65e515c9d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -263,6 +263,7 @@ struct intel_panel {
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
+   bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
bool util_pin_active_low;   /* bxt+ */
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c10e9b0405e8..8bc43205d6a0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
  */
 static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)  {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
u32 mul;
 
-   if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY)
+   if (panel->backlight.alternate_pwm_increment)
mul = 128;
else
mul = 16;
@@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)  static u32 lpt_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)  {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
u32 mul, clock;
 
-   if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY)
+   if (panel->backlight.alternate_pwm_increment)
mul = 16;
else
mul = 128;
@@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector 
*connector, enum pipe unus
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
u32 pch_ctl1, pch_ctl2, val;
+   bool alt;
+
+   if (HAS_PCH_LPT(dev_priv))
+   alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
+   else
+   alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
+   panel->backlight.alternate_pwm_increment = alt;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
--
2.1.4

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


[Intel-gfx] [PULL] drm-intel-next

2016-09-19 Thread Daniel Vetter
Hi Dave,

drm-intel-next-2016-09-19:
- refactor the sseu code (Imre)
- refine guc dmesg output (Dave Gordon)
- more vgpu work
- more skl wm fixes (Lyude)
- refactor dpll code in prep for upfront link training (Jim Bride et al)
- consolidate all platform feature checks into intel_device_info (Carlos Santa)
- refactor elsp/execlist submission as prep for re-submission after hang
  recovery and eventually scheduling (Chris Wilson)
- allow synchronous gpu reset handling, to remove tricky/impossible/fragile
  error recovery code (Chris Wilson)
- prep work for nonblocking (execlist) submission, using fences to track
  depencies and drive elsp submission (Chris Wilson)
- partial error recover/resubmission of non-guilty batches after hangs (Chris 
Wilson)
- full dma-buf implicit fencing support (Chris Wilson)
- dp link training fixes (Jim, Dhinkaran, Navare, ...)
- obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for
  many vga dongles
- bunch of small cleanups and polish all over, as usual
drm-intel-next-2016-09-02:
- skl wm fixes (Lyude, Matt, Maarten)
- cleanup of kdev/drm_dev/i915_dev handling (David Weinehall)
- make (most) encoders take advantage of atomic states (Maarten)
- MMAP_GTT_VERSION driver param to announce that gtt mmaps are reliable (Chris)
- allow contexts on all rings (Chris)
- a few fixes (around diagnostic messages) to make BAT less noisy
- misc fixes and cleanups all over, as usual

Since you're on vacation I figured I'll just combine the pull from before
my vacations, and the final 4.9 feature pile I just assembled. With this
4.9 is now for Jani.

Tomeu just pinged me about the crc drm patches, and David made some noises
about cleanup patches he has pending, so I guess there'll be a few
stragglers for 4.9 for -misc still. But if Linus tags final 4.8 (against
excpectations) this w/e already I'll postpone them I think.

Cheers, Daniel


The following changes since commit d5d0804f8f6d0c89913f6a2de5348adef8ec33e4:

  drm/i915: Update DRIVER_DATE to 20160822 (2016-08-22 08:35:48 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-09-19

for you to fetch changes up to 6e05f3d3b9298a56d6f1acb474a75cf14a17c31e:

  drm/i915: Update DRIVER_DATE to 20160919 (2016-09-19 09:26:08 +0200)


- refactor the sseu code (Imre)
- refine guc dmesg output (Dave Gordon)
- more vgpu work
- more skl wm fixes (Lyude)
- refactor dpll code in prep for upfront link training (Jim Bride et al)
- consolidate all platform feature checks into intel_device_info (Carlos Santa)
- refactor elsp/execlist submission as prep for re-submission after hang
  recovery and eventually scheduling (Chris Wilson)
- allow synchronous gpu reset handling, to remove tricky/impossible/fragile
  error recovery code (Chris Wilson)
- prep work for nonblocking (execlist) submission, using fences to track
  depencies and drive elsp submission (Chris Wilson)
- partial error recover/resubmission of non-guilty batches after hangs (Chris 
Wilson)
- full dma-buf implicit fencing support (Chris Wilson)
- dp link training fixes (Jim, Dhinkaran, Navare, ...)
- obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for
  many vga dongles
- bunch of small cleanups and polish all over, as usual


Ander Conselvan de Oliveira (2):
  drm/i915: Don't pass crtc_state to intel_dp_set_link_params()
  drm/i915: Remove ddi_pll_sel from intel_crtc_state

Carlos Santa (22):
  drm/i915: Move HAS_PSR definition to platform struct definition
  drm/i915: Remove .is_mobile field from platform struct
  drm/i915: Introduce GEN6_FEATURES for device info
  drm/i915: Move HAS_RUNTIME_PM definition to platform
  drm/i915: Remove runtime PM for SNB
  drm/i915: Get rid of HAS_CORE_RING_FREQ
  drm/i915 Move HAS_CSR definition to platform definition
  drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition
  drm/i915: Move HAS_RC6 definition to platform definition
  drm/i915: Move HAS_RC6p definition to platform definition
  drm/i915: Move HAS_DP_MST definition to platform definition
  drm/i915: Introduce GEN5_FEATURES for device info
  drm/i915: Move HAS_GMBUS_IRQ definition to platform definition
  drm/i915: Introduce GEN4_FEATURES for device info
  drm/i915: Introduce GEN3_FEATURES for device info
  drm/i915: Introduce GEN2_FEATURES for device info
  drm/i915: Move HAS_HW_CONTEXTS definition to platform
  drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform
  drm/i915: Move HAS_L3_DPF definition to platform definition
  drm/i915: Move HAS_GMCH_DISPLAY definition to platform
  drm/i915: Make HWS_NEEDS_PHYSICAL the exception
  drm/i915: Move HAS_GUC definition to platform definition

Chris Wilson (46):
  drm/i915: Restore debugfs

[Intel-gfx] Updated drm-intel-testing

2016-09-19 Thread Daniel Vetter
Hi all,

New -testing cycle with cool stuff:
- refactor the sseu code (Imre)
- refine guc dmesg output (Dave Gordon)
- more vgpu work
- more skl wm fixes (Lyude)
- refactor dpll code in prep for upfront link training (Jim Bride et al)
- consolidate all platform feature checks into intel_device_info (Carlos Santa)
- refactor elsp/execlist submission as prep for re-submission after hang
  recovery and eventually scheduling (Chris Wilson)
- allow synchronous gpu reset handling, to remove tricky/impossible/fragile
  error recovery code (Chris Wilson)
- prep work for nonblocking (execlist) submission, using fences to track
  depencies and drive elsp submission (Chris Wilson)
- partial error recover/resubmission of non-guilty batches after hangs (Chris 
Wilson)
- full dma-buf implicit fencing support (Chris Wilson)
- dp link training fixes (Jim, Dhinkaran, Navare, ...)
- obey dp branch device pixel rate/bpc/clock limits (Mika Kahola), needed for
  many vga dongles
- bunch of small cleanups and polish all over, as usual

Happy testing!

Cheers, Daniel

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


Re: [Intel-gfx] [PATCH 09/18] drm/i915: Wait first for submission, before waiting for request completion

2016-09-19 Thread Joonas Lahtinen
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +static long
> +__i915_request_wait_for_submit(struct drm_i915_gem_request *request,
> +    unsigned int flags,
> +    long timeout)
> +{
> + const int state = flags & I915_WAIT_INTERRUPTIBLE ?
> + TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;

const bool wait_locked = flags & I915_WAIT_LOCKED;

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 v2] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, "Lee, Shawn C"  wrote:
> + if (HAS_PCH_LPT(dev_priv)) {
> + mul = I915_READ(SOUTH_CHICKEN2);
> + mul &= ~LPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN2, mul | 
> (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));
> + } else {
> + mul = I915_READ(SOUTH_CHICKEN1);
> + mul &= ~SPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN1, mul | 
> (panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY));
> + }

Also, both of the shifts are wrong here. The *_PWM_GRANULARITY macros
already contain the shifts.

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 1/2] drm/i915: Only shrink the unbound objects during freeze

2016-09-19 Thread Chris Wilson
On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote:
> On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
> >  int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
> >  {
> > >   struct drm_i915_gem_object *obj;
> > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private 
> > *dev_priv)
> > >    * the objects as well.
> > >    */
> >  
> > > - i915_gem_shrink_all(dev_priv);
> > +   mutex_lock(_priv->drm.struct_mutex);
> 
> Previously the shrinking here was without a mutex. And the new
> shrinking during _freeze is also mutex protected, any specific reason?

Silencing lockdep. We know we are single threaded here, but lockdep
doesn't. This version of i915_gem_shrink() doesn't automagically take
the struct_mutex (later versions do).
-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 v2] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, "Lee, Shawn C"  wrote:
> From: "Lee, Shawn C" 
>
> SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
> (minimum increment) of the PWM backlight control counter. PWM frequency
> adjustment on 128 clock increments when this bit was 1. And 16 clock
> increments when it was 0.
>
> PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to
> SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save
> SOUTH_CHICKEN1 register value before suspend. And will restore
> it after i915 resume.

Sorry, I updated the patch already

https://patchwork.freedesktop.org/patch/28/
https://patchwork.freedesktop.org/patch/29/

BR,
Jani.

>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
>
> Cc: Jani Nikula 
> Reviewed-by: Cooper Chiou 
> Reviewed-by: Wei Shun Chen 
> Reviewed-by: Gary C Wang 
> Signed-off-by: Shawn Lee 
> ---
>  drivers/gpu/drm/i915/intel_drv.h   |1 +
>  drivers/gpu/drm/i915/intel_panel.c |   24 ++--
>  2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 570a7ca..c4bc690 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -256,6 +256,7 @@ struct intel_panel {
>   u32 level;
>   u32 min;
>   u32 max;
> + bool pwm_alternate_increment;
>   bool enabled;
>   bool combination_mode;  /* gen 2/4 only */
>   bool active_low_pwm;
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index c10e9b0..e1dc6bd 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
> *connector)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2;
> + u32 pch_ctl1, pch_ctl2, mul;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
> @@ -867,6 +867,16 @@ static void lpt_enable_backlight(struct intel_connector 
> *connector)
>  
>   /* This won't stick until the above enable. */
>   intel_panel_actually_set_backlight(connector, panel->backlight.level);
> +
> + if (HAS_PCH_LPT(dev_priv)) {
> + mul = I915_READ(SOUTH_CHICKEN2);
> + mul &= ~LPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN2, mul | 
> (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));
> + } else {
> + mul = I915_READ(SOUTH_CHICKEN1);
> + mul &= ~SPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN1, mul | 
> (panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY));
> + }
>  }
>  
>  static void pch_enable_backlight(struct intel_connector *connector)
> @@ -1413,7 +1423,7 @@ static int lpt_setup_backlight(struct intel_connector 
> *connector, enum pipe unus
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2, val;
> + u32 pch_ctl1, pch_ctl2, val, mul;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
> @@ -1436,6 +1446,16 @@ static int lpt_setup_backlight(struct intel_connector 
> *connector, enum pipe unus
>  
>   panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
>  
> + if (HAS_PCH_LPT(dev_priv))
> + mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> + else
> + mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
> +
> + if ( mul )
> + panel->backlight.pwm_alternate_increment = true;
> + else
> + panel->backlight.pwm_alternate_increment = false;
> +
>   return 0;
>  }

-- 
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 v2 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, Jani Nikula  wrote:
> From: Shawn Lee 
>
> Backlight enable is supposed to do a full setup of the backlight. We
> were missing the PWM alternate increment bit in the south chicken
> registers on lpt+ pch. This potentially caused a PWM frequency change
> when the chicken register value was lost e.g. on suspend.
>
> v2 by Jani, rebase on the patch caching alt increment
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486

There's a good chance this'll also fix a bug long ago deemed
NOTOURBUG...

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67454

> Cc: Cooper Chiou 
> Cc: Wei Shun Chen 
> Cc: Gary C Wang 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Shawn Lee 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index 8bc43205d6a0..be4b4d546fd9 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
> *connector)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2;
> + u32 pch_ctl1, pch_ctl2, schicken;
>  
>   pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
>   if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
> @@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector 
> *connector)
>   I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1);
>   }
>  
> + if (HAS_PCH_LPT(dev_priv)) {
> + schicken = I915_READ(SOUTH_CHICKEN2);
> + if (panel->backlight.alternate_pwm_increment)
> + schicken |= LPT_PWM_GRANULARITY;
> + else
> + schicken &= ~LPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN2, schicken);
> + } else {
> + schicken = I915_READ(SOUTH_CHICKEN1);
> + if (panel->backlight.alternate_pwm_increment)
> + schicken |= SPT_PWM_GRANULARITY;
> + else
> + schicken &= ~SPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN1, schicken);
> + }
> +
>   pch_ctl2 = panel->backlight.max << 16;
>   I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2);

-- 
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] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

2016-09-19 Thread Lee, Shawn C
From: "Lee, Shawn C" 

SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
(minimum increment) of the PWM backlight control counter. PWM frequency
adjustment on 128 clock increments when this bit was 1. And 16 clock
increments when it was 0.

PWM frequency multiple octuple (from 200Hz to 1.6KHz) due to
SPT_PWM_GRANULARITY was clear to 0 after S3. This patch save
SOUTH_CHICKEN1 register value before suspend. And will restore
it after i915 resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486

Cc: Jani Nikula 
Reviewed-by: Cooper Chiou 
Reviewed-by: Wei Shun Chen 
Reviewed-by: Gary C Wang 
Signed-off-by: Shawn Lee 
---
 drivers/gpu/drm/i915/intel_drv.h   |1 +
 drivers/gpu/drm/i915/intel_panel.c |   24 ++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 570a7ca..c4bc690 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -256,6 +256,7 @@ struct intel_panel {
u32 level;
u32 min;
u32 max;
+   bool pwm_alternate_increment;
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c10e9b0..e1dc6bd 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2;
+   u32 pch_ctl1, pch_ctl2, mul;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
@@ -867,6 +867,16 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
 
/* This won't stick until the above enable. */
intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+   if (HAS_PCH_LPT(dev_priv)) {
+   mul = I915_READ(SOUTH_CHICKEN2);
+   mul &= ~LPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN2, mul | 
(panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));
+   } else {
+   mul = I915_READ(SOUTH_CHICKEN1);
+   mul &= ~SPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN1, mul | 
(panel->backlight.pwm_alternate_increment << SPT_PWM_GRANULARITY));
+   }
 }
 
 static void pch_enable_backlight(struct intel_connector *connector)
@@ -1413,7 +1423,7 @@ static int lpt_setup_backlight(struct intel_connector 
*connector, enum pipe unus
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2, val;
+   u32 pch_ctl1, pch_ctl2, val, mul;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
@@ -1436,6 +1446,16 @@ static int lpt_setup_backlight(struct intel_connector 
*connector, enum pipe unus
 
panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
 
+   if (HAS_PCH_LPT(dev_priv))
+   mul = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
+   else
+   mul = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
+
+   if ( mul )
+   panel->backlight.pwm_alternate_increment = true;
+   else
+   panel->backlight.pwm_alternate_increment = false;
+
return 0;
 }
 
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze

2016-09-19 Thread Joonas Lahtinen
On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
>  int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
>  {
> >     struct drm_i915_gem_object *obj;
> @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private 
> *dev_priv)
> >      * the objects as well.
> >      */
>  
> > -   i915_gem_shrink_all(dev_priv);
> + mutex_lock(_priv->drm.struct_mutex);

Previously the shrinking here was without a mutex. And the new
shrinking during _freeze is also mutex protected, any specific reason?

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 v4] drm/i915/skl: New ddb allocation algorithm

2016-09-19 Thread Maarten Lankhorst
Hey,

Op 14-09-16 om 14:36 schreef 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. 

kms_cursor_legacy.cursorA-vs-flipA-atomic-transitions-varying-size is broken by 
this patch.

It's easy to overlook, since cursorA-vs-flipB of the same test was already 
broken,
but this is definitely something new introduced by this patch.

~Maarten

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915/execlists: Reset RING registers upon resume

2016-09-19 Thread Joonas Lahtinen
On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
>  void intel_lr_context_resume(struct drm_i915_private *dev_priv)
>  {
> > -   struct i915_gem_context *ctx = dev_priv->kernel_context;
> >     struct intel_engine_cs *engine;
> > +   struct i915_gem_context *ctx;
> +
> > +   /* Because we emit WA_TAIL_DWORDS there may be a disparity
> > +    * between our bookkeeping in ce->ring->head and ce->ring->tail and
> +  * that stored in context. As we only write new comamnds from

"new commands"

> +  * ce->ring->tail onwards, everything before that is junk. If the GPU
> > +    * starts reading from its RING_HEAD from the context, it may try to
> > +    * execute that junk and die.
> > +    *
> > +    * So to avoid that we reset the context images upon resume. For
> > +    * simplicity, we just zero everything out.
> > +    */
> > +   list_for_each_entry(ctx, _priv->context_list, link) {
> > +   for_each_engine(engine, dev_priv) {
> > +   struct intel_context *ce = >engine[engine->id];
> > +   u32 *reg_state;
>  
> > -   for_each_engine(engine, dev_priv) {
> > -   struct intel_context *ce = >engine[engine->id];
> > -   void *vaddr;
> > -   uint32_t *reg_state;
> -
> > -   if (!ce->state)
> > -   continue;
> -
> > -   vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
> > -   if (WARN_ON(IS_ERR(vaddr)))
> > -   continue;
> > +   if (!ce->state)
> > +   continue;
>  
> > -   reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
> > +   reg_state = i915_gem_object_pin_map(ce->state->obj,
> > +   I915_MAP_WB);
> > +   if (WARN_ON(IS_ERR(reg_state)))
> > +   continue;
>  
> > -   reg_state[CTX_RING_HEAD+1] = 0;
> > -   reg_state[CTX_RING_TAIL+1] = 0;
> + reg_state += LRC_STATE_PN * PAGE_SIZE / sizeof(u32);

/ sizeof(*reg_state) I presume.

Also add a newline here.

With those;

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] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, Jani Nikula  wrote:
> From: Shawn Lee 
>
> Backlight enable is supposed to do a full setup of the backlight. We
> were missing the PWM alternate increment bit in the south chicken
> registers on lpt+ pch. This potentially caused a PWM frequency change
> when the chicken register value was lost e.g. on suspend.
>
> v2 by Jani, rebase on the patch caching alt increment

Fat fingered this one, please ignore, and look at the two patches in
reply to this one. Sorry.

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] [PATCH v2 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

2016-09-19 Thread Jani Nikula
From: Shawn Lee 

Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.

v2 by Jani, rebase on the patch caching alt increment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
Cc: Cooper Chiou 
Cc: Wei Shun Chen 
Cc: Gary C Wang 
Cc: sta...@vger.kernel.org
Signed-off-by: Shawn Lee 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_panel.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 8bc43205d6a0..be4b4d546fd9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2;
+   u32 pch_ctl1, pch_ctl2, schicken;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
@@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1);
}
 
+   if (HAS_PCH_LPT(dev_priv)) {
+   schicken = I915_READ(SOUTH_CHICKEN2);
+   if (panel->backlight.alternate_pwm_increment)
+   schicken |= LPT_PWM_GRANULARITY;
+   else
+   schicken &= ~LPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN2, schicken);
+   } else {
+   schicken = I915_READ(SOUTH_CHICKEN1);
+   if (panel->backlight.alternate_pwm_increment)
+   schicken |= SPT_PWM_GRANULARITY;
+   else
+   schicken &= ~SPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN1, schicken);
+   }
+
pch_ctl2 = panel->backlight.max << 16;
I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2);
 
-- 
2.1.4

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


[Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

2016-09-19 Thread Jani Nikula
This will also be needed later on when setting up the alternate
increment in backlight enable.

Cc: Shawn Lee 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_panel.c | 14 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fd16adf069b..c3e65e515c9d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -263,6 +263,7 @@ struct intel_panel {
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
+   bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
bool util_pin_active_low;   /* bxt+ */
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c10e9b0405e8..8bc43205d6a0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1242,10 +1242,10 @@ static u32 bxt_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
  */
 static u32 spt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
 {
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
u32 mul;
 
-   if (I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY)
+   if (panel->backlight.alternate_pwm_increment)
mul = 128;
else
mul = 16;
@@ -1261,9 +1261,10 @@ static u32 spt_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
 static u32 lpt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
u32 mul, clock;
 
-   if (I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY)
+   if (panel->backlight.alternate_pwm_increment)
mul = 16;
else
mul = 128;
@@ -1414,6 +1415,13 @@ static int lpt_setup_backlight(struct intel_connector 
*connector, enum pipe unus
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
u32 pch_ctl1, pch_ctl2, val;
+   bool alt;
+
+   if (HAS_PCH_LPT(dev_priv))
+   alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
+   else
+   alt = I915_READ(SOUTH_CHICKEN1) & SPT_PWM_GRANULARITY;
+   panel->backlight.alternate_pwm_increment = alt;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
-- 
2.1.4

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


[Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

2016-09-19 Thread Jani Nikula
From: Shawn Lee 

Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.

v2 by Jani, rebase on the patch caching alt increment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
Cc: Cooper Chiou 
Cc: Wei Shun Chen 
Cc: Gary C Wang 
Cc: sta...@vger.kernel.org
Signed-off-by: Shawn Lee 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_panel.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 8bc43205d6a0..be4b4d546fd9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -841,7 +841,7 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2;
+   u32 pch_ctl1, pch_ctl2, schicken;
 
pch_ctl1 = I915_READ(BLC_PWM_PCH_CTL1);
if (pch_ctl1 & BLM_PCH_PWM_ENABLE) {
@@ -850,6 +850,22 @@ static void lpt_enable_backlight(struct intel_connector 
*connector)
I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1);
}
 
+   if (HAS_PCH_LPT(dev_priv)) {
+   schicken = I915_READ(SOUTH_CHICKEN2);
+   if (panel->backlight.alternate_pwm_increment)
+   schicken |= LPT_PWM_GRANULARITY;
+   else
+   schicken &= ~LPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN2, schicken);
+   } else {
+   schicken = I915_READ(SOUTH_CHICKEN1);
+   if (panel->backlight.alternate_pwm_increment)
+   schicken |= SPT_PWM_GRANULARITY;
+   else
+   schicken &= ~SPT_PWM_GRANULARITY;
+   I915_WRITE(SOUTH_CHICKEN1, schicken);
+   }
+
pch_ctl2 = panel->backlight.max << 16;
I915_WRITE(BLC_PWM_PCH_CTL2, pch_ctl2);
 
-- 
2.1.4

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


Re: [Intel-gfx] [PATCH 1/5] drm/i915/skl: drop workarounds for A0 and B0 revisions

2016-09-19 Thread Jani Nikula
On Mon, 19 Sep 2016, Mika Kahola  wrote:
> On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote:
>> Pre-production hardware is not supported.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c   |  4 
>>  drivers/gpu/drm/i915/intel_dp_link_training.c |  3 ---
>>  drivers/gpu/drm/i915/intel_guc_loader.c   |  5 ++---
>>  drivers/gpu/drm/i915/intel_lrc.c  |  8 +++-
>>  drivers/gpu/drm/i915/intel_ringbuffer.c   | 21 ++---
>> 
>>  5 files changed, 11 insertions(+), 30 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index acd0c51f74d5..b2a9eb82ac4b 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1299,10 +1299,6 @@ bool intel_dp_source_supports_hbr2(struct
>> intel_dp *intel_dp)
>>  struct intel_digital_port *dig_port =
>> dp_to_dig_port(intel_dp);
>>  struct drm_device *dev = dig_port->base.base.dev;
>>  
>> -/* WaDisableHBR2:skl */
>> -if (IS_SKL_REVID(dev, 0, SKL_REVID_B0))
>> -return false;
>> -
>>  if ((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) ||
>> IS_BROADWELL(dev) ||
>>  (INTEL_INFO(dev)->gen >= 9))
>>  return true;
>> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
>> b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> index c438b02184cb..0048b520baf7 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> @@ -225,9 +225,6 @@ static u32 intel_dp_training_pattern(struct
>> intel_dp *intel_dp)
>>   * Intel platforms that support HBR2 also support TPS3. TPS3
>> support is
>>   * also mandatory for downstream devices that support HBR2.
>> However, not
>>   * all sinks follow the spec.
>> - *
>> - * Due to WaDisableHBR2 SKL < B0 is the only exception where
>> TPS3 is
>> - * supported in source but still not enabled.
>>   */
>>  source_tps3 = intel_dp_source_supports_hbr2(intel_dp);
>>  sink_tps3 = drm_dp_tps3_supported(intel_dp->dpcd);
>> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
>> b/drivers/gpu/drm/i915/intel_guc_loader.c
>> index 6fd39efb7894..acc1dbdd024e 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
>> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
>> @@ -375,9 +375,8 @@ static int guc_ucode_xfer(struct drm_i915_private
>> *dev_priv)
>>  /* Enable MIA caching. GuC clock gating is disabled. */
>>  I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE);
>>  
>> -/* WaDisableMinuteIaClockGating:skl,bxt */
>> -if (IS_SKL_REVID(dev, 0, SKL_REVID_B0) ||
>> -IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
>> +/* WaDisableMinuteIaClockGating:bxt */
>> +if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
>>  I915_WRITE(GUC_SHIM_CONTROL,
>> (I915_READ(GUC_SHIM_CONTROL) &
>>    ~GUC_ENABLE_MIA_CLOCK_
>> GATING));
>>  }
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> b/drivers/gpu/drm/i915/intel_lrc.c
>> index 251143361f31..4bfa3c015e25 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -269,8 +269,7 @@ logical_ring_init_platform_invariants(struct
>> intel_engine_cs *engine)
>>  struct drm_i915_private *dev_priv = engine->i915;
>>  
>>  engine->disable_lite_restore_wa =
>> -(IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0) ||
>> - IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) &&
>> +IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) &&
>>  (engine->id == VCS || engine->id == VCS2);
>>  
>>  engine->ctx_desc_template = GEN8_CTX_VALID;
>> @@ -1068,9 +1067,8 @@ static int gen9_init_perctx_bb(struct
>> intel_engine_cs *engine,
>>  {
>>  uint32_t index = wa_ctx_start(wa_ctx, *offset,
>> CACHELINE_DWORDS);
>>  
>> -/*
>> WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
>> -if (IS_SKL_REVID(engine->i915, 0, SKL_REVID_B0) ||
>> -IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) {
>> +/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:bxt
>> */
>> +if (IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) {
>>  wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
>>  wa_ctx_emit_reg(batch, index,
>> GEN9_SLICE_COMMON_ECO_CHICKEN0);
>>  wa_ctx_emit(batch, index,
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 7a74750076c5..2faf64f9f256 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -851,15 +851,13 @@ static int gen9_init_workarounds(struct
>> intel_engine_cs *engine)
>>  WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
>>    GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
>>  
>> -/* WaDisableDgMirrorFixInHalfSliceChicken5:skl,bxt */
>> -if (IS_SKL_REVID(dev_priv, 0, 

Re: [Intel-gfx] [PATCH 1/5] drm/i915/skl: drop workarounds for A0 and B0 revisions

2016-09-19 Thread Mika Kahola
On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote:
> Pre-production hardware is not supported.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   |  4 
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  3 ---
>  drivers/gpu/drm/i915/intel_guc_loader.c   |  5 ++---
>  drivers/gpu/drm/i915/intel_lrc.c  |  8 +++-
>  drivers/gpu/drm/i915/intel_ringbuffer.c   | 21 ++---
> 
>  5 files changed, 11 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index acd0c51f74d5..b2a9eb82ac4b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1299,10 +1299,6 @@ bool intel_dp_source_supports_hbr2(struct
> intel_dp *intel_dp)
>   struct intel_digital_port *dig_port =
> dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
>  
> - /* WaDisableHBR2:skl */
> - if (IS_SKL_REVID(dev, 0, SKL_REVID_B0))
> - return false;
> -
>   if ((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) ||
> IS_BROADWELL(dev) ||
>   (INTEL_INFO(dev)->gen >= 9))
>   return true;
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index c438b02184cb..0048b520baf7 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -225,9 +225,6 @@ static u32 intel_dp_training_pattern(struct
> intel_dp *intel_dp)
>    * Intel platforms that support HBR2 also support TPS3. TPS3
> support is
>    * also mandatory for downstream devices that support HBR2.
> However, not
>    * all sinks follow the spec.
> -  *
> -  * Due to WaDisableHBR2 SKL < B0 is the only exception where
> TPS3 is
> -  * supported in source but still not enabled.
>    */
>   source_tps3 = intel_dp_source_supports_hbr2(intel_dp);
>   sink_tps3 = drm_dp_tps3_supported(intel_dp->dpcd);
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 6fd39efb7894..acc1dbdd024e 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -375,9 +375,8 @@ static int guc_ucode_xfer(struct drm_i915_private
> *dev_priv)
>   /* Enable MIA caching. GuC clock gating is disabled. */
>   I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE);
>  
> - /* WaDisableMinuteIaClockGating:skl,bxt */
> - if (IS_SKL_REVID(dev, 0, SKL_REVID_B0) ||
> - IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
> + /* WaDisableMinuteIaClockGating:bxt */
> + if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
>   I915_WRITE(GUC_SHIM_CONTROL,
> (I915_READ(GUC_SHIM_CONTROL) &
>     ~GUC_ENABLE_MIA_CLOCK_
> GATING));
>   }
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 251143361f31..4bfa3c015e25 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -269,8 +269,7 @@ logical_ring_init_platform_invariants(struct
> intel_engine_cs *engine)
>   struct drm_i915_private *dev_priv = engine->i915;
>  
>   engine->disable_lite_restore_wa =
> - (IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0) ||
> -  IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) &&
> + IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) &&
>   (engine->id == VCS || engine->id == VCS2);
>  
>   engine->ctx_desc_template = GEN8_CTX_VALID;
> @@ -1068,9 +1067,8 @@ static int gen9_init_perctx_bb(struct
> intel_engine_cs *engine,
>  {
>   uint32_t index = wa_ctx_start(wa_ctx, *offset,
> CACHELINE_DWORDS);
>  
> - /*
> WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
> - if (IS_SKL_REVID(engine->i915, 0, SKL_REVID_B0) ||
> - IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) {
> + /* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:bxt
> */
> + if (IS_BXT_REVID(engine->i915, 0, BXT_REVID_A1)) {
>   wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
>   wa_ctx_emit_reg(batch, index,
> GEN9_SLICE_COMMON_ECO_CHICKEN0);
>   wa_ctx_emit(batch, index,
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 7a74750076c5..2faf64f9f256 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -851,15 +851,13 @@ static int gen9_init_workarounds(struct
> intel_engine_cs *engine)
>   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
>     GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
>  
> - /* WaDisableDgMirrorFixInHalfSliceChicken5:skl,bxt */
> - if (IS_SKL_REVID(dev_priv, 0, SKL_REVID_B0) ||
> - IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
> + /* WaDisableDgMirrorFixInHalfSliceChicken5:bxt */
> +

  1   2   >