[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Add MIPIIO Enable/disable sequence

2017-02-28 Thread Patchwork
== Series Details ==

Series: drm/i915/glk: Add MIPIIO Enable/disable sequence
URL   : https://patchwork.freedesktop.org/series/20436/
State : success

== Summary ==

Series 20436v1 drm/i915/glk: Add MIPIIO Enable/disable sequence
https://patchwork.freedesktop.org/api/1.0/series/20436/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
f25326a drm/i915/glk: Add MIPIIO Enable/disable sequence

== Logs ==

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


Re: [Intel-gfx] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

2017-02-28 Thread Tomi Valkeinen
On 28/02/17 14:55, Joe Perches wrote:
> Use a more common logging style.
> 
> Miscellanea:
> 
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
> 
> Signed-off-by: Joe Perches 

For omap:

Acked-by: Tomi Valkeinen 

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable sequence

2017-02-28 Thread Madhav Chauhan
From: Deepak M 

v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Jani's Review comment for aligning code to platforms and added
wrapper functions.
v4: Corrected enable/disable seuqence as per BSPEC
v5: Corrected waiting twice for same bit (Review comments: Jani)
v6: Rebased to Han's patches(dsi restructuring code)

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi.c | 206 ---
 1 file changed, 195 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 20ed799..8e97bae3 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
return true;
 }
 
+static void glk_dsi_device_ready(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   enum port port;
+   u32 tmp, val;
+
+   /* Set the MIPI mode
+* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
+* Power ON MIPI IO first and then write into IO reset and LP wake bits
+*/
+   for_each_dsi_port(port, intel_dsi->ports) {
+   tmp = I915_READ(MIPI_CTRL(port));
+   I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
+   }
+
+   /* Put the IO into reset */
+   tmp = I915_READ(MIPI_CTRL(PORT_A));
+   tmp &= ~GLK_MIPIIO_RESET_RELEASED;
+   I915_WRITE(MIPI_CTRL(PORT_A), tmp);
+
+   /* Program LP Wake */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   tmp = I915_READ(MIPI_CTRL(port));
+   tmp |= GLK_LP_WAKE;
+   I915_WRITE(MIPI_CTRL(port), tmp);
+   }
+
+   /* Wait for Pwr ACK */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
+   GLK_MIPIIO_PORT_POWERED, 20))
+   DRM_ERROR("MIPIO port is powergated\n");
+   }
+
+   /* Wait for MIPI PHY status bit to set */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_PHY_STATUS_PORT_READY,
+   GLK_PHY_STATUS_PORT_READY, 20))
+   DRM_ERROR("PHY is not ON\n");
+   }
+
+   /* Get IO out of reset */
+   tmp = I915_READ(MIPI_CTRL(PORT_A));
+   I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED);
+
+   /* Get IO out of Low power state*/
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) {
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= DEVICE_READY;
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+   usleep_range(10, 15);
+   }
+
+   /* Enter ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_ENTER | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+   /* Wait for ULPS Not active */
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
+   GLK_ULPS_NOT_ACTIVE, 20))
+
+   /* Exit ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_EXIT | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+   /* Enter Normal Mode */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+   tmp = I915_READ(MIPI_CTRL(port));
+   tmp &= ~GLK_LP_WAKE;
+   I915_WRITE(MIPI_CTRL(port), tmp);
+   }
+
+   /* Wait for Stop state */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_DATA_LANE_STOP_STATE,
+   GLK_DATA_LANE_STOP_STATE, 20))
+   DRM_ERROR("Date lane not in STOP state\n");
+   }
+
+   /* Wait for AFE LATCH */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   BXT_MIPI_PORT_CTRL(port), AFE_LATCHOUT,
+

[Intel-gfx] [GLK MIPI DSI V7] GLK MIPI DSI VIDEO MODE PATCHES

2017-02-28 Thread Madhav Chauhan
The patches in this list enable MIPI DSI video mode
support for GLK platform. Tesed locally.
v2: Renamed bitfields macros as per review comments(Jani)
v3: Code alignment/abstraction as per arch (Jani review comments)
v4: Fix MIPI DSI disable sequence. Review comments(Jani)
v5: Review comments addressed for restructuring code (Jani & Ander)
v6: Changes in enable i/o sequence, remove compile warning (Jani review 
comments)
v7: Patch (GLK MIPI DSI V6 3/7) rebased to Han dsi restructuring series [1]
[1]: https://patchwork.freedesktop.org/series/20361
Rest of the GLK dsi video mode patches which published from
v1 to v6 merged to drm-tip.

Deepak M (1):
  drm/i915/glk: Add MIPIIO Enable/disable sequence

 drivers/gpu/drm/i915/intel_dsi.c | 206 ---
 1 file changed, 195 insertions(+), 11 deletions(-)

-- 
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 series starting with [1/2] drm/i915/glk: Apply cdclk workaround for DP audio

2017-02-28 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/glk: Apply cdclk workaround for DP 
audio
URL   : https://patchwork.freedesktop.org/series/20430/
State : warning

== Summary ==

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

Test gem_exec_parallel:
Subgroup basic:
pass   -> DMESG-WARN (fi-skl-6700k)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
bc61fcd drm/i915: Implement BXT and GLK cdclk restriction based on Azalia BCLK
122bad9 drm/i915/glk: Apply cdclk workaround for DP audio

== Logs ==

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


[Intel-gfx] [PATCH 1/2] drm/i915/glk: Apply cdclk workaround for DP audio

2017-02-28 Thread Dhinakaran Pandiyan
Implement GLK cdclk restriction for DP audio, similar to what's implemented
for BDW and other GEN9 platforms. The cdclk restriction has been
refactored out of max. pixel clock computation as the 1:1 relationship
between pixel clock and cdclk frequency does not hold for GLK.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 83 --
 1 file changed, 52 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index d643c0c..8fc0f72 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1069,11 +1069,11 @@ static int bxt_calc_cdclk(int max_pixclk)
return 144000;
 }
 
-static int glk_calc_cdclk(int max_pixclk)
+static int glk_calc_cdclk(int max_pixclk, int min_cdclk)
 {
-   if (max_pixclk > 2 * 158400)
+   if (max_pixclk > 2 * 158400 || min_cdclk > 158400)
return 316800;
-   else if (max_pixclk > 2 * 79200)
+   else if (max_pixclk > 2 * 79200 || min_cdclk > 79200)
return 158400;
else
return 79200;
@@ -1367,7 +1367,7 @@ void bxt_init_cdclk(struct drm_i915_private *dev_priv)
 *   Need to make this change after VBT has changes for BXT.
 */
if (IS_GEMINILAKE(dev_priv)) {
-   cdclk_state.cdclk = glk_calc_cdclk(0);
+   cdclk_state.cdclk = glk_calc_cdclk(0, 0);
cdclk_state.vco = glk_de_pll_vco(dev_priv, cdclk_state.cdclk);
} else {
cdclk_state.cdclk = bxt_calc_cdclk(0);
@@ -1432,28 +1432,37 @@ void intel_set_cdclk(struct drm_i915_private *dev_priv,
dev_priv->display.set_cdclk(dev_priv, cdclk_state);
 }
 
-static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state *crtc_state,
- int pixel_rate)
+static int intel_min_cdclk(struct drm_atomic_state *state)
 {
-   struct drm_i915_private *dev_priv =
-   to_i915(crtc_state->base.crtc->dev);
+   struct drm_i915_private *dev_priv = to_i915(state->dev);
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *cstate;
+   int i;
+   int min_cdclk = 0;
 
-   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
-   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
-   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   struct intel_crtc_state *crtc_state;
 
-   /* BSpec says "Do not use DisplayPort with CDCLK less than
-* 432 MHz, audio enabled, port width x4, and link rate
-* HBR2 (5.4 GHz), or else there may be audio corruption or
-* screen corruption."
-*/
-   if (intel_crtc_has_dp_encoder(crtc_state) &&
-   crtc_state->has_audio &&
-   crtc_state->port_clock >= 54 &&
-   crtc_state->lane_count == 4)
-   pixel_rate = max(432000, pixel_rate);
+   crtc_state = to_intel_crtc_state(cstate);
+
+   /* According to BSpec, "Do not use DisplayPort with CDCLK less
+* than 432 MHz, audio enabled, port width x4, and link rate
+* HBR2 (5.4 GHz), or else there may be audio corruption or
+* screen corruption." for BDW and GEN9. The cdclk restriction
+* for GLK is at 316.8 MHz
+*/
+   if (intel_crtc_has_dp_encoder(crtc_state) &&
+   crtc_state->has_audio &&
+   crtc_state->port_clock >= 54 &&
+   crtc_state->lane_count == 4) {
+   if (IS_GEMINILAKE(dev_priv))
+   min_cdclk = 316800;
+   else if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
+   min_cdclk = 432000;
+   }
+   }
 
-   return pixel_rate;
+   return min_cdclk;
 }
 
 /* compute the max rate for new configuration */
@@ -1481,10 +1490,9 @@ static int intel_max_pixel_rate(struct drm_atomic_state 
*state)
 
pixel_rate = crtc_state->pixel_rate;
 
-   if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
-   pixel_rate =
-   bdw_adjust_min_pipe_pixel_rate(crtc_state,
-  pixel_rate);
+   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
+   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
+   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
 
intel_state->min_pixclk[i] = pixel_rate;
}
@@ -1531,13 +1539,17 @@ static int bdw_modeset_calc_cdclk(struct 
drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
  

[Intel-gfx] [PATCH 2/2] drm/i915: Implement BXT and GLK cdclk restriction based on Azalia BCLK

2017-02-28 Thread Dhinakaran Pandiyan
According to BSpec, "The CD clock frequency must be at least twice the
frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by
default. BXT and GLK both have cdclk frequencies that are less han 192 MHz,
so apply the check conditionally for these platforms.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 8fc0f72..89027fa 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1444,6 +1444,8 @@ static int intel_min_cdclk(struct drm_atomic_state *state)
struct intel_crtc_state *crtc_state;
 
crtc_state = to_intel_crtc_state(cstate);
+   if (!crtc_state->has_audio)
+   continue;
 
/* According to BSpec, "Do not use DisplayPort with CDCLK less
 * than 432 MHz, audio enabled, port width x4, and link rate
@@ -1452,7 +1454,6 @@ static int intel_min_cdclk(struct drm_atomic_state *state)
 * for GLK is at 316.8 MHz
 */
if (intel_crtc_has_dp_encoder(crtc_state) &&
-   crtc_state->has_audio &&
crtc_state->port_clock >= 54 &&
crtc_state->lane_count == 4) {
if (IS_GEMINILAKE(dev_priv))
@@ -1460,6 +1461,13 @@ static int intel_min_cdclk(struct drm_atomic_state 
*state)
else if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
min_cdclk = 432000;
}
+
+   /* According to BSpec, "The CD clock frequency must be at least
+* twice the frequency of the Azalia BCLK." and BCLK is 96 MHz
+* by default.
+*/
+   if (IS_BROXTON(dev_priv) || IS_GEMINILAKE(dev_priv))
+   min_cdclk = max(min_cdclk, 2 * 96000);
}
 
return min_cdclk;
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v4 4/5] drm/atomic: Convert get_existing_state callers to get_old/new_state, v3.

2017-02-28 Thread Laurent Pinchart
Hi Maarten,

Thank you for the patch.

On Thursday 16 Feb 2017 15:47:09 Maarten Lankhorst wrote:
> This is a straightforward conversion that converts all the users of
> get_existing_state in atomic core to use get_old_state or get_new_state
> 
> Changes since v1:
> - Fix using the wrong state in
> drm_atomic_helper_update_legacy_modeset_state. Changes since v2:
> - Use the correct state in disable_outputs()
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic.c|  6 ++---
>  drivers/gpu/drm/drm_atomic_helper.c | 43 ++
>  drivers/gpu/drm/drm_blend.c |  3 +--
>  drivers/gpu/drm/drm_simple_kms_helper.c |  4 +--
>  4 files changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index afec53832145..c9aac9cbf111 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1358,8 +1358,8 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state, return 0;
> 
>   if (conn_state->crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(conn_state-
>state,
> - conn_state-
>crtc);
> + crtc_state = drm_atomic_get_new_crtc_state(conn_state->state,
> +conn_state->crtc);

I believe more *_state -> *_(new|old)_state renames could be useful, but that 
can be addressed as a subsequent patch, so

Reviewed-by: Laurent Pinchart 

>   crtc_state->connector_mask &=
>   ~(1 << drm_connector_index(conn_state->connector));
> @@ -1476,7 +1476,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
> *state, {
>   struct drm_plane *plane;
> 
> - WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
> + WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
> 
>   drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
>   struct drm_plane_state *plane_state =
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index ea544bddc29b..6296ae6e6aff
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -70,8 +70,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state, struct drm_crtc_state *crtc_state;
> 
>   if (old_plane_state->crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(state,
> - 
old_plane_state->crtc);
> + crtc_state = drm_atomic_get_new_crtc_state(state,
> +old_plane_state-
>crtc);
> 
>   if (WARN_ON(!crtc_state))
>   return;
> @@ -80,8 +80,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state, }
> 
>   if (plane_state->crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(state,
> - plane_state-
>crtc);
> + crtc_state = drm_atomic_get_new_crtc_state(state, plane_state-
>crtc);
> 
>   if (WARN_ON(!crtc_state))
>   return;
> @@ -150,7 +149,7 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state, drm_for_each_connector_iter(connector, _iter)
> {
>   struct drm_crtc_state *crtc_state;
> 
> - if (drm_atomic_get_existing_connector_state(state, connector))
> + if (drm_atomic_get_new_connector_state(state, connector))
>   continue;
> 
>   encoder = connector->state->best_encoder;
> @@ -178,7 +177,7 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state, new_conn_state->crtc->base.id,
> new_conn_state->crtc->name,
>connector->base.id, connector->name);
> 
> - crtc_state = drm_atomic_get_existing_crtc_state(state,
> new_conn_state->crtc); +  crtc_state = 
drm_atomic_get_new_crtc_state(state,
> new_conn_state->crtc);
> 
>   ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
>   if (ret)
> @@ -219,7 +218,7 @@ set_best_encoder(struct drm_atomic_state *state,
>*/
>   WARN_ON(!crtc && encoder != conn_state->best_encoder);
>   if (crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
> + crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
> 
>   crtc_state->encoder_mask &=
>   ~(1 << drm_encoder_index(conn_state-
>best_encoder));
> @@ -230,7 +229,7 @@ set_best_encoder(struct drm_atomic_state *state,
>   crtc = conn_state->crtc;
>   WARN_ON(!crtc);
>   if 

Re: [Intel-gfx] [PATCH v4 5/5] drm/blend: Use new atomic iterator macros.

2017-02-28 Thread Laurent Pinchart
Hi Maarten,

Thank you for the patch.

On Thursday 16 Feb 2017 15:47:10 Maarten Lankhorst wrote:
> There are new iterator macros that annotate whether the new or old
> state should be used. This is better than using a state that depends on
> whether it's called before or after swap. For clarity, also rename the
> variables from $obj_state to (old,new)_$obj_state as well.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_blend.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index d7053bb67db6..a0d0d6843288 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -377,26 +377,26 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
> struct drm_atomic_state *state)
>  {
>   struct drm_crtc *crtc;
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *old_plane_state, *new_plane_state;
>   int i, ret = 0;
> 
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - crtc = plane_state->crtc;
> + for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) { +   crtc = new_plane_state->crtc;
>   if (!crtc)
>   continue;
> - if (plane->state->zpos != plane_state->zpos) {
> - crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
> - crtc_state->zpos_changed = true;
> + if (old_plane_state->zpos != new_plane_state->zpos) {
> + new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
> + new_crtc_state->zpos_changed = true;
>   }
>   }
> 
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (crtc_state->plane_mask != crtc->state->plane_mask ||
> - crtc_state->zpos_changed) {
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state,
> i) { +if (old_crtc_state->plane_mask != new_crtc_state-
>plane_mask || +
>new_crtc_state->zpos_changed) {
>   ret = drm_atomic_helper_crtc_normalize_zpos(crtc,
> - 
crtc_state);
> + 
new_crtc_state);
>   if (ret)
>   return ret;
>   }

-- 
Regards,

Laurent Pinchart

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


Re: [Intel-gfx] [PATCH v4 3/5] drm/atomic: Add macros to access existing old/new state, v2.

2017-02-28 Thread Laurent Pinchart
Hi Maarten,

Thank you for the patch.

On Thursday 16 Feb 2017 15:47:08 Maarten Lankhorst wrote:
> After atomic commit, these macros should be used in place of
> get_existing_state. Also after commit get_xx_state should no longer
> be used because it may not have the required locks.
> 
> The calls to drm_atomic_get_existing_$obj_state should no longer be
> used, and converted over to these new calls.
> 
> Changes since v1:
> - Expand commit message.
> - Deprecate get_existing_*_state functions in the documentation.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Laurent Pinchart 

> ---
>  include/drm/drm_atomic.h | 108 +++
>  1 file changed, 108 insertions(+)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index c6f355a970d2..0147a047878d 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -277,6 +277,9 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector, *
>   * This function returns the crtc state for the given crtc, or NULL
>   * if the crtc is not part of the global atomic state.
> + *
> + * This function is deprecated, @drm_atomic_get_old_crtc_state or
> + * @drm_atomic_get_new_crtc_state should be used instead.
>   */
>  static inline struct drm_crtc_state *
>  drm_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
> @@ -286,12 +289,44 @@ drm_atomic_get_existing_crtc_state(struct
> drm_atomic_state *state, }
> 
>  /**
> + * drm_atomic_get_old_crtc_state - get old crtc state, if it exists
> + * @state: global atomic state object
> + * @crtc: crtc to grab
> + *
> + * This function returns the old crtc state for the given crtc, or
> + * NULL if the crtc is not part of the global atomic state.
> + */
> +static inline struct drm_crtc_state *
> +drm_atomic_get_old_crtc_state(struct drm_atomic_state *state,
> +   struct drm_crtc *crtc)
> +{
> + return state->crtcs[drm_crtc_index(crtc)].old_state;
> +}
> +/**
> + * drm_atomic_get_new_crtc_state - get new crtc state, if it exists
> + * @state: global atomic state object
> + * @crtc: crtc to grab
> + *
> + * This function returns the new crtc state for the given crtc, or
> + * NULL if the crtc is not part of the global atomic state.
> + */
> +static inline struct drm_crtc_state *
> +drm_atomic_get_new_crtc_state(struct drm_atomic_state *state,
> +   struct drm_crtc *crtc)
> +{
> + return state->crtcs[drm_crtc_index(crtc)].new_state;
> +}
> +
> +/**
>   * drm_atomic_get_existing_plane_state - get plane state, if it exists
>   * @state: global atomic state object
>   * @plane: plane to grab
>   *
>   * This function returns the plane state for the given plane, or NULL
>   * if the plane is not part of the global atomic state.
> + *
> + * This function is deprecated, @drm_atomic_get_old_plane_state or
> + * @drm_atomic_get_new_plane_state should be used instead.
>   */
>  static inline struct drm_plane_state *
>  drm_atomic_get_existing_plane_state(struct drm_atomic_state *state,
> @@ -301,12 +336,45 @@ drm_atomic_get_existing_plane_state(struct
> drm_atomic_state *state, }
> 
>  /**
> + * drm_atomic_get_old_plane_state - get plane state, if it exists
> + * @state: global atomic state object
> + * @plane: plane to grab
> + *
> + * This function returns the old plane state for the given plane, or
> + * NULL if the plane is not part of the global atomic state.
> + */
> +static inline struct drm_plane_state *
> +drm_atomic_get_old_plane_state(struct drm_atomic_state *state,
> +struct drm_plane *plane)
> +{
> + return state->planes[drm_plane_index(plane)].old_state;
> +}
> +
> +/**
> + * drm_atomic_get_new_plane_state - get plane state, if it exists
> + * @state: global atomic state object
> + * @plane: plane to grab
> + *
> + * This function returns the new plane state for the given plane, or
> + * NULL if the plane is not part of the global atomic state.
> + */
> +static inline struct drm_plane_state *
> +drm_atomic_get_new_plane_state(struct drm_atomic_state *state,
> +struct drm_plane *plane)
> +{
> + return state->planes[drm_plane_index(plane)].new_state;
> +}
> +
> +/**
>   * drm_atomic_get_existing_connector_state - get connector state, if it
> exists * @state: global atomic state object
>   * @connector: connector to grab
>   *
>   * This function returns the connector state for the given connector,
>   * or NULL if the connector is not part of the global atomic state.
> + *
> + * This function is deprecated, @drm_atomic_get_old_connector_state or
> + * @drm_atomic_get_new_connector_state should be used instead.
>   */
>  static inline struct drm_connector_state *
>  drm_atomic_get_existing_connector_state(struct drm_atomic_state *state,
> @@ -321,6 +389,46 @@ drm_atomic_get_existing_connector_state(struct
> drm_atomic_state *state, }
> 
>  

Re: [Intel-gfx] [PATCH v4 2/5] drm/atomic: Make drm_atomic_plane_disabling easier to understand.

2017-02-28 Thread Laurent Pinchart
Hi Maarten,

Thank you for the patch.

On Thursday 16 Feb 2017 15:47:07 Maarten Lankhorst wrote:
> This function becomes a lot simpler when having passed both the old and
> new state to it. Looking at all callers, it seems that old_plane_state
> is never NULL so the check can be dropped.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  7 ---
>  drivers/gpu/drm/drm_plane_helper.c  |  2 +-
>  include/drm/drm_atomic_helper.h | 26 --
>  3 files changed, 13 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 7d432d9a18cf..ea544bddc29b
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1757,7 +1757,8 @@ void drm_atomic_helper_commit_planes(struct drm_device
> *dev, if (!funcs)
>   continue;
> 
> - disabling = drm_atomic_plane_disabling(plane, 
old_plane_state);
> + disabling = drm_atomic_plane_disabling(old_plane_state,
> +new_plane_state);
> 
>   if (active_only) {
>   /*
> @@ -1852,11 +1853,11 @@ drm_atomic_helper_commit_planes_on_crtc(struct
> drm_crtc_state *old_crtc_state)
> 
>   WARN_ON(plane->state->crtc && plane->state->crtc != crtc);
> 
> - if (drm_atomic_plane_disabling(plane, old_plane_state) &&
> + if (drm_atomic_plane_disabling(old_plane_state, plane->state) 
&&
>   plane_funcs->atomic_disable)
>   plane_funcs->atomic_disable(plane, old_plane_state);
>   else if (plane->state->crtc ||
> -  drm_atomic_plane_disabling(plane, old_plane_state))
> +  drm_atomic_plane_disabling(old_plane_state, plane-
>state))
>   plane_funcs->atomic_update(plane, old_plane_state);
>   }
> 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c index 148688fb920a..f4d70dd5e3e4
> 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -470,7 +470,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>* Drivers may optionally implement the ->atomic_disable callback, so
>* special-case that here.
>*/
> - if (drm_atomic_plane_disabling(plane, plane_state) &&
> + if (drm_atomic_plane_disabling(plane_state, plane->state) &&
>   plane_funcs->atomic_disable)
>   plane_funcs->atomic_disable(plane, plane_state);
>   else
> diff --git a/include/drm/drm_atomic_helper.h
> b/include/drm/drm_atomic_helper.h index 9ceda379ce58..dc16274987c7 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -220,10 +220,10 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc, __drm_atomic_get_current_plane_state((crtc_state)->state, \ plane)))
> 
> -/*
> +/**
>   * drm_atomic_plane_disabling - check whether a plane is being disabled
> - * @plane: plane object
> - * @old_state: previous atomic state
> + * @old_plane_state: old atomic plane state
> + * @new_plane_state: new atomic plane state
>   *
>   * Checks the atomic state of a plane to determine whether it's being
> disabled * or not. This also WARNs if it detects an invalid state (both
> CRTC and FB @@ -233,28 +233,18 @@ int
> drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc, * True if the
> plane is being disabled, false otherwise.
>   */
>  static inline bool
> -drm_atomic_plane_disabling(struct drm_plane *plane,
> -struct drm_plane_state *old_state)
> +drm_atomic_plane_disabling(struct drm_plane_state *old_plane_state,
> +struct drm_plane_state *new_plane_state)
>  {
>   /*
>* When disabling a plane, CRTC and FB should always be NULL together.
>* Anything else should be considered a bug in the atomic core, so we
>* gently warn about it.
>*/
> - WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
> - (plane->state->crtc != NULL && plane->state->fb == NULL));
> + WARN_ON((new_plane_state->crtc == NULL && new_plane_state->fb != NULL) 
||
> + (new_plane_state->crtc != NULL && new_plane_state->fb == 
NULL));
> 
> - /*
> -  * When using the transitional helpers, old_state may be NULL. If so,
> -  * we know nothing about the current state and have to assume that it
> -  * might be enabled.
> -  *
> -  * When using the atomic helpers, old_state won't be NULL. Therefore
> -  * this check assumes that either the driver will have reconstructed
> -  * the correct state in ->reset() or that the driver will have taken
> -  * appropriate measures to disable all planes.
> -  */
> 

Re: [Intel-gfx] [PATCH v4 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v2.

2017-02-28 Thread Laurent Pinchart
Hi Maarten,

Thank you for the patch.

On Thursday 16 Feb 2017 15:47:06 Maarten Lankhorst wrote:
> There are new iterator macros that annotate whether the new or old
> state should be used. This is better than using a state that depends on
> whether it's called before or after swap. For clarity, also rename the
> variables from $obj_state to (old,new)_$obj_state as well.
> 
> Changes since v1:
> - Use old/new_*_state for variable names as much as possible. (pinchartl)
> - Expand commit message.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 431 +
>  1 file changed, 222 insertions(+), 209 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 9203f3e933f7..7d432d9a18cf
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c

[snip]

> @@ -1929,11 +1926,21 @@ void drm_atomic_helper_cleanup_planes(struct
> drm_device *dev, struct drm_atomic_state *old_state)
>  {
>   struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *old_plane_state, *new_plane_state;
>   int i;
> 
> - for_each_plane_in_state(old_state, plane, plane_state, i) {
> + for_each_oldnew_plane_in_state(old_state, plane, old_plane_state,
> new_plane_state, i) { const struct drm_plane_helper_funcs *funcs;
> + struct drm_plane_state *plane_state;
> +
> + /*
> +  * This might be called before swapping when commit is 
aborted,
> +  * in which case we have to free the new state.

s/free/cleanup/

Apart from that,

Reviewed-by: Laurent Pinchart 

You will however need to rebase the series on top of the latest drm-misc as it 
conflicts (at compile time) with

commit 40ee6fbef75fe6452dc9e69e6f9f1a2c7808ed67
Author: Manasi Navare 
Date:   Fri Dec 16 12:29:06 2016 +0200

drm: Add a new connector atomic property for link status

> +  */
> + if (old_plane_state == plane->state)
> + plane_state = new_plane_state;
> + else
> + plane_state = old_plane_state;
> 
>   funcs = plane->helper_private;
> 

[snip]

-- 
Regards,

Laurent Pinchart

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


Re: [Intel-gfx] [PATCH] #1: test capitalizing PATCH

2017-02-28 Thread Hans de Goede

Hi,

On 28-02-17 17:31, Jani Nikula wrote:


Cc: Hans, this probably applies to you as well.


I'm already always using git-send-email, so whatever the
reason why the CI system is not picking up my patches, this
aint it.

Regards,

Hans



On Tue, 28 Feb 2017, Dan Carpenter  wrote:

The new version patchwork is filtering out my patches for some reason.
Test if it's because it now insists on a capital [PATCH] in the subject.

Patchwork should be more version control agnostic than that.


The patchwork flavor at freedesktop.org expects patches are sent using
git send-email [1]. I hear otherwise there were too many false
positives.

Please either use git send-email, or add

X-Mailer: git-send-email haha only kidding

header into your patch mails.

I'm sorry for the inconvenience and lack of transparency on
this. Apparently git send-email is so ubiquitous nowadays that this
hasn't been much of a problem.


BR,
Jani.


[1] 
https://github.com/dlespiau/patchwork/blob/master/patchwork/bin/parsemail.py#L323


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


Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

2017-02-28 Thread Ben Widawsky

On 17-02-28 12:18:39, Jason Ekstrand wrote:

On Thu, Jan 5, 2017 at 7:14 AM,  wrote:


From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.

Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.

Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.

Also not all planes will be capable of scanning out compressed surfaces,
and eg. 90/270 degree rotation is not supported in combination with
decompression either.

This patch may contain work from at least the following people:
* Vandana Kannan 
* Daniel Vetter 
* Ben Widawsky 

v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)

Cc: Paulo Zanoni 
Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  23 
 drivers/gpu/drm/i915/intel_display.c | 234 ++
++---
 drivers/gpu/drm/i915/intel_pm.c  |  29 -
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 4 files changed, 274 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_
reg.h
index 00970aa77afa..6849ba93f1d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6209,6 +6209,28 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))

+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
_PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
_PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
@@ -6433,6 +6455,7 @@ enum {
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)

 #define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
 #define  DPA_MASK_VBLANK_SRD   (1 << 15)
 #define  FORCE_ARB_IDLE_PLANES (1 << 14)
 #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 38de9df0ec60..2236abebd8bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
drm_framebuffer *fb, int plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   if (plane == 1)
+   return 64;



I've said it before but reading through Ben's patches again make me want to
be peskier about it.  I would really like the UABI to treat 

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/gem_bad_address: Fix store address

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 01:58:24PM -0800, Antonio Argenziano wrote:
> The test purpose is to write at an invalid GTT location. To do so, the
> store instruction used in the test has been updated to use the correct
> value and extra unneeded flags have been removed. The batch buffer is
> also sent as privileged now.

Delete it.
-Chris

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


[Intel-gfx] [PATCH i-g-t 2/2] tests/gem_bad_address: Fix store address

2017-02-28 Thread Antonio Argenziano
The test purpose is to write at an invalid GTT location. To do so, the
store instruction used in the test has been updated to use the correct
value and extra unneeded flags have been removed. The batch buffer is
also sent as privileged now.

Signed-off-by: Antonio Argenziano 
---
 tests/gem_bad_address.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/tests/gem_bad_address.c b/tests/gem_bad_address.c
index a970dfa4..720ab24d 100644
--- a/tests/gem_bad_address.c
+++ b/tests/gem_bad_address.c
@@ -38,22 +38,26 @@
 #include "drm.h"
 #include "intel_bufmgr.h"
 
+/*
+The intent of this test is to try write an area of memory that is outside
+the currently allowed boundary of the GTT. To do so it will use a batch
+buffer that will run on Blitter engine as a privileged batch.
+*/
+
 static drm_intel_bufmgr *bufmgr;
 struct intel_batchbuffer *batch;
 
-#define BAD_GTT_DEST ((512*1024*1024)) /* past end of aperture */
-
 static void
 bad_store(void)
 {
BEGIN_BATCH(4, 0);
-   OUT_BATCH(MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL | 1 << 21);
-   OUT_BATCH(0);
-   OUT_BATCH(BAD_GTT_DEST);
+   OUT_BATCH(MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL );
+   OUT_BATCH(0); // lower part of the address (first 4 GByte = GTT size)
+   OUT_BATCH(0x1); //Higher part of the address (>GTT size)
OUT_BATCH(0xdeadbeef);
ADVANCE_BATCH();
 
-   intel_batchbuffer_flush(batch);
+   intel_batchbuffer_flush_secure(batch);
 }
 
 igt_simple_main
-- 
2.11.0

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


[Intel-gfx] [PATCH i-g-t 1/2] lib/intel_batchbuffer: Add secure batch buffer flushing on ring

2017-02-28 Thread Antonio Argenziano
Added functions for flushing a batch buffer as privileged.

Signed-off-by: Antonio Argenziano 
---
 lib/intel_batchbuffer.c | 45 +
 lib/intel_batchbuffer.h |  4 +++-
 2 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index f1353901..38ce3b69 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -158,15 +158,35 @@ flush_on_ring_common(struct intel_batchbuffer *batch, int 
ring)
 }
 
 /**
- * intel_batchbuffer_flush_on_ring:
+ * intel_batchbuffer_flush_on_ring_secure:
  * @batch: batchbuffer object
  * @ring: execbuf ring flag
  *
  * Submits the batch for execution on @ring.
  */
 void
-intel_batchbuffer_flush_on_ring(struct intel_batchbuffer *batch, int ring)
+intel_batchbuffer_flush_on_ring_secure(struct intel_batchbuffer *batch, int 
ring)
+{
+int flags = 0;
+
+   flags |= ring;
+   flags |= I915_EXEC_SECURE;
+
+intel_batchbuffer_flush_on_ring(batch, flags);
+
+}
+
+/**
+ * intel_batchbuffer_flush_on_ring:
+ * @batch: batchbuffer object
+ * @flags: execbuf ring flag, plus additional submission flags
+ *
+ * Submits the batch for execution on the engine set in @flags.
+ */
+void
+intel_batchbuffer_flush_on_ring(struct intel_batchbuffer *batch, int flags)
 {
+int ring = flags & I915_EXEC_RING_MASK;
unsigned int used = flush_on_ring_common(batch, ring);
drm_intel_context *ctx;
 
@@ -179,9 +199,10 @@ intel_batchbuffer_flush_on_ring(struct intel_batchbuffer 
*batch, int ring)
 
/* XXX bad kernel API */
ctx = batch->ctx;
-   if (ring != I915_EXEC_RENDER)
+   if ((ring) != I915_EXEC_RENDER)
ctx = NULL;
-   do_or_die(drm_intel_gem_bo_context_exec(batch->bo, ctx, used, ring));
+
+   do_or_die(drm_intel_gem_bo_context_exec(batch->bo, ctx, used, flags));
 
intel_batchbuffer_reset(batch);
 }
@@ -224,6 +245,22 @@ intel_batchbuffer_flush_with_context(struct 
intel_batchbuffer *batch,
 }
 
 /**
+ * intel_batchbuffer_flush_secure:
+ * @batch: batchbuffer object
+ *
+ * Submits the batch, as a secure batch, for execution on the blitter engine,
+ * selecting the right ring depending upon the hardware platform.
+ */
+void
+intel_batchbuffer_flush_secure(struct intel_batchbuffer *batch)
+{
+   int ring = 0;
+   if (HAS_BLT_RING(batch->devid))
+   ring = I915_EXEC_BLT;
+   intel_batchbuffer_flush_on_ring_secure(batch, ring);
+}
+
+/**
  * intel_batchbuffer_flush:
  * @batch: batchbuffer object
  *
diff --git a/lib/intel_batchbuffer.h b/lib/intel_batchbuffer.h
index 869747db..0ed2055a 100644
--- a/lib/intel_batchbuffer.h
+++ b/lib/intel_batchbuffer.h
@@ -35,7 +35,9 @@ void intel_batchbuffer_free(struct intel_batchbuffer *batch);
 
 
 void intel_batchbuffer_flush(struct intel_batchbuffer *batch);
-void intel_batchbuffer_flush_on_ring(struct intel_batchbuffer *batch, int 
ring);
+void intel_batchbuffer_flush_secure(struct intel_batchbuffer *batch);
+void intel_batchbuffer_flush_on_ring(struct intel_batchbuffer *batch, int 
flags);
+void intel_batchbuffer_flush_on_ring_secure(struct intel_batchbuffer *batch, 
int ring);
 void intel_batchbuffer_flush_with_context(struct intel_batchbuffer *batch,
  drm_intel_context *context);
 
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH] #1: test capitalizing PATCH

2017-02-28 Thread Dan Carpenter
On Tue, Feb 28, 2017 at 06:31:48PM +0200, Jani Nikula wrote:
> 
> Cc: Hans, this probably applies to you as well.
> 
> On Tue, 28 Feb 2017, Dan Carpenter  wrote:
> > The new version patchwork is filtering out my patches for some reason.
> > Test if it's because it now insists on a capital [PATCH] in the subject.
> >
> > Patchwork should be more version control agnostic than that.
> 
> The patchwork flavor at freedesktop.org expects patches are sent using
> git send-email [1]. I hear otherwise there were too many false
> positives.
> 
> Please either use git send-email, or add
> 
> X-Mailer: git-send-email haha only kidding
> 
> header into your patch mails.

Ah.  Great.  Thanks!

regards,
dan carpenter

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


Re: [Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 07:07:38PM +0100, Michal Wajdeczko wrote:
> On Tue, Feb 28, 2017 at 04:52:34PM +, Chris Wilson wrote:
> > On Tue, Feb 28, 2017 at 04:43:02PM +, Chris Wilson wrote:
> > > On Tue, Feb 28, 2017 at 02:12:09PM +, Michal Wajdeczko wrote:
> > > > +/* Hardware Engine ID definitions */
> > > > +#define RCS_HW 0
> > > > +#define VCS_HW 1
> > > > +#define BCS_HW 2
> > > > +#define VECS_HW3
> > > > +#define VCS2_HW4
> > > 
> > > So don't put them in the header if they may have inconsistent meanings.
> > 
> > Or if you do want to keep them in a header, either i915_reg.h or
> > intel_engine_reg.h as somewhere out of the way, and clear that they are
> > not meant for the rest of the bookkeeping in intel_ringbuffer.h.
> 
> I can't find nice spot for these engine IDs in the i915_reg.h
> 
> Can I just move these definitions to the top of this header?

I would rather we spend a little effort on splitting our driver API from
hw innards.
-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/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

2017-02-28 Thread Sinclair Yeh
For drm/vmwgfx:  Acked-by: Sinclair Yeh 

On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote:
> Use a more common logging style.
> 
> Miscellanea:
> 
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  9 -
>  drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
>  drivers/gpu/drm/gma500/psb_drv.h  |  5 ++---
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  7 +++
>  drivers/gpu/drm/i915/i915_sw_fence.c  |  8 
>  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
>  drivers/gpu/drm/msm/msm_drv.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_acpi.c|  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  4 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
>  drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
>  drivers/gpu/drm/omapdrm/dss/dss.c |  3 +--
>  drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
>  drivers/gpu/drm/omapdrm/omap_gem.c|  5 ++---
>  drivers/gpu/drm/r128/r128_cce.c   |  7 +++
>  drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  6 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  3 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  4 ++--
>  20 files changed, 72 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
>   head) {
>   if (tmp_encoder != encoder
>   && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> -"encoder on the same pipe\n");
> + pr_err("Can't enable LVDS and another encoder on the 
> same pipe\n");
>   return false;
>   }
>   }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>  
>  failed_find:
>   mutex_unlock(>mode_config.mutex);
> - printk(KERN_ERR "Failed find\n");
> + pr_err("Failed find\n");
>   psb_intel_i2c_destroy(gma_encoder->ddc_bus);
>  failed_ddc:
> - printk(KERN_ERR "Failed DDC\n");
> + pr_err("Failed DDC\n");
>   psb_intel_i2c_destroy(gma_encoder->i2c_bus);
>  failed_blc_i2c:
> - printk(KERN_ERR "Failed BLC\n");
> + pr_err("Failed BLC\n");
>   drm_encoder_cleanup(encoder);
>   drm_connector_cleanup(connector);
>   kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct 
> drm_device *dev,
>   ((ti->vblank_hi << 8) | ti->vblank_lo);
>   mode->clock = ti->pixel_clock * 10;
>  #if 0
> - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> - printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> - printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> - printk(KERN_INFO "htotal is %d\n", mode->htotal);
> - printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> - printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> - printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> - printk(KERN_INFO "clock is %d\n", mode->clock);
> + pr_info("hdisplay is %d\n", mode->hdisplay);
> + pr_info("vdisplay is %d\n", mode->vdisplay);
> + pr_info("HSS is %d\n", mode->hsync_start);
> + pr_info("HSE is %d\n", mode->hsync_end);
> + pr_info("htotal is %d\n", mode->htotal);
> + pr_info("VSS is %d\n", mode->vsync_start);
> + pr_info("VSE is %d\n", mode->vsync_end);
> + pr_info("vtotal is %d\n", mode->vtotal);
> + pr_info("clock is %d\n", mode->clock);
>  #endif
>   mode_dev->panel_fixed_mode = mode;
>   }
> diff --git a/drivers/gpu/drm/gma500/psb_drv.h 
> b/drivers/gpu/drm/gma500/psb_drv.h
> index 83e22fd4cfc0..83667087d6e5 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.h
> +++ b/drivers/gpu/drm/gma500/psb_drv.h
> @@ -905,9 +905,8 @@ static inline void REGISTER_WRITE8(struct drm_device *dev,
>  #define PSB_RSGX32(_offs)   

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

2017-02-28 Thread Ben Widawsky

On 17-02-28 12:18:39, Jason Ekstrand wrote:

On Thu, Jan 5, 2017 at 7:14 AM,  wrote:


From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.

Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.

Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.

Also not all planes will be capable of scanning out compressed surfaces,
and eg. 90/270 degree rotation is not supported in combination with
decompression either.

This patch may contain work from at least the following people:
* Vandana Kannan 
* Daniel Vetter 
* Ben Widawsky 

v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)

Cc: Paulo Zanoni 
Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  23 
 drivers/gpu/drm/i915/intel_display.c | 234 ++
++---
 drivers/gpu/drm/i915/intel_pm.c  |  29 -
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 4 files changed, 274 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_
reg.h
index 00970aa77afa..6849ba93f1d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6209,6 +6209,28 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))

+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
_PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
_PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
@@ -6433,6 +6455,7 @@ enum {
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)

 #define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
 #define  DPA_MASK_VBLANK_SRD   (1 << 15)
 #define  FORCE_ARB_IDLE_PLANES (1 << 14)
 #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 38de9df0ec60..2236abebd8bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
drm_framebuffer *fb, int plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   if (plane == 1)
+   return 64;



I've said it before but reading through Ben's patches again make me want to
be peskier about it.  I would really like the UABI to treat 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: PAT: swap UC and WT.

2017-02-28 Thread Patchwork
== Series Details ==

Series: drm/i915: PAT: swap UC and WT.
URL   : https://patchwork.freedesktop.org/series/20418/
State : success

== Summary ==

Series 20418v1 drm/i915: PAT: swap UC and WT.
https://patchwork.freedesktop.org/api/1.0/series/20418/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
c9ac31d drm/i915: PAT: swap UC and WT.

== Logs ==

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


Re: [Intel-gfx] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

2017-02-28 Thread Patrik Jakobsson
On Tue, Feb 28, 2017 at 1:55 PM, Joe Perches  wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches 

For the gma500 changes:

Acked-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  9 -
>  drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
>  drivers/gpu/drm/gma500/psb_drv.h  |  5 ++---
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  7 +++
>  drivers/gpu/drm/i915/i915_sw_fence.c  |  8 
>  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
>  drivers/gpu/drm/msm/msm_drv.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_acpi.c|  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  4 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
>  drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
>  drivers/gpu/drm/omapdrm/dss/dss.c |  3 +--
>  drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
>  drivers/gpu/drm/omapdrm/omap_gem.c|  5 ++---
>  drivers/gpu/drm/r128/r128_cce.c   |  7 +++
>  drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  6 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  3 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  4 ++--
>  20 files changed, 72 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
> head) {
> if (tmp_encoder != encoder
> && tmp_encoder->crtc == encoder->crtc) {
> -   printk(KERN_ERR "Can't enable LVDS and another "
> -  "encoder on the same pipe\n");
> +   pr_err("Can't enable LVDS and another encoder on the 
> same pipe\n");
> return false;
> }
> }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>
>  failed_find:
> mutex_unlock(>mode_config.mutex);
> -   printk(KERN_ERR "Failed find\n");
> +   pr_err("Failed find\n");
> psb_intel_i2c_destroy(gma_encoder->ddc_bus);
>  failed_ddc:
> -   printk(KERN_ERR "Failed DDC\n");
> +   pr_err("Failed DDC\n");
> psb_intel_i2c_destroy(gma_encoder->i2c_bus);
>  failed_blc_i2c:
> -   printk(KERN_ERR "Failed BLC\n");
> +   pr_err("Failed BLC\n");
> drm_encoder_cleanup(encoder);
> drm_connector_cleanup(connector);
> kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct 
> drm_device *dev,
> ((ti->vblank_hi << 8) | ti->vblank_lo);
> mode->clock = ti->pixel_clock * 10;
>  #if 0
> -   printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> -   printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> -   printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> -   printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> -   printk(KERN_INFO "htotal is %d\n", mode->htotal);
> -   printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> -   printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> -   printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> -   printk(KERN_INFO "clock is %d\n", mode->clock);
> +   pr_info("hdisplay is %d\n", mode->hdisplay);
> +   pr_info("vdisplay is %d\n", mode->vdisplay);
> +   pr_info("HSS is %d\n", mode->hsync_start);
> +   pr_info("HSE is %d\n", mode->hsync_end);
> +   pr_info("htotal is %d\n", mode->htotal);
> +   pr_info("VSS is %d\n", mode->vsync_start);
> +   pr_info("VSE is %d\n", mode->vsync_end);
> +   pr_info("vtotal is %d\n", mode->vtotal);
> +   pr_info("clock is %d\n", mode->clock);
>  #endif
> mode_dev->panel_fixed_mode = mode;
> }
> diff --git a/drivers/gpu/drm/gma500/psb_drv.h 
> b/drivers/gpu/drm/gma500/psb_drv.h
> index 83e22fd4cfc0..83667087d6e5 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.h
> +++ b/drivers/gpu/drm/gma500/psb_drv.h
> @@ -905,9 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path

2017-02-28 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Fix all intel_framebuffer_init 
failures to take the error path
URL   : https://patchwork.freedesktop.org/series/20409/
State : success

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#14

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:278  pass:246  dwarn:1   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
fc05620 drm/i915: Fix all intel_framebuffer_init failures to take the error path

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

2017-02-28 Thread Jason Ekstrand
On Thu, Jan 5, 2017 at 7:14 AM,  wrote:

> From: Ville Syrjälä 
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes
> which parts of the main surface are compressed and which are not. The
> location of CCS is provided by userspace as just another plane with its
> own offset.
>
> Add the required stuff to validate the user provided AUX plane metadata
> and convert the user provided linear offset into something the hardware
> can consume.
>
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with NV12), so finding suitable
> offsets for both requires a bit of work. Assuming we still want keep
> playing tricks with the offsets. I've just gone with a dumb "search
> backward for suitable offsets" approach, which is far from optimal,
> but it works.
>
> Also not all planes will be capable of scanning out compressed surfaces,
> and eg. 90/270 degree rotation is not supported in combination with
> decompression either.
>
> This patch may contain work from at least the following people:
> * Vandana Kannan 
> * Daniel Vetter 
> * Ben Widawsky 
>
> v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
>
> Cc: Paulo Zanoni 
> Cc: Vandana Kannan 
> Cc: Daniel Vetter 
> Cc: Ben Widawsky 
> Cc: Jason Ekstrand 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  23 
>  drivers/gpu/drm/i915/intel_display.c | 234 ++
> ++---
>  drivers/gpu/drm/i915/intel_pm.c  |  29 -
>  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
>  4 files changed, 274 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_
> reg.h
> index 00970aa77afa..6849ba93f1d9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6209,6 +6209,28 @@ enum {
> _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
> _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>
> +#define PLANE_AUX_DIST_1_A 0x701c0
> +#define PLANE_AUX_DIST_2_A 0x702c0
> +#define PLANE_AUX_DIST_1_B 0x711c0
> +#define PLANE_AUX_DIST_2_B 0x712c0
> +#define _PLANE_AUX_DIST_1(pipe) \
> +   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
> +#define _PLANE_AUX_DIST_2(pipe) \
> +   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
> +#define PLANE_AUX_DIST(pipe, plane) \
> +   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> _PLANE_AUX_DIST_2(pipe))
> +
> +#define PLANE_AUX_OFFSET_1_A   0x701c4
> +#define PLANE_AUX_OFFSET_2_A   0x702c4
> +#define PLANE_AUX_OFFSET_1_B   0x711c4
> +#define PLANE_AUX_OFFSET_2_B   0x712c4
> +#define _PLANE_AUX_OFFSET_1(pipe)   \
> +   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> +#define _PLANE_AUX_OFFSET_2(pipe)   \
> +   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> +#define PLANE_AUX_OFFSET(pipe, plane)   \
> +   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
> _PLANE_AUX_OFFSET_2(pipe))
> +
>  /* legacy palette */
>  #define _LGC_PALETTE_A   0x4a000
>  #define _LGC_PALETTE_B   0x4a800
> @@ -6433,6 +6455,7 @@ enum {
>  # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
>
>  #define CHICKEN_PAR1_1 _MMIO(0x42080)
> +#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
>  #define  DPA_MASK_VBLANK_SRD   (1 << 15)
>  #define  FORCE_ARB_IDLE_PLANES (1 << 14)
>  #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 38de9df0ec60..2236abebd8bc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
> drm_framebuffer *fb, int plane)
> return 128;
> else
> return 512;
> +   case I915_FORMAT_MOD_Y_TILED_CCS:
> +   if (plane == 1)
> +   return 64;
> +   /* fall through */
> case I915_FORMAT_MOD_Y_TILED:
> if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
> return 128;
> else
> return 512;
> +   case I915_FORMAT_MOD_Yf_TILED_CCS:
> +   if (plane == 1)
> +

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915/gtt: Make I915_PDPES_PER_PDP inline function

2017-02-28 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/gtt: Make I915_PDPES_PER_PDP inline 
function
URL   : https://patchwork.freedesktop.org/series/20405/
State : warning

== Summary ==

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

Test gem_exec_parallel:
Subgroup basic:
pass   -> DMESG-WARN (fi-skl-6700k)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
6d729bfd drm/i915/gtt: Setup vm callbacks late
0e34328 drm/i915: Avoid using word legacy with ppgtt
dd57d6d drm/i915/gtt: Prefer i915_vm_is_48bit() over macro
19b9ac8 drm/i915: Don't mark pdps clear if pdps are not submitted
b36ec89 drm/i915/gtt: Make I915_PDPES_PER_PDP inline function

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4008/
___
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: Tighten mmio arrays for MIPI_PORT

2017-02-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Tighten mmio arrays for MIPI_PORT
URL   : https://patchwork.freedesktop.org/series/20402/
State : success

== Summary ==

Series 20402v1 drm/i915: Tighten mmio arrays for MIPI_PORT
https://patchwork.freedesktop.org/api/1.0/series/20402/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
9e4b700 drm/i915: Tighten mmio arrays for MIPI_PORT

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move updating color management to before vblank evasion

2017-02-28 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Move updating color management to 
before vblank evasion
URL   : https://patchwork.freedesktop.org/series/20399/
State : success

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
skip   -> INCOMPLETE (fi-bsw-n3050) fdo#14

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#14 https://bugs.freedesktop.org/show_bug.cgi?id=14

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:236  pass:201  dwarn:0   dfail:0   fail:0   skip:34 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29 
fi-byt-j1900 failed to collect. IGT log at Patchwork_4006/fi-byt-j1900/igt.log

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
5bced1e drm/i915: Complain if we take too long under vblank evasion.
628d35b drm/i915: Move updating color management to before vblank evasion

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Force uncached PPAT for debugging purposes.

2017-02-28 Thread Vivi, Rodrigo
On Tue, 2017-02-28 at 09:05 +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 05:18:08PM -0800, Ben Widawsky wrote:
> > On 17-02-27 17:12:07, Rodrigo Vivi wrote:
> > >Many screen corruptions and hangs in the past were somehow
> > >related to the caches. In many situations forcing the uncached
> > >was useful at least to narrow down the issue by confirming it
> > >was cache related.
> > >
> > >Instead of having to hardcode it everytime that we suspect on
> > >this table let's provide a mechanism to disable these
> > >cache leves on this private table (PPAT).
> > >
> > >Cc: Ben Widawsky 
> > >Cc: Daniele Ceraolo Spurio 
> > >Signed-off-by: Rodrigo Vivi 
> > 
> > I think this is a cool idea, it could equally be achieved by modifying the 
> > PTE
> > encoding function. In my head, modifying the pte encode makes more sense 
> > since
> > it applies to all legacy context, advanced context, and ggtt entries.
> 
> Changing the mocs table is not the same as changing the PTE. Both are
> useful for different types of bugs.

Indeed.

Although I believe Ben mentioned the pat_sel inside PTE. But if this is
the case I checked here and it seems that it is spread in different
functions here so I believe the simplest and safiest place to do is here
inside the PPAT setup.

> -Chris
> 

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


[Intel-gfx] [RFC] drm/i915: PAT: swap UC and WT.

2017-02-28 Thread Rodrigo Vivi
When trying to understand our PPAT table definition I noticed that
pat_sel is composed by:
PAT - Bit 7 of PTE
PCD - Bit 4 of PTE (Cache disabled)
PWT - Bit 3 of PTE (Write through)

So it seems
010 should indicate Uncached while
011 should indicate Write Through

But we are currently doing
Index 2 WT for scanout with eLLC
Index 3 UC fr uncached objects, mostly for scanout.

This patch shouldn't have any real impact because it just change the
internal mapping PTE to PAT in a way that makes more sense of Mapping
PCD and PWT bits.

Cc: Chris Wilson 
Cc: Ben Widawsky 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index df9f71e..f153cd9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2652,8 +2652,8 @@ static void bdw_setup_private_ppat(struct 
drm_i915_private *dev_priv)
 
pat = GEN8_PPAT(0, GEN8_PPAT_WB | GEN8_PPAT_LLC) | /* for normal 
objects, no eLLC */
  GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) | /* for something 
pointing to ptes? */
- GEN8_PPAT(2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC) | /* for scanout 
with eLLC */
- GEN8_PPAT(3, GEN8_PPAT_UC) | /* Uncached 
objects, mostly for scanout */
+ GEN8_PPAT(2, GEN8_PPAT_UC) | /* Uncached 
objects, mostly for scanout */
+ GEN8_PPAT(3, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC) | /* for scanout 
with eLLC */
  GEN8_PPAT(4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0)) 
|
  GEN8_PPAT(5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1)) 
|
  GEN8_PPAT(6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2)) 
|
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f7d4e19..2d831ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -128,10 +128,10 @@
 #define I915_PDPES_PER_PDP(dev_priv)   (USES_FULL_48BIT_PPGTT(dev_priv) ?\
GEN8_PML4ES_PER_PML4 : 
GEN8_LEGACY_PDPES)
 
-#define PPAT_UNCACHED_INDEX(_PAGE_PWT | _PAGE_PCD)
+#define PPAT_UNCACHED_INDEX_PAGE_PCD
 #define PPAT_CACHED_PDE_INDEX  0 /* WB LLC */
 #define PPAT_CACHED_INDEX  _PAGE_PAT /* WB LLCeLLC */
-#define PPAT_DISPLAY_ELLC_INDEX_PAGE_PCD /* WT eLLC */
+#define PPAT_DISPLAY_ELLC_INDEX(_PAGE_PWT | _PAGE_PCD) /* WT 
eLLC */
 
 #define CHV_PPAT_SNOOP (1<<6)
 #define GEN8_PPAT_AGE(x)   (x<<4)
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

2017-02-28 Thread Rob Clark
On Tue, Feb 28, 2017 at 7:55 AM, Joe Perches  wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches 

for drm/msm part:

Acked-by: Rob Clark 


> ---
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  9 -
>  drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
>  drivers/gpu/drm/gma500/psb_drv.h  |  5 ++---
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  7 +++
>  drivers/gpu/drm/i915/i915_sw_fence.c  |  8 
>  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
>  drivers/gpu/drm/msm/msm_drv.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_acpi.c|  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  4 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
>  drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
>  drivers/gpu/drm/omapdrm/dss/dss.c |  3 +--
>  drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
>  drivers/gpu/drm/omapdrm/omap_gem.c|  5 ++---
>  drivers/gpu/drm/r128/r128_cce.c   |  7 +++
>  drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  6 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  3 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  4 ++--
>  20 files changed, 72 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
> head) {
> if (tmp_encoder != encoder
> && tmp_encoder->crtc == encoder->crtc) {
> -   printk(KERN_ERR "Can't enable LVDS and another "
> -  "encoder on the same pipe\n");
> +   pr_err("Can't enable LVDS and another encoder on the 
> same pipe\n");
> return false;
> }
> }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>
>  failed_find:
> mutex_unlock(>mode_config.mutex);
> -   printk(KERN_ERR "Failed find\n");
> +   pr_err("Failed find\n");
> psb_intel_i2c_destroy(gma_encoder->ddc_bus);
>  failed_ddc:
> -   printk(KERN_ERR "Failed DDC\n");
> +   pr_err("Failed DDC\n");
> psb_intel_i2c_destroy(gma_encoder->i2c_bus);
>  failed_blc_i2c:
> -   printk(KERN_ERR "Failed BLC\n");
> +   pr_err("Failed BLC\n");
> drm_encoder_cleanup(encoder);
> drm_connector_cleanup(connector);
> kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct 
> drm_device *dev,
> ((ti->vblank_hi << 8) | ti->vblank_lo);
> mode->clock = ti->pixel_clock * 10;
>  #if 0
> -   printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> -   printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> -   printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> -   printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> -   printk(KERN_INFO "htotal is %d\n", mode->htotal);
> -   printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> -   printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> -   printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> -   printk(KERN_INFO "clock is %d\n", mode->clock);
> +   pr_info("hdisplay is %d\n", mode->hdisplay);
> +   pr_info("vdisplay is %d\n", mode->vdisplay);
> +   pr_info("HSS is %d\n", mode->hsync_start);
> +   pr_info("HSE is %d\n", mode->hsync_end);
> +   pr_info("htotal is %d\n", mode->htotal);
> +   pr_info("VSS is %d\n", mode->vsync_start);
> +   pr_info("VSE is %d\n", mode->vsync_end);
> +   pr_info("vtotal is %d\n", mode->vtotal);
> +   pr_info("clock is %d\n", mode->clock);
>  #endif
> mode_dev->panel_fixed_mode = mode;
> }
> diff --git a/drivers/gpu/drm/gma500/psb_drv.h 
> b/drivers/gpu/drm/gma500/psb_drv.h
> index 83e22fd4cfc0..83667087d6e5 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.h
> +++ b/drivers/gpu/drm/gma500/psb_drv.h
> @@ -905,9 +905,8 @@ static 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Don't use enums for hardware engine id

2017-02-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Don't use enums for hardware engine id
URL   : https://patchwork.freedesktop.org/series/20396/
State : failure

== Summary ==

Series 20396v1 drm/i915: Don't use enums for hardware engine id
https://patchwork.freedesktop.org/api/1.0/series/20396/revisions/1/mbox/

Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-byt-j1900)
Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> DMESG-FAIL (fi-byt-j1900)
Subgroup nb-await-default:
pass   -> SKIP   (fi-byt-j1900)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-batch-kernel-default-uc:
pass   -> SKIP   (fi-byt-j1900) fdo#14
Subgroup basic-batch-kernel-default-wb:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-uc-pro-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-uc-prw-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-uc-ro-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-uc-rw-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-uc-set-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-wb-pro-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-wb-prw-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-wb-ro-before-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-wb-ro-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-wb-rw-before-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-wb-rw-default:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-wb-set-default:
pass   -> SKIP   (fi-byt-j1900)
Test gem_exec_gttfill:
Subgroup basic:
pass   -> SKIP   (fi-byt-j1900)
Test gem_exec_nop:
Subgroup basic-parallel:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-series:
pass   -> SKIP   (fi-byt-j1900)
Test gem_exec_parallel:
Subgroup basic:
pass   -> SKIP   (fi-byt-j1900)
Test gem_exec_parse:
Subgroup basic-allowed:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-rejected:
pass   -> SKIP   (fi-byt-j1900)
Test gem_exec_reloc:
Subgroup basic-cpu:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-active:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-gtt:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-gtt-active:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-gtt-noreloc:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-noreloc:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-read:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-read-active:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-cpu-read-noreloc:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-active:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-cpu:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-cpu-active:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-cpu-noreloc:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-noreloc:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-read:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-read-active:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-gtt-read-noreloc:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-softpin:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-write-cpu:
pass   -> SKIP   (fi-byt-j1900)
Subgroup basic-write-cpu-active:
WARNING: Long output truncated

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
d0ed15b drm/i915: Don't use enums for hardware engine id

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id

2017-02-28 Thread Michal Wajdeczko
On Tue, Feb 28, 2017 at 04:52:34PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 04:43:02PM +, Chris Wilson wrote:
> > On Tue, Feb 28, 2017 at 02:12:09PM +, Michal Wajdeczko wrote:
> > > +/* Hardware Engine ID definitions */
> > > +#define RCS_HW   0
> > > +#define VCS_HW   1
> > > +#define BCS_HW   2
> > > +#define VECS_HW  3
> > > +#define VCS2_HW  4
> > 
> > So don't put them in the header if they may have inconsistent meanings.
> 
> Or if you do want to keep them in a header, either i915_reg.h or
> intel_engine_reg.h as somewhere out of the way, and clear that they are
> not meant for the rest of the bookkeeping in intel_ringbuffer.h.

I can't find nice spot for these engine IDs in the i915_reg.h

Can I just move these definitions to the top of this header?

There are already some comments/defs that refer to the Bspec,
so it should be clear that they are not the same as enums from
intel_engine_id.

-Michal

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Use BUILD_BUG_ON to detected missing engine definitions
URL   : https://patchwork.freedesktop.org/series/20394/
State : failure

== Summary ==

Series 20394v1 drm/i915: Use BUILD_BUG_ON to detected missing engine definitions
https://patchwork.freedesktop.org/api/1.0/series/20394/revisions/1/mbox/

Test gem_exec_basic:
Subgroup gtt-vebox:
skip   -> INCOMPLETE (fi-byt-j1900)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:36   pass:30   dwarn:0   dfail:0   fail:0   skip:5  
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5d37006b578e38562382215e8782cfced9c992ce drm-tip: 2017y-02m-28d-16h-27m-13s UTC 
integration manifest
ad75ffb drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec

2017-02-28 Thread Bob Paauwe
On Tue, 28 Feb 2017 13:59:16 +0100
Hans de Goede  wrote:

> Document the DSI panel enable / disable sequences from the spec,
> for easy comparison between the code and the spec.
> 
> Signed-off-by: Hans de Goede 
> Acked-by: Jani Nikula 

I think this looks a lot better and makes it more obvious any
differences between the different sequences.  Thanks Hans!

The rest of the patches in this series look good too. So for the series:

Reviewed-by: Bob Paauwe 

> ---
> Changes in v2:
> -Make the comment a table with 3 columns for easier comparison of the
>  3 sequences
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 20ed799..c271475 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -554,6 +554,43 @@ static void intel_dsi_prepare(struct intel_encoder 
> *intel_encoder,
> struct intel_crtc_state *pipe_config);
>  static void intel_dsi_unprepare(struct intel_encoder *encoder);
>  
> +/*
> + * Panel enable/disable sequences from the VBT spec.
> + *
> + * Note the spec has AssertReset / DeassertReset swapped from their
> + * usual naming. We use the normal names to avoid confusion (so below
> + * they are swapped compared to the spec).
> + *
> + * Steps starting with MIPI refer to VBT sequences, note that for v2
> + * VBTs several steps which have a VBT in v2 are expected to be handled
> + * directly by the driver, by directly driving gpios for example.
> + *
> + * v2 video mode seq v3 video mode seq command mode seq
> + * - power on- MIPIPanelPowerOn- power on
> + * - wait t1+t2- wait t1+t2
> + * - MIPIDeassertResetPin- MIPIDeassertResetPin- MIPIDeassertResetPin
> + * - io lines to lp-11   - io lines to lp-11   - io lines to lp-11
> + * - MIPISendInitialDcsCmds  - MIPISendInitialDcsCmds  - 
> MIPISendInitialDcsCmds
> + * - MIPITearOn
> + * - MIPIDisplayOn
> + * - turn on DPI - turn on DPI - set pipe to dsr mode
> + * - MIPIDisplayOn   - MIPIDisplayOn
> + * - wait t5   - wait t5
> + * - backlight on- MIPIBacklightOn - backlight on
> + * ...   ...   ... issue mem cmds ...
> + * - backlight off   - MIPIBacklightOff- backlight off
> + * - wait t6   - wait t6
> + * - MIPIDisplayOff
> + * - turn off DPI- turn off DPI- disable pipe dsr 
> mode
> + * - MIPITearOff
> + *   - MIPIDisplayOff  - MIPIDisplayOff
> + * - io lines to lp-00   - io lines to lp-00   - io lines to lp-00
> + * - MIPIAssertResetPin  - MIPIAssertResetPin  - MIPIAssertResetPin
> + * - wait t3   - wait t3
> + * - power off   - MIPIPanelPowerOff   - power off
> + * - wait t4   - wait t4
> + */
> +
>  static void intel_dsi_pre_enable(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
>struct drm_connector_state *conn_state)



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Use drm_connector_list_iter in debugfs

2017-02-28 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915: Use drm_connector_list_iter in 
debugfs
URL   : https://patchwork.freedesktop.org/series/20392/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

89683de1f9e7f8fb56bf90ad0682c407b7037bf7 drm-tip: 2017y-02m-28d-14h-58m-42s UTC 
integration manifest
4de840c drm/i915: Fix up verify_encoder_state
cb072b6 drm/i915: use for_each_intel_connector_iter in intel_display.c
89553f7 drm/i915: Make intel_get_pipe_from_connector atomic
05d530b drm/i915: use drm_connector_list_iter in intel_opregion.c
ae91ef5 drm/i915: use drm_connector_list_iter in intel_hotplug.c
c3bc0ad drm/i915: Use drm_connector_list_iter in debugfs

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 04:43:02PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 02:12:09PM +, Michal Wajdeczko wrote:
> > +/* Hardware Engine ID definitions */
> > +#define RCS_HW 0
> > +#define VCS_HW 1
> > +#define BCS_HW 2
> > +#define VECS_HW3
> > +#define VCS2_HW4
> 
> So don't put them in the header if they may have inconsistent meanings.

Or if you do want to keep them in a header, either i915_reg.h or
intel_engine_reg.h as somewhere out of the way, and clear that they are
not meant for the rest of the bookkeeping in intel_ringbuffer.h.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 02:12:09PM +, Michal Wajdeczko wrote:
> Generally we are using macros for any hardware identifiers as these
> may change between Gens. Do the same with hardware engine ids.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c  |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 41 
> -
>  2 files changed, 26 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 4db2f23..8df53ae 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -29,7 +29,7 @@
>  static const struct engine_info {
>   const char *name;
>   unsigned exec_id;
> - enum intel_engine_hw_id hw_id;
> + unsigned hw_id;
>   u32 mmio_base;
>   unsigned irq_shift;
>   int (*init_legacy)(struct intel_engine_cs *engine);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 3dd6eee..9cc7863 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -186,26 +186,35 @@ struct i915_ctx_workarounds {
>  struct drm_i915_gem_request;
>  struct intel_render_state;
>  
> +
> +/*
> + * Engine IDs definitions.
> + * Keep instances of the same type engine together.
> + */
> +enum intel_engine_id {
> + RCS = 0,
> + BCS,
> + VCS,
> + VCS2,
> +#define _VCS(n) (VCS + (n))
> + VECS
> +};
> +
> +/* Hardware Engine ID definitions */
> +#define RCS_HW   0
> +#define VCS_HW   1
> +#define BCS_HW   2
> +#define VECS_HW  3
> +#define VCS2_HW  4

So don't put them in the header if they may have inconsistent meanings.
It only a field which we supply to hardware and can simply be defined in
intel_engine_cs.c and treated as an opaque field elsewhere. We will keep
using our own classification (enum engine_id and whatnot) to refer to
the engines in the driver.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Michal Wajdeczko
On Tue, Feb 28, 2017 at 03:08:19PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 03:52:31PM +0100, Michal Wajdeczko wrote:
> > On Tue, Feb 28, 2017 at 02:21:23PM +, Tvrtko Ursulin wrote:
> > > 
> > > On 28/02/2017 14:00, Michal Wajdeczko wrote:
> > > > Additionally use runtime check to catch invalid engine indices.
> > > > 
> > > > Signed-off-by: Michal Wajdeczko 
> > > > Cc: Jani Nikula 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > > > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > index a238304..8df53ae 100644
> > > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > > @@ -89,6 +89,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
> > > > const struct engine_info *info = _engines[id];
> > > > struct intel_engine_cs *engine;
> > > > 
> > > > +   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != I915_NUM_ENGINES);
> > > 
> > > For some reason I feel this is too strict. ;)
> > 
> > It has to be strict to be useful. 
> 
> But is pointless if it doesn't apply to gen+1, or tomorrow's packing of
> sparse engines, which is where Tvrtko is coming from.

But it applies.

It shall still work as each ring bit used by HAS_ENGINE() will likely
still represent single entry in dev_priv->engine[].

As design assumes strong relation between intel_engines[] and dev_priv->engine[]
arrays, we should have some way to validate correctness of that assumption.

Note that this check should help us catch any mistakes that Tvrtko introduces ;)

Unless, there will be full redesign.

-Michal


ps. I'm coming from almost the same place as Tvrtko ;)

___
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: Prevent concurrent tiling/framebuffer modifications

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 04:22:33PM +, Chris Wilson wrote:
> Reintroduce a lock around tiling vs framebuffer creation to prevent
> modification of the obj->tiling_and_stride whilst the framebuffer is
> being created. Rather than use struct_mutex once again, use the
> per-object lock - this will also be required in future to prevent
> changing the tiling whilst submitting rendering.

It also means that we can't create a framebuffer whilst submitting
rendering to/from the object (on this or other device). However, the
gen2/gen3 fence requirement means that we will want some serialisation
between set_tiling_ioctl and execbuffer_ioctl - and so the ww_mutex
still seems apt.
-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] #1: test capitalizing PATCH

2017-02-28 Thread Jani Nikula

Cc: Hans, this probably applies to you as well.

On Tue, 28 Feb 2017, Dan Carpenter  wrote:
> The new version patchwork is filtering out my patches for some reason.
> Test if it's because it now insists on a capital [PATCH] in the subject.
>
> Patchwork should be more version control agnostic than that.

The patchwork flavor at freedesktop.org expects patches are sent using
git send-email [1]. I hear otherwise there were too many false
positives.

Please either use git send-email, or add

X-Mailer: git-send-email haha only kidding

header into your patch mails.

I'm sorry for the inconvenience and lack of transparency on
this. Apparently git send-email is so ubiquitous nowadays that this
hasn't been much of a problem.


BR,
Jani.


[1] 
https://github.com/dlespiau/patchwork/blob/master/patchwork/bin/parsemail.py#L323

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Purge i915_gem_object_is_dead()

2017-02-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Purge i915_gem_object_is_dead()
URL   : https://patchwork.freedesktop.org/series/20380/
State : failure

== Summary ==

Series 20380v1 drm/i915: Purge i915_gem_object_is_dead()
https://patchwork.freedesktop.org/api/1.0/series/20380/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> FAIL   (fi-skl-6770hq) fdo#99787
Subgroup nonblocking-crc-pipe-c:
pass   -> FAIL   (fi-skl-6770hq)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> FAIL   (fi-skl-6770hq) fdo#99788

fdo#99787 https://bugs.freedesktop.org/show_bug.cgi?id=99787
fdo#99788 https://bugs.freedesktop.org/show_bug.cgi?id=99788

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:265  dwarn:0   dfail:0   fail:3   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

89683de1f9e7f8fb56bf90ad0682c407b7037bf7 drm-tip: 2017y-02m-28d-14h-58m-42s UTC 
integration manifest
56d2129 drm/i915: Purge i915_gem_object_is_dead()

== Logs ==

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


[Intel-gfx] [PATCH 2/2] drm/i915: Prevent concurrent tiling/framebuffer modifications

2017-02-28 Thread Chris Wilson
Reintroduce a lock around tiling vs framebuffer creation to prevent
modification of the obj->tiling_and_stride whilst the framebuffer is
being created. Rather than use struct_mutex once again, use the
per-object lock - this will also be required in future to prevent
changing the tiling whilst submitting rendering.

Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the 
framebuffer")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_object.h   | 18 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c   |  9 -
 drivers/gpu/drm/i915/intel_display.c | 25 -
 4 files changed, 42 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index ad1bc0b1a0c2..8c02c8ec2a3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -169,7 +169,7 @@ struct drm_i915_gem_object {
struct reservation_object *resv;
 
/** References from framebuffers, locks out tiling changes. */
-   atomic_t framebuffer_references;
+   unsigned int framebuffer_references;
 
/** Record of address bit 17 of each page at last unbind. */
unsigned long *bit_17;
@@ -263,6 +263,16 @@ extern void drm_gem_object_unreference(struct 
drm_gem_object *);
 __deprecated
 extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *);
 
+static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj)
+{
+   reservation_object_lock(obj->resv, NULL);
+}
+
+static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
+{
+   reservation_object_unlock(obj->resv);
+}
+
 static inline bool
 i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
 {
@@ -303,6 +313,12 @@ i915_gem_object_clear_active_reference(struct 
drm_i915_gem_object *obj)
 
 void __i915_gem_object_release_unless_active(struct drm_i915_gem_object *obj);
 
+static inline bool
+i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj)
+{
+   return READ_ONCE(obj->framebuffer_references);
+}
+
 static inline unsigned int
 i915_gem_object_get_tiling(struct drm_i915_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 7e3bb48e043e..630697001b38 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -210,7 +210,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
 
if (!(flags & I915_SHRINK_ACTIVE) &&
(i915_gem_object_is_active(obj) ||
-atomic_read(>framebuffer_references)))
+i915_gem_object_is_framebuffer(obj)))
continue;
 
if (!can_release_pages(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index c1d669e32f41..ad5e05f6b836 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
if ((tiling | stride) == obj->tiling_and_stride)
return 0;
 
-   if (atomic_read(>framebuffer_references))
+   if (i915_gem_object_is_framebuffer(obj))
return -EBUSY;
 
/* We need to rebind the object if its current allocation
@@ -258,6 +258,12 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
if (err)
return err;
 
+   i915_gem_object_lock(obj);
+   if (i915_gem_object_is_framebuffer(obj)) {
+   i915_gem_object_unlock(obj);
+   return -EBUSY;
+   }
+
/* If the memory has unknown (i.e. varying) swizzling, we pin the
 * pages to prevent them being swapped out and causing corruption
 * due to the change in swizzling.
@@ -294,6 +300,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
}
 
obj->tiling_and_stride = tiling | stride;
+   i915_gem_object_unlock(obj);
 
/* Force the fence to be reacquired for GTT access */
i915_gem_release_mmap(obj);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 77936ddd860a..62a1e628e399 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14255,7 +14255,10 @@ static void intel_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 
drm_framebuffer_cleanup(fb);
 
-   WARN_ON(atomic_dec_return(_fb->obj->framebuffer_references) < 0);
+   i915_gem_object_lock(intel_fb->obj);
+   WARN_ON(!intel_fb->obj->framebuffer_references--);
+   i915_gem_object_unlock(intel_fb->obj);
+
i915_gem_object_put(intel_fb->obj);

[Intel-gfx] [PATCH 1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path

2017-02-28 Thread Chris Wilson
No more direct return -EINVAL as we have to unwind the
obj->framebuffer_references.

Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the 
framebuffer")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 10e68dfb7260..77936ddd860a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14383,7 +14383,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_INFO(dev_priv)->gen < 4 &&
tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
DRM_DEBUG("tiling_mode must match fb modifier exactly on 
gen2/3\n");
-   return -EINVAL;
+   goto err;
}
 
stride_alignment = intel_fb_stride_alignment(dev_priv,
@@ -14428,7 +14428,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_GEN(dev_priv) > 3) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_ABGR:
@@ -14436,7 +14436,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
INTEL_GEN(dev_priv) < 9) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_XBGR:
@@ -14445,14 +14445,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_GEN(dev_priv) < 4) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_ABGR2101010:
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_YUYV:
@@ -14462,13 +14462,13 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_GEN(dev_priv) < 5) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
default:
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
 
/* FIXME need to adjust LINOFF/TILEOFF accordingly. */
@@ -14481,7 +14481,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 
ret = intel_fill_fb_info(dev_priv, _fb->base);
if (ret)
-   return ret;
+   goto err;
 
ret = drm_framebuffer_init(obj->base.dev,
   _fb->base,
-- 
2.11.0

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Implement DDB algorithm and WM cleanup

2017-02-28 Thread Patchwork
== Series Details ==

Series: Implement DDB algorithm and WM cleanup
URL   : https://patchwork.freedesktop.org/series/20376/
State : failure

== Summary ==

Series 20376v1 Implement DDB algorithm and WM cleanup
https://patchwork.freedesktop.org/api/1.0/series/20376/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6770hq) fdo#14
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-skl-6770hq) fdo#14
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> INCOMPLETE (fi-skl-6770hq)

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:196  pass:190  dwarn:2   dfail:0   fail:0   skip:3  
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

89683de1f9e7f8fb56bf90ad0682c407b7037bf7 drm-tip: 2017y-02m-28d-14h-58m-42s UTC 
integration manifest
a21d035 drm/i915/skl+: consider max supported plane pixel rate while scaling
3de7987 drm/i915/skl: New ddb allocation algorithm
05345a5 drm/i915/skl+: Watermark calculation cleanup
4fb432b drm/i915/skl+: ddb min requirement may exceed allocation
37a7a8a drm/i915/skl+: no need to memset again
05e3efc drm/i915/skl: Fail the flip if no FB for WM calculation
d61c0e7 drm/i915/skl+: use linetime latency if ddb size is not available
12d716c drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed point

== Logs ==

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


Re: [Intel-gfx] [PATCH 5/5] drm/i915/gtt: Setup vm callbacks late

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 05:28:11PM +0200, Mika Kuoppala wrote:
> If we manage to tangle errorpaths and get call to callbacks,
> it is better to defensively keep them as null until object init is
> finished so that we get clean null deref on callsite,
> instead of more cryptic wreckage with partly initialized vm objects.

I wouldn't go so far as saying clean; it's a jump to the NULL function
pointer, which can be quite confusing until you realise why you have
such an odd stack frame.

> Signed-off-by: Mika Kuoppala 

Reviewed-by: Chris Wilson 
-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 4/5] drm/i915: Avoid using word legacy with ppgtt

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 05:28:10PM +0200, Mika Kuoppala wrote:
> The term legacy is subjective. Use 3lvl and 4lvl
> where appropriate.
> 
> Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
-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/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over macro

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 05:28:09PM +0200, Mika Kuoppala wrote:
> If we setup the vm size early, we can use the newly introduced
> i915_vm_is_48bit() in majority of callsites wanting to know the vm size.
> 
> As we operate either with 3lvl or 4lvl page table structure,
> wrap the vm size query inside a function which tells us if
> 4lvl setup is needed for particular vm, as the following
> code uses the function names where level is noted.
> 
> v2: use_4lvl (Chris)
> 
> Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
-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/5] drm/i915: Don't mark pdps clear if pdps are not submitted

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 05:28:08PM +0200, Mika Kuoppala wrote:
> Don't mark pdps clear if never do the necessary actions
> with the hardware to make them clear.
> 
> v2: totally get rid of confusing ppgtt bool (Chris)
> 
> Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
-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 1/5] drm/i915/gtt: Make I915_PDPES_PER_PDP inline function

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 05:28:07PM +0200, Mika Kuoppala wrote:
> +static inline unsigned int
> +i915_pdpes_per_pdp(const struct i915_address_space *vm)
> +{
> + if (i915_vm_is_48bit(vm))
> + return GEN8_PML4ES_PER_PML4;
> +
> + return GEN8_LEGACY_PDPES;
> +}

Does this need to be in the header? Isn't it private to i915_gem_ppgtt.c?

>  /* Equivalent to the gen6 version, For each pde iterates over every pde
>   * between from start until start + length. On gen8+ it simply iterates
>   * over every page directory entry in a page directory.
> @@ -471,7 +483,7 @@ static inline u32 gen6_pde_index(u32 addr)
>  
>  #define gen8_for_each_pdpe(pd, pdp, start, length, iter) \
>   for (iter = gen8_pdpe_index(start); \
> -  length > 0 && iter < I915_PDPES_PER_PDP(dev) &&\
> +  length > 0 && iter < i915_pdpes_per_pdp(vm) && \

Oh. Because of a pair of impossible conditions here.

Add rewriting these iterators based on the knowleged that length is
assert to be > 0 and <= total - start to the task list. 

Reviewed-by: Chris Wilson 
-Chris

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


[Intel-gfx] [PATCH 3/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over macro

2017-02-28 Thread Mika Kuoppala
If we setup the vm size early, we can use the newly introduced
i915_vm_is_48bit() in majority of callsites wanting to know the vm size.

As we operate either with 3lvl or 4lvl page table structure,
wrap the vm size query inside a function which tells us if
4lvl setup is needed for particular vm, as the following
code uses the function names where level is noted.

v2: use_4lvl (Chris)

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 63 ++---
 1 file changed, 38 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5299600..9399906 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -548,13 +548,18 @@ static void __pdp_fini(struct i915_page_directory_pointer 
*pdp)
pdp->page_directory = NULL;
 }
 
+static inline bool use_4lvl(const struct i915_address_space *vm)
+{
+   return i915_vm_is_48bit(vm);
+}
+
 static struct i915_page_directory_pointer *
 alloc_pdp(struct i915_address_space *vm)
 {
struct i915_page_directory_pointer *pdp;
int ret = -ENOMEM;
 
-   WARN_ON(!USES_FULL_48BIT_PPGTT(vm->i915));
+   WARN_ON(!use_4lvl(vm));
 
pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
if (!pdp)
@@ -582,10 +587,12 @@ static void free_pdp(struct i915_address_space *vm,
 struct i915_page_directory_pointer *pdp)
 {
__pdp_fini(pdp);
-   if (USES_FULL_48BIT_PPGTT(vm->i915)) {
-   cleanup_px(vm, pdp);
-   kfree(pdp);
-   }
+
+   if (!use_4lvl(vm))
+   return;
+
+   cleanup_px(vm, pdp);
+   kfree(pdp);
 }
 
 static void gen8_initialize_pdp(struct i915_address_space *vm,
@@ -739,7 +746,7 @@ static void gen8_ppgtt_set_pdpe(struct i915_address_space 
*vm,
gen8_ppgtt_pdpe_t *vaddr;
 
pdp->page_directory[pdpe] = pd;
-   if (!USES_FULL_48BIT_PPGTT(vm->i915))
+   if (!use_4lvl(vm))
return;
 
vaddr = kmap_atomic_px(pdp);
@@ -804,7 +811,7 @@ static void gen8_ppgtt_clear_4lvl(struct i915_address_space 
*vm,
struct i915_page_directory_pointer *pdp;
unsigned int pml4e;
 
-   GEM_BUG_ON(!USES_FULL_48BIT_PPGTT(vm->i915));
+   GEM_BUG_ON(!use_4lvl(vm));
 
gen8_for_each_pml4e(pdp, pml4, start, length, pml4e) {
GEM_BUG_ON(pdp == vm->scratch_pdp);
@@ -968,7 +975,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
goto free_pt;
}
 
-   if (USES_FULL_48BIT_PPGTT(dev)) {
+   if (use_4lvl(vm)) {
vm->scratch_pdp = alloc_pdp(vm);
if (IS_ERR(vm->scratch_pdp)) {
ret = PTR_ERR(vm->scratch_pdp);
@@ -978,7 +985,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
 
gen8_initialize_pt(vm, vm->scratch_pt);
gen8_initialize_pd(vm, vm->scratch_pd);
-   if (USES_FULL_48BIT_PPGTT(dev_priv))
+   if (use_4lvl(vm))
gen8_initialize_pdp(vm, vm->scratch_pdp);
 
return 0;
@@ -995,12 +1002,13 @@ static int gen8_init_scratch(struct i915_address_space 
*vm)
 
 static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt *ppgtt, bool create)
 {
+   struct i915_address_space *vm = >base;
+   struct drm_i915_private *dev_priv = vm->i915;
enum vgt_g2v_type msg;
-   struct drm_i915_private *dev_priv = ppgtt->base.i915;
int i;
 
-   if (USES_FULL_48BIT_PPGTT(dev_priv)) {
-   u64 daddr = px_dma(>pml4);
+   if (use_4lvl(vm)) {
+   const u64 daddr = px_dma(>pml4);
 
I915_WRITE(vgtif_reg(pdp[0].lo), lower_32_bits(daddr));
I915_WRITE(vgtif_reg(pdp[0].hi), upper_32_bits(daddr));
@@ -1009,7 +1017,7 @@ static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt 
*ppgtt, bool create)
VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY);
} else {
for (i = 0; i < GEN8_LEGACY_PDPES; i++) {
-   u64 daddr = i915_page_dir_dma_addr(ppgtt, i);
+   const u64 daddr = i915_page_dir_dma_addr(ppgtt, i);
 
I915_WRITE(vgtif_reg(pdp[i].lo), lower_32_bits(daddr));
I915_WRITE(vgtif_reg(pdp[i].hi), upper_32_bits(daddr));
@@ -1026,7 +1034,7 @@ static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt 
*ppgtt, bool create)
 
 static void gen8_free_scratch(struct i915_address_space *vm)
 {
-   if (USES_FULL_48BIT_PPGTT(vm->i915))
+   if (use_4lvl(vm))
free_pdp(vm, vm->scratch_pdp);
free_pd(vm, vm->scratch_pd);
free_pt(vm, vm->scratch_pt);
@@ -1072,10 +1080,10 @@ static void gen8_ppgtt_cleanup(struct 
i915_address_space *vm)
if (intel_vgpu_active(dev_priv))
gen8_ppgtt_notify_vgt(ppgtt, false);
 
-   if (!USES_FULL_48BIT_PPGTT(vm->i915))
-   

[Intel-gfx] [PATCH 5/5] drm/i915/gtt: Setup vm callbacks late

2017-02-28 Thread Mika Kuoppala
If we manage to tangle errorpaths and get call to callbacks,
it is better to defensively keep them as null until object init is
finished so that we get clean null deref on callsite,
instead of more cryptic wreckage with partly initialized vm objects.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9c9a03ee..cee9c4f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1338,11 +1338,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
}
 
-   ppgtt->base.cleanup = gen8_ppgtt_cleanup;
-   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
-   ppgtt->base.bind_vma = ppgtt_bind_vma;
-   ppgtt->debug_dump = gen8_dump_ppgtt;
-
/* There are only few exceptions for gen >=6. chv and bxt.
 * And we are not sure about the latter so play safe for now.
 */
@@ -1382,6 +1377,11 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
if (intel_vgpu_active(dev_priv))
gen8_ppgtt_notify_vgt(ppgtt, true);
 
+   ppgtt->base.cleanup = gen8_ppgtt_cleanup;
+   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
+   ppgtt->base.bind_vma = ppgtt_bind_vma;
+   ppgtt->debug_dump = gen8_dump_ppgtt;
+
return 0;
 
 free_scratch:
@@ -1808,13 +1808,7 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
if (ret)
return ret;
 
-   ppgtt->base.clear_range = gen6_ppgtt_clear_range;
-   ppgtt->base.insert_entries = gen6_ppgtt_insert_entries;
-   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
-   ppgtt->base.bind_vma = ppgtt_bind_vma;
-   ppgtt->base.cleanup = gen6_ppgtt_cleanup;
ppgtt->base.total = I915_PDES * GEN6_PTES * PAGE_SIZE;
-   ppgtt->debug_dump = gen6_dump_ppgtt;
 
gen6_scratch_va_range(ppgtt, 0, ppgtt->base.total);
gen6_write_page_range(ppgtt, 0, ppgtt->base.total);
@@ -1825,6 +1819,13 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
}
 
+   ppgtt->base.clear_range = gen6_ppgtt_clear_range;
+   ppgtt->base.insert_entries = gen6_ppgtt_insert_entries;
+   ppgtt->base.unbind_vma = ppgtt_unbind_vma;
+   ppgtt->base.bind_vma = ppgtt_bind_vma;
+   ppgtt->base.cleanup = gen6_ppgtt_cleanup;
+   ppgtt->debug_dump = gen6_dump_ppgtt;
+
DRM_DEBUG_DRIVER("Allocated pde space (%lldM) at GTT entry: %llx\n",
 ppgtt->node.size >> 20,
 ppgtt->node.start / PAGE_SIZE);
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/5] drm/i915/gtt: Make I915_PDPES_PER_PDP inline function

2017-02-28 Thread Mika Kuoppala
The macro takes a vm pointer at some sites, and dev_priv on others
We were saved as the internal macro never deferences the pointer
given.

As the number of pdpes depend on vm configuration, make it
as a inline function that accepts vm pointer.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.h | 26 --
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e0c9542..5299600 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -528,7 +528,7 @@ static void gen8_initialize_pd(struct i915_address_space 
*vm,
 static int __pdp_init(struct i915_address_space *vm,
  struct i915_page_directory_pointer *pdp)
 {
-   const unsigned int pdpes = I915_PDPES_PER_PDP(vm->i915);
+   const unsigned int pdpes = i915_pdpes_per_pdp(vm);
unsigned int i;
 
pdp->page_directory = kmalloc_array(pdpes, sizeof(*pdp->page_directory),
@@ -852,7 +852,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
gen8_pte_t *vaddr;
bool ret;
 
-   GEM_BUG_ON(idx->pdpe >= I915_PDPES_PER_PDP(vm));
+   GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(>base));
pd = pdp->page_directory[idx->pdpe];
vaddr = kmap_atomic_px(pd->page_table[idx->pde]);
do {
@@ -883,7 +883,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
break;
}
 
-   GEM_BUG_ON(idx->pdpe >= I915_PDPES_PER_PDP(vm));
+   GEM_BUG_ON(idx->pdpe >= 
i915_pdpes_per_pdp(>base));
pd = pdp->page_directory[idx->pdpe];
}
 
@@ -1036,9 +1036,10 @@ static void gen8_free_scratch(struct i915_address_space 
*vm)
 static void gen8_ppgtt_cleanup_3lvl(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp)
 {
+   const unsigned int pdpes = i915_pdpes_per_pdp(vm);
int i;
 
-   for (i = 0; i < I915_PDPES_PER_PDP(vm->i915); i++) {
+   for (i = 0; i < pdpes; i++) {
if (pdp->page_directory[i] == vm->scratch_pd)
continue;
 
@@ -1127,7 +1128,7 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space 
*vm,
gen8_initialize_pd(vm, pd);
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
pdp->used_pdpes++;
-   GEM_BUG_ON(pdp->used_pdpes > I915_PDPES_PER_PDP(vm));
+   GEM_BUG_ON(pdp->used_pdpes > i915_pdpes_per_pdp(vm));
 
mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
}
@@ -1201,6 +1202,7 @@ static void gen8_dump_pdp(struct i915_hw_ppgtt *ppgtt,
  gen8_pte_t scratch_pte,
  struct seq_file *m)
 {
+   struct i915_address_space *vm = >base;
struct i915_page_directory *pd;
u32 pdpe;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f7d4e19..562c632 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -125,9 +125,6 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define GEN8_LEGACY_PDPES  4
 #define GEN8_PTES  I915_PTES(sizeof(gen8_pte_t))
 
-#define I915_PDPES_PER_PDP(dev_priv)   (USES_FULL_48BIT_PPGTT(dev_priv) ?\
-   GEN8_PML4ES_PER_PML4 : 
GEN8_LEGACY_PDPES)
-
 #define PPAT_UNCACHED_INDEX(_PAGE_PWT | _PAGE_PCD)
 #define PPAT_CACHED_PDE_INDEX  0 /* WB LLC */
 #define PPAT_CACHED_INDEX  _PAGE_PAT /* WB LLCeLLC */
@@ -332,6 +329,12 @@ struct i915_address_space {
 
 #define i915_is_ggtt(V) (!(V)->file)
 
+static inline bool
+i915_vm_is_48bit(const struct i915_address_space *vm)
+{
+   return (vm->total - 1) >> 32;
+}
+
 /* The Graphics Translation Table is the way in which GEN hardware translates a
  * Graphics Virtual Address into a Physical Address. In addition to the normal
  * collateral associated with any va->pa translations GEN hardware also has a
@@ -457,6 +460,15 @@ static inline u32 gen6_pde_index(u32 addr)
return i915_pde_index(addr, GEN6_PDE_SHIFT);
 }
 
+static inline unsigned int
+i915_pdpes_per_pdp(const struct i915_address_space *vm)
+{
+   if (i915_vm_is_48bit(vm))
+   return GEN8_PML4ES_PER_PML4;
+
+   return GEN8_LEGACY_PDPES;
+}
+
 /* Equivalent to the gen6 version, For each pde iterates over every pde
  * between from start until start + length. On gen8+ it simply iterates
  * over every page directory entry in a page directory.
@@ -471,7 +483,7 @@ static inline u32 gen6_pde_index(u32 addr)
 
 #define 

[Intel-gfx] [PATCH 2/5] drm/i915: Don't mark pdps clear if pdps are not submitted

2017-02-28 Thread Mika Kuoppala
Don't mark pdps clear if never do the necessary actions
with the hardware to make them clear.

v2: totally get rid of confusing ppgtt bool (Chris)

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f9a8545..4ae9f1f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1319,9 +1319,8 @@ static int intel_logical_ring_emit_pdps(struct 
drm_i915_gem_request *req)
 
 static int gen8_emit_bb_start(struct drm_i915_gem_request *req,
  u64 offset, u32 len,
- unsigned int dispatch_flags)
+ const unsigned int flags)
 {
-   bool ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
u32 *cs;
int ret;
 
@@ -1332,13 +1331,12 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
 * not idle). PML4 is allocated during ppgtt init so this is
 * not needed in 48-bit.*/
if (req->ctx->ppgtt &&
-   (intel_engine_flag(req->engine) & req->ctx->ppgtt->pd_dirty_rings)) 
{
-   if (!i915_vm_is_48bit(>ctx->ppgtt->base) &&
-   !intel_vgpu_active(req->i915)) {
-   ret = intel_logical_ring_emit_pdps(req);
-   if (ret)
-   return ret;
-   }
+   (intel_engine_flag(req->engine) & req->ctx->ppgtt->pd_dirty_rings) 
&&
+   !i915_vm_is_48bit(>ctx->ppgtt->base) &&
+   !intel_vgpu_active(req->i915)) {
+   ret = intel_logical_ring_emit_pdps(req);
+   if (ret)
+   return ret;
 
req->ctx->ppgtt->pd_dirty_rings &= 
~intel_engine_flag(req->engine);
}
@@ -1348,8 +1346,9 @@ static int gen8_emit_bb_start(struct drm_i915_gem_request 
*req,
return PTR_ERR(cs);
 
/* FIXME(BDW): Address space and security selectors. */
-   *cs++ = MI_BATCH_BUFFER_START_GEN8 | (ppgtt << 8) | (dispatch_flags &
-   I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0);
+   *cs++ = MI_BATCH_BUFFER_START_GEN8 |
+   (flags & I915_DISPATCH_SECURE ? 0 : BIT(8)) |
+   (flags & I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0);
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
*cs++ = MI_NOOP;
-- 
2.7.4

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


[Intel-gfx] [PATCH 4/5] drm/i915: Avoid using word legacy with ppgtt

2017-02-28 Thread Mika Kuoppala
The term legacy is subjective. Use 3lvl and 4lvl
where appropriate.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 18 --
 drivers/gpu/drm/i915/i915_gem_gtt.h | 21 +++--
 drivers/gpu/drm/i915/intel_lrc.c|  4 ++--
 3 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9399906..9c9a03ee 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -641,12 +641,12 @@ static int gen8_write_pdp(struct drm_i915_gem_request 
*req,
return 0;
 }
 
-static int gen8_legacy_mm_switch(struct i915_hw_ppgtt *ppgtt,
-struct drm_i915_gem_request *req)
+static int gen8_mm_switch_3lvl(struct i915_hw_ppgtt *ppgtt,
+  struct drm_i915_gem_request *req)
 {
int i, ret;
 
-   for (i = GEN8_LEGACY_PDPES - 1; i >= 0; i--) {
+   for (i = GEN8_3LVL_PDPES - 1; i >= 0; i--) {
const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
 
ret = gen8_write_pdp(req, i, pd_daddr);
@@ -657,8 +657,8 @@ static int gen8_legacy_mm_switch(struct i915_hw_ppgtt 
*ppgtt,
return 0;
 }
 
-static int gen8_48b_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct drm_i915_gem_request *req)
+static int gen8_mm_switch_4lvl(struct i915_hw_ppgtt *ppgtt,
+  struct drm_i915_gem_request *req)
 {
return gen8_write_pdp(req, 0, px_dma(>pml4));
 }
@@ -1016,7 +1016,7 @@ static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt 
*ppgtt, bool create)
msg = (create ? VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE :
VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY);
} else {
-   for (i = 0; i < GEN8_LEGACY_PDPES; i++) {
+   for (i = 0; i < GEN8_3LVL_PDPES; i++) {
const u64 daddr = i915_page_dir_dma_addr(ppgtt, i);
 
I915_WRITE(vgtif_reg(pdp[i].lo), lower_32_bits(daddr));
@@ -1356,8 +1356,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
 
gen8_initialize_pml4(>base, >pml4);
 
-   ppgtt->switch_mm = gen8_48b_mm_switch;
-
+   ppgtt->switch_mm = gen8_mm_switch_4lvl;
ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl;
@@ -1366,8 +1365,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
if (ret)
goto free_scratch;
 
-   ppgtt->switch_mm = gen8_legacy_mm_switch;
-
if (intel_vgpu_active(dev_priv)) {
ret = gen8_preallocate_top_level_pdp(ppgtt);
if (ret) {
@@ -1376,6 +1373,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
}
}
 
+   ppgtt->switch_mm = gen8_mm_switch_3lvl;
ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_3lvl;
ppgtt->base.insert_entries = gen8_ppgtt_insert_3lvl;
ppgtt->base.clear_range = gen8_ppgtt_clear_3lvl;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 562c632..fb15684 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -101,13 +101,20 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define HSW_GTT_ADDR_ENCODE(addr)  ((addr) | (((addr) >> 28) & 0x7f0))
 #define HSW_PTE_ADDR_ENCODE(addr)  HSW_GTT_ADDR_ENCODE(addr)
 
-/* GEN8 legacy style address is defined as a 3 level page table:
+/* GEN8 32b style address is defined as a 3 level page table:
  * 31:30 | 29:21 | 20:12 |  11:0
  * PDPE  |  PDE  |  PTE  | offset
  * The difference as compared to normal x86 3 level page table is the PDPEs are
  * programmed via register.
- *
- * GEN8 48b legacy style address is defined as a 4 level page table:
+ */
+#define GEN8_3LVL_PDPES4
+#define GEN8_PDE_SHIFT 21
+#define GEN8_PDE_MASK  0x1ff
+#define GEN8_PTE_SHIFT 12
+#define GEN8_PTE_MASK  0x1ff
+#define GEN8_PTES  I915_PTES(sizeof(gen8_pte_t))
+
+/* GEN8 48b style address is defined as a 4 level page table:
  * 47:39 | 38:30 | 29:21 | 20:12 |  11:0
  * PML4E | PDPE  |  PDE  |  PTE  | offset
  */
@@ -118,12 +125,6 @@ typedef u64 gen8_ppgtt_pml4e_t;
 /* NB: GEN8_PDPE_MASK is untrue for 32b platforms, but it has no impact on 32b 
page
  * tables */
 #define GEN8_PDPE_MASK 0x1ff
-#define GEN8_PDE_SHIFT 21
-#define GEN8_PDE_MASK  0x1ff
-#define GEN8_PTE_SHIFT 12
-#define GEN8_PTE_MASK  0x1ff
-#define GEN8_LEGACY_PDPES  4
-#define 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/3] HAX enable guc submission for CI

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 02:48:25PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v5,1/3] HAX enable guc submission for CI
> URL   : https://patchwork.freedesktop.org/series/20375/
> State : success
> 
> == Summary ==
> 
> Series 20375v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20375/revisions/1/mbox/
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 
> 
> cbeef675410c1628969ac5396d751ff44a541a81 drm-tip: 2017y-02m-28d-13h-53m-02s 
> UTC integration manifest
> 1485f0f drm/i915/guc: Reorder __i915_guc_submit to reduce spinlock holdtime
> 46e04ea drm/i915/guc: Make wq_lock irq-safe

Applied this pair and now back to wondering about bxt.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 03:52:31PM +0100, Michal Wajdeczko wrote:
> On Tue, Feb 28, 2017 at 02:21:23PM +, Tvrtko Ursulin wrote:
> > 
> > On 28/02/2017 14:00, Michal Wajdeczko wrote:
> > > Additionally use runtime check to catch invalid engine indices.
> > > 
> > > Signed-off-by: Michal Wajdeczko 
> > > Cc: Jani Nikula 
> > > ---
> > >  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > index a238304..8df53ae 100644
> > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > @@ -89,6 +89,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
> > >   const struct engine_info *info = _engines[id];
> > >   struct intel_engine_cs *engine;
> > > 
> > > + BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != I915_NUM_ENGINES);
> > 
> > For some reason I feel this is too strict. ;)
> 
> It has to be strict to be useful. 

But is pointless if it doesn't apply to gen+1, or tomorrow's packing of
sparse engines, which is where Tvrtko is coming from.
-Chris

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


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Tvrtko Ursulin


On 28/02/2017 14:52, Michal Wajdeczko wrote:

On Tue, Feb 28, 2017 at 02:21:23PM +, Tvrtko Ursulin wrote:


[snip]


+   GEM_BUG_ON(id < 0 || id >= I915_NUM_ENGINES);


The caller of this function iterates 0..ARRAY_SIZE(intel_engines) and also
filters with HAS_ENGINE before calling it so not sure this is absolutely
needed. Maybe instead:

GEM_BUG_ON(id >= ARRAY_SIZE(dev_priv->engine));



With your approach we could drop GEM_BUG_ON completely as with correct
iteration we should never hit condition id > ARRAY_SIZE.

>
> If we could assume that everyone is doing right, then we should never
> need any asserts at all.

That is not correct. I suggested the function should just check the size 
of the array it is concerned with, rather than assuming how 
I915_NUM_ENGINES relates to the same array.



Problem is that this function does not know anything about the caller.
And also it does not know if enums were defined correctly.
But then it uses these enums as index into two external arrays.
In my opition we should do our best to catch any inproper usage/definitions.
If not everywhere, then at least once during build or boot.


Agreed, but intel_engine_setup does not care about the enum so much. It 
cares that it doesn't do out of bounds access to the two arrays. In the 
light of that, GEM_BUG_ON(id >= ARRAY_SIZE(intel_engines) || id >= 
ARRAY_SIZE(dev_priv->engines)) sounds like the most robust solution to me.


Since the function handles failure as well, perhaps we could even 
upgrade that to a WARN_ON and return -EINVAL. Not sure.


Regards,

Tvrtko
___
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: Remove duplicate DDI enabling logic from MST path

2017-02-28 Thread Ville Syrjälä
On Tue, Feb 28, 2017 at 04:47:51PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 28, 2017 at 04:33:46PM +0200, Imre Deak wrote:
> > On Tue, Feb 28, 2017 at 04:09:31PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 28, 2017 at 03:59:52PM +0200, Imre Deak wrote:
> > > > On Tue, Feb 28, 2017 at 09:21:13AM +0200, Ander Conselvan de Oliveira 
> > > > wrote:
> > > > > The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
> > > > > the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
> > > > > by calling the post_disable hook on the intel_dig_port instead of
> > > >  ^pre_enable
> > > > > duplicating that code.
> > > > > 
> > > > > Cc: Ville Syrjälä 
> > > > > Signed-off-by: Ander Conselvan de Oliveira 
> > > > > 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_ddi.c|  2 ++
> > > > >  drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
> > > > >  2 files changed, 5 insertions(+), 20 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > index e9013f1..71aaddf 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > @@ -1695,6 +1695,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > > > intel_encoder *encoder,
> > > > >   enum port port = intel_ddi_get_encoder_port(encoder);
> > > > >   struct intel_digital_port *dig_port = 
> > > > > enc_to_dig_port(>base);
> > > > >  
> > > > > + WARN_ON(link_mst && port == PORT_A);
> > > > > +
> > > > 
> > > > So IIUC, this wasn't used before for MST and so link_mst was always
> > > > false.
> > > 
> > > The MST code explicitly passes 'true' here.
> > 
> > Yes, after the change.
> 
> It was 'true' before. After the change it'll be 'intel_crtc_has_type(MST)'

Ahem. So I thought we were talking about intel_dp_set_link_params(), but
really this was about intel_ddi_pre_enable_dp(). So yes, you're correct
that intel_ddi_pre_enable_dp() was not actually used for MST.

> 
> > I was just wondering why this wasn't used for MST
> > before.
> > 
> > > 
> > > > Also link_mst=true implies type == INTEL_OUTPUT_DP, as this will
> > > > be called for the primary encoder. After the change crtc->config will be
> > > > used instead of the (new) pipe_config, but this is fine since the two
> > > > are the same in the enable hooks.
> > > 
> > > Nope. AFAICS this should explode totally since encoder->crtc for the
> > > primary will be NULL. I guess Maarten didn't yet nuke all crtc->config
> > > usage from the ddi code (or he did but the patches didn't get reviewed).
> > 
> > Err, right. So this would need first changing to use crtc->config to
> > pipe_config in intel_ddi_pre_enable.
> 
> + review all the code that gets called from there to make sure no more
> users are lurking somewhere deeper.
> 
> > 
> > --Imre
> > 
> > > 
> > > > Looks ok to me:
> > > > 
> > > > Reviewed-by: Imre Deak 
> > > > 
> > > > >   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> > > > >link_mst);
> > > > >   if (encoder->type == INTEL_OUTPUT_EDP)
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > > index a8334e1..094cbdc 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > > @@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct 
> > > > > intel_encoder *encoder,
> > > > >  
> > > > >   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > > > >  
> > > > > - if (intel_dp->active_mst_links == 0) {
> > > > > - intel_ddi_clk_select(_dig_port->base,
> > > > > -  pipe_config->shared_dpll);
> > > > > -
> > > > > - intel_display_power_get(dev_priv,
> > > > > - 
> > > > > intel_dig_port->ddi_io_power_domain);
> > > > > -
> > > > > - intel_prepare_dp_ddi_buffers(_dig_port->base);
> > > > > - intel_dp_set_link_params(intel_dp,
> > > > > -  pipe_config->port_clock,
> > > > > -  pipe_config->lane_count,
> > > > > -  true);
> > > > > -
> > > > > - intel_ddi_init_dp_buf_reg(_dig_port->base);
> > > > > -
> > > > > - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > > > -
> > > > > - intel_dp_start_link_train(intel_dp);
> > > > > - intel_dp_stop_link_train(intel_dp);
> > > > > - }
> > > > > + if (intel_dp->active_mst_links == 0)
> > > > > + intel_dig_port->base.pre_enable(_dig_port->base,
> > > > > + pipe_config, NULL);
> > > > >  
> > > > >   ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
> > > > 

Re: [Intel-gfx] 4.11-rc0, thinkpad x220: GPU hang

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 03:34:53PM +0100, Pavel Machek wrote:
> Hi!
> 
> mplayer stopped working after a while. Dmesg says:
> 
> [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
> usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5
> [ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium
> [4597], reason: Hang on render ring, action: reset
> [ 3190.767311] [drm] GPU hangs can indicate a bug anywhere in the
> entire gfx stack, including userspace.
> [ 3190.767313] [drm] Please file a _new_ bug report on
> bugs.freedesktop.org against DRI -> DRM/Intel
> [ 3190.767315] [drm] drm/i915 developers can then reassign to the
> right component if it's not a kernel issue.
> [ 3190.767317] [drm] The gpu crash dump is required to analyze gpu
> hangs, so please always attach it.
> [ 3190.767320] [drm] GPU crash dump saved to
> /sys/class/drm/card0/error
> [ 3190.767427] drm/i915: Resetting chip after gpu hang
> [ 3228.329384] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been
> dropped
> [ 3228.329604] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been
> dropped
> [ 3877.246261] perf: interrupt took too long (3142 > 3133), lowering
> kernel.perf_event_max_sample_rate to 63500
> [ 4802.784478] drm/i915: Resetting chip after gpu hang
> [ 4810.784851] drm/i915: Resetting chip after gpu hang
> [ 4829.829795] drm/i915: Resetting chip after gpu hang
> [ 4837.826154] drm/i915: Resetting chip after gpu hang
> [ 5125.026814] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308257 end=308258) time 203 us, min 763, max
> 767, scanline start 761, end 771
> [ 5125.192602] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe B (start=307385 end=307386) time 204 us, min 1073, max
> 1079, scanline start 1071, end 1086
> [ 5125.309992] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308274 end=308275) time 203 us, min 763, max
> 767, scanline start 758, end 768
> [ 5125.460013] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308283 end=308284) time 204 us, min 763, max
> 767, scanline start 761, end 771
> [ 5125.493340] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308285 end=308286) time 202 us, min 763, max
> 767, scanline start 761, end 771
> [ 5125.526684] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308287 end=308288) time 204 us, min 763, max
> 767, scanline start 762, end 772
> [ 5125.593245] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308291 end=308292) time 203 us, min 763, max
> 767, scanline start 758, end 768
> [ 5125.676636] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308296 end=308297) time 202 us, min 763, max
> 767, scanline start 762, end 772
> [ 5125.709960] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308298 end=308299) time 203 us, min 763, max
> 767, scanline start 762, end 772
> [ 5126.093109] [drm:intel_pipe_update_end] *ERROR* Atomic update
> failure on pipe A (start=308321 end=308322) time 204 us, min 763, max
> 767, scanline start 759, end 770
> [ 5647.879171] drm/i915: Resetting chip after gpu hang
> [ 5655.879507] drm/i915: Resetting chip after gpu hang
> [ 5850.864464] drm/i915: Resetting chip after gpu hang
> [ 5858.864853] drm/i915: Resetting chip after gpu hang
> [ 5904.850879] drm/i915: Resetting chip after gpu hang
> [ 5912.851252] drm/i915: Resetting chip after gpu hang
> [ 5949.876973] drm/i915: Resetting chip after gpu hang
> [ 5957.877460] drm/i915: Resetting chip after gpu hang
> [ 6018.872153] drm/i915: Resetting chip after gpu hang
> [ 6030.872646] drm/i915: Resetting chip after gpu hang
> [ 7108.362610] perf: interrupt took too long (3935 > 3927), lowering
> kernel.perf_event_max_sample_rate to 50750
> [ 9670.047072] drm/i915: Resetting chip after gpu hang
> [ 9678.047415] drm/i915: Resetting chip after gpu hang
> [10408.064806] drm/i915: Resetting chip after gpu hang
> [10416.097168] drm/i915: Resetting chip after gpu hang
> [10416.097181] [drm:i915_reset] *ERROR* GPU recovery failed
> pavel@duo:/data/film$
> 
> Umm. Dmesg wants me to attach card0/error, but it looks like it
> contains quite a lot of data. If it contains actual framebuffer
> content, it may not be wise to post to mailing list

It contains command and register states. No pixel data unless userspace
got particularly creative with its memory corruption.
-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 1/2] drm/i915: Move updating color management to before vblank evasion

2017-02-28 Thread Ville Syrjälä
On Tue, Feb 28, 2017 at 03:28:47PM +0100, Maarten Lankhorst wrote:
> This cannot be done reliably during vblank evasasion
> since the color management registers are not double buffered.
> 
> The original commit that moved it always during vblank evasion was
> wrong, so revert it to before vblank evasion again.
> 
> Signed-off-by: Maarten Lankhorst 
> Fixes: 20a34e78f0d7 ("drm/i915: Update color management during vblank 
> evasion.")
> Cc: sta...@vger.kernel.org # v4.7+

Wasn't there a bugzilla + tested-by ?

> ---
>  drivers/gpu/drm/i915/intel_display.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3c862d0ab389..a0108041fd4a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13301,17 +13301,19 @@ static void intel_begin_crtc_commit(struct drm_crtc 
> *crtc,
>   to_intel_atomic_state(old_crtc_state->state);
>   bool modeset = needs_modeset(crtc->state);
>  
> + if (!modeset &&
> + (intel_cstate->base.color_mgmt_changed ||
> +  intel_cstate->update_pipe)) {
> + intel_color_set_csc(crtc->state);
> + intel_color_load_luts(crtc->state);
> + }
> +
>   /* Perform vblank evasion around commit operation */
>   intel_pipe_update_start(intel_crtc);
>  
>   if (modeset)
>   goto out;
>  
> - if (crtc->state->color_mgmt_changed || 
> to_intel_crtc_state(crtc->state)->update_pipe) {
> - intel_color_set_csc(crtc->state);
> - intel_color_load_luts(crtc->state);
> - }
> -
>   if (intel_cstate->update_pipe)
>   intel_update_pipe_config(intel_crtc, old_intel_cstate);
>   else if (INTEL_GEN(dev_priv) >= 9)
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH] drm/i915: Tighten mmio arrays for MIPI_PORT

2017-02-28 Thread Jani Nikula
On Tue, 28 Feb 2017, Chris Wilson  wrote:
> drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’:
> drivers/gpu/drm/i915/intel_dsi.c:1308:1: error: the frame size of 2488 bytes 
> is larger than 2048 bytes [-Werror=frame-larger-than=]
>
> which is caused by the compiling expanding every _MIPI_PORT into an
> on-stack array of u32[3] at every callsite. Not sure why only one
> machine/compiler appears susceptible, but with a minor tweak to _MIPI_PORT
> we can defer the error until later.
>
> This is a partial revert of commit ce64645d86ac ("drm/i915: use variadic
> macros and arrays to choose port/pipe based registers") for a particular
> bad offender.
>
> Signed-off-by: Chris Wilson 
> Cc: Jani Nikula 

:(

Acked-by: Jani Nikula 



> ---
>  drivers/gpu/drm/i915/i915_reg.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 93dcbbccb740..4906ce4d3a5d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8264,7 +8264,7 @@ enum {
>  
>  /* MIPI DSI registers */
>  
> -#define _MIPI_PORT(port, a, c)   _PORT3(port, a, 0, c)   /* ports A and 
> C only */
> +#define _MIPI_PORT(port, a, c)   ((port) ? c : a)/* ports A and 
> C only */
>  #define _MMIO_MIPI(port, a, c)   _MMIO(_MIPI_PORT(port, a, c))
>  
>  #define MIPIO_TXESC_CLK_DIV1 _MMIO(0x160004)

-- 
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: Tighten mmio arrays for MIPI_PORT

2017-02-28 Thread Chris Wilson
drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’:
drivers/gpu/drm/i915/intel_dsi.c:1308:1: error: the frame size of 2488 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]

which is caused by the compiling expanding every _MIPI_PORT into an
on-stack array of u32[3] at every callsite. Not sure why only one
machine/compiler appears susceptible, but with a minor tweak to _MIPI_PORT
we can defer the error until later.

This is a partial revert of commit ce64645d86ac ("drm/i915: use variadic
macros and arrays to choose port/pipe based registers") for a particular
bad offender.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 93dcbbccb740..4906ce4d3a5d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8264,7 +8264,7 @@ enum {
 
 /* MIPI DSI registers */
 
-#define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
+#define _MIPI_PORT(port, a, c) ((port) ? c : a)/* ports A and C only */
 #define _MMIO_MIPI(port, a, c) _MMIO(_MIPI_PORT(port, a, c))
 
 #define MIPIO_TXESC_CLK_DIV1   _MMIO(0x160004)
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Michal Wajdeczko
On Tue, Feb 28, 2017 at 02:21:23PM +, Tvrtko Ursulin wrote:
> 
> On 28/02/2017 14:00, Michal Wajdeczko wrote:
> > Additionally use runtime check to catch invalid engine indices.
> > 
> > Signed-off-by: Michal Wajdeczko 
> > Cc: Jani Nikula 
> > ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index a238304..8df53ae 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -89,6 +89,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
> > const struct engine_info *info = _engines[id];
> > struct intel_engine_cs *engine;
> > 
> > +   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != I915_NUM_ENGINES);
> 
> For some reason I feel this is too strict. ;)

It has to be strict to be useful. 


> 
> > +   GEM_BUG_ON(id < 0 || id >= I915_NUM_ENGINES);
> 
> The caller of this function iterates 0..ARRAY_SIZE(intel_engines) and also
> filters with HAS_ENGINE before calling it so not sure this is absolutely
> needed. Maybe instead:
> 
> GEM_BUG_ON(id >= ARRAY_SIZE(dev_priv->engine));
> 

With your approach we could drop GEM_BUG_ON completely as with correct
iteration we should never hit condition id > ARRAY_SIZE.

If we could assume that everyone is doing right, then we should never
need any asserts at all.

Problem is that this function does not know anything about the caller.
And also it does not know if enums were defined correctly.
But then it uses these enums as index into two external arrays.
In my opition we should do our best to catch any inproper usage/definitions.
If not everywhere, then at least once during build or boot.

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/3] HAX enable guc submission for CI

2017-02-28 Thread Patchwork
== Series Details ==

Series: series starting with [v5,1/3] HAX enable guc submission for CI
URL   : https://patchwork.freedesktop.org/series/20375/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

cbeef675410c1628969ac5396d751ff44a541a81 drm-tip: 2017y-02m-28d-13h-53m-02s UTC 
integration manifest
1485f0f drm/i915/guc: Reorder __i915_guc_submit to reduce spinlock holdtime
46e04ea drm/i915/guc: Make wq_lock irq-safe
5c33c9f HAX enable guc submission for CI

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4000/
___
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: Remove duplicate DDI enabling logic from MST path

2017-02-28 Thread Ville Syrjälä
On Tue, Feb 28, 2017 at 04:33:46PM +0200, Imre Deak wrote:
> On Tue, Feb 28, 2017 at 04:09:31PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 28, 2017 at 03:59:52PM +0200, Imre Deak wrote:
> > > On Tue, Feb 28, 2017 at 09:21:13AM +0200, Ander Conselvan de Oliveira 
> > > wrote:
> > > > The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
> > > > the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
> > > > by calling the post_disable hook on the intel_dig_port instead of
> > >  ^pre_enable
> > > > duplicating that code.
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: Ander Conselvan de Oliveira 
> > > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_ddi.c|  2 ++
> > > >  drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
> > > >  2 files changed, 5 insertions(+), 20 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index e9013f1..71aaddf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -1695,6 +1695,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > > intel_encoder *encoder,
> > > > enum port port = intel_ddi_get_encoder_port(encoder);
> > > > struct intel_digital_port *dig_port = 
> > > > enc_to_dig_port(>base);
> > > >  
> > > > +   WARN_ON(link_mst && port == PORT_A);
> > > > +
> > > 
> > > So IIUC, this wasn't used before for MST and so link_mst was always
> > > false.
> > 
> > The MST code explicitly passes 'true' here.
> 
> Yes, after the change.

It was 'true' before. After the change it'll be 'intel_crtc_has_type(MST)'

> I was just wondering why this wasn't used for MST
> before.
> 
> > 
> > > Also link_mst=true implies type == INTEL_OUTPUT_DP, as this will
> > > be called for the primary encoder. After the change crtc->config will be
> > > used instead of the (new) pipe_config, but this is fine since the two
> > > are the same in the enable hooks.
> > 
> > Nope. AFAICS this should explode totally since encoder->crtc for the
> > primary will be NULL. I guess Maarten didn't yet nuke all crtc->config
> > usage from the ddi code (or he did but the patches didn't get reviewed).
> 
> Err, right. So this would need first changing to use crtc->config to
> pipe_config in intel_ddi_pre_enable.

+ review all the code that gets called from there to make sure no more
users are lurking somewhere deeper.

> 
> --Imre
> 
> > 
> > > Looks ok to me:
> > > 
> > > Reviewed-by: Imre Deak 
> > > 
> > > > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> > > >  link_mst);
> > > > if (encoder->type == INTEL_OUTPUT_EDP)
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > index a8334e1..094cbdc 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > @@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct 
> > > > intel_encoder *encoder,
> > > >  
> > > > DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > > >  
> > > > -   if (intel_dp->active_mst_links == 0) {
> > > > -   intel_ddi_clk_select(_dig_port->base,
> > > > -pipe_config->shared_dpll);
> > > > -
> > > > -   intel_display_power_get(dev_priv,
> > > > -   
> > > > intel_dig_port->ddi_io_power_domain);
> > > > -
> > > > -   intel_prepare_dp_ddi_buffers(_dig_port->base);
> > > > -   intel_dp_set_link_params(intel_dp,
> > > > -pipe_config->port_clock,
> > > > -pipe_config->lane_count,
> > > > -true);
> > > > -
> > > > -   intel_ddi_init_dp_buf_reg(_dig_port->base);
> > > > -
> > > > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > > -
> > > > -   intel_dp_start_link_train(intel_dp);
> > > > -   intel_dp_stop_link_train(intel_dp);
> > > > -   }
> > > > +   if (intel_dp->active_mst_links == 0)
> > > > +   intel_dig_port->base.pre_enable(_dig_port->base,
> > > > +   pipe_config, NULL);
> > > >  
> > > > ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
> > > >connector->port,
> > > > -- 
> > > > 2.9.3
> > > > 
> > > > ___
> > > > 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
> > > 

[Intel-gfx] 4.11-rc0, thinkpad x220: GPU hang

2017-02-28 Thread Pavel Machek
Hi!

mplayer stopped working after a while. Dmesg says:

[ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5
[ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium
[4597], reason: Hang on render ring, action: reset
[ 3190.767311] [drm] GPU hangs can indicate a bug anywhere in the
entire gfx stack, including userspace.
[ 3190.767313] [drm] Please file a _new_ bug report on
bugs.freedesktop.org against DRI -> DRM/Intel
[ 3190.767315] [drm] drm/i915 developers can then reassign to the
right component if it's not a kernel issue.
[ 3190.767317] [drm] The gpu crash dump is required to analyze gpu
hangs, so please always attach it.
[ 3190.767320] [drm] GPU crash dump saved to
/sys/class/drm/card0/error
[ 3190.767427] drm/i915: Resetting chip after gpu hang
[ 3228.329384] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been
dropped
[ 3228.329604] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been
dropped
[ 3877.246261] perf: interrupt took too long (3142 > 3133), lowering
kernel.perf_event_max_sample_rate to 63500
[ 4802.784478] drm/i915: Resetting chip after gpu hang
[ 4810.784851] drm/i915: Resetting chip after gpu hang
[ 4829.829795] drm/i915: Resetting chip after gpu hang
[ 4837.826154] drm/i915: Resetting chip after gpu hang
[ 5125.026814] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308257 end=308258) time 203 us, min 763, max
767, scanline start 761, end 771
[ 5125.192602] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe B (start=307385 end=307386) time 204 us, min 1073, max
1079, scanline start 1071, end 1086
[ 5125.309992] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308274 end=308275) time 203 us, min 763, max
767, scanline start 758, end 768
[ 5125.460013] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308283 end=308284) time 204 us, min 763, max
767, scanline start 761, end 771
[ 5125.493340] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308285 end=308286) time 202 us, min 763, max
767, scanline start 761, end 771
[ 5125.526684] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308287 end=308288) time 204 us, min 763, max
767, scanline start 762, end 772
[ 5125.593245] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308291 end=308292) time 203 us, min 763, max
767, scanline start 758, end 768
[ 5125.676636] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308296 end=308297) time 202 us, min 763, max
767, scanline start 762, end 772
[ 5125.709960] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308298 end=308299) time 203 us, min 763, max
767, scanline start 762, end 772
[ 5126.093109] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308321 end=308322) time 204 us, min 763, max
767, scanline start 759, end 770
[ 5647.879171] drm/i915: Resetting chip after gpu hang
[ 5655.879507] drm/i915: Resetting chip after gpu hang
[ 5850.864464] drm/i915: Resetting chip after gpu hang
[ 5858.864853] drm/i915: Resetting chip after gpu hang
[ 5904.850879] drm/i915: Resetting chip after gpu hang
[ 5912.851252] drm/i915: Resetting chip after gpu hang
[ 5949.876973] drm/i915: Resetting chip after gpu hang
[ 5957.877460] drm/i915: Resetting chip after gpu hang
[ 6018.872153] drm/i915: Resetting chip after gpu hang
[ 6030.872646] drm/i915: Resetting chip after gpu hang
[ 7108.362610] perf: interrupt took too long (3935 > 3927), lowering
kernel.perf_event_max_sample_rate to 50750
[ 9670.047072] drm/i915: Resetting chip after gpu hang
[ 9678.047415] drm/i915: Resetting chip after gpu hang
[10408.064806] drm/i915: Resetting chip after gpu hang
[10416.097168] drm/i915: Resetting chip after gpu hang
[10416.097181] [drm:i915_reset] *ERROR* GPU recovery failed
pavel@duo:/data/film$

Umm. Dmesg wants me to attach card0/error, but it looks like it
contains quite a lot of data. If it contains actual framebuffer
content, it may not be wise to post to mailing list

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
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: Remove duplicate DDI enabling logic from MST path

2017-02-28 Thread Imre Deak
On Tue, Feb 28, 2017 at 04:09:31PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 28, 2017 at 03:59:52PM +0200, Imre Deak wrote:
> > On Tue, Feb 28, 2017 at 09:21:13AM +0200, Ander Conselvan de Oliveira wrote:
> > > The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
> > > the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
> > > by calling the post_disable hook on the intel_dig_port instead of
> >  ^pre_enable
> > > duplicating that code.
> > > 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Ander Conselvan de Oliveira 
> > > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c|  2 ++
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
> > >  2 files changed, 5 insertions(+), 20 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index e9013f1..71aaddf 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1695,6 +1695,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > intel_encoder *encoder,
> > >   enum port port = intel_ddi_get_encoder_port(encoder);
> > >   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> > >  
> > > + WARN_ON(link_mst && port == PORT_A);
> > > +
> > 
> > So IIUC, this wasn't used before for MST and so link_mst was always
> > false.
> 
> The MST code explicitly passes 'true' here.

Yes, after the change. I was just wondering why this wasn't used for MST
before.

> 
> > Also link_mst=true implies type == INTEL_OUTPUT_DP, as this will
> > be called for the primary encoder. After the change crtc->config will be
> > used instead of the (new) pipe_config, but this is fine since the two
> > are the same in the enable hooks.
> 
> Nope. AFAICS this should explode totally since encoder->crtc for the
> primary will be NULL. I guess Maarten didn't yet nuke all crtc->config
> usage from the ddi code (or he did but the patches didn't get reviewed).

Err, right. So this would need first changing to use crtc->config to
pipe_config in intel_ddi_pre_enable.

--Imre

> 
> > Looks ok to me:
> > 
> > Reviewed-by: Imre Deak 
> > 
> > >   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> > >link_mst);
> > >   if (encoder->type == INTEL_OUTPUT_EDP)
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index a8334e1..094cbdc 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct 
> > > intel_encoder *encoder,
> > >  
> > >   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> > >  
> > > - if (intel_dp->active_mst_links == 0) {
> > > - intel_ddi_clk_select(_dig_port->base,
> > > -  pipe_config->shared_dpll);
> > > -
> > > - intel_display_power_get(dev_priv,
> > > - intel_dig_port->ddi_io_power_domain);
> > > -
> > > - intel_prepare_dp_ddi_buffers(_dig_port->base);
> > > - intel_dp_set_link_params(intel_dp,
> > > -  pipe_config->port_clock,
> > > -  pipe_config->lane_count,
> > > -  true);
> > > -
> > > - intel_ddi_init_dp_buf_reg(_dig_port->base);
> > > -
> > > - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > -
> > > - intel_dp_start_link_train(intel_dp);
> > > - intel_dp_stop_link_train(intel_dp);
> > > - }
> > > + if (intel_dp->active_mst_links == 0)
> > > + intel_dig_port->base.pre_enable(_dig_port->base,
> > > + pipe_config, NULL);
> > >  
> > >   ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
> > >  connector->port,
> > > -- 
> > > 2.9.3
> > > 
> > > ___
> > > 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
> 
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Joonas Lahtinen
On ti, 2017-02-28 at 14:21 +, Tvrtko Ursulin wrote:
> The caller of this function iterates 0..ARRAY_SIZE(intel_engines) and 
> also filters with HAS_ENGINE before calling it so not sure this is 
> absolutely needed. Maybe instead:
> 
> GEM_BUG_ON(id >= ARRAY_SIZE(dev_priv->engine));

I think that's even better.

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: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Michal Wajdeczko
On Tue, Feb 28, 2017 at 02:12:59PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 02:00:50PM +, Michal Wajdeczko wrote:
> > Additionally use runtime check to catch invalid engine indices.
> 
> Oh no you don't!

We can skip it, but today there is no way to verify that our enums fits
into [0..I915_NUM_ENGINES) range.

Additionally, you've moved definition of the I915_NUM_ENGINES to
separate file far away from enum intel_engine_id definition.


>  
> > Signed-off-by: Michal Wajdeczko 
> > Cc: Jani Nikula 
> > ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index a238304..8df53ae 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -89,6 +89,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
> > const struct engine_info *info = _engines[id];
> > struct intel_engine_cs *engine;
> >  
> > +   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != I915_NUM_ENGINES);
> > +   GEM_BUG_ON(id < 0 || id >= I915_NUM_ENGINES);
> 
> Are you sure sparse/smatch won't complain?
> /me too lazy to check the C standard for signedness of an enum without a
> negative value.

enums are int's and as such can be negative ;)
see http://en.cppreference.com/w/c/language/enum

-Michal

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


[Intel-gfx] [PATCH 1/2] drm/i915: Move updating color management to before vblank evasion

2017-02-28 Thread Maarten Lankhorst
This cannot be done reliably during vblank evasasion
since the color management registers are not double buffered.

The original commit that moved it always during vblank evasion was
wrong, so revert it to before vblank evasion again.

Signed-off-by: Maarten Lankhorst 
Fixes: 20a34e78f0d7 ("drm/i915: Update color management during vblank evasion.")
Cc: sta...@vger.kernel.org # v4.7+
---
 drivers/gpu/drm/i915/intel_display.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3c862d0ab389..a0108041fd4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13301,17 +13301,19 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
to_intel_atomic_state(old_crtc_state->state);
bool modeset = needs_modeset(crtc->state);
 
+   if (!modeset &&
+   (intel_cstate->base.color_mgmt_changed ||
+intel_cstate->update_pipe)) {
+   intel_color_set_csc(crtc->state);
+   intel_color_load_luts(crtc->state);
+   }
+
/* Perform vblank evasion around commit operation */
intel_pipe_update_start(intel_crtc);
 
if (modeset)
goto out;
 
-   if (crtc->state->color_mgmt_changed || 
to_intel_crtc_state(crtc->state)->update_pipe) {
-   intel_color_set_csc(crtc->state);
-   intel_color_load_luts(crtc->state);
-   }
-
if (intel_cstate->update_pipe)
intel_update_pipe_config(intel_crtc, old_intel_cstate);
else if (INTEL_GEN(dev_priv) >= 9)
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/2] drm/i915: Complain if we take too long under vblank evasion.

2017-02-28 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 27e0752d1578..375ca91b308c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -65,6 +65,8 @@ int intel_usecs_to_scanlines(const struct drm_display_mode 
*adjusted_mode,
1000 * adjusted_mode->crtc_htotal);
 }
 
+#define VBLANK_EVASION_TIME_US 100
+
 /**
  * intel_pipe_update_start() - start update of a set of display registers
  * @crtc: the crtc of which the registers are going to be updated
@@ -92,7 +94,8 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
vblank_start = DIV_ROUND_UP(vblank_start, 2);
 
/* FIXME needs to be calibrated sensibly */
-   min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, 100);
+   min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
+ VBLANK_EVASION_TIME_US);
max = vblank_start - 1;
 
local_irq_disable();
@@ -191,7 +194,12 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct 
intel_flip_work *work
  ktime_us_delta(end_vbl_time, 
crtc->debug.start_vbl_time),
  crtc->debug.min_vbl, crtc->debug.max_vbl,
  crtc->debug.scanline_start, scanline_end);
-   }
+   } else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
+  VBLANK_EVASION_TIME_US)
+   DRM_WARN("Atomic update on pipe (%c) took %lld us, max time 
under evasion is %u us\n",
+pipe_name(pipe),
+ktime_us_delta(end_vbl_time, 
crtc->debug.start_vbl_time),
+VBLANK_EVASION_TIME_US);
 }
 
 static void
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Tvrtko Ursulin


On 28/02/2017 14:00, Michal Wajdeczko wrote:

Additionally use runtime check to catch invalid engine indices.

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

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a238304..8df53ae 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -89,6 +89,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
const struct engine_info *info = _engines[id];
struct intel_engine_cs *engine;

+   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != I915_NUM_ENGINES);


For some reason I feel this is too strict. ;)


+   GEM_BUG_ON(id < 0 || id >= I915_NUM_ENGINES);


The caller of this function iterates 0..ARRAY_SIZE(intel_engines) and 
also filters with HAS_ENGINE before calling it so not sure this is 
absolutely needed. Maybe instead:


GEM_BUG_ON(id >= ARRAY_SIZE(dev_priv->engine));

?


GEM_BUG_ON(dev_priv->engine[id]);
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
if (!engine)



Regards,

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


Re: [Intel-gfx] [PATCH] drm/i915: Avoiding recursing on ww_mutex inside shrinker

2017-02-28 Thread Joonas Lahtinen
On ma, 2017-02-27 at 22:39 +, Chris Wilson wrote:
> We have to avoid taking ww_mutex inside the shrinker as we use it as a
> plain mutex type and so need to avoid recursive deadlocks:
> 
> [  602.771969] =
> [  602.771970] [ INFO: inconsistent lock state ]
> [  602.771973] 4.10.0gpudebug+ #122 Not tainted
> [  602.771974] -
> [  602.771975] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
> [  602.771978] kswapd0/40 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [  602.771979]  (reservation_ww_class_mutex){+.+.?.}, at: 
> [] i915_gem_object_wait+0x39a/0x410 [i915]
> [  602.772020] {RECLAIM_FS-ON-W} state was registered at:
> [  602.772024]   mark_held_locks+0x76/0x90
> [  602.772026]   lockdep_trace_alloc+0xb8/0xc0
> [  602.772028]   __kmalloc_track_caller+0x5d/0x130
> [  602.772031]   krealloc+0x89/0xb0
> [  602.772033]   reservation_object_reserve_shared+0xaf/0xd0
> [  602.772055]   i915_gem_do_execbuffer.isra.35+0x1413/0x18b0 [i915]
> [  602.772075]   i915_gem_execbuffer2+0x10e/0x1d0 [i915]
> [  602.772078]   drm_ioctl+0x291/0x480
> [  602.772079]   do_vfs_ioctl+0x695/0x6f0
> [  602.772081]   SyS_ioctl+0x3c/0x70
> [  602.772084]   entry_SYSCALL_64_fastpath+0x18/0xad
> [  602.772085] irq event stamp: 5197423
> [  602.772088] hardirqs last  enabled at (5197423): [] 
> kfree+0xdd/0x170
> [  602.772091] hardirqs last disabled at (5197422): [] 
> kfree+0xb9/0x170
> [  602.772095] softirqs last  enabled at (5190992): [] 
> __do_softirq+0x221/0x280
> [  602.772097] softirqs last disabled at (5190575): [] 
> irq_exit+0x64/0xc0
> [  602.772099]
>    other info that might help us debug this:
> [  602.772100]  Possible unsafe locking scenario:
> 
> [  602.772101]CPU0
> [  602.772101]
> [  602.772102]   lock(reservation_ww_class_mutex);
> [  602.772104]   
> [  602.772105] lock(reservation_ww_class_mutex);
> [  602.772107]
> *** DEADLOCK ***
> 
> [  602.772109] 2 locks held by kswapd0/40:
> [  602.772110]  #0:  (shrinker_rwsem){..}, at: [] 
> shrink_slab.constprop.62+0x35/0x280
> [  602.772116]  #1:  (>struct_mutex){+.+.+.}, at: [] 
> i915_gem_shrinker_lock+0x27/0x60 [i915]
> [  602.772141]
>    stack backtrace:
> [  602.772144] CPU: 2 PID: 40 Comm: kswapd0 Not tainted 4.10.0gpudebug+ #122
> [  602.772145] Hardware name: LENOVO 42433ZG/42433ZG, BIOS 8AET64WW (1.44 ) 
> 07/26/2013
> [  602.772147] Call Trace:
> [  602.772151]  dump_stack+0x68/0xa1
> [  602.772153]  print_usage_bug+0x1d4/0x1f0
> [  602.772155]  mark_lock+0x390/0x530
> [  602.772157]  ? print_irq_inversion_bug+0x200/0x200
> [  602.772159]  __lock_acquire+0x405/0x1260
> [  602.772181]  ? i915_gem_object_wait+0x39a/0x410 [i915]
> [  602.772183]  lock_acquire+0x60/0x80
> [  602.772205]  ? i915_gem_object_wait+0x39a/0x410 [i915]
> [  602.772207]  mutex_lock_nested+0x69/0x760
> [  602.772229]  ? i915_gem_object_wait+0x39a/0x410 [i915]
> [  602.772231]  ? kfree+0xdd/0x170
> [  602.772253]  ? i915_gem_object_wait+0x163/0x410 [i915]
> [  602.772255]  ? trace_hardirqs_on_caller+0x18d/0x1c0
> [  602.772256]  ? trace_hardirqs_on+0xd/0x10
> [  602.772278]  i915_gem_object_wait+0x39a/0x410 [i915]
> [  602.772300]  i915_gem_object_unbind+0x5e/0x130 [i915]
> [  602.772323]  i915_gem_shrink+0x22d/0x3d0 [i915]
> [  602.772347]  i915_gem_shrinker_scan+0x3f/0x80 [i915]
> [  602.772349]  shrink_slab.constprop.62+0x1ad/0x280
> [  602.772352]  shrink_node+0x52/0x80
> [  602.772355]  kswapd+0x427/0x5c0
> [  602.772358]  kthread+0x122/0x130
> [  602.772360]  ? try_to_free_pages+0x270/0x270
> [  602.772362]  ? kthread_stop+0x70/0x70
> [  602.772365]  ret_from_fork+0x2e/0x40
> 
> Reported-by: Jan Nordholz 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99977#c10
> Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Matthew Auld 



> @@ -466,10 +466,11 @@ i915_gem_object_wait_reservation(struct 
> reservation_object *resv,
>   dma_fence_put(excl);
> 

Make a comment here that this pruning is opportunistic only.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

>   if (prune_fences && !__read_seqcount_retry(>seq, seq)) {
> - reservation_object_lock(resv, NULL);
> - if (!__read_seqcount_retry(>seq, seq))
> - reservation_object_add_excl_fence(resv, NULL);
> - reservation_object_unlock(resv);
> + if (reservation_object_trylock(resv)) {
> + if (!__read_seqcount_retry(>seq, seq))
> + reservation_object_add_excl_fence(resv, NULL);
> + reservation_object_unlock(resv);
> + }
>   }
>  
>   return timeout;
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 02:12:59PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 02:00:50PM +, Michal Wajdeczko wrote:
> > Additionally use runtime check to catch invalid engine indices.
> 
> Oh no you don't!

Parse error on my part, GEM_BUG_ON didn't register as runtime.
Conditionally runtime!
-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/15] drm/i915: Copy user requested buffers into the error state

2017-02-28 Thread Joonas Lahtinen
On to, 2017-02-23 at 16:18 +, Chris Wilson wrote:
> Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
> use to indicate that it wants the contents of this buffer preserved in
> the error state (/sys/class/drm/cardN/error) following a GPU hang
> involving this batch.
> 
> Use this at your discretion, the contents of the error state. although
> compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
> eternity (until the error state is destroyed).
> 
> Based on an earlier patch by Ben Widawsky 
> Signed-off-by: Chris Wilson 
> Cc: Ben Widawsky 
> Cc: Matt Turner 

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 2/2] drm/i915: Remove duplicate DDI enabling logic from MST path

2017-02-28 Thread Ville Syrjälä
On Tue, Feb 28, 2017 at 03:59:52PM +0200, Imre Deak wrote:
> On Tue, Feb 28, 2017 at 09:21:13AM +0200, Ander Conselvan de Oliveira wrote:
> > The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
> > the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
> > by calling the post_disable hook on the intel_dig_port instead of
>  ^pre_enable
> > duplicating that code.
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Ander Conselvan de Oliveira 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c|  2 ++
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
> >  2 files changed, 5 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index e9013f1..71aaddf 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1695,6 +1695,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> >  
> > +   WARN_ON(link_mst && port == PORT_A);
> > +
> 
> So IIUC, this wasn't used before for MST and so link_mst was always
> false.

The MST code explicitly passes 'true' here.

> Also link_mst=true implies type == INTEL_OUTPUT_DP, as this will
> be called for the primary encoder. After the change crtc->config will be
> used instead of the (new) pipe_config, but this is fine since the two
> are the same in the enable hooks.

Nope. AFAICS this should explode totally since encoder->crtc for the
primary will be NULL. I guess Maarten didn't yet nuke all crtc->config
usage from the ddi code (or he did but the patches didn't get reviewed).

> Looks ok to me:
> 
> Reviewed-by: Imre Deak 
> 
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >  link_mst);
> > if (encoder->type == INTEL_OUTPUT_EDP)
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index a8334e1..094cbdc 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct 
> > intel_encoder *encoder,
> >  
> > DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> >  
> > -   if (intel_dp->active_mst_links == 0) {
> > -   intel_ddi_clk_select(_dig_port->base,
> > -pipe_config->shared_dpll);
> > -
> > -   intel_display_power_get(dev_priv,
> > -   intel_dig_port->ddi_io_power_domain);
> > -
> > -   intel_prepare_dp_ddi_buffers(_dig_port->base);
> > -   intel_dp_set_link_params(intel_dp,
> > -pipe_config->port_clock,
> > -pipe_config->lane_count,
> > -true);
> > -
> > -   intel_ddi_init_dp_buf_reg(_dig_port->base);
> > -
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > -
> > -   intel_dp_start_link_train(intel_dp);
> > -   intel_dp_stop_link_train(intel_dp);
> > -   }
> > +   if (intel_dp->active_mst_links == 0)
> > +   intel_dig_port->base.pre_enable(_dig_port->base,
> > +   pipe_config, NULL);
> >  
> > ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
> >connector->port,
> > -- 
> > 2.9.3
> > 
> > ___
> > 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

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


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 02:00:50PM +, Michal Wajdeczko wrote:
> Additionally use runtime check to catch invalid engine indices.

Oh no you don't!
 
> Signed-off-by: Michal Wajdeczko 
> Cc: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index a238304..8df53ae 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -89,6 +89,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
>   const struct engine_info *info = _engines[id];
>   struct intel_engine_cs *engine;
>  
> + BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != I915_NUM_ENGINES);
> + GEM_BUG_ON(id < 0 || id >= I915_NUM_ENGINES);

Are you sure sparse/smatch won't complain?
/me too lazy to check the C standard for signedness of an enum without a
negative value.
-Chris

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


[Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id

2017-02-28 Thread Michal Wajdeczko
Generally we are using macros for any hardware identifiers as these
may change between Gens. Do the same with hardware engine ids.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h | 41 -
 2 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4db2f23..8df53ae 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -29,7 +29,7 @@
 static const struct engine_info {
const char *name;
unsigned exec_id;
-   enum intel_engine_hw_id hw_id;
+   unsigned hw_id;
u32 mmio_base;
unsigned irq_shift;
int (*init_legacy)(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3dd6eee..9cc7863 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -186,26 +186,35 @@ struct i915_ctx_workarounds {
 struct drm_i915_gem_request;
 struct intel_render_state;
 
+
+/*
+ * Engine IDs definitions.
+ * Keep instances of the same type engine together.
+ */
+enum intel_engine_id {
+   RCS = 0,
+   BCS,
+   VCS,
+   VCS2,
+#define _VCS(n) (VCS + (n))
+   VECS
+};
+
+/* Hardware Engine ID definitions */
+#define RCS_HW 0
+#define VCS_HW 1
+#define BCS_HW 2
+#define VECS_HW3
+#define VCS2_HW4
+
+
 struct intel_engine_cs {
struct drm_i915_private *i915;
const char  *name;
-   enum intel_engine_id {
-   RCS = 0,
-   BCS,
-   VCS,
-   VCS2,   /* Keep instances of the same type engine together. */
-   VECS
-   } id;
-#define _VCS(n) (VCS + (n))
+   enum intel_engine_id id;
unsigned int exec_id;
-   enum intel_engine_hw_id {
-   RCS_HW = 0,
-   VCS_HW,
-   BCS_HW,
-   VECS_HW,
-   VCS2_HW
-   } hw_id;
-   enum intel_engine_hw_id guc_id; /* XXX same as hw_id? */
+   unsigned int hw_id;
+   unsigned int guc_id;
u32 mmio_base;
unsigned int irq_shift;
struct intel_ring *buffer;
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH] drm/i915: use BUILD_BUG_ON to ensure platform name has been set up

2017-02-28 Thread Jani Nikula
On Tue, 28 Feb 2017, Joonas Lahtinen  wrote:
> On ti, 2017-02-28 at 13:11 +0200, Jani Nikula wrote:
>> Leave the runtime check in place in case the platform variable itself
>> comes from bogus sources.
>> 
>> Signed-off-by: Jani Nikula 
>
> 
>
>> @@ -890,6 +890,7 @@ enum intel_platform {
>>  INTEL_BROXTON,
>>  INTEL_KABYLAKE,
>>  INTEL_GEMINILAKE,
>> +INTEL_MAX_PLATFORMS
>>  };
>
> Easily confused to be be off by one, INTEL_MAX_PLATFORMS =
> INTEL_GEMINILAKE, so I suggest changing it to INTEL_NUM_PLATFORMS which
> is explicit.

...and wrong. INTEL_MAX_PLATFORMS is not the same as number of supported
platforms.

BR,
Jani.




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


Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Joonas Lahtinen
On ti, 2017-02-28 at 14:00 +, Michal Wajdeczko wrote:
> Additionally use runtime check to catch invalid engine indices.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Jani Nikula 

Reviewed-by: Joonas Lahtinen 

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


[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

2017-02-28 Thread Michal Wajdeczko
Additionally use runtime check to catch invalid engine indices.

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

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a238304..8df53ae 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -89,6 +89,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
const struct engine_info *info = _engines[id];
struct intel_engine_cs *engine;
 
+   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != I915_NUM_ENGINES);
+   GEM_BUG_ON(id < 0 || id >= I915_NUM_ENGINES);
GEM_BUG_ON(dev_priv->engine[id]);
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
if (!engine)
-- 
2.7.4

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Try to fix MST regression with DDI IO power domains

2017-02-28 Thread Ander Conselvan De Oliveira
On Tue, 2017-02-28 at 07:53 +, Patchwork wrote:
> == Series Details ==
> 
> Series: Try to fix MST regression with DDI IO power domains
> URL   : https://patchwork.freedesktop.org/series/20345/
> State : failure
> 
> == Summary ==
> 
> Series 20345v1 Try to fix MST regression with DDI IO power domains
> https://patchwork.freedesktop.org/api/1.0/series/20345/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600)

I filed a bug for this one, it happened a couple of times in the past CI rounds.

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


> Test gem_exec_parallel:
> Subgroup basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)

I'm not sure what to make of this:

[  276.628178] BUG: spinlock already unlocked on CPU#6, gem_exec_parall/6632
[  276.628185]  lock: 0x8801a0f53220, .magic: dead4ead, .owner: /-1, 
.owner_cpu: -1
[  276.628190] CPU: 6 PID: 6632 Comm: gem_exec_parall Not tainted 
4.10.0-CI-Patchwork_3992+ #1
[  276.628193] Hardware name: TOSHIBA SATELLITE P50-C/06F4  
  , BIOS 1.20 10/08/2015
[  276.628197] Call Trace:
[  276.628198]  
[  276.628202]  dump_stack+0x67/0x92
[  276.628205]  spin_dump+0x73/0xc0
[  276.628208]  do_raw_spin_unlock+0x79/0xb0
[  276.628212]  _raw_spin_unlock_irqrestore+0x27/0x60
[  276.628216]  dma_fence_signal+0x160/0x230
[  276.628242]  notify_ring+0xae/0x2e0 [i915]
[  276.628255]  ? ibx_hpd_irq_handler+0xc0/0xc0 [i915]
[  276.628269]  gen8_gt_irq_handler+0x219/0x290 [i915]
[  276.628283]  gen8_irq_handler+0x8e/0x6b0 [i915]
[  276.628286]  __handle_irq_event_percpu+0x58/0x370
[  276.628289]  handle_irq_event_percpu+0x1e/0x50
[  276.628292]  handle_irq_event+0x34/0x60
[  276.628294]  handle_edge_irq+0xbe/0x150
[  276.628299]  handle_irq+0x15/0x20
[  276.628302]  do_IRQ+0x63/0x130
[  276.628306]  common_interrupt+0x90/0x90
[  276.628310] RIP: 0010:osq_lock+0x77/0x110
[  276.628313] RSP: 0018:c90009113a80 EFLAGS: 0246 ORIG_RAX: 
ffad
[  276.628318] RAX:  RBX: 880281d98d40 RCX: 88022181d758
[  276.628322] RDX: 88022181cf40 RSI: 81c65a58 RDI: 81c73840
[  276.628325] RBP: c90009113a98 R08: 3f352d81 R09: 3e2d9cbd
[  276.628329] R10: 0001 R11: 0001 R12: 880281c18d40
[  276.628333] R13: 88026ab400b0 R14:  R15: 88026ab40070
[  276.628336]  
[  276.628340]  mutex_optimistic_spin+0xf4/0x2a0
[  276.628343]  ? mutex_optimistic_spin+0x39/0x2a0
[  276.628362]  ? i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628366]  mutex_lock_interruptible_nested+0xa9/0x920
[  276.628399]  ? i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628416]  ? i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628433]  i915_mutex_lock_interruptible+0x39/0x140 [i915]
[  276.628437]  ? __pm_runtime_resume+0x56/0x80
[  276.628453]  i915_gem_do_execbuffer.isra.15+0x419/0x1ba0 [i915]
[  276.628457]  ? __lock_acquire+0x449/0x1b50
[  276.628461]  ? __might_fault+0x3e/0x90
[  276.628464]  ? __might_fault+0x87/0x90
[  276.628467]  ? __might_fault+0x3e/0x90
[  276.628482]  i915_gem_execbuffer2+0xb5/0x220 [i915]
[  276.628487]  drm_ioctl+0x200/0x450
[  276.628502]  ? i915_gem_execbuffer+0x330/0x330 [i915]
[  276.628507]  do_vfs_ioctl+0x90/0x6e0
[  276.628510]  ? __fget+0x108/0x200
[  276.628513]  ? expand_files+0x2b0/0x2b0
[  276.628517]  SyS_ioctl+0x3c/0x70
[  276.628520]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  276.628523] RIP: 0033:0x7f5914d87357
[  276.628526] RSP: 002b:7f58ed475bf8 EFLAGS: 0246 ORIG_RAX: 
0010
[  276.628531] RAX: ffda RBX: 81474ff3 RCX: 7f5914d87357
[  276.628534] RDX: 7f58ed475c70 RSI: 40406469 RDI: 0003
[  276.628538] RBP: c90009113f88 R08: 0040 R09: 03f7
[  276.628541] R10:  R11: 0246 R12: 
[  276.628545] R13: 0003 R14: 40406469 R15: 024105f0
[  276.628549]  ? __this_cpu_preempt_check+0x13/0x20


Ander

> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove duplicate DDI enabling logic from MST path

2017-02-28 Thread Imre Deak
On Tue, Feb 28, 2017 at 09:21:13AM +0200, Ander Conselvan de Oliveira wrote:
> The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
> the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
> by calling the post_disable hook on the intel_dig_port instead of
 ^pre_enable
> duplicating that code.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c|  2 ++
>  drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
>  2 files changed, 5 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index e9013f1..71aaddf 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1695,6 +1695,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   enum port port = intel_ddi_get_encoder_port(encoder);
>   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
>  
> + WARN_ON(link_mst && port == PORT_A);
> +

So IIUC, this wasn't used before for MST and so link_mst was always
false. Also link_mst=true implies type == INTEL_OUTPUT_DP, as this will
be called for the primary encoder. After the change crtc->config will be
used instead of the (new) pipe_config, but this is fine since the two
are the same in the enable hooks. Looks ok to me:

Reviewed-by: Imre Deak 

>   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>link_mst);
>   if (encoder->type == INTEL_OUTPUT_EDP)
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index a8334e1..094cbdc 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>  
>   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>  
> - if (intel_dp->active_mst_links == 0) {
> - intel_ddi_clk_select(_dig_port->base,
> -  pipe_config->shared_dpll);
> -
> - intel_display_power_get(dev_priv,
> - intel_dig_port->ddi_io_power_domain);
> -
> - intel_prepare_dp_ddi_buffers(_dig_port->base);
> - intel_dp_set_link_params(intel_dp,
> -  pipe_config->port_clock,
> -  pipe_config->lane_count,
> -  true);
> -
> - intel_ddi_init_dp_buf_reg(_dig_port->base);
> -
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> -
> - intel_dp_start_link_train(intel_dp);
> - intel_dp_stop_link_train(intel_dp);
> - }
> + if (intel_dp->active_mst_links == 0)
> + intel_dig_port->base.pre_enable(_dig_port->base,
> + pipe_config, NULL);
>  
>   ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
>  connector->port,
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 6/6] drm/i915: Fix up verify_encoder_state

2017-02-28 Thread Daniel Vetter
The trouble here is that looking at all connector->state in the
verifier isn't good, because that's run from the commit work, which
doesn't hold the connection_mutex. Which means we're only allowed to
look at states in our atomic update.

The simple fix for future proofing would be to switch over to
drm_for_each_connector_in_state, but that has the problem that the
verification then fails if not all connectors are in the state. And we
also need to be careful to check both old and new encoders, and not
screw things up when an encoder gets reassigned.

Note that this isn't the full fix, since we still look at
connector->state. To fix that, we need Maarten's patch series to
switch over to state pointers within drm_atomic_state, but that's a
different series.

v2: Use oldnew iterator (Maarten).

Cc: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8dedf82c1c27..62ed706f94fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11898,31 +11898,37 @@ verify_connector_state(struct drm_device *dev,
 }
 
 static void
-verify_encoder_state(struct drm_device *dev)
+verify_encoder_state(struct drm_device *dev, struct drm_atomic_state *state)
 {
struct intel_encoder *encoder;
-   struct intel_connector *connector;
-   struct drm_connector_list_iter conn_iter;
+   struct drm_connector *connector;
+   struct drm_connector_state *old_conn_state, *new_conn_state;
+   int i;
 
for_each_intel_encoder(dev, encoder) {
-   bool enabled = false;
+   bool enabled = false, found = false;
enum pipe pipe;
 
DRM_DEBUG_KMS("[ENCODER:%d:%s]\n",
  encoder->base.base.id,
  encoder->base.name);
 
-   drm_connector_list_iter_get(dev, _iter);
-   for_each_intel_connector_iter(connector, _iter) {
-   if (connector->base.state->best_encoder != 
>base)
+   for_each_oldnew_connector_in_state(state, connector, 
old_conn_state,
+  new_conn_state, i) {
+   if (old_conn_state->best_encoder == >base)
+   found = true;
+
+   if (new_conn_state->best_encoder != >base)
continue;
-   enabled = true;
+   found = enabled = true;
 
-   I915_STATE_WARN(connector->base.state->crtc !=
+   I915_STATE_WARN(new_conn_state->crtc !=
encoder->base.crtc,
 "connector's crtc doesn't match encoder crtc\n");
}
-   drm_connector_list_iter_put(_iter);
+
+   if (!found)
+   continue;
 
I915_STATE_WARN(!!encoder->base.crtc != enabled,
 "encoder's enabled state mismatch "
@@ -12124,7 +12130,7 @@ static void
 intel_modeset_verify_disabled(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
-   verify_encoder_state(dev);
+   verify_encoder_state(dev, state);
verify_connector_state(dev, state, NULL);
verify_disabled_dpll_state(dev);
 }
-- 
2.11.0

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


[Intel-gfx] [PATCH 3/6] drm/i915: use drm_connector_list_iter in intel_opregion.c

2017-02-28 Thread Daniel Vetter
One case where I nuked a now unecessary locking, otherwise all just
boring stuff.

Cc: Jani Nikula 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_opregion.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 4a862a358c70..9e9105df3184 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -434,6 +434,7 @@ int intel_opregion_notify_adapter(struct drm_i915_private 
*dev_priv,
 static u32 asle_set_backlight(struct drm_i915_private *dev_priv, u32 bclp)
 {
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
struct opregion_asle *asle = dev_priv->opregion.asle;
struct drm_device *dev = _priv->drm;
 
@@ -458,8 +459,10 @@ static u32 asle_set_backlight(struct drm_i915_private 
*dev_priv, u32 bclp)
 * only one).
 */
DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
-   for_each_intel_connector(dev, connector)
+   drm_connector_list_iter_get(dev, _iter);
+   for_each_intel_connector_iter(connector, _iter)
intel_panel_set_backlight_acpi(connector, bclp, 255);
+   drm_connector_list_iter_put(_iter);
asle->cblv = DIV_ROUND_UP(bclp * 100, 255) | ASLE_CBLV_VALID;
 
drm_modeset_unlock(>mode_config.connection_mutex);
@@ -701,6 +704,7 @@ static void intel_didl_outputs(struct drm_i915_private 
*dev_priv)
 {
struct intel_opregion *opregion = _priv->opregion;
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
int i = 0, max_outputs;
int display_index[16] = {};
 
@@ -714,7 +718,8 @@ static void intel_didl_outputs(struct drm_i915_private 
*dev_priv)
max_outputs = ARRAY_SIZE(opregion->acpi->didl) +
ARRAY_SIZE(opregion->acpi->did2);
 
-   for_each_intel_connector(_priv->drm, connector) {
+   drm_connector_list_iter_get(_priv->drm, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
u32 device_id, type;
 
device_id = acpi_display_type(connector);
@@ -729,6 +734,7 @@ static void intel_didl_outputs(struct drm_i915_private 
*dev_priv)
set_did(opregion, i, device_id);
i++;
}
+   drm_connector_list_iter_put(_iter);
 
DRM_DEBUG_KMS("%d outputs detected\n", i);
 
@@ -745,6 +751,7 @@ static void intel_setup_cadls(struct drm_i915_private 
*dev_priv)
 {
struct intel_opregion *opregion = _priv->opregion;
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
int i = 0;
 
/*
@@ -757,11 +764,13 @@ static void intel_setup_cadls(struct drm_i915_private 
*dev_priv)
 * Note that internal panels should be at the front of the connector
 * list already, ensuring they're not left out.
 */
-   for_each_intel_connector(_priv->drm, connector) {
+   drm_connector_list_iter_get(_priv->drm, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
if (i >= ARRAY_SIZE(opregion->acpi->cadl))
break;
opregion->acpi->cadl[i++] = connector->acpi_device_id;
}
+   drm_connector_list_iter_put(_iter);
 
/* If fewer than 8 active devices, the list must be null terminated */
if (i < ARRAY_SIZE(opregion->acpi->cadl))
-- 
2.11.0

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


[Intel-gfx] [PATCH 4/6] drm/i915: Make intel_get_pipe_from_connector atomic

2017-02-28 Thread Daniel Vetter
Drive-by fixup while looking at all the connector_list walkers -
holding connection_mutex does actually _not_ give you locking to look
at the legacy drm_connector->encoder->crtc pointer chain. That one is
solely owned by the atomic commit workers. Instead we must inspect the
atomic state.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7673d5d9e74a..0f30362b4ad8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13875,15 +13875,14 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 
 enum pipe intel_get_pipe_from_connector(struct intel_connector *connector)
 {
-   struct drm_encoder *encoder = connector->base.encoder;
struct drm_device *dev = connector->base.dev;
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 
-   if (!encoder || WARN_ON(!encoder->crtc))
+   if (!connector->base.state->crtc)
return INVALID_PIPE;
 
-   return to_intel_crtc(encoder->crtc)->pipe;
+   return to_intel_crtc(connector->base.state->crtc)->pipe;
 }
 
 int intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data,
-- 
2.11.0

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


[Intel-gfx] [PATCH 5/6] drm/i915: use for_each_intel_connector_iter in intel_display.c

2017-02-28 Thread Daniel Vetter
This gets rid of the last users of for_each_intel_connector(), remove
that too.

At first I wasn't sure whether the 2 loops in the modeset state
checker should instead only loop over the connectors in the atomic
commit. But we never add connectors to an atomic update if they don't
(or won't have) a CRTC assigned, which means there'd be a gap in check
coverage. Hence loop over everything on those too.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 -
 drivers/gpu/drm/i915/intel_display.c | 20 
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb670d819134..32a67f438021 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -489,11 +489,6 @@ struct i915_hotplug {
&(dev)->mode_config.encoder_list,   \
base.head)
 
-#define for_each_intel_connector(dev, intel_connector) \
-   list_for_each_entry(intel_connector,\
-   &(dev)->mode_config.connector_list, \
-   base.head)
-
 #define for_each_intel_connector_iter(intel_connector, iter) \
while ((intel_connector = 
to_intel_connector(drm_connector_list_iter_next(iter
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0f30362b4ad8..8dedf82c1c27 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10977,8 +10977,10 @@ static const struct drm_crtc_helper_funcs 
intel_helper_funcs = {
 static void intel_modeset_update_connector_atomic_state(struct drm_device *dev)
 {
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
-   for_each_intel_connector(dev, connector) {
+   drm_connector_list_iter_get(dev, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
if (connector->base.state->crtc)
drm_connector_unreference(>base);
 
@@ -10994,6 +10996,7 @@ static void 
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
connector->base.state->crtc = NULL;
}
}
+   drm_connector_list_iter_put(_iter);
 }
 
 static void
@@ -11899,6 +11902,7 @@ verify_encoder_state(struct drm_device *dev)
 {
struct intel_encoder *encoder;
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
for_each_intel_encoder(dev, encoder) {
bool enabled = false;
@@ -11908,7 +11912,8 @@ verify_encoder_state(struct drm_device *dev)
  encoder->base.base.id,
  encoder->base.name);
 
-   for_each_intel_connector(dev, connector) {
+   drm_connector_list_iter_get(dev, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
if (connector->base.state->best_encoder != 
>base)
continue;
enabled = true;
@@ -11917,6 +11922,7 @@ verify_encoder_state(struct drm_device *dev)
encoder->base.crtc,
 "connector's crtc doesn't match encoder crtc\n");
}
+   drm_connector_list_iter_put(_iter);
 
I915_STATE_WARN(!!encoder->base.crtc != enabled,
 "encoder's enabled state mismatch "
@@ -15009,6 +15015,7 @@ int intel_modeset_init(struct drm_device *dev)
 static void intel_enable_pipe_a(struct drm_device *dev)
 {
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
struct drm_connector *crt = NULL;
struct intel_load_detect_pipe load_detect_temp;
struct drm_modeset_acquire_ctx *ctx = dev->mode_config.acquire_ctx;
@@ -15016,12 +15023,14 @@ static void intel_enable_pipe_a(struct drm_device 
*dev)
/* We can't just switch on the pipe A, we need to set things up with a
 * proper mode and output configuration. As a gross hack, enable pipe A
 * by enabling the load detect pipe once. */
-   for_each_intel_connector(dev, connector) {
+   drm_connector_list_iter_get(dev, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
if (connector->encoder->type == INTEL_OUTPUT_ANALOG) {
crt = >base;
break;
}
}
+   drm_connector_list_iter_put(_iter);
 
if (!crt)
return;
@@ -15267,6 +15276,7 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
struct intel_crtc *crtc;
struct intel_encoder *encoder;
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
int i;
 
dev_priv->active_crtcs = 

[Intel-gfx] [PATCH 2/6] drm/i915: use drm_connector_list_iter in intel_hotplug.c

2017-02-28 Thread Daniel Vetter
Nothing special, just rote conversion.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_hotplug.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 0756bdc672b3..b525304aacca 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -150,16 +150,17 @@ static bool intel_hpd_irq_storm_detect(struct 
drm_i915_private *dev_priv,
 static void intel_hpd_irq_storm_disable(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = _priv->drm;
-   struct drm_mode_config *mode_config = >mode_config;
struct intel_connector *intel_connector;
struct intel_encoder *intel_encoder;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
enum hpd_pin pin;
bool hpd_disabled = false;
 
assert_spin_locked(_priv->irq_lock);
 
-   list_for_each_entry(connector, _config->connector_list, head) {
+   drm_connector_list_iter_get(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->polled != DRM_CONNECTOR_POLL_HPD)
continue;
 
@@ -182,6 +183,7 @@ static void intel_hpd_irq_storm_disable(struct 
drm_i915_private *dev_priv)
| DRM_CONNECTOR_POLL_DISCONNECT;
hpd_disabled = true;
}
+   drm_connector_list_iter_put(_iter);
 
/* Enable polling and queue hotplug re-enabling. */
if (hpd_disabled) {
@@ -197,7 +199,6 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
container_of(work, typeof(*dev_priv),
 hotplug.reenable_work.work);
struct drm_device *dev = _priv->drm;
-   struct drm_mode_config *mode_config = >mode_config;
int i;
 
intel_runtime_pm_get(dev_priv);
@@ -205,13 +206,15 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
spin_lock_irq(_priv->irq_lock);
for_each_hpd_pin(i) {
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
if (dev_priv->hotplug.stats[i].state != HPD_DISABLED)
continue;
 
dev_priv->hotplug.stats[i].state = HPD_ENABLED;
 
-   list_for_each_entry(connector, _config->connector_list, 
head) {
+   drm_connector_list_iter_get(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
struct intel_connector *intel_connector = 
to_intel_connector(connector);
 
if (intel_connector->encoder->hpd_pin == i) {
@@ -223,6 +226,7 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
connector->polled = 
DRM_CONNECTOR_POLL_HPD;
}
}
+   drm_connector_list_iter_put(_iter);
}
if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup)
dev_priv->display.hpd_irq_setup(dev_priv);
@@ -308,14 +312,14 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
struct drm_i915_private *dev_priv =
container_of(work, struct drm_i915_private, 
hotplug.hotplug_work);
struct drm_device *dev = _priv->drm;
-   struct drm_mode_config *mode_config = >mode_config;
struct intel_connector *intel_connector;
struct intel_encoder *intel_encoder;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
bool changed = false;
u32 hpd_event_bits;
 
-   mutex_lock(_config->mutex);
+   mutex_lock(>mode_config.mutex);
DRM_DEBUG_KMS("running encoder hotplug functions\n");
 
spin_lock_irq(_priv->irq_lock);
@@ -328,7 +332,8 @@ static void i915_hotplug_work_func(struct work_struct *work)
 
spin_unlock_irq(_priv->irq_lock);
 
-   list_for_each_entry(connector, _config->connector_list, head) {
+   drm_connector_list_iter_get(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
intel_connector = to_intel_connector(connector);
if (!intel_connector->encoder)
continue;
@@ -342,7 +347,8 @@ static void i915_hotplug_work_func(struct work_struct *work)
changed = true;
}
}
-   mutex_unlock(_config->mutex);
+   drm_connector_list_iter_put(_iter);
+   mutex_unlock(>mode_config.mutex);
 
if (changed)
drm_kms_helper_hotplug_event(dev);
@@ -490,15 +496,16 @@ static void i915_hpd_poll_init_work(struct work_struct 
*work)
container_of(work, struct drm_i915_private,
 hotplug.poll_init_work);
struct 

[Intel-gfx] [PATCH 1/6] drm/i915: Use drm_connector_list_iter in debugfs

2017-02-28 Thread Daniel Vetter
While at it also try to reduce the locking a bit to what's really just
needed instead of everything that we could possibly lock.

Added a new for_each_intel_connector_iter which includes the cast to
intel_connector.

Otherwise just plain transformation with nothing special going on.

v2: Review from Maarten:
- Stick with modeset_lock_all in sink_crc, it looks at crtc->state.
- Fix up early loop exit in i915_displayport_test_active_write.

Cc: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 59 -
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 2 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1a28b5279bec..4ae30d6de036 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2730,12 +2730,14 @@ static int i915_sink_crc(struct seq_file *m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_device *dev = _priv->drm;
struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
struct intel_dp *intel_dp = NULL;
int ret;
u8 crc[6];
 
drm_modeset_lock_all(dev);
-   for_each_intel_connector(dev, connector) {
+   drm_connector_list_iter_get(dev, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
struct drm_crtc *crtc;
 
if (!connector->base.state->best_encoder)
@@ -2761,6 +2763,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
}
ret = -ENODEV;
 out:
+   drm_connector_list_iter_put(_iter);
drm_modeset_unlock_all(dev);
return ret;
 }
@@ -3197,9 +3200,9 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
struct drm_device *dev = _priv->drm;
struct intel_crtc *crtc;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
intel_runtime_pm_get(dev_priv);
-   drm_modeset_lock_all(dev);
seq_printf(m, "CRTC info\n");
seq_printf(m, "-\n");
for_each_intel_crtc(dev, crtc) {
@@ -3207,6 +3210,7 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
struct intel_crtc_state *pipe_config;
int x, y;
 
+   drm_modeset_lock(>base.mutex, NULL);
pipe_config = to_intel_crtc_state(crtc->base.state);
 
seq_printf(m, "CRTC %d: pipe: %c, active=%s, (size=%dx%d), 
dither=%s, bpp=%d\n",
@@ -3231,15 +3235,19 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
+   drm_modeset_unlock(>base.mutex);
}
 
seq_printf(m, "\n");
seq_printf(m, "Connector info\n");
seq_printf(m, "--\n");
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   mutex_lock(>mode_config.mutex);
+   drm_connector_list_iter_get(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter)
intel_connector_info(m, connector);
-   }
-   drm_modeset_unlock_all(dev);
+   drm_connector_list_iter_put(_iter);
+   mutex_unlock(>mode_config.mutex);
+
intel_runtime_pm_put(dev_priv);
 
return 0;
@@ -3566,13 +3574,16 @@ static void drrs_status_per_crtc(struct seq_file *m,
struct i915_drrs *drrs = _priv->drrs;
int vrefresh = 0;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
-   drm_for_each_connector(connector, dev) {
+   drm_connector_list_iter_get(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->state->crtc != _crtc->base)
continue;
 
seq_printf(m, "%s:\n", connector->name);
}
+   drm_connector_list_iter_put(_iter);
 
if (dev_priv->vbt.drrs_type == STATIC_DRRS_SUPPORT)
seq_puts(m, "\tVBT: DRRS_type: Static");
@@ -3658,9 +3669,10 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
struct intel_encoder *intel_encoder;
struct intel_digital_port *intel_dig_port;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
-   drm_modeset_lock_all(dev);
-   drm_for_each_connector(connector, dev) {
+   drm_connector_list_iter_get(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort)
continue;
 
@@ -3676,7 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: use BUILD_BUG_ON to ensure platform name has been set up

2017-02-28 Thread Patchwork
== Series Details ==

Series: drm/i915: use BUILD_BUG_ON to ensure platform name has been set up
URL   : https://patchwork.freedesktop.org/series/20373/
State : failure

== Summary ==

Series 20373v1 drm/i915: use BUILD_BUG_ON to ensure platform name has been set 
up
https://patchwork.freedesktop.org/api/1.0/series/20373/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-ivb-3520m) fdo#14
pass   -> DMESG-WARN (fi-bxt-j4205) fdo#14
pass   -> DMESG-WARN (fi-byt-j1900) fdo#14
pass   -> DMESG-WARN (fi-snb-2520m) fdo#14
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-ivb-3770)
Test kms_flip:
Subgroup basic-plain-flip:
pass   -> INCOMPLETE (fi-byt-j1900)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-bxt-j4205) fdo#14
dmesg-warn -> PASS   (fi-snb-2520m) fdo#14
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ivb-3520m) fdo#14

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#14 https://bugs.freedesktop.org/show_bug.cgi?id=14

fi-bdw-5557u total:278  pass:266  dwarn:1   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:238  dwarn:1   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:258  dwarn:1   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:210  pass:190  dwarn:1   dfail:0   fail:0   skip:18 
fi-byt-n2820 total:278  pass:246  dwarn:1   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:261  dwarn:1   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:261  dwarn:1   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:227  dwarn:1   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:258  dwarn:2   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:260  dwarn:1   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:249  dwarn:1   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:248  dwarn:1   dfail:0   fail:0   skip:29 

b2a0b6040942a2844abfe5098aaef584529f3ed3 drm-tip: 2017y-02m-28d-12h-31m-07s UTC 
integration manifest
c318577 drm/i915: use BUILD_BUG_ON to ensure platform name has been set up

== Logs ==

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915/perf: rate limit spurious oa report notice

2017-02-28 Thread Chris Wilson
On Tue, Feb 28, 2017 at 01:28:13PM +, Matthew Auld wrote:
> On 22 February 2017 at 15:25, Robert Bragg  wrote:
> > This change is pre-emptively aiming to avoid a potential cause of kernel
> > logging noise in case some condition were to result in us seeing invalid
> > OA reports.
> >
> > The workaround for the OA unit's tail pointer race condition is what
> > avoids the primary know cause of invalid reports being seen and with
> > that in place we aren't expecting to see this notice but it can't be
> > entirely ruled out.
> >
> > Just in case some condition does lead to the notice then it's likely
> > that it will be triggered repeatedly while attempting to append a
> > sequence of reports and depending on the configured OA sampling
> > frequency that might be a large number of repeat notices.
> >
> > Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 

printk_ratelimits emits a WARN when triggered, defeating the purpose of
using NOTE.
-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] [Nouveau] [PATCH 0/3] gpu: drm: Convert printk(KERN_ to pr_

2017-02-28 Thread Daniel Vetter
On Tue, Feb 28, 2017 at 04:55:51AM -0800, Joe Perches wrote:
> Broken up for Daniel Vetter

Thanks, I applied the core patch (needed a minor resolution in
drm_edid.c). I'll wait with the driver patch for a few more acks maybe,
and leave the 2 other patches to Alex for picking up directly.

Thanks, Daniel

> 
> Joe Perches (3):
>   gpu: drm: amd/radeon: Convert printk(KERN_ to pr_
>   gpu: drm: core: Convert printk(KERN_ to pr_
>   gpu: drm: drivers: Convert printk(KERN_ to pr_
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c   |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/atom.c  | 44 -
>  drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  4 +-
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  4 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 +-
>  drivers/gpu/drm/amd/include/amd_pcie_helpers.h |  4 +-
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  2 +-
>  drivers/gpu/drm/amd/powerplay/inc/pp_debug.h   |  2 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  4 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++---
>  .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  4 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  4 +-
>  drivers/gpu/drm/drm_cache.c| 12 ++---
>  drivers/gpu/drm/drm_edid.c |  4 +-
>  drivers/gpu/drm/drm_ioc32.c|  3 +-
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c|  9 ++--
>  drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++
>  drivers/gpu/drm/gma500/psb_drv.h   |  5 +-
>  drivers/gpu/drm/gma500/psb_intel_lvds.c|  7 ++-
>  drivers/gpu/drm/i915/i915_sw_fence.c   |  8 ++--
>  drivers/gpu/drm/mgag200/mgag200_mode.c |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c  |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |  7 +--
>  drivers/gpu/drm/nouveau/nouveau_vga.c  |  4 +-
>  drivers/gpu/drm/nouveau/nv50_display.c | 22 -
>  drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 ++--
>  drivers/gpu/drm/omapdrm/dss/dsi.c  | 17 ---
>  drivers/gpu/drm/omapdrm/dss/dss.c  |  3 +-
>  drivers/gpu/drm/omapdrm/dss/dss.h  | 15 +++---
>  drivers/gpu/drm/omapdrm/omap_gem.c |  5 +-
>  drivers/gpu/drm/r128/r128_cce.c|  7 ++-
>  drivers/gpu/drm/radeon/atom.c  | 46 --
>  drivers/gpu/drm/radeon/cik.c   | 56 
> --
>  drivers/gpu/drm/radeon/evergreen.c |  2 +-
>  drivers/gpu/drm/radeon/evergreen_cs.c  |  7 ++-
>  drivers/gpu/drm/radeon/ni.c| 22 +++--
>  drivers/gpu/drm/radeon/r100.c  | 18 +++
>  drivers/gpu/drm/radeon/r200.c  |  3 +-
>  drivers/gpu/drm/radeon/r300.c  | 13 ++---
>  drivers/gpu/drm/radeon/r420.c  |  9 ++--
>  drivers/gpu/drm/radeon/r520.c  |  3 +-
>  drivers/gpu/drm/radeon/r600.c  | 21 +++-
>  drivers/gpu/drm/radeon/r600_cs.c   |  7 ++-
>  drivers/gpu/drm/radeon/radeon.h|  3 +-
>  drivers/gpu/drm/radeon/radeon_atpx_handler.c   |  4 +-
>  drivers/gpu/drm/radeon/radeon_audio.c  |  4 +-
>  drivers/gpu/drm/radeon/radeon_clocks.c |  2 +-
>  drivers/gpu/drm/radeon/radeon_device.c |  8 ++--
>  drivers/gpu/drm/radeon/radeon_fb.c |  3 +-
>  drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
>  drivers/gpu/drm/radeon/radeon_test.c   |  6 +--
>  drivers/gpu/drm/radeon/rs400.c |  4 +-
>  drivers/gpu/drm/radeon/rs690.c |  3 +-
>  drivers/gpu/drm/radeon/rv515.c |  9 ++--
>  drivers/gpu/drm/radeon/si.c| 45 ++---
>  drivers/gpu/drm/ttm/ttm_bo.c   |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  6 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c  |  3 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  4 +-
>  69 files changed, 253 insertions(+), 362 deletions(-)
> 
> -- 
> 2.10.0.rc2.1.g053435c
> 
> 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Enable DDI IO power domains in the DP MST path

2017-02-28 Thread Imre Deak
On Tue, Feb 28, 2017 at 09:21:12AM +0200, Ander Conselvan de Oliveira wrote:
> Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
> enabling DPLL") changed how the DDI IO power domains get enabled, but
> neglected the need to enable those domains when enabling a DP connector
> with MST enabled, leading to
> 
> Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast 
> exception handler
> 
> Fixes: 62b695662a24 ("drm/i915: Only enable DDI IO power domains after 
> enabling DPLL")
> Cc: David Weinehall 
> Cc: Imre Deak 
> Cc: Ander Conselvan de Oliveira 
> Cc: David Weinehall 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä 
> Reported-by: Ville Syrjälä 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index d94fd4b..a8334e1 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -163,6 +163,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>   intel_ddi_clk_select(_dig_port->base,
>pipe_config->shared_dpll);
>  
> + intel_display_power_get(dev_priv,
> + intel_dig_port->ddi_io_power_domain);
> +
>   intel_prepare_dp_ddi_buffers(_dig_port->base);
>   intel_dp_set_link_params(intel_dp,
>pipe_config->port_clock,
> -- 
> 2.9.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm/i915/perf: rate limit spurious oa report notice

2017-02-28 Thread Matthew Auld
On 22 February 2017 at 15:25, Robert Bragg  wrote:
> This change is pre-emptively aiming to avoid a potential cause of kernel
> logging noise in case some condition were to result in us seeing invalid
> OA reports.
>
> The workaround for the OA unit's tail pointer race condition is what
> avoids the primary know cause of invalid reports being seen and with
> that in place we aren't expecting to see this notice but it can't be
> entirely ruled out.
>
> Just in case some condition does lead to the notice then it's likely
> that it will be triggered repeatedly while attempting to append a
> sequence of reports and depending on the configured OA sampling
> frequency that might be a large number of repeat notices.
>
> Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/3] drm/i915/perf: better pipeline aged/aging tail updates

2017-02-28 Thread Matthew Auld
On 22 February 2017 at 15:25, Robert Bragg  wrote:
> This updates the tail pointer race workaround handling to updating the
> 'aged' pointer before looking to start aging a new one. There's the
> possibility that there is already new data available and so we can
> immediately start aging a new pointer without having to first wait for a
> later hrtimer callback (and then another to age).
>
> Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Purge i915_gem_object_is_dead()

2017-02-28 Thread Joonas Lahtinen
On ti, 2017-02-28 at 11:13 +, Chris Wilson wrote:
> i915_gem_object_is_dead() was a temporary lockdep aide whilst
> transitioning to a new locking structure for obj->mm. Since commit
> 1233e2db199d ("drm/i915: Move object backing storage manipulation to its
> own locking") it is now unused and should be removed.
> 
> Signed-off-by: Chris Wilson 
> Cc:  Joonas Lahtinen 

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 08/10] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable

2017-02-28 Thread Hans de Goede
For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF,
v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Only call MIPI_SEQ_TEAR_OFF in cmd mode
---
 drivers/gpu/drm/i915/intel_dsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b9727a0..d316c24 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -739,6 +739,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
 * if disable packets are sent before sending shutdown packet then in
 * some next enable sequence send turn on packet error is observed
 */
+   if (is_cmd_mode(intel_dsi))
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
 
/* Transition to LP-00 */
-- 
2.9.3

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


[Intel-gfx] [PATCH v2 07/10] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

2017-02-28 Thread Hans de Goede
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.

Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Slightly change added comment wording
---
 drivers/gpu/drm/i915/intel_dsi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 2dd276a..b9727a0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -701,6 +701,11 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder,
I915_WRITE(MIPI_DEVICE_READY(port), 0);
}
 
+   /*
+* According to the spec we should send SHUTDOWN before
+* MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but field testing
+* has shown that the v3 sequence works for v2 VBTs too
+*/
if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
for_each_dsi_port(port, intel_dsi->ports)
-- 
2.9.3

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


[Intel-gfx] [PATCH v2 06/10] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

2017-02-28 Thread Hans de Goede
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
---
Changes in v2:
-Drop meaningless code-comments
---
 drivers/gpu/drm/i915/intel_dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b7b8c6d..2dd276a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -658,12 +658,12 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
msleep(100);
 
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
 
intel_dsi_port_enable(encoder);
}
 
intel_panel_enable_backlight(intel_dsi->attached_connector);
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
 }
 
 static void intel_dsi_enable_nop(struct intel_encoder *encoder,
@@ -689,6 +689,7 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("\n");
 
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_panel_disable_backlight(intel_dsi->attached_connector);
 
/*
@@ -733,7 +734,6 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
 * if disable packets are sent before sending shutdown packet then in
 * some next enable sequence send turn on packet error is observed
 */
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
 
/* Transition to LP-00 */
-- 
2.9.3

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


  1   2   >