[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add pipe scaler for Gen9 in atomic path

2016-08-29 Thread Patchwork
== Series Details ==

Series: drm/i915: Add pipe scaler for Gen9 in atomic path
URL   : https://patchwork.freedesktop.org/series/11764/
State : success

== Summary ==

Series 11764v1 drm/i915: Add pipe scaler for Gen9 in atomic path
http://patchwork.freedesktop.org/api/1.0/series/11764/revisions/1/mbox/


fi-bdw-5557u total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-bsw-n3050 total:252  pass:204  dwarn:0   dfail:0   fail:2   skip:46 
fi-hsw-4770k total:252  pass:228  dwarn:0   dfail:0   fail:2   skip:22 
fi-hsw-4770r total:252  pass:224  dwarn:0   dfail:0   fail:2   skip:26 
fi-ivb-3520m total:252  pass:220  dwarn:0   dfail:0   fail:1   skip:31 
fi-skl-6260u total:252  pass:203  dwarn:33  dfail:1   fail:1   skip:14 
fi-skl-6700k total:252  pass:189  dwarn:33  dfail:1   fail:1   skip:28 
fi-snb-2520m total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 
fi-snb-2600  total:252  pass:206  dwarn:0   dfail:0   fail:2   skip:44 

Results at /archive/results/CI_IGT_test/Patchwork_2450/

57de27e40b9741c17c6749a366e891faf8b22fcb drm-intel-nightly: 
2016y-08m-29d-15h-38m-26s UTC integration manifest
12be5fb drm/i915: Pipescaler destination size limit check on Gen9
fc9e212 drm/i915: Update pipe-scaler according to destination size
f84c7a4 drm/i915: Add pipe scaler co-ordinate and size property for Gen9
a2958a2 drm/i915: Adding atomic fitting mode property for GEN9
14decbe drm/i915: Panel fitting calculation for GEN9
03dc183 drm/i915: Add pipe_src size property calculations in atomic path.
417cfb0 drm/i915: Add pipe scaler pipe source drm property

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


[Intel-gfx] [PATCH 7/7] drm/i915: Pipescaler destination size limit check on Gen9

2016-08-29 Thread Nabendu Maiti
Pipe scaler on  gen9 destination size may go out of adjusted modeset
size.This patch add limit check on user custom crtc destination size and
clamp it within modeset size.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/i915/intel_display.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 15d185e..45e5204 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12565,6 +12565,17 @@ intel_gen9_pipe_scale(struct intel_crtc *intel_crtc,
pipe_config->pipe_src_w))
goto done;
 
+   /* Out of boundary, clamping it */
+   if ((pipe_config->pipe_dst_x + pipe_config->pipe_dst_w) >
+adjusted_mode->hdisplay)
+   pipe_config->pipe_dst_w =
+   (adjusted_mode->hdisplay - pipe_config->pipe_dst_x);
+
+   if ((pipe_config->pipe_dst_y + pipe_config->pipe_dst_h) >
+   adjusted_mode->vdisplay)
+   pipe_config->pipe_dst_h =
+   (adjusted_mode->vdisplay - pipe_config->pipe_dst_y);
+
x = pipe_config->pipe_dst_x;
y = pipe_config->pipe_dst_y;
width = pipe_config->pipe_dst_w;
-- 
1.9.1

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


[Intel-gfx] [PATCH 5/7] drm/i915: Add pipe scaler co-ordinate and size property for Gen9

2016-08-29 Thread Nabendu Maiti
Adding pipe destination co-ordinate and size property as crtc atomic drm
property to dynamically change pipe destination attributes on GEN9.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/drm_atomic.c | 20 +++
 drivers/gpu/drm/drm_crtc.c   | 32 +
 drivers/gpu/drm/i915/intel_display.c | 70 +---
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 include/drm/drm_crtc.h   |  5 +++
 include/uapi/drm/drm_mode.h  |  1 +
 6 files changed, 126 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3fddfa4..3df78c0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -502,6 +502,18 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
} else if (property == config->prop_fitting_mode) {
state->fitting_mode = val;
state->pipescaler_changed = true;
+   } else if (property == config->prop_pipe_dst_x) {
+   state->dst_x = val;
+   state->pipescaler_changed = true;
+   } else if (property == config->prop_pipe_dst_y) {
+   state->dst_y = val;
+   state->pipescaler_changed = true;
+   } else if (property == config->prop_pipe_dst_w) {
+   state->dst_w = val;
+   state->pipescaler_changed = true;
+   } else if (property == config->prop_pipe_dst_h) {
+   state->dst_h = val;
+   state->pipescaler_changed = true;
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -550,6 +562,14 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val =  state->src_h;
else if (property == config->prop_fitting_mode)
*val = state->fitting_mode;
+   else if (property == config->prop_pipe_dst_x)
+   *val = state->dst_x;
+   else if (property == config->prop_pipe_dst_y)
+   *val = state->dst_y;
+   else if (property == config->prop_pipe_dst_w)
+   *val = state->dst_w;
+   else if (property == config->prop_pipe_dst_h)
+   *val = state->dst_h;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b24e839..c941f58 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -383,6 +383,14 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
   config->prop_pipe_src_h, 0);
drm_object_attach_property(>base,
   config->prop_fitting_mode, 0);
+   drm_object_attach_property(>base,
+  config->prop_pipe_dst_x, 0);
+   drm_object_attach_property(>base,
+  config->prop_pipe_dst_y, 0);
+   drm_object_attach_property(>base,
+  config->prop_pipe_dst_w, 0);
+   drm_object_attach_property(>base,
+  config->prop_pipe_dst_h, 0);
}
 
return 0;
@@ -967,6 +975,30 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fitting_mode = prop;
 
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "PIPE_DST_X", 0, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_pipe_dst_x = prop;
+
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "PIPE_DST_Y", 0, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_pipe_dst_y = prop;
+
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "PIPE_DST_W", 0, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_pipe_dst_w = prop;
+
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "PIPE_DST_H", 0, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_pipe_dst_h = prop;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e3ecb8b..9c7434f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12548,6 +12548,35 @@ static bool check_single_encoder_cloning(struct 
drm_atomic_state *state,
return true;
 }
 
+void
+intel_gen9_pipe_scale(struct intel_crtc *intel_crtc,
+   struct intel_crtc_state *pipe_config,
+   int 

[Intel-gfx] [PATCH 6/7] drm/i915: Update pipe-scaler according to destination size

2016-08-29 Thread Nabendu Maiti
Pipe scaler is scaler registers are updated according to provided
destination size from user.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9c7434f..15d185e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4710,7 +4710,6 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 int skl_update_scaler_crtc(struct intel_crtc_state *state)
 {
struct intel_crtc *intel_crtc = to_intel_crtc(state->base.crtc);
-   const struct drm_display_mode *adjusted_mode = 
>base.adjusted_mode;
 
DRM_DEBUG_KMS("Updating scaler for [CRTC:%d:%s] scaler_user index 
%u.%u\n",
  intel_crtc->base.base.id, intel_crtc->base.name,
@@ -4719,7 +4718,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
>scaler_state.scaler_id, DRM_ROTATE_0,
state->pipe_src_w, state->pipe_src_h,
-   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
+   state->pipe_dst_w, state->pipe_dst_h);
 }
 
 /**
@@ -12609,6 +12608,7 @@ static int skylake_pfiter_calculate(struct drm_crtc 
*crtc,
intel_pch_panel_fitting(intel_crtc,
pipe_config,
pipe_config->pipe_scaling_mode);
+   }
pipe_config->pipe_dst_x =
(pipe_config->pch_pfit.pos >> 16);
pipe_config->pipe_dst_y =
@@ -12617,7 +12617,6 @@ static int skylake_pfiter_calculate(struct drm_crtc 
*crtc,
(pipe_config->pch_pfit.size >> 16);
pipe_config->pipe_dst_h =
(pipe_config->pch_pfit.size & 0x);
-   }
}
}
return ret;
@@ -13096,7 +13095,10 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
 
pipe_config->pipe_dst_w = pipe_config->pipe_src_w;
pipe_config->pipe_dst_h = pipe_config->pipe_src_h;
-
+   pipe_config->base.dst_w = pipe_config->pipe_src_w;
+   pipe_config->base.dst_h = pipe_config->pipe_src_h;
+   pipe_config->base.src_w = pipe_config->pipe_src_w;
+   pipe_config->base.src_h = pipe_config->pipe_src_h;
 
 encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
@@ -13106,7 +13108,6 @@ encoder_retry:
/* Fill in default crtc timings, allow encoders to overwrite them. */
drm_mode_set_crtcinfo(_config->base.adjusted_mode,
  CRTC_STEREO_DOUBLE);
-
/* Pass our mode to the connectors and the CRTC to give them a chance to
 * adjust it according to limitations or connector properties, and also
 * a chance to reject the mode entirely.
@@ -14081,8 +14082,8 @@ static int intel_atomic_check(struct drm_device *dev,
 
crtc_state->src_w = adjusted_mode->hdisplay;
crtc_state->src_h = adjusted_mode->vdisplay;
-   crtc_state->dst_w = adjusted_mode->hdisplay;
-   crtc_state->dst_h = adjusted_mode->vdisplay;
+   crtc_state->dst_w = crtc_state->src_w;
+   crtc_state->dst_h = crtc_state->src_h;
crtc_state->dst_x =  0;
crtc_state->dst_y =  0;
crtc_state->fitting_mode = 0;
-- 
1.9.1

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


[Intel-gfx] [PATCH 3/7] drm/i915: Panel fitting calculation for GEN9

2016-08-29 Thread Nabendu Maiti
No boundary condition was checked while calculating pipe scaler size
in pch_panel_fitting(), which might result in blank out or
corruptions for invalid values. This patch fixes this by adding
appropriate checks and calculation for each fitting mode.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/i915/intel_panel.c | 34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 96c65d7..b5ea1b6 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -107,18 +107,36 @@ intel_pch_panel_fitting(struct intel_crtc *intel_crtc,
 {
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int x = 0, y = 0, width = 0, height = 0;
+   bool downscale = false;
 
/* Native modes don't need fitting */
if (adjusted_mode->crtc_hdisplay == pipe_config->pipe_src_w &&
adjusted_mode->crtc_vdisplay == pipe_config->pipe_src_h)
goto done;
 
+   /* Downscale pfiter */
+   if (IS_GEN9(intel_crtc->base.dev) &&
+(adjusted_mode->hdisplay < pipe_config->pipe_src_w ||
+   adjusted_mode->vdisplay < pipe_config->pipe_src_h))
+   downscale = true;
+
switch (fitting_mode) {
case DRM_MODE_SCALE_CENTER:
width = pipe_config->pipe_src_w;
height = pipe_config->pipe_src_h;
x = (adjusted_mode->crtc_hdisplay - width + 1)/2;
y = (adjusted_mode->crtc_vdisplay - height + 1)/2;
+
+   if (downscale) {
+   if (x < 0) {
+   x = 0;
+   width = adjusted_mode->hdisplay;
+   }
+   if (y < 0) {
+   y = 0;
+   height = adjusted_mode->vdisplay;
+   }
+   }
break;
 
case DRM_MODE_SCALE_ASPECT:
@@ -132,14 +150,26 @@ intel_pch_panel_fitting(struct intel_crtc *intel_crtc,
width = scaled_height / pipe_config->pipe_src_h;
if (width & 1)
width++;
-   x = (adjusted_mode->crtc_hdisplay - width + 1) 
/ 2;
+   if (adjusted_mode->hdisplay > width) {
+   x = (adjusted_mode->hdisplay -
+width + 1) / 2;
+   } else if (downscale) {
+   width = adjusted_mode->hdisplay;
+   x = 0;
+   }
y = 0;
height = adjusted_mode->crtc_vdisplay;
} else if (scaled_width < scaled_height) { /* letter */
height = scaled_width / pipe_config->pipe_src_w;
if (height & 1)
height++;
-   y = (adjusted_mode->crtc_vdisplay - height + 1) 
/ 2;
+   if (adjusted_mode->vdisplay > height) {
+   y = (adjusted_mode->vdisplay -
+height + 1) / 2;
+   } else if (downscale) {
+   height = adjusted_mode->vdisplay;
+   y = 0;
+   }
x = 0;
width = adjusted_mode->crtc_hdisplay;
} else {
-- 
1.9.1

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


[Intel-gfx] [PATCH 0/7] drm/i915: Add pipe scaler for Gen9 in atomic path

2016-08-29 Thread Nabendu Maiti
Following patch series add pipe scaler functionality in atomic path.The pipe
scaler can be changed dynamically without modeset.Apart from default panel
fitter supported scaling modes -CENTER/ASPECT/FULLSCREEN custom scaling mode
mode is added as there is no such restriction on GEn9 pipe scaler.



Nabendu Maiti (7):
  drm/i915: Add pipe scaler pipe source drm property
  drm/i915: Add pipe_src size property calculations in atomic path.
  drm/i915: Panel fitting calculation for GEN9
  drm/i915: Adding atomic fitting mode property for GEN9
  drm/i915: Add pipe scaler co-ordinate and size property for Gen9
  drm/i915: Update pipe-scaler according to destination size
  drm/i915: Pipescaler destination size limit check on Gen9

 drivers/gpu/drm/drm_atomic.c |  35 ++
 drivers/gpu/drm/drm_crtc.c   |  56 +++
 drivers/gpu/drm/i915/intel_display.c | 128 +--
 drivers/gpu/drm/i915/intel_drv.h |   3 +
 drivers/gpu/drm/i915/intel_panel.c   |  34 +-
 include/drm/drm_crtc.h   |  14 
 include/uapi/drm/drm_mode.h  |   1 +
 7 files changed, 263 insertions(+), 8 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH 4/7] drm/i915: Adding atomic fitting mode property for GEN9

2016-08-29 Thread Nabendu Maiti
Pipe scaler Fitting mode property is added as crtc atomic property.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/drm_atomic.c |  5 
 drivers/gpu/drm/drm_crtc.c   |  8 ++
 drivers/gpu/drm/i915/intel_display.c | 47 ++--
 include/drm/drm_crtc.h   |  2 ++
 4 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 066f010..3fddfa4 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -499,6 +499,9 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
} else if (property == config->prop_pipe_src_h) {
state->src_h = val;
state->pipescaler_changed = true;
+   } else if (property == config->prop_fitting_mode) {
+   state->fitting_mode = val;
+   state->pipescaler_changed = true;
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -545,6 +548,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val =  state->src_w;
else if (property == config->prop_pipe_src_h)
*val =  state->src_h;
+   else if (property == config->prop_fitting_mode)
+   *val = state->fitting_mode;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fd6dd8..b24e839 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -381,6 +381,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
   config->prop_pipe_src_w, 0);
drm_object_attach_property(>base,
   config->prop_pipe_src_h, 0);
+   drm_object_attach_property(>base,
+  config->prop_fitting_mode, 0);
}
 
return 0;
@@ -959,6 +961,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_pipe_src_h = prop;
 
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "SCALER_MODE", 0, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_fitting_mode = prop;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ff5dea8..e3ecb8b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12551,48 +12551,25 @@ static bool check_single_encoder_cloning(struct 
drm_atomic_state *state,
 static int skylake_pfiter_calculate(struct drm_crtc *crtc,
   struct drm_crtc_state *crtc_state)
 {
-   struct drm_device *dev = crtc->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
bool mode_changed = needs_modeset(crtc_state);
-   struct intel_connector *intel_connector;
int ret = 0;
-   struct drm_display_mode *adjusted_mode =
-   _crtc->config->base.adjusted_mode;
-
-   for_each_intel_connector(dev, intel_connector) {
-   if (!(intel_connector) || !(intel_connector->encoder) ||
-   (intel_connector->encoder->base.crtc  != crtc))
-   continue;
 
-   if (((pipe_config->pipe_src_w !=
- intel_crtc->config->pipe_src_w) ||
-(pipe_config->pipe_src_h !=
- intel_crtc->config->pipe_src_h)) && (!mode_changed))
-   pipe_config->update_pipe = true;
-
-   if ((pipe_config->pipe_scaling_mode !=
-   intel_connector->panel.fitting_mode) &&
-   (!mode_changed)) {
-   if  ((adjusted_mode->hdisplay !=
- pipe_config->pipe_src_w) ||
-(adjusted_mode->vdisplay !=
- pipe_config->pipe_src_h)) {
-   pipe_config->pipe_scaling_mode =
-   intel_connector->panel.fitting_mode;
-   pipe_config->update_pipe = true;
-   }
-   }
+   if (((pipe_config->pipe_scaling_mode !=
+ intel_crtc->config->pipe_scaling_mode) ||
+(pipe_config->pipe_src_w != intel_crtc->config->pipe_src_w) ||
+(pipe_config->pipe_src_h != intel_crtc->config->pipe_src_h)) &&
+   (!mode_changed)) {
+   pipe_config->update_pipe = true;
+   }
 
-   if 

[Intel-gfx] [PATCH 2/7] drm/i915: Add pipe_src size property calculations in atomic path.

2016-08-29 Thread Nabendu Maiti
Adding pipe source size property calculations on atomic path to
dynamically change pipe source size.

Write desired values to change the size. Write 0 to disable pipe scaler
and restore the original mode adjusted values.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/i915/intel_display.c | 69 ++--
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..ff5dea8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12548,6 +12548,55 @@ static bool check_single_encoder_cloning(struct 
drm_atomic_state *state,
return true;
 }
 
+static int skylake_pfiter_calculate(struct drm_crtc *crtc,
+  struct drm_crtc_state *crtc_state)
+{
+   struct drm_device *dev = crtc->dev;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *pipe_config =
+   to_intel_crtc_state(crtc_state);
+   bool mode_changed = needs_modeset(crtc_state);
+   struct intel_connector *intel_connector;
+   int ret = 0;
+   struct drm_display_mode *adjusted_mode =
+   _crtc->config->base.adjusted_mode;
+
+   for_each_intel_connector(dev, intel_connector) {
+   if (!(intel_connector) || !(intel_connector->encoder) ||
+   (intel_connector->encoder->base.crtc  != crtc))
+   continue;
+
+   if (((pipe_config->pipe_src_w !=
+ intel_crtc->config->pipe_src_w) ||
+(pipe_config->pipe_src_h !=
+ intel_crtc->config->pipe_src_h)) && (!mode_changed))
+   pipe_config->update_pipe = true;
+
+   if ((pipe_config->pipe_scaling_mode !=
+   intel_connector->panel.fitting_mode) &&
+   (!mode_changed)) {
+   if  ((adjusted_mode->hdisplay !=
+ pipe_config->pipe_src_w) ||
+(adjusted_mode->vdisplay !=
+ pipe_config->pipe_src_h)) {
+   pipe_config->pipe_scaling_mode =
+   intel_connector->panel.fitting_mode;
+   pipe_config->update_pipe = true;
+   }
+   }
+
+   if ((mode_changed) || (pipe_config->update_pipe)) {
+   ret = skl_update_scaler_crtc(pipe_config);
+   if (ret)
+   break;
+   intel_pch_panel_fitting(intel_crtc, pipe_config,
+   intel_connector->panel.fitting_mode);
+   break;
+   }
+   }
+   return ret;
+}
+
 static int intel_crtc_atomic_check(struct drm_crtc *crtc,
   struct drm_crtc_state *crtc_state)
 {
@@ -12616,9 +12665,7 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
}
 
if (INTEL_INFO(dev)->gen >= 9) {
-   if (mode_changed)
-   ret = skl_update_scaler_crtc(pipe_config);
-
+   ret = skylake_pfiter_calculate(crtc, crtc_state);
if (!ret)
ret = intel_atomic_setup_scalers(dev, intel_crtc,
 pipe_config);
@@ -13995,6 +14042,21 @@ static int intel_atomic_check(struct drm_device *dev,
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
 
+   if (crtc_state->pipescaler_changed) {
+   if (crtc_state->src_w == 0 && crtc_state->src_h == 0) {
+   struct intel_crtc *intel_crtc =
+   to_intel_crtc(crtc);
+   struct drm_display_mode *adjusted_mode =
+   _crtc->config->base.adjusted_mode;
+
+   crtc_state->src_w = adjusted_mode->hdisplay;
+   crtc_state->src_h = adjusted_mode->vdisplay;
+   }
+   pipe_config->pipe_src_w = crtc_state->src_w;
+   pipe_config->pipe_src_h = crtc_state->src_h;
+   crtc_state->pipescaler_changed = false;
+   }
+
/* Catch I915_MODE_FLAG_INHERITED */
if (crtc_state->mode.private_flags != 
crtc->state->mode.private_flags)
crtc_state->mode_changed = true;
@@ -14988,6 +15050,7 @@ fail:
return NULL;
 }
 
+
 void intel_create_rotation_property(struct drm_device *dev, struct intel_plane 
*plane)
 {
if (!dev->mode_config.rotation_property) {
diff --git 

[Intel-gfx] [PATCH 1/7] drm/i915: Add pipe scaler pipe source drm property

2016-08-29 Thread Nabendu Maiti
Initialization of pipe source size property as intel drm property to drm level
to dynamically change pipe source size.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/drm_atomic.c | 10 ++
 drivers/gpu/drm/drm_crtc.c   | 16 
 include/drm/drm_crtc.h   |  7 +++
 3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 0b8f33d..066f010 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -493,6 +493,12 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->prop_pipe_src_w) {
+   state->src_w = val;
+   state->pipescaler_changed = true;
+   } else if (property == config->prop_pipe_src_h) {
+   state->src_h = val;
+   state->pipescaler_changed = true;
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -535,6 +541,10 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+   else if (property == config->prop_pipe_src_w)
+   *val =  state->src_w;
+   else if (property == config->prop_pipe_src_h)
+   *val =  state->src_h;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9316a2b..6fd6dd8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -377,6 +377,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, config->prop_active, 0);
drm_object_attach_property(>base, config->prop_mode_id, 
0);
+   drm_object_attach_property(>base,
+  config->prop_pipe_src_w, 0);
+   drm_object_attach_property(>base,
+  config->prop_pipe_src_h, 0);
}
 
return 0;
@@ -943,6 +947,18 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;
 
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "PIPE_SRC_W", 0, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_pipe_src_w = prop;
+
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "PIPE_SRC_H", 0, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_pipe_src_h = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bb214a1..4d6b580 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -197,6 +197,9 @@ struct drm_crtc_state {
struct drm_pending_vblank_event *event;
 
struct drm_atomic_state *state;
+
+   bool pipescaler_changed;
+   u32 src_w, src_h;
 };
 
 /**
@@ -1942,6 +1945,10 @@ struct drm_mode_config {
 */
struct drm_property *prop_mode_id;
 
+   /* pipe scaler properties */
+   struct drm_property *prop_pipe_src_w;
+   struct drm_property *prop_pipe_src_h;
+
/**
 * @dvi_i_subconnector_property: Optional DVI-I property to
 * differentiate between analog or digital mode.
-- 
1.9.1

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


[Intel-gfx] keep Nalu start code in VASliceDataBufferType data

2016-08-29 Thread Randy Li

Hi all:
  When I just doing the driver for us chip, we would request the Nalu 
header present in the data to be process. But I found the data be 
Rendered to with type VASliceDataBufferType is removed the Nalu start 
code. Is there any way to make the client send the data without remove 
the start code ? Thank you.


P.S Thank you for the Intel guys help, I decided not to use the DRM 
framework to implement the interface in kernel after I talked to the 
kernel upstream. But the request API would be used.

--
Randy Li
The third produce department

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


Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Switch to using port stored in intel_encoder

2016-08-29 Thread Pandiyan, Dhinakaran
Just realized this patch needs s/attached_port/port, will send out
another version.


On Mon, 2016-08-29 at 17:23 -0400, Lyude Paul wrote:
> Looks like a much better solution then the previous one.
> 
> Reviewed-by: Lyude 
> 
> On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> > Now that we have the port enum stored in intel_encoder, use that instead of
> > dereferencing intel_dig_port. Saves us a few locals.
> > 
> > struct intel_encoder variables have been renamed to be consistent and
> > convey type information.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 39 +++
> > ---
> >  1 file changed, 15 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index d32f586..5a41439 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -276,17 +276,15 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder
> > *encoder)
> >  }
> >  
> >  static void hsw_audio_codec_enable(struct drm_connector *connector,
> > -  struct intel_encoder *encoder,
> > +  struct intel_encoder *intel_encoder,
> >const struct drm_display_mode
> > *adjusted_mode)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > -   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > +   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> > >base.crtc);
> > enum pipe pipe = intel_crtc->pipe;
> > +   enum port port = intel_encoder->attached_port;
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > const uint8_t *eld = connector->eld;
> > -   struct intel_digital_port *intel_dig_port =
> > -   enc_to_dig_port(>base);
> > -   enum port port = intel_dig_port->port;
> > uint32_t tmp;
> > int len, i;
> > int n, rate;
> > @@ -355,14 +353,12 @@ static void hsw_audio_codec_enable(struct 
> > drm_connector
> > *connector,
> > mutex_unlock(_priv->av_mutex);
> >  }
> >  
> > -static void ilk_audio_codec_disable(struct intel_encoder *encoder)
> > +static void ilk_audio_codec_disable(struct intel_encoder *intel_encoder)
> >  {
> > -   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > -   struct intel_digital_port *intel_dig_port =
> > -   enc_to_dig_port(>base);
> > -   enum port port = intel_dig_port->port;
> > +   struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
> > +   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> > >base.crtc);
> > enum pipe pipe = intel_crtc->pipe;
> > +   enum port port = intel_encoder->attached_port;
> > uint32_t tmp, eldv;
> > i915_reg_t aud_config, aud_cntrl_st2;
> >  
> > @@ -402,18 +398,15 @@ static void ilk_audio_codec_disable(struct 
> > intel_encoder
> > *encoder)
> >  }
> >  
> >  static void ilk_audio_codec_enable(struct drm_connector *connector,
> > -  struct intel_encoder *encoder,
> > +  struct intel_encoder *intel_encoder,
> >const struct drm_display_mode
> > *adjusted_mode)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > -   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > -   struct intel_digital_port *intel_dig_port =
> > -   enc_to_dig_port(>base);
> > -   enum port port = intel_dig_port->port;
> > +   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> > >base.crtc);
> > enum pipe pipe = intel_crtc->pipe;
> > +   enum port port = intel_encoder->attached_port;
> > uint8_t *eld = connector->eld;
> > -   uint32_t eldv;
> > -   uint32_t tmp;
> > +   uint32_t tmp, eldv;
> > int len, i;
> > i915_reg_t hdmiw_hdmiedid, aud_config, aud_cntl_st, aud_cntrl_st2;
> >  
> > @@ -495,11 +488,10 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> > struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > const struct drm_display_mode *adjusted_mode = >config-
> > >base.adjusted_mode;
> > struct drm_connector *connector;
> > -   struct drm_device *dev = encoder->dev;
> > -   struct drm_i915_private *dev_priv = to_i915(dev);
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > -   enum port port = intel_dig_port->port;
> > +   enum port port = intel_encoder->attached_port;
> >  
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -542,11 +534,10 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> >  

[Intel-gfx] [PATCH v4 3/4] drm/i915: Move audio_connector to intel_encoder

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

v2: Removed locals that are not needed anymore.

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

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

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


Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Move audio_connector to intel_encoder

2016-08-29 Thread Pandiyan, Dhinakaran
Confirmed on IRC, Lyude is fine with carrying over R-B from previous
version.


On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> With DP MST, a digital_port can carry more than one audio stream. Hence,
> more than one audio_connector needs to be attached to intel_digital_port in
> such cases. However, each stream is associated with an unique encoder. So,
> instead of creating an array of audio_connectors per port, move
> audio_connector from struct intel_digital_port to struct intel_encoder.
> This also simplifies access to the right audio_connector from codec
> functions in intel_audio.c that receive intel_encoder.
> 
> v2: Removed locals that are not needed anymore.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 12 
>  drivers/gpu/drm/i915/intel_drv.h   |  4 ++--
>  2 files changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 5a41439..b86bfad 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -490,7 +490,6 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>   struct drm_connector *connector;
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
> - struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_encoder->attached_port;
>  
>   connector = drm_select_eld(encoder);
> @@ -515,7 +514,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>adjusted_mode);
>  
>   mutex_lock(_priv->av_mutex);
> - intel_dig_port->audio_connector = connector;
> + intel_encoder->audio_connector = connector;
>   /* referred in audio callbacks */
>   dev_priv->dig_port_map[port] = intel_encoder;
>   mutex_unlock(_priv->av_mutex);
> @@ -536,14 +535,13 @@ void intel_audio_codec_disable(struct intel_encoder 
> *intel_encoder)
>   struct drm_encoder *encoder = _encoder->base;
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
> - struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_encoder->attached_port;
>  
>   if (dev_priv->display.audio_codec_disable)
>   dev_priv->display.audio_codec_disable(intel_encoder);
>  
>   mutex_lock(_priv->av_mutex);
> - intel_dig_port->audio_connector = NULL;
> + intel_encoder->audio_connector = NULL;
>   dev_priv->dig_port_map[port] = NULL;
>   mutex_unlock(_priv->av_mutex);
>  
> @@ -704,7 +702,6 @@ static int i915_audio_component_get_eld(struct device 
> *dev, int port,
>  {
>   struct drm_i915_private *dev_priv = dev_to_i915(dev);
>   struct intel_encoder *intel_encoder;
> - struct intel_digital_port *intel_dig_port;
>   const u8 *eld;
>   int ret = -EINVAL;
>  
> @@ -713,10 +710,9 @@ static int i915_audio_component_get_eld(struct device 
> *dev, int port,
>   /* intel_encoder might be NULL for DP MST */
>   if (intel_encoder) {
>   ret = 0;
> - intel_dig_port = enc_to_dig_port(_encoder->base);
> - *enabled = intel_dig_port->audio_connector != NULL;
> + *enabled = intel_encoder->audio_connector != NULL;
>   if (*enabled) {
> - eld = intel_dig_port->audio_connector->eld;
> + eld = intel_encoder->audio_connector->eld;
>   ret = drm_eld_size(eld);
>   memcpy(buf, eld, min(max_bytes, ret));
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 68bf134..30186bf 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -232,6 +232,8 @@ struct intel_encoder {
>   void (*suspend)(struct intel_encoder *);
>   int crtc_mask;
>   enum hpd_pin hpd_pin;
> + /* for communication with audio component; protected by av_mutex */
> + const struct drm_connector *audio_connector;
>  };
>  
>  struct intel_panel {
> @@ -948,8 +950,6 @@ struct intel_digital_port {
>   enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
>   bool release_cl2_override;
>   uint8_t max_lanes;
> - /* for communication with audio component; protected by av_mutex */
> - const struct drm_connector *audio_connector;
>  };
>  
>  struct intel_dp_mst_encoder {

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


Re: [Intel-gfx] [PATCH 0/4] Backported vlv fixes for 4.7.y

2016-08-29 Thread Lyude Paul
drm/i915/vlv: Make intel_crt_reset() per-encoder:
4570d833390b10043d082fe535375d4a0e071d9c
drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init():
4c732e6ee9e71903934d75b12a021eb3520b6197
drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug():
21842ea84f161ae37ba25f0250c377fd19c5b307
drm/i915: Enable polling when we don't have hpd:
84c8e0963da434d37355079b568465cd121af295

On Mon, 2016-08-22 at 16:33 -0400, Greg KH wrote:
> On Mon, Aug 22, 2016 at 11:31:31AM -0400, Lyude wrote:
> > 
> > Hope this didn't take too long! Here's the backported versions of the
> > patches
> > you had trouble applying to stable. The patch for FBC won't be necessary as
> > that is already present in 4.7.y.
> > 
> > Cheers,
> > Lyude
> 
> Thanks, but what are the git commit ids of these patches in Linus's
> tree?  I need those to add to the commits...
> 
> thanks,
> 
> greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Switch to using port stored in intel_encoder

2016-08-29 Thread Lyude Paul
Looks like a much better solution then the previous one.

Reviewed-by: Lyude 

On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> Now that we have the port enum stored in intel_encoder, use that instead of
> dereferencing intel_dig_port. Saves us a few locals.
> 
> struct intel_encoder variables have been renamed to be consistent and
> convey type information.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 39 +++
> ---
>  1 file changed, 15 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index d32f586..5a41439 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -276,17 +276,15 @@ static void hsw_audio_codec_disable(struct intel_encoder
> *encoder)
>  }
>  
>  static void hsw_audio_codec_enable(struct drm_connector *connector,
> -    struct intel_encoder *encoder,
> +    struct intel_encoder *intel_encoder,
>      const struct drm_display_mode
> *adjusted_mode)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> + struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> >base.crtc);
>   enum pipe pipe = intel_crtc->pipe;
> + enum port port = intel_encoder->attached_port;
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   const uint8_t *eld = connector->eld;
> - struct intel_digital_port *intel_dig_port =
> - enc_to_dig_port(>base);
> - enum port port = intel_dig_port->port;
>   uint32_t tmp;
>   int len, i;
>   int n, rate;
> @@ -355,14 +353,12 @@ static void hsw_audio_codec_enable(struct drm_connector
> *connector,
>   mutex_unlock(_priv->av_mutex);
>  }
>  
> -static void ilk_audio_codec_disable(struct intel_encoder *encoder)
> +static void ilk_audio_codec_disable(struct intel_encoder *intel_encoder)
>  {
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> - struct intel_digital_port *intel_dig_port =
> - enc_to_dig_port(>base);
> - enum port port = intel_dig_port->port;
> + struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
> + struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> >base.crtc);
>   enum pipe pipe = intel_crtc->pipe;
> + enum port port = intel_encoder->attached_port;
>   uint32_t tmp, eldv;
>   i915_reg_t aud_config, aud_cntrl_st2;
>  
> @@ -402,18 +398,15 @@ static void ilk_audio_codec_disable(struct intel_encoder
> *encoder)
>  }
>  
>  static void ilk_audio_codec_enable(struct drm_connector *connector,
> -    struct intel_encoder *encoder,
> +    struct intel_encoder *intel_encoder,
>      const struct drm_display_mode
> *adjusted_mode)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> - struct intel_digital_port *intel_dig_port =
> - enc_to_dig_port(>base);
> - enum port port = intel_dig_port->port;
> + struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> >base.crtc);
>   enum pipe pipe = intel_crtc->pipe;
> + enum port port = intel_encoder->attached_port;
>   uint8_t *eld = connector->eld;
> - uint32_t eldv;
> - uint32_t tmp;
> + uint32_t tmp, eldv;
>   int len, i;
>   i915_reg_t hdmiw_hdmiedid, aud_config, aud_cntl_st, aud_cntrl_st2;
>  
> @@ -495,11 +488,10 @@ void intel_audio_codec_enable(struct intel_encoder
> *intel_encoder)
>   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>   const struct drm_display_mode *adjusted_mode = >config-
> >base.adjusted_mode;
>   struct drm_connector *connector;
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> - enum port port = intel_dig_port->port;
> + enum port port = intel_encoder->attached_port;
>  
>   connector = drm_select_eld(encoder);
>   if (!connector)
> @@ -542,11 +534,10 @@ void intel_audio_codec_enable(struct intel_encoder
> *intel_encoder)
>  void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
>  {
>   struct drm_encoder *encoder = _encoder->base;
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private 

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Store port enum in intel_encoder

2016-08-29 Thread Lyude Paul
Reviewed-by: Lyude 

On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> Storing the port enum in intel_encoder makes it convenient to know the
> port attached to an encoder. Moving the port information up from
> intel_digital_port to intel_encoder avoids unecessary intel_digital_port
> access and handles MST encoders cleanly without requiring conditional
> checks for them (thanks danvet).
> 
> v2:
> Renamed the port enum member from 'attached_port' to 'port' (danvet)
> Fixed missing initialization of port in intel_sdvo.c (danvet)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 1 +
>  drivers/gpu/drm/i915/intel_ddi.c| 1 +
>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>  drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_dsi.c| 1 +
>  drivers/gpu/drm/i915/intel_dvo.c| 2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c   | 1 +
>  drivers/gpu/drm/i915/intel_lvds.c   | 3 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c   | 1 +
>  drivers/gpu/drm/i915/intel_tv.c | 2 ++
>  11 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9cd102c..60e282d5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -185,6 +185,7 @@ enum plane {
>  #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) +
> 'A')
>  
>  enum port {
> + PORT_NONE = -1,
>   PORT_A = 0,
>   PORT_B,
>   PORT_C,
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c2df4e4..402755d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2426,6 +2426,7 @@ void intel_ddi_init(struct drm_device *dev, enum port
> port)
>   intel_dig_port->max_lanes = max_lanes;
>  
>   intel_encoder->type = INTEL_OUTPUT_UNKNOWN;
> + intel_encoder->port = port;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>   intel_encoder->cloneable = 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 364db90..cfe2f4a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5726,6 +5726,7 @@ bool intel_dp_init(struct drm_device *dev,
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>   }
>   intel_encoder->cloneable = 0;
> + intel_encoder->port = port;
>  
>   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
>   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 629337d..d1d7e91 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -540,6 +540,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
> *intel_dig_port, enum
>    DRM_MODE_ENCODER_DPMST, "DP-MST %c",
> pipe_name(pipe));
>  
>   intel_encoder->type = INTEL_OUTPUT_DP_MST;
> + intel_encoder->port = intel_dig_port->port;
>   intel_encoder->crtc_mask = 0x7;
>   intel_encoder->cloneable = 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1c700b0..68bf134 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -202,6 +202,7 @@ struct intel_encoder {
>   struct drm_encoder base;
>  
>   enum intel_output_type type;
> + enum port port;
>   unsigned int cloneable;
>   void (*hot_plug)(struct intel_encoder *);
>   bool (*compute_config)(struct intel_encoder *,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index de8e9fb..eb5cc0b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1478,6 +1478,7 @@ void intel_dsi_init(struct drm_device *dev)
>  
>   intel_connector->get_hw_state = intel_connector_get_hw_state;
>  
> + intel_encoder->port = port;
>   /*
>    * On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI
> DSI
>    * port C. BXT isn't limited like this.
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 47bdf9d..6dc2791 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -511,7 +511,9 @@ void intel_dvo_init(struct drm_device *dev)
>    "DVO %c", intel_dvo_port_name(dvo-
> >dvo_reg));
>  
>   intel_encoder->type = INTEL_OUTPUT_DVO;
> + intel_encoder->port = PORT_NONE;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
> +
>   switch (dvo->type) {
>   case INTEL_DVO_CHIP_TMDS:
>   

Re: [Intel-gfx] [PATCH] drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE to SNB

2016-08-29 Thread Chris Wilson
On Mon, Aug 29, 2016 at 09:33:18AM +0200, Maarten Lankhorst wrote:
> Op 26-08-16 om 12:59 schreef Chris Wilson:
> > According to the CI test machines, SNB also uses the
> > GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
> > GEN6_PCODE_MIN_FREQ_TABLE request.
> >
> > [  157.744641] WARNING: CPU: 5 PID: 9238 at
> > drivers/gpu/drm/i915/intel_pm.c:7760 sandybridge_pcode_write+0x141/0x200 
> > [i915]
> > [  157.744642] Missing switch case (16) in gen6_check_mailbox_status
> > [  157.744642] Modules linked in: snd_hda_intel i915 ax88179_178a usbnet 
> > mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul 
> > crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek 
> > snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me lpc_ich 
> > snd_pcm mei broadcom bcm_phy_lib tg3 ptp pps_core [last unloaded: vgem]
> > [  157.744658] CPU: 5 PID: 9238 Comm: drv_hangman Tainted: G U  W 
> > 4.8.0-rc3-CI-CI_DRM_1589+ #1
> > [  157.744658] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
> > 10/17/2011
> > [  157.744659]   88011f093a98 81426415 
> > 88011f093ae8
> > [  157.744662]   88011f093ad8 8107d2a6 
> > 1e50810d3c9f
> > [  157.744663]  88012868 0008  
> > 88012868a650
> > [  157.744665] Call Trace:
> > [  157.744669]  [] dump_stack+0x67/0x92
> > [  157.744672]  [] __warn+0xc6/0xe0
> > [  157.744673]  [] warn_slowpath_fmt+0x4a/0x50
> > [  157.744685]  [] sandybridge_pcode_write+0x141/0x200 
> > [i915]
> > [  157.744697]  [] intel_enable_gt_powersave+0x64a/0x1330 
> > [i915]
> > [  157.744712]  [] ? i9xx_emit_request+0x1b/0x80 [i915]
> > [  157.744725]  [] __i915_add_request+0x1e3/0x370 [i915]
> > [  157.744738]  [] 
> > i915_gem_do_execbuffer.isra.16+0xced/0x1b80 [i915]
> > [  157.744740]  [] ? __might_fault+0x3e/0x90
> > [  157.744752]  [] i915_gem_execbuffer2+0xc2/0x2a0 [i915]
> > [  157.744753]  [] drm_ioctl+0x207/0x4c0
> > [  157.744765]  [] ? i915_gem_execbuffer+0x360/0x360 
> > [i915]
> > [  157.744767]  [] ?  debug_lockdep_rcu_enabled+0x1d/0x20
> > [  157.744769]  [] do_vfs_ioctl+0x8e/0x680
> > [  157.744770]  [] ? __might_fault+0x87/0x90
> > [  157.744771]  [] ? __might_fault+0x3e/0x90
> > [  157.744773]  [] ?  trace_hardirqs_on_caller+0x122/0x1b0
> > [  157.744774]  [] SyS_ioctl+0x3c/0x70
> > [  157.744776]  [] entry_SYSCALL_64_fastpath+0x1c/0xac
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97491
> > Fixes: 87660502f1a4 ("drm/i915/gen6+: Interpret mailbox error flags")
> > Signed-off-by: Chris Wilson 
> > Cc: Lyude 
> > Cc: Matt Roper 
> > Cc: Maarten Lankhorst 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 729d952174d8..aba6fd036c4e 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7753,6 +7753,7 @@ static inline int gen6_check_mailbox_status(struct 
> > drm_i915_private *dev_priv)
> > case GEN6_PCODE_ILLEGAL_CMD:
> > return -ENXIO;
> > case GEN6_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
> > +   case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
> > return -EOVERFLOW;
> > case GEN6_PCODE_TIMEOUT:
> > return -ETIMEDOUT;
> 
> Isn't it more likely that 0x10 means something different?

Could well be just coincidence that it seemed to pop out of the
MIN_FREQ_TABLE write.

> I vaguely recall looking
> over the table and saw that 10h was something different entirely, but can't 
> find it back now.

I was hoping you still had the spec handy. I don't think it's that
urgent, the error value is mostly ignored :) It's adding a common WARN
that tends to get noticed.
-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/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

2016-08-29 Thread Andrea Arcangeli
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.

CC'ed Martin who filed the bz, he can reproduce too
https://bugzilla.kernel.org/show_bug.cgi?id=151731

Since you can reproduce would you have the time to test the two above
options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid
I won't be able to test it today and I'll be mostly offline for a week
starting tomorrow.

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


[Intel-gfx] ✓ Fi.CI.BAT: success for intel_opregion_get_panel_type potential bug fix

2016-08-29 Thread Patchwork
== Series Details ==

Series: intel_opregion_get_panel_type potential bug fix
URL   : https://patchwork.freedesktop.org/series/11735/
State : success

== Summary ==

Series 11735v1 intel_opregion_get_panel_type potential bug fix
http://patchwork.freedesktop.org/api/1.0/series/11735/revisions/1/mbox/


fi-bdw-5557u total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-bsw-n3050 total:252  pass:205  dwarn:0   dfail:0   fail:1   skip:46 
fi-hsw-4770k total:252  pass:228  dwarn:0   dfail:0   fail:2   skip:22 
fi-hsw-4770r total:252  pass:224  dwarn:0   dfail:0   fail:2   skip:26 
fi-ivb-3520m total:252  pass:220  dwarn:0   dfail:0   fail:1   skip:31 
fi-skl-6260u total:252  pass:236  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-6700k total:252  pass:222  dwarn:0   dfail:0   fail:2   skip:28 
fi-snb-2520m total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 
fi-snb-2600  total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 

Results at /archive/results/CI_IGT_test/Patchwork_2448/

57de27e40b9741c17c6749a366e891faf8b22fcb drm-intel-nightly: 
2016y-08m-29d-15h-38m-26s UTC integration manifest
cb6ef47 intel_opregion_get_panel_type potential bug fix

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


Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split skl_get_dpll()

2016-08-29 Thread Manasi Navare
On Mon, Aug 22, 2016 at 06:41:05PM -0700, Manasi Navare wrote:
> From: Jim Bride 
> 
> Split out the DisplayPort and HDMI pll setup code into separate
> functions and refactor the DP code does not directly depend on
> crtc state, so that the code can be used for upfront link training.
> 
> Signed-off-by: Jim Bride 
  Reviewed-by: Manasi Navare 


> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 131 
> +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |   4 ++
>  2 files changed, 87 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 61d2311..8ce220e 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1172,75 +1172,110 @@ skip_remaining_dividers:
>   return true;
>  }
>  
> -static struct intel_shared_dpll *
> -skl_get_dpll(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
> -  struct intel_encoder *encoder)
> +static bool skl_ddi_hdmi_pll_dividers(struct intel_crtc *crtc,
> +   struct intel_crtc_state *crtc_state,
> +   int clock)
>  {
> - struct intel_shared_dpll *pll;
>   uint32_t ctrl1, cfgcr1, cfgcr2;
> - int clock = crtc_state->port_clock;
> + struct skl_wrpll_params wrpll_params = { 0, };
>  
>   /*
>* See comment in intel_dpll_hw_state to understand why we always use 0
>* as the DPLL id in this function.
>*/
> -
>   ctrl1 = DPLL_CTRL1_OVERRIDE(0);
>  
> - if (encoder->type == INTEL_OUTPUT_HDMI) {
> - struct skl_wrpll_params wrpll_params = { 0, };
> + ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
>  
> - ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
> + if (!skl_ddi_calculate_wrpll(clock * 1000, _params))
> + return false;
>  
> - if (!skl_ddi_calculate_wrpll(clock * 1000, _params))
> - return NULL;
> + cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
> + DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
> + wrpll_params.dco_integer;
> +
> + cfgcr2 = DPLL_CFGCR2_QDIV_RATIO(wrpll_params.qdiv_ratio) |
> + DPLL_CFGCR2_QDIV_MODE(wrpll_params.qdiv_mode) |
> + DPLL_CFGCR2_KDIV(wrpll_params.kdiv) |
> + DPLL_CFGCR2_PDIV(wrpll_params.pdiv) |
> + wrpll_params.central_freq;
> +
> + memset(_state->dpll_hw_state, 0,
> +sizeof(crtc_state->dpll_hw_state));
> +
> + crtc_state->dpll_hw_state.ctrl1 = ctrl1;
> + crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
> + crtc_state->dpll_hw_state.cfgcr2 = cfgcr2;
> + return true;
> +}
> +
> +
> +bool skl_ddi_dp_set_dpll_hw_state(int clock,
> +   struct intel_dpll_hw_state *dpll_hw_state)
> +{
> + uint32_t ctrl1;
> +
> + /*
> +  * See comment in intel_dpll_hw_state to understand why we always use 0
> +  * as the DPLL id in this function.
> +  */
> + ctrl1 = DPLL_CTRL1_OVERRIDE(0);
> + switch (clock / 2) {
> + case 81000:
> + ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, 0);
> + break;
> + case 135000:
> + ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1350, 0);
> + break;
> + case 27:
> + ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2700, 0);
> + break;
> + /* eDP 1.4 rates */
> + case 162000:
> + ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1620, 0);
> + break;
> + case 108000:
> + ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1080, 0);
> + break;
> + case 216000:
> + ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2160, 0);
> + break;
> + }
>  
> - cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
> -  DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
> -  wrpll_params.dco_integer;
> + dpll_hw_state->ctrl1 = ctrl1;
> + return true;
> +}
>  
> - cfgcr2 = DPLL_CFGCR2_QDIV_RATIO(wrpll_params.qdiv_ratio) |
> -  DPLL_CFGCR2_QDIV_MODE(wrpll_params.qdiv_mode) |
> -  DPLL_CFGCR2_KDIV(wrpll_params.kdiv) |
> -  DPLL_CFGCR2_PDIV(wrpll_params.pdiv) |
> -  wrpll_params.central_freq;
> +static struct intel_shared_dpll *
> +skl_get_dpll(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
> +  struct intel_encoder *encoder)
> +{
> + struct intel_shared_dpll *pll;
> + int clock = crtc_state->port_clock;
> + bool bret;
> + struct intel_dpll_hw_state dpll_hw_state;
> +
> + memset(_hw_state, 0, sizeof(dpll_hw_state));
> +
> + if (encoder->type == INTEL_OUTPUT_HDMI) {
> + bret = 

[Intel-gfx] intel_opregion_get_panel_type potential bug fix

2016-08-29 Thread Sean Greenslade
Hello, all. I've been attempting to track down a bug with my Panasonic
CF-30 laptop. I have a bug report[0] submitted.

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

I see there has already been a fix for one particular laptop[1], however
my machine is not a Skylake so this fix does not apply to me. After
reading over what Ville Syrjälä wrote in the patch notes for the
get_panel_type function, I went and read part of the intel spec[2] that
describes this data, and found a discrepancy that I don't fully
understand. On page 106 of [2], there is a table that describes the
layout of the response that intel_opregion_get_panel_type parses for the
panel type. Bit 17 is listed as reserved, must be zero. On my machine,
that bit is set to one. Additionally, on my two other Intel graphics
laptops that aren't exhibiting this issue, it is also set to one,
however they both fail the existing sanity checks in the function and
revert to the VBT entry.

But now I'm in a bit over my head. I've attached the patch (applies to
drm-intel-nightly) that I used to get the full u32 response of the swsci
lookup, as well as a tentative fix. My fix checks for the reserved bit
being set incorrectly and reverts to using the VBT entry. This fixes the
regression on my CF-30, and doesn't hurt anything on my other two
machines, but I have no newer machines to test it on. Can someone look
this over and see if I'm taking the correct approach? Additionally, I
would love to know if anyone has any more information on why the
reserved bit is set (it was set on all three of my machines).

Thanks for your attention,

--Sean


[0]: https://bugs.freedesktop.org/show_bug.cgi?id=97443
[1]: https://lists.freedesktop.org/archives/intel-gfx/2016-July/100573.html
[2]: 
https://01.org/sites/default/files/documentation/acpi_igd_opregion_spec_0.pdf
diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index adca262..1c35eab 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -1059,6 +1059,7 @@ intel_opregion_get_panel_type(struct drm_i915_private *dev_priv)
 			  ret);
 		return ret;
 	}
+	DRM_DEBUG_KMS("SEAN: panel_details: 0x%08x\n", panel_details);
 
 	ret = (panel_details >> 8) & 0xff;
 	if (ret > 0x10) {
@@ -1072,6 +1073,14 @@ intel_opregion_get_panel_type(struct drm_i915_private *dev_priv)
 		return -ENODEV;
 	}
 
+	/* Bit 17 is reserved and should be zero. Observed it set to one on
+	 * a Panasonic CF-30, where it also returns the incorrect panel type.
+	 */
+	if (panel_details & (1<<17)) {
+		DRM_DEBUG_KMS("Invalid panel details, ignoring OpRegion panel type (%d)\n", ret - 1);
+		return -ENODEV;
+	}
+
 	/*
 	 * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
 	 * low vswing for eDP, whereas the VBT panel type (2) gives us normal
___
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/skl: Don't try to update plane watermarks if they haven't changed (rev3)

2016-08-29 Thread Patchwork
== Series Details ==

Series: drm/i915/skl: Don't try to update plane watermarks if they haven't 
changed (rev3)
URL   : https://patchwork.freedesktop.org/series/11654/
State : success

== Summary ==

Series 11654v3 drm/i915/skl: Don't try to update plane watermarks if they 
haven't changed
http://patchwork.freedesktop.org/api/1.0/series/11654/revisions/3/mbox/


fi-bdw-5557u total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-bsw-n3050 total:252  pass:205  dwarn:0   dfail:0   fail:1   skip:46 
fi-hsw-4770k total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
fi-hsw-4770r total:252  pass:223  dwarn:0   dfail:0   fail:2   skip:27 
fi-ivb-3520m total:252  pass:220  dwarn:0   dfail:0   fail:1   skip:31 
fi-skl-6260u total:252  pass:236  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-6700k total:252  pass:222  dwarn:0   dfail:0   fail:2   skip:28 
fi-snb-2520m total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 
fi-snb-2600  total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 

Results at /archive/results/CI_IGT_test/Patchwork_2447/

57de27e40b9741c17c6749a366e891faf8b22fcb drm-intel-nightly: 
2016y-08m-29d-15h-38m-26s UTC integration manifest
6c4a762 drm/i915/skl: Don't try to update plane watermarks if they haven't 
changed

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


Re: [Intel-gfx] S4 resume breakage with i915 driver

2016-08-29 Thread Lukas Wunner
On Mon, Aug 29, 2016 at 04:25:25PM +0100, Chris Wilson wrote:
> On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> > On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > > Hmm, this always confuses me.  Is the freeze callback called to the
> > > loader kernel?
> > 
> > It's called both in loader and target kernel, before creating or
> > restoring the image.
> 
> So the right answer for hiberation is?

According to Documentation/power/devices.txt:

"After the image has been loaded, the devices managed by the boot kernel
need to be prepared for passing control back to the image kernel.  This
is very similar to the initial steps involved in creating a system image,
and it is accomplished in the same way, using prepare, freeze, and
freeze_noirq phases.  However the devices affected by these phases are
only those having drivers in the boot kernel; other devices will still be
in whatever state the boot loader left them."

"Most often the pre-hibernation memory contents are restored successfully
and control is passed to the image kernel, which then becomes responsible
for bringing the system back to the working state.
To achieve this, the image kernel must restore the devices' pre-hibernation
functionality.  The operation is much like waking up from the memory sleep
state, although it involves different phases:
restore_noirq, restore_early, restore, complete"


If a missing i915.ko in the boot kernel's initrd causes problems, perhaps
this can be solved by amending intel_graphics_quirks() to reset the GPU?

Best regards,

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


[Intel-gfx] [PATCH v3] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

2016-08-29 Thread Lyude
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.

Simple reproduction recipe:
 - Get a SKL laptop, launch any kind of X session
 - Get two extra monitors
 - Keep hotplugging both displays (so that the display configuration
   jumps from 1 active pipe to 3 active pipes and back)
 - Eventually underrun

Changes since v1:
 - Fix incorrect use of "it's"
Changes since v2:
 - Add reproduction recipe

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
during plane updates")

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 drivers/gpu/drm/i915/intel_sprite.c  | 9 +++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..13e47a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
 
-   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!crtc->primary->state->visible)
+   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a..73a521f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct 
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;
 
-   skl_write_plane_wm(to_intel_crtc(crtc), _priv->wm.skl_results,
-  plane);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!dplane->state->visible)
+   skl_write_plane_wm(to_intel_crtc(crtc),
+  _priv->wm.skl_results, plane);
 
I915_WRITE(PLANE_CTL(pipe, plane), 0);
 
-- 
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/dp/mst: Validate modes against the available link bandwidth

2016-08-29 Thread Jim Bride
On Thu, Aug 18, 2016 at 05:11:31PM -0700, Anusha Srivatsa wrote:
> Change intel_dp_mst_mode_valid() to use available link bandwidth
> rather than the link's maximum supported bandwidth to evaluate
> whether modes are legal for the current configuration. This takes
> into account the fact that link bandwidth may already be dedicated
> to other virtual channels.
> 
> Signed-off-by: Anusha Srivatsa 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 629337d..39c58eb 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -352,16 +352,22 @@ static enum drm_mode_status
>  intel_dp_mst_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)
>  {
> - int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> + int req_pbn = 0;
> + int slots = 0;
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + struct intel_dp *intel_dp = intel_connector->mst_port;
> + struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
> +
> + req_pbn = drm_dp_calc_pbn_mode(mode->clock, 24);
> + slots = drm_dp_find_vcpi_slots(mgr, req_pbn);
>  
> - /* TODO - validate mode against available PBN for link */
>   if (mode->clock < 1)
>   return MODE_CLOCK_LOW;
>  
>   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return MODE_H_ILLEGAL;
>  
> - if (mode->clock > max_dotclk)
> + if (slots == -ENOSPC)
>   return MODE_CLOCK_HIGH;
>  
>   return MODE_OK;
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 01/17] drm/i915: Add a sw fence for collecting up dma fences

2016-08-29 Thread Chris Wilson
On Mon, Aug 29, 2016 at 04:43:04PM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> > +static void __i915_sw_fence_wake_up_all(struct i915_sw_fence *fence,
> > +   struct list_head *continuation)
> > +{
> > +   wait_queue_head_t *x = >wait;
> 
> Rather mystique variable naming to me.

From trying to keep familarity with struct completion.

> > +    * (and so added to the list to be woken).
> > +    */
> > +
> > +   smp_mb__before_spinlock();
> > +   spin_lock_irqsave_nested(>lock, flags, 1 + !!continuation);
> > +   if (continuation) {
> > +   list_splice_tail_init(>task_list, continuation);
> > +   } else {
> > +   LIST_HEAD(extra);
> > +
> > +   do {
> > +   __wake_up_locked_key(x, TASK_NORMAL, );
> 
> It might be worth mentioning here that we've rigged our callback so
> that it will be called synchronously here so that the code can be
> understood with less waitqueue internal digging.

We're not the only set of callback on this list, we also allow for
regular wait_event entries.

> > +   if (list_empty())
> > +   break;
> > +
> > +   list_splice_tail_init(, >task_list);
> > +   } while (1);
> 
> Why exactly do you loop here, shouldn't single invocation of
> __wake_up_locked_key trigger all the callbacks and result in all the
> entries being listed?

We handle recursion of fence completion by extending the task_list in
the top-level fence, and handle the extra fence to be woken (which will
remove them from the task list again) by looping.

> > +void i915_sw_fence_init(struct i915_sw_fence *fence, 
> > i915_sw_fence_notify_t fn)
> > +{
> > +   BUG_ON((unsigned long)fn & ~I915_SW_FENCE_MASK);
> > +
> > +   init_waitqueue_head(>wait);
> > +   kref_init(>kref);
> > +   atomic_set(>pending, 1);
> 
> fence->pending = ATOMIC_INIT(1);

Tried. ATOMIC_INIT is only valid in declarations.
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Don't try to update plane watermarks if they haven't changed (rev2)

2016-08-29 Thread Patchwork
== Series Details ==

Series: drm/i915/skl: Don't try to update plane watermarks if they haven't 
changed (rev2)
URL   : https://patchwork.freedesktop.org/series/11654/
State : failure

== Summary ==

Series 11654v2 drm/i915/skl: Don't try to update plane watermarks if they 
haven't changed
http://patchwork.freedesktop.org/api/1.0/series/11654/revisions/2/mbox/

Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
pass   -> FAIL   (fi-bsw-n3050)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-hsw-4770k)

fi-bdw-5557u total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-bsw-n3050 total:252  pass:204  dwarn:0   dfail:0   fail:2   skip:46 
fi-byt-n2820 total:252  pass:208  dwarn:0   dfail:0   fail:3   skip:41 
fi-hsw-4770k total:252  pass:228  dwarn:0   dfail:0   fail:2   skip:22 
fi-hsw-4770r total:252  pass:224  dwarn:0   dfail:0   fail:2   skip:26 
fi-ivb-3520m total:252  pass:220  dwarn:0   dfail:0   fail:1   skip:31 
fi-skl-6260u total:252  pass:236  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-6700k total:252  pass:222  dwarn:0   dfail:0   fail:2   skip:28 
fi-snb-2520m total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 
fi-snb-2600  total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 

Results at /archive/results/CI_IGT_test/Patchwork_2446/

f4f46e5544894b2198cdfd5a226ee587d9834cc4 drm-intel-nightly: 
2016y-08m-29d-14h-09m-23s UTC integration manifest
9d8dab1 drm/i915/skl: Don't try to update plane watermarks if they haven't 
changed

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


Re: [Intel-gfx] S4 resume breakage with i915 driver

2016-08-29 Thread Chris Wilson
On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > Hmm, this always confuses me.  Is the freeze callback called to the
> > loader kernel?
> 
> It's called both in loader and target kernel, before creating or
> restoring the image.

So the right answer for hiberation is?

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 492c4d4e5ebc..892e1626a9ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1915,6 +1915,7 @@ static int i915_pm_freeze_late(struct device *kdev)
if (ret)
return ret;
 
+   intel_gpu_reset(dev_priv, ALL_ENGINES);
return 0;
 }

-- 
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/skl: Don't try to update plane watermarks if they haven't changed

2016-08-29 Thread Jani Nikula
On Mon, 29 Aug 2016, Lyude  wrote:
> i915 sometimes needs to disable planes in the middle of an atomic
> commit, and then reenable them later in the same commit. Because of
> this, we can't make the assumption that the state of the plane actually
> changed. Since the state of the plane hasn't actually changed, neither
> have it's watermarks. And if the watermarks hasn't changed then we
> haven't populated skl_results with anything, which means we'll end up
> zeroing out a plane's watermarks in the middle of the atomic commit
> without restoring them later.

I would appreciate a (brief) description of what the failure mode is in
this case.

BR,
Jani.


>
> Changes since v1:
>  - Fix incorrect use of "it's"
>
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
> during plane updates")
>
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 7 ++-
>  drivers/gpu/drm/i915/intel_sprite.c  | 9 +++--
>  2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e4e6141..13e47a7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct 
> drm_plane *primary,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   int pipe = intel_crtc->pipe;
>  
> - skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
> + /*
> +  * We only populate skl_results on watermark updates, and if the
> +  * plane's visiblity isn't actually changing neither is its watermarks.
> +  */
> + if (!crtc->primary->state->visible)
> + skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
>  
>   I915_WRITE(PLANE_CTL(pipe, 0), 0);
>   I915_WRITE(PLANE_SURF(pipe, 0), 0);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 0df783a..73a521f 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct 
> drm_crtc *crtc)
>   const int pipe = intel_plane->pipe;
>   const int plane = intel_plane->plane + 1;
>  
> - skl_write_plane_wm(to_intel_crtc(crtc), _priv->wm.skl_results,
> -plane);
> + /*
> +  * We only populate skl_results on watermark updates, and if the
> +  * plane's visiblity isn't actually changing neither is its watermarks.
> +  */
> + if (!dplane->state->visible)
> + skl_write_plane_wm(to_intel_crtc(crtc),
> +_priv->wm.skl_results, plane);
>  
>   I915_WRITE(PLANE_CTL(pipe, plane), 0);

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


Re: [Intel-gfx] [PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

2016-08-29 Thread Jani Nikula
On Mon, 29 Aug 2016, Andrea Arcangeli  wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> If it's an Iybridge, there's no low vswing, and that explanation is
>> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> on an unpatched kernel.
>
> What I should look for when trying those two settings? Will they
> successfully fix my problem with intel_backlight with upstream 4.8-rc?
>
> I thought it had to be the same issue as on skylake as I get the
> backlight flikering at low frequency but getting brighter and darker
> in a cycle lasting a few seconds and I thought there couldn't be too
> many other random bugs that ends up with the same side effect.

Your Ivybridge does not have low voltage swing *and* low voltage swing
has nothing to do with the backlight. The regressing commit may be the
same for you, but the failure mode appears to be completely different.

BR,
Jani.




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


Re: [Intel-gfx] S4 resume breakage with i915 driver

2016-08-29 Thread Imre Deak
On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> On Mon, 29 Aug 2016 16:09:23 +0200,
> Imre Deak wrote:
> > 
> > On ma, 2016-08-29 at 15:32 +0200, Daniel Vetter wrote:
> > > On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> > > > On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> > > > > On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > > > > > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai
> > > > > > wrote:
> > > > > > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > > > > > Takashi Iwai wrote:
> > > > > > > > I had to modify the intel_gpu_reset() call because the
> > > > > > > > test was
> > > > > > > > done
> > > > > > > > on the older kernel, so it's like:
> > > > > > > > 
> > > > > > > > +   intel_gpu_reset(dev_to_i915(dev)->dev);
> > > > > > > > 
> > > > > > > > And, it seems working on HSW! \o/
> > > > > > > > 
> > > > > > > > A simple trick, better than the magical register write
> > > > > > > > revert.
> > > > > > > > I'll check other machines, too, to see whether it has
> > > > > > > > any
> > > > > > > > negative
> > > > > > > > impact.
> > > > > > > 
> > > > > > > The test results look good on all machines.
> > > > > > 
> > > > > > The theory then is that the GPU's are active across the
> > > > > > load of the
> > > > > > hibernation image and so before the GTT is updated the
> > > > > > memory
> > > > > > currently
> > > > > > in use by the GPU is reused by the system.
> > > > > > 
> > > > > > The key question then is the memory of boot kernel still in
> > > > > > place
> > > > > > during
> > > > > > the hibernate restore phase?
> > > > > 
> > > > > Before restoring the image all devices are quiesced by
> > > > > calling their
> > > > > freeze callback, so the GPU should be idle already
> > > > > in i915_pm_restore_early() already.
> > > > 
> > > > But this happens in the loader kernel, so if that doesn't have
> > > > the
> > > > driver built-in then the freeze callback won't be called
> > > > either. So any
> > > > possible BIOS related GPU activity/setup should be quiesced
> > > > from the
> > > > restore callback then.
> > > 
> > > I thought the loader kernel has an entire initrd attached, to
> > > allow stuff
> > > like typing in the disk encryption passwd. Which means we very
> > > much do
> > > load i915 in the loader kernel already.
> > 
> > AFAICS, the hibernation image is restored from a late_initcall and
> > so
> > /bin/init etc. won't be run in the loader kernel and so the driver
> > won't be loaded if built as a module.
> 
> Well, on many systems, it's explicitly triggered from initrd (at
> least, (open)SUSE does it so since ages ago).  dracut does it after
> the whole driver initializations on initrd, usually.

Right, with manual resume that will work. But it's still possible not
to have the driver configured or use kernel resume (passing resume=..).

> > But in theory at least it's
> > possible that the driver won't even be configured in the loader
> > kernel.
> > 
> > > So maybe we need to throw a gpu reset into the right hook
> > > (shutdown or
> > > whatever it was) to make sure the loader kernel really stops all
> > > gpu write
> > > cycles, including anything done due to power saving context
> > > restoring.
> > 
> > The callback called right before the hibernation image is restored
> > is
> > freeze. Shutdown is called only after creating the image, before
> > powering off.
> 
> Hmm, this always confuses me.  Is the freeze callback called to the
> loader kernel?

It's called both in loader and target kernel, before creating or
restoring the image.

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


[Intel-gfx] [PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

2016-08-29 Thread Lyude
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.

Changes since v1:
 - Fix incorrect use of "it's"

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
during plane updates")

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 drivers/gpu/drm/i915/intel_sprite.c  | 9 +++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..13e47a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
 
-   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!crtc->primary->state->visible)
+   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a..73a521f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct 
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;
 
-   skl_write_plane_wm(to_intel_crtc(crtc), _priv->wm.skl_results,
-  plane);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+   if (!dplane->state->visible)
+   skl_write_plane_wm(to_intel_crtc(crtc),
+  _priv->wm.skl_results, plane);
 
I915_WRITE(PLANE_CTL(pipe, plane), 0);
 
-- 
2.7.4

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


Re: [Intel-gfx] S4 resume breakage with i915 driver

2016-08-29 Thread Takashi Iwai
On Mon, 29 Aug 2016 16:09:23 +0200,
Imre Deak wrote:
> 
> On ma, 2016-08-29 at 15:32 +0200, Daniel Vetter wrote:
> > On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> > > On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> > > > On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > > > > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > > > > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > > > > Takashi Iwai wrote:
> > > > > > > I had to modify the intel_gpu_reset() call because the test was
> > > > > > > done
> > > > > > > on the older kernel, so it's like:
> > > > > > > 
> > > > > > > +   intel_gpu_reset(dev_to_i915(dev)->dev);
> > > > > > > 
> > > > > > > And, it seems working on HSW! \o/
> > > > > > > 
> > > > > > > A simple trick, better than the magical register write revert.
> > > > > > > I'll check other machines, too, to see whether it has any
> > > > > > > negative
> > > > > > > impact.
> > > > > > 
> > > > > > The test results look good on all machines.
> > > > > 
> > > > > The theory then is that the GPU's are active across the load of the
> > > > > hibernation image and so before the GTT is updated the memory
> > > > > currently
> > > > > in use by the GPU is reused by the system.
> > > > > 
> > > > > The key question then is the memory of boot kernel still in place
> > > > > during
> > > > > the hibernate restore phase?
> > > > 
> > > > Before restoring the image all devices are quiesced by calling their
> > > > freeze callback, so the GPU should be idle already
> > > > in i915_pm_restore_early() already.
> > > 
> > > But this happens in the loader kernel, so if that doesn't have the
> > > driver built-in then the freeze callback won't be called either. So any
> > > possible BIOS related GPU activity/setup should be quiesced from the
> > > restore callback then.
> > 
> > I thought the loader kernel has an entire initrd attached, to allow stuff
> > like typing in the disk encryption passwd. Which means we very much do
> > load i915 in the loader kernel already.
> 
> AFAICS, the hibernation image is restored from a late_initcall and so
> /bin/init etc. won't be run in the loader kernel and so the driver
> won't be loaded if built as a module.

Well, on many systems, it's explicitly triggered from initrd (at
least, (open)SUSE does it so since ages ago).  dracut does it after
the whole driver initializations on initrd, usually.

> But in theory at least it's
> possible that the driver won't even be configured in the loader kernel.
> 
> > So maybe we need to throw a gpu reset into the right hook (shutdown or
> > whatever it was) to make sure the loader kernel really stops all gpu write
> > cycles, including anything done due to power saving context restoring.
> 
> The callback called right before the hibernation image is restored is
> freeze. Shutdown is called only after creating the image, before
> powering off.

Hmm, this always confuses me.  Is the freeze callback called to the
loader kernel?


thanks,

Takashi


> 
> --Imre
> 
> > We already know that the only way to get the gpu off the context image
> > permanently is a gpu reset, so that would make some sense.
> > -Daniel
> > 
> > > 
> > > > > If we need to add a ->shutdown callback (if
> > > > > that is even called before hibernate restore) then we can only fix
> > > > > future kernels and are still susceptible to corruption when booing
> > > > > from
> > > > > old kernels.
> > > > > 
> > > > > Any one familiar with the details of the hibernation restore? (And
> > > > > how
> > > > > much relates to kexec?)
> > > > > -Chris
> > 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] S4 resume breakage with i915 driver

2016-08-29 Thread Imre Deak
On ma, 2016-08-29 at 15:32 +0200, Daniel Vetter wrote:
> On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> > On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> > > On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > > > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > > > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > > > Takashi Iwai wrote:
> > > > > > I had to modify the intel_gpu_reset() call because the test was
> > > > > > done
> > > > > > on the older kernel, so it's like:
> > > > > > 
> > > > > > +   intel_gpu_reset(dev_to_i915(dev)->dev);
> > > > > > 
> > > > > > And, it seems working on HSW! \o/
> > > > > > 
> > > > > > A simple trick, better than the magical register write revert.
> > > > > > I'll check other machines, too, to see whether it has any
> > > > > > negative
> > > > > > impact.
> > > > > 
> > > > > The test results look good on all machines.
> > > > 
> > > > The theory then is that the GPU's are active across the load of the
> > > > hibernation image and so before the GTT is updated the memory
> > > > currently
> > > > in use by the GPU is reused by the system.
> > > > 
> > > > The key question then is the memory of boot kernel still in place
> > > > during
> > > > the hibernate restore phase?
> > > 
> > > Before restoring the image all devices are quiesced by calling their
> > > freeze callback, so the GPU should be idle already
> > > in i915_pm_restore_early() already.
> > 
> > But this happens in the loader kernel, so if that doesn't have the
> > driver built-in then the freeze callback won't be called either. So any
> > possible BIOS related GPU activity/setup should be quiesced from the
> > restore callback then.
> 
> I thought the loader kernel has an entire initrd attached, to allow stuff
> like typing in the disk encryption passwd. Which means we very much do
> load i915 in the loader kernel already.

AFAICS, the hibernation image is restored from a late_initcall and so
/bin/init etc. won't be run in the loader kernel and so the driver
won't be loaded if built as a module. But in theory at least it's
possible that the driver won't even be configured in the loader kernel.

> So maybe we need to throw a gpu reset into the right hook (shutdown or
> whatever it was) to make sure the loader kernel really stops all gpu write
> cycles, including anything done due to power saving context restoring.

The callback called right before the hibernation image is restored is
freeze. Shutdown is called only after creating the image, before
powering off.

--Imre

> We already know that the only way to get the gpu off the context image
> permanently is a gpu reset, so that would make some sense.
> -Daniel
> 
> > 
> > > > If we need to add a ->shutdown callback (if
> > > > that is even called before hibernate restore) then we can only fix
> > > > future kernels and are still susceptible to corruption when booing
> > > > from
> > > > old kernels.
> > > > 
> > > > Any one familiar with the details of the hibernation restore? (And
> > > > how
> > > > much relates to kexec?)
> > > > -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 09/17] drm/i915: Expand bool interruptible to pass flags to i915_wait_request()

2016-08-29 Thread Joonas Lahtinen
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> @@ -598,7 +598,7 @@ bool __i915_spin_request(const struct 
> drm_i915_gem_request *req,
>  /**
>   * i915_wait_request - wait until execution of request has finished
>   * @req: duh!
> - * @interruptible: do an interruptible wait (normally yes)

Because we use INTERRUPTIBLE as default, one might make the flag
UNINTERRUPTIBLE and omit it mostly?



> +#define I915_WAIT_INTERRUPTIBLE BIT(0)
>  

With or without that;

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 08/17] drm/i915: Drop local struct_mutex around intel_init_emon[ilk]

2016-08-29 Thread Joonas Lahtinen
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> Access to intel_init_emon() is strictly ordered by gt_powersave, using

How exactly?

> struct_mutex around it is overkill (and will conflict with the caller
> holding struct_mutex themselves).
> 
> Signed-off-by: Chris Wilson 

Was this intentionally added to the series? Maybe a splat could be
included.

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 08/17] drm/i915: Drop local struct_mutex around intel_init_emon[ilk]

2016-08-29 Thread Mika Kuoppala
Chris Wilson  writes:

> Access to intel_init_emon() is strictly ordered by gt_powersave, using
> struct_mutex around it is overkill (and will conflict with the caller
> holding struct_mutex themselves).
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index aba6fd036c4e..5e2a33d066c4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6773,9 +6773,7 @@ void intel_autoenable_gt_powersave(struct 
> drm_i915_private *dev_priv)
>  
>   if (IS_IRONLAKE_M(dev_priv)) {
>   ironlake_enable_drps(dev_priv);
> - mutex_lock(_priv->drm.struct_mutex);
>   intel_init_emon(dev_priv);
> - mutex_unlock(_priv->drm.struct_mutex);
>   } else if (INTEL_INFO(dev_priv)->gen >= 6) {
>   /*
>* PCU communication is slow and this doesn't need to be
> -- 
> 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


Re: [Intel-gfx] [PATCH 01/17] drm/i915: Add a sw fence for collecting up dma fences

2016-08-29 Thread Joonas Lahtinen
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> +static void i915_sw_fence_free(struct kref *kref)
> +{
> + struct i915_sw_fence *fence = container_of(kref, typeof(*fence), kref);
> +
> + WARN_ON(atomic_read(>pending) > 0);
> +
> + if (fence->flags & I915_SW_FENCE_MASK)
> + WARN_ON(__i915_sw_fence_notify(fence) != NOTIFY_DONE);

Suspicious to call _notify from free without any notification type
parameter. Better add the notification type parameter.

> +static void __i915_sw_fence_wake_up_all(struct i915_sw_fence *fence,
> + struct list_head *continuation)
> +{
> + wait_queue_head_t *x = >wait;

Rather mystique variable naming to me.

> + unsigned long flags;
> +
> + atomic_set(>pending, -1); /* 0 -> -1 [done] */
> +
> + /*
> +  * To prevent unbounded recursion as we traverse the graph of
> +  * i915_sw_fences, we move the task_list from this the next ready
> +  * fence to the tail of the original fence's task_list

".. from this the next ready fence to ..." Strange expression.

> +  * (and so added to the list to be woken).
> +  */
> +
> + smp_mb__before_spinlock();
> + spin_lock_irqsave_nested(>lock, flags, 1 + !!continuation);
> + if (continuation) {
> + list_splice_tail_init(>task_list, continuation);
> + } else {
> + LIST_HEAD(extra);
> +
> + do {
> + __wake_up_locked_key(x, TASK_NORMAL, );

It might be worth mentioning here that we've rigged our callback so
that it will be called synchronously here so that the code can be
understood with less waitqueue internal digging.

> +
> + if (list_empty())
> + break;
> +
> + list_splice_tail_init(, >task_list);
> + } while (1);

Why exactly do you loop here, shouldn't single invocation of
__wake_up_locked_key trigger all the callbacks and result in all the
entries being listed?

> +void i915_sw_fence_init(struct i915_sw_fence *fence, i915_sw_fence_notify_t 
> fn)
> +{
> + BUG_ON((unsigned long)fn & ~I915_SW_FENCE_MASK);
> +
> + init_waitqueue_head(>wait);
> + kref_init(>kref);
> + atomic_set(>pending, 1);

fence->pending = ATOMIC_INIT(1);

> +static bool i915_sw_fence_check_if_after(struct i915_sw_fence *fence,
> +   const struct i915_sw_fence * const signaler)

Naming is still bad, but _err_if_after is not much better.

With above addressed;

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

2016-08-29 Thread Andrea Arcangeli
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.

What I should look for when trying those two settings? Will they
successfully fix my problem with intel_backlight with upstream 4.8-rc?

I thought it had to be the same issue as on skylake as I get the
backlight flikering at low frequency but getting brighter and darker
in a cycle lasting a few seconds and I thought there couldn't be too
many other random bugs that ends up with the same side effect.

It looks like the hardware actually broke, software issue isn't the
first thing that comes to mind. As it's hard to imagine a timer in the
kernel reprogramming the backlight setting higher and lower just to
annoy me :). First in fact I thought at a plasma issue, but I tried to
downgrade the kernel first as that was quicker than downgrading
kde/plasma... I initially thought there were two userland daemons
stepping into each other toes.

Another thing is that if I keep decreasing the brightness the screen
eventually goes off and it returns on as I increase the backlight
level again (then low freq flickering starts). With acpi_video0 even
at the lowest brightness setting of 0, it never turns off the screen
completely.

> Doesn't mean there can't be something else wrong with the mode you get
> using a different panel_type. And this makes me wonder what the point is
> in trying to patch up the commit instead of reverting.

Reverting the whole thing would be sure fine with me, I don't know
what the benefits there should be in using intel_backlight instead of
acpi_video0 like the previous code did, but I couldn't imagine too
many hw to behave like this if intel_backlight clearly has to work
stable for someone or it wouldn't exist in the first place.

This is just a "echo " into a backlight file if I tweak the backlight
settings... doesn't sound performance critical stuff to me, ACPI will
do just fine. However I'm not even sure how this problem could surface
in the first place without the kernel continuously reprogramming the
hw values.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] S4 resume breakage with i915 driver

2016-08-29 Thread Daniel Vetter
On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> > On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > > Takashi Iwai wrote:
> > > > > I had to modify the intel_gpu_reset() call because the test was
> > > > > done
> > > > > on the older kernel, so it's like:
> > > > > 
> > > > > +   intel_gpu_reset(dev_to_i915(dev)->dev);
> > > > > 
> > > > > And, it seems working on HSW! \o/
> > > > > 
> > > > > A simple trick, better than the magical register write revert.
> > > > > I'll check other machines, too, to see whether it has any
> > > > > negative
> > > > > impact.
> > > > 
> > > > The test results look good on all machines.
> > > 
> > > The theory then is that the GPU's are active across the load of the
> > > hibernation image and so before the GTT is updated the memory
> > > currently
> > > in use by the GPU is reused by the system.
> > > 
> > > The key question then is the memory of boot kernel still in place
> > > during
> > > the hibernate restore phase?
> > 
> > Before restoring the image all devices are quiesced by calling their
> > freeze callback, so the GPU should be idle already
> > in i915_pm_restore_early() already.
> 
> But this happens in the loader kernel, so if that doesn't have the
> driver built-in then the freeze callback won't be called either. So any
> possible BIOS related GPU activity/setup should be quiesced from the
> restore callback then.

I thought the loader kernel has an entire initrd attached, to allow stuff
like typing in the disk encryption passwd. Which means we very much do
load i915 in the loader kernel already.

So maybe we need to throw a gpu reset into the right hook (shutdown or
whatever it was) to make sure the loader kernel really stops all gpu write
cycles, including anything done due to power saving context restoring. We
already know that the only way to get the gpu off the context image
permanently is a gpu reset, so that would make some sense.
-Daniel

> 
> > > If we need to add a ->shutdown callback (if
> > > that is even called before hibernate restore) then we can only fix
> > > future kernels and are still susceptible to corruption when booing
> > > from
> > > old kernels.
> > > 
> > > Any one familiar with the details of the hibernation restore? (And
> > > how
> > > much relates to kexec?)
> > > -Chris

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


[Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

2016-08-29 Thread Kumar, Mahesh
This patch enables Transition WM for SKL+ platforms.

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

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9f69050..f4f387f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2861,6 +2861,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
 #define SKL_DDB_SIZE   896 /* in blocks */
 #define BXT_DDB_SIZE   512
 #define SKL_SAGV_BLOCK_TIME30 /* µs */
+#define SKL_TRANS_WM_AMOUNT10
+#define SKL_TRANS_WM_MIN   14
 
 /*
  * Return the index of a plane in the SKL DDB and wm result arrays.  Primary
@@ -3579,6 +3581,41 @@ static uint32_t skl_adjusted_plane_pixel_rate(const 
struct intel_crtc_state *cst
return pixel_rate;
 }
 
+static void skl_compute_plane_trans_wm(const struct drm_i915_private *dev_priv,
+   struct skl_pipe_wm *pipe_wm,
+   struct intel_plane_state *intel_pstate,
+   uint32_t y_tile_min,
+   bool y_tile)
+{
+   struct drm_plane_state *pstate = _pstate->base;
+   int id = skl_wm_plane_id(to_intel_plane(pstate->plane));
+   uint16_t *out_blocks = _wm->trans_wm.plane_res_b[id];
+   uint8_t *out_lines = _wm->trans_wm.plane_res_l[id];
+   uint16_t res_blocks = pipe_wm->wm[0].plane_res_b[id];
+   uint32_t trans_min = 0, trans_offset_blocks;
+   uint16_t trans_y_tile_min = 0;
+   uint16_t trans_res_blocks;
+
+
+   if (IS_GEN9(dev_priv))
+   trans_min = SKL_TRANS_WM_MIN;
+
+   trans_offset_blocks = trans_min + SKL_TRANS_WM_AMOUNT;
+
+   if (y_tile) {
+   trans_y_tile_min = 2 * y_tile_min;
+   trans_res_blocks = max(trans_y_tile_min, res_blocks) +
+   trans_offset_blocks;
+   } else {
+   trans_res_blocks = res_blocks + trans_offset_blocks;
+   /* WA BUG:1938466 add one block for non y-tile planes */
+   trans_res_blocks += 1;
+   }
+
+   *out_blocks = trans_res_blocks;
+   *out_lines = 0;
+}
+
 static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
struct intel_plane_state *intel_pstate,
@@ -3600,6 +3637,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
struct skl_wm_level *result = _wm->wm[level];
uint16_t *out_blocks = >plane_res_b[id];
uint8_t *out_lines = >plane_res_l[id];
+   uint32_t y_tile_minimum = 0;
+   bool y_tile = false;
 
if (latency == 0 || !cstate->base.active || !intel_pstate->base.visible)
return 0;
@@ -3627,7 +3666,6 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
uint32_t min_scanlines = 4;
-   uint32_t y_tile_minimum;
if (intel_rotation_90_or_270(pstate->rotation)) {
int cpp = (fb->pixel_format == DRM_FORMAT_NV12) ?
drm_format_plane_cpp(fb->pixel_format, 1) :
@@ -3646,6 +3684,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
y_tile_minimum = plane_blocks_per_line * min_scanlines;
selected_result = max(method2, y_tile_minimum);
+   y_tile = true;
} else {
linetime_us = DIV_ROUND_UP(width * 1000,
skl_pipe_pixel_rate(cstate));
@@ -3669,6 +3708,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
*out_blocks = res_blocks;
*out_lines = res_lines;
 
+   if (level == 0)
+   skl_compute_plane_trans_wm(dev_priv, pipe_wm, intel_pstate,
+   y_tile_minimum, y_tile);
return 0;
 }
 
@@ -3738,11 +3780,13 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
 }
 
 static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
- struct skl_wm_level *trans_wm /* out */)
+ struct skl_wm_level *trans_wm,
+ struct skl_ddb_allocation *ddb)
 {
struct drm_crtc *crtc = cstate->base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_plane *intel_plane;
+   enum pipe pipe = to_intel_crtc(crtc)->pipe;
 
if 

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

2016-08-29 Thread Kumar, Mahesh
This patch make changes to use linetime latency instead of allocated
DDB size during plane watermark calculation in switch case, This is
required to implement new DDB allocation algorithm.

In New Algorithm DDB is allocated based on WM values, because of which
number of DDB blocks will not be available during WM calculation,
So this "linetime latency" is suggested by SV/HW team to use during
switch-case for WM blocks selection.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index aba6fd0..b2f17eb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3554,6 +3554,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint8_t cpp;
uint32_t width = 0, height = 0;
uint32_t plane_pixel_rate;
+   uint32_t linetime_us = 0;
 
if (latency == 0 || !cstate->base.active || 
!intel_pstate->base.visible) {
*enabled = false;
@@ -3603,7 +3604,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
y_tile_minimum = plane_blocks_per_line * min_scanlines;
selected_result = max(method2, y_tile_minimum);
} else {
-   if ((ddb_allocation / plane_blocks_per_line) >= 1)
+   linetime_us = DIV_ROUND_UP(width * 1000,
+   skl_pipe_pixel_rate(cstate));
+   if (latency >= linetime_us)
selected_result = min(method1, method2);
else
selected_result = method1;
-- 
2.8.3

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


Re: [Intel-gfx] [PATCH 06/17] drm/i915: Simplify ELSP queue request tracking

2016-08-29 Thread Mika Kuoppala
Chris Wilson  writes:

> Emulate HW to track and manage ELSP queue. A set of SW ports are defined
> and requests are assigned to these ports before submitting them to HW. This
> helps in cleaning up incomplete requests during reset recovery easier
> especially after engine reset by decoupling elsp queue management. This
> will become more clear in the next patch.
>
> In the engine reset case we want to resume where we left-off after skipping
> the incomplete batch which requires checking the elsp queue, removing
> element and fixing elsp_submitted counts in some cases. Instead of directly
> manipulating the elsp queue from reset path we can examine these ports, fix
> up ringbuffer pointers using the incomplete request and restart submissions
> again after reset.
>
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> Cc: Arun Siluvery 
> Signed-off-by: Chris Wilson 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1470414607-32453-3-git-send-email-arun.siluv...@linux.intel.com
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |   2 +-
>  drivers/gpu/drm/i915/i915_gem.c |  13 +-
>  drivers/gpu/drm/i915/i915_gem_request.c |   1 -
>  drivers/gpu/drm/i915/i915_gem_request.h |  21 +-
>  drivers/gpu/drm/i915/intel_lrc.c| 405 
> ++--
>  drivers/gpu/drm/i915/intel_lrc.h|   2 -
>  drivers/gpu/drm/i915/intel_ringbuffer.h |   7 +-
>  7 files changed, 188 insertions(+), 263 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d89359a50742..5f932ebc6ff1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2074,7 +2074,7 @@ static int i915_execlists(struct seq_file *m, void 
> *data)
>   status_pointer = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
>   seq_printf(m, "\tStatus pointer: 0x%08X\n", status_pointer);
>  
> - read_pointer = engine->next_context_status_buffer;
> + read_pointer = GEN8_CSB_READ_PTR(status_pointer);
>   write_pointer = GEN8_CSB_WRITE_PTR(status_pointer);
>   if (read_pointer > write_pointer)
>   write_pointer += GEN8_CSB_ENTRIES;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d37b44126942..838a275e7fac 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2575,6 +2575,9 @@ static void i915_gem_reset_engine_cleanup(struct 
> intel_engine_cs *engine)
>   struct drm_i915_gem_request *request;
>   struct intel_ring *ring;
>  
> + /* Ensure irq handler finishes, and not run again. */
> + tasklet_kill(>irq_tasklet);
> +
>   /* Mark all pending requests as complete so that any concurrent
>* (lockless) lookup doesn't try and wait upon the request as we
>* reset it.
> @@ -2588,10 +2591,12 @@ static void i915_gem_reset_engine_cleanup(struct 
> intel_engine_cs *engine)
>*/
>  
>   if (i915.enable_execlists) {
> - /* Ensure irq handler finishes or is cancelled. */
> - tasklet_kill(>irq_tasklet);
> -
> - intel_execlists_cancel_requests(engine);
> + spin_lock(>execlist_lock);
> + INIT_LIST_HEAD(>execlist_queue);
> + i915_gem_request_put(engine->execlist_port[0].request);
> + i915_gem_request_put(engine->execlist_port[1].request);
> + memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
> + spin_unlock(>execlist_lock);
>   }
>  
>   /*
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 9cc08a1e43c6..ec613fd5e01c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -402,7 +402,6 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
>   req->previous_context = NULL;
>   req->file_priv = NULL;
>   req->batch = NULL;
> - req->elsp_submitted = 0;
>  
>   /*
>* Reserve space in the ring buffer for all the commands required to
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
> b/drivers/gpu/drm/i915/i915_gem_request.h
> index 2faa3bb4c39b..a231bd318ef0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -137,27 +137,8 @@ struct drm_i915_gem_request {
>   /** file_priv list entry for this request */
>   struct list_head client_list;
>  
> - /**
> -  * The ELSP only accepts two elements at a time, so we queue
> -  * context/tail pairs on a given queue (ring->execlist_queue) until the
> -  * hardware is available. The queue serves a double purpose: we also use
> -  * it to keep track of the up to 2 contexts currently in the hardware
> -  * (usually one in 

[Intel-gfx] [PATCH 4/7] drm/i915/skl: New ddb allocation algorithm

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

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5fa02cb..9f69050 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3331,6 +3331,7 @@ skl_ddb_min_alloc(const struct drm_plane_state *pstate,
 
 static int
 skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
+ struct skl_pipe_wm *pipe_wm,
  struct skl_ddb_allocation *ddb /* out */)
 {
struct drm_atomic_state *state = cstate->base.state;
@@ -3346,8 +3347,11 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
uint16_t *minimum = cstate->wm.skl.minimum_blocks;
uint16_t *y_minimum = cstate->wm.skl.minimum_y_blocks;
unsigned int total_data_rate;
+   uint16_t total_min_blocks = 0;
+   uint16_t total_level_ddb = 0;
int num_active;
-   int id, i;
+   int max_level, level;
+   int id, i, ret = 0;
 
if (WARN_ON(!state))
return 0;
@@ -3363,6 +3367,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
alloc_size = skl_ddb_entry_size(alloc);
if (alloc_size == 0) {
memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
+   memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
return 0;
}
 
@@ -3396,19 +3401,42 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
}
 
for (i = 0; i < PLANE_CURSOR; i++) {
-   alloc_size -= minimum[i];
-   alloc_size -= y_minimum[i];
+   total_min_blocks += minimum[i];
+   total_min_blocks += y_minimum[i];
}
 
-   /*
-* 2. Distribute the remaining space in proportion to the amount of
-* data each plane needs to fetch from memory.
-*
-* FIXME: we may not allocate every single block here.
-*/
+   for (level = ilk_wm_max_level(dev); level >= 0; level--) {
+   total_level_ddb = 0;
+   for (i = 0; i < PLANE_CURSOR; i++) {
+   /*
+* TODO: We should calculate watermark values for Y/UV
+* plane both in case of NV12 format and use both values
+* for ddb calculation, As NV12 is disabled as of now.
+* using only single plane value here.
+*/
+   uint16_t min = minimum[i] + y_minimum[i];
+   uint16_t plane_level_ddb_wm =
+   max(pipe_wm->wm[level].plane_res_b[i], min);
+   total_level_ddb += plane_level_ddb_wm;
+   }
+
+   if (total_level_ddb <= alloc_size)
+   break;
+   }
+
+   if ((level < 0) || (total_min_blocks > alloc_size)) {
+   DRM_DEBUG_KMS("Requested display configuration exceeds system 
DDB limitations");
+   DRM_DEBUG_KMS("minimum required %d/%d\n", (level < 0) ?
+   total_level_ddb : total_min_blocks, alloc_size);
+   ret = -EINVAL;
+   goto exit;
+   }
+   max_level = level;
+   alloc_size -= total_level_ddb;
+
total_data_rate = skl_get_total_relative_data_rate(cstate);
if (total_data_rate == 0)
-   return 0;
+   goto exit;
 
start = alloc->start;
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
@@ -3423,7 +3451,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
 * promote the expression to 64 bits to avoid overflowing, the
 * result is < available as data_rate / total_data_rate < 1
 */
-   plane_blocks = minimum[id];
+   plane_blocks = max(pipe_wm->wm[max_level].plane_res_b[id],
+   minimum[id]);
plane_blocks += div_u64((uint64_t)alloc_size * data_rate,
total_data_rate);
 
@@ -3437,6 +3466,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
 
/*
 * allocation for y_plane part of planar format:
+* TODO: Once we start calculating watermark values for Y/UV
+* plane both consider it for initial allowed wm blocks.
 */
y_data_rate = cstate->wm.skl.plane_y_data_rate[id];
 
@@ -3450,9 +3481,22 @@ skl_allocate_pipe_ddb(struct 

[Intel-gfx] [PATCH 5/7] drm/i915: Decode system memory bandwidth

2016-08-29 Thread Kumar, Mahesh
This patch adds support to decode system memory bandwidth
which will be used for arbitrated display memory percentage
calculation in GEN9 based system.

Signed-off-by: Kumar, Mahesh 
---
 drivers/gpu/drm/i915/i915_drv.c | 96 +
 drivers/gpu/drm/i915/i915_drv.h | 18 
 drivers/gpu/drm/i915/i915_reg.h | 25 +++
 3 files changed, 139 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 47fe072..5ece036 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -996,6 +996,96 @@ static void intel_sanitize_options(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", yesno(i915.semaphores));
 }
 
+static void
+intel_get_memdev_info(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   uint32_t val = 0;
+   uint32_t mem_speed = 0;
+   uint8_t dram_type;
+   uint32_t dram_channel;
+   uint8_t num_channel;
+   bool rank_valid = false;
+
+   if (!IS_GEN9(dev_priv))
+   goto exit;
+
+   val = I915_READ(P_CR_MC_BIOS_REQ_0_0_0);
+   mem_speed = div_u64((uint64_t) (val & REQ_DATA_MASK) *
+   MEMORY_FREQ_MULTIPLIER, 1000);
+
+   if (mem_speed == 0)
+   goto exit;
+
+   dev_priv->memdev_info.valid = true;
+   dev_priv->memdev_info.mem_speed = mem_speed;
+   dram_type = (val >> DRAM_TYPE_SHIFT) & DRAM_TYPE_MASK;
+   dram_channel = (val >> DRAM_CHANNEL_SHIFT) & DRAM_CHANNEL_MASK;
+   num_channel = hweight32(dram_channel);
+
+   /*
+* The lpddr3 and lpddr4 technologies can have 1-4 channels and the
+* channels are 32bits wide; while ddr3l technologies can have 1-2
+* channels and the channels are 64 bits wide. But SV team found that in
+* case of single 64 bit wide DDR3L dimms two bits were set and system
+* with two DDR3L 64bit dimm all four bits were set.
+*/
+
+   switch (dram_type) {
+   case DRAM_TYPE_LPDDR3:
+   case DRAM_TYPE_LPDDR4:
+   dev_priv->memdev_info.data_width = 4;
+   dev_priv->memdev_info.num_channel = num_channel;
+   break;
+   case DRAM_TYPE_DDR3L:
+   dev_priv->memdev_info.data_width = 8;
+   dev_priv->memdev_info.num_channel = num_channel / 2;
+   break;
+   default:
+   dev_priv->memdev_info.data_width = 4;
+   dev_priv->memdev_info.num_channel = num_channel;
+   }
+
+   /*
+* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
+* all the dimms should have same rank as in first valid Dimm
+*/
+#define D_CR_DRP0_DUNIT_INVALID0x
+
+   dev_priv->memdev_info.rank_valid = true;
+   if (I915_READ(D_CR_DRP0_DUNIT8) != D_CR_DRP0_DUNIT_INVALID) {
+   val = I915_READ(D_CR_DRP0_DUNIT8);
+   rank_valid = true;
+   } else if (I915_READ(D_CR_DRP0_DUNIT9) != D_CR_DRP0_DUNIT_INVALID) {
+   val = I915_READ(D_CR_DRP0_DUNIT9);
+   rank_valid = true;
+   } else if (I915_READ(D_CR_DRP0_DUNIT10) != D_CR_DRP0_DUNIT_INVALID) {
+   val = I915_READ(D_CR_DRP0_DUNIT10);
+   rank_valid = true;
+   } else if (I915_READ(D_CR_DRP0_DUNIT11) != D_CR_DRP0_DUNIT_INVALID) {
+   val = I915_READ(D_CR_DRP0_DUNIT11);
+   rank_valid = true;
+   }
+#undef D_CR_DRP0_DUNIT_INVALID
+
+   if (rank_valid) {
+   dev_priv->memdev_info.rank_valid = true;
+   dev_priv->memdev_info.rank = (val & DRAM_RANK_MASK);
+   }
+
+   DRM_DEBUG_DRIVER("valid:%s speed-%d width-%d num_channel-%d\n",
+   dev_priv->memdev_info.valid ? "true" : "false",
+   dev_priv->memdev_info.mem_speed,
+   dev_priv->memdev_info.data_width,
+   dev_priv->memdev_info.num_channel);
+   DRM_DEBUG_DRIVER("rank_valid:%s rank-%d\n",
+   dev_priv->memdev_info.rank_valid ? "true" : "false",
+   dev_priv->memdev_info.rank);
+   return;
+exit:
+   dev_priv->memdev_info.valid = false;
+}
+
 /**
  * i915_driver_init_hw - setup state requiring device access
  * @dev_priv: device private
@@ -1099,6 +1189,12 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_DRIVER("can't enable MSI");
}
 
+   /*
+* Fill the memdev structure to get the system raw bandwidth
+* This will be used by WM algorithm, to implement GEN9 based WA
+*/
+   intel_get_memdev_info(dev);
+
return 0;
 
 out_ggtt:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77a5478..d0123f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2017,6 +2017,24 @@ struct drm_i915_private {
  

[Intel-gfx] [PATCH 0/7] Implement New DDB allocation algorithm

2016-08-29 Thread Kumar, Mahesh
This series implements new DDB allocation algorithm to solve the cases,
where we have sufficient DDB available to enable multiple planes, But
due to the current algorithm not dividing it properly among planes, we
end-up failing the flip.
It also takes care of enabling same watermark level for each
plane, for efficient power saving.
This series also implements Transition Watermarks and Gen-9 related
arbitrated display bandwidth Workarounds.

There are two steps in current WM programming.

1. Calculate minimum number of blocks required  for a WM level to be
enabled. For 1440x2560 panel we need 41 blocks as minimum number of
blocks to enable WM0. This is the step which doesn't use vertical size.
It only depends on Pipe drain rate and plane horizontal size as per the
current Bspec algorithm.
So all the plane below have minimum  number of blocks required to enable
WM0 as 41
Plane 1  - 1440x2560-Min blocks to enable WM0 = 41
Plane 2  - 1440x2560-Min blocks to enable WM0 = 41
Plane 3  - 1440x48  -Min blocks to enable WM0 = 41
Plane 4  - 1440x96  -Min blocks to enable WM0 = 41

2. Number of blocks allotted by the driver
Driver allocates  12 for Plane 3   &  16 for plane 4

Total Dbuf Available = 508
Dbuf Available after 32 blocks for cursor = 508 - (32)  = 476
allocate minimum blocks for each plane 8 * 4 = 32
remaining blocks = 476 - 32 = 444
Relative Data Rate for Planes
   Plane 1  =  1440 * 2560 * 3  =  11059200
   Plane 2  =  1440 * 2560 * 3  =  11059200
   Plane 3  =  1440 * 48   * 3  =  207360
   Plane 4  =  1440 * 96   * 3  =  414720
   Total Relative BW=  22740480

-   Allocate Buffer
buffer allocation = (Plane relative data rate / total data rate)
* total remaming DDB + minimum plane DDB
 Plane 1  buffer allocation = (11059200 / 22740480) * 444 + 8 = 223
 Plane 2  buffer allocation = (11059200 / 22740480) * 444 + 8 = 223
 Plane 3  buffer allocation = (207360   / 22740480) * 444 + 8 = 12
 Plane 4  buffer allocation = (414720   / 22740480) * 444 + 8 = 16

In this case it forced driver to disable Plane 3 & 4. Driver need to use
more efficient way to allocate buffer that is optimum for power.

New Algorithm suggested by HW team is:

1. Calculate minimum buffer allocations for each plane and for each
watermark level

2. Add minimum buffer allocations required for enabling WM7
for all the planes

Level 0 =  41 + 41 + 41 + 41  = 164
Level 1 =  42 + 42 + 42 + 42  = 168
Level 2 =  42 + 42 + 42 + 42  = 168
Level 3 =  94 + 94 + 94 + 94 =  376
Level 4 =  94 + 94 + 94 + 94 =  376
Level 5 =  94 + 94 + 94 + 94 =  376
Level 6 =  94 + 94 + 94 + 94 =  376
Level 7 =  94 + 94 + 94 + 94 =  376

3. Check to see how many buffer allocation are left and enable
the best case. In this case since we have 476 blocks we can enable
WM0-7 on all 4 planes.
Let's say if we have only 200 block available then the best cases
allocation is to enable Level2 which requires 168 blocks

Kumar, Mahesh (7):
  drm/i915/hsw+: set intel_crtc active once pipe is active
  drm/i915/skl+: use linetime latency instead of ddb size
  drm/i915/skl: pass pipe_wm in skl_compute_(wm_level/plane_wm)
functions
  drm/i915/skl: New ddb allocation algorithm
  drm/i915: Decode system memory bandwidth
  FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM
  drm/i915/gen9: WM memory bandwidth related workaround

 drivers/gpu/drm/i915/i915_drv.c  |  96 +
 drivers/gpu/drm/i915/i915_drv.h  |  27 +++
 drivers/gpu/drm/i915/i915_reg.h  |  25 +++
 drivers/gpu/drm/i915/intel_display.c |   4 +-
 drivers/gpu/drm/i915/intel_drv.h |  11 ++
 drivers/gpu/drm/i915/intel_pm.c  | 366 +++
 6 files changed, 447 insertions(+), 82 deletions(-)

-- 
2.8.3

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


[Intel-gfx] [PATCH] drm/i915/gen9: WM memory bandwidth related workaround

2016-08-29 Thread Kumar, Mahesh
This patch implemnets Workariunds related to display arbitrated memory
bandwidth. These WA are applicabe for all gen-9 based platforms.

Signed-off-by: Kumar, Mahesh 
---
 drivers/gpu/drm/i915/i915_drv.h  |   9 +++
 drivers/gpu/drm/i915/intel_drv.h |  11 +++
 drivers/gpu/drm/i915/intel_pm.c  | 145 +++
 3 files changed, 165 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0123f8..095af6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1055,6 +1055,13 @@ enum intel_sbi_destination {
SBI_MPHY,
 };
 
+/* SKL+ Watermark arbitrated display bandwidth Workarounds */
+enum watermark_memory_wa {
+   WATERMARK_WA_NONE,
+   WATERMARK_WA_X_TILED,
+   WATERMARK_WA_Y_TILED,
+};
+
 #define QUIRK_PIPEA_FORCE (1<<0)
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
 #define QUIRK_INVERT_BRIGHTNESS (1<<2)
@@ -1604,6 +1611,8 @@ struct skl_ddb_allocation {
 
 struct skl_wm_values {
unsigned dirty_pipes;
+   /* any WaterMark memory workaround Required */
+   enum watermark_memory_wa mem_wa;
struct skl_ddb_allocation ddb;
uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 570a7ca..f2c38cc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1807,6 +1807,17 @@ intel_atomic_get_crtc_state(struct drm_atomic_state 
*state,
return to_intel_crtc_state(crtc_state);
 }
 
+static inline struct intel_crtc_state *
+intel_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state, >base);
+
+   return to_intel_crtc_state(crtc_state);
+}
+
 static inline struct intel_plane_state *
 intel_atomic_get_existing_plane_state(struct drm_atomic_state *state,
  struct intel_plane *plane)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ac0d0ca..e9cd6ac 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3624,6 +3624,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 {
struct drm_plane_state *pstate = _pstate->base;
struct drm_framebuffer *fb = pstate->fb;
+   struct intel_atomic_state *intel_state =
+   to_intel_atomic_state(cstate->base.state);
uint32_t latency = dev_priv->wm.skl_latency[level];
uint32_t method1, method2;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -3639,10 +3641,17 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint8_t *out_lines = >plane_res_l[id];
uint32_t y_tile_minimum = 0;
bool y_tile = false;
+   enum watermark_memory_wa mem_wa;
 
if (latency == 0 || !cstate->base.active || !intel_pstate->base.visible)
return 0;
 
+   mem_wa = intel_state ? intel_state->wm_results.mem_wa : 
WATERMARK_WA_NONE;
+   if (mem_wa != WATERMARK_WA_NONE) {
+   if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
+   latency += 15;
+   }
+
width = drm_rect_width(_pstate->base.src) >> 16;
height = drm_rect_height(_pstate->base.src) >> 16;
 
@@ -3682,6 +3691,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
WARN(1, "Unsupported pixel depth for rotation");
}
}
+   if (mem_wa == WATERMARK_WA_Y_TILED)
+   min_scanlines *= 2;
+
y_tile_minimum = plane_blocks_per_line * min_scanlines;
selected_result = max(method2, y_tile_minimum);
y_tile = true;
@@ -4065,6 +4077,15 @@ skl_include_affected_pipes(struct drm_atomic_state 
*state)
intel_state->wm_results.dirty_pipes = ~0;
}
 
+   /*
+* If Watermark workaround is changed we need to recalculate
+* watermark values for all active pipes
+*/
+   if (intel_state->wm_results.mem_wa != dev_priv->wm.skl_hw.mem_wa) {
+   realloc_pipes = ~0;
+   intel_state->wm_results.dirty_pipes = ~0;
+   }
+
for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
struct intel_crtc_state *cstate;
 
@@ -4081,6 +4102,128 @@ skl_include_affected_pipes(struct drm_atomic_state 
*state)
 }
 
 static void
+skl_set_memory_bandwidth_wm_wa(struct drm_atomic_state *state)
+{
+   struct drm_device *dev = state->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *intel_crtc;
+   struct intel_plane_state *intel_pstate;
+   struct 

[Intel-gfx] [PATCH 3/7] drm/i915/skl: pass pipe_wm in skl_compute_(wm_level/plane_wm) functions

2016-08-29 Thread Kumar, Mahesh
This patch make use of plane_wm variable directly instead of passing
skl_plane_wm struct. this way reduces number of argument requirement
in watermark calculation functions.

It also gives more freedom of decision making to implement Bspec WM
workarounds.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b2f17eb..5fa02cb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3540,9 +3540,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
struct intel_plane_state *intel_pstate,
uint16_t ddb_allocation,
int level,
-   uint16_t *out_blocks, /* out */
-   uint8_t *out_lines, /* out */
-   bool *enabled /* out */)
+   struct skl_pipe_wm *pipe_wm)
 {
struct drm_plane_state *pstate = _pstate->base;
struct drm_framebuffer *fb = pstate->fb;
@@ -3555,6 +3553,11 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint32_t width = 0, height = 0;
uint32_t plane_pixel_rate;
uint32_t linetime_us = 0;
+   int id = skl_wm_plane_id(to_intel_plane(pstate->plane));
+   struct skl_wm_level *result = _wm->wm[level];
+   uint16_t *out_blocks = >plane_res_b[id];
+   uint8_t *out_lines = >plane_res_l[id];
+   bool *enabled = >plane_en[id];
 
if (latency == 0 || !cstate->base.active || 
!intel_pstate->base.visible) {
*enabled = false;
@@ -3655,7 +3658,7 @@ skl_compute_wm_level(const struct drm_i915_private 
*dev_priv,
 struct skl_ddb_allocation *ddb,
 struct intel_crtc_state *cstate,
 int level,
-struct skl_wm_level *result)
+struct skl_pipe_wm *pipe_wm)
 {
struct drm_atomic_state *state = cstate->base.state;
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
@@ -3666,12 +3669,6 @@ skl_compute_wm_level(const struct drm_i915_private 
*dev_priv,
enum pipe pipe = intel_crtc->pipe;
int ret;
 
-   /*
-* We'll only calculate watermarks for planes that are actually
-* enabled, so make sure all other planes are set as disabled.
-*/
-   memset(result, 0, sizeof(*result));
-
for_each_intel_plane_mask(_priv->drm,
  intel_plane,
  cstate->base.plane_mask) {
@@ -3709,9 +3706,7 @@ skl_compute_wm_level(const struct drm_i915_private 
*dev_priv,
   intel_pstate,
   ddb_blocks,
   level,
-  >plane_res_b[i],
-  >plane_res_l[i],
-  >plane_en[i]);
+  pipe_wm);
if (ret)
return ret;
}
@@ -3759,9 +3754,15 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
int level, max_level = ilk_wm_max_level(dev);
int ret;
 
+   /*
+* We'll only calculate watermarks for planes that are actually
+* enabled, so make sure all other planes are set as disabled.
+*/
+   memset(pipe_wm, 0, sizeof(*pipe_wm));
+
for (level = 0; level <= max_level; level++) {
ret = skl_compute_wm_level(dev_priv, ddb, cstate,
-  level, _wm->wm[level]);
+  level, pipe_wm);
if (ret)
return ret;
}
-- 
2.8.3

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


[Intel-gfx] [PATCH 1/7] drm/i915/hsw+: set intel_crtc active once pipe is active

2016-08-29 Thread Kumar, Mahesh
Set the intel_crtc->active flag after pipe/crtc is actually active in
haswell_crtc_enable function.

Signed-off-by: Kumar, Mahesh 
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..7258883 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5427,8 +5427,6 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
 
intel_color_set_csc(_config->base);
 
-   intel_crtc->active = true;
-
if (intel_crtc->config->has_pch_encoder)
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
else
@@ -5475,6 +5473,8 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
assert_vblank_disabled(crtc);
drm_crtc_vblank_on(crtc);
 
+   intel_crtc->active = true;
+
intel_encoders_enable(crtc, pipe_config, old_state);
 
if (intel_crtc->config->has_pch_encoder) {
-- 
2.8.3

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


Re: [Intel-gfx] [PATCH 03/17] drm/i915: Allow the user to pass a context to any ring

2016-08-29 Thread Joonas Lahtinen
On to, 2016-08-25 at 16:28 +0100, John Harrison wrote:
> Just had a quick look at gem_ctx_switch and that seems to notice the
> change with this patch. Without it skips non-render engines, with it
> runs a bunch of non-default context tests across all engines. Is that
> sufficient to satisfy the IGT coverage requirement? Maybe with an
> update to make it fail rather than skip if it can't use a non-default 
> context?
> 

Sounds good to me.

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 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

2016-08-29 Thread Christian König

Am 29.08.2016 um 09:08 schrieb Chris Wilson:

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: Christian König 


Mhm, actually it was one of our developers who added the shortcut into 
reservation_object_wait_timeout_rcu().


But it looks like we forgot to clean this up in the amdgpu driver after 
doing this. So thanks for taking care of this.


Patch #1 as well as patch #6 are Reviewed-by: Christian König 
.


For patch #6 there is also an use case for this in TTM 
ttm_bo_add_move_fence().


We could change the lock into an RCU if we can make sure that we get an 
up to date RCU protected fence and not NULL if the fence becomes freed 
right at the wrong time.


Regards,
Christian.


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 88fbed2389c0..a3e6f883ac2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -407,10 +407,8 @@ int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, 
void *data,
return -ENOENT;
}
robj = gem_to_amdgpu_bo(gobj);
-   if (timeout == 0)
-   ret = reservation_object_test_signaled_rcu(robj->tbo.resv, 
true);
-   else
-   ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, 
true, timeout);
+   ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true,
+ timeout);
  
  	/* ret == 0 means not signaled,

 * ret > 0 means signaled



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


[Intel-gfx] ✗ Fi.CI.BAT: warning for Feature macro cleanup, batch 1

2016-08-29 Thread Patchwork
== Series Details ==

Series: Feature macro cleanup, batch 1
URL   : https://patchwork.freedesktop.org/series/11717/
State : warning

== Summary ==

Series 11717v1 Feature macro cleanup, batch 1
http://patchwork.freedesktop.org/api/1.0/series/11717/revisions/1/mbox/

Test gem_exec_gttfill:
Subgroup basic:
skip   -> PASS   (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> SKIP   (fi-hsw-4770r)

fi-bdw-5557u total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-bsw-n3050 total:252  pass:205  dwarn:0   dfail:0   fail:1   skip:46 
fi-byt-n2820 total:252  pass:208  dwarn:0   dfail:0   fail:3   skip:41 
fi-hsw-4770k total:252  pass:228  dwarn:0   dfail:0   fail:2   skip:22 
fi-hsw-4770r total:252  pass:223  dwarn:0   dfail:0   fail:2   skip:27 
fi-ivb-3520m total:252  pass:220  dwarn:0   dfail:0   fail:1   skip:31 
fi-skl-6260u total:252  pass:236  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-6700k total:252  pass:222  dwarn:0   dfail:0   fail:2   skip:28 
fi-snb-2520m total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 
fi-snb-2600  total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 

Results at /archive/results/CI_IGT_test/Patchwork_2445/

111559eb2a460c94679ee1e5be5931c1d89ad367 drm-intel-nightly: 
2016y-08m-29d-09h-31m-22s UTC integration manifest
0f98b32 drm/i915: INTEL_GEN() fixes, part 6
c09d98a drm/i915: RESOURCE_STREAMER/CORE_RING_FREQ fixes
2b66f93 drm/i915: HAS_GMCH_DISPLAY() fixes
9fd9bdf drm/i915: i915_vgacntrl_reg() fixes
eb8666c drm/i915: INTEL_GEN() fixes, part 5
04ef863 drm/i915: INTEL_GEN() fixes, part 4
e2dc6f4 drm/i915: INTEL_GEN() fixes, part 3
fc847db drm/i915: INTEL_GEN() fixes, part 2
e3cd6a0 drm/i915: INTEL_GEN() fixes, part 1
bdfdb57 drm/i915: HAS_POOLED_EU() fixes
9ae06fc drm/i915: IS_MOBILE() fixes
086471c drm/i915: Transitional, non-polymorph, macros

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


[Intel-gfx] [PATCH 12/12] drm/i915: INTEL_GEN() fixes, part 6

2016-08-29 Thread David Weinehall
Final batch of INTEL_INFO()->gen to INTEL_GEN().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 21 +++--
 drivers/gpu/drm/i915/i915_gpu_error.c |  4 ++--
 drivers/gpu/drm/i915/intel_dp.c   |  8 
 drivers/gpu/drm/i915/intel_pm.c   |  2 +-
 5 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cef3c34b15ab..c5fb12cdf438 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -575,7 +575,7 @@ static void i915_gem_fini(struct drm_device *dev)
 * machines is a good idea, we don't - just in case it leaves the
 * machine in an unusable condition.
 */
-   if (HAS_HW_CONTEXTS(dev)) {
+   if (HAS_HW_CONTEXTS(dev_priv)) {
int reset = intel_gpu_reset(dev_priv, ALL_ENGINES);
WARN_ON(reset && reset != -ENODEV);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff8df2995df8..7c01b1c3af54 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2735,8 +2735,8 @@ struct drm_i915_cmd_table {
 HAS_EDRAM(dev))
 #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
 
-#define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 6)
-#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 8)
+#define HAS_HW_CONTEXTS(dev_priv)  (INTEL_GEN(dev_priv) >= 6)
+#define HAS_LOGICAL_RING_CONTEXTS(dev_priv)(INTEL_GEN(dev_priv) >= 8)
 #define USES_PPGTT(dev)(i915.enable_ppgtt)
 #define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt >= 2)
 #define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
@@ -2759,8 +2759,8 @@ struct drm_i915_cmd_table {
  * legacy irq no. is shared with another device. The kernel then disables that
  * interrupt source and so prevents the other device from working properly.
  */
-#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
+#define HAS_AUX_IRQ(dev_priv)  (INTEL_GEN(dev_priv) >= 5)
+#define HAS_GMBUS_IRQ(dev_priv)(INTEL_GEN(dev_priv) >= 5)
 
 /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
  * rows, which changed the alignment requirements and fence programming.
@@ -2770,14 +2770,15 @@ struct drm_i915_cmd_table {
 #define SUPPORTS_TV(dev)   (INTEL_INFO(dev)->supports_tv)
 #define I915_HAS_HOTPLUG(dev)   (INTEL_INFO(dev)->has_hotplug)
 
-#define HAS_FW_BLC(dev) (INTEL_INFO(dev)->gen > 2)
+#define HAS_FW_BLC(dev_priv)   (INTEL_GEN(dev_priv) > 2)
 #define HAS_PIPE_CXSR(dev) (INTEL_INFO(dev)->has_pipe_cxsr)
 #define HAS_FBC(dev) (INTEL_INFO(dev)->has_fbc)
 
 #define HAS_IPS(dev)   (IS_HSW_ULT(dev) || IS_BROADWELL(dev))
 
-#define HAS_DP_MST(dev)(IS_HASWELL(dev) || IS_BROADWELL(dev) 
|| \
-INTEL_INFO(dev)->gen >= 9)
+#define HAS_DP_MST(dev_priv)   (IS_HASWELL(dev_priv) || \
+IS_BROADWELL(dev_priv) || \
+INTEL_GEN(dev_priv) >= 9)
 
 #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
@@ -2788,10 +2789,10 @@ struct drm_i915_cmd_table {
 IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
 IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
 IS_KABYLAKE(dev) || IS_BROXTON(dev))
-#define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
-#define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
+#define HAS_RC6(dev_priv)  (INTEL_GEN(dev_priv) >= 6)
+#define HAS_RC6p(dev_priv) (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
 
-#define HAS_CSR(dev)   (IS_GEN9(dev))
+#define HAS_CSR(dev_priv)  (IS_GEN9(dev_priv))
 
 /*
  * For now, anything with a GuC requires uCode loading, and then supports
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3c8a8d6248c6..2814839218a8 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -375,7 +375,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
   pdev->subsystem_device);
err_printf(m, "IOMMU enabled?: %d\n", error->iommu);
 
-   if (HAS_CSR(dev)) {
+   if (HAS_CSR(dev_priv)) {
struct intel_csr *csr = _priv->csr;
 
err_printf(m, "DMC loaded: %s\n",
@@ -1340,7 +1340,7 @@ static void i915_capture_reg_state(struct 
drm_i915_private *dev_priv,
}
 
/* 4: Everything else */
-   if (HAS_HW_CONTEXTS(dev))
+   if (HAS_HW_CONTEXTS(dev_priv))
error->ccid = I915_READ(CCID);
 
if (INTEL_GEN(dev_priv) >= 8) {
diff 

[Intel-gfx] [PATCH 03/12] drm/i915: HAS_POOLED_EU() fixes

2016-08-29 Thread David Weinehall
Pass dev_priv to all instances of HAS_POOLED_EU(), as well as
to INTEL_INFO()->min_eu_in_pool, and make the macro
use the new non-polymorph version of INTEL_INFO().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
 drivers/gpu/drm/i915/i915_drv.h  | 2 +-
 drivers/gpu/drm/i915/i915_gem_render_state.c | 3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 47fe07283d88..9fb32d9d5bb8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -350,10 +350,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
value = 1;
break;
case I915_PARAM_HAS_POOLED_EU:
-   value = HAS_POOLED_EU(dev);
+   value = HAS_POOLED_EU(dev_priv);
break;
case I915_PARAM_MIN_EU_IN_POOL:
-   value = INTEL_INFO(dev)->min_eu_in_pool;
+   value = INTEL_INFO(dev_priv)->min_eu_in_pool;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22b75b93d084..3cf5220dfae4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2809,7 +2809,7 @@ struct drm_i915_cmd_table {
 !IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev) && \
 !IS_BROXTON(dev))
 
-#define HAS_POOLED_EU(dev) (INTEL_INFO(dev)->has_pooled_eu)
+#define HAS_POOLED_EU(dev_priv)(__INTEL_INFO(dev_priv)->has_pooled_eu)
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff00
 #define INTEL_PCH_IBX_DEVICE_ID_TYPE   0x3b00
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 95b7e9afd5f8..d6d239211087 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -73,6 +73,7 @@ render_state_get_rodata(const struct drm_i915_gem_request 
*req)
 static int render_state_setup(struct render_state *so)
 {
struct drm_device *dev = so->vma->vm->dev;
+   struct drm_i915_private *dev_priv = to_i915(so->vma->vm->dev);
const struct intel_renderstate_rodata *rodata = so->rodata;
const bool has_64bit_reloc = INTEL_GEN(dev) >= 8;
unsigned int i = 0, reloc_index = 0;
@@ -115,7 +116,7 @@ static int render_state_setup(struct render_state *so)
 
so->aux_batch_offset = i * sizeof(u32);
 
-   if (HAS_POOLED_EU(dev)) {
+   if (HAS_POOLED_EU(dev_priv)) {
/*
 * We always program 3x6 pool config but depending upon which
 * subslice is disabled HW drops down to appropriate config
-- 
2.9.3

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


[Intel-gfx] [PATCH 00/12] Feature macro cleanup, batch 1

2016-08-29 Thread David Weinehall
Most of our feature macros are made to take
drm_i915_private as a parameter, since the wanted
information is part of that struct.

A lot of code still passes drm_device instead, meaning
extra pointer churn.  As a stop-gap solution our macros
currently implements a poor man's polymorphism by use of
the magic __I915__ macro.

This batch of patches starts a transition to a shinier
world with non-polymorphic macros.  I've got more
patches in the pipeline, but to prevent the merge
from stalling due to lack of review or due to merge
conflicts, I've decided to split them into several
batches.

The first patch in this series is only needed during
the merge period; the final patch in the final batch
of patches will undo those changes (but until then
these transitional macros serve to prevent new code
being added that uses the old behaviour).

This batch will, due to the introduction of some
transitional code, introduce more lines that it deletes,
but the following batches will more than compensate for this.
In terms of module size, this patch should save us a bit less
than 1kB. The total series will save something on the order
of 35-40kB (without doing most of the further cleanup that
this enables).

The philosophy when doing this transition has been:

* Whenever struct drm_i915_private * has been introduced
  it has been named dev_priv[1].

* In most of those cases I've tried to make the newly introduced
  pointers be independent from struct drm_device *, to ease finding
  unused variables once the transition is complete

* Whenever a transitioned macro has another macro on the same line,
  or the ones immediately preceeding or succeeding, I've transitioned
  those too, to minimise the amount of patches that changes the
  same lines.

* If leaf functions with struct drm_device * as an in-parameter
  has ended up not using that parameter at all (except for turning
  it into struct drm_i915_private *), I have in a few cases modified
  the function to take the latter pointer as a parameter instead.

* In a few cases I've rebroken lines to make them follow the kernel
  coding style.

[1] Let the bikeshedding ensue; i915 is an alternative
that would make the code slightly more compact,
be slightly more descriptive, and allow for fewer
lines that violates that the kernel coding style
in terms of length, but it does have a solid majority
against it in terms of established use.

David Weinehall (12):
  drm/i915: Transitional, non-polymorph, macros
  drm/i915: IS_MOBILE() fixes
  drm/i915: HAS_POOLED_EU() fixes
  drm/i915: INTEL_GEN() fixes, part 1
  drm/i915: INTEL_GEN() fixes, part 2
  drm/i915: INTEL_GEN() fixes, part 3
  drm/i915: INTEL_GEN() fixes, part 4
  drm/i915: INTEL_GEN() fixes, part 5
  drm/i915: i915_vgacntrl_reg() fixes
  drm/i915: HAS_GMCH_DISPLAY() fixes
  drm/i915: RESOURCE_STREAMER/CORE_RING_FREQ fixes
  drm/i915: INTEL_GEN() fixes, part 6

 drivers/gpu/drm/i915/i915_drv.c  |  29 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  52 +++---
 drivers/gpu/drm/i915/i915_gem.c  |  14 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  11 +-
 drivers/gpu/drm/i915/i915_gem_fence.c|   9 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  22 +--
 drivers/gpu/drm/i915/i915_gem_render_state.c |   6 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c   |   9 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c   |   7 +-
 drivers/gpu/drm/i915/i915_gpu_error.c|  18 +--
 drivers/gpu/drm/i915/i915_irq.c  |  50 +++---
 drivers/gpu/drm/i915/i915_suspend.c  |  18 +--
 drivers/gpu/drm/i915/intel_audio.c   |   2 +-
 drivers/gpu/drm/i915/intel_bios.c|   2 +-
 drivers/gpu/drm/i915/intel_color.c   |  16 +-
 drivers/gpu/drm/i915/intel_crt.c |   9 +-
 drivers/gpu/drm/i915/intel_ddi.c |  24 ++-
 drivers/gpu/drm/i915/intel_device_info.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c | 231 ++-
 drivers/gpu/drm/i915/intel_dp.c  |  56 ---
 drivers/gpu/drm/i915/intel_dpll_mgr.c|   5 +-
 drivers/gpu/drm/i915/intel_drv.h |   2 +-
 drivers/gpu/drm/i915/intel_dsi.c |   5 +-
 drivers/gpu/drm/i915/intel_fbc.c |  28 ++--
 drivers/gpu/drm/i915/intel_fifo_underrun.c   |   2 +-
 drivers/gpu/drm/i915/intel_guc_loader.c  |   2 +-
 drivers/gpu/drm/i915/intel_hdmi.c|  15 +-
 drivers/gpu/drm/i915/intel_lvds.c|  17 +-
 drivers/gpu/drm/i915/intel_mocs.c|   2 +-
 drivers/gpu/drm/i915/intel_panel.c   |  12 +-
 drivers/gpu/drm/i915/intel_pm.c  |  83 ++
 drivers/gpu/drm/i915/intel_psr.c |   8 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   2 +-
 drivers/gpu/drm/i915/intel_sdvo.c|  12 +-
 drivers/gpu/drm/i915/intel_sprite.c  |  17 +-
 drivers/gpu/drm/i915/intel_tv.c  |   2 +-
 drivers/gpu/drm/i915/intel_uncore.c  |  

[Intel-gfx] [PATCH 05/12] drm/i915: INTEL_GEN() fixes, part 2

2016-08-29 Thread David Weinehall
Convert all instances of INTEL_INFO(dev_priv)->gen to INTEL_GEN(dev_priv).

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c|  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 10 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  6 +++---
 drivers/gpu/drm/i915/i915_gem_fence.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  6 +++---
 drivers/gpu/drm/i915/i915_gem_stolen.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c| 24 
 drivers/gpu/drm/i915/intel_audio.c |  2 +-
 drivers/gpu/drm/i915/intel_bios.c  |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c   |  4 ++--
 drivers/gpu/drm/i915/intel_device_info.c   |  2 +-
 drivers/gpu/drm/i915/intel_display.c   | 22 +++---
 drivers/gpu/drm/i915/intel_dp.c|  4 ++--
 drivers/gpu/drm/i915/intel_fbc.c   | 28 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c|  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |  4 ++--
 drivers/gpu/drm/i915/intel_lvds.c  |  2 +-
 drivers/gpu/drm/i915/intel_mocs.c  |  2 +-
 drivers/gpu/drm/i915/intel_panel.c |  2 +-
 drivers/gpu/drm/i915/intel_pm.c| 12 ++--
 drivers/gpu/drm/i915/intel_psr.c   |  4 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c|  2 +-
 drivers/gpu/drm/i915/intel_uncore.c| 14 +++---
 23 files changed, 80 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9fb32d9d5bb8..a7e1dfd3f4c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1531,7 +1531,7 @@ static int i915_drm_suspend_late(struct drm_device *dev, 
bool hibernation)
 * Fujitsu FSC S7110
 * Acer Aspire 1830T
 */
-   if (!(hibernation && INTEL_INFO(dev_priv)->gen < 6))
+   if (!(hibernation && INTEL_GEN(dev_priv) < 6))
pci_set_power_state(pdev, PCI_D3hot);
 
dev_priv->suspended_to_idle = suspend_to_idle(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d37b44126942..2eb8afd85da1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4459,7 +4459,7 @@ out:
 
 bool intel_sanitize_semaphores(struct drm_i915_private *dev_priv, int value)
 {
-   if (INTEL_INFO(dev_priv)->gen < 6)
+   if (INTEL_GEN(dev_priv) < 6)
return false;
 
/* TODO: make semaphores and Execlists play nicely together */
@@ -4471,7 +4471,7 @@ bool intel_sanitize_semaphores(struct drm_i915_private 
*dev_priv, int value)
 
 #ifdef CONFIG_INTEL_IOMMU
/* Enable semaphores on SNB when IO remapping is off */
-   if (INTEL_INFO(dev_priv)->gen == 6 && intel_iommu_gfx_mapped)
+   if (INTEL_GEN(dev_priv) == 6 && intel_iommu_gfx_mapped)
return false;
 #endif
 
@@ -4553,10 +4553,10 @@ i915_gem_load_init_fences(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = _priv->drm;
int i;
 
-   if (INTEL_INFO(dev_priv)->gen >= 7 && !IS_VALLEYVIEW(dev_priv) &&
-   !IS_CHERRYVIEW(dev_priv))
+   if (INTEL_GEN(dev_priv) >= 7 &&
+   !IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
dev_priv->num_fence_regs = 32;
-   else if (INTEL_INFO(dev_priv)->gen >= 4 || IS_I945G(dev_priv) ||
+   else if (INTEL_GEN(dev_priv) >= 4 || IS_I945G(dev_priv) ||
 IS_I945GM(dev_priv) || IS_G33(dev_priv))
dev_priv->num_fence_regs = 16;
else
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 57d096aef548..8cbe0a807a35 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1460,19 +1460,19 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
 
if (instp_mode != dev_priv->relative_constants_mode) {
-   if (INTEL_INFO(dev_priv)->gen < 4) {
+   if (INTEL_GEN(dev_priv) < 4) {
DRM_DEBUG("no rel constants on pre-gen4\n");
return -EINVAL;
}
 
-   if (INTEL_INFO(dev_priv)->gen > 5 &&
+   if (INTEL_GEN(dev_priv) > 5 &&
instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
DRM_DEBUG("rel surface constants mode invalid 
on gen5+\n");
return -EINVAL;
}
 
/* The HW changed the meaning on this bit on gen6 */
-   if (INTEL_INFO(dev_priv)->gen >= 6)
+   if (INTEL_GEN(dev_priv) >= 6)
instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
}
break;
diff --git 

[Intel-gfx] [PATCH 09/12] drm/i915: i915_vgacntrl_reg() fixes

2016-08-29 Thread David Weinehall
Modify i915_vgacntrl_reg() to take dev_priv instead of dev,
and replace its call to INTEL_INFO(dev)->gen with INTEL_GEN(dev_priv).

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h  | 6 +++---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e3b42e817580..83762e7d2874 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3814,11 +3814,11 @@ __raw_write(64, q)
 #define INTEL_BROADCAST_RGB_FULL 1
 #define INTEL_BROADCAST_RGB_LIMITED 2
 
-static inline i915_reg_t i915_vgacntrl_reg(struct drm_device *dev)
+static inline i915_reg_t i915_vgacntrl_reg(struct drm_i915_private *dev_priv)
 {
-   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
return VLV_VGACNTRL;
-   else if (INTEL_INFO(dev)->gen >= 5)
+   else if (INTEL_GEN(dev_priv) >= 5)
return CPU_VGACNTRL;
else
return VGACNTRL;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 69033420be0a..ab734c46a996 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -16221,7 +16221,7 @@ static void i915_disable_vga(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
u8 sr1;
-   i915_reg_t vga_reg = i915_vgacntrl_reg(dev);
+   i915_reg_t vga_reg = i915_vgacntrl_reg(dev_priv);
 
/* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */
vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO);
@@ -1,7 +1,7 @@ static void intel_sanitize_encoder(struct intel_encoder 
*encoder)
 void i915_redisable_vga_power_on(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   i915_reg_t vga_reg = i915_vgacntrl_reg(dev);
+   i915_reg_t vga_reg = i915_vgacntrl_reg(dev_priv);
 
if (!(I915_READ(vga_reg) & VGA_DISP_DISABLE)) {
DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n");
-- 
2.9.3

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


[Intel-gfx] [PATCH 08/12] drm/i915: INTEL_GEN() fixes, part 5

2016-08-29 Thread David Weinehall
Convert all remaining instances of INTEL_INFO(dev)->gen in *.c
to INTEL_GEN(dev_priv).

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c| 19 +++---
 drivers/gpu/drm/i915/i915_gem.c|  4 +--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 ++-
 drivers/gpu/drm/i915/i915_gem_fence.c  |  4 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c| 16 +++-
 drivers/gpu/drm/i915/i915_gem_stolen.c |  7 ++---
 drivers/gpu/drm/i915/i915_gem_tiling.c |  7 ++---
 drivers/gpu/drm/i915/i915_gpu_error.c  | 14 +-
 drivers/gpu/drm/i915/i915_irq.c| 26 +-
 drivers/gpu/drm/i915/i915_suspend.c| 18 ++---
 drivers/gpu/drm/i915/intel_color.c |  5 ++--
 drivers/gpu/drm/i915/intel_crt.c   |  9 +++
 drivers/gpu/drm/i915/intel_ddi.c   | 20 +++---
 drivers/gpu/drm/i915/intel_display.c   |  6 ++---
 drivers/gpu/drm/i915/intel_dp.c| 42 ++
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |  5 ++--
 drivers/gpu/drm/i915/intel_drv.h   |  2 +-
 drivers/gpu/drm/i915/intel_lvds.c  | 10 +++
 drivers/gpu/drm/i915/intel_panel.c | 10 +++
 drivers/gpu/drm/i915/intel_psr.c   |  4 +--
 drivers/gpu/drm/i915/intel_sdvo.c  |  8 +++---
 drivers/gpu/drm/i915/intel_sprite.c| 14 +-
 drivers/gpu/drm/i915/intel_tv.c|  2 +-
 23 files changed, 124 insertions(+), 131 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7e1dfd3f4c0..eee2fdba2e27 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -283,7 +283,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = 1;
break;
case I915_PARAM_HAS_EXEC_CONSTANTS:
-   value = INTEL_INFO(dev)->gen >= 4;
+   value = INTEL_GEN(dev_priv) >= 4;
break;
case I915_PARAM_HAS_RELAXED_DELTA:
value = 1;
@@ -387,15 +387,14 @@ static int i915_get_bridge_dev(struct drm_device *dev)
 
 /* Allocate space for the MCH regs if needed, return nonzero on error */
 static int
-intel_alloc_mchbar_resource(struct drm_device *dev)
+intel_alloc_mchbar_resource(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
+   int reg = INTEL_GEN(dev_priv) >= 4 ? MCHBAR_I965 : MCHBAR_I915;
u32 temp_lo, temp_hi = 0;
u64 mchbar_addr;
int ret;
 
-   if (INTEL_INFO(dev)->gen >= 4)
+   if (INTEL_GEN(dev_priv) >= 4)
pci_read_config_dword(dev_priv->bridge_dev, reg + 4, _hi);
pci_read_config_dword(dev_priv->bridge_dev, reg, _lo);
mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
@@ -422,7 +421,7 @@ intel_alloc_mchbar_resource(struct drm_device *dev)
return ret;
}
 
-   if (INTEL_INFO(dev)->gen >= 4)
+   if (INTEL_GEN(dev_priv) >= 4)
pci_write_config_dword(dev_priv->bridge_dev, reg + 4,
   upper_32_bits(dev_priv->mch_res.start));
 
@@ -436,7 +435,7 @@ static void
 intel_setup_mchbar(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
+   int mchbar_reg = INTEL_GEN(dev_priv) >= 4 ? MCHBAR_I965 : MCHBAR_I915;
u32 temp;
bool enabled;
 
@@ -457,7 +456,7 @@ intel_setup_mchbar(struct drm_device *dev)
if (enabled)
return;
 
-   if (intel_alloc_mchbar_resource(dev))
+   if (intel_alloc_mchbar_resource(dev_priv))
return;
 
dev_priv->mchbar_need_disable = true;
@@ -476,7 +475,7 @@ static void
 intel_teardown_mchbar(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
+   int mchbar_reg = INTEL_GEN(dev_priv) >= 4 ? MCHBAR_I965 : MCHBAR_I915;
 
if (dev_priv->mchbar_need_disable) {
if (IS_I915G(dev) || IS_I915GM(dev)) {
@@ -903,7 +902,7 @@ static int i915_mmio_setup(struct drm_device *dev)
 * the register BAR remains the same size for all the earlier
 * generations up to Ironlake.
 */
-   if (INTEL_INFO(dev)->gen < 5)
+   if (INTEL_GEN(dev_priv) < 5)
mmio_size = 512 * 1024;
else
mmio_size = 2 * 1024 * 1024;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2eb8afd85da1..5600f4c5f1e3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4343,7 +4343,7 @@ void i915_gem_init_swizzling(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = 

[Intel-gfx] [PATCH 02/12] drm/i915: IS_MOBILE() fixes

2016-08-29 Thread David Weinehall
Pass dev_priv to all instances of IS_MOBILE(), convert the
only user of INTEL_INFO()->is_mobile to use IS_MOBILE(),
and make the macro use the new non-polymorph version of INTEL_INFO().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h   | 4 ++--
 drivers/gpu/drm/i915/i915_gem_fence.c | 3 ++-
 drivers/gpu/drm/i915/intel_display.c  | 9 +
 drivers/gpu/drm/i915/intel_lvds.c | 5 -
 drivers/gpu/drm/i915/intel_pm.c   | 2 +-
 drivers/gpu/drm/i915/intel_sdvo.c | 4 ++--
 6 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b544f43fc533..22b75b93d084 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2564,7 +2564,7 @@ struct drm_i915_cmd_table {
__p; \
 })
 #define INTEL_INFO(p)  (&__I915__(p)->info)
-#define __INTEL_INFO(dev_priv) (dev_priv->info)
+#define __INTEL_INFO(dev_priv) (_priv->info)
 #define INTEL_GEN(p)   (INTEL_INFO(p)->gen)
 #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
 #define __INTEL_DEVID(dev_priv)(__INTEL_INFO(dev_priv)->device_id)
@@ -2628,7 +2628,7 @@ struct drm_i915_cmd_table {
 #define IS_SKYLAKE(dev)(INTEL_INFO(dev)->is_skylake)
 #define IS_BROXTON(dev)(INTEL_INFO(dev)->is_broxton)
 #define IS_KABYLAKE(dev)   (INTEL_INFO(dev)->is_kabylake)
-#define IS_MOBILE(dev) (INTEL_INFO(dev)->is_mobile)
+#define IS_MOBILE(dev_priv)(__INTEL_INFO(dev_priv)->is_mobile)
 #define IS_HSW_EARLY_SDV(dev)  (IS_HASWELL(dev) && \
 (INTEL_DEVID(dev) & 0xFF00) == 0x0C00)
 #define IS_BDW_ULT(dev)(IS_BROADWELL(dev) && \
diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
b/drivers/gpu/drm/i915/i915_gem_fence.c
index 8df1fa7234e8..359da6b2cc1e 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -499,7 +499,8 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
 */
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
-   } else if (IS_MOBILE(dev) || (IS_GEN3(dev) && !IS_G33(dev))) {
+   } else if (IS_MOBILE(dev_priv) ||
+  (IS_GEN3(dev_priv) && !IS_G33(dev_priv))) {
uint32_t dcc;
 
/* On 9xx chipsets, channel interleave by the CPU is
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 19ffd024ddec..62cf7a49a521 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1619,7 +1619,7 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
assert_pipe_disabled(dev_priv, crtc->pipe);
 
/* PLL is protected by panel, make sure we can write it */
-   if (IS_MOBILE(dev) && !IS_I830(dev))
+   if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
assert_panel_unlocked(dev_priv, crtc->pipe);
 
/* Enable DVO 2x clock on both PLLs if necessary */
@@ -7530,7 +7530,7 @@ static unsigned int intel_hpll_vco(struct drm_device *dev)
else
return 0;
 
-   tmp = I915_READ(IS_MOBILE(dev) ? HPLLVCO_MOBILE : HPLLVCO);
+   tmp = I915_READ(IS_MOBILE(dev_priv) ? HPLLVCO_MOBILE : HPLLVCO);
 
vco = vco_table[tmp & 0x7];
if (vco == 0)
@@ -8638,7 +8638,8 @@ static void i9xx_get_pfit_config(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(dev);
uint32_t tmp;
 
-   if (INTEL_INFO(dev)->gen <= 3 && (IS_I830(dev) || !IS_MOBILE(dev)))
+   if (INTEL_GEN(dev_priv) <= 3 &&
+   (IS_I830(dev_priv) || !IS_MOBILE(dev_priv)))
return;
 
tmp = I915_READ(PFIT_CONTROL);
@@ -15297,7 +15298,7 @@ static bool has_edp_a(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   if (!IS_MOBILE(dev))
+   if (!IS_MOBILE(dev_priv))
return false;
 
if ((I915_READ(DP_A) & DP_DETECTED) == 0)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index e1d47d51ea47..a66692d679db 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -951,6 +951,8 @@ static bool compute_is_dual_link_lvds(struct 
intel_lvds_encoder *lvds_encoder)
 
 static bool intel_lvds_supported(struct drm_device *dev)
 {
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
/* With the introduction of the PCH we gained a dedicated
 * LVDS presence pin, use it. */
if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
@@ -958,7 +960,8 @@ static bool intel_lvds_supported(struct drm_device *dev)
 
/* Otherwise LVDS was only attached to mobile products,
 * except for the inglorious 830gm */
-   if (INTEL_INFO(dev)->gen <= 4 && IS_MOBILE(dev) && !IS_I830(dev))
+   if (INTEL_GEN(dev_priv) <= 4 &&
+   IS_MOBILE(dev_priv) && 

[Intel-gfx] [PATCH 10/12] drm/i915: HAS_GMCH_DISPLAY() fixes

2016-08-29 Thread David Weinehall
Pass dev_priv to all instances of HAS_GMCH_DISPLAY(), and make the
macro use INTEL_GEN().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h|  5 +++--
 drivers/gpu/drm/i915/intel_color.c | 11 +--
 drivers/gpu/drm/i915/intel_display.c   | 12 ++--
 drivers/gpu/drm/i915/intel_dp.c|  2 +-
 drivers/gpu/drm/i915/intel_dsi.c   |  5 +++--
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c  | 11 ++-
 7 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 83762e7d2874..e7c6d95edcdf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2835,8 +2835,9 @@ struct drm_i915_cmd_table {
 #define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
 #define HAS_PCH_SPLIT(dev) (INTEL_PCH_TYPE(dev) != PCH_NONE)
 
-#define HAS_GMCH_DISPLAY(dev) (INTEL_INFO(dev)->gen < 5 || \
-  IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
+#define HAS_GMCH_DISPLAY(dev_priv) (INTEL_GEN(dev_priv) < 5 || \
+IS_VALLEYVIEW(dev_priv) || \
+IS_CHERRYVIEW(dev_priv))
 
 /* DPF == dynamic parity feature */
 #define HAS_L3_DPF(dev) (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 9bf072f5615a..0a3acc91c283 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -266,13 +266,12 @@ static void i9xx_load_luts_internal(struct drm_crtc *crtc,
struct drm_property_blob *blob,
struct intel_crtc_state *crtc_state)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
int i;
 
-   if (HAS_GMCH_DISPLAY(dev)) {
+   if (HAS_GMCH_DISPLAY(dev_priv)) {
if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
assert_dsi_pll_enabled(dev_priv);
else
@@ -280,14 +279,14 @@ static void i9xx_load_luts_internal(struct drm_crtc *crtc,
}
 
if (blob) {
-   struct drm_color_lut *lut = (struct drm_color_lut *) blob->data;
+   struct drm_color_lut *lut = (struct drm_color_lut *)blob->data;
for (i = 0; i < 256; i++) {
uint32_t word =
(drm_color_lut_extract(lut[i].red, 8) << 16) |
(drm_color_lut_extract(lut[i].green, 8) << 8) |
drm_color_lut_extract(lut[i].blue, 8);
 
-   if (HAS_GMCH_DISPLAY(dev))
+   if (HAS_GMCH_DISPLAY(dev_priv))
I915_WRITE(PALETTE(pipe, i), word);
else
I915_WRITE(LGC_PALETTE(pipe, i), word);
@@ -296,7 +295,7 @@ static void i9xx_load_luts_internal(struct drm_crtc *crtc,
for (i = 0; i < 256; i++) {
uint32_t word = (i << 16) | (i << 8) | i;
 
-   if (HAS_GMCH_DISPLAY(dev))
+   if (HAS_GMCH_DISPLAY(dev_priv))
I915_WRITE(PALETTE(pipe, i), word);
else
I915_WRITE(LGC_PALETTE(pipe, i), word);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ab734c46a996..a699d7bc6e31 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5003,8 +5003,8 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
 static void
 intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+   struct drm_device *dev = _priv->drm;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
 
@@ -5019,7 +5019,7 @@ intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
 * event which is after the vblank start event, so we need to have a
 * wait-for-vblank between disabling the plane and the pipe.
 */
-   if (HAS_GMCH_DISPLAY(dev)) {
+   if (HAS_GMCH_DISPLAY(dev_priv)) {
intel_set_memory_cxsr(dev_priv, false);
dev_priv->wm.vlv.cxsr = false;
intel_wait_for_vblank(dev, pipe);
@@ -5084,7 +5084,7 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)

[Intel-gfx] [PATCH 04/12] drm/i915: INTEL_GEN() fixes, part 1

2016-08-29 Thread David Weinehall
Pass dev_priv to all instances of INTEL_GEN(), and make the macro
use the new non-polymorph version of INTEL_INFO().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h  | 2 +-
 drivers/gpu/drm/i915/i915_gem_render_state.c | 3 +--
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_sprite.c  | 3 ++-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3cf5220dfae4..e3b42e817580 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2565,7 +2565,7 @@ struct drm_i915_cmd_table {
 })
 #define INTEL_INFO(p)  (&__I915__(p)->info)
 #define __INTEL_INFO(dev_priv) (_priv->info)
-#define INTEL_GEN(p)   (INTEL_INFO(p)->gen)
+#define INTEL_GEN(dev_priv)(__INTEL_INFO(dev_priv)->gen)
 #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
 #define __INTEL_DEVID(dev_priv)(__INTEL_INFO(dev_priv)->device_id)
 
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index d6d239211087..a98c0f42badd 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -72,10 +72,9 @@ render_state_get_rodata(const struct drm_i915_gem_request 
*req)
 
 static int render_state_setup(struct render_state *so)
 {
-   struct drm_device *dev = so->vma->vm->dev;
struct drm_i915_private *dev_priv = to_i915(so->vma->vm->dev);
const struct intel_renderstate_rodata *rodata = so->rodata;
-   const bool has_64bit_reloc = INTEL_GEN(dev) >= 8;
+   const bool has_64bit_reloc = INTEL_GEN(dev_priv) >= 8;
unsigned int i = 0, reloc_index = 0;
struct page *page;
u32 *d;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 62cf7a49a521..8fd7d3d9a1e9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12432,7 +12432,7 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
struct drm_framebuffer *fb = plane_state->fb;
int ret;
 
-   if (INTEL_GEN(dev) >= 9 && plane->type != DRM_PLANE_TYPE_CURSOR) {
+   if (INTEL_GEN(dev_priv) >= 9 && plane->type != DRM_PLANE_TYPE_CURSOR) {
ret = skl_update_scaler_plane(
to_intel_crtc_state(crtc_state),
to_intel_plane_state(plane_state));
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a66bfb..8d81a4c8e71d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -748,6 +748,7 @@ intel_check_sprite_plane(struct drm_plane *plane,
 struct intel_crtc_state *crtc_state,
 struct intel_plane_state *state)
 {
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
struct drm_device *dev = plane->dev;
struct drm_crtc *crtc = state->base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -927,7 +928,7 @@ intel_check_sprite_plane(struct drm_plane *plane,
dst->y1 = crtc_y;
dst->y2 = crtc_y + crtc_h;
 
-   if (INTEL_GEN(dev) >= 9) {
+   if (INTEL_GEN(dev_priv) >= 9) {
ret = skl_check_plane_surface(state);
if (ret)
return ret;
-- 
2.9.3

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


[Intel-gfx] [PATCH 01/12] drm/i915: Transitional, non-polymorph, macros

2016-08-29 Thread David Weinehall
Introduce non-polymorph versions of INTEL_INFO(), INTEL_DEVID(),
and INTEL_REVID(), to help the transition to ridding the driver
of the polymorph versions.

These macros are only intended to be used *within* i915_drv.h,
to prevent already transitioned macros from inadvertent introduction
of new, non-fixed, uses.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77a5478043e7..b544f43fc533 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2564,11 +2564,14 @@ struct drm_i915_cmd_table {
__p; \
 })
 #define INTEL_INFO(p)  (&__I915__(p)->info)
+#define __INTEL_INFO(dev_priv) (dev_priv->info)
 #define INTEL_GEN(p)   (INTEL_INFO(p)->gen)
 #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
+#define __INTEL_DEVID(dev_priv)(__INTEL_INFO(dev_priv)->device_id)
 
 #define REVID_FOREVER  0xff
 #define INTEL_REVID(p) (__I915__(p)->drm.pdev->revision)
+#define __INTEL_REVID(dev_priv)(dev_priv->drm.pdev->revision)
 
 #define GEN_FOREVER (0)
 /*
-- 
2.9.3

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


[Intel-gfx] [PATCH 06/12] drm/i915: INTEL_GEN() fixes, part 3

2016-08-29 Thread David Weinehall
Convert all instances of INTEL_INFO(dev)->gen in intel_display.c
to INTEL_GEN(dev_priv).

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/intel_display.c | 176 ++-
 1 file changed, 89 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cc69aa5bfb96..e5e627b04e51 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1075,7 +1075,7 @@ static void intel_wait_for_pipe_off(struct intel_crtc 
*crtc)
enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
enum pipe pipe = crtc->pipe;
 
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
i915_reg_t reg = PIPECONF(cpu_transcoder);
 
/* Wait for the Pipe State to go off */
@@ -1294,11 +1294,10 @@ static void assert_plane(struct drm_i915_private 
*dev_priv,
 static void assert_planes_disabled(struct drm_i915_private *dev_priv,
   enum pipe pipe)
 {
-   struct drm_device *dev = _priv->drm;
int i;
 
/* Primary planes are fixed to pipes on gen4+ */
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
u32 val = I915_READ(DSPCNTR(pipe));
I915_STATE_WARN(val & DISPLAY_PLANE_ENABLE,
 "plane %c assertion failure, should be disabled but not\n",
@@ -1323,7 +1322,7 @@ static void assert_sprites_disabled(struct 
drm_i915_private *dev_priv,
struct drm_device *dev = _priv->drm;
int sprite;
 
-   if (INTEL_INFO(dev)->gen >= 9) {
+   if (INTEL_GEN(dev_priv) >= 9) {
for_each_sprite(dev_priv, pipe, sprite) {
u32 val = I915_READ(PLANE_CTL(pipe, sprite));
I915_STATE_WARN(val & PLANE_CTL_ENABLE,
@@ -1337,12 +1336,12 @@ static void assert_sprites_disabled(struct 
drm_i915_private *dev_priv,
 "sprite %c assertion failure, should be off on 
pipe %c but is still active\n",
 sprite_name(pipe, sprite), pipe_name(pipe));
}
-   } else if (INTEL_INFO(dev)->gen >= 7) {
+   } else if (INTEL_GEN(dev_priv) >= 7) {
u32 val = I915_READ(SPRCTL(pipe));
I915_STATE_WARN(val & SPRITE_ENABLE,
 "sprite %c assertion failure, should be off on pipe %c but 
is still active\n",
 plane_name(pipe), pipe_name(pipe));
-   } else if (INTEL_INFO(dev)->gen >= 5) {
+   } else if (INTEL_GEN(dev_priv) >= 5) {
u32 val = I915_READ(DVSCNTR(pipe));
I915_STATE_WARN(val & DVS_ENABLE,
 "sprite %c assertion failure, should be off on pipe %c but 
is still active\n",
@@ -1648,7 +1647,7 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
POSTING_READ(reg);
udelay(150);
 
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
I915_WRITE(DPLL_MD(crtc->pipe),
   crtc->config->dpll_hw_state.dpll_md);
} else {
@@ -3022,7 +3021,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
 
dspcntr |= DISPLAY_PLANE_ENABLE;
 
-   if (INTEL_INFO(dev)->gen < 4) {
+   if (INTEL_GEN(dev_priv) < 4) {
if (intel_crtc->pipe == PIPE_B)
dspcntr |= DISPPLANE_SEL_PIPE_B;
 
@@ -3076,7 +3075,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
 
intel_add_fb_offsets(, , plane_state, 0);
 
-   if (INTEL_INFO(dev)->gen >= 4)
+   if (INTEL_GEN(dev_priv) >= 4)
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(, , plane_state, 0);
 
@@ -3089,7 +3088,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
 
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
 
-   if (INTEL_INFO(dev)->gen < 4)
+   if (INTEL_GEN(dev_priv) < 4)
intel_crtc->dspaddr_offset = linear_offset;
 
intel_crtc->adjusted_x = x;
@@ -3098,7 +3097,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
I915_WRITE(reg, dspcntr);
 
I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
-   if (INTEL_INFO(dev)->gen >= 4) {
+   if (INTEL_GEN(dev_priv) >= 4) {
I915_WRITE(DSPSURF(plane),
   intel_fb_gtt_offset(fb, rotation) +
   intel_crtc->dspaddr_offset);
@@ -3690,7 +3689,7 @@ static void intel_update_pipe_config(struct intel_crtc 
*crtc,
   (pipe_config->pipe_src_h - 1));
 
/* on skylake this is done by detaching scalers */
-   if (INTEL_INFO(dev)->gen >= 9) {
+   if (INTEL_GEN(dev_priv) >= 9) {
skl_detach_scalers(crtc);
 
if 

[Intel-gfx] [PATCH 11/12] drm/i915: RESOURCE_STREAMER/CORE_RING_FREQ fixes

2016-08-29 Thread David Weinehall
Pass dev_priv to all instances of HAS_RESOURCE_STREAMER() and
HAS_CORE_RING_FREQ(), and make the macros use INTEL_GEN().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 11 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index eee2fdba2e27..cef3c34b15ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -344,7 +344,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = i915.enable_hangcheck && intel_has_gpu_reset(dev_priv);
break;
case I915_PARAM_HAS_RESOURCE_STREAMER:
-   value = HAS_RESOURCE_STREAMER(dev);
+   value = HAS_RESOURCE_STREAMER(dev_priv);
break;
case I915_PARAM_HAS_EXEC_SOFTPIN:
value = 1;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e7c6d95edcdf..ff8df2995df8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2802,12 +2802,13 @@ struct drm_i915_cmd_table {
 #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
 
-#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
-   INTEL_INFO(dev)->gen >= 8)
+#define HAS_RESOURCE_STREAMER(dev_priv)(IS_HASWELL(dev_priv) || \
+INTEL_GEN(dev_priv) >= 8)
 
-#define HAS_CORE_RING_FREQ(dev)(INTEL_INFO(dev)->gen >= 6 && \
-!IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev) && \
-!IS_BROXTON(dev))
+#define HAS_CORE_RING_FREQ(dev_priv)   (INTEL_GEN(dev_priv) >= 6 && \
+!IS_VALLEYVIEW(dev_priv) && \
+!IS_CHERRYVIEW(dev_priv) && \
+!IS_BROXTON(dev_priv))
 
 #define HAS_POOLED_EU(dev_priv)(__INTEL_INFO(dev_priv)->has_pooled_eu)
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6a94d8723770..be85c0325ddf 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1651,7 +1651,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
 
if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
-   if (!HAS_RESOURCE_STREAMER(dev)) {
+   if (!HAS_RESOURCE_STREAMER(dev_priv)) {
DRM_DEBUG("RS is only allowed for Haswell, Gen8 and 
above\n");
return -EINVAL;
}
-- 
2.9.3

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


[Intel-gfx] [PATCH 07/12] drm/i915: INTEL_GEN() fixes, part 4

2016-08-29 Thread David Weinehall
Convert all instances of INTEL_INFO(dev)->gen in intel_pm.c
to INTEL_GEN(dev_priv).

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/intel_pm.c | 67 -
 1 file changed, 40 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f9c7708325e3..3eec187f5697 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1852,23 +1852,27 @@ static uint32_t ilk_compute_fbc_wm(const struct 
intel_crtc_state *cstate,
return ilk_wm_fbc(pri_val, drm_rect_width(>base.dst), cpp);
 }
 
-static unsigned int ilk_display_fifo_size(const struct drm_device *dev)
+static unsigned int
+ilk_display_fifo_size(const struct drm_i915_private *dev_priv)
 {
-   if (INTEL_INFO(dev)->gen >= 8)
+   if (INTEL_GEN(dev_priv) >= 8)
return 3072;
-   else if (INTEL_INFO(dev)->gen >= 7)
+   else if (INTEL_GEN(dev_priv) >= 7)
return 768;
else
return 512;
 }
 
-static unsigned int ilk_plane_wm_reg_max(const struct drm_device *dev,
-int level, bool is_sprite)
+static unsigned int
+ilk_plane_wm_reg_max(const struct drm_device *dev,
+int level, bool is_sprite)
 {
-   if (INTEL_INFO(dev)->gen >= 8)
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (INTEL_GEN(dev_priv) >= 8)
/* BDW primary/sprite plane watermarks */
return level == 0 ? 255 : 2047;
-   else if (INTEL_INFO(dev)->gen >= 7)
+   else if (INTEL_GEN(dev_priv) >= 7)
/* IVB/HSW primary/sprite plane watermarks */
return level == 0 ? 127 : 1023;
else if (!is_sprite)
@@ -1879,18 +1883,23 @@ static unsigned int ilk_plane_wm_reg_max(const struct 
drm_device *dev,
return level == 0 ? 63 : 255;
 }
 
-static unsigned int ilk_cursor_wm_reg_max(const struct drm_device *dev,
- int level)
+static unsigned int
+ilk_cursor_wm_reg_max(const struct drm_device *dev, int level)
 {
-   if (INTEL_INFO(dev)->gen >= 7)
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (INTEL_GEN(dev_priv) >= 7)
return level == 0 ? 63 : 255;
else
return level == 0 ? 31 : 63;
 }
 
-static unsigned int ilk_fbc_wm_reg_max(const struct drm_device *dev)
+static unsigned int
+ilk_fbc_wm_reg_max(const struct drm_device *dev)
 {
-   if (INTEL_INFO(dev)->gen >= 8)
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (INTEL_GEN(dev_priv) >= 8)
return 31;
else
return 15;
@@ -1903,7 +1912,8 @@ static unsigned int ilk_plane_wm_max(const struct 
drm_device *dev,
 enum intel_ddb_partitioning 
ddb_partitioning,
 bool is_sprite)
 {
-   unsigned int fifo_size = ilk_display_fifo_size(dev);
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   unsigned int fifo_size = ilk_display_fifo_size(dev_priv);
 
/* if sprites aren't enabled, sprites get nothing */
if (is_sprite && !config->sprites_enabled)
@@ -1918,7 +1928,7 @@ static unsigned int ilk_plane_wm_max(const struct 
drm_device *dev,
 * FIFO size is only half of the self
 * refresh FIFO size on ILK/SNB.
 */
-   if (INTEL_INFO(dev)->gen <= 6)
+   if (INTEL_GEN(dev_priv) <= 6)
fifo_size /= 2;
}
 
@@ -2163,14 +2173,14 @@ static void intel_read_wm_latency(struct drm_device 
*dev, uint16_t wm[8])
wm[2] = (sskpd >> 12) & 0xFF;
wm[3] = (sskpd >> 20) & 0x1FF;
wm[4] = (sskpd >> 32) & 0x1FF;
-   } else if (INTEL_INFO(dev)->gen >= 6) {
+   } else if (INTEL_GEN(dev_priv) >= 6) {
uint32_t sskpd = I915_READ(MCH_SSKPD);
 
wm[0] = (sskpd >> SSKPD_WM0_SHIFT) & SSKPD_WM_MASK;
wm[1] = (sskpd >> SSKPD_WM1_SHIFT) & SSKPD_WM_MASK;
wm[2] = (sskpd >> SSKPD_WM2_SHIFT) & SSKPD_WM_MASK;
wm[3] = (sskpd >> SSKPD_WM3_SHIFT) & SSKPD_WM_MASK;
-   } else if (INTEL_INFO(dev)->gen >= 5) {
+   } else if (INTEL_GEN(dev_priv) >= 5) {
uint32_t mltr = I915_READ(MLTR_ILK);
 
/* ILK primary LP0 latency is 700 ns */
@@ -2200,12 +2210,14 @@ static void intel_fixup_cur_wm_latency(struct 
drm_device *dev, uint16_t wm[5])
 
 int ilk_wm_max_level(const struct drm_device *dev)
 {
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
/* how many WM levels are we expecting */
-   if (INTEL_INFO(dev)->gen >= 9)
+   if (INTEL_GEN(dev_priv) >= 9)
return 7;
else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
return 4;
-   else if 

[Intel-gfx] Skylake underruns on 4.8-rc4

2016-08-29 Thread Andy Lutomirski
My Dell XPS 13 9350 laptop just got a buffer underrun:

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

I'm seeing this very occasionally, and they don't come in groups -- I
seem to get one underrun with a black flash and that's it.  This is
with just the laptop screen -- nothing at all is plugged in to the
USB-C port.

4.8-rc4 has the latest round of fixes applied, so
i915/skl_dmc_ver1_26.bin loaded successfully and the SAGV fix is
there.

I had the same problem on 4.8-rc3.  4.7 seemed okay.

I have:

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)

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


Re: [Intel-gfx] [PATCH] drm/i915: remove leftover for_each_intel_crtc_masked

2016-08-29 Thread Jani Nikula
On Mon, 29 Aug 2016, Ander Conselvan De Oliveira  wrote:
> On Thu, 2016-08-25 at 15:04 +0300, Jani Nikula wrote:
>> The last user of for_each_intel_crtc_masked macro was removed in
>> 
>> commit 0a9ab303b87a94115e361a7f3a15d9f481bc453b
>> Author: Ander Conselvan de Oliveira 
>> Date:   Tue Apr 21 17:13:04 2015 +0300
>> 
>> drm/i915: Remove all *_pipes flags from modeset
>> 
>> Get rid of the unused macro.
>> 
>> Cc: Ander Conselvan de Oliveira 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ander Conselvan de Oliveira 

Pushed, thanks.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 8 
>>  1 file changed, 8 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index e4e6141b38c0..19ffd024ddec 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13128,12 +13128,6 @@ static bool intel_fuzzy_clock_check(int clock1, int
>> clock2)
>>  return false;
>>  }
>>  
>> -#define for_each_intel_crtc_masked(dev, mask, intel_crtc) \
>> -list_for_each_entry((intel_crtc), \
>> -&(dev)->mode_config.crtc_list, \
>> -base.head) \
>> -for_each_if (mask & (1 <<(intel_crtc)->pipe))
>> -
>>  static bool
>>  intel_compare_m_n(unsigned int m, unsigned int n,
>>    unsigned int m2, unsigned int n2,
>> @@ -14585,8 +14579,6 @@ out:
>>  drm_atomic_state_free(state);
>>  }
>>  
>> -#undef for_each_intel_crtc_masked
>> -
>>  /*
>>   * FIXME: Remove this once i915 is fully DRIVER_ATOMIC by calling
>>   *drm_atomic_helper_legacy_gamma_set() directly.

-- 
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 17/17] drm/i915: Support explicit fencing for execbuf

2016-08-29 Thread Chris Wilson
On Sun, Aug 28, 2016 at 09:46:24PM +0100, Chris Wilson wrote:
> +/* Setting I915_EXEC_FENCE_OUT causes the ioctl to return a sync_file fd
> + * in the upper_32_bits(rsvd2) upon success. Ownership of the fd is given
> + * to the caller, and it should be close() after use. (The fd is a regular
> + * file descriptor and will be cleaned up on process termination. It holds
> + * a reference to the request, but nothing else.)
> + *
> + * The sync_file fd can be combined with other sync_file and passed either
> + * to execbuf using I915_EXEC_FENCE_IN, to atomic KMS ioctls (so that a flip
> + * will only occur after this request completes), or to other devices.

Addendum:

Using I915_EXEC_FENCE_OUT requires use of
DRM_IOCTL_I915_GEM_EXECBUFFER2_WR ioctl so that the result is written
back to userspace. Failure to do so will cause the out-fence to always
be reported as zero, and the real fence fd to be leaked.

-- 
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] i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

2016-08-29 Thread Meelis Roos
Tried 4.8-rc4 on my i5-2400 PC, got this warning:

[   14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   15.847321] [ cut here ]
[   15.847346] WARNING: CPU: 0 PID: 208 at drivers/gpu/drm/i915/intel_pm.c:7866 
sandybridge_pcode_write+0x109/0x1f0 [i915]
[   15.847348] Missing switch case (16) in gen6_check_mailbox_status
[   15.847349] Modules linked in: cpufreq_powersave cpufreq_userspace 
cpufreq_conservative joydev hid_generic usbhid hid x86_pkg_temp_thermal 
kvm_intel kvm irqbypass crc32c_intel aesni_intel snd_hda_codec_realtek 
snd_hda_codec_generic iTCO_wdt i915 aes_x86_64 iTCO_vendor_support glue_helper 
lrw ablk_helper cryptd video i2c_algo_bit drm_kms_helper psmouse pcspkr 
syscopyarea sysfillrect sysimgblt fb_sys_fops ehci_pci ehci_hcd snd_hda_intel 
xhci_pci xhci_hcd e1000e snd_hda_codec snd_hwdep usbcore drm snd_hda_core 
usb_common i2c_i801 ptp pps_core i2c_smbus snd_pcm_oss snd_mixer_oss snd_pcm 
snd_timer evdev snd tpm_tis lpc_ich parport_pc tpm_tis_core mfd_core parport 
nuvoton_cir rc_core tpm soundcore floppy w83627ehf hwmon_vid coretemp hwmon 
eeprom i2c_core loop ip_tables x_tables autofs4
[   15.847395] CPU: 0 PID: 208 Comm: kworker/0:2 Not tainted 4.8.0-rc4 #213
[   15.847396] Hardware name:  /DQ67OW, BIOS 
SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
[   15.847412] Workqueue: events intel_gen6_powersave_work [i915]
[   15.847414]   812d8198 88023191fd70 

[   15.847417]  81056d1e 88022ea4 88023191fdc0 

[   15.847419]  88022ea4a3c8 88022ea487c0 088023e21ba0 
81056d8f
[   15.847422] Call Trace:
[   15.847427]  [] ? dump_stack+0x46/0x5e
[   15.847429]  [] ? __warn+0xbe/0xe0
[   15.847431]  [] ? warn_slowpath_fmt+0x4f/0x60
[   15.847446]  [] ? sandybridge_pcode_write+0x109/0x1f0 
[i915]
[   15.847459]  [] ? intel_gen6_powersave_work+0x2a8/0x1400 
[i915]
[   15.847462]  [] ? process_one_work+0x1eb/0x480
[   15.847465]  [] ? worker_thread+0x47/0x4c0
[   15.847467]  [] ? __schedule+0x1d7/0x660
[   15.847469]  [] ? process_one_work+0x480/0x480
[   15.847472]  [] ? kthread+0xbd/0xe0
[   15.847475]  [] ? ret_from_fork+0x1f/0x40
[   15.847478]  [] ? kthread_worker_fn+0x160/0x160
[   15.847487] ---[ end trace ad9e991297d99be1 ]---

-- 
Meelis Roos (mr...@linux.ee)
___
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 [01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

2016-08-29 Thread Patchwork
== Series Details ==

Series: series starting with [01/11] drm/amdgpu: Remove call to 
reservation_object_test_signaled_rcu before wait
URL   : https://patchwork.freedesktop.org/series/11705/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6260u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
fail   -> PASS   (fi-bsw-n3050)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-hsw-4770k)

fi-bdw-5557u total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-bsw-n3050 total:252  pass:205  dwarn:0   dfail:0   fail:1   skip:46 
fi-hsw-4770k total:252  pass:228  dwarn:0   dfail:0   fail:2   skip:22 
fi-hsw-4770r total:252  pass:224  dwarn:0   dfail:0   fail:2   skip:26 
fi-ivb-3520m total:252  pass:220  dwarn:0   dfail:0   fail:1   skip:31 
fi-skl-6260u total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-skl-6700k total:252  pass:222  dwarn:0   dfail:0   fail:2   skip:28 
fi-snb-2520m total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 
fi-snb-2600  total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 

Results at /archive/results/CI_IGT_test/Patchwork_2444/

a72d2489965e2ae2d83cbdd784722396138378fc drm-intel-nightly: 
2016y-08m-29d-06h-05m-38s UTC integration manifest
dc106f2 dma-buf: Do a fast lockless check for poll with timeout=0
5a2b906 dma-buf: Use seqlock to close RCU race in test_signaled_single
80cd4d6 dma-buf: Restart reservation_object_test_signaled_rcu() after writes
75f4406 dma-buf: Restart reservation_object_wait_timeout_rcu() after writes
244eae2 dma-buf: Restart reservation_object_get_fences_rcu() after writes
d9ce65b dma-buf: Introduce fence_get_rcu_safe()
90c14ac drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before 
wait
e90bdbf drm/nouveau: Remove call to reservation_object_test_signaled_rcu before 
wait
96ef037 drm/msm: Remove call to reservation_object_test_signaled_rcu before wait
462131d drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu 
before wait
52e40e9 drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before 
wait

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


Re: [Intel-gfx] [PATCH] drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE to SNB

2016-08-29 Thread Maarten Lankhorst
Op 26-08-16 om 12:59 schreef Chris Wilson:
> According to the CI test machines, SNB also uses the
> GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
> GEN6_PCODE_MIN_FREQ_TABLE request.
>
> [  157.744641] WARNING: CPU: 5 PID: 9238 at
> drivers/gpu/drm/i915/intel_pm.c:7760 sandybridge_pcode_write+0x141/0x200 
> [i915]
> [  157.744642] Missing switch case (16) in gen6_check_mailbox_status
> [  157.744642] Modules linked in: snd_hda_intel i915 ax88179_178a usbnet mii 
> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
> ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me lpc_ich 
> snd_pcm mei broadcom bcm_phy_lib tg3 ptp pps_core [last unloaded: vgem]
> [  157.744658] CPU: 5 PID: 9238 Comm: drv_hangman Tainted: G U  W 
> 4.8.0-rc3-CI-CI_DRM_1589+ #1
> [  157.744658] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
> [  157.744659]   88011f093a98 81426415 
> 88011f093ae8
> [  157.744662]   88011f093ad8 8107d2a6 
> 1e50810d3c9f
> [  157.744663]  88012868 0008  
> 88012868a650
> [  157.744665] Call Trace:
> [  157.744669]  [] dump_stack+0x67/0x92
> [  157.744672]  [] __warn+0xc6/0xe0
> [  157.744673]  [] warn_slowpath_fmt+0x4a/0x50
> [  157.744685]  [] sandybridge_pcode_write+0x141/0x200 
> [i915]
> [  157.744697]  [] intel_enable_gt_powersave+0x64a/0x1330 
> [i915]
> [  157.744712]  [] ? i9xx_emit_request+0x1b/0x80 [i915]
> [  157.744725]  [] __i915_add_request+0x1e3/0x370 [i915]
> [  157.744738]  [] 
> i915_gem_do_execbuffer.isra.16+0xced/0x1b80 [i915]
> [  157.744740]  [] ? __might_fault+0x3e/0x90
> [  157.744752]  [] i915_gem_execbuffer2+0xc2/0x2a0 [i915]
> [  157.744753]  [] drm_ioctl+0x207/0x4c0
> [  157.744765]  [] ? i915_gem_execbuffer+0x360/0x360 [i915]
> [  157.744767]  [] ?  debug_lockdep_rcu_enabled+0x1d/0x20
> [  157.744769]  [] do_vfs_ioctl+0x8e/0x680
> [  157.744770]  [] ? __might_fault+0x87/0x90
> [  157.744771]  [] ? __might_fault+0x3e/0x90
> [  157.744773]  [] ?  trace_hardirqs_on_caller+0x122/0x1b0
> [  157.744774]  [] SyS_ioctl+0x3c/0x70
> [  157.744776]  [] entry_SYSCALL_64_fastpath+0x1c/0xac
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97491
> Fixes: 87660502f1a4 ("drm/i915/gen6+: Interpret mailbox error flags")
> Signed-off-by: Chris Wilson 
> Cc: Lyude 
> Cc: Matt Roper 
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 729d952174d8..aba6fd036c4e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7753,6 +7753,7 @@ static inline int gen6_check_mailbox_status(struct 
> drm_i915_private *dev_priv)
>   case GEN6_PCODE_ILLEGAL_CMD:
>   return -ENXIO;
>   case GEN6_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
> + case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
>   return -EOVERFLOW;
>   case GEN6_PCODE_TIMEOUT:
>   return -ETIMEDOUT;

Isn't it more likely that 0x10 means something different? I vaguely recall 
looking
over the table and saw that 10h was something different entirely, but can't 
find it back now.

~Maarten

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


Re: [Intel-gfx] [PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

2016-08-29 Thread Jani Nikula
On Sun, 28 Aug 2016, Andrea Arcangeli  wrote:
> Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> model which is based on IvyBridge.
>
> The commit that introduced the regression is
> 1d6da87a3241deb13d073c4125d19ed0e5a0c62c

That's a merge commit, the real one is

commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä 
Date:   Mon Apr 11 10:23:51 2016 +0300

drm/i915: Get panel_type from OpRegion panel details

> The Skylake workaround for the regression was introduced in commit
> aeddda06c1a704bb97c8a7bfe7a472120193bd56
>
> Signed-off-by: Andrea Arcangeli 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index adca262..ca17ab6 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1073,12 +1073,14 @@ intel_opregion_get_panel_type(struct drm_i915_private 
> *dev_priv)
>   }
>  
>   /*
> -  * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> -  * low vswing for eDP, whereas the VBT panel type (2) gives us normal
> -  * vswing instead. Low vswing results in some display flickers, so
> -  * let's simply ignore the OpRegion panel type on SKL for now.
> +  * FIXME On Dell XPS 13 9350 and Dell XPS 13 L322X the
> +  * OpRegion panel type (0) gives us low vswing for eDP,
> +  * whereas the VBT panel type (2) gives us normal vswing
> +  * instead. Low vswing results in some display flickers, so
> +  * let's simply ignore the OpRegion panel type on SKL and
> +  * IVYBRIDGE for now.
>*/

If it's an Iybridge, there's no low vswing, and that explanation is
false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
on an unpatched kernel.

Doesn't mean there can't be something else wrong with the mode you get
using a different panel_type. And this makes me wonder what the point is
in trying to patch up the commit instead of reverting.


BR,
Jani.



> - if (IS_SKYLAKE(dev_priv)) {
> + if (IS_SKYLAKE(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 08/11] dma-buf: Restart reservation_object_wait_timeout_rcu() after writes

2016-08-29 Thread Chris Wilson
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Christian König 
Cc: Alex Deucher 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/reservation.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 10fd441dd4ed..3369e4668e96 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -388,9 +388,6 @@ retry:
if (fobj)
shared_count = fobj->shared_count;
 
-   if (read_seqcount_retry(>seq, seq))
-   goto unlock_retry;
-
for (i = 0; i < shared_count; ++i) {
struct fence *lfence = rcu_dereference(fobj->shared[i]);
 
@@ -413,9 +410,6 @@ retry:
if (!shared_count) {
struct fence *fence_excl = rcu_dereference(obj->fence_excl);
 
-   if (read_seqcount_retry(>seq, seq))
-   goto unlock_retry;
-
if (fence_excl &&
!test_bit(FENCE_FLAG_SIGNALED_BIT, _excl->flags)) {
if (!fence_get_rcu(fence_excl))
@@ -430,6 +424,11 @@ retry:
 
rcu_read_unlock();
if (fence) {
+   if (read_seqcount_retry(>seq, seq)) {
+   fence_put(fence);
+   goto retry;
+   }
+
ret = fence_wait_timeout(fence, intr, ret);
fence_put(fence);
if (ret > 0 && wait_all && (i + 1 < shared_count))
-- 
2.9.3

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


[Intel-gfx] [PATCH 07/11] dma-buf: Restart reservation_object_get_fences_rcu() after writes

2016-08-29 Thread Chris Wilson
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Christian König 
Cc: Alex Deucher 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/reservation.c | 71 +++
 1 file changed, 31 insertions(+), 40 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 723d8af988e5..10fd441dd4ed 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -280,18 +280,24 @@ int reservation_object_get_fences_rcu(struct 
reservation_object *obj,
  unsigned *pshared_count,
  struct fence ***pshared)
 {
-   unsigned shared_count = 0;
-   unsigned retry = 1;
-   struct fence **shared = NULL, *fence_excl = NULL;
-   int ret = 0;
+   struct fence **shared = NULL;
+   struct fence *fence_excl;
+   unsigned shared_count;
+   int ret = 1;
 
-   while (retry) {
+   do {
struct reservation_object_list *fobj;
unsigned seq;
+   unsigned i;
 
-   seq = read_seqcount_begin(>seq);
+   shared_count = i = 0;
 
rcu_read_lock();
+   seq = read_seqcount_begin(>seq);
+
+   fence_excl = rcu_dereference(obj->fence_excl);
+   if (fence_excl && !fence_get_rcu(fence_excl))
+   goto unlock;
 
fobj = rcu_dereference(obj->fence);
if (fobj) {
@@ -309,52 +315,37 @@ int reservation_object_get_fences_rcu(struct 
reservation_object *obj,
}
 
ret = -ENOMEM;
-   shared_count = 0;
break;
}
shared = nshared;
-   memcpy(shared, fobj->shared, sz);
shared_count = fobj->shared_count;
-   } else
-   shared_count = 0;
-   fence_excl = rcu_dereference(obj->fence_excl);
-
-   retry = read_seqcount_retry(>seq, seq);
-   if (retry)
-   goto unlock;
-
-   if (!fence_excl || fence_get_rcu(fence_excl)) {
-   unsigned i;
 
for (i = 0; i < shared_count; ++i) {
-   if (fence_get_rcu(shared[i]))
-   continue;
-
-   /* uh oh, refcount failed, abort and retry */
-   while (i--)
-   fence_put(shared[i]);
-
-   if (fence_excl) {
-   fence_put(fence_excl);
-   fence_excl = NULL;
-   }
-
-   retry = 1;
-   break;
+   shared[i] = rcu_dereference(fobj->shared[i]);
+   if (!fence_get_rcu(shared[i]))
+   break;
}
-   } else
-   retry = 1;
+   }
+
+   if (i != shared_count || read_seqcount_retry(>seq, seq)) {
+   while (i--)
+   fence_put(shared[i]);
+   fence_put(fence_excl);
+   goto unlock;
+   }
 
+   ret = 0;
 unlock:
rcu_read_unlock();
-   }
-   *pshared_count = shared_count;
-   if (shared_count)
-   *pshared = shared;
-   else {
-   *pshared = NULL;
+   } while (ret);
+
+   if (!shared_count) {
kfree(shared);
+   shared = NULL;
}
+
+   *pshared_count = shared_count;
+   *pshared = shared;
*pfence_excl = fence_excl;
 
return ret;
-- 
2.9.3

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


[Intel-gfx] [PATCH 09/11] dma-buf: Restart reservation_object_test_signaled_rcu() after writes

2016-08-29 Thread Chris Wilson
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Christian König 
Cc: Alex Deucher 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/reservation.c | 30 ++
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 3369e4668e96..e74493e7332b 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -474,12 +474,13 @@ bool reservation_object_test_signaled_rcu(struct 
reservation_object *obj,
  bool test_all)
 {
unsigned seq, shared_count;
-   int ret = true;
+   int ret;
 
+   rcu_read_lock();
 retry:
+   ret = true;
shared_count = 0;
seq = read_seqcount_begin(>seq);
-   rcu_read_lock();
 
if (test_all) {
unsigned i;
@@ -490,46 +491,35 @@ retry:
if (fobj)
shared_count = fobj->shared_count;
 
-   if (read_seqcount_retry(>seq, seq))
-   goto unlock_retry;
-
for (i = 0; i < shared_count; ++i) {
struct fence *fence = rcu_dereference(fobj->shared[i]);
 
ret = reservation_object_test_signaled_single(fence);
if (ret < 0)
-   goto unlock_retry;
+   goto retry;
else if (!ret)
break;
}
 
-   /*
-* There could be a read_seqcount_retry here, but nothing cares
-* about whether it's the old or newer fence pointers that are
-* signaled. That race could still have happened after checking
-* read_seqcount_retry. If you care, use ww_mutex_lock.
-*/
+   if (read_seqcount_retry(>seq, seq))
+   goto retry;
}
 
if (!shared_count) {
struct fence *fence_excl = rcu_dereference(obj->fence_excl);
 
-   if (read_seqcount_retry(>seq, seq))
-   goto unlock_retry;
-
if (fence_excl) {
ret = reservation_object_test_signaled_single(
fence_excl);
if (ret < 0)
-   goto unlock_retry;
+   goto retry;
+
+   if (read_seqcount_retry(>seq, seq))
+   goto retry;
}
}
 
rcu_read_unlock();
return ret;
-
-unlock_retry:
-   rcu_read_unlock();
-   goto retry;
 }
 EXPORT_SYMBOL_GPL(reservation_object_test_signaled_rcu);
-- 
2.9.3

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


[Intel-gfx] [PATCH 10/11] dma-buf: Use seqlock to close RCU race in test_signaled_single

2016-08-29 Thread Chris Wilson
With the seqlock now extended to cover the lookup of the fence and its
testing, we can perform that testing solely under the seqlock guard and
avoid the effective locking and serialisation of acquiring a reference to
the request.  As the fence is RCU protected we know it cannot disappear
as we test it, the same guarantee that made it safe to acquire the
reference previously.  The seqlock tests whether the fence was replaced
as we are testing it telling us whether or not we can trust the result
(if not, we just repeat the test until stable).

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/reservation.c | 32 
 1 file changed, 4 insertions(+), 28 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index e74493e7332b..1ddffa5adb5a 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -442,24 +442,6 @@ unlock_retry:
 }
 EXPORT_SYMBOL_GPL(reservation_object_wait_timeout_rcu);
 
-
-static inline int
-reservation_object_test_signaled_single(struct fence *passed_fence)
-{
-   struct fence *fence, *lfence = passed_fence;
-   int ret = 1;
-
-   if (!test_bit(FENCE_FLAG_SIGNALED_BIT, >flags)) {
-   fence = fence_get_rcu(lfence);
-   if (!fence)
-   return -1;
-
-   ret = !!fence_is_signaled(fence);
-   fence_put(fence);
-   }
-   return ret;
-}
-
 /**
  * reservation_object_test_signaled_rcu - Test if a reservation object's
  * fences have been signaled.
@@ -474,7 +456,7 @@ bool reservation_object_test_signaled_rcu(struct 
reservation_object *obj,
  bool test_all)
 {
unsigned seq, shared_count;
-   int ret;
+   bool ret;
 
rcu_read_lock();
 retry:
@@ -494,10 +476,8 @@ retry:
for (i = 0; i < shared_count; ++i) {
struct fence *fence = rcu_dereference(fobj->shared[i]);
 
-   ret = reservation_object_test_signaled_single(fence);
-   if (ret < 0)
-   goto retry;
-   else if (!ret)
+   ret = fence_is_signaled(fence);
+   if (!ret)
break;
}
 
@@ -509,11 +489,7 @@ retry:
struct fence *fence_excl = rcu_dereference(obj->fence_excl);
 
if (fence_excl) {
-   ret = reservation_object_test_signaled_single(
-   fence_excl);
-   if (ret < 0)
-   goto retry;
-
+   ret = fence_is_signaled(fence_excl);
if (read_seqcount_retry(>seq, seq))
goto retry;
}
-- 
2.9.3

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


[Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

2016-08-29 Thread Chris Wilson
Currently we install a callback for performing poll on a dma-buf,
irrespective of the timeout. This involves taking a spinlock, as well as
unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
multiple threads.

We can query whether the poll will block prior to installing the
callback to make the busy-query fast.

Single thread: 60% faster
8 threads on 4 (+4 HT) cores: 600% faster

Still not quite the perfect scaling we get with a native busy ioctl, but
poll(dmabuf) is faster due to the quicker lookup of the object and
avoiding drm_ioctl().

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Reviewed-by: Daniel Vetter 
---
 drivers/dma-buf/dma-buf.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index cf04d249a6a4..c7a7bc579941 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -156,6 +156,18 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
if (!events)
return 0;
 
+   if (poll_does_not_wait(poll)) {
+   if (events & POLLOUT &&
+   !reservation_object_test_signaled_rcu(resv, true))
+   events &= ~(POLLOUT | POLLIN);
+
+   if (events & POLLIN &&
+   !reservation_object_test_signaled_rcu(resv, false))
+   events &= ~POLLIN;
+
+   return events;
+   }
+
 retry:
seq = read_seqcount_begin(>seq);
rcu_read_lock();
-- 
2.9.3

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


[Intel-gfx] [PATCH 04/11] drm/nouveau: Remove call to reservation_object_test_signaled_rcu before wait

2016-08-29 Thread Chris Wilson
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

Signed-off-by: Chris Wilson 
Cc: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 72e2399bce39..b90e21ff1ed8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -861,6 +861,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void 
*data,
struct nouveau_bo *nvbo;
bool no_wait = !!(req->flags & NOUVEAU_GEM_CPU_PREP_NOWAIT);
bool write = !!(req->flags & NOUVEAU_GEM_CPU_PREP_WRITE);
+   long lret;
int ret;
 
gem = drm_gem_object_lookup(file_priv, req->handle);
@@ -868,19 +869,15 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void 
*data,
return -ENOENT;
nvbo = nouveau_gem_object(gem);
 
-   if (no_wait)
-   ret = reservation_object_test_signaled_rcu(nvbo->bo.resv, 
write) ? 0 : -EBUSY;
-   else {
-   long lret;
+   lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true,
+  no_wait ? 0 :30 * HZ);
+   if (!lret)
+   ret = -EBUSY;
+   else if (lret > 0)
+   ret = 0;
+   else
+   ret = lret;
 
-   lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, 
write, true, 30 * HZ);
-   if (!lret)
-   ret = -EBUSY;
-   else if (lret > 0)
-   ret = 0;
-   else
-   ret = lret;
-   }
nouveau_bo_sync_for_cpu(nvbo);
drm_gem_object_unreference_unlocked(gem);
 
-- 
2.9.3

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


[Intel-gfx] [PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

2016-08-29 Thread Chris Wilson
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 88fbed2389c0..a3e6f883ac2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -407,10 +407,8 @@ int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, 
void *data,
return -ENOENT;
}
robj = gem_to_amdgpu_bo(gobj);
-   if (timeout == 0)
-   ret = reservation_object_test_signaled_rcu(robj->tbo.resv, 
true);
-   else
-   ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, 
true, timeout);
+   ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true,
+ timeout);
 
/* ret == 0 means not signaled,
 * ret > 0 means signaled
-- 
2.9.3

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


[Intel-gfx] [PATCH 06/11] dma-buf: Introduce fence_get_rcu_safe()

2016-08-29 Thread Chris Wilson
This variant of fence_get_rcu() takes an RCU protected pointer to a
fence and carefully returns a reference to the fence ensuring that it is
not reallocated as it does. This is required when mixing fences and
SLAB_DESTROY_BY_RCU - although it serves a more pedagogical function atm

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 include/linux/fence.h | 56 ++-
 1 file changed, 51 insertions(+), 5 deletions(-)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index 0d763053f97a..c9c5ba98c302 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -183,6 +183,16 @@ void fence_release(struct kref *kref);
 void fence_free(struct fence *fence);
 
 /**
+ * fence_put - decreases refcount of the fence
+ * @fence: [in]fence to reduce refcount of
+ */
+static inline void fence_put(struct fence *fence)
+{
+   if (fence)
+   kref_put(>refcount, fence_release);
+}
+
+/**
  * fence_get - increases refcount of the fence
  * @fence: [in]fence to increase refcount of
  *
@@ -210,13 +220,49 @@ static inline struct fence *fence_get_rcu(struct fence 
*fence)
 }
 
 /**
- * fence_put - decreases refcount of the fence
- * @fence: [in]fence to reduce refcount of
+ * fence_get_rcu_safe  - acquire a reference to an RCU tracked fence
+ * @fence: [in]pointer to fence to increase refcount of
+ *
+ * Function returns NULL if no refcount could be obtained, or the fence.
+ * This function handles acquiring a reference to a fence that may be
+ * reallocated within the RCU grace period (such as with SLAB_DESTROY_BY_RCU),
+ * so long as the caller is using RCU on the pointer to the fence.
+ *
+ * An alternative mechanism is to employ a seqlock to protect a bunch of
+ * fences, such as used by struct reservation_object. When using a seqlock,
+ * the seqlock must be taken before and checked after a reference to the
+ * fence is acquired (as shown here).
+ *
+ * The caller is required to hold the RCU read lock.
  */
-static inline void fence_put(struct fence *fence)
+static inline struct fence *fence_get_rcu_safe(struct fence * __rcu *fencep)
 {
-   if (fence)
-   kref_put(>refcount, fence_release);
+   do {
+   struct fence *fence;
+
+   fence = rcu_dereference(*fencep);
+   if (!fence || !fence_get_rcu(fence))
+   return NULL;
+
+   /* The atomic_inc_not_zero() inside fence_get_rcu()
+* provides a full memory barrier upon success (such as now).
+* This is paired with the write barrier from assigning
+* to the __rcu protected fence pointer so that if that
+* pointer still matches the current fence, we know we
+* have successfully acquire a reference to it. If it no
+* longer matches, we are holding a reference to some other
+* reallocated pointer. This is possible if the allocator
+* is using a freelist like SLAB_DESTROY_BY_RCU where the
+* fence remains valid for the RCU grace period, but it
+* may be reallocated. When using such allocators, we are
+* responsible for ensuring the reference we get is to
+* the right fence, as below.
+*/
+   if (fence == rcu_access_pointer(*fencep))
+   return rcu_pointer_handoff(fence);
+
+   fence_put(fence);
+   } while (1);
 }
 
 int fence_signal(struct fence *fence);
-- 
2.9.3

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


[Intel-gfx] [PATCH 05/11] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait

2016-08-29 Thread Chris Wilson
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

Signed-off-by: Chris Wilson 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 6a328d507a28..1a85fb2d4dc6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -574,10 +574,8 @@ static int vmw_user_dmabuf_synccpu_grab(struct 
vmw_user_dma_buffer *user_bo,
bool nonblock = !!(flags & drm_vmw_synccpu_dontblock);
long lret;
 
-   if (nonblock)
-   return reservation_object_test_signaled_rcu(bo->resv, 
true) ? 0 : -EBUSY;
-
-   lret = reservation_object_wait_timeout_rcu(bo->resv, true, 
true, MAX_SCHEDULE_TIMEOUT);
+   lret = reservation_object_wait_timeout_rcu(bo->resv, true, true,
+  nonblock ? 0 : 
MAX_SCHEDULE_TIMEOUT);
if (!lret)
return -EBUSY;
else if (lret < 0)
-- 
2.9.3

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


[Intel-gfx] [PATCH 03/11] drm/msm: Remove call to reservation_object_test_signaled_rcu before wait

2016-08-29 Thread Chris Wilson
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

v2: 9 is only 0 in German.

Signed-off-by: Chris Wilson 
Cc: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6cd4af443139..45796a88d353 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -584,18 +584,16 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t 
op, ktime_t *timeout)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
bool write = !!(op & MSM_PREP_WRITE);
-
-   if (op & MSM_PREP_NOSYNC) {
-   if (!reservation_object_test_signaled_rcu(msm_obj->resv, write))
-   return -EBUSY;
-   } else {
-   int ret;
-
-   ret = reservation_object_wait_timeout_rcu(msm_obj->resv, write,
-   true, timeout_to_jiffies(timeout));
-   if (ret <= 0)
-   return ret == 0 ? -ETIMEDOUT : ret;
-   }
+   unsigned long remain =
+   op & MSG_PREP_NOSYNC ? 0 : timeout_to_jiffies(timeout);
+   long ret;
+
+   ret = reservation_object_wait_timeout_rcu(msm_obj->resv, write,
+ true,  remain);
+   if (ret == 0)
+   return remain == 0 ? -EBUSY : -ETIMEDOUT;
+   else if (ret < 0)
+   return ret;
 
/* TODO cache maintenance */
 
-- 
2.9.3

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


[Intel-gfx] [PATCH 02/11] drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu before wait

2016-08-29 Thread Chris Wilson
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

Signed-off-by: Chris Wilson 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 5ce3603e6eac..9ffca2478e02 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -409,20 +409,16 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 
op,
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
struct drm_device *dev = obj->dev;
bool write = !!(op & ETNA_PREP_WRITE);
-   int ret;
-
-   if (op & ETNA_PREP_NOSYNC) {
-   if (!reservation_object_test_signaled_rcu(etnaviv_obj->resv,
- write))
-   return -EBUSY;
-   } else {
-   unsigned long remain = etnaviv_timeout_to_jiffies(timeout);
-
-   ret = reservation_object_wait_timeout_rcu(etnaviv_obj->resv,
- write, true, remain);
-   if (ret <= 0)
-   return ret == 0 ? -ETIMEDOUT : ret;
-   }
+   unsigned long remain =
+   op & ETNA_PREP_NOSYNC ? 0 : etnaviv_timeout_to_jiffies(timeout);
+   long lret;
+
+   lret = reservation_object_wait_timeout_rcu(etnaviv_obj->resv,
+  write, true, remain);
+   if (lret < 0)
+   return lret;
+   else if (lret == 0)
+   return remain == 0 ? -EBUSY : -ETIMEDOUT;
 
if (etnaviv_obj->flags & ETNA_BO_CACHED) {
if (!etnaviv_obj->sgt) {
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

2016-08-29 Thread Maarten Lankhorst
Op 25-08-16 om 20:56 schreef Paolo Stivanin:
> Hello,
> I applied these patches[1][2] to the latest kernel revision (
> 4.8.0-rc3-g61c0457) but the brightness keys are not working on my
> laptop.
> With the older patches from the 29th of June the brightness keys were
> working correctly.
>
> Cheers,
>
> [1] https://patchwork.freedesktop.org/patch/107280/
> [2] https://patchwork.freedesktop.org/patch/107281/
>
Does it work after suspend?

~Maarten

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