[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Plumb modifiers through plane init

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Plumb modifiers through plane init
URL   : https://patchwork.freedesktop.org/series/23862/
State : success

== Summary ==

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

Test drv_module_reload:
Subgroup basic-reload-final:
dmesg-warn -> PASS   (fi-skl-6770hq) fdo#100248

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:549s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:492s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:565s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:458s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:460s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:439s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:527s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

7f027554339633cb4e6a2d3974510aaef1a9e24c drm-tip: 2017y-05m-02d-18h-48m-28s UTC 
integration manifest
599b151 drm/i915: Add format modifiers for Intel
23f6b02 drm: Create a format/modifier blob
c32fe9d drm: Plumb modifiers through plane init

== Logs ==

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

[Intel-gfx] [PATCH 3/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

v2:
  - Add LINEAR and Yf modifiers to list (Ville)
  - Combine i8xx and i965 into one list of formats (Ville)
  - Allow 1010102 formats for Y/Yf tiled (Ville)

v3:
  - Handle cursor formats (Ville)
  - Put handling for LINEAR in the mod_support functions (Ville)

v4:
  - List each modifier explicitly in supported modifiers (Ville)
  - Handle the CURSOR plane (Ville)

v5:
  - Split out cursor and sprite handling (Ville)

Cc: Ville Syrjälä 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 131 +--
 drivers/gpu/drm/i915/intel_sprite.c  |  76 +++-
 2 files changed, 201 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d52bd05a017d..18aac538d978 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };
 
+static const uint64_t i9xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED,
+   I915_FORMAT_MOD_Y_TILED,
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13381,6 +13395,103 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }
 
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   return true;
+   default:
+   return false;
+   }
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   /* All i915 modifiers are fine */
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_Yf_TILED:
+   return true;
+   default:
+   return false;
+   }
+   default:
+   return false;
+   }
+}
+
+static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+   return false;
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   return skl_mod_supported(format, modifier);
+   else if (INTEL_GEN(dev_priv) >= 4)
+   return i965_mod_supported(format, modifier);
+   else
+   return i8xx_mod_supported(format, modifier);
+
+   return false;
+}
+
+static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
+   uint32_t format,
+   

[Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/drm_mode_config.c |   7 +++
 drivers/gpu/drm/drm_plane.c   | 119 ++
 include/drm/drm_mode_config.h |   6 ++
 include/uapi/drm/drm_mode.h   |  26 +
 4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ 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(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }
 
+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+   /* Version of this blob format */
+   u32 version;
+
+   /* Flags */
+   u32 flags;
+
+   /* Number of fourcc formats supported */
+   u32 count_formats;
+
+   /* Where in this blob the formats exist (in bytes) */
+   u32 formats_offset;
+
+   /* Number of drm_format_modifiers */
+   u32 count_modifiers;
+
+   /* Where in this blob the modifiers exist (in bytes) */
+   u32 modifiers_offset;
+
+   /* u32 formats[] */
+   /* struct drm_format_modifier modifiers[] */
+} __packed;
+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int 
format_count,
+const uint64_t *format_modifiers)
+{
+   const struct drm_mode_config *config = >mode_config;
+   const uint64_t *temp_modifiers = format_modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (format_modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(__u32) * format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), formats, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; i++) {
+   for (j = 0; j < format_count; j++) {
+   if (funcs->format_mod_supported(plane, formats[j],
+   format_modifiers[i])) {
+   mod->formats |= 1 << j;
+   }
+   }
+
+   mod->modifier = 

[Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Ben Widawsky]

v2: A minor addition from Daniel

Cc: Daniel Stone 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
 drivers/gpu/drm/arm/malidp_planes.c |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c|  1 +
 drivers/gpu/drm/armada/armada_overlay.c |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 +++-
 drivers/gpu/drm/drm_modeset_helper.c|  1 +
 drivers/gpu/drm/drm_plane.c | 32 -
 drivers/gpu/drm/drm_simple_kms_helper.c |  3 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  7 +-
 drivers/gpu/drm/i915/intel_sprite.c |  4 ++--
 drivers/gpu/drm/imx/ipuv3-plane.c   |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 ++--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  5 ++--
 drivers/gpu/drm/omapdrm/omap_plane.c|  3 ++-
 drivers/gpu/drm/qxl/qxl_display.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  4 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 ++--
 drivers/gpu/drm/sti/sti_cursor.c|  2 +-
 drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  2 +-
 drivers/gpu/drm/tegra/dc.c  | 12 +-
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|  4 ++--
 drivers/gpu/drm/zte/zx_plane.c  |  2 +-
 include/drm/drm_plane.h | 21 +++-
 include/drm/drm_simple_kms_helper.h |  1 +
 include/uapi/drm/drm_fourcc.h   | 11 +
 41 files changed, 126 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..cd8a24c7c67d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct 
drm_device *drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, _pgu_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 798a3cc480a2..0caa03ae8708 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device 
*drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, _plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
devm_kfree(drm->dev, plane);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 814fda23cead..b156610c68a5 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -400,7 +400,7 @@ int malidp_de_planes_init(struct drm_device *drm)
DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(drm, >base, crtcs,
   _de_plane_funcs, formats,
-  n, plane_type, NULL);
+  n, NULL, plane_type, NULL);
if (ret < 0)
goto cleanup;
 
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 4fe19fde84f9..ea48ef88f0e4 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1269,6 +1269,7 @@ static int armada_drm_crtc_create(struct drm_device *drm, 
struct device *dev,
   _primary_plane_funcs,
   armada_primary_formats,
   

Re: [Intel-gfx] [PATCH RESEND v4 6/6] drm/i915: Set PWM divider to match desired frequency in vbt

[Manasi Navare]

On Wed, May 03, 2017 at 02:15:06AM +, Pandiyan, Dhinakaran wrote:
> On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote:
> > Read desired PWM frequency from panel vbt and calculate the
> > value for divider in DPCD address 0x724 and 0x728 to match
> > that frequency as close as possible.
> > 
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 56 
> > +++
> >  1 file changed, 56 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index f99cf0a6ae44..9adc77bfb515 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -111,12 +111,60 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
> > intel_dp *intel_dp,
> >   dbc, sizeof(dbc));
> >  }
> >  
> > +/*
> > + * Set PWM Frequency divider to match desired frequency in vbt.
> > + * The PWM Frequency is calculated as 27Mhz / (F x P).
> > + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of 
> > the
> > + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> > + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> > + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> > + */
> > +static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > +   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
> > +   int freq, fxp, f;
> > +   u8 pn, pn_min, pn_max;
> > +
> > +   /* Find desired value of (F x P)
> > +* Note that, if F x P is out of supported range, the maximum value or
> > +* minimum value will applied automatically. So no need to check that.
> > +*/
> > +   freq = dev_priv->vbt.backlight.pwm_freq_hz;
> > +   fxp = DP_EDP_BACKLIGHT_FREQ_BASE / freq;
> 
> 
> 
> How do we know vbt.backlight.pwm_freq_hz isn't zero? Or am I missing
> something here.
> intel_panel.c: get_backlight_max_vbt() seems to do a check.
> 
> 
> -DK
>

Yes I had the exact same comment, you should check for if 
(!vbt.backlight.pwm_freq_hz)

Everything else looks good to me.

Manasi
 
> > +
> > +   /* Use lowest possible value of Pn to try to make F to be between 1 and
> > +* 255 while still in the range Pn_min and Pn_max
> > +*/
> > +   if (!drm_dp_dpcd_readb(_dp->aux,
> > +  DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min)) {
> > +   return;
> > +   }
> > +   if (!drm_dp_dpcd_readb(_dp->aux,
> > +  DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max)) {
> > +   return;
> > +   }
> > +   pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > +   pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > +   f = fxp / (1 << pn_min);
> > +   for (pn = pn_min; pn < pn_max && f > 255; pn++)
> > +   f /= 2;
> > +
> > +   /* Cap F to be in the range between 1 and 255. */
> > +   f = min(f, 255);
> > +   f = max(f, 1);
> > +
> > +   drm_dp_dpcd_writeb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, pn);
> > +   drm_dp_dpcd_writeb(_dp->aux, DP_EDP_BACKLIGHT_FREQ_SET, (u8) f);
> > +}
> > +
> >  static void intel_dp_aux_enable_backlight(struct intel_connector 
> > *connector)
> >  {
> > struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
> > uint8_t dpcd_buf = 0;
> > uint8_t new_dpcd_buf = 0;
> > uint8_t edp_backlight_mode = 0;
> > +   bool freq_cap;
> >  
> > set_aux_backlight_enable(intel_dp, true);
> >  
> > @@ -147,10 +195,18 @@ static void intel_dp_aux_enable_backlight(struct 
> > intel_connector *connector)
> > intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
> > }
> >  
> > +   freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
> > +   if (freq_cap)
> > +   new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
> > +
> > if (new_dpcd_buf != dpcd_buf) {
> > drm_dp_dpcd_writeb(_dp->aux,
> > DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf);
> > }
> > +
> > +   if (freq_cap)
> > +   intel_dp_aux_set_pwm_freq(connector);
> > +
> > intel_dp_aux_set_backlight(connector, connector->panel.backlight.level);
> >  }
> >  
> 
> ___
> 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 RESEND v4 3/6] drm/i915: Support dynamic backlight via DPCD register

[Pandiyan, Dhinakaran]

On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote:
> This patch enables dynamic backlight by default for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.


What does dynamic backlight do? I am trying to understand what allowing
0% minimum brightness means. 


> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 31 
> +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index f06c8381c74e..ae1b6fe67feb 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -97,10 +97,24 @@ intel_dp_aux_set_backlight(struct intel_connector 
> *connector, u32 level)
>   }
>  }
>  
> +/*
> + * Set minimum / maximum dynamic brightness percentage. This value is 
> expressed
> + * as the percentage of normal brightness in 5% increments.
> + */
> +static void
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> + drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> +   dbc, sizeof(dbc));
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
> + uint8_t new_dpcd_buf = 0;
>   uint8_t edp_backlight_mode = 0;
>  
>   set_aux_backlight_enable(intel_dp, true);
> @@ -110,16 +124,15 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   return;
>   }
>  
> + new_dpcd_buf = dpcd_buf;
>   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>  
>   switch (edp_backlight_mode) {
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> - drm_dp_dpcd_writeb(_dp->aux,
> - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf);
> + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>   break;
>  
>   /* Do nothing when it is already DPCD mode */
> @@ -127,6 +140,16 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   default:
>   break;
>   }


Still need a switch here? You are setting mode as
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD for all four values of mode. 



> +
> + if (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP) {
> + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> + intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
> + }

Should enabling dynamic backlight control be logged in debug messages?
Could be useful in case this turns out to be buggy.

-DK

> +
> + if (new_dpcd_buf != dpcd_buf) {
> + drm_dp_dpcd_writeb(_dp->aux,
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf);
> + }
>  }
>  
>  static void intel_dp_aux_disable_backlight(struct intel_connector *connector)

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

Re: [Intel-gfx] [PATCH RESEND v4 6/6] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote:
> Read desired PWM frequency from panel vbt and calculate the
> value for divider in DPCD address 0x724 and 0x728 to match
> that frequency as close as possible.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 56 
> +++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index f99cf0a6ae44..9adc77bfb515 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -111,12 +111,60 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
> intel_dp *intel_dp,
> dbc, sizeof(dbc));
>  }
>  
> +/*
> + * Set PWM Frequency divider to match desired frequency in vbt.
> + * The PWM Frequency is calculated as 27Mhz / (F x P).
> + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
> + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> + */
> +static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
> + int freq, fxp, f;
> + u8 pn, pn_min, pn_max;
> +
> + /* Find desired value of (F x P)
> +  * Note that, if F x P is out of supported range, the maximum value or
> +  * minimum value will applied automatically. So no need to check that.
> +  */
> + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> + fxp = DP_EDP_BACKLIGHT_FREQ_BASE / freq;



How do we know vbt.backlight.pwm_freq_hz isn't zero? Or am I missing
something here.
intel_panel.c: get_backlight_max_vbt() seems to do a check.


-DK

> +
> + /* Use lowest possible value of Pn to try to make F to be between 1 and
> +  * 255 while still in the range Pn_min and Pn_max
> +  */
> + if (!drm_dp_dpcd_readb(_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min)) {
> + return;
> + }
> + if (!drm_dp_dpcd_readb(_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max)) {
> + return;
> + }
> + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> + f = fxp / (1 << pn_min);
> + for (pn = pn_min; pn < pn_max && f > 255; pn++)
> + f /= 2;
> +
> + /* Cap F to be in the range between 1 and 255. */
> + f = min(f, 255);
> + f = max(f, 1);
> +
> + drm_dp_dpcd_writeb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, pn);
> + drm_dp_dpcd_writeb(_dp->aux, DP_EDP_BACKLIGHT_FREQ_SET, (u8) f);
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
>   uint8_t new_dpcd_buf = 0;
>   uint8_t edp_backlight_mode = 0;
> + bool freq_cap;
>  
>   set_aux_backlight_enable(intel_dp, true);
>  
> @@ -147,10 +195,18 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
>   }
>  
> + freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
> + if (freq_cap)
> + new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
> +
>   if (new_dpcd_buf != dpcd_buf) {
>   drm_dp_dpcd_writeb(_dp->aux,
>   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf);
>   }
> +
> + if (freq_cap)
> + intel_dp_aux_set_pwm_freq(connector);
> +
>   intel_dp_aux_set_backlight(connector, connector->panel.backlight.level);
>  }
>  

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

Re: [Intel-gfx] [PATCH RESEND v4 2/6] drm/i915: Correctly enable blacklight adjustment via DPCD

[Manasi Navare]

On Tue, Apr 18, 2017 at 04:48:20PM -0700, Puthikorn Voravootivat wrote:
> intel_dp_aux_enable_backlight() assumed that the register
> BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
> (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.
> 
> This patch fixed that by handling all cases of that register.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 29 
> +--
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 42f73d9a3ccf..f06c8381c74e 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -101,15 +101,32 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
> + uint8_t edp_backlight_mode = 0;
>  
>   set_aux_backlight_enable(intel_dp, true);
>  
> - if ((drm_dp_dpcd_readb(_dp->aux,
> -DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) 
> == 1) &&
> - ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> -  DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
> - drm_dp_dpcd_writeb(_dp->aux, 
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> -(dpcd_buf | 
> DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
> + if (!drm_dp_dpcd_readb(_dp->aux,
> +DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf)) {
> + return;
> + }
> +
> + edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> +
> + switch (edp_backlight_mode) {
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> + dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> + drm_dp_dpcd_writeb(_dp->aux,
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf);
> + break;
> +
> + /* Do nothing when it is already DPCD mode */
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
> + default:
> + break;

Do you really need a break; here?

Manasi
> + }
>  }
>  
>  static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
> -- 
> 2.12.2.816.g281164-goog
> 
> ___
> 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] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Chen, Xiaoguang]

>-Original Message-
>From: Gerd Hoffmann [mailto:kra...@redhat.com]
>Sent: Tuesday, May 02, 2017 5:51 PM
>To: Chen, Xiaoguang 
>Cc: alex.william...@redhat.com; intel-gfx@lists.freedesktop.org; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A ;
>zhen...@linux.intel.com; linux-ker...@vger.kernel.org; Lv, Zhiyuan
>; Tian, Kevin 
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote:
>> +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char
>> *buf,
>> +   size_t count, loff_t *ppos, bool iswrite) {
>> +   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
>> +   VFIO_PCI_NUM_REGIONS;
>> +   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>> +   int fd;
>> +
>> +   if (pos >= vgpu->vdev.region[i].size || iswrite) {
>> +   gvt_vgpu_err("invalid op or offset for Intel vgpu fd
>> region\n");
>> +   return -EINVAL;
>> +   }
>> +
>> +   fd = anon_inode_getfd("gvtg", _vgpu_gvtg_ops, vgpu,
>> +   O_RDWR | O_CLOEXEC);
>> +   if (fd < 0) {
>> +   gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd);
>> +   return -EINVAL;
>> +   }
>> +
>> +   count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
>> +   memcpy(buf, , count);
>> +
>> +   return count;
>> +}
>
>Hmm, that looks like a rather strange way to return a file descriptor.
>
>What is the reason to not use ioctls on the vfio file handle, like older 
>version of
>these patches did?
If I understood correctly that Alex prefer not to change the ioctls on the vfio 
file handle like the old version.
So I used this way the smallest change to general vfio framework only adding a 
subregion definition.

>
>cheers,
>  Gerd

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

Re: [Intel-gfx] [PATCH RESEND v4 5/6] drm: Add definition for eDP backlight frequency

[Manasi Navare]

On Tue, Apr 18, 2017 at 04:48:23PM -0700, Puthikorn Voravootivat wrote:

Since this adds definitions in the DRM layer, you need to copy
the dri-de...@lists.freedesktop.org M-L.

> This patch adds the following definition
> - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap
>   register which only use bit 0:4
> - Base frequency (27 MHz) for backlight PWM frequency
>   generator.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  include/drm/drm_dp_helper.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c0bd0d7651a9..9aee65ebc54c 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -572,10 +572,12 @@
>  #define DP_EDP_PWMGEN_BIT_COUNT 0x724
>  #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725
>  #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726
> +# define  DP_EDP_PWMGEN_BIT_COUNT_MASK  (31 << 0)
>  
>  #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727
>  
>  #define DP_EDP_BACKLIGHT_FREQ_SET   0x728
> +# define DP_EDP_BACKLIGHT_FREQ_BASE 2700

Could you use HEX value to define this? Thats the convention around.

Manasi
>  
>  #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB   0x72a
>  #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID   0x72b
> -- 
> 2.12.2.816.g281164-goog
> 
> ___
> 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 RESEND v4 1/6] drm/i915: Add DPCD preferred mode for backlight control

[Pandiyan, Dhinakaran]

On Wed, 2017-05-03 at 00:54 +, Pandiyan, Dhinakaran wrote:
> Sorry for the wait. This is not a complete review, just some quick
> comments for now.
> 
> 
> On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote:
> > Currently the intel_dp_aux_backlight driver requires eDP panel
> > to not also support backlight adjustment via PWM pin to use
> > this driver.
> > 
> > This force the eDP panel that support both ways of backlight
> > adjustment to do it via PWM pin.
> > 
> > This patch adds the new prefer DPCD mode in the i915_param
> > to make it enable to prefer DPCD over the PWM via kernel param.
> > 
> > This patch also add a check to DP_EDP_BACKLIGHT_AUX_ENABLE_CAP
> > in set_aux_backlight_enable() since the backlight enablement
> > can be done via BL_ENABLE eDP connector pin in the case that
> > it does not support doing that via AUX.
> > 
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c|  6 ++---
> >  drivers/gpu/drm/i915/i915_params.h|  2 +-
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 33 
> > +++
> >  3 files changed, 27 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > b/drivers/gpu/drm/i915/i915_params.c
> > index b6a7e363d076..960393dd5edf 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
> > .huc_firmware_path = NULL,
> > .enable_dp_mst = true,
> > .inject_load_failure = 0,
> > -   .enable_dpcd_backlight = false,
> > +   .enable_dpcd_backlight = 0,
> > .enable_gvt = false,
> >  };
> >  
> > @@ -246,9 +246,9 @@ MODULE_PARM_DESC(enable_dp_mst,
> >  module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, 
> > uint, 0400);
> >  MODULE_PARM_DESC(inject_load_failure,
> > "Force an error after a number of failure check points (0:disabled 
> > (default), N:force failure at the Nth failure check point)");
> > -module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, 
> > bool, 0600);
> > +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
> > 0600);
> >  MODULE_PARM_DESC(enable_dpcd_backlight,
> > -   "Enable support for DPCD backlight control (default:false)");
> > +   "Enable support for DPCD backlight control (0:disable (default), 
> > 1:prefer PWM pin, 2: prefer DPCD)");
> 
> I looked at other int parameters, -1=default, 0=disable(prefer PWM in
> your case), 1=enable(prefer DPCD) seems like the more common way to do
> this.
> 
> 
> >  
> >  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> >  MODULE_PARM_DESC(enable_gvt,
> > diff --git a/drivers/gpu/drm/i915/i915_params.h 
> > b/drivers/gpu/drm/i915/i915_params.h
> > index 34148cc8637c..bf6e2c60f697 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -51,6 +51,7 @@
> > func(int, use_mmio_flip); \
> > func(int, mmio_debug); \
> > func(int, edp_vswing); \
> > +   func(int, enable_dpcd_backlight); \
> > func(unsigned int, inject_load_failure); \
> > /* leave bools at the end to not create holes */ \
> > func(bool, alpha_support); \
> > @@ -66,7 +67,6 @@
> > func(bool, verbose_state_checks); \
> > func(bool, nuclear_pageflip); \
> > func(bool, enable_dp_mst); \
> > -   func(bool, enable_dpcd_backlight); \
> > func(bool, enable_gvt)
> >  
> >  #define MEMBER(T, member) T member
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index 6532e226db29..42f73d9a3ccf 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
> > *intel_dp, bool enable)
> >  {
> > uint8_t reg_val = 0;
> >  
> > +   /* Early return when display use other mechanism to enable backlight. */
> > +   if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> > +   return;
> > +
> > if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
> >   _val) < 0) {
> > DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > @@ -138,27 +142,36 @@ static bool
> >  intel_dp_aux_display_control_capable(struct intel_connector *connector)
> >  {
> > struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
> > +   bool supported;
> >  
> > /* Check the  eDP Display control capabilities registers to determine if
> >  * the panel can support backlight control over the aux channel
> >  */
> > -   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> > -   (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> > -   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> > - (intel_dp->edp_dpcd[2] & 
> > 

Re: [Intel-gfx] [PATCH RESEND v4 2/6] drm/i915: Correctly enable blacklight adjustment via DPCD

[Pandiyan, Dhinakaran]

Adjusting "blacklight" probably won't make a lot of difference even if
done correctly:) Typo in the patch subject.

-DK


On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote:
> intel_dp_aux_enable_backlight() assumed that the register
> BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
> (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.
> 
> This patch fixed that by handling all cases of that register.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 29 
> +--
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 42f73d9a3ccf..f06c8381c74e 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -101,15 +101,32 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
> + uint8_t edp_backlight_mode = 0;
>  
>   set_aux_backlight_enable(intel_dp, true);
>  
> - if ((drm_dp_dpcd_readb(_dp->aux,
> -DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) 
> == 1) &&
> - ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> -  DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
> - drm_dp_dpcd_writeb(_dp->aux, 
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> -(dpcd_buf | 
> DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
> + if (!drm_dp_dpcd_readb(_dp->aux,
> +DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf)) {
> + return;
> + }
> +
> + edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> +
> + switch (edp_backlight_mode) {
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> + dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> + drm_dp_dpcd_writeb(_dp->aux,
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf);
> + break;
> +
> + /* Do nothing when it is already DPCD mode */
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
> + default:
> + break;
> + }
>  }
>  
>  static void intel_dp_aux_disable_backlight(struct intel_connector *connector)

___
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/gvt: return the actual aperture size under gvt environment (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: return the actual aperture size under gvt environment 
(rev3)
URL   : https://patchwork.freedesktop.org/series/22910/
State : success

== Summary ==

Series 22910v3 drm/i915/gvt: return the actual aperture size under gvt 
environment
https://patchwork.freedesktop.org/api/1.0/series/22910/revisions/3/mbox/

Test drv_module_reload:
Subgroup basic-reload-final:
dmesg-warn -> PASS   (fi-skl-6770hq) fdo#100248
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:573s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:555s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:477s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:496s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:458s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:564s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:569s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:433s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:410s

7f027554339633cb4e6a2d3974510aaef1a9e24c drm-tip: 2017y-05m-02d-18h-48m-28s UTC 
integration manifest
fafe274 drm/i915/gvt: return the actual aperture size under gvt environment

== Logs ==

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

[Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

[Weinan Li]

I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
In gvt environment, each vm only use the ballooned part of aperture, so we
should return the actual available aperture size exclude the reserved part
by balloon.

v2: add 'reserved' in struct i915_address_space to record the reserved size
in ggtt by balloon.

v3: remain aper_size as total, adjust aper_available_size exclude reserved
and pinned. UMD driver need to adjust the max allocation size according to
the available aperture size but not total size.

Signed-off-by: Weinan Li 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 +++
 drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++-
 drivers/gpu/drm/i915/i915_vgpu.c| 5 -
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 84ea249..e84576c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -145,9 +145,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_get_aperture *args = data;
struct i915_vma *vma;
-   size_t pinned;
+   size_t pinned = 0;
 
-   pinned = 0;
mutex_lock(>struct_mutex);
list_for_each_entry(vma, >base.active_list, vm_link)
if (i915_vma_is_pinned(vma))
@@ -158,8 +157,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
mutex_unlock(>struct_mutex);
 
args->aper_size = ggtt->base.total;
-   args->aper_available_size = args->aper_size - pinned;
-
+   args->aper_available_size = args->aper_size
+   - ggtt->base.reserved - pinned;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fb15684..bdf832d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -255,7 +255,8 @@ struct i915_address_space {
struct drm_i915_file_private *file;
struct list_head global_link;
u64 total;  /* size addr space maps (ex. 2GB for ggtt) */
-
+   /* size addr space reserved by GVT balloon, only used for ggtt */
+   u64 reserved;
bool closed;
 
struct i915_page_dma scratch_page;
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 4ab8a97..58055a9 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -183,7 +183,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 
unsigned long mappable_base, mappable_size, mappable_end;
unsigned long unmappable_base, unmappable_size, unmappable_end;
-   int ret;
+   int ret, i;
 
if (!intel_vgpu_active(dev_priv))
return 0;
@@ -242,6 +242,9 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
goto err;
}
 
+   for (i = 0; i < ARRAY_SIZE(bl_info.space); i++)
+   ggtt->base.reserved += bl_info.space[i].size;
+
DRM_INFO("VGT balloon successfully\n");
return 0;
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH RESEND v4 2/6] drm/i915: Correctly enable blacklight adjustment via DPCD

[Pandiyan, Dhinakaran]

On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote:
> intel_dp_aux_enable_backlight() assumed that the register
> BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
> (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.
> 
> This patch fixed that by handling all cases of that register.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 29 
> +--
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 42f73d9a3ccf..f06c8381c74e 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -101,15 +101,32 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
> + uint8_t edp_backlight_mode = 0;
>  
>   set_aux_backlight_enable(intel_dp, true);
>  
> - if ((drm_dp_dpcd_readb(_dp->aux,
> -DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) 
> == 1) &&
> - ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> -  DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
> - drm_dp_dpcd_writeb(_dp->aux, 
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> -(dpcd_buf | 
> DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
> + if (!drm_dp_dpcd_readb(_dp->aux,
> +DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf)) {
> + return;
> + }
> +
> + edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> +
> + switch (edp_backlight_mode) {
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> + dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> + drm_dp_dpcd_writeb(_dp->aux,
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf);


You check the return value for _readb() above, but don't check for the
_writeb() here.



> + break;
> +
> + /* Do nothing when it is already DPCD mode */
> + case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
> + default:
> + break;
> + }
>  }
>  
>  static void intel_dp_aux_disable_backlight(struct intel_connector *connector)

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

Re: [Intel-gfx] [PATCH RESEND v4 1/6] drm/i915: Add DPCD preferred mode for backlight control

[Pandiyan, Dhinakaran]

Sorry for the wait. This is not a complete review, just some quick
comments for now.


On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote:
> Currently the intel_dp_aux_backlight driver requires eDP panel
> to not also support backlight adjustment via PWM pin to use
> this driver.
> 
> This force the eDP panel that support both ways of backlight
> adjustment to do it via PWM pin.
> 
> This patch adds the new prefer DPCD mode in the i915_param
> to make it enable to prefer DPCD over the PWM via kernel param.
> 
> This patch also add a check to DP_EDP_BACKLIGHT_AUX_ENABLE_CAP
> in set_aux_backlight_enable() since the backlight enablement
> can be done via BL_ENABLE eDP connector pin in the case that
> it does not support doing that via AUX.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/i915_params.c|  6 ++---
>  drivers/gpu/drm/i915/i915_params.h|  2 +-
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 33 
> +++
>  3 files changed, 27 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index b6a7e363d076..960393dd5edf 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
>   .huc_firmware_path = NULL,
>   .enable_dp_mst = true,
>   .inject_load_failure = 0,
> - .enable_dpcd_backlight = false,
> + .enable_dpcd_backlight = 0,
>   .enable_gvt = false,
>  };
>  
> @@ -246,9 +246,9 @@ MODULE_PARM_DESC(enable_dp_mst,
>  module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, 
> uint, 0400);
>  MODULE_PARM_DESC(inject_load_failure,
>   "Force an error after a number of failure check points (0:disabled 
> (default), N:force failure at the Nth failure check point)");
> -module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
> 0600);
> +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
> 0600);
>  MODULE_PARM_DESC(enable_dpcd_backlight,
> - "Enable support for DPCD backlight control (default:false)");
> + "Enable support for DPCD backlight control (0:disable (default), 
> 1:prefer PWM pin, 2: prefer DPCD)");

I looked at other int parameters, -1=default, 0=disable(prefer PWM in
your case), 1=enable(prefer DPCD) seems like the more common way to do
this.


>  
>  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
>  MODULE_PARM_DESC(enable_gvt,
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 34148cc8637c..bf6e2c60f697 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -51,6 +51,7 @@
>   func(int, use_mmio_flip); \
>   func(int, mmio_debug); \
>   func(int, edp_vswing); \
> + func(int, enable_dpcd_backlight); \
>   func(unsigned int, inject_load_failure); \
>   /* leave bools at the end to not create holes */ \
>   func(bool, alpha_support); \
> @@ -66,7 +67,6 @@
>   func(bool, verbose_state_checks); \
>   func(bool, nuclear_pageflip); \
>   func(bool, enable_dp_mst); \
> - func(bool, enable_dpcd_backlight); \
>   func(bool, enable_gvt)
>  
>  #define MEMBER(T, member) T member
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 6532e226db29..42f73d9a3ccf 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
> *intel_dp, bool enable)
>  {
>   uint8_t reg_val = 0;
>  
> + /* Early return when display use other mechanism to enable backlight. */
> + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> + return;
> +
>   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
> _val) < 0) {
>   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> @@ -138,27 +142,36 @@ static bool
>  intel_dp_aux_display_control_capable(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
> + bool supported;
>  
>   /* Check the  eDP Display control capabilities registers to determine if
>* the panel can support backlight control over the aux channel
>*/
> - if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> - !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> -   (intel_dp->edp_dpcd[2] & 
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
> - DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
> - return true;
> + switch (i915.enable_dpcd_backlight) {
> + case 1: /* prefer PWM pin */
> +   

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Mark up clflushes as belonging to an unordered timeline

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Mark up clflushes as belonging to 
an unordered timeline
URL   : https://patchwork.freedesktop.org/series/23853/
State : success

== Summary ==

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

Test drv_module_reload:
Subgroup basic-reload-final:
dmesg-warn -> PASS   (fi-skl-6770hq) fdo#100248

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:437s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:424s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:586s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:531s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:477s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:571s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:452s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:397s

7f027554339633cb4e6a2d3974510aaef1a9e24c drm-tip: 2017y-05m-02d-18h-48m-28s UTC 
integration manifest
1722c92 drm/i915: Switch the global i915.semaphores check to a local predicate
9dd9a8f drm/i915: Do not record a successful syncpoint for a dma-await
79f2d92 drm/i915: Rename intel_timeline.sync_seqno[] to .global_sync[]
d4374f9 drm/i915: Squash repeated awaits on the same fence
fa789b6 drm/i915: Lift timeline ordering to await_dma_fence
291f320 drm/i915: Unwrap top level fence-array
f2382e3 drm/i915: Mark up clflushes as belonging to an unordered timeline

== Logs ==

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

[Intel-gfx] [PATCH 4/7] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment. (Tvrkto)
v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto)
v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves
v13: kselftests to investigate struct i915_syncmap itself (Tvrtko)
v14: Foray into ascii art graphs
v15: Take into account that the random lookup/insert does 2 prng calls,
not 1, when benchmarking, and use for_each_set_bit() (Tvrtko)
v16: Improved ascii art

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_gem.c|   1 +
 drivers/gpu/drm/i915/i915_gem.h|   2 +
 drivers/gpu/drm/i915/i915_gem_request.c|   9 +
 drivers/gpu/drm/i915/i915_gem_timeline.c   |  95 +++-
 drivers/gpu/drm/i915/i915_gem_timeline.h   |  38 ++
 drivers/gpu/drm/i915/i915_syncmap.c| 412 ++
 drivers/gpu/drm/i915/i915_syncmap.h|  38 ++
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 301 ++
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_random.c   |  11 +
 drivers/gpu/drm/i915/selftests/i915_random.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 617 +
 drivers/gpu/drm/i915/selftests/mock_timeline.c |  45 ++
 drivers/gpu/drm/i915/selftests/mock_timeline.h |  33 ++
 15 files changed, 1589 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..7b05fb802f4c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
  i915_params.o \
  i915_pci.o \
   i915_suspend.o \
+ i915_syncmap.o \
  i915_sw_fence.o \
  i915_sysfs.o \
  intel_csr.o \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e91590dae083..f9c6b9b5002c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3196,6 +3196,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
}
+   i915_gem_timelines_mark_idle(dev_priv);
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5a49487368ca..ee54597465b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -25,6 +25,8 @@
 #ifndef __I915_GEM_H__
 #define __I915_GEM_H__
 
+#include 
+
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(expr) BUG_ON(expr)
 #define GEM_WARN_ON(expr) WARN_ON(expr)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 022f5588d906..637b8cddf988 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -773,6 +773,11 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
continue;
 
+   /* Squash repeated waits to the same timelines */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_is_later(req->timeline, fence))
+   

[Intel-gfx] [PATCH 2/7] drm/i915: Unwrap top level fence-array

[Chris Wilson]

By first unwrapping an incoming fence-array into its child fences, we
can simplify the internal branching, and so avoid triggering a potential
in the next patch when not squashing the child fences on the same timeline.

It will also have the advantage of keeping the (top-level) fence arrays
out of any fence/timeline caching since these are unordered timelines
but with a random context id.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 41 +++--
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 6198f6997d05..b68935d056c5 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -743,22 +743,9 @@ int
 i915_gem_request_await_dma_fence(struct drm_i915_gem_request *req,
 struct dma_fence *fence)
 {
-   struct dma_fence_array *array;
+   struct dma_fence **child = 
+   unsigned int nchild = 1;
int ret;
-   int i;
-
-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
-   return 0;
-
-   if (dma_fence_is_i915(fence))
-   return i915_gem_request_await_request(req, to_request(fence));
-
-   if (!dma_fence_is_array(fence)) {
-   ret = i915_sw_fence_await_dma_fence(>submit,
-   fence, I915_FENCE_TIMEOUT,
-   GFP_KERNEL);
-   return ret < 0 ? ret : 0;
-   }
 
/* Note that if the fence-array was created in signal-on-any mode,
 * we should *not* decompose it into its individual fences. However,
@@ -767,21 +754,29 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
 * amdgpu and we should not see any incoming fence-array from
 * sync-file being in signal-on-any mode.
 */
+   if (dma_fence_is_array(fence)) {
+   struct dma_fence_array *array = to_dma_fence_array(fence);
+
+   child = array->fences;
+   nchild = array->num_fences;
+   GEM_BUG_ON(!nchild);
+   }
 
-   array = to_dma_fence_array(fence);
-   for (i = 0; i < array->num_fences; i++) {
-   struct dma_fence *child = array->fences[i];
+   do {
+   fence = *child++;
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
+   continue;
 
-   if (dma_fence_is_i915(child))
+   if (dma_fence_is_i915(fence))
ret = i915_gem_request_await_request(req,
-to_request(child));
+to_request(fence));
else
-   ret = i915_sw_fence_await_dma_fence(>submit,
-   child, 
I915_FENCE_TIMEOUT,
+   ret = i915_sw_fence_await_dma_fence(>submit, fence,
+   I915_FENCE_TIMEOUT,
GFP_KERNEL);
if (ret < 0)
return ret;
-   }
+   } while (--nchild);
 
return 0;
 }
-- 
2.11.0

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

[Intel-gfx] [PATCH 7/7] drm/i915: Switch the global i915.semaphores check to a local predicate

[Chris Wilson]

Rather than use a global modparam, we can just check to see if the
engine has semaphores configured upon it.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index b30d432415d8..9074303c 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -711,13 +711,15 @@ i915_gem_request_await_request(struct 
drm_i915_gem_request *to,
if (!seqno)
goto await_dma_fence;
 
-   if (!i915.semaphores) {
+   if (!to->engine->semaphore.sync_to) {
if (!__i915_gem_request_started(from, seqno))
goto await_dma_fence;
 
if (!__i915_spin_request(from, seqno, TASK_INTERRUPTIBLE, 2))
goto await_dma_fence;
} else {
+   GEM_BUG_ON(!from->engine->semaphore.signal);
+
if (seqno <= to->timeline->global_sync[from->engine->id])
return 0;
 
-- 
2.11.0

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

[Intel-gfx] [PATCH 5/7] drm/i915: Rename intel_timeline.sync_seqno[] to .global_sync[]

[Chris Wilson]

With the addition of the inter-context intel_time.sync map, having a
very similar sync_seqno[] is confusing. Aide the reader by denoting that
this a pre-allocated array for storing semaphore sync points wrt to the
global seqno.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c  | 8 
 drivers/gpu/drm/i915/i915_gem_timeline.h | 9 -
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 637b8cddf988..b6246b50e375 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -218,8 +218,8 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
tl->seqno = seqno;
 
list_for_each_entry(timeline, >gt.timelines, link)
-   memset(timeline->engine[id].sync_seqno, 0,
-  sizeof(timeline->engine[id].sync_seqno));
+   memset(timeline->engine[id].global_sync, 0,
+  sizeof(timeline->engine[id].global_sync));
}
 
return 0;
@@ -715,7 +715,7 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,
return ret < 0 ? ret : 0;
}
 
-   if (seqno <= to->timeline->sync_seqno[from->engine->id])
+   if (seqno <= to->timeline->global_sync[from->engine->id])
return 0;
 
trace_i915_gem_ring_sync_to(to, from);
@@ -733,7 +733,7 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,
return ret;
}
 
-   to->timeline->sync_seqno[from->engine->id] = seqno;
+   to->timeline->global_sync[from->engine->id] = seqno;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.h 
b/drivers/gpu/drm/i915/i915_gem_timeline.h
index ff65c648407f..bfb5eb94c64d 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.h
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.h
@@ -68,7 +68,14 @@ struct intel_timeline {
 * redundant and we can discard it without loss of generality.
 */
struct i915_syncmap *sync;
-   u32 sync_seqno[I915_NUM_ENGINES];
+   /**
+* Separately to the inter-context seqno map above, we track the last
+* barrier (e.g. semaphore wait) to the global engine timelines. Note
+* that this tracks global_seqno rather than the context.seqno, and
+* so it is subject to the limitations of hw wraparound and that we
+* may need to revoke global_seqno (on pre-emption).
+*/
+   u32 global_sync[I915_NUM_ENGINES];
 
struct i915_gem_timeline *common;
 };
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/7] drm/i915: Mark up clflushes as belonging to an unordered timeline

[Chris Wilson]

2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special global context to mean unordered.
Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to
have the same semantics everywhere.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_clflush.c | 8 +---
 drivers/gpu/drm/i915/i915_gem_clflush.h | 1 -
 4 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4588b3efe730..271a04c59247 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1513,6 +1513,8 @@ struct i915_gem_mm {
/** LRU list of objects with fence regs on them. */
struct list_head fence_list;
 
+   u64 unordered_timeline;
+
/* the indicator for dispatch video commands on two BSD rings */
atomic_t bsd_engine_dispatch_index;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f5f605740886..e91590dae083 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4745,7 +4745,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 
mutex_lock(_priv->drm.struct_mutex);
 
-   i915_gem_clflush_init(dev_priv);
+   dev_priv->mm.unordered_timeline = dma_fence_context_alloc(1);
 
if (!i915.enable_execlists) {
dev_priv->gt.resume = intel_legacy_submission_resume;
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index ffd01e02fe94..ffac7a1f0caf 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -27,7 +27,6 @@
 #include "i915_gem_clflush.h"
 
 static DEFINE_SPINLOCK(clflush_lock);
-static u64 clflush_context;
 
 struct clflush {
struct dma_fence dma; /* Must be first for dma_fence_free() */
@@ -157,7 +156,7 @@ void i915_gem_clflush_object(struct drm_i915_gem_object 
*obj,
dma_fence_init(>dma,
   _clflush_ops,
   _lock,
-  clflush_context,
+  to_i915(obj->base.dev)->mm.unordered_timeline,
   0);
i915_sw_fence_init(>wait, i915_clflush_notify);
 
@@ -182,8 +181,3 @@ void i915_gem_clflush_object(struct drm_i915_gem_object 
*obj,
GEM_BUG_ON(obj->base.write_domain != I915_GEM_DOMAIN_CPU);
}
 }
-
-void i915_gem_clflush_init(struct drm_i915_private *i915)
-{
-   clflush_context = dma_fence_context_alloc(1);
-}
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.h 
b/drivers/gpu/drm/i915/i915_gem_clflush.h
index b62d61a2d15f..2455a7820937 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.h
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.h
@@ -28,7 +28,6 @@
 struct drm_i915_private;
 struct drm_i915_gem_object;
 
-void i915_gem_clflush_init(struct drm_i915_private *i915);
 void i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 unsigned int flags);
 #define I915_CLFLUSH_FORCE BIT(0)
-- 
2.11.0

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

[Intel-gfx] [PATCH 6/7] drm/i915: Do not record a successful syncpoint for a dma-await

[Chris Wilson]

As we may unwind the requests, even though the request we are awaiting
has a global_seqno that seqno may be revoked during the await and so we
can not reliably use it as a barrier for all future awaits on the same
timeline.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 37 +
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index b6246b50e375..b30d432415d8 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -708,33 +708,34 @@ i915_gem_request_await_request(struct 
drm_i915_gem_request *to,
}
 
seqno = i915_gem_request_global_seqno(from);
-   if (!seqno) {
-   ret = i915_sw_fence_await_dma_fence(>submit,
-   >fence, 0,
-   GFP_KERNEL);
-   return ret < 0 ? ret : 0;
-   }
+   if (!seqno)
+   goto await_dma_fence;
 
-   if (seqno <= to->timeline->global_sync[from->engine->id])
-   return 0;
-
-   trace_i915_gem_ring_sync_to(to, from);
if (!i915.semaphores) {
-   if (!i915_spin_request(from, TASK_INTERRUPTIBLE, 2)) {
-   ret = i915_sw_fence_await_dma_fence(>submit,
-   >fence, 0,
-   GFP_KERNEL);
-   if (ret < 0)
-   return ret;
-   }
+   if (!__i915_gem_request_started(from, seqno))
+   goto await_dma_fence;
+
+   if (!__i915_spin_request(from, seqno, TASK_INTERRUPTIBLE, 2))
+   goto await_dma_fence;
} else {
+   if (seqno <= to->timeline->global_sync[from->engine->id])
+   return 0;
+
+   trace_i915_gem_ring_sync_to(to, from);
ret = to->engine->semaphore.sync_to(to, from);
if (ret)
return ret;
+
+   to->timeline->global_sync[from->engine->id] = seqno;
}
 
-   to->timeline->global_sync[from->engine->id] = seqno;
return 0;
+
+await_dma_fence:
+   ret = i915_sw_fence_await_dma_fence(>submit,
+   >fence, 0,
+   GFP_KERNEL);
+   return ret < 0 ? ret : 0;
 }
 
 int
-- 
2.11.0

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

[Intel-gfx] [PATCH 3/7] drm/i915: Lift timeline ordering to await_dma_fence

[Chris Wilson]

Currently we filter out repeated use of the same timeline in the low
level i915_gem_request_await_request(), after having added the
dependency on the old request. However, we can lift this to
i915_gem_request_await_dma_fence() (before the dependency is added)
using the observation that requests along the same timeline are
explicitly ordered via i915_add_request (along with the dependencies).

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index b68935d056c5..022f5588d906 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -687,6 +687,7 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,
int ret;
 
GEM_BUG_ON(to == from);
+   GEM_BUG_ON(to->timeline == from->timeline);
 
if (i915_gem_request_completed(from))
return 0;
@@ -699,9 +700,6 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,
return ret;
}
 
-   if (to->timeline == from->timeline)
-   return 0;
-
if (to->engine == from->engine) {
ret = i915_sw_fence_await_sw_fence_gfp(>submit,
   >submit,
@@ -767,6 +765,14 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
continue;
 
+   /*
+* Requests on the same timeline are explicitly ordered, along
+* with their dependencies, by i915_add_request() which ensures
+* that requests are submitted in-order through each ring.
+*/
+   if (fence->context == req->fence.context)
+   continue;
+
if (dma_fence_is_i915(fence))
ret = i915_gem_request_await_request(req,
 to_request(fence));
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow the UMD to configure their own power clock state

[Patchwork]

== Series Details ==

Series: drm/i915: Allow the UMD to configure their own power clock state
URL   : https://patchwork.freedesktop.org/series/23846/
State : success

== Summary ==

Series 23846v1 drm/i915: Allow the UMD to configure their own power clock state
https://patchwork.freedesktop.org/api/1.0/series/23846/revisions/1/mbox/

Test drv_module_reload:
Subgroup basic-reload-final:
dmesg-warn -> PASS   (fi-skl-6770hq) fdo#100248

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:437s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:562s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:491s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:458s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:450s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:579s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

7f027554339633cb4e6a2d3974510aaef1a9e24c drm-tip: 2017y-05m-02d-18h-48m-28s UTC 
integration manifest
7a90a9b drm/i915: Allow the UMD to configure their own power clock state

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: New vfunc prepare_request

[Oscar Mateo]

On 05/02/2017 08:59 AM, Chris Wilson wrote:

On Mon, May 01, 2017 at 07:28:12AM +, Oscar Mateo wrote:


On 04/29/2017 08:31 AM, Chris Wilson wrote:

On Fri, Apr 28, 2017 at 05:26:09PM +, Oscar Mateo wrote:

This will be more useful later to support platforms that need to emit
HW commands at the beginning of every request (more general than emitting
things at the beginning of every batchbuffer, which is already covered by
emit_bb_start).

We already have one... You are presenting this without a good reason and
failing to transform similar code, which indicates to me that this vfunc
isn't that general.

It looks like I've missed that. What function are you talking about?

For example, you can argue that both legacy ring submission and
execlists share the same sequence of request_alloc:

request->ring = ce->ring (this is now common so can be moved
out, thanks to unifying context pin)


OK


[guc_wq_reserve we have ideas how to eliminate]


Can I simply create a guc_request_alloc for now? This will actually work 
out nicely for me, because I only need to emit extra stuff in the GuC 
case anyway.



some rudimentary reserving of ring space

context initialisation <- time to unify the legacy code


OK (or, at least, I'll try)


The choice for adding a new callback here, is we either take more common
code out of the request_alloc callback such that we reduce it to you new
vfunc -- and so we may end up with 2 common vfuncs called by the core.
Or you refactor the current code so that you can specialise request
alloc and use some execlist helpers for the common portion.
-Chris



Sounds reasonable, thanks!

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

[Intel-gfx] [RFC] drm/i915: Allow the UMD to configure their own power clock state

[Oscar Mateo]

This allows userspace to shutdown slices at will for performance/power reasons
(because it doesn't have a use for more slices).

Cc: Dmitry Rogozhkin 
Cc: Chris Wilson 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 402769d..17ff88d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -628,6 +628,7 @@ static int wa_ring_whitelist_reg(struct intel_engine_cs 
*engine,
 static int gen8_init_workarounds(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
+   int ret;
 
WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
 
@@ -673,6 +674,11 @@ static int gen8_init_workarounds(struct intel_engine_cs 
*engine)
GEN6_WIZ_HASHING_MASK,
GEN6_WIZ_HASHING_16x4);
 
+   /* Allow the UMD to configure their own power clock state */
+   ret = wa_ring_whitelist_reg(engine, GEN8_R_PWR_CLK_STATE);
+   if (ret)
+   return ret;
+
return 0;
 }
 
@@ -841,6 +847,11 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
if (ret)
return ret;
 
+   /* Allow the UMD to configure their own power clock state */
+   ret = wa_ring_whitelist_reg(engine, GEN8_R_PWR_CLK_STATE);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
1.9.1

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

[Intel-gfx] [RFC] tests/pm_sseu: Add subtest to verify UMD can configure render powerclock state

[Oscar Mateo]

Cc: Dmitry Rogozhkin 
Cc: Chris Wilson 
Signed-off-by: Oscar Mateo 
---
 tests/pm_sseu.c | 105 
 1 file changed, 105 insertions(+)

diff --git a/tests/pm_sseu.c b/tests/pm_sseu.c
index 7d4b33c..1fb36c5 100644
--- a/tests/pm_sseu.c
+++ b/tests/pm_sseu.c
@@ -352,6 +352,108 @@ full_enable(void)
check_full_enable();
 }
 
+#define GEN8_R_PWR_CLK_STATE   (0x20C8)
+#define   GEN8_RPCS_ENABLE (1 << 31)
+
+#define MI_STORE_REGISTER_MEM_64_BIT_ADDR  ((0x24 << 23) | 2)
+
+static uint32_t read_pwrclk_state(drm_intel_bufmgr *bufmgr,
+ struct intel_batchbuffer *batch,
+ drm_intel_context *context)
+{
+   uint32_t rpcs_config;
+   uint32_t *data;
+   drm_intel_bo *dst_bo;
+
+   dst_bo = drm_intel_bo_alloc(bufmgr, "dst", 4, 4096);
+
+   BEGIN_BATCH(3, 1);
+   OUT_BATCH(MI_STORE_REGISTER_MEM_64_BIT_ADDR);
+   OUT_BATCH(GEN8_R_PWR_CLK_STATE);
+   OUT_RELOC(dst_bo, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
+   ADVANCE_BATCH();
+
+   intel_batchbuffer_flush_with_context(batch, context);
+
+   drm_intel_bo_map(dst_bo, 1);
+
+   data = dst_bo->virtual;
+   rpcs_config = *data;
+
+   drm_intel_bo_unmap(dst_bo);
+
+   drm_intel_bo_unreference(dst_bo);
+
+   return rpcs_config;
+}
+
+#define LOCAL_MI_LOAD_REGISTER_IMM (0x22 << 23)
+
+#define GFX_OP_PIPE_CONTROL(len)   
((0x3<<29)|(0x3<<27)|(0x2<<24)|((len)-2))
+#define   PIPE_CONTROL_CS_STALL(1<<20)
+#define   PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH   (1<<12)
+#define   PIPE_CONTROL_FLUSH_ENABLE(1<<7)
+#define   PIPE_CONTROL_DC_FLUSH_ENABLE (1<<5)
+#define   PIPE_CONTROL_DEPTH_CACHE_FLUSH   (1<<0)
+
+static void write_pwrclk_state(drm_intel_bufmgr *bufmgr,
+  struct intel_batchbuffer *batch,
+  drm_intel_context *context,
+  uint32_t rpcs_config)
+{
+   drm_intel_bo *dst_bo;
+
+   dst_bo = drm_intel_bo_alloc(bufmgr, "scratch", 4, 4096);
+
+   BEGIN_BATCH(9, 1);
+   OUT_BATCH(LOCAL_MI_LOAD_REGISTER_IMM | 1);
+   OUT_BATCH(GEN8_R_PWR_CLK_STATE);
+   OUT_BATCH(rpcs_config);
+   OUT_BATCH(GFX_OP_PIPE_CONTROL(6));
+   OUT_BATCH(PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_DC_FLUSH_ENABLE |
+ PIPE_CONTROL_FLUSH_ENABLE |
+ PIPE_CONTROL_CS_STALL);
+   OUT_RELOC(dst_bo, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
+   OUT_BATCH(0);
+   OUT_BATCH(0);
+   OUT_BATCH(0);
+   ADVANCE_BATCH();
+
+   intel_batchbuffer_flush_with_context(batch, context);
+
+   drm_intel_bo_unreference(dst_bo);
+}
+
+/* Makes sure userspace can configure GEN8_R_PWR_CLK_STATE (e.g. is 
whitelisted) */
+static void
+pwrclk_state(void)
+{
+   drm_intel_context *context;
+   uint32_t rpcs_config;
+   bool rpcs_enabled;
+
+   /*
+* Gen8 BDW is the first case in which usermode can configure their
+* own render power gating
+   */
+   igt_require(gem.gen >= 8);
+
+   context = drm_intel_gem_context_create(gem.bufmgr);
+
+   rpcs_config = read_pwrclk_state(gem.bufmgr, gem.batch, context);
+   rpcs_enabled = rpcs_config & GEN8_RPCS_ENABLE;
+
+   rpcs_config ^= GEN8_RPCS_ENABLE;
+   write_pwrclk_state(gem.bufmgr, gem.batch, context, rpcs_config);
+
+   rpcs_config = read_pwrclk_state(gem.bufmgr, gem.batch, context);
+   igt_assert_neq(rpcs_enabled, !!(rpcs_config & GEN8_RPCS_ENABLE));
+
+   drm_intel_gem_context_destroy(context);
+}
+
 static void
 exit_handler(int sig)
 {
@@ -370,4 +472,7 @@ igt_main
 
igt_subtest("full-enable")
full_enable();
+
+   igt_subtest("pwrclk-state")
+   pwrclk_state();
 }
-- 
1.9.1

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

[Intel-gfx] [RFC] benchmarks/gem_slice_shutdown: microbenchmark for slice shutdown delays

[Oscar Mateo]

Cc: Dmitry Rogozhkin 
Cc: Chris Wilson 
Signed-off-by: Oscar Mateo 
---
 benchmarks/Makefile.sources |   1 +
 benchmarks/gem_slice_shutdown.c | 295 
 2 files changed, 296 insertions(+)
 create mode 100644 benchmarks/gem_slice_shutdown.c

diff --git a/benchmarks/Makefile.sources b/benchmarks/Makefile.sources
index 3a94115..591b5ae 100644
--- a/benchmarks/Makefile.sources
+++ b/benchmarks/Makefile.sources
@@ -13,6 +13,7 @@ benchmarks_prog_list =\
gem_mmap\
gem_prw \
gem_set_domain  \
+   gem_slice_shutdown  \
gem_syslatency  \
gem_wsim\
kms_vblank  \
diff --git a/benchmarks/gem_slice_shutdown.c b/benchmarks/gem_slice_shutdown.c
new file mode 100644
index 000..dcb17c1
--- /dev/null
+++ b/benchmarks/gem_slice_shutdown.c
@@ -0,0 +1,295 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Oscar Mateo 
+ *
+ */
+
+/*
+ * This tool measures time to change the configuration of number of slices
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm.h"
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_io.h"
+#include "igt_stats.h"
+#include "intel_chipset.h"
+#include "intel_bufmgr.h"
+
+#define GEN8_R_PWR_CLK_STATE   (0x20C8)
+#define   GEN8_RPCS_ENABLE (1 << 31)
+#define   GEN8_RPCS_S_CNT_ENABLE   (1 << 18)
+#define   GEN8_RPCS_S_CNT_SHIFT15
+#define   GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define   GEN8_RPCS_SS_CNT_ENABLE  (1 << 11)
+#define   GEN8_RPCS_SS_CNT_SHIFT   8
+#define   GEN8_RPCS_SS_CNT_MASK(0x7 << GEN8_RPCS_SS_CNT_SHIFT)
+#define   GEN8_RPCS_EU_MAX_SHIFT   4
+#define   GEN8_RPCS_EU_MAX_MASK(0xf << GEN8_RPCS_EU_MAX_SHIFT)
+#define   GEN8_RPCS_EU_MIN_SHIFT   0
+#define   GEN8_RPCS_EU_MIN_MASK(0xf << GEN8_RPCS_EU_MIN_SHIFT)
+
+static const char *yesno(bool x)
+{
+   return x ? "yes" : "no";
+}
+
+static void print_rpcs_config(uint32_t rpcs_config)
+{
+   bool rpcs_enable, s_enable, ss_enable;
+   uint s_count, ss_count, eu_max, eu_min;
+
+   rpcs_enable = rpcs_config & GEN8_RPCS_ENABLE;
+   s_enable= rpcs_config & GEN8_RPCS_S_CNT_ENABLE;
+   ss_enable   = rpcs_config & GEN8_RPCS_SS_CNT_ENABLE;
+   s_count  = (rpcs_config & GEN8_RPCS_S_CNT_MASK)  >> 
GEN8_RPCS_S_CNT_SHIFT;
+   ss_count = (rpcs_config & GEN8_RPCS_SS_CNT_MASK) >> 
GEN8_RPCS_SS_CNT_SHIFT;
+   eu_max   = (rpcs_config & GEN8_RPCS_EU_MAX_MASK) >> 
GEN8_RPCS_EU_MAX_SHIFT;
+   eu_min   = (rpcs_config & GEN8_RPCS_EU_MIN_MASK) >> 
GEN8_RPCS_EU_MIN_SHIFT;
+   printf("RPCS enabled: %s\n", yesno(rpcs_enable));
+   printf("Slice count enabled: %s, count: %u\n", yesno(s_enable), 
s_count);
+   printf("Subslice count enabled: %s, count: %u\n", yesno(ss_enable), 
ss_count);
+   printf("EU max: %u, min: %u\n", eu_max, eu_min);
+}
+
+static void init_buffer(drm_intel_bufmgr *bufmgr,
+   struct igt_buf *buf,
+   uint32_t size)
+{
+   buf->bo = drm_intel_bo_alloc(bufmgr, "", size, 4096);
+   buf->size = size;
+   buf->tiling = I915_TILING_NONE;
+   buf->stride = 4096;
+}
+
+static double elapsed(const struct timespec *start, const struct timespec *end)
+{
+   return 1e6*(end->tv_sec - start->tv_sec) + 1e-3*(end->tv_nsec - 
start->tv_nsec);
+}
+
+#define MI_STORE_REGISTER_MEM_64_BIT_ADDR  ((0x24 << 23) | 2)
+

Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Oscar Mateo]

On 05/02/2017 07:55 PM, Chris Wilson wrote:

On Tue, May 02, 2017 at 10:33:19AM +, Oscar Mateo wrote:


On 05/02/2017 11:49 AM, Chris Wilson wrote:

We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI).

Userspace could also do this by themselves via LRI if we simply
whitelist GEN8_R_PWR_CLK_STATE.

Hardware people suggested this programming model:

- PIPECONTROL - Stalling flish, flush all caches (color, depth, DC$)
- LOAD_REGISTER_IMMEDIATE - R_PWR_CLK_STATE
- Reprogram complete state

Hmm, treating it as a complete state wipe is a nuisance, but fairly
trivial. The simplest way will be for the user to execute the LRI batch
as part of creating the context. But there will be some use cases where
dynamic reconfiguration within an active context will be desired, I'm
sure.


Exactly, in this way the UMD gets the best of both worlds: they can do 
the LRI once and forget about it, or they can reconfigure on-demand.



If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.

There is another cost associated with the adjustment: slice poweron
and shutdown do take some time to happen (in the order of tens of
usecs). I have been playing with an i-g-t benchmark to measure this
delay, I'll send it to the mailing list.

Hmm, I thought the argument for why selecting smaller subslices gave
better performance was that it was restoring the whole set between
contexts, even when the configuration between contexts was the same.


Hmmm... it's the first time I hear that particular argument. I can 
definitely see the delay when changing the configuration (also, powering 
slices on takes a little bit more than switching them down) but no 
difference when I am just switching between contexts with the same 
configuration.
Until now, the most convincing argument I've heard is that thread 
scheduling is much more efficient with just one slice when you don't 
really need more, but maybe that doesn't explain the whole picture.



As always numbers demonstrating the advantage, perhaps explaining why
it helps, and also for spotting when we break it are most welcome :)
-Chris


I can provide numbers for the slice configuration delay (numbers that 
have to be taken into account by the UMD when deciding which 
configuration to use) but I think Dimitry is in a better position to 
provide numbers for the advantage.


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

[Intel-gfx] [PATCH v10 12/15] drm/i915/perf: Add OA unit support for Gen 8+

[Lionel Landwerlin]

From: Robert Bragg 

Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.

Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.

The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).

This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.

The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).

Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.

v5: Drain submitted requests when enabling metric set to ensure no
lite-restore erases the context image we just updated (Lionel)

v6: In addition to drain, switch to kernel context & update all
context in place (Chris)

v7: Add missing mutex_unlock() if switching to kernel context fails
(Matthew)

v8: Simplify OA period/flex-eu-counters programming by using the
batchbuffer instead of modifying ctx-image (Lionel)

v9: Back to updating the context image (due to erroneous testing,
batchbuffer programming the OA unit doesn't actually work)
(Lionel)
Pin context before updating context image (Chris)
Drop MMIO programming now that we switch to a kernel context with
right values in initial context image (Chris)

v10: Just pin_map the contexts we want to modify or let the
 configuration happen on first use (Chris)

Signed-off-by: Robert Bragg 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld  \o/
---
 drivers/gpu/drm/i915/i915_drv.h  |  45 +-
 drivers/gpu/drm/i915/i915_perf.c | 889 +++
 drivers/gpu/drm/i915/i915_reg.h  |  22 +
 drivers/gpu/drm/i915/intel_lrc.c |   2 +
 include/uapi/drm/i915_drm.h  |  19 +-
 5 files changed, 884 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f15751534c29..eaf4ce5e5790 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2063,9 +2063,17 @@ struct i915_oa_ops {
void (*init_oa_buffer)(struct drm_i915_private *dev_priv);

/**
-* @enable_metric_set: Applies any MUX configuration to set up the
-* Boolean and Custom (B/C) counters that are part of the counter
-* reports being sampled. May apply system constraints such as
+* @select_metric_set: The auto generated code that checks whether a
+* requested OA config is applicable to the system and if so sets up
+* the mux, oa and flex eu register config pointers according to the
+* current dev_priv->perf.oa.metrics_set.
+*/
+   int (*select_metric_set)(struct drm_i915_private *dev_priv);
+
+   /**
+* @enable_metric_set: Selects and applies any MUX configuration to set
+* up the Boolean and Custom (B/C) counters 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Move notification code into virtual function

[Michal Wajdeczko]

On Tue, May 02, 2017 at 09:37:45AM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 02/05/17 05:39, Michal Wajdeczko wrote:
> > Prepare for alternate GuC notification mechanism.
> > 
> > Signed-off-by: Michal Wajdeczko 
> > Cc: Joonas Lahtinen 
> > Cc: Daniele Ceraolo Spurio 
> > ---
> >  drivers/gpu/drm/i915/intel_uc.c | 10 +-
> >  drivers/gpu/drm/i915/intel_uc.h |  7 +++
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_uc.c 
> > b/drivers/gpu/drm/i915/intel_uc.c
> > index 7fd75ca..72f49e6 100644
> > --- a/drivers/gpu/drm/i915/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/intel_uc.c
> > @@ -94,12 +94,20 @@ void intel_uc_sanitize_options(struct drm_i915_private 
> > *dev_priv)
> > i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
> >  }
> > 
> > +static void guc_write_irq_trigger(struct intel_guc *guc)
> > +{
> > +   struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > +
> > +   I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
> > +}
> > +
> >  void intel_uc_init_early(struct drm_i915_private *dev_priv)
> >  {
> > struct intel_guc *guc = _priv->guc;
> > 
> > mutex_init(>send_mutex);
> > guc->send = intel_guc_send_nop;
> > +   guc->notify = guc_write_irq_trigger;
> >  }
> > 
> >  static void fetch_uc_fw(struct drm_i915_private *dev_priv,
> > @@ -413,7 +421,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const 
> > u32 *action, u32 len)
> > 
> > POSTING_READ(SOFT_SCRATCH(i - 1));
> > 
> > -   I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
> > +   intel_guc_notify(guc);
> > 
> > /*
> >  * No GuC command should ever take longer than 10ms.
> > diff --git a/drivers/gpu/drm/i915/intel_uc.h 
> > b/drivers/gpu/drm/i915/intel_uc.h
> > index 1e0eecd..097289b 100644
> > --- a/drivers/gpu/drm/i915/intel_uc.h
> > +++ b/drivers/gpu/drm/i915/intel_uc.h
> > @@ -210,6 +210,9 @@ struct intel_guc {
> > 
> > /* GuC's FW specific send function */
> > int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
> > +
> > +   /* GuC's FW specific notify function */
> > +   void (*notify)(struct intel_guc *guc);
> >  };
> > 
> >  struct intel_huc {
> > @@ -233,6 +236,10 @@ static inline int intel_guc_send(struct intel_guc 
> > *guc, const u32 *action, u32 l
> >  {
> > return guc->send(guc, action, len);
> >  }
> > +static inline void intel_guc_notify(struct intel_guc *guc)
> > +{
> > +   guc->notify(guc);
> > +}
> > 
> 
> personal preference: I would use guc->notify directly instead of adding
> intel_guc_notify(). intel_guc_send() made more sense because a function with
> that name already existed and by keeping it we minimized the change, but I
> don't see such benefit with intel_guc_notify() and calling the function
> pointer directly feels more in sync with what we do elsewhere in the driver.
> 

Note that thanks to the compiler, resulting code is the same, but by keeping
intel_guc_notify() we are more flexible than when using hardcoded guc->notify.
Note that the same reason why we added intel_guc_send() "minimize the change"
can also be valid when in the future we may want to switch from vfun pointer
to other implementation that then can be hidden in that tiny inline that you
just wanted to kill.

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

[Intel-gfx] Overscan problem : Intel HD Graphics 610 + Wayland + Fedora 25

[G. Morgan]

Hello,

I would like to thank you for the good driver you provide.

There is only one thing missing for my complete joy...I would like to know
how to adjust overcan parameter (dunno if it's the right word : the output
display is a little bit larger than the physical screen by maybe an inch
(bottom) )

I can't adjust it on my cheap LED  TV (RCA). There's nothing like it in the
settings menu.

I know it can be done at the software level...Just dunno now that I'm using
Wayland and intel drivers if it's Wayland's job / intel-gfx job or gnome3's
job?

** I used to overcome this in X.org + nvdia on my other box by using the
ViewPortOut parameter of nvidia-settings, I've heard some people were using
xrandr back then...

But now, we're talking Intel + Fedora25 + Wayland.

I've heard of panel fitting for the Intel graphic driver but I guess it's
available on Windows only.

Other question : Is there some kind of a control panel for Intel Graphics
610 (Kabylake) in Linux/Wayland ?

Could the problem I encounter be related to this cheap TV not being P'n'P
(EDID not being read properly)

I just wanna make the display fits the screen correctly.


Thanks for any help

G.

* latest kernel installed *updated intel drivers using the 01.org update
tool
---

System:Host: labibitte-localdomain Kernel: 4.10.13-200.fc25.x86_64
x86_64 (64 bit)
   Desktop: Gnome 3.22.3 Distro: Fedora release 25 (Twenty Five)
Machine:   Device: server System: Supermicro product: C7H170-M v: 0123456789
   Mobo: Supermicro model: C7H170-M v: 1.01
   UEFI [Legacy]: American Megatrends v: 2.0 date: 12/19/2016
CPU:   Dual core Intel Pentium G4560 (-HT-MCP-) cache: 3072 KB
   clock speeds: max: 3500 MHz 1: 818 MHz 2: 1335 MHz 3: 799 MHz
   4: 871 MHz
Graphics:  Card: Intel HD Graphics 610
   Display Server: Fedora X.org 119.3 driver: N/A
   Resolution: 1920x1080@59.96hz
   GLX Renderer: Mesa DRI Intel Kabylake GT1
   GLX Version: 3.0 Mesa 13.0.4
Audio: Card-1 Intel Sunrise Point-H HD Audio driver: snd_hda_intel
   Card-2 Texas Instruments PCM2902 Audio Codec driver: USB Audio
   Sound: ALSA v: k4.10.13-200.fc25.x86_64
Network:   Card: Intel Ethernet Connection (2) I219-V driver: e1000e
   IF: eno1 state: up speed: 1000 Mbps duplex: full
   mac: 0c:c4:7a:e1:d6:39
Drives:HDD Total Size: 3000.6GB (0.5% used)
   ID-1: /dev/sda model: ST3000DM008 size: 3000.6GB
   ID-2: /dev/nvme0n1 model: N/A size: 128.0GB
Partition: ID-1: / size: 50G used: 5.2G (12%) fs: ext4 dev: /dev/dm-0
   ID-2: /boot size: 976M used: 173M (20%) fs: ext4 dev:
/dev/nvme0n1p1
   ID-3: /home size: 60G used: 660M (2%) fs: ext4 dev: /dev/dm-2
   ID-4: swap-1 size: 8.44GB used: 0.00GB (0%) fs: swap dev:
/dev/dm-1
RAID:  No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 29.8C mobo: 27.0C
   Fan Speeds (in rpm): cpu: N/A
Info:  Processes: 223 Uptime: 27 min Memory: 1630.0/15972.2MB
   Client: Shell (bash) inxi: 2.3.8
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Rafael J. Wysocki]

On Tuesday, May 02, 2017 03:04:08 PM Imre Deak wrote:
> Some drivers - like i915 - may not support the system suspend direct
> complete optimization due to differences in their runtime and system
> suspend sequence. Add a flag that when set resumes the device before
> calling the driver's system suspend handlers which effectively disables
> the optimization.
> 
> Needed by the next patch fixing suspend/resume on i915.
> 
> Suggested by Rafael.
> 
> v2-v3:
> - unchanged
> 
> v4:
> - Move the flag to dev_flags instead of using a bit field. (Rafael)

Acked-by: Rafael J. Wysocki 

And yes, the PCI device PM flags need to be cleaned up.  I'll take care of this
later unless somebody else steps up.

> 
> Cc: Rafael J. Wysocki 
> Cc: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Signed-off-by: Imre Deak 
> Acked-by: Rafael J. Wysocki  (v3)
> ---
>  drivers/pci/pci.c   | 3 ++-
>  include/linux/pci.h | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..a4ef755 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2141,7 +2141,8 @@ bool pci_dev_keep_suspended(struct pci_dev *pci_dev)
>  
>   if (!pm_runtime_suspended(dev)
>   || pci_target_state(pci_dev) != pci_dev->current_state
> - || platform_pci_need_resume(pci_dev))
> + || platform_pci_need_resume(pci_dev)
> + || (pci_dev->dev_flags & PCI_DEV_FLAGS_NEEDS_RESUME))
>   return false;
>  
>   /*
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 5948cfd..8acb560 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -178,6 +178,11 @@ enum pci_dev_flags {
>   PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
>   /* Get VPD from function 0 VPD */
>   PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
> + /*
> +  * Resume before calling the driver's system suspend hooks, disabling
> +  * the direct_complete optimization.
> +  */
> + PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 9),
>  };
>  
>  enum pci_irq_reroute_variant {
> 

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

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Rafael J. Wysocki]

On Tuesday, May 02, 2017 12:05:38 PM Imre Deak wrote:
> On Mon, May 01, 2017 at 10:36:13PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, April 30, 2017 03:57:13 PM Imre Deak wrote:
> > > On Sat, Apr 29, 2017 at 12:21:57PM +0200, Rafael J. Wysocki wrote:
> > > > On Friday, April 28, 2017 11:33:02 PM Rafael J. Wysocki wrote:
> > > > > On Friday, April 28, 2017 05:16:02 PM Imre Deak wrote:
> > > > > > Some drivers - like i915 - may not support the system suspend direct
> > > > > > complete optimization due to differences in their runtime and system
> > > > > > suspend sequence. Add a flag that when set resumes the device before
> > > > > > calling the driver's system suspend handlers which effectively 
> > > > > > disables
> > > > > > the optimization.
> > > > > > 
> > > > > > Needed by the next patch fixing suspend/resume on i915.
> > > > > > 
> > > > > > Suggested by Rafael.
> > > > > > 
> > > > > > Cc: Rafael J. Wysocki 
> > > > > > Cc: Bjorn Helgaas 
> > > > > > Cc: linux-...@vger.kernel.org
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > Signed-off-by: Imre Deak 
> > > > > 
> > > > > Acked-by: Rafael J. Wysocki 
> > > > > 
> > > > > The reason why the opt-out flag was not added on day one was because 
> > > > > we were
> > > > > not sure whether or not it would be necessary at all.
> > > > > 
> > > > > Quite evidently, it is needed.
> > > > 
> > > > But that said, it actually can be implemented as a flag in dev_flags 
> > > > too, say
> > > > PCI_DEV_FLAGS_NEEDS_RESUME, in analogy with PCI_DEV_FLAGS_NO_D3 that's
> > > > already there.
> > > > 
> > > > The struct size would not need to grow then which I guess would be 
> > > > better?
> > > 
> > > Hm, both the bit field and the flag would need to increase if running
> > > out of bits, so what's the difference? (Atm, the struct size wouldn't
> > > change either way.)
> > 
> > In the bit field case this depends on what the compiler thinks is better to 
> > be
> > entirely precise, so they are not 100% equivalent.
> > 
> > Plus, since there already are things related to PM in dev_flags, why to 
> > depart
> > from that pattern?
> 
> There are a few PM related flags in the bit field too.
> 
> The need for moving it is still not clear to me, but I don't see any
> problem with it either, so will move it there.

Well, we are not too consistent in that respect overall.

Either way works, so I guess it's Bjorn's call at this point. :-)

Thanks,
Rafael

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

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

[Takashi Iwai]

On Tue, 02 May 2017 22:15:20 +0200,
Pierre-Louis Bossart wrote:
> 
> On 5/2/17 1:27 PM, Ville Syrjälä wrote:
> > On Mon, May 01, 2017 at 08:29:10PM -0500, Pierre-Louis Bossart wrote:
> >>
> >>
> >> On 04/28/2017 02:37 PM, Ville Syrjälä wrote:
> >>> On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote:
> 
>  On 04/28/2017 03:41 AM, Takashi Iwai wrote:
> > On Thu, 27 Apr 2017 18:02:19 +0200,
> > ville.syrj...@linux.intel.com wrote:
> >> From: Ville Syrjälä 
> >>
> >> Okay, here's the second attempt at getting multiple pipes playing back
> >> audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
> >> that now the PCM devices are associated with ports instead of pipes,
> >> so the audio from one device always gets output on the same display.
> >>
> >> I've also tacked on the alsa-lib conf update. No clue whether it's
> >> really correct or not (the config language isn't a close friend
> >> of mine).
> >>
> >> BTW I did notice that with LPE audio all the controls say iface=PCM,
> >> whereas on HDA a bunch of them say iface=MIXER. No idea if that's
> >> OK or not, just something I spotted when I was comparing the results
> >> with HDA.
> > We generally accept both iface types for IEC958 stuff, since
> > historically many drivers have already mixed them up.  So it's no
> > problem :)
> >
> >
> >> Entire series available here:
> >> git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2
> >>
> >> Cc: Takashi Iwai 
> >> Cc: Pierre-Louis Bossart 
> > All look good, and feel free to take my reviewed-by tag
> > Reviewed-by: Takashi Iwai 
> >
> > As said previously, my only slight concern is the compatibility.
> > But, in the current situation with PulseAudio, only few people would
> > use this driver, so it shouldn't be so big impact, I suppose.
> >
> > BTW, which port is used in general on BYT/CHT?
> >
> > Oh, also, I suppose you want to carry these over i915 tree?
> > I don't mind either way, I can take them through sound tree if
> > preferred, too.
>  I see frequent oops on startup with this lpe_audio_multipipe_2 branch
>  with my CHT device not booting or no HDMI audio device created.
>  Not sure if these issues are due to the new patches or to the rest of
>  the drm code?
> 
>  [5.529023] BUG: unable to handle kernel NULL pointer dereference
>  at   (null)
>  [5.529143] IP: hdmi_lpe_audio_probe+0x40f/0x650 [snd_hdmi_lpe_audio]
>  [5.529202] PGD 0
> 
>  [5.529242] Oops:  [#1] SMP
>  [5.529274] Modules linked in: snd_soc_sst_atom_hifi2_platform
>  snd_soc_sst_match snd_soc_core snd_compress lpc_ich snd_seq
>  snd_seq_device shpchp snd_hdmi_lpe_audio(+) snd_pcm snd_timer dw_dmac
>  snd soundcore i2c_designware_platform(+) i2c_designware_core
>  spi_pxa2xx_platform acpi_pad mac_hid nfsd auth_rpcgss nfs_acl lockd
>  grace sunrpc ip_tables x_tables hid_generic mmc_block i2c_hid usbhid hid
>  autofs4
>  [5.529605] CPU: 2 PID: 512 Comm: systemd-udevd Not tainted
>  4.11.0-rc8-test+ #11
>  [5.529671] Hardware name: ZOTAC XX/Cherry Trail FFD, BIOS 5.11
>  09/28/2016
>  [5.529736] task: 88007485b780 task.stack: c9bfc000
>  [5.529793] RIP: 0010:hdmi_lpe_audio_probe+0x40f/0x650
>  [snd_hdmi_lpe_audio]
>  [5.529855] RSP: 0018:c9bffaf0 EFLAGS: 00010246
>  [5.529904] RAX:  RBX: 880079209898 RCX:
>  88007920f078
>  [5.529967] RDX: 0014 RSI: c9bffb28 RDI:
>  0002
>  [5.530031] RBP: c9bffb70 R08: 0001 R09:
>  
>  [5.530094] R10: 88007441bf00 R11: c9bffb36 R12:
>  88007920ef20
>  [5.530159] R13: 88007920ef48 R14: 5688 R15:
>  0047
>  [5.530225] FS:  7f627c988640() GS:88007b30()
>  knlGS:
>  [5.530299] CS:  0010 DS:  ES:  CR0: 80050033
>  [5.530352] CR2:  CR3: 78cb8000 CR4:
>  001006e0
>  [5.530416] Call Trace:
>  [5.530452]  platform_drv_probe+0x3b/0xa0
>  [5.530494]  driver_probe_device+0x2bb/0x460
>  [5.530538]  __driver_attach+0xdf/0xf0
>  [5.530576]  ? driver_probe_device+0x460/0x460
>  [5.530620]  bus_for_each_dev+0x60/0xa0
>  [5.530658]  driver_attach+0x1e/0x20
>  [5.530693]  bus_add_driver+0x170/0x270
>  [5.530731]  driver_register+0x60/0xe0
>  [5.530769]  ? 0xa01cb000
>  [5.530803]  __platform_driver_register+0x36/0x40
>  [5.530851]  

Re: [Intel-gfx] [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

[Chris Wilson]

On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> The existing drm_gem_prime_import function uses the underlying
> struct device of a drm_device for attaching to a dma_buf. Some drivers
> (notably vgem) may not have an underlying device structure. Offer
> an alternate function to attach using a platform device associated
> with drm_device.
> 
> Cc: intel-gfx@lists.freedesktop.org
> Reviewed-by: Chris Wilson 
> Signed-off-by: Laura Abbott 
> ---
> v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
> added for new function. Brought back drm_device->platformdev as it had been
> removed in 76adb460fd93 ("drm: Remove the struct drm_device platformdev 
> field").
> I'm not entirely thrilled about this since the platformdev removal was good
> cleanup and this feels like a small step backwards. I don't know of a better
> approach though.
> ---
>  drivers/gpu/drm/drm_prime.c | 49 
> +++--
>  include/drm/drmP.h  |  2 ++
>  include/drm/drm_prime.h |  4 
>  3 files changed, 44 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 9fb65b7..a557a4b 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -594,16 +594,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
>  
> -/**
> - * drm_gem_prime_import - helper library implementation of the import 
> callback
> - * @dev: drm_device to import into
> - * @dma_buf: dma-buf object to import
> - *
> - * This is the implementation of the gem_prime_import functions for GEM 
> drivers
> - * using the PRIME helpers.
> - */
> -struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> - struct dma_buf *dma_buf)
> +static struct drm_gem_object *__drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf,
> + struct device *attach_dev)
>  {
>   struct dma_buf_attachment *attach;
>   struct sg_table *sgt;
> @@ -625,7 +618,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
> drm_device *dev,
>   if (!dev->driver->gem_prime_import_sg_table)
>   return ERR_PTR(-EINVAL);
>  
> - attach = dma_buf_attach(dma_buf, dev->dev);
> + attach = dma_buf_attach(dma_buf, attach_dev);
>   if (IS_ERR(attach))
>   return ERR_CAST(attach);
>  
> @@ -655,9 +648,43 @@ struct drm_gem_object *drm_gem_prime_import(struct 
> drm_device *dev,
>  
>   return ERR_PTR(ret);
>  }
> +
> +/**
> + * drm_gem_prime_import - helper library implementation of the import 
> callback
> + * @dev: drm_device to import into
> + * @dma_buf: dma-buf object to import
> + *
> + * This is the implementation of the gem_prime_import functions for GEM 
> drivers
> + * using the PRIME helpers.
> + */
> +struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf)
> +{
> + return __drm_gem_prime_import(dev, dma_buf, dev->dev);
> +}
>  EXPORT_SYMBOL(drm_gem_prime_import);
>  
>  /**
> + * drm_gem_prime_import_platform - alternate implementation of the import 
> callback
> + * @dev: drm_device to import into
> + * @dma_buf: dma-buf object to import
> + *
> + * This is identical to drm_gem_prime_import except the device used for 
> dma_buf
> + * attachment is an internal platform device instead of the standard device
> + * structure. The use of this function should be limited to drivers that do 
> not
> + * set up an underlying device structure.
> + */
> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,

Simpler soluation will be for the caller to provide the platformdev?

That works nicely for the vgem case, I think.

> + struct dma_buf *dma_buf)
> +{
> + if (WARN_ON_ONCE(!dev->platformdev))
> + return NULL;
> +
> + return __drm_gem_prime_import(dev, dma_buf, >platformdev->dev);
> +}
> +EXPORT_SYMBOL(drm_gem_prime_import_platform);

-- 
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] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

[Pierre-Louis Bossart]

On 5/2/17 1:27 PM, Ville Syrjälä wrote:

On Mon, May 01, 2017 at 08:29:10PM -0500, Pierre-Louis Bossart wrote:



On 04/28/2017 02:37 PM, Ville Syrjälä wrote:

On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote:


On 04/28/2017 03:41 AM, Takashi Iwai wrote:

On Thu, 27 Apr 2017 18:02:19 +0200,
ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Okay, here's the second attempt at getting multiple pipes playing back
audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
that now the PCM devices are associated with ports instead of pipes,
so the audio from one device always gets output on the same display.

I've also tacked on the alsa-lib conf update. No clue whether it's
really correct or not (the config language isn't a close friend
of mine).

BTW I did notice that with LPE audio all the controls say iface=PCM,
whereas on HDA a bunch of them say iface=MIXER. No idea if that's
OK or not, just something I spotted when I was comparing the results
with HDA.

We generally accept both iface types for IEC958 stuff, since
historically many drivers have already mixed them up.  So it's no
problem :)



Entire series available here:
git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2

Cc: Takashi Iwai 
Cc: Pierre-Louis Bossart 

All look good, and feel free to take my reviewed-by tag
Reviewed-by: Takashi Iwai 

As said previously, my only slight concern is the compatibility.
But, in the current situation with PulseAudio, only few people would
use this driver, so it shouldn't be so big impact, I suppose.

BTW, which port is used in general on BYT/CHT?

Oh, also, I suppose you want to carry these over i915 tree?
I don't mind either way, I can take them through sound tree if
preferred, too.

I see frequent oops on startup with this lpe_audio_multipipe_2 branch
with my CHT device not booting or no HDMI audio device created.
Not sure if these issues are due to the new patches or to the rest of
the drm code?

[5.529023] BUG: unable to handle kernel NULL pointer dereference
at   (null)
[5.529143] IP: hdmi_lpe_audio_probe+0x40f/0x650 [snd_hdmi_lpe_audio]
[5.529202] PGD 0

[5.529242] Oops:  [#1] SMP
[5.529274] Modules linked in: snd_soc_sst_atom_hifi2_platform
snd_soc_sst_match snd_soc_core snd_compress lpc_ich snd_seq
snd_seq_device shpchp snd_hdmi_lpe_audio(+) snd_pcm snd_timer dw_dmac
snd soundcore i2c_designware_platform(+) i2c_designware_core
spi_pxa2xx_platform acpi_pad mac_hid nfsd auth_rpcgss nfs_acl lockd
grace sunrpc ip_tables x_tables hid_generic mmc_block i2c_hid usbhid hid
autofs4
[5.529605] CPU: 2 PID: 512 Comm: systemd-udevd Not tainted
4.11.0-rc8-test+ #11
[5.529671] Hardware name: ZOTAC XX/Cherry Trail FFD, BIOS 5.11
09/28/2016
[5.529736] task: 88007485b780 task.stack: c9bfc000
[5.529793] RIP: 0010:hdmi_lpe_audio_probe+0x40f/0x650
[snd_hdmi_lpe_audio]
[5.529855] RSP: 0018:c9bffaf0 EFLAGS: 00010246
[5.529904] RAX:  RBX: 880079209898 RCX:
88007920f078
[5.529967] RDX: 0014 RSI: c9bffb28 RDI:
0002
[5.530031] RBP: c9bffb70 R08: 0001 R09:

[5.530094] R10: 88007441bf00 R11: c9bffb36 R12:
88007920ef20
[5.530159] R13: 88007920ef48 R14: 5688 R15:
0047
[5.530225] FS:  7f627c988640() GS:88007b30()
knlGS:
[5.530299] CS:  0010 DS:  ES:  CR0: 80050033
[5.530352] CR2:  CR3: 78cb8000 CR4:
001006e0
[5.530416] Call Trace:
[5.530452]  platform_drv_probe+0x3b/0xa0
[5.530494]  driver_probe_device+0x2bb/0x460
[5.530538]  __driver_attach+0xdf/0xf0
[5.530576]  ? driver_probe_device+0x460/0x460
[5.530620]  bus_for_each_dev+0x60/0xa0
[5.530658]  driver_attach+0x1e/0x20
[5.530693]  bus_add_driver+0x170/0x270
[5.530731]  driver_register+0x60/0xe0
[5.530769]  ? 0xa01cb000
[5.530803]  __platform_driver_register+0x36/0x40
[5.530851]  hdmi_lpe_audio_driver_init+0x17/0x1000 [snd_hdmi_lpe_audio]
[5.530915]  do_one_initcall+0x43/0x180
[5.530956]  ? __vunmap+0x81/0xd0
[5.530991]  ? kfree+0x14c/0x160
[5.531024]  ? kmem_cache_alloc_trace+0x38/0x150
[5.531070]  do_init_module+0x5f/0x1f8
[5.531108]  load_module+0x271e/0x2bd0
[5.531147]  ? kernel_read_file+0x1a3/0x1c0
[5.531188]  SYSC_finit_module+0xbc/0xf0
[5.531226]  ? SYSC_finit_module+0xbc/0xf0
[5.531267]  SyS_finit_module+0xe/0x10
[5.531305]  do_syscall_64+0x6e/0x180
[5.531345]  entry_SYSCALL64_slow_path+0x25/0x25
[5.531389] RIP: 0033:0x7f627b5fbbf9
[5.531424] RSP: 002b:7ffe053eee68 EFLAGS: 0246 ORIG_RAX:
0139
[5.531493] RAX: ffda RBX: 55d6c745b690 RCX:
7f627b5fbbf9
[

Re: [Intel-gfx] [PATCH v9 12/15] drm/i915/perf: Add OA unit support for Gen 8+

[Chris Wilson]

On Mon, May 01, 2017 at 06:17:09PM -0700, Lionel Landwerlin wrote:

Focusing on the bit I know best and leaving the hw mumbo jumbo to one
side...

> +static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv)
> +{
> + struct intel_engine_cs *engine = dev_priv->engine[RCS];
> + struct i915_gem_context *ctx;
> + int ret;
> +
> + ret = i915_mutex_lock_interruptible(_priv->drm);
> + if (ret)
> + return ret;
> +
> + /* Switch away from any user context.  */
> + ret = i915_gem_switch_to_kernel_context(dev_priv);
> + if (ret) {
> + mutex_unlock(_priv->drm.struct_mutex);
> + return ret;
> + }
> +
> + /* The OA register config is setup through the context image. This image
> +  * might be written to by the GPU on context switch (in particular on
> +  * lite-restore). This means we can't safely update a context's image,
> +  * if this context is scheduled/submitted to run on the GPU.
> +  *
> +  * We could emit the OA register config through the batch buffer but
> +  * this might leave small interval of time where the OA unit is
> +  * configured at an invalid sampling period.
> +  *
> +  * So far the best way to work around this issue seems to be draining
> +  * the GPU from any submitted work.
> +  */
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE |
> +  I915_WAIT_LOCKED);
> + if (ret) {
> + mutex_unlock(_priv->drm.struct_mutex);
> + return ret;
> + }
> +
> + /* Update all contexts now that we've stalled the submission. */
> + list_for_each_entry(ctx, _priv->context_list, link) {
> + ret = engine->context_pin(engine, ctx);
> + if (ret) {
> + mutex_unlock(_priv->drm.struct_mutex);
> + return ret;
> + }
> +
> + gen8_update_reg_state_unlocked(ctx,
> +ctx->engine[RCS].lrc_reg_state);

engine->context_unpin is missing.

Since you do populate the OA settings for contexts initialised later,
you can skip the context_pin here (keeping the deferred initialisation
for currently unused contexts) and use

list_for_each_entry(ctx, _priv->context_list, link) {
struct intel_context *ce = >engine[RCS];
u32 *regs;

if (!ce->state) /* OA settings will be set upon first use */
continue;

/* Hmm, export this from intel_lrc.c? */
regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
if (IS_ERR(regs)) {
/* teardown? */
mutex_unlock(>i915->drm.struct_mutex);
return PTR_ERR(regs);
}
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
/* Probably best since we don't really want to expose
 * the LRC_STATE_PN trick.
 */

gen8_update_reg_state_unlocked(ctx, regs);

i915_gem_object_unpin_map(ce->state->obj);
}

-- 
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] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Chris Wilson]

On Tue, May 02, 2017 at 10:33:19AM +, Oscar Mateo wrote:
> 
> 
> On 05/02/2017 11:49 AM, Chris Wilson wrote:
> >We want to allow userspace to reconfigure the subslice configuration for
> >its own use case. To do so, we expose a context parameter to allow
> >adjustment of the RPCS register stored within the context image (and
> >currently not accessible via LRI).
> 
> Userspace could also do this by themselves via LRI if we simply
> whitelist GEN8_R_PWR_CLK_STATE.
> 
> Hardware people suggested this programming model:
> 
> - PIPECONTROL - Stalling flish, flush all caches (color, depth, DC$)
> - LOAD_REGISTER_IMMEDIATE - R_PWR_CLK_STATE
> - Reprogram complete state

Hmm, treating it as a complete state wipe is a nuisance, but fairly
trivial. The simplest way will be for the user to execute the LRI batch
as part of creating the context. But there will be some use cases where
dynamic reconfiguration within an active context will be desired, I'm
sure.

> >If the context is adjusted before
> >first use, the adjustment is for "free"; otherwise if the context is
> >active we flush the context off the GPU (stalling all users) and forcing
> >the GPU to save the context to memory where we can modify it and so
> >ensure that the register is reloaded on next execution.
> 
> There is another cost associated with the adjustment: slice poweron
> and shutdown do take some time to happen (in the order of tens of
> usecs). I have been playing with an i-g-t benchmark to measure this
> delay, I'll send it to the mailing list.

Hmm, I thought the argument for why selecting smaller subslices gave
better performance was that it was restoring the whole set between
contexts, even when the configuration between contexts was the same.

As always numbers demonstrating the advantage, perhaps explaining why
it helps, and also for spotting when we break it are most welcome :)
-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] [RFC 2/4] drm/i915: Program RPCS for Broadwell

[Lionel Landwerlin]

On 02/05/17 04:49, Chris Wilson wrote:

Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_lrc.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 45c187abf10a..9add516d66c2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1804,13 +1804,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
u32 rpcs = 0;
  
  	/*

-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
-   */
-   if (INTEL_GEN(dev_priv) < 9)
-   return 0;


Makes sense. Comments were confusing too.


-
-   /*
 * Starting in Gen9, render power gating can leave
 * slice/subslice/EU in a partially enabled state. We
 * must make an explicit request through RPCS for full



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

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

[Ville Syrjälä]

On Mon, May 01, 2017 at 08:29:10PM -0500, Pierre-Louis Bossart wrote:
> 
> 
> On 04/28/2017 02:37 PM, Ville Syrjälä wrote:
> > On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote:
> >>
> >> On 04/28/2017 03:41 AM, Takashi Iwai wrote:
> >>> On Thu, 27 Apr 2017 18:02:19 +0200,
> >>> ville.syrj...@linux.intel.com wrote:
>  From: Ville Syrjälä 
> 
>  Okay, here's the second attempt at getting multiple pipes playing back
>  audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
>  that now the PCM devices are associated with ports instead of pipes,
>  so the audio from one device always gets output on the same display.
> 
>  I've also tacked on the alsa-lib conf update. No clue whether it's
>  really correct or not (the config language isn't a close friend
>  of mine).
> 
>  BTW I did notice that with LPE audio all the controls say iface=PCM,
>  whereas on HDA a bunch of them say iface=MIXER. No idea if that's
>  OK or not, just something I spotted when I was comparing the results
>  with HDA.
> >>> We generally accept both iface types for IEC958 stuff, since
> >>> historically many drivers have already mixed them up.  So it's no
> >>> problem :)
> >>>
> >>>
>  Entire series available here:
>  git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2
> 
>  Cc: Takashi Iwai 
>  Cc: Pierre-Louis Bossart 
> >>> All look good, and feel free to take my reviewed-by tag
> >>> Reviewed-by: Takashi Iwai 
> >>>
> >>> As said previously, my only slight concern is the compatibility.
> >>> But, in the current situation with PulseAudio, only few people would
> >>> use this driver, so it shouldn't be so big impact, I suppose.
> >>>
> >>> BTW, which port is used in general on BYT/CHT?
> >>>
> >>> Oh, also, I suppose you want to carry these over i915 tree?
> >>> I don't mind either way, I can take them through sound tree if
> >>> preferred, too.
> >> I see frequent oops on startup with this lpe_audio_multipipe_2 branch
> >> with my CHT device not booting or no HDMI audio device created.
> >> Not sure if these issues are due to the new patches or to the rest of
> >> the drm code?
> >>
> >> [5.529023] BUG: unable to handle kernel NULL pointer dereference
> >> at   (null)
> >> [5.529143] IP: hdmi_lpe_audio_probe+0x40f/0x650 [snd_hdmi_lpe_audio]
> >> [5.529202] PGD 0
> >>
> >> [5.529242] Oops:  [#1] SMP
> >> [5.529274] Modules linked in: snd_soc_sst_atom_hifi2_platform
> >> snd_soc_sst_match snd_soc_core snd_compress lpc_ich snd_seq
> >> snd_seq_device shpchp snd_hdmi_lpe_audio(+) snd_pcm snd_timer dw_dmac
> >> snd soundcore i2c_designware_platform(+) i2c_designware_core
> >> spi_pxa2xx_platform acpi_pad mac_hid nfsd auth_rpcgss nfs_acl lockd
> >> grace sunrpc ip_tables x_tables hid_generic mmc_block i2c_hid usbhid hid
> >> autofs4
> >> [5.529605] CPU: 2 PID: 512 Comm: systemd-udevd Not tainted
> >> 4.11.0-rc8-test+ #11
> >> [5.529671] Hardware name: ZOTAC XX/Cherry Trail FFD, BIOS 5.11
> >> 09/28/2016
> >> [5.529736] task: 88007485b780 task.stack: c9bfc000
> >> [5.529793] RIP: 0010:hdmi_lpe_audio_probe+0x40f/0x650
> >> [snd_hdmi_lpe_audio]
> >> [5.529855] RSP: 0018:c9bffaf0 EFLAGS: 00010246
> >> [5.529904] RAX:  RBX: 880079209898 RCX:
> >> 88007920f078
> >> [5.529967] RDX: 0014 RSI: c9bffb28 RDI:
> >> 0002
> >> [5.530031] RBP: c9bffb70 R08: 0001 R09:
> >> 
> >> [5.530094] R10: 88007441bf00 R11: c9bffb36 R12:
> >> 88007920ef20
> >> [5.530159] R13: 88007920ef48 R14: 5688 R15:
> >> 0047
> >> [5.530225] FS:  7f627c988640() GS:88007b30()
> >> knlGS:
> >> [5.530299] CS:  0010 DS:  ES:  CR0: 80050033
> >> [5.530352] CR2:  CR3: 78cb8000 CR4:
> >> 001006e0
> >> [5.530416] Call Trace:
> >> [5.530452]  platform_drv_probe+0x3b/0xa0
> >> [5.530494]  driver_probe_device+0x2bb/0x460
> >> [5.530538]  __driver_attach+0xdf/0xf0
> >> [5.530576]  ? driver_probe_device+0x460/0x460
> >> [5.530620]  bus_for_each_dev+0x60/0xa0
> >> [5.530658]  driver_attach+0x1e/0x20
> >> [5.530693]  bus_add_driver+0x170/0x270
> >> [5.530731]  driver_register+0x60/0xe0
> >> [5.530769]  ? 0xa01cb000
> >> [5.530803]  __platform_driver_register+0x36/0x40
> >> [5.530851]  hdmi_lpe_audio_driver_init+0x17/0x1000 [snd_hdmi_lpe_audio]
> >> [5.530915]  do_one_initcall+0x43/0x180
> >> [5.530956]  ? __vunmap+0x81/0xd0
> >> [5.530991]  ? kfree+0x14c/0x160
> >> [5.531024]  ? kmem_cache_alloc_trace+0x38/0x150
> >> [5.531070]  do_init_module+0x5f/0x1f8
> >> [5.531108]  

[Intel-gfx] [maintainer-tools PATCH v2] dim: Add pull request tag headers

[Sean Paul]

Add some standard headers to the pull request tag annotation.

Changes in v2:
  - Tweaked the template var name s/PULL/TAG/ (Daniel)

Signed-off-by: Sean Paul 
---
 dim | 25 -
 dim.rst |  4 
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index 8937803..e94eb0c 100755
--- a/dim
+++ b/dim
@@ -67,6 +67,9 @@ 
DIM_TEMPLATE_HELLO=${DIM_TEMPLATE_HELLO:-$HOME/.dim.template.hello}
 # signature pull request template
 DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-$HOME/.dim.template.signature}
 
+# tag headers for pull requests
+DIM_TEMPLATE_TAG_HEADERS=${DIM_TEMPLATE_TAG_HEADERS:-$HOME/.dim.template.tagheaders}
+
 #
 # Internal configuration.
 #
@@ -1501,10 +1504,28 @@ function dim_tag_next
 
 }
 
+function prep_pull_tag_headers
+{
+   local template
+
+   if [ -r $DIM_TEMPLATE_TAG_HEADERS ]; then
+   while read -r m || [[ -n "$line" ]]; do
+   template="$template -m '$m'"
+   done < "$DIM_TEMPLATE_TAG_HEADERS"
+   else
+   template="-m 'UABI Changes:'"
+   template="$template -m 'Cross-subsystem Changes:'"
+   template="$template -m 'Core Changes:'"
+   template="$template -m 'Driver Changes:'"
+   fi
+   echo $template
+}
+
 # dim_pull_request branch upstream
 function dim_pull_request
 {
local branch upstream remote repo req_file url git_url suffix tag
+   local tag_headers
 
branch=${1:?$usage}
upstream=${2:?$usage}
@@ -1535,7 +1556,9 @@ function dim_pull_request
done
 
gitk "$branch@{upstream}" ^$upstream &
-   $DRY git tag -a $tag "$branch@{upstream}"
+   tag_headers=$(prep_pull_tag_headers)
+   $DRY git tag $tag_headers $tag "$branch@{upstream}"
+   $DRY git tag -a -f $tag
$DRY git push $remote $tag
prep_pull_mail $req_file $tag
 
diff --git a/dim.rst b/dim.rst
index 3dd19f9..d6438a3 100644
--- a/dim.rst
+++ b/dim.rst
@@ -464,6 +464,10 @@ DIM_TEMPLATE_SIGNATURE
 --
 Path to a file containing a signature template for pull request mails.
 
+DIM_TEMPLATE_TAG_HEADERS
+-
+Path to a file containing tag headers for pull requests, each on their own 
line.
+
 dim_alias_
 -
 Make  an alias for the subcommand defined as the value. For example,
-- 
2.13.0.rc1.294.g07d810a77f-goog

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

Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Oscar Mateo]

On 05/02/2017 11:49 AM, Chris Wilson wrote:

We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI).


Userspace could also do this by themselves via LRI if we simply 
whitelist GEN8_R_PWR_CLK_STATE.


Hardware people suggested this programming model:

- PIPECONTROL - Stalling flish, flush all caches (color, depth, DC$)
- LOAD_REGISTER_IMMEDIATE - R_PWR_CLK_STATE
- Reprogram complete state


If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.


There is another cost associated with the adjustment: slice poweron and 
shutdown do take some time to happen (in the order of tens of usecs). I 
have been playing with an i-g-t benchmark to measure this delay, I'll 
send it to the mailing list.



The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.

We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,

struct drm_i915_gem_context_param arg;

memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
union drm_i915_gem_context_param_sseu *sseu = 

sseu->packed.subslice_mask = 0;

drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}

could be used to disable all subslices where supported.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson 
Cc: Dmitry Rogozhkin 
CC: Tvrtko Ursulin 
CC: Zhipeng Gong 
CC: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem_context.c | 12 +++
  drivers/gpu/drm/i915/intel_lrc.c| 63 +
  drivers/gpu/drm/i915/intel_lrc.h|  3 ++
  include/uapi/drm/i915_drm.h | 11 ++
  4 files changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 71ca74bcf170..0b72f9f62ddb 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1044,6 +1044,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->priority;
break;
+   case I915_CONTEXT_PARAM_SSEU:
+   args->value = intel_lr_context_get_sseu(ctx);
+   break;
default:
ret = -EINVAL;
break;
@@ -1120,6 +1123,15 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
}
break;
  
+	case I915_CONTEXT_PARAM_SSEU:

+   if (args->size)
+   ret = -EINVAL;
+   else if (!i915.enable_execlists)
+   ret = -ENODEV;
+   else
+   ret = intel_lr_context_set_sseu(ctx, args->value);
+   break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a3183298b993..e4e2eefd4854 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2064,3 +2064,66 @@ void intel_lr_context_resume(struct drm_i915_private 
*dev_priv)
}
}
  }
+
+int intel_lr_context_set_sseu(struct i915_gem_context *ctx, u64 value)
+{
+   union drm_i915_gem_context_param_sseu user = { .value = value };
+   struct drm_i915_private *i915 = ctx->i915;
+   struct intel_context *ce = >engine[RCS];
+   struct sseu_dev_info sseu = ctx->sseu;
+   int ret;
+
+   lockdep_assert_held(>drm.struct_mutex);
+
+   sseu.slice_mask =
+   user.packed.slice_mask & INTEL_INFO(i915)->sseu.slice_mask;
+   sseu.subslice_mask =
+   user.packed.subslice_mask & 
INTEL_INFO(i915)->sseu.subslice_mask;
+   sseu.min_eu_per_subslice =
+   max(user.packed.min_eu_per_subslice,
+   INTEL_INFO(i915)->sseu.min_eu_per_subslice);
+   sseu.max_eu_per_subslice =
+   min(user.packed.max_eu_per_subslice,
+   INTEL_INFO(i915)->sseu.max_eu_per_subslice);
+
+   if (memcmp(, >sseu, 

[Intel-gfx] ✓ Fi.CI.BAT: success for dma_buf import support for vgem

[Patchwork]

== Series Details ==

Series: dma_buf import support for vgem
URL   : https://patchwork.freedesktop.org/series/23824/
State : success

== Summary ==

Series 23824v1 dma_buf import support for vgem
https://patchwork.freedesktop.org/api/1.0/series/23824/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-bsw-n3050) fdo#100651

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:434s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:428s
fi-bsw-n3050 total:278  pass:241  dwarn:1   dfail:0   fail:0   skip:36  
time:564s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:542s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:405s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:404s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:565s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:572s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:405s
fi-byt-j1900 failed to collect. IGT log at Patchwork_4600/fi-byt-j1900/igt.log

310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC 
integration manifest
132 drm/vgem: Enable dmabuf import interfaces
6f7618d drm/prime: Introduce drm_gem_prime_import_platform
c510f33 drm/vgem: Add a dummy platform device

== Logs ==

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

[Intel-gfx] [PATCHv3 3/3] drm/vgem: Enable dmabuf import interfaces

[Laura Abbott]

Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).

Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson 
Signed-off-by: Laura Abbott 
---
v3: Minor fixes suggested by Chris Wilson
---
 drivers/gpu/drm/vgem/vgem_drv.c | 133 +++-
 drivers/gpu/drm/vgem/vgem_drv.h |   2 +
 2 files changed, 106 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 727eed2..c254c80 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 #include 
+
+#include 
+
 #include "vgem_drv.h"
 
 #define DRIVER_NAME"vgem"
@@ -46,6 +49,11 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
 {
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
 
+   drm_free_large(vgem_obj->pages);
+
+   if (obj->import_attach)
+   drm_prime_gem_destroy(obj, vgem_obj->table);
+
drm_gem_object_release(obj);
kfree(vgem_obj);
 }
@@ -56,26 +64,49 @@ static int vgem_gem_fault(struct vm_fault *vmf)
struct drm_vgem_gem_object *obj = vma->vm_private_data;
/* We don't use vmf->pgoff since that has the fake offset */
unsigned long vaddr = vmf->address;
-   struct page *page;
-
-   page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
-  (vaddr - vma->vm_start) >> PAGE_SHIFT);
-   if (!IS_ERR(page)) {
-   vmf->page = page;
-   return 0;
-   } else switch (PTR_ERR(page)) {
-   case -ENOSPC:
-   case -ENOMEM:
-   return VM_FAULT_OOM;
-   case -EBUSY:
-   return VM_FAULT_RETRY;
-   case -EFAULT:
-   case -EINVAL:
-   return VM_FAULT_SIGBUS;
-   default:
-   WARN_ON_ONCE(PTR_ERR(page));
-   return VM_FAULT_SIGBUS;
+   int ret;
+   loff_t num_pages;
+   pgoff_t page_offset;
+   page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
+
+   num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
+
+   if (page_offset > num_pages)
+   return VM_FAULT_SIGBUS;
+
+   if (obj->pages) {
+   get_page(obj->pages[page_offset]);
+   vmf->page = obj->pages[page_offset];
+   ret = 0;
+   } else {
+   struct page *page;
+
+   page = shmem_read_mapping_page(
+   file_inode(obj->base.filp)->i_mapping,
+   page_offset);
+   if (!IS_ERR(page)) {
+   vmf->page = page;
+   ret = 0;
+   } else switch (PTR_ERR(page)) {
+   case -ENOSPC:
+   case -ENOMEM:
+   ret = VM_FAULT_OOM;
+   break;
+   case -EBUSY:
+   ret = VM_FAULT_RETRY;
+   break;
+   case -EFAULT:
+   case -EINVAL:
+   ret = VM_FAULT_SIGBUS;
+   break;
+   default:
+   WARN_ON(PTR_ERR(page));
+   ret = VM_FAULT_SIGBUS;
+   break;
+   }
+
}
+   return ret;
 }
 
 static const struct vm_operations_struct vgem_gem_vm_ops = {
@@ -112,12 +143,8 @@ static void vgem_postclose(struct drm_device *dev, struct 
drm_file *file)
kfree(vfile);
 }
 
-/* ioctls */
-
-static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
- struct drm_file *file,
- unsigned int *handle,
- unsigned long size)
+static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
+   unsigned long size)
 {
struct drm_vgem_gem_object *obj;
int ret;
@@ -127,8 +154,31 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
return ERR_PTR(-ENOMEM);
 
ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
-   if (ret)
-   goto err_free;
+   if (ret) {
+   kfree(obj);
+   return ERR_PTR(ret);
+   }
+
+   return obj;
+}
+
+static void __vgem_gem_destroy(struct drm_vgem_gem_object *obj)
+{
+   drm_gem_object_release(>base);
+   kfree(obj);
+}
+
+static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
+ struct 

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Prevent the system suspend complete optimization

[Imre Deak]

On Tue, May 02, 2017 at 06:51:01PM +0200, Daniel Vetter wrote:
> On Tue, May 02, 2017 at 03:04:09PM +0300, Imre Deak wrote:
> > Since
> > 
> > commit bac2a909a096c9110525c18cbb8ce73c660d5f71
> > Author: Rafael J. Wysocki 
> > Date:   Wed Jan 21 02:17:42 2015 +0100
> > 
> > PCI / PM: Avoid resuming PCI devices during system suspend
> > 
> > PCI devices will default to allowing the system suspend complete
> > optimization where devices are not woken up during system suspend if
> > they were already runtime suspended. This however breaks the i915/HDA
> > drivers for two reasons:
> > 
> > - The i915 driver has system suspend specific steps that it needs to
> >   run, that bring the device to a different state than its runtime
> >   suspended state.
> > 
> > - The HDA driver's suspend handler requires power that it will request
> >   from the i915 driver's power domain handler. This in turn requires the
> >   i915 driver to runtime resume itself, but this won't be possible if the
> >   suspend complete optimization is in effect: in this case the i915
> >   runtime PM is disabled and trying to get an RPM reference returns
> >   -EACCESS.
> > 
> > Solve this by requiring the PCI/PM core to resume the device during
> > system suspend which in effect disables the suspend complete optimization.
> > 
> > Regardless of the above commit the optimization stayed disabled for DRM
> > devices until
> > 
> > commit d14d2a8453d650bea32a1c5271af1458cd283a0f
> > Author: Lukas Wunner 
> > Date:   Wed Jun 8 12:49:29 2016 +0200
> > 
> > drm: Remove dev_pm_ops from drm_class
> > 
> > so this patch is in practice a fix for this commit. Another reason for
> > the bug staying hidden for so long is that the optimization for a device
> > is disabled if it's disabled for any of its children devices. i915 may
> > have a backlight device as its child which doesn't support runtime PM
> > and so doesn't allow the optimization either.  So if this backlight
> > device got registered the bug stayed hidden.
> > 
> > Credits to Marta, Tomi and David who enabled pstore logging,
> > that caught one instance of this issue across a suspend/
> > resume-to-ram and Ville who rememberd that the optimization was enabled
> > for some devices at one point.
> > 
> > The first WARN triggered by the problem:
> > 
> > [ 6250.746445] WARNING: CPU: 2 PID: 17384 at 
> > drivers/gpu/drm/i915/intel_runtime_pm.c:2846 intel_runtime_pm_get+0x6b/0xd0 
> > [i915]
> > [ 6250.746448] pm_runtime_get_sync() failed: -13
> > [ 6250.746451] Modules linked in: snd_hda_intel i915 vgem 
> > snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp 
> > crct10dif_pclmul crc32_pclmul
> > snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel e1000e 
> > snd_hda_codec snd_hwdep snd_hda_core ptp mei_me pps_core snd_pcm lpc_ich 
> > mei prime_
> > numbers i2c_hid i2c_designware_platform i2c_designware_core [last unloaded: 
> > i915]
> > [ 6250.746512] CPU: 2 PID: 17384 Comm: kworker/u8:0 Tainted: G U  W 
> >   4.11.0-rc5-CI-CI_DRM_334+ #1
> > [ 6250.746515] Hardware name:  /NUC5i5RYB, BIOS 
> > RYBDWi35.86A.0362.2017.0118.0940 01/18/2017
> > [ 6250.746521] Workqueue: events_unbound async_run_entry_fn
> > [ 6250.746525] Call Trace:
> > [ 6250.746530]  dump_stack+0x67/0x92
> > [ 6250.746536]  __warn+0xc6/0xe0
> > [ 6250.746542]  ? pci_restore_standard_config+0x40/0x40
> > [ 6250.746546]  warn_slowpath_fmt+0x46/0x50
> > [ 6250.746553]  ? __pm_runtime_resume+0x56/0x80
> > [ 6250.746584]  intel_runtime_pm_get+0x6b/0xd0 [i915]
> > [ 6250.746610]  intel_display_power_get+0x1b/0x40 [i915]
> > [ 6250.746646]  i915_audio_component_get_power+0x15/0x20 [i915]
> > [ 6250.746654]  snd_hdac_display_power+0xc8/0x110 [snd_hda_core]
> > [ 6250.746661]  azx_runtime_resume+0x218/0x280 [snd_hda_intel]
> > [ 6250.746667]  pci_pm_runtime_resume+0x76/0xa0
> > [ 6250.746672]  __rpm_callback+0xb4/0x1f0
> > [ 6250.746677]  ? pci_restore_standard_config+0x40/0x40
> > [ 6250.746682]  rpm_callback+0x1f/0x80
> > [ 6250.746686]  ? pci_restore_standard_config+0x40/0x40
> > [ 6250.746690]  rpm_resume+0x4ba/0x740
> > [ 6250.746698]  __pm_runtime_resume+0x49/0x80
> > [ 6250.746703]  pci_pm_suspend+0x57/0x140
> > [ 6250.746709]  dpm_run_callback+0x6f/0x330
> > [ 6250.746713]  ? pci_pm_freeze+0xe0/0xe0
> > [ 6250.746718]  __device_suspend+0xf9/0x370
> > [ 6250.746724]  ? dpm_watchdog_set+0x60/0x60
> > [ 6250.746730]  async_suspend+0x1a/0x90
> > [ 6250.746735]  async_run_entry_fn+0x34/0x160
> > [ 6250.746741]  process_one_work+0x1f2/0x6d0
> > [ 6250.746749]  worker_thread+0x49/0x4a0
> > [ 6250.746755]  kthread+0x107/0x140
> > [ 6250.746759]  ? process_one_work+0x6d0/0x6d0
> > [ 6250.746763]  ? kthread_create_on_node+0x40/0x40
> > [ 6250.746768]  ret_from_fork+0x2e/0x40
> > [ 6250.746778] ---[ end trace 102a62fd2160f5e6 ]---
> > 
> > v2:
> > - Use the new pci_dev->needs_resume flag, to avoid any overhead during
> >   the 

[Intel-gfx] [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

[Laura Abbott]

The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using a platform device associated
with drm_device.

Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson 
Signed-off-by: Laura Abbott 
---
v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
added for new function. Brought back drm_device->platformdev as it had been
removed in 76adb460fd93 ("drm: Remove the struct drm_device platformdev field").
I'm not entirely thrilled about this since the platformdev removal was good
cleanup and this feels like a small step backwards. I don't know of a better
approach though.
---
 drivers/gpu/drm/drm_prime.c | 49 +++--
 include/drm/drmP.h  |  2 ++
 include/drm/drm_prime.h |  4 
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..a557a4b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -594,16 +594,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
 
-/**
- * drm_gem_prime_import - helper library implementation of the import callback
- * @dev: drm_device to import into
- * @dma_buf: dma-buf object to import
- *
- * This is the implementation of the gem_prime_import functions for GEM drivers
- * using the PRIME helpers.
- */
-struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
-   struct dma_buf *dma_buf)
+static struct drm_gem_object *__drm_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf,
+   struct device *attach_dev)
 {
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -625,7 +618,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
if (!dev->driver->gem_prime_import_sg_table)
return ERR_PTR(-EINVAL);
 
-   attach = dma_buf_attach(dma_buf, dev->dev);
+   attach = dma_buf_attach(dma_buf, attach_dev);
if (IS_ERR(attach))
return ERR_CAST(attach);
 
@@ -655,9 +648,43 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
 
return ERR_PTR(ret);
 }
+
+/**
+ * drm_gem_prime_import - helper library implementation of the import callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers.
+ */
+struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf)
+{
+   return __drm_gem_prime_import(dev, dma_buf, dev->dev);
+}
 EXPORT_SYMBOL(drm_gem_prime_import);
 
 /**
+ * drm_gem_prime_import_platform - alternate implementation of the import 
callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is identical to drm_gem_prime_import except the device used for dma_buf
+ * attachment is an internal platform device instead of the standard device
+ * structure. The use of this function should be limited to drivers that do not
+ * set up an underlying device structure.
+ */
+struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
+   struct dma_buf *dma_buf)
+{
+   if (WARN_ON_ONCE(!dev->platformdev))
+   return NULL;
+
+   return __drm_gem_prime_import(dev, dma_buf, >platformdev->dev);
+}
+EXPORT_SYMBOL(drm_gem_prime_import_platform);
+
+/**
  * drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
  * @dev: dev to export the buffer from
  * @file_priv: drm file-private structure
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e1daa4f..086daee 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -439,6 +439,8 @@ struct drm_device {
struct pci_controller *hose;
 #endif
 
+   /**< Platform device for drivers that do not use the standard device */
+   struct platform_device *platformdev;
struct virtio_device *virtdev;
 
struct drm_sg_mem *sg;  /**< Scatter gather memory */
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 0b2a235..9fe39f8 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -65,6 +65,10 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
   int *prime_fd);
 struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
+
+struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
+  

[Intel-gfx] [PATCHv3 1/3] drm/vgem: Add a dummy platform device

[Laura Abbott]

The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.

Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson 
Signed-off-by: Laura Abbott 
---
v3: No changes
---
 drivers/gpu/drm/vgem/vgem_drv.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 9fee38a..727eed2 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -335,11 +335,20 @@ static int __init vgem_init(void)
int ret;
 
vgem_device = drm_dev_alloc(_driver, NULL);
-   if (IS_ERR(vgem_device)) {
-   ret = PTR_ERR(vgem_device);
+   if (IS_ERR(vgem_device))
+   return PTR_ERR(vgem_device);
+
+   vgem_device->platformdev = platform_device_register_simple("vgem",
+   -1, NULL, 0);
+
+   if (!vgem_device->platformdev) {
+   ret = -ENODEV;
goto out;
}
 
+   dma_coerce_mask_and_coherent(_device->platformdev->dev,
+   DMA_BIT_MASK(64));
+
ret  = drm_dev_register(vgem_device, 0);
if (ret)
goto out_unref;
@@ -347,13 +356,15 @@ static int __init vgem_init(void)
return 0;
 
 out_unref:
-   drm_dev_unref(vgem_device);
+   platform_device_unregister(vgem_device->platformdev);
 out:
+   drm_dev_unref(vgem_device);
return ret;
 }
 
 static void __exit vgem_exit(void)
 {
+   platform_device_unregister(vgem_device->platformdev);
drm_dev_unregister(vgem_device);
drm_dev_unref(vgem_device);
 }
-- 
2.7.4

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

[Intel-gfx] [PATCHv3 0/3] dma_buf import support for vgem

[Laura Abbott]

Hi,

This is v3 of the series to add dma_buf import functions for vgem.
This is mostly a rebase to drm-misc/drm-misc-next with a fixup of
the resulting conflicts. More details can be found on the individual
patches.

Thanks,
Laura

Laura Abbott (3):
  drm/vgem: Add a dummy platform device
  drm/prime: Introduce drm_gem_prime_import_platform
  drm/vgem: Enable dmabuf import interfaces

 drivers/gpu/drm/drm_prime.c |  49 ++---
 drivers/gpu/drm/vgem/vgem_drv.c | 150 +++-
 drivers/gpu/drm/vgem/vgem_drv.h |   2 +
 include/drm/drmP.h  |   2 +
 include/drm/drm_prime.h |   4 ++
 5 files changed, 164 insertions(+), 43 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Make scratch register base and count flexible

[Daniele Ceraolo Spurio]

On 02/05/17 05:39, Michal Wajdeczko wrote:

We are using some scratch registers in MMIO based send function.
Make their base and count flexible in preparation of upcoming
GuC firmware/hardware changes.

Signed-off-by: Michal Wajdeczko 
Suggested-by: Daniele Ceraolo Spurio 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.c | 42 +
 drivers/gpu/drm/i915/intel_uc.h |  7 +++
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 72f49e6..73c3324 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -260,9 +260,35 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
__intel_uc_fw_fini(_priv->huc.fw);
 }

+static inline i915_reg_t guc_send_reg(struct intel_guc *guc, u32 i)
+{
+   GEM_BUG_ON(!guc->send_regs.base);
+   GEM_BUG_ON(!guc->send_regs.count);
+   GEM_BUG_ON(i >= guc->send_regs.count);
+
+   return _MMIO(guc->send_regs.base + 4 * i);
+}
+
+static void guc_init_send_regs(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   enum forcewake_domains fw_domains = 0;
+   u32 i;
+
+   guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
+   guc->send_regs.count = SOFT_SCRATCH_COUNT - 1;
+
+   for (i = 0; i < guc->send_regs.count; i++) {
+   fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
+   guc_send_reg(guc, i),
+   FW_REG_READ | FW_REG_WRITE);
+   }
+   guc->send_regs.fw_domains = fw_domains;
+}
+
 static int guc_enable_communication(struct intel_guc *guc)
 {
-   /* XXX: placeholder for alternate setup */


Is it worth retaining this comment? We still expect the new _send 
mechanism setup to be added here, right?



+   guc_init_send_regs(guc);
guc->send = intel_guc_send_mmio;
return 0;
 }
@@ -407,19 +433,19 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
int i;
int ret;

-   if (WARN_ON(len < 1 || len > 15))
-   return -EINVAL;
+   GEM_BUG_ON(!len);
+   GEM_BUG_ON(len > guc->send_regs.count);


Should we call out this change from WARN to GEM_BUG in the commit message?

Nitpicks aside,
Reviewed-by: Daniele Ceraolo Spurio 

Regards,
Daniele



mutex_lock(>send_mutex);
-   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_get(dev_priv, guc->send_regs.fw_domains);

dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = action[0];

for (i = 0; i < len; i++)
-   I915_WRITE(SOFT_SCRATCH(i), action[i]);
+   I915_WRITE(guc_send_reg(guc, i), action[i]);

-   POSTING_READ(SOFT_SCRATCH(i - 1));
+   POSTING_READ(guc_send_reg(guc, i - 1));

intel_guc_notify(guc);

@@ -428,7 +454,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 * Fast commands should still complete in 10us.
 */
ret = __intel_wait_for_register_fw(dev_priv,
-  SOFT_SCRATCH(0),
+  guc_send_reg(guc, 0),
   INTEL_GUC_RECV_MASK,
   INTEL_GUC_RECV_MASK,
   10, 10, );
@@ -450,7 +476,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
}
dev_priv->guc.action_status = status;

-   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
mutex_unlock(>send_mutex);

return ret;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 097289b..a37a8cc 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -205,6 +205,13 @@ struct intel_guc {
uint64_t submissions[I915_NUM_ENGINES];
uint32_t last_seqno[I915_NUM_ENGINES];

+   /* GuC's FW specific registers used in MMIO send */
+   struct {
+   u32 base;
+   u32 count;
+   u32 fw_domains; /* enum forcewake_domains */
+   } send_regs;
+
/* To serialize the intel_guc_send actions */
struct mutex send_mutex;



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

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Prevent the system suspend complete optimization

[Daniel Vetter]

On Tue, May 02, 2017 at 03:04:09PM +0300, Imre Deak wrote:
> Since
> 
> commit bac2a909a096c9110525c18cbb8ce73c660d5f71
> Author: Rafael J. Wysocki 
> Date:   Wed Jan 21 02:17:42 2015 +0100
> 
> PCI / PM: Avoid resuming PCI devices during system suspend
> 
> PCI devices will default to allowing the system suspend complete
> optimization where devices are not woken up during system suspend if
> they were already runtime suspended. This however breaks the i915/HDA
> drivers for two reasons:
> 
> - The i915 driver has system suspend specific steps that it needs to
>   run, that bring the device to a different state than its runtime
>   suspended state.
> 
> - The HDA driver's suspend handler requires power that it will request
>   from the i915 driver's power domain handler. This in turn requires the
>   i915 driver to runtime resume itself, but this won't be possible if the
>   suspend complete optimization is in effect: in this case the i915
>   runtime PM is disabled and trying to get an RPM reference returns
>   -EACCESS.
> 
> Solve this by requiring the PCI/PM core to resume the device during
> system suspend which in effect disables the suspend complete optimization.
> 
> Regardless of the above commit the optimization stayed disabled for DRM
> devices until
> 
> commit d14d2a8453d650bea32a1c5271af1458cd283a0f
> Author: Lukas Wunner 
> Date:   Wed Jun 8 12:49:29 2016 +0200
> 
> drm: Remove dev_pm_ops from drm_class
> 
> so this patch is in practice a fix for this commit. Another reason for
> the bug staying hidden for so long is that the optimization for a device
> is disabled if it's disabled for any of its children devices. i915 may
> have a backlight device as its child which doesn't support runtime PM
> and so doesn't allow the optimization either.  So if this backlight
> device got registered the bug stayed hidden.
> 
> Credits to Marta, Tomi and David who enabled pstore logging,
> that caught one instance of this issue across a suspend/
> resume-to-ram and Ville who rememberd that the optimization was enabled
> for some devices at one point.
> 
> The first WARN triggered by the problem:
> 
> [ 6250.746445] WARNING: CPU: 2 PID: 17384 at 
> drivers/gpu/drm/i915/intel_runtime_pm.c:2846 intel_runtime_pm_get+0x6b/0xd0 
> [i915]
> [ 6250.746448] pm_runtime_get_sync() failed: -13
> [ 6250.746451] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul
> snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel e1000e 
> snd_hda_codec snd_hwdep snd_hda_core ptp mei_me pps_core snd_pcm lpc_ich mei 
> prime_
> numbers i2c_hid i2c_designware_platform i2c_designware_core [last unloaded: 
> i915]
> [ 6250.746512] CPU: 2 PID: 17384 Comm: kworker/u8:0 Tainted: G U  W   
> 4.11.0-rc5-CI-CI_DRM_334+ #1
> [ 6250.746515] Hardware name:  /NUC5i5RYB, BIOS 
> RYBDWi35.86A.0362.2017.0118.0940 01/18/2017
> [ 6250.746521] Workqueue: events_unbound async_run_entry_fn
> [ 6250.746525] Call Trace:
> [ 6250.746530]  dump_stack+0x67/0x92
> [ 6250.746536]  __warn+0xc6/0xe0
> [ 6250.746542]  ? pci_restore_standard_config+0x40/0x40
> [ 6250.746546]  warn_slowpath_fmt+0x46/0x50
> [ 6250.746553]  ? __pm_runtime_resume+0x56/0x80
> [ 6250.746584]  intel_runtime_pm_get+0x6b/0xd0 [i915]
> [ 6250.746610]  intel_display_power_get+0x1b/0x40 [i915]
> [ 6250.746646]  i915_audio_component_get_power+0x15/0x20 [i915]
> [ 6250.746654]  snd_hdac_display_power+0xc8/0x110 [snd_hda_core]
> [ 6250.746661]  azx_runtime_resume+0x218/0x280 [snd_hda_intel]
> [ 6250.746667]  pci_pm_runtime_resume+0x76/0xa0
> [ 6250.746672]  __rpm_callback+0xb4/0x1f0
> [ 6250.746677]  ? pci_restore_standard_config+0x40/0x40
> [ 6250.746682]  rpm_callback+0x1f/0x80
> [ 6250.746686]  ? pci_restore_standard_config+0x40/0x40
> [ 6250.746690]  rpm_resume+0x4ba/0x740
> [ 6250.746698]  __pm_runtime_resume+0x49/0x80
> [ 6250.746703]  pci_pm_suspend+0x57/0x140
> [ 6250.746709]  dpm_run_callback+0x6f/0x330
> [ 6250.746713]  ? pci_pm_freeze+0xe0/0xe0
> [ 6250.746718]  __device_suspend+0xf9/0x370
> [ 6250.746724]  ? dpm_watchdog_set+0x60/0x60
> [ 6250.746730]  async_suspend+0x1a/0x90
> [ 6250.746735]  async_run_entry_fn+0x34/0x160
> [ 6250.746741]  process_one_work+0x1f2/0x6d0
> [ 6250.746749]  worker_thread+0x49/0x4a0
> [ 6250.746755]  kthread+0x107/0x140
> [ 6250.746759]  ? process_one_work+0x6d0/0x6d0
> [ 6250.746763]  ? kthread_create_on_node+0x40/0x40
> [ 6250.746768]  ret_from_fork+0x2e/0x40
> [ 6250.746778] ---[ end trace 102a62fd2160f5e6 ]---
> 
> v2:
> - Use the new pci_dev->needs_resume flag, to avoid any overhead during
>   the ->pm_prepare hook. (Rafael)
> 
> v3:
> - Update commit message to reference the actual regressing commit.
>   (Lukas)
> 
> v4:
> - Rebase on v4 of patch 1/2.
> 
> Fixes: d14d2a8453d6 ("drm: Remove dev_pm_ops from drm_class")
> References: 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Move notification code into virtual function

[Daniele Ceraolo Spurio]

On 02/05/17 05:39, Michal Wajdeczko wrote:

Prepare for alternate GuC notification mechanism.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_uc.c | 10 +-
 drivers/gpu/drm/i915/intel_uc.h |  7 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 7fd75ca..72f49e6 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -94,12 +94,20 @@ void intel_uc_sanitize_options(struct drm_i915_private 
*dev_priv)
i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
 }

+static void guc_write_irq_trigger(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
+}
+
 void intel_uc_init_early(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;

mutex_init(>send_mutex);
guc->send = intel_guc_send_nop;
+   guc->notify = guc_write_irq_trigger;
 }

 static void fetch_uc_fw(struct drm_i915_private *dev_priv,
@@ -413,7 +421,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)

POSTING_READ(SOFT_SCRATCH(i - 1));

-   I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
+   intel_guc_notify(guc);

/*
 * No GuC command should ever take longer than 10ms.
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 1e0eecd..097289b 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -210,6 +210,9 @@ struct intel_guc {

/* GuC's FW specific send function */
int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
+
+   /* GuC's FW specific notify function */
+   void (*notify)(struct intel_guc *guc);
 };

 struct intel_huc {
@@ -233,6 +236,10 @@ static inline int intel_guc_send(struct intel_guc *guc, 
const u32 *action, u32 l
 {
return guc->send(guc, action, len);
 }
+static inline void intel_guc_notify(struct intel_guc *guc)
+{
+   guc->notify(guc);
+}



personal preference: I would use guc->notify directly instead of adding 
intel_guc_notify(). intel_guc_send() made more sense because a function 
with that name already existed and by keeping it we minimized the 
change, but I don't see such benefit with intel_guc_notify() and calling 
the function pointer directly feels more in sync with what we do 
elsewhere in the driver.


No strong feelings anyway, so:

Reviewed-by: Daniele Ceraolo Spurio 

Regards,
Daniele


 /* intel_guc_loader.c */
 int intel_guc_select_fw(struct intel_guc *guc);


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

Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

[Oscar Mateo]

On 05/02/2017 09:17 AM, Mika Kuoppala wrote:

Chris Wilson  writes:


On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote:

The new batchbuffer for CNL surpasses the 4096 byte mark.

Cc: Mika Kuoppala 
Cc: Ben Widawsky 
Signed-off-by: Oscar Mateo 

Evil, 4k+ of nothing-ness that userspace then has to configure for itself
for correctness anyway.

Patch looks ok, but still question the sanity.

Is there a requirement for CNL to init the renderstate?

I would like to drop the render state init from CNL if
we can't find evidence that it needs it. Bspec indicates
that it doesnt.

-Mika


Hi Mika,

I can double-check with the hardware architects, but word around here is 
that render state init has never stopped being a requirement. Where did 
you see in the BSpec that it is not required for CNL?


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Imre Deak]

On Tue, May 02, 2017 at 03:10:29PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to 
> avoid suspend complete optimization
> URL   : https://patchwork.freedesktop.org/series/23803/
> State : warning
> 
> == Summary ==
> 
> Series 23803v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/23803/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> Test kms_flip:
> Subgroup basic-flip-vs-modeset:
> pass   -> DMESG-WARN (fi-byt-j1900) fdo#100652
> Test kms_setmode:
> Subgroup basic-clone-single-crtc:
> pass   -> DMESG-WARN (fi-kbl-7560u)

Slab corruption happening when we allocate, but doesn't look to be our fault.
The corrupted data looks like some DNS query stuff. 

[  536.637703] BUG kmalloc-4096 (Tainted: G U  W  ): Poison overwritten
[  536.637714] 
-

[  536.637730] Disabling lock debugging due to kernel taint
[  536.637731] INFO: 0x880264921198-0x8802649212f1. First byte 0x56 
instead of 0x6b
[  536.637740] INFO: Allocated in kernfs_iop_get_link+0x3e/0x1e0 age=4142 cpu=2 
pid=9676
[  536.637748]  ___slab_alloc.constprop.28+0x38f/0x3d0
[  536.637753]  __slab_alloc.isra.22.constprop.27+0x43/0x80
[  536.637758]  kmem_cache_alloc_trace+0x237/0x2e0
[  536.637762]  kernfs_iop_get_link+0x3e/0x1e0
[  536.637768]  trailing_symlink+0x1e5/0x230
[  536.637772]  path_lookupat+0x5b/0x100
[  536.637776]  filename_lookup+0xa0/0x120
[  536.637781]  user_path_at_empty+0x31/0x40
[  536.637785]  SyS_faccessat+0xa6/0x210
[  536.637789]  SyS_access+0x13/0x20
[  536.637793]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  536.637799] INFO: Freed in kfree_link+0x9/0x10 age=4142 cpu=2 pid=9676
[  536.637804]  __slab_free+0x3cb/0x580
[  536.637808]  kfree+0x266/0x2e0
[  536.637812]  kfree_link+0x9/0x10
[  536.637816]  walk_component+0xc4/0x2d0
[  536.637820]  path_lookupat+0x4f/0x100
[  536.637824]  filename_lookup+0xa0/0x120
[  536.637828]  user_path_at_empty+0x31/0x40
[  536.637833]  SyS_faccessat+0xa6/0x210
[  536.637836]  SyS_access+0x13/0x20
[  536.637840]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  536.637846] INFO: Slab 0xea0009924800 objects=7 used=7 fp=0x  
(null) flags=0x80008100
[  536.637854] INFO: Object 0x880264921158 @offset=4440 
fp=0x8802649267e8

...

[  536.639826] CPU: 1 PID: 9693 Comm: kms_setmode Tainted: GBU  W   
4.11.0-rc8-CI-Patchwork_4598+ #1
[  536.639827] Hardware name: Dell Inc. XPS 13 9360/093TW6, BIOS 1.3.2 
01/18/2017
[  536.639828] Call Trace:
[  536.639831]  dump_stack+0x67/0x92
[  536.639832]  print_trailer+0x14b/0x230
[  536.639834]  check_bytes_and_report+0xc0/0x100
[  536.639835]  check_object+0x261/0x2b0
[  536.639855]  ? __pdp_init.isra.4+0x44/0x90 [i915]
[  536.639857]  alloc_debug_processing+0x199/0x1b0
[  536.639858]  ___slab_alloc.constprop.28+0x38f/0x3d0
[  536.639871]  ? __pdp_init.isra.4+0x44/0x90 [i915]
[  536.639872]  ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[  536.639874]  ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[  536.639885]  ? alloc_pdp+0x3a/0xd0 [i915]
[  536.639887]  ? save_stack.isra.2+0x53/0xa0
[  536.639899]  ? __pdp_init.isra.4+0x44/0x90 [i915]
[  536.639900]  __slab_alloc.isra.22.constprop.27+0x43/0x80
[  536.639902]  ? __slab_alloc.isra.22.constprop.27+0x43/0x80
[  536.639903]  __kmalloc+0x288/0x330
[  536.639914]  __pdp_init.isra.4+0x44/0x90 [i915]
[  536.639925]  alloc_pdp+0x62/0xd0 [i915]
[  536.639935]  gen8_ppgtt_alloc_4lvl+0xba/0x150 [i915]
[  536.639946]  ppgtt_bind_vma+0x2c/0x80 [i915]
[  536.639959]  i915_vma_bind+0xb9/0x240 [i915]
[  536.639972]  __i915_vma_do_pin+0x404/0x6b0 [i915]
[  536.639983]  i915_gem_execbuffer_reserve_vma.isra.9+0xc3/0x240 [i915]
[  536.639994]  i915_gem_execbuffer_reserve.isra.10+0x43e/0x470 [i915]
[  536.640005]  i915_gem_do_execbuffer.isra.16+0x639/0x1b80 [i915]
[  536.640007]  ? __lock_acquire+0x484/0x1ac0
[  536.640019]  i915_gem_execbuffer2+0xb5/0x220 [i915]
[  536.640021]  drm_ioctl+0x1f4/0x480
[  536.640031]  ? i915_gem_execbuffer+0x330/0x330 [i915]
[  536.640034]  do_vfs_ioctl+0x90/0x6e0


> 
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> fdo#100652 https://bugs.freedesktop.org/show_bug.cgi?id=100652
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:437s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:429s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:580s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:502s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time:545s
> fi-byt-j1900 total:278  pass:253  dwarn:1   dfail:0   fail:0   skip:24  
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid 
suspend complete optimization
URL   : https://patchwork.freedesktop.org/series/23803/
State : success

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:430s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:556s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:404s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:419s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:486s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:562s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:457s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:428s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:412s

310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC 
integration manifest
f4a0cab drm/i915: Prevent the system suspend complete optimization
58b9cf9 PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Logs ==

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

Re: [Intel-gfx] [PATCH v14] drm/i915: Squash repeated awaits on the same fence

[Tvrtko Ursulin]

On 02/05/2017 15:45, Chris Wilson wrote:

On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote:

On 28/04/2017 20:02, Chris Wilson wrote:

+   if (!p->height) {
+   for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) {


Would for_each_set_bit be more readable?


Downside is that we have to cast bitmap to unsigned long:

Something like:

diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c 
b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
index 1f8b594b4157..9fbc9e144833 100644
--- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
@@ -33,7 +33,7 @@ __sync_print(struct i915_syncmap *p,
 unsigned int idx)
 {
unsigned long len;
-   unsigned i, bits, X;
+   unsigned i, X;

if (depth) {
unsigned int d;
@@ -61,7 +61,7 @@ __sync_print(struct i915_syncmap *p,
*sz -= len;

if (!p->height) {
-   for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) {
+   for_each_set_bit(i, (unsigned long *)>bitmap, KSYNCMAP) {
len = scnprintf(buf, *sz, " %x:%x,",
   i - 1, __sync_seqno(p)[i - 1]);
buf += len;
@@ -76,11 +76,11 @@ __sync_print(struct i915_syncmap *p,
*sz -= len;

if (p->height) {
-   for (bits = p->bitmap; (i = ffs(bits)); ) {
-   bits &= ~0u << i;
+   for_each_set_bit(i, (unsigned long *)>bitmap, KSYNCMAP) {
buf = __sync_print(__sync_child(p)[i - 1],
   buf, sz,
-  depth + 1, (last << 1) | !!bits,
+  depth + 1, (last << 1) |
+  !!(p->bitmap & (~0u << i)),
   i - 1);
}
}


Its a bit smaller line shrink in this version so I am not sure. Most 
importantly it is not getting rid of the ~0u << i business. Have it as 
you prefer it.



And thank you for not suggesting to use the horrible code generation of
for_each_set_bit() outside of the pretty printer. :)

P.S. Latest ascii graphs:
0x
0-> 0x00XX
|   0-> 0x0XXX
|   |   0-> 0x00XX
|   |   |   0-> 0x000X 0:0, 1:1, 2:2
|   |   |   1-> 0x001X 0:10, 1:11
|   |   2-> 0x020X 0:200, 1:201
|   5-> 0x0050
|   0-> 0x005X 0:50, 1:51
|   3-> 0x0050300X 0:503000, 1:503001
e-> 0xe00X e:e


I think that's better. And thank you for adding the graph!

Regards,

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

Re: [Intel-gfx] [PATCH v14] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Tue, May 02, 2017 at 03:45:23PM +0100, Chris Wilson wrote:
> On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote:
> > On 28/04/2017 20:02, Chris Wilson wrote:
> > >+  if (!p->height) {
> > >+  for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) {
> > 
> > Would for_each_set_bit be more readable?
> 
> Downside is that we have to cast bitmap to unsigned long:
> 
> Something like:

Well that forgot that for_each_set_bit was 0-based and not off-by-one
like ffs(). Let's try again:


diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c 
b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
index 7b9c6eeaf62c..f279347ab218 100644
--- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
@@ -33,7 +33,7 @@ __sync_print(struct i915_syncmap *p,
 unsigned int idx)
 {
unsigned long len;
-   unsigned i, bits, X;
+   unsigned i, X;
 
if (depth) {
unsigned int d;
@@ -60,9 +60,9 @@ __sync_print(struct i915_syncmap *p,
scnprintf(buf - X, *sz + X, "%*s", X, "X");
 
if (!p->height) {
-   for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) {
+   for_each_set_bit(i, (unsigned long *)>bitmap, KSYNCMAP) {
len = scnprintf(buf, *sz, " %x:%x,",
-  i - 1, __sync_seqno(p)[i - 1]);
+  i, __sync_seqno(p)[i]);
buf += len;
*sz -= len;
}
@@ -75,12 +75,12 @@ __sync_print(struct i915_syncmap *p,
*sz -= len;
 
if (p->height) {
-   for (bits = p->bitmap; (i = ffs(bits)); ) {
-   bits &= ~0u << i;
-   buf = __sync_print(__sync_child(p)[i - 1],
-  buf, sz,
-  depth + 1, (last << 1) | !!bits,
-  i - 1);
+   for_each_set_bit(i, (unsigned long *)>bitmap, KSYNCMAP) {
+   buf = __sync_print(__sync_child(p)[i], buf, sz,
+  depth + 1,
+  (last << 1) |
+  !!(p->bitmap & (~0u << (i + 1))),
+  i);
}
}
 

I'm in favour of the cast over gratiutious use of ffs()
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid 
suspend complete optimization
URL   : https://patchwork.freedesktop.org/series/23803/
State : warning

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-byt-j1900) fdo#100652
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> DMESG-WARN (fi-kbl-7560u)

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:437s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:429s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:580s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:545s
fi-byt-j1900 total:278  pass:253  dwarn:1   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:416s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:458s
fi-kbl-7560u total:278  pass:266  dwarn:2   dfail:0   fail:0   skip:10  
time:567s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:584s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:459s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:523s
fi-snb-2600  total:278  pass:248  dwarn:1   dfail:0   fail:0   skip:29  
time:413s

310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC 
integration manifest
443c742 drm/i915: Prevent the system suspend complete optimization
36f68e3 PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Logs ==

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

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Add pull request tag headers

[Sean Paul]

On Tue, May 2, 2017 at 10:55 AM, Sean Paul  wrote:
> Add some standard headers to the pull request tag annotation.
>
> Signed-off-by: Sean Paul 
> ---

This time to Daniel's actual address.

Note that I couldn't add the headers as comments since git tag -m
skips anything prefixed with #. Hopefully having the ability to
override the headers makes up for this.

Sean

>  dim | 25 -
>  dim.rst |  4 
>  2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/dim b/dim
> index 8937803..0d52e9d 100755
> --- a/dim
> +++ b/dim
> @@ -67,6 +67,9 @@ 
> DIM_TEMPLATE_HELLO=${DIM_TEMPLATE_HELLO:-$HOME/.dim.template.hello}
>  # signature pull request template
>  
> DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-$HOME/.dim.template.signature}
>
> +# pull request headers template
> +DIM_TEMPLATE_PULL_HEADERS=${DIM_TEMPLATE_PULL_HEADERS:-$HOME/.dim.template.pullheaders}
> +
>  #
>  # Internal configuration.
>  #
> @@ -1501,10 +1504,28 @@ function dim_tag_next
>
>  }
>
> +function prep_pull_tag_headers
> +{
> +   local template
> +
> +   if [ -r $DIM_TEMPLATE_PULL_HEADERS ]; then
> +   while read -r m || [[ -n "$line" ]]; do
> +   template="$template -m '$m'"
> +   done < "$DIM_TEMPLATE_PULL_HEADERS"
> +   else
> +   template="-m 'UABI Changes:'"
> +   template="$template -m 'Cross-subsystem Changes:'"
> +   template="$template -m 'Core Changes:'"
> +   template="$template -m 'Driver Changes:'"
> +   fi
> +   echo $template
> +}
> +
>  # dim_pull_request branch upstream
>  function dim_pull_request
>  {
> local branch upstream remote repo req_file url git_url suffix tag
> +   local tag_headers
>
> branch=${1:?$usage}
> upstream=${2:?$usage}
> @@ -1535,7 +1556,9 @@ function dim_pull_request
> done
>
> gitk "$branch@{upstream}" ^$upstream &
> -   $DRY git tag -a $tag "$branch@{upstream}"
> +   tag_headers=$(prep_pull_tag_headers)
> +   $DRY git tag $tag_headers $tag "$branch@{upstream}"
> +   $DRY git tag -a -f $tag
> $DRY git push $remote $tag
> prep_pull_mail $req_file $tag
>
> diff --git a/dim.rst b/dim.rst
> index 3dd19f9..02a7a55 100644
> --- a/dim.rst
> +++ b/dim.rst
> @@ -464,6 +464,10 @@ DIM_TEMPLATE_SIGNATURE
>  --
>  Path to a file containing a signature template for pull request mails.
>
> +DIM_TEMPLATE_PULL_HEADERS
> +-
> +Path to a file containing pull request headers, each on their own line.
> +
>  dim_alias_
>  -
>  Make  an alias for the subcommand defined as the value. For 
> example,
> --
> 2.13.0.rc1.294.g07d810a77f-goog
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [maintainer-tools PATCH] dim: Add pull request tag headers

[Sean Paul]

Add some standard headers to the pull request tag annotation.

Signed-off-by: Sean Paul 
---
 dim | 25 -
 dim.rst |  4 
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index 8937803..0d52e9d 100755
--- a/dim
+++ b/dim
@@ -67,6 +67,9 @@ 
DIM_TEMPLATE_HELLO=${DIM_TEMPLATE_HELLO:-$HOME/.dim.template.hello}
 # signature pull request template
 DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-$HOME/.dim.template.signature}
 
+# pull request headers template
+DIM_TEMPLATE_PULL_HEADERS=${DIM_TEMPLATE_PULL_HEADERS:-$HOME/.dim.template.pullheaders}
+
 #
 # Internal configuration.
 #
@@ -1501,10 +1504,28 @@ function dim_tag_next
 
 }
 
+function prep_pull_tag_headers
+{
+   local template
+
+   if [ -r $DIM_TEMPLATE_PULL_HEADERS ]; then
+   while read -r m || [[ -n "$line" ]]; do
+   template="$template -m '$m'"
+   done < "$DIM_TEMPLATE_PULL_HEADERS"
+   else
+   template="-m 'UABI Changes:'"
+   template="$template -m 'Cross-subsystem Changes:'"
+   template="$template -m 'Core Changes:'"
+   template="$template -m 'Driver Changes:'"
+   fi
+   echo $template
+}
+
 # dim_pull_request branch upstream
 function dim_pull_request
 {
local branch upstream remote repo req_file url git_url suffix tag
+   local tag_headers
 
branch=${1:?$usage}
upstream=${2:?$usage}
@@ -1535,7 +1556,9 @@ function dim_pull_request
done
 
gitk "$branch@{upstream}" ^$upstream &
-   $DRY git tag -a $tag "$branch@{upstream}"
+   tag_headers=$(prep_pull_tag_headers)
+   $DRY git tag $tag_headers $tag "$branch@{upstream}"
+   $DRY git tag -a -f $tag
$DRY git push $remote $tag
prep_pull_mail $req_file $tag
 
diff --git a/dim.rst b/dim.rst
index 3dd19f9..02a7a55 100644
--- a/dim.rst
+++ b/dim.rst
@@ -464,6 +464,10 @@ DIM_TEMPLATE_SIGNATURE
 --
 Path to a file containing a signature template for pull request mails.
 
+DIM_TEMPLATE_PULL_HEADERS
+-
+Path to a file containing pull request headers, each on their own line.
+
 dim_alias_
 -
 Make  an alias for the subcommand defined as the value. For example,
-- 
2.13.0.rc1.294.g07d810a77f-goog

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

Re: [Intel-gfx] [PATCH v14] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote:
> On 28/04/2017 20:02, Chris Wilson wrote:
> >+prandom_seed_state(, i915_selftest.random_seed);
> >+count = 0;
> >+kt = ktime_get();
> >+end_time = jiffies + HZ/10;
> >+do {
> >+u32 id = random_engine();
> >+u32 seqno = prandom_u32_state();
> >+
> >+if (!__intel_timeline_sync_is_later(tl, id, seqno))
> >+__intel_timeline_sync_set(tl, id, seqno);
> >+
> >+count++;
> >+} while (!time_after(jiffies, end_time));
> >+kt = ktime_sub(ktime_get(), kt);
> >+kt = ktime_sub_ns(kt, count * prng32_1M / M);
> 
> Two randoms to account here.

Thank you. That fixes the discrepancy between the random_engine results
and using the engines in order.
-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 v14] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote:
> On 28/04/2017 20:02, Chris Wilson wrote:
> >+if (!p->height) {
> >+for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) {
> 
> Would for_each_set_bit be more readable?

Downside is that we have to cast bitmap to unsigned long:

Something like:

diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c 
b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
index 1f8b594b4157..9fbc9e144833 100644
--- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
@@ -33,7 +33,7 @@ __sync_print(struct i915_syncmap *p,
 unsigned int idx)
 {
unsigned long len;
-   unsigned i, bits, X;
+   unsigned i, X;
 
if (depth) {
unsigned int d;
@@ -61,7 +61,7 @@ __sync_print(struct i915_syncmap *p,
*sz -= len;
 
if (!p->height) {
-   for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) {
+   for_each_set_bit(i, (unsigned long *)>bitmap, KSYNCMAP) {
len = scnprintf(buf, *sz, " %x:%x,",
   i - 1, __sync_seqno(p)[i - 1]);
buf += len;
@@ -76,11 +76,11 @@ __sync_print(struct i915_syncmap *p,
*sz -= len;
 
if (p->height) {
-   for (bits = p->bitmap; (i = ffs(bits)); ) {
-   bits &= ~0u << i;
+   for_each_set_bit(i, (unsigned long *)>bitmap, KSYNCMAP) {
buf = __sync_print(__sync_child(p)[i - 1],
   buf, sz,
-  depth + 1, (last << 1) | !!bits,
+  depth + 1, (last << 1) |
+  !!(p->bitmap & (~0u << i)),
   i - 1);
}
}

And thank you for not suggesting to use the horrible code generation of
for_each_set_bit() outside of the pretty printer. :)

P.S. Latest ascii graphs:
0x
0-> 0x00XX
|   0-> 0x0XXX
|   |   0-> 0x00XX
|   |   |   0-> 0x000X 0:0, 1:1, 2:2
|   |   |   1-> 0x001X 0:10, 1:11
|   |   2-> 0x020X 0:200, 1:201
|   5-> 0x0050
|   0-> 0x005X 0:50, 1:51
|   3-> 0x0050300X 0:503000, 1:503001
e-> 0xe00X e:e
-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: success for series starting with [1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework (rev4)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common 
mmio dbg framework (rev4)
URL   : https://patchwork.freedesktop.org/series/22571/
State : success

== Summary ==

Series 22571v4 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22571/revisions/4/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:434s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:575s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:547s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:455s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:566s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:571s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:467s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:396s

310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC 
integration manifest
12c80e1 drm/i915: Use wait_for_atomic_us when waiting for gt fifo
d578fcc drm/i915: Move the GTFIFODBG to the common mmio dbg framework

== Logs ==

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

[Intel-gfx] [PATCH 2/2] drm/i915: Use wait_for_atomic_us when waiting for gt fifo

[Mika Kuoppala]

From: Mika Kuoppala 

Replace the handcrafter loop when checking for fifo slots
with atomic wait for. This brings this wait in line with
the other waits on register access. We also get a readable
timeout constraint, so make it to fail after 10ms.

Chris suggested that we should fail silently as the fifo debug
handler, now attached to unclaimed mmio handling, will take care of the
possible errors at later stage.

Note that the decision to wait was changed so that we avoid
allocating the first reserved entry. Nor do we reduce the count
if we fail the wait, removing the possiblity to wrap the
count if the hw fifo returned zero.

v2: remove unclaimed check on timeout (Chris)
v3: use void return (Chris)

References: https://bugs.freedesktop.org/show_bug.cgi?id=100247
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uncore.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index ba7e9e8..aa9d306 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -29,6 +29,7 @@
 #include 
 
 #define FORCEWAKE_ACK_TIMEOUT_MS 50
+#define GT_FIFO_TIMEOUT_MS  10
 
 #define __raw_posting_read(dev_priv__, reg__) 
(void)__raw_i915_read32((dev_priv__), (reg__))
 
@@ -179,30 +180,27 @@ static inline u32 fifo_free_entries(struct 
drm_i915_private *dev_priv)
return count & GT_FIFO_FREE_ENTRIES_MASK;
 }
 
-static int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
+static void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
 {
-   int ret = 0;
+   u32 n;
 
/* On VLV, FIFO will be shared by both SW and HW.
 * So, we need to read the FREE_ENTRIES everytime */
if (IS_VALLEYVIEW(dev_priv))
-   dev_priv->uncore.fifo_count = fifo_free_entries(dev_priv);
-
-   if (dev_priv->uncore.fifo_count < GT_FIFO_NUM_RESERVED_ENTRIES) {
-   int loop = 500;
-   u32 fifo = fifo_free_entries(dev_priv);
-
-   while (fifo <= GT_FIFO_NUM_RESERVED_ENTRIES && loop--) {
-   udelay(10);
-   fifo = fifo_free_entries(dev_priv);
+   n = fifo_free_entries(dev_priv);
+   else
+   n = dev_priv->uncore.fifo_count;
+
+   if (n <= GT_FIFO_NUM_RESERVED_ENTRIES) {
+   if (wait_for_atomic((n = fifo_free_entries(dev_priv)) >
+   GT_FIFO_NUM_RESERVED_ENTRIES,
+   GT_FIFO_TIMEOUT_MS)) {
+   DRM_DEBUG("GT_FIFO timeout, entries: %u\n", n);
+   return;
}
-   if (WARN_ON(loop < 0 && fifo <= GT_FIFO_NUM_RESERVED_ENTRIES))
-   ++ret;
-   dev_priv->uncore.fifo_count = fifo;
}
-   dev_priv->uncore.fifo_count--;
 
-   return ret;
+   dev_priv->uncore.fifo_count = n - 1;
 }
 
 static enum hrtimer_restart
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Move notification code into virtual function

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915/guc: Move notification code into 
virtual function
URL   : https://patchwork.freedesktop.org/series/23805/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:530s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:451s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:550s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:440s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:562s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:453s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:485s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:415s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:407s

310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC 
integration manifest
3335977 HAX Enable GuC loading & submission
6a06ee0 drm/i915/guc: Make scratch register base and count flexible
0207b59 drm/i915/guc: Move notification code into virtual function

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Imre Deak]

On Tue, May 02, 2017 at 01:21:41PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to 
> avoid suspend complete optimization
> URL   : https://patchwork.freedesktop.org/series/23803/
> State : failure
> 
> == Summary ==
> 
> Series 23803v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/23803/revisions/1/mbox/
> 
> Test drv_module_reload:
> Subgroup basic-reload:
> pass   -> INCOMPLETE (fi-kbl-7500u)

Looks unrelated as it happens after vgem_basic/unload or during
drm_module_reload/basic-reload, neither of which is related to the
change (which makes a difference only during system suspend/resume).

> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> pass   -> INCOMPLETE (fi-bxt-t5700)

Looks like CI provisoning problem:
Installing IGT_newest
tar: ./bin/intel-gpu-overlay: time stamp 2017-05-02 15:19:58 is 
38519469.423180746 s in the future
...
Build timed out (after 14 minutes). Marking the build as aborted.
FATAL: command execution failed
java.util.concurrent.TimeoutException: Ping started at 1493730937083 hasn't 
completed by 1493731177084

> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:436s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:427s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:572s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:513s
> fi-bxt-t5700 total:207  pass:193  dwarn:0   dfail:0   fail:0   skip:13 
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:494s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:484s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:411s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:403s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:420s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:486s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:469s
> fi-kbl-7500u total:274  pass:256  dwarn:0   dfail:0   fail:0   skip:17 
> fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:563s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:451s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:576s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:456s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:491s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:433s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:534s
> fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
> time:412s
> 
> 310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s 
> UTC integration manifest
> e606d9f drm/i915: Prevent the system suspend complete optimization
> b3a3fc7 PCI / PM: Add needs_resume flag to avoid suspend complete optimization
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4594/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Move the GTFIFODBG to the 
common mmio dbg framework
URL   : https://patchwork.freedesktop.org/series/23804/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:540s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:452s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:564s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:502s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:433s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:248  dwarn:1   dfail:0   fail:0   skip:29  
time:413s

310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC 
integration manifest
48bedb7 drm/i915: Use wait_for_atomic_us when waiting for gt fifo
3017c51 drm/i915: Move the GTFIFODBG to the common mmio dbg framework

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid 
suspend complete optimization
URL   : https://patchwork.freedesktop.org/series/23803/
State : failure

== Summary ==

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

Test drv_module_reload:
Subgroup basic-reload:
pass   -> INCOMPLETE (fi-kbl-7500u)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> INCOMPLETE (fi-bxt-t5700)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:436s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:513s
fi-bxt-t5700 total:207  pass:193  dwarn:0   dfail:0   fail:0   skip:13 
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:484s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:403s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:486s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:274  pass:256  dwarn:0   dfail:0   fail:0   skip:17 
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:563s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:576s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:456s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:433s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:534s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:412s

310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC 
integration manifest
e606d9f drm/i915: Prevent the system suspend complete optimization
b3a3fc7 PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Logs ==

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

[Intel-gfx] [PATCH 3/3] HAX Enable GuC loading & submission

[Michal Wajdeczko]

This is just for CI testing, *** DO NOT MERGE ***

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..abd2894 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = 1,
+   .enable_guc_submission = 1,
.guc_log_level = -1,
.guc_firmware_path = NULL,
.huc_firmware_path = NULL,
@@ -221,12 +221,12 @@ MODULE_PARM_DESC(edp_vswing,
 module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
 MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto, 0=never, 1=if available [default], 2=required)");
 
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto, 0=never, 1=if available [default], 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Make scratch register base and count flexible

[Michal Wajdeczko]

We are using some scratch registers in MMIO based send function.
Make their base and count flexible in preparation of upcoming
GuC firmware/hardware changes.

Signed-off-by: Michal Wajdeczko 
Suggested-by: Daniele Ceraolo Spurio 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.c | 42 +
 drivers/gpu/drm/i915/intel_uc.h |  7 +++
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 72f49e6..73c3324 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -260,9 +260,35 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
__intel_uc_fw_fini(_priv->huc.fw);
 }
 
+static inline i915_reg_t guc_send_reg(struct intel_guc *guc, u32 i)
+{
+   GEM_BUG_ON(!guc->send_regs.base);
+   GEM_BUG_ON(!guc->send_regs.count);
+   GEM_BUG_ON(i >= guc->send_regs.count);
+
+   return _MMIO(guc->send_regs.base + 4 * i);
+}
+
+static void guc_init_send_regs(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   enum forcewake_domains fw_domains = 0;
+   u32 i;
+
+   guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
+   guc->send_regs.count = SOFT_SCRATCH_COUNT - 1;
+
+   for (i = 0; i < guc->send_regs.count; i++) {
+   fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
+   guc_send_reg(guc, i),
+   FW_REG_READ | FW_REG_WRITE);
+   }
+   guc->send_regs.fw_domains = fw_domains;
+}
+
 static int guc_enable_communication(struct intel_guc *guc)
 {
-   /* XXX: placeholder for alternate setup */
+   guc_init_send_regs(guc);
guc->send = intel_guc_send_mmio;
return 0;
 }
@@ -407,19 +433,19 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
int i;
int ret;
 
-   if (WARN_ON(len < 1 || len > 15))
-   return -EINVAL;
+   GEM_BUG_ON(!len);
+   GEM_BUG_ON(len > guc->send_regs.count);
 
mutex_lock(>send_mutex);
-   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_get(dev_priv, guc->send_regs.fw_domains);
 
dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = action[0];
 
for (i = 0; i < len; i++)
-   I915_WRITE(SOFT_SCRATCH(i), action[i]);
+   I915_WRITE(guc_send_reg(guc, i), action[i]);
 
-   POSTING_READ(SOFT_SCRATCH(i - 1));
+   POSTING_READ(guc_send_reg(guc, i - 1));
 
intel_guc_notify(guc);
 
@@ -428,7 +454,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 * Fast commands should still complete in 10us.
 */
ret = __intel_wait_for_register_fw(dev_priv,
-  SOFT_SCRATCH(0),
+  guc_send_reg(guc, 0),
   INTEL_GUC_RECV_MASK,
   INTEL_GUC_RECV_MASK,
   10, 10, );
@@ -450,7 +476,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
}
dev_priv->guc.action_status = status;
 
-   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
mutex_unlock(>send_mutex);
 
return ret;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 097289b..a37a8cc 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -205,6 +205,13 @@ struct intel_guc {
uint64_t submissions[I915_NUM_ENGINES];
uint32_t last_seqno[I915_NUM_ENGINES];
 
+   /* GuC's FW specific registers used in MMIO send */
+   struct {
+   u32 base;
+   u32 count;
+   u32 fw_domains; /* enum forcewake_domains */
+   } send_regs;
+
/* To serialize the intel_guc_send actions */
struct mutex send_mutex;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Move notification code into virtual function

[Michal Wajdeczko]

Prepare for alternate GuC notification mechanism.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_uc.c | 10 +-
 drivers/gpu/drm/i915/intel_uc.h |  7 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 7fd75ca..72f49e6 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -94,12 +94,20 @@ void intel_uc_sanitize_options(struct drm_i915_private 
*dev_priv)
i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
 }
 
+static void guc_write_irq_trigger(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
+}
+
 void intel_uc_init_early(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
 
mutex_init(>send_mutex);
guc->send = intel_guc_send_nop;
+   guc->notify = guc_write_irq_trigger;
 }
 
 static void fetch_uc_fw(struct drm_i915_private *dev_priv,
@@ -413,7 +421,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 
POSTING_READ(SOFT_SCRATCH(i - 1));
 
-   I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
+   intel_guc_notify(guc);
 
/*
 * No GuC command should ever take longer than 10ms.
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 1e0eecd..097289b 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -210,6 +210,9 @@ struct intel_guc {
 
/* GuC's FW specific send function */
int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
+
+   /* GuC's FW specific notify function */
+   void (*notify)(struct intel_guc *guc);
 };
 
 struct intel_huc {
@@ -233,6 +236,10 @@ static inline int intel_guc_send(struct intel_guc *guc, 
const u32 *action, u32 l
 {
return guc->send(guc, action, len);
 }
+static inline void intel_guc_notify(struct intel_guc *guc)
+{
+   guc->notify(guc);
+}
 
 /* intel_guc_loader.c */
 int intel_guc_select_fw(struct intel_guc *guc);
-- 
2.7.4

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

[Intel-gfx] [CI 2/2] drm/i915: Use wait_for_atomic_us when waiting for gt fifo

[Mika Kuoppala]

From: Mika Kuoppala 

Replace the handcrafter loop when checking for fifo slots
with atomic wait for. This brings this wait in line with
the other waits on register access. We also get a readable
timeout constraint, so make it to fail after 10ms.

Chris suggested that we should fail silently as the fifo debug
handler, now attached to unclaimed mmio handling, will take care of the
possible errors at later stage.

Note that the decision to wait was changed so that we avoid
allocating the first reserved entry. Nor do we reduce the count
if we fail the wait, removing the possiblity to wrap the
count if the hw fifo returned zero.

v2: remove unclaimed check on timeout (Chris)

References: https://bugs.freedesktop.org/show_bug.cgi?id=100247
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uncore.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index ba7e9e8..092e3dd 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -29,6 +29,7 @@
 #include 
 
 #define FORCEWAKE_ACK_TIMEOUT_MS 50
+#define GT_FIFO_TIMEOUT_MS  10
 
 #define __raw_posting_read(dev_priv__, reg__) 
(void)__raw_i915_read32((dev_priv__), (reg__))
 
@@ -181,28 +182,26 @@ static inline u32 fifo_free_entries(struct 
drm_i915_private *dev_priv)
 
 static int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
 {
-   int ret = 0;
+   u32 n;
 
/* On VLV, FIFO will be shared by both SW and HW.
 * So, we need to read the FREE_ENTRIES everytime */
if (IS_VALLEYVIEW(dev_priv))
-   dev_priv->uncore.fifo_count = fifo_free_entries(dev_priv);
-
-   if (dev_priv->uncore.fifo_count < GT_FIFO_NUM_RESERVED_ENTRIES) {
-   int loop = 500;
-   u32 fifo = fifo_free_entries(dev_priv);
-
-   while (fifo <= GT_FIFO_NUM_RESERVED_ENTRIES && loop--) {
-   udelay(10);
-   fifo = fifo_free_entries(dev_priv);
+   n = fifo_free_entries(dev_priv);
+   else
+   n = dev_priv->uncore.fifo_count;
+
+   if (n <= GT_FIFO_NUM_RESERVED_ENTRIES) {
+   if (wait_for_atomic((n = fifo_free_entries(dev_priv)) >
+   GT_FIFO_NUM_RESERVED_ENTRIES,
+   GT_FIFO_TIMEOUT_MS)) {
+   DRM_DEBUG("GT_FIFO timeout, entries: %u\n", n);
+   return -EBUSY;
}
-   if (WARN_ON(loop < 0 && fifo <= GT_FIFO_NUM_RESERVED_ENTRIES))
-   ++ret;
-   dev_priv->uncore.fifo_count = fifo;
}
-   dev_priv->uncore.fifo_count--;
 
-   return ret;
+   dev_priv->uncore.fifo_count = n - 1;
+   return 0;
 }
 
 static enum hrtimer_restart
-- 
2.7.4

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

[Intel-gfx] [CI 1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

[Mika Kuoppala]

From: Mika Kuoppala 

Remove the per-mmio checking of the FIFO debug register into the common
conditional mmio debug handling. Based on patch from Chris Wilson.

v2: postpone warn on fifodbg for unclaimed reg debugs

Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uncore.c | 76 +++--
 1 file changed, 30 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 07a722f..ba7e9e8 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -172,22 +172,6 @@ static void fw_domains_get_with_thread_status(struct 
drm_i915_private *dev_priv,
__gen6_gt_wait_for_thread_c0(dev_priv);
 }
 
-static void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv)
-{
-   u32 gtfifodbg;
-
-   gtfifodbg = __raw_i915_read32(dev_priv, GTFIFODBG);
-   if (WARN(gtfifodbg, "GT wake FIFO error 0x%x\n", gtfifodbg))
-   __raw_i915_write32(dev_priv, GTFIFODBG, gtfifodbg);
-}
-
-static void fw_domains_put_with_fifo(struct drm_i915_private *dev_priv,
-enum forcewake_domains fw_domains)
-{
-   fw_domains_put(dev_priv, fw_domains);
-   gen6_gt_check_fifodbg(dev_priv);
-}
-
 static inline u32 fifo_free_entries(struct drm_i915_private *dev_priv)
 {
u32 count = __raw_i915_read32(dev_priv, GTFIFOCTL);
@@ -384,15 +368,35 @@ vlv_check_for_unclaimed_mmio(struct drm_i915_private 
*dev_priv)
 }
 
 static bool
+gen6_check_for_fifo_debug(struct drm_i915_private *dev_priv)
+{
+   u32 fifodbg;
+
+   fifodbg = __raw_i915_read32(dev_priv, GTFIFODBG);
+
+   if (unlikely(fifodbg)) {
+   DRM_DEBUG_DRIVER("GTFIFODBG = 0x08%x\n", fifodbg);
+   __raw_i915_write32(dev_priv, GTFIFODBG, fifodbg);
+   }
+
+   return fifodbg;
+}
+
+static bool
 check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
 {
+   bool ret = false;
+
if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
-   return fpga_check_for_unclaimed_mmio(dev_priv);
+   ret |= fpga_check_for_unclaimed_mmio(dev_priv);
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
-   return vlv_check_for_unclaimed_mmio(dev_priv);
+   ret |= vlv_check_for_unclaimed_mmio(dev_priv);
 
-   return false;
+   if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv))
+   ret |= gen6_check_for_fifo_debug(dev_priv);
+
+   return ret;
 }
 
 static void __intel_uncore_early_sanitize(struct drm_i915_private *dev_priv,
@@ -404,11 +408,6 @@ static void __intel_uncore_early_sanitize(struct 
drm_i915_private *dev_priv,
if (check_for_unclaimed_mmio(dev_priv))
DRM_DEBUG("unclaimed mmio detected on uncore init, clearing\n");
 
-   /* clear out old GT FIFO errors */
-   if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv))
-   __raw_i915_write32(dev_priv, GTFIFODBG,
-  __raw_i915_read32(dev_priv, GTFIFODBG));
-
/* WaDisableShadowRegForCpd:chv */
if (IS_CHERRYVIEW(dev_priv)) {
__raw_i915_write32(dev_priv, GTFIFOCTL,
@@ -1047,15 +1046,10 @@ __gen2_write(32)
 #define __gen6_write(x) \
 static void \
 gen6_write##x(struct drm_i915_private *dev_priv, i915_reg_t reg, u##x val, 
bool trace) { \
-   u32 __fifo_ret = 0; \
GEN6_WRITE_HEADER; \
-   if (NEEDS_FORCE_WAKE(offset)) { \
-   __fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
-   } \
+   if (NEEDS_FORCE_WAKE(offset)) \
+   __gen6_gt_wait_for_fifo(dev_priv); \
__raw_i915_write##x(dev_priv, reg, val); \
-   if (unlikely(__fifo_ret)) { \
-   gen6_gt_check_fifodbg(dev_priv); \
-   } \
GEN6_WRITE_FOOTER; \
 }
 
@@ -1190,11 +1184,7 @@ static void intel_uncore_fw_domains_init(struct 
drm_i915_private *dev_priv)
   FORCEWAKE_MEDIA_GEN9, FORCEWAKE_ACK_MEDIA_GEN9);
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
dev_priv->uncore.funcs.force_wake_get = fw_domains_get;
-   if (!IS_CHERRYVIEW(dev_priv))
-   dev_priv->uncore.funcs.force_wake_put =
-   fw_domains_put_with_fifo;
-   else
-   dev_priv->uncore.funcs.force_wake_put = fw_domains_put;
+   dev_priv->uncore.funcs.force_wake_put = fw_domains_put;
fw_domain_init(dev_priv, FW_DOMAIN_ID_RENDER,
   FORCEWAKE_VLV, FORCEWAKE_ACK_VLV);
fw_domain_init(dev_priv, FW_DOMAIN_ID_MEDIA,
@@ -1202,11 +1192,7 @@ static void intel_uncore_fw_domains_init(struct 
drm_i915_private *dev_priv)
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {

Re: [Intel-gfx] [PATCH v14] drm/i915: Squash repeated awaits on the same fence

[Tvrtko Ursulin]

On 28/04/2017 20:02, Chris Wilson wrote:

Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment. (Tvrkto)
v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto)
v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves
v13: kselftests to investigate struct i915_syncmap itself (Tvrtko)
v14: Foray into ascii art graphs

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_gem.c|   1 +
 drivers/gpu/drm/i915/i915_gem.h|   2 +
 drivers/gpu/drm/i915/i915_gem_request.c|   9 +
 drivers/gpu/drm/i915/i915_gem_timeline.c   |  93 +++-
 drivers/gpu/drm/i915/i915_gem_timeline.h   |  38 ++
 drivers/gpu/drm/i915/i915_syncmap.c| 419 ++
 drivers/gpu/drm/i915/i915_syncmap.h|  39 ++
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 272 +
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_random.c   |  11 +
 drivers/gpu/drm/i915/selftests/i915_random.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 609 +
 drivers/gpu/drm/i915/selftests/mock_timeline.c |  45 ++
 drivers/gpu/drm/i915/selftests/mock_timeline.h |  33 ++
 15 files changed, 1558 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..7b05fb802f4c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
  i915_params.o \
  i915_pci.o \
   i915_suspend.o \
+ i915_syncmap.o \
  i915_sw_fence.o \
  i915_sysfs.o \
  intel_csr.o \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a7da9cdf6c39..0f8046e0a63c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3215,6 +3215,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
}
+   i915_gem_timelines_mark_idle(dev_priv);

GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5a49487368ca..ee54597465b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -25,6 +25,8 @@
 #ifndef __I915_GEM_H__
 #define __I915_GEM_H__

+#include 
+
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(expr) BUG_ON(expr)
 #define GEM_WARN_ON(expr) WARN_ON(expr)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 022f5588d906..637b8cddf988 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -773,6 +773,11 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
continue;

+   /* Squash repeated waits to the same timelines */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_is_later(req->timeline, fence))
+   continue;
+
if (dma_fence_is_i915(fence))
ret = i915_gem_request_await_request(req,
 

Re: [Intel-gfx] [RFC 2/4] drm/i915: Program RPCS for Broadwell

[Joonas Lahtinen]

On ti, 2017-05-02 at 12:49 +0100, Chris Wilson wrote:
> Currently we only configure the power gating for Skylake and above, but
> the configuration should equally apply to Broadwell and Braswell. Even
> though, there is not as much variation as for later generations, we want
> to expose control over the configuration to userspace and may want to
> opt out of the "always-enabled" setting.
> 
> Signed-off-by: Chris Wilson 

This craves for T-b's because it excercises new portions of HW.

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] ✓ Fi.CI.BAT: success for drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

[Joonas Lahtinen]

On pe, 2017-04-28 at 10:46 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Do not leak dev_priv->l3_parity.remap_info[]
> URL   : https://patchwork.freedesktop.org/series/23679/
> State : success

Merged the patch. Thanks for the review.

> == Summary ==
> 
> Series 23679v1 drm/i915: Do not leak dev_priv->l3_parity.remap_info[]
> https://patchwork.freedesktop.org/api/1.0/series/23679/revisions/1/mbox/
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:428s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:579s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:517s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time:558s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:497s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:479s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:412s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:401s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:414s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:495s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:466s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:460s
> fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
> time:574s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:450s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:570s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:466s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:496s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:430s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:531s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time:407s
> fi-bdw-gvtdvm failed to collect. IGT log at 
> Patchwork_4574/fi-bdw-gvtdvm/igt.log
> 
> 86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s 
> UTC integration manifest
> 38aca2b drm/i915: Do not leak dev_priv->l3_parity.remap_info[]
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4574/
-- 
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] [RFC 1/4] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

[Joonas Lahtinen]

On ti, 2017-05-02 at 12:49 +0100, Chris Wilson wrote:
> When we query the available eu on each subslice, we currently only
> report the max. It would also be useful to report the minimum found as
> well.
> 
> When we set RPCS (power gating over the EU), we can also specify both
> the min and max number of eu to configure on each slice; currently we
> just set it to a single value, but the flexibility may be beneficial in
> future.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/4] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/4] drm/i915: Record both min/max 
eu_per_subslice in sseu_dev_info
URL   : https://patchwork.freedesktop.org/series/23802/
State : success

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:509s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:561s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:403s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:410s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:566s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:577s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:460s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:485s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:401s

0d90375e6d38f986224e4dfce1674c5b093590cc drm-tip: 2017y-05m-02d-09h-11m-43s UTC 
integration manifest
b39d79e drm/i915: Record the sseu configuration per-context
4f22f59 drm/i915: Program RPCS for Broadwell
0c72600 drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

== Logs ==

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

Re: [Intel-gfx] [CI 1/2] drm/i915/guc: Enable send function only after successful init

[Chris Wilson]

On Tue, May 02, 2017 at 10:32:42AM +, Michal Wajdeczko wrote:
> It is safer to setup valid send function after successful GuC
> hardware initialization. In addition we prepare placeholder
> where we can setup any alternate GuC communication mechanism.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Joonas Lahtinen 
> Cc: Daniele Ceraolo Spurio 
> Reviewed-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_uc.c | 27 ++-
>  drivers/gpu/drm/i915/intel_uc.h |  1 +
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index 900e376..5957a95 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -99,7 +99,7 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
>   struct intel_guc *guc = _priv->guc;
>  
>   mutex_init(>send_mutex);
> - guc->send = intel_guc_send_mmio;
> + guc->send = intel_guc_send_nop;
>  }
>  
>  static void fetch_uc_fw(struct drm_i915_private *dev_priv,
> @@ -252,13 +252,27 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
>   __intel_uc_fw_fini(_priv->huc.fw);
>  }
>  
> +static int guc_enable_communication(struct intel_guc *guc)
> +{
> + /* XXX: placeholder for alternate setup */
> + guc->send = intel_guc_send_mmio;
> + return 0;
> +}
> +
> +static void guc_disable_communication(struct intel_guc *guc)
> +{
> + guc->send = intel_guc_send_nop;
> +}
> +
>  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
>  {
> + struct intel_guc *guc = _priv->guc;
>   int ret, attempts;
>  
>   if (!i915.enable_guc_loading)
>   return 0;
>  
> + guc_disable_communication(guc);
>   gen9_reset_guc_interrupts(dev_priv);
>  
>   /* We need to notify the guc whenever we change the GGTT */
> @@ -308,6 +322,10 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
>   if (ret)
>   goto err_submission;
>  
> + ret = guc_enable_communication(guc);
> + if (ret)
> + goto err_submission;
> +
>   intel_guc_auth_huc(dev_priv);
>   if (i915.enable_guc_submission) {
>   if (i915.guc_log_level >= 0)
> @@ -330,6 +348,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
>* marks the GPU as wedged until reset).
>*/
>  err_interrupts:
> + guc_disable_communication(guc);
>   gen9_disable_guc_interrupts(dev_priv);
>  err_submission:
>   if (i915.enable_guc_submission)
> @@ -364,6 +383,12 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
>   i915_ggtt_disable_guc(dev_priv);
>  }
>  
> +int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len)
> +{
> + WARN(1, "Unexpected send: action=%#x\n", *action);
> + return -ENOSYS;

For internal errors we use -ENODEV.

I fixed that whilst applying as I'm sure no one else but checkpatch
cares for a path that should never occur.

Applied and pushed, thanks for the patch and review.
-Chris

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

[Intel-gfx] [PATCH v4 2/2] drm/i915: Prevent the system suspend complete optimization

[Imre Deak]

Since

commit bac2a909a096c9110525c18cbb8ce73c660d5f71
Author: Rafael J. Wysocki 
Date:   Wed Jan 21 02:17:42 2015 +0100

PCI / PM: Avoid resuming PCI devices during system suspend

PCI devices will default to allowing the system suspend complete
optimization where devices are not woken up during system suspend if
they were already runtime suspended. This however breaks the i915/HDA
drivers for two reasons:

- The i915 driver has system suspend specific steps that it needs to
  run, that bring the device to a different state than its runtime
  suspended state.

- The HDA driver's suspend handler requires power that it will request
  from the i915 driver's power domain handler. This in turn requires the
  i915 driver to runtime resume itself, but this won't be possible if the
  suspend complete optimization is in effect: in this case the i915
  runtime PM is disabled and trying to get an RPM reference returns
  -EACCESS.

Solve this by requiring the PCI/PM core to resume the device during
system suspend which in effect disables the suspend complete optimization.

Regardless of the above commit the optimization stayed disabled for DRM
devices until

commit d14d2a8453d650bea32a1c5271af1458cd283a0f
Author: Lukas Wunner 
Date:   Wed Jun 8 12:49:29 2016 +0200

drm: Remove dev_pm_ops from drm_class

so this patch is in practice a fix for this commit. Another reason for
the bug staying hidden for so long is that the optimization for a device
is disabled if it's disabled for any of its children devices. i915 may
have a backlight device as its child which doesn't support runtime PM
and so doesn't allow the optimization either.  So if this backlight
device got registered the bug stayed hidden.

Credits to Marta, Tomi and David who enabled pstore logging,
that caught one instance of this issue across a suspend/
resume-to-ram and Ville who rememberd that the optimization was enabled
for some devices at one point.

The first WARN triggered by the problem:

[ 6250.746445] WARNING: CPU: 2 PID: 17384 at 
drivers/gpu/drm/i915/intel_runtime_pm.c:2846 intel_runtime_pm_get+0x6b/0xd0 
[i915]
[ 6250.746448] pm_runtime_get_sync() failed: -13
[ 6250.746451] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul
snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel e1000e 
snd_hda_codec snd_hwdep snd_hda_core ptp mei_me pps_core snd_pcm lpc_ich mei 
prime_
numbers i2c_hid i2c_designware_platform i2c_designware_core [last unloaded: 
i915]
[ 6250.746512] CPU: 2 PID: 17384 Comm: kworker/u8:0 Tainted: G U  W   
4.11.0-rc5-CI-CI_DRM_334+ #1
[ 6250.746515] Hardware name:  /NUC5i5RYB, BIOS 
RYBDWi35.86A.0362.2017.0118.0940 01/18/2017
[ 6250.746521] Workqueue: events_unbound async_run_entry_fn
[ 6250.746525] Call Trace:
[ 6250.746530]  dump_stack+0x67/0x92
[ 6250.746536]  __warn+0xc6/0xe0
[ 6250.746542]  ? pci_restore_standard_config+0x40/0x40
[ 6250.746546]  warn_slowpath_fmt+0x46/0x50
[ 6250.746553]  ? __pm_runtime_resume+0x56/0x80
[ 6250.746584]  intel_runtime_pm_get+0x6b/0xd0 [i915]
[ 6250.746610]  intel_display_power_get+0x1b/0x40 [i915]
[ 6250.746646]  i915_audio_component_get_power+0x15/0x20 [i915]
[ 6250.746654]  snd_hdac_display_power+0xc8/0x110 [snd_hda_core]
[ 6250.746661]  azx_runtime_resume+0x218/0x280 [snd_hda_intel]
[ 6250.746667]  pci_pm_runtime_resume+0x76/0xa0
[ 6250.746672]  __rpm_callback+0xb4/0x1f0
[ 6250.746677]  ? pci_restore_standard_config+0x40/0x40
[ 6250.746682]  rpm_callback+0x1f/0x80
[ 6250.746686]  ? pci_restore_standard_config+0x40/0x40
[ 6250.746690]  rpm_resume+0x4ba/0x740
[ 6250.746698]  __pm_runtime_resume+0x49/0x80
[ 6250.746703]  pci_pm_suspend+0x57/0x140
[ 6250.746709]  dpm_run_callback+0x6f/0x330
[ 6250.746713]  ? pci_pm_freeze+0xe0/0xe0
[ 6250.746718]  __device_suspend+0xf9/0x370
[ 6250.746724]  ? dpm_watchdog_set+0x60/0x60
[ 6250.746730]  async_suspend+0x1a/0x90
[ 6250.746735]  async_run_entry_fn+0x34/0x160
[ 6250.746741]  process_one_work+0x1f2/0x6d0
[ 6250.746749]  worker_thread+0x49/0x4a0
[ 6250.746755]  kthread+0x107/0x140
[ 6250.746759]  ? process_one_work+0x6d0/0x6d0
[ 6250.746763]  ? kthread_create_on_node+0x40/0x40
[ 6250.746768]  ret_from_fork+0x2e/0x40
[ 6250.746778] ---[ end trace 102a62fd2160f5e6 ]---

v2:
- Use the new pci_dev->needs_resume flag, to avoid any overhead during
  the ->pm_prepare hook. (Rafael)

v3:
- Update commit message to reference the actual regressing commit.
  (Lukas)

v4:
- Rebase on v4 of patch 1/2.

Fixes: d14d2a8453d6 ("drm: Remove dev_pm_ops from drm_class")
References: https://bugs.freedesktop.org/show_bug.cgi?id=100378
References: https://bugs.freedesktop.org/show_bug.cgi?id=100770
Cc: Rafael J. Wysocki 
Cc: Marta Lofstedt 
Cc: David Weinehall 
Cc: Tomi Sarvela 
Cc: Ville 

[Intel-gfx] [PATCH v4 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Imre Deak]

Some drivers - like i915 - may not support the system suspend direct
complete optimization due to differences in their runtime and system
suspend sequence. Add a flag that when set resumes the device before
calling the driver's system suspend handlers which effectively disables
the optimization.

Needed by the next patch fixing suspend/resume on i915.

Suggested by Rafael.

v2-v3:
- unchanged

v4:
- Move the flag to dev_flags instead of using a bit field. (Rafael)

Cc: Rafael J. Wysocki 
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Imre Deak 
Acked-by: Rafael J. Wysocki  (v3)
---
 drivers/pci/pci.c   | 3 ++-
 include/linux/pci.h | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7904d02..a4ef755 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2141,7 +2141,8 @@ bool pci_dev_keep_suspended(struct pci_dev *pci_dev)
 
if (!pm_runtime_suspended(dev)
|| pci_target_state(pci_dev) != pci_dev->current_state
-   || platform_pci_need_resume(pci_dev))
+   || platform_pci_need_resume(pci_dev)
+   || (pci_dev->dev_flags & PCI_DEV_FLAGS_NEEDS_RESUME))
return false;
 
/*
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5948cfd..8acb560 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -178,6 +178,11 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
/* Get VPD from function 0 VPD */
PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
+   /*
+* Resume before calling the driver's system suspend hooks, disabling
+* the direct_complete optimization.
+*/
+   PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 9),
 };
 
 enum pci_irq_reroute_variant {
-- 
2.7.4

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

[Intel-gfx] [RFC 3/4] drm/i915: Record the sseu configuration per-context

[Chris Wilson]

In the next patch, we will expose the ability to reconfigure the slices,
subslice and eu per context. To facilitate that, store the current
configuration on the context, which is initially set to the device
default upon creation.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h | 19 ---
 drivers/gpu/drm/i915/i915_gem_context.c |  3 +++
 drivers/gpu/drm/i915/i915_gem_context.h | 22 ++
 drivers/gpu/drm/i915/intel_lrc.c| 23 +--
 4 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b69fc8fb0c8..a8a622078849 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -840,25 +840,6 @@ struct intel_csr {
func(overlay_needs_physical); \
func(supports_tv);
 
-struct sseu_dev_info {
-   u8 slice_mask;
-   u8 subslice_mask;
-   u8 eu_total;
-   u8 min_eu_per_subslice;
-   u8 max_eu_per_subslice;
-   u8 min_eu_in_pool;
-   /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
-   u8 subslice_7eu[3];
-   u8 has_slice_pg:1;
-   u8 has_subslice_pg:1;
-   u8 has_eu_pg:1;
-};
-
-static inline unsigned int sseu_subslice_total(const struct sseu_dev_info 
*sseu)
-{
-   return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
-}
-
 /* Keep in gen based order, and chronological order within a gen */
 enum intel_platform {
INTEL_PLATFORM_UNINITIALIZED = 0,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 612d1045f90a..71ca74bcf170 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -308,6 +308,9 @@ __create_hw_context(struct drm_i915_private *dev_priv,
 * is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
 
+   /* Use the whole device by default */
+   ctx->sseu = INTEL_INFO(dev_priv)->sseu;
+
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 82c99ba92ad3..7c07791e804e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -39,6 +39,25 @@ struct i915_hw_ppgtt;
 struct i915_vma;
 struct intel_ring;
 
+struct sseu_dev_info {
+   u8 slice_mask;
+   u8 subslice_mask;
+   u8 eu_total;
+   u8 min_eu_per_subslice;
+   u8 max_eu_per_subslice;
+   u8 min_eu_in_pool;
+   /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
+   u8 subslice_7eu[3];
+   u8 has_slice_pg:1;
+   u8 has_subslice_pg:1;
+   u8 has_eu_pg:1;
+};
+
+static inline unsigned int sseu_subslice_total(const struct sseu_dev_info 
*sseu)
+{
+   return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
+}
+
 #define DEFAULT_CONTEXT_HANDLE 0
 
 /**
@@ -199,6 +218,9 @@ struct i915_gem_context {
 
/** remap_slice: Bitmask of cache lines that need remapping */
u8 remap_slice;
+
+   /** sseu: Control eu/slice partitioning */
+   struct sseu_dev_info sseu;
 };
 
 static inline bool i915_gem_context_is_closed(const struct i915_gem_context 
*ctx)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9add516d66c2..a3183298b993 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1798,8 +1798,7 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
 }
 
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu)
 {
u32 rpcs = 0;
 
@@ -1809,25 +1808,21 @@ make_rpcs(struct drm_i915_private *dev_priv)
 * must make an explicit request through RPCS for full
 * enablement.
*/
-   if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+   if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
-   rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
-   GEN8_RPCS_S_CNT_SHIFT;
+   rpcs |= hweight8(sseu->slice_mask) << GEN8_RPCS_S_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
 
-   if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+   if (sseu->has_subslice_pg) {
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
-   rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask) <<
-   GEN8_RPCS_SS_CNT_SHIFT;
+   rpcs |= hweight8(sseu->subslice_mask) << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
 
-   if (INTEL_INFO(dev_priv)->sseu.has_eu_pg) {
-   rpcs |= INTEL_INFO(dev_priv)->sseu.min_eu_per_subslice <<
-   

[Intel-gfx] [RFC 2/4] drm/i915: Program RPCS for Broadwell

[Chris Wilson]

Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 45c187abf10a..9add516d66c2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1804,13 +1804,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
u32 rpcs = 0;
 
/*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
-   */
-   if (INTEL_GEN(dev_priv) < 9)
-   return 0;
-
-   /*
 * Starting in Gen9, render power gating can leave
 * slice/subslice/EU in a partially enabled state. We
 * must make an explicit request through RPCS for full
-- 
2.11.0

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

[Intel-gfx] [RFC 1/4] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

[Chris Wilson]

When we query the available eu on each subslice, we currently only
report the max. It would also be useful to report the minimum found as
well.

When we set RPCS (power gating over the EU), we can also specify both
the min and max number of eu to configure on each slice; currently we
just set it to a single value, but the flexibility may be beneficial in
future.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 36 +++-
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/intel_device_info.c | 32 +---
 drivers/gpu/drm/i915/intel_lrc.c |  4 ++--
 4 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2472048b84d..e15c4609375e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4480,6 +4480,7 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_cache_sharing_fops,
 static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv,
  struct sseu_dev_info *sseu)
 {
+   unsigned int min_eu_per_subslice, max_eu_per_subslice;
int ss_max = 2;
int ss;
u32 sig1[ss_max], sig2[ss_max];
@@ -4489,6 +4490,9 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
sig2[0] = I915_READ(CHV_POWER_SS0_SIG2);
sig2[1] = I915_READ(CHV_POWER_SS1_SIG2);
 
+   min_eu_per_subslice = ~0u;
+   max_eu_per_subslice = 0;
+
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
 
@@ -4503,14 +4507,18 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
 ((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
sseu->eu_total += eu_cnt;
-   sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice, eu_cnt);
+   min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+   max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
+
+   sseu->min_eu_per_subslice = min_eu_per_subslice;
+   sseu->max_eu_per_subslice = max_eu_per_subslice;
 }
 
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
+   unsigned int min_eu_per_subslice, max_eu_per_subslice;
int s_max = 3, ss_max = 4;
int s, ss;
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
@@ -4536,6 +4544,9 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
+   min_eu_per_subslice = ~0u;
+   max_eu_per_subslice = 0;
+
for (s = 0; s < s_max; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
@@ -4561,11 +4572,14 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
   eu_mask[ss%2]);
sseu->eu_total += eu_cnt;
-   sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice,
- eu_cnt);
+
+   min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+   max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
}
+
+   sseu->min_eu_per_subslice = min_eu_per_subslice;
+   sseu->max_eu_per_subslice = max_eu_per_subslice;
 }
 
 static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv,
@@ -4578,9 +4592,11 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
 
if (sseu->slice_mask) {
sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
-   sseu->eu_per_subslice =
-   INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
-   sseu->eu_total = sseu->eu_per_subslice *
+   sseu->min_eu_per_subslice =
+   INTEL_INFO(dev_priv)->sseu.min_eu_per_subslice;
+   sseu->max_eu_per_subslice =
+   INTEL_INFO(dev_priv)->sseu.max_eu_per_subslice;
+   sseu->eu_total = sseu->max_eu_per_subslice *
 sseu_subslice_total(sseu);
 
/* subtract fused off EU(s) from enabled slice(s) */
@@ -4611,8 +4627,8 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
   hweight8(sseu->subslice_mask));
seq_printf(m, "  %s EU Total: %u\n", type,
   

[Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Chris Wilson]

We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.

The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.

We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,

struct drm_i915_gem_context_param arg;

memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
union drm_i915_gem_context_param_sseu *sseu = 

sseu->packed.subslice_mask = 0;

drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}

could be used to disable all subslices where supported.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson 
Cc: Dmitry Rogozhkin 
CC: Tvrtko Ursulin 
CC: Zhipeng Gong 
CC: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 12 +++
 drivers/gpu/drm/i915/intel_lrc.c| 63 +
 drivers/gpu/drm/i915/intel_lrc.h|  3 ++
 include/uapi/drm/i915_drm.h | 11 ++
 4 files changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 71ca74bcf170..0b72f9f62ddb 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1044,6 +1044,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->priority;
break;
+   case I915_CONTEXT_PARAM_SSEU:
+   args->value = intel_lr_context_get_sseu(ctx);
+   break;
default:
ret = -EINVAL;
break;
@@ -1120,6 +1123,15 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
}
break;
 
+   case I915_CONTEXT_PARAM_SSEU:
+   if (args->size)
+   ret = -EINVAL;
+   else if (!i915.enable_execlists)
+   ret = -ENODEV;
+   else
+   ret = intel_lr_context_set_sseu(ctx, args->value);
+   break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a3183298b993..e4e2eefd4854 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2064,3 +2064,66 @@ void intel_lr_context_resume(struct drm_i915_private 
*dev_priv)
}
}
 }
+
+int intel_lr_context_set_sseu(struct i915_gem_context *ctx, u64 value)
+{
+   union drm_i915_gem_context_param_sseu user = { .value = value };
+   struct drm_i915_private *i915 = ctx->i915;
+   struct intel_context *ce = >engine[RCS];
+   struct sseu_dev_info sseu = ctx->sseu;
+   int ret;
+
+   lockdep_assert_held(>drm.struct_mutex);
+
+   sseu.slice_mask =
+   user.packed.slice_mask & INTEL_INFO(i915)->sseu.slice_mask;
+   sseu.subslice_mask =
+   user.packed.subslice_mask & 
INTEL_INFO(i915)->sseu.subslice_mask;
+   sseu.min_eu_per_subslice =
+   max(user.packed.min_eu_per_subslice,
+   INTEL_INFO(i915)->sseu.min_eu_per_subslice);
+   sseu.max_eu_per_subslice =
+   min(user.packed.max_eu_per_subslice,
+   INTEL_INFO(i915)->sseu.max_eu_per_subslice);
+
+   if (memcmp(, >sseu, sizeof(sseu)) == 0)
+   return 0;
+
+   if (ce->pin_count) { /* Assume that the context is active! */
+   ret = i915_gem_switch_to_kernel_context(i915);
+   if (ret)
+   return ret;
+
+   ret = i915_gem_wait_for_idle(i915,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED);
+   if (ret)
+   return ret;
+   }
+
+   if (ce->state) {
+   u32 *regs;
+
+   regs = 

Re: [Intel-gfx] [PATCH v6 02/12] drm/atomic: Add support for custom scaling mode properties, v2

[Maarten Lankhorst]

Op 02-05-17 om 11:44 schreef Daniel Vetter:
> On Mon, May 01, 2017 at 03:37:54PM +0200, Maarten Lankhorst wrote:
>> Some connectors may not allow all scaling mode properties, this function 
>> will allow
>> creating the scaling mode property with only the supported subset. It also 
>> wires up
>> this state for atomic.
>>
>> This will make it possible to convert i915 connectors to atomic.
>>
>> Changes since v1:
>>  - Add DRM_MODE_PROP_ENUM flag to drm_property_create
>>  - Use the correct index in drm_property_add_enum.
>>  - Add DocBook for function (Sean Paul).
>>  - Warn if less than 2 valid scaling modes are passed.
>>  - Remove level of indent. (Sean Paul)
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic.c|  4 +++
>>  drivers/gpu/drm/drm_connector.c | 58 
>> +
>>  include/drm/drm_connector.h | 10 +++
>>  3 files changed, 72 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 77bb36e956db..c7f91dcebbe9 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -1125,6 +1125,8 @@ int drm_atomic_connector_set_property(struct 
>> drm_connector *connector,
>>  state->link_status = val;
>>  } else if (property == config->aspect_ratio_property) {
>>  state->picture_aspect_ratio = val;
>> +} else if (property == connector->scaling_mode_property) {
>> +state->scaling_mode = val;
> Can't we still handle mode_config->scaling_mode_property as fallback?
> Seems a lot more consistent to me ...
>
>>  } else if (connector->funcs->atomic_set_property) {
>>  return connector->funcs->atomic_set_property(connector,
>>  state, property, val);
>> @@ -1203,6 +1205,8 @@ drm_atomic_connector_get_property(struct drm_connector 
>> *connector,
>>  *val = state->link_status;
>>  } else if (property == config->aspect_ratio_property) {
>>  *val = state->picture_aspect_ratio;
>> +} else if (property == connector->scaling_mode_property) {
>> +*val = state->scaling_mode;
>>  } else if (connector->funcs->atomic_get_property) {
>>  return connector->funcs->atomic_get_property(connector,
>>  state, property, val);
>> diff --git a/drivers/gpu/drm/drm_connector.c 
>> b/drivers/gpu/drm/drm_connector.c
>> index 9f847615ac74..b3912f2e48c6 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -961,6 +961,64 @@ int drm_mode_create_scaling_mode_property(struct 
>> drm_device *dev)
>>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>>  
>>  /**
>> + * drm_mode_connector_attach_scaling_mode_property - attach atomic scaling 
>> mode property
>> + * @connector: connector to attach scaling mode property on.
>> + * @scaling_mode_mask: or'ed mask of BIT(DRM_MODE_SCALE_\*).
>> + *
>> + * This is used to add support for scaling mode to atomic drivers.
>> + * The scaling mode will be set to  
>> drm_connector_state->picture_aspect_ratio
> s/->/./ to get a real link
>
>> + * and can be used from  drm_connector_helper_funcs->atomic_check 
>> for validation.
> Same here, plus needs &.
>
> Please check the html output when typing docs ...
>
> Also please link to drm_mode_create_scaling_mode_property() and from the
> kerneldoc of that to this one here.
Ah right, thanks.
>
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_mode_connector_attach_scaling_mode_property(struct drm_connector 
>> *connector,
>> +u32 scaling_mode_mask)
> Usual prefix is just drm_connector_ (yes I know we're not consistent here,
> yet).
>
> With those nits: Reviewed-by: Daniel Vetter 
>
Will rename. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/guc: Enable send function only after successful init

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/guc: Enable send function only 
after successful init
URL   : https://patchwork.freedesktop.org/series/23799/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:436s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:428s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:574s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:527s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:478s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:403s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:483s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:453s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:555s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:438s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:559s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:484s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:413s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:402s

0d90375e6d38f986224e4dfce1674c5b093590cc drm-tip: 2017y-05m-02d-09h-11m-43s UTC 
integration manifest
ebc37af HAX Enable GuC loading & submission
66bb87c drm/i915/guc: Enable send function only after successful init

== Logs ==

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

[Intel-gfx] [CI 1/2] drm/i915/guc: Enable send function only after successful init

[Michal Wajdeczko]

It is safer to setup valid send function after successful GuC
hardware initialization. In addition we prepare placeholder
where we can setup any alternate GuC communication mechanism.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_uc.c | 27 ++-
 drivers/gpu/drm/i915/intel_uc.h |  1 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 900e376..5957a95 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -99,7 +99,7 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
struct intel_guc *guc = _priv->guc;
 
mutex_init(>send_mutex);
-   guc->send = intel_guc_send_mmio;
+   guc->send = intel_guc_send_nop;
 }
 
 static void fetch_uc_fw(struct drm_i915_private *dev_priv,
@@ -252,13 +252,27 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
__intel_uc_fw_fini(_priv->huc.fw);
 }
 
+static int guc_enable_communication(struct intel_guc *guc)
+{
+   /* XXX: placeholder for alternate setup */
+   guc->send = intel_guc_send_mmio;
+   return 0;
+}
+
+static void guc_disable_communication(struct intel_guc *guc)
+{
+   guc->send = intel_guc_send_nop;
+}
+
 int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 {
+   struct intel_guc *guc = _priv->guc;
int ret, attempts;
 
if (!i915.enable_guc_loading)
return 0;
 
+   guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
 
/* We need to notify the guc whenever we change the GGTT */
@@ -308,6 +322,10 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_submission;
 
+   ret = guc_enable_communication(guc);
+   if (ret)
+   goto err_submission;
+
intel_guc_auth_huc(dev_priv);
if (i915.enable_guc_submission) {
if (i915.guc_log_level >= 0)
@@ -330,6 +348,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * marks the GPU as wedged until reset).
 */
 err_interrupts:
+   guc_disable_communication(guc);
gen9_disable_guc_interrupts(dev_priv);
 err_submission:
if (i915.enable_guc_submission)
@@ -364,6 +383,12 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
i915_ggtt_disable_guc(dev_priv);
 }
 
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len)
+{
+   WARN(1, "Unexpected send: action=%#x\n", *action);
+   return -ENOSYS;
+}
+
 /*
  * This function implements the MMIO based host to GuC interface.
  */
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 2f0229d..1e0eecd 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -227,6 +227,7 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
 int intel_guc_sample_forcewake(struct intel_guc *guc);
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len);
 int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
 static inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 
len)
 {
-- 
2.7.4

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

[Intel-gfx] [CI 2/2] HAX Enable GuC loading & submission

[Michal Wajdeczko]

This is just for CI testing, *** DO NOT MERGE ***

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..abd2894 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = 1,
+   .enable_guc_submission = 1,
.guc_log_level = -1,
.guc_firmware_path = NULL,
.huc_firmware_path = NULL,
@@ -221,12 +221,12 @@ MODULE_PARM_DESC(edp_vswing,
 module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
 MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto, 0=never, 1=if available [default], 2=required)");
 
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+   "(-1=auto, 0=never, 1=if available [default], 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
-- 
2.7.4

___
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/gvt: disable GVT-g if host GuC submission is enabled

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: disable GVT-g if host GuC submission is enabled
URL   : https://patchwork.freedesktop.org/series/23796/
State : success

== Summary ==

Series 23796v1 drm/i915/gvt: disable GVT-g if host GuC submission is enabled
https://patchwork.freedesktop.org/api/1.0/series/23796/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:434s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:424s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:575s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:509s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:543s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:481s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:459s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:565s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:457s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:567s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:457s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:499s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:407s

0d90375e6d38f986224e4dfce1674c5b093590cc drm-tip: 2017y-05m-02d-09h-11m-43s UTC 
integration manifest
94abe09 drm/i915/gvt: disable GVT-g if host GuC submission is enabled

== Logs ==

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

Re: [Intel-gfx] [PATCH v6 05/12] drm/i915: Add plumbing for digital connector state, v3.

[Daniel Vetter]

On Mon, May 01, 2017 at 03:37:57PM +0200, Maarten Lankhorst wrote:
> Some atomic properties are common between the various kinds of
> connectors, for example a lot of them use panel fitting mode.
> It makes sense to put a lot of it in a common place, so each
> connector can use it while they're being converted.
> 
> Implement the properties required for the connectors:
> - scaling mode property
> - force audio property
> - broadcast rgb
> - aspect ratio
> 
> While at it, make clear that intel_digital_connector_atomic_get_property
> is a hack that has to be removed when all connector properties
> are converted to atomic.
> 
> Changes since v1:
> - Scaling mode and aspect ratio are partly handled in core now.
> Changes since v2:
> - Split out the scaling mode / aspect ratio changes to a preparation
>   patch.
> - Use mode_changed for panel fitter, changes to this property
>   are checked by fastset.
> - Allowed_scaling_modes is removed, handled through core now.
> 
> Signed-off-by: Maarten Lankhorst 

Patches 3-5: Reviewed-by: Daniel Vetter 

Pls ping Dave for an Ack for getting the first 2 landed through drm-intel
(they'll still show up in the first pull request right after -rc1, so all
good imo).

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/intel_atomic.c  | 131 
> +--
>  drivers/gpu/drm/i915/intel_display.c |  14 +++-
>  drivers/gpu/drm/i915/intel_drv.h |  23 ++
>  3 files changed, 159 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 50fb1f76cc5f..182909f266f5 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -36,7 +36,7 @@
>  #include "intel_drv.h"
>  
>  /**
> - * intel_connector_atomic_get_property - fetch connector property value
> + * intel_connector_atomic_get_property - fetch legacy connector property 
> value
>   * @connector: connector to fetch property for
>   * @state: state containing the property value
>   * @property: property to look up
> @@ -45,12 +45,14 @@
>   * The DRM core does not store shadow copies of properties for
>   * atomic-capable drivers.  This entrypoint is used to fetch
>   * the current value of a driver-specific connector property.
> + *
> + * This is a intermediary solution until all connectors are
> + * converted to support full atomic properties.
>   */
> -int
> -intel_connector_atomic_get_property(struct drm_connector *connector,
> - const struct drm_connector_state *state,
> - struct drm_property *property,
> - uint64_t *val)
> +int intel_connector_atomic_get_property(struct drm_connector *connector,
> + const struct drm_connector_state *state,
> + struct drm_property *property,
> + uint64_t *val)
>  {
>   int i;
>  
> @@ -73,7 +75,122 @@ intel_connector_atomic_get_property(struct drm_connector 
> *connector,
>   return -EINVAL;
>  }
>  
> -/*
> +/**
> + * intel_digital_connector_atomic_get_property - hook for 
> connector->atomic_get_property.
> + * @connector: Connector to get the property for.
> + * @state: Connector state to retrieve the property from.
> + * @property: Property to retrieve.
> + * @val: Return value for the property.
> + *
> + * Returns the atomic property value for a digital connector.
> + */
> +int intel_digital_connector_atomic_get_property(struct drm_connector 
> *connector,
> + const struct 
> drm_connector_state *state,
> + struct drm_property *property,
> + uint64_t *val)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct intel_digital_connector_state *intel_conn_state =
> + to_intel_digital_connector_state(state);
> +
> + if (property == dev_priv->force_audio_property)
> + *val = intel_conn_state->force_audio;
> + else if (property == dev_priv->broadcast_rgb_property)
> + *val = intel_conn_state->broadcast_rgb;
> + else {
> + DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * intel_digital_connector_atomic_set_property - hook for 
> connector->atomic_set_property.
> + * @connector: Connector to set the property for.
> + * @state: Connector state to set the property on.
> + * @property: Property to set.
> + * @val: New value for the property.
> + *
> + * Sets the atomic property value for a digital connector.
> + */
> +int intel_digital_connector_atomic_set_property(struct drm_connector 
> *connector,
> +

Re: [Intel-gfx] [PATCH v6 01/12] drm/atomic: Handle picture_aspect_ratio in atomic core

[Daniel Vetter]

On Mon, May 01, 2017 at 03:37:53PM +0200, Maarten Lankhorst wrote:
> This is only used in i915, which had used its own non-taomic way to
> deal with the picture aspect ratio. Move selected aspect_ratio to
> atomic state and use the atomic state in the affected i915 connectors.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_atomic.c  |  4 
>  drivers/gpu/drm/i915/intel_drv.h  |  1 -
>  drivers/gpu/drm/i915/intel_hdmi.c | 18 +++---
>  drivers/gpu/drm/i915/intel_sdvo.c | 23 +++
>  include/drm/drm_connector.h   | 10 ++
>  5 files changed, 20 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 30229ab719c0..77bb36e956db 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1123,6 +1123,8 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>*/
>   if (state->link_status != DRM_LINK_STATUS_GOOD)
>   state->link_status = val;
> + } else if (property == config->aspect_ratio_property) {
> + state->picture_aspect_ratio = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1199,6 +1201,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->tv.hue;
>   } else if (property == config->link_status_property) {
>   *val = state->link_status;
> + } else if (property == config->aspect_ratio_property) {
> + *val = state->picture_aspect_ratio;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 54f3ff840812..d38fed78500b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -877,7 +877,6 @@ struct intel_hdmi {
>   bool has_audio;
>   enum hdmi_force_audio force_audio;
>   bool rgb_quant_range_selectable;
> - enum hdmi_picture_aspect aspect_ratio;
>   struct intel_connector *attached_connector;
>   void (*write_infoframe)(struct drm_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 52f0b2d5fad2..58d690393b29 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1408,7 +1408,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   }
>  
>   /* Set user selected PAR to incoming mode's member */
> - adjusted_mode->picture_aspect_ratio = intel_hdmi->aspect_ratio;
> + adjusted_mode->picture_aspect_ratio = conn_state->picture_aspect_ratio;
>  
>   pipe_config->lane_count = 4;
>  
> @@ -1654,19 +1654,7 @@ intel_hdmi_set_property(struct drm_connector 
> *connector,
>   }
>  
>   if (property == connector->dev->mode_config.aspect_ratio_property) {
> - switch (val) {
> - case DRM_MODE_PICTURE_ASPECT_NONE:
> - intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> - break;
> - case DRM_MODE_PICTURE_ASPECT_4_3:
> - intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_4_3;
> - break;
> - case DRM_MODE_PICTURE_ASPECT_16_9:
> - intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
> - break;
> - default:
> - return -EINVAL;
> - }
> + connector->state->picture_aspect_ratio = val;
>   goto done;
>   }
>  
> @@ -1828,7 +1816,7 @@ intel_hdmi_add_properties(struct intel_hdmi 
> *intel_hdmi, struct drm_connector *c
>   intel_attach_broadcast_rgb_property(connector);
>   intel_hdmi->color_range_auto = true;
>   intel_attach_aspect_ratio_property(connector);
> - intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  }
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 816a6f5a3fd9..ef6fa87b2f8a 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -107,11 +107,6 @@ struct intel_sdvo {
>   bool color_range_auto;
>  
>   /**
> -  * HDMI user specified aspect ratio
> -  */
> - enum hdmi_picture_aspect aspect_ratio;
> -
> - /**
>* This is set if we're going to treat the device as TV-out.
>*
>* While we have these nice 

Re: [Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

[Petri Latvala]

On Wed, Apr 19, 2017 at 01:01:47PM +0200, Arkadiusz Hiler wrote:
> Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
> guard, and the file itself was included unconditionally.

I see unconditional config.h inclusion in several other places,
is igt_chamelium.h the only file where it causes problems?


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

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Gerd Hoffmann]

On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote:
> +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char
> *buf,
> +   size_t count, loff_t *ppos, bool iswrite)
> +{
> +   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
> +   VFIO_PCI_NUM_REGIONS;
> +   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
> +   int fd;
> +
> +   if (pos >= vgpu->vdev.region[i].size || iswrite) {
> +   gvt_vgpu_err("invalid op or offset for Intel vgpu fd
> region\n");
> +   return -EINVAL;
> +   }
> +
> +   fd = anon_inode_getfd("gvtg", _vgpu_gvtg_ops, vgpu,
> +   O_RDWR | O_CLOEXEC);
> +   if (fd < 0) {
> +   gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd);
> +   return -EINVAL;
> +   }
> +
> +   count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
> +   memcpy(buf, , count);
> +
> +   return count;
> +}

Hmm, that looks like a rather strange way to return a file descriptor.

What is the reason to not use ioctls on the vfio file handle, like older
version of these patches did?

cheers,
  Gerd

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

Re: [Intel-gfx] [PATCH v6 02/12] drm/atomic: Add support for custom scaling mode properties, v2

[Daniel Vetter]

On Mon, May 01, 2017 at 03:37:54PM +0200, Maarten Lankhorst wrote:
> Some connectors may not allow all scaling mode properties, this function will 
> allow
> creating the scaling mode property with only the supported subset. It also 
> wires up
> this state for atomic.
> 
> This will make it possible to convert i915 connectors to atomic.
> 
> Changes since v1:
>  - Add DRM_MODE_PROP_ENUM flag to drm_property_create
>  - Use the correct index in drm_property_add_enum.
>  - Add DocBook for function (Sean Paul).
>  - Warn if less than 2 valid scaling modes are passed.
>  - Remove level of indent. (Sean Paul)
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic.c|  4 +++
>  drivers/gpu/drm/drm_connector.c | 58 
> +
>  include/drm/drm_connector.h | 10 +++
>  3 files changed, 72 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 77bb36e956db..c7f91dcebbe9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1125,6 +1125,8 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->link_status = val;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio = val;
> + } else if (property == connector->scaling_mode_property) {
> + state->scaling_mode = val;

Can't we still handle mode_config->scaling_mode_property as fallback?
Seems a lot more consistent to me ...

>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1203,6 +1205,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->link_status;
>   } else if (property == config->aspect_ratio_property) {
>   *val = state->picture_aspect_ratio;
> + } else if (property == connector->scaling_mode_property) {
> + *val = state->scaling_mode;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 9f847615ac74..b3912f2e48c6 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -961,6 +961,64 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
>  /**
> + * drm_mode_connector_attach_scaling_mode_property - attach atomic scaling 
> mode property
> + * @connector: connector to attach scaling mode property on.
> + * @scaling_mode_mask: or'ed mask of BIT(DRM_MODE_SCALE_\*).
> + *
> + * This is used to add support for scaling mode to atomic drivers.
> + * The scaling mode will be set to  
> drm_connector_state->picture_aspect_ratio

s/->/./ to get a real link

> + * and can be used from  drm_connector_helper_funcs->atomic_check for 
> validation.

Same here, plus needs &.

Please check the html output when typing docs ...

Also please link to drm_mode_create_scaling_mode_property() and from the
kerneldoc of that to this one here.

> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_connector_attach_scaling_mode_property(struct drm_connector 
> *connector,
> + u32 scaling_mode_mask)

Usual prefix is just drm_connector_ (yes I know we're not consistent here,
yet).

With those nits: Reviewed-by: Daniel Vetter 

> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *scaling_mode_property;
> + int i, j = 0;
> + const unsigned valid_scaling_mode_mask =
> + (1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
> +
> + if (WARN_ON(hweight32(scaling_mode_mask) < 2 ||
> + scaling_mode_mask & ~valid_scaling_mode_mask))
> + return -EINVAL;
> +
> + scaling_mode_property =
> + drm_property_create(dev, DRM_MODE_PROP_ENUM, "scaling mode",
> + hweight32(scaling_mode_mask));
> +
> + if (!scaling_mode_property)
> + return -ENOMEM;
> +
> + for (i = 0; i < ARRAY_SIZE(drm_scaling_mode_enum_list); i++) {
> + int ret;
> +
> + if (!(BIT(i) & scaling_mode_mask))
> + continue;
> +
> + ret = drm_property_add_enum(scaling_mode_property, j++,
> + drm_scaling_mode_enum_list[i].type,
> + drm_scaling_mode_enum_list[i].name);
> +
> + if (ret) {
> + drm_property_destroy(dev, scaling_mode_property);
> +
> + return ret;
> 

Re: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

[Gerd Hoffmann]

  Hi,

> > +#ifndef _GVT_DMABUF_H_
> > +#define _GVT_DMABUF_H_
> > +
> > +#define INTEL_VGPU_QUERY_DMABUF0
> > +#define INTEL_VGPU_GENERATE_DMABUF 1
> > +
> > +struct intel_vgpu_dmabuf {
> 
> This looks to be uapi. What's it doing here?

It is indeed, should go to include/uapi/

cheers,
  Gerd

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

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Daniel Vetter]

On Tue, May 2, 2017 at 10:55 AM, Arnd Bergmann  wrote:
> On Tue, May 2, 2017 at 10:41 AM, Stephen Rothwell  
> wrote:
>> Hi Daniel,
>>
>> On Tue, 2 May 2017 10:25:18 +0200 Daniel Vetter  wrote:
>>>
>>> Since this is an all-new driver it might be best to stagger the pull
>>> requests and merge the new tee subsystem (or whatever it is) after drm?
>>>
>>> Not sure what to best do here ...
>>
>> This will merge via Dave, so Dave just needs to let Linus know that a
>> fix up is needed when this merges with the arm-soc stuff in Linus' tree.
>
> The TEE subsystem is currently on a separate branch by itself in arm-soc,
> so we could easily delay that until DRM is in, and point out the resolution
> here.

Dave is somewhere without mail, but I chatted with him quickly and he
agrees this seems simplest. drm-next main pull should go out somewhere
tomorrow he said.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

[Mika Kuoppala]

Chris Wilson  writes:

> On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote:
>> The new batchbuffer for CNL surpasses the 4096 byte mark.
>> 
>> Cc: Mika Kuoppala 
>> Cc: Ben Widawsky 
>> Signed-off-by: Oscar Mateo 
>
> Evil, 4k+ of nothing-ness that userspace then has to configure for itself
> for correctness anyway.
>
> Patch looks ok, but still question the sanity.

Is there a requirement for CNL to init the renderstate?

I would like to drop the render state init from CNL if
we can't find evidence that it needs it. Bspec indicates
that it doesnt.

-Mika

> -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 v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

[Imre Deak]

On Mon, May 01, 2017 at 10:36:13PM +0200, Rafael J. Wysocki wrote:
> On Sunday, April 30, 2017 03:57:13 PM Imre Deak wrote:
> > On Sat, Apr 29, 2017 at 12:21:57PM +0200, Rafael J. Wysocki wrote:
> > > On Friday, April 28, 2017 11:33:02 PM Rafael J. Wysocki wrote:
> > > > On Friday, April 28, 2017 05:16:02 PM Imre Deak wrote:
> > > > > Some drivers - like i915 - may not support the system suspend direct
> > > > > complete optimization due to differences in their runtime and system
> > > > > suspend sequence. Add a flag that when set resumes the device before
> > > > > calling the driver's system suspend handlers which effectively 
> > > > > disables
> > > > > the optimization.
> > > > > 
> > > > > Needed by the next patch fixing suspend/resume on i915.
> > > > > 
> > > > > Suggested by Rafael.
> > > > > 
> > > > > Cc: Rafael J. Wysocki 
> > > > > Cc: Bjorn Helgaas 
> > > > > Cc: linux-...@vger.kernel.org
> > > > > Cc: sta...@vger.kernel.org
> > > > > Signed-off-by: Imre Deak 
> > > > 
> > > > Acked-by: Rafael J. Wysocki 
> > > > 
> > > > The reason why the opt-out flag was not added on day one was because we 
> > > > were
> > > > not sure whether or not it would be necessary at all.
> > > > 
> > > > Quite evidently, it is needed.
> > > 
> > > But that said, it actually can be implemented as a flag in dev_flags too, 
> > > say
> > > PCI_DEV_FLAGS_NEEDS_RESUME, in analogy with PCI_DEV_FLAGS_NO_D3 that's
> > > already there.
> > > 
> > > The struct size would not need to grow then which I guess would be better?
> > 
> > Hm, both the bit field and the flag would need to increase if running
> > out of bits, so what's the difference? (Atm, the struct size wouldn't
> > change either way.)
> 
> In the bit field case this depends on what the compiler thinks is better to be
> entirely precise, so they are not 100% equivalent.
> 
> Plus, since there already are things related to PM in dev_flags, why to depart
> from that pattern?

There are a few PM related flags in the bit field too.

The need for moving it is still not clear to me, but I don't see any
problem with it either, so will move it there.

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