[Intel-gfx] [PATCH] drm/i915/gvt: Fix workload status after wait

[Zhenyu Wang]

From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting
was changed to only capture on error path, but we need to set it properly in
normal path too, otherwise we'll fail to complete workload which could lead
guest VM vGPU reset.

Cc: Chris Wilson 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 18acb45..bc4c14a 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -455,7 +455,8 @@ static int workload_thread(void *priv)
if (lret < 0) {
workload->status = lret;
gvt_err("fail to wait workload, skip\n");
-   }
+   } else
+   workload->status = 0;
 
 complete:
gvt_dbg_sched("will complete workload %p\n, status: %d\n",
-- 
2.10.2

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Set the Z inversion overlap field

[Patchwork]

== Series Details ==

Series: drm/i915: Set the Z inversion overlap field
URL   : https://patchwork.freedesktop.org/series/14704/
State : warning

== Summary ==

Series 14704v1 drm/i915: Set the Z inversion overlap field
https://patchwork.freedesktop.org/api/1.0/series/14704/revisions/1/mbox/

Test kms_busy:
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:181  dwarn:6   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 
2016y-11m-01d-16h-36m-25s UTC integration manifest
138d57c drm/i915: Set the Z inversion overlap field

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Set the Z inversion overlap field

[Deepak M]

Dual link Z-inversion overlap field is present
in MIPI_CTRL register unlike the older platforms,
hence setting the same in this patch.

Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++
 drivers/gpu/drm/i915/intel_dsi.c | 17 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bdc7b35..7a79dd1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8350,6 +8350,8 @@ enum {
 #define _MIPIA_CTRL(dev_priv->mipi_mmio_base + 0xb104)
 #define _MIPIC_CTRL(dev_priv->mipi_mmio_base + 0xb904)
 #define MIPI_CTRL(port)_MMIO_MIPI(port, _MIPIA_CTRL, 
_MIPIC_CTRL)
+#define  BXT_PIXEL_OVERLAP_CNT_MASK(0xf << 10)
+#define  BXT_PIXEL_OVERLAP_CNT_SHIFT   10
 #define  ESCAPE_CLOCK_DIVIDER_SHIFT5 /* A only */
 #define  ESCAPE_CLOCK_DIVIDER_MASK (3 << 5)
 #define  ESCAPE_CLOCK_DIVIDER_1(0 << 5)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 4e0d025..b1a4675 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -455,12 +455,21 @@ static void intel_dsi_port_enable(struct intel_encoder 
*encoder)
 
if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
u32 temp;
-
-   temp = I915_READ(VLV_CHICKEN_3);
-   temp &= ~PIXEL_OVERLAP_CNT_MASK |
+   if (IS_BROXTON(dev_priv)) {
+   for_each_dsi_port(port, intel_dsi->ports) {
+   temp = I915_READ(MIPI_CTRL(port));
+   temp &= ~BXT_PIXEL_OVERLAP_CNT_MASK |
+   intel_dsi->pixel_overlap <<
+   BXT_PIXEL_OVERLAP_CNT_SHIFT;
+   I915_WRITE(MIPI_CTRL(port), temp);
+   }
+   } else {
+   temp = I915_READ(VLV_CHICKEN_3);
+   temp &= ~PIXEL_OVERLAP_CNT_MASK |
intel_dsi->pixel_overlap <<
PIXEL_OVERLAP_CNT_SHIFT;
-   I915_WRITE(VLV_CHICKEN_3, temp);
+   I915_WRITE(VLV_CHICKEN_3, temp);
+   }
}
 
for_each_dsi_port(port, intel_dsi->ports) {
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Tue, Nov 01, 2016 at 12:34:37PM -0700, Manasi Navare wrote:
> On Tue, Nov 01, 2016 at 09:16:28PM +0200, Jani Nikula wrote:
> > On Tue, 01 Nov 2016, Manasi Navare  wrote:
> > > On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote:
> > >> On Sat, 29 Oct 2016, Manasi Navare  wrote:
> > >> > If link training at a link rate optimal for a particular
> > >> > mode fails during modeset's atomic commit phase, then we
> > >> > let the modeset complete and then retry. We save the link rate
> > >> > value at which link training failed, update the link status property
> > >> > to "BAD" and use a lower link rate to prune the modes. It will redo
> > >> > the modeset on the current mode at lower link rate or if the current
> > >> > mode gets pruned due to lower link constraints then, it will send a
> > >> > hotplug uevent for userspace to handle it.
> > >> >
> > >> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > >> > 4.3.1.6.
> > >> >
> > >> > v2:
> > >> > * Squashed a few patches (Jani Nikula)
> > >> >
> > >> > Cc: Jani Nikula 
> > >> > Cc: Daniel Vetter 
> > >> > Cc: Ville Syrjala 
> > >> > Signed-off-by: Manasi Navare 
> > >> > ---
> > >> >  drivers/gpu/drm/drm_atomic_helper.c   |  4 ++
> > >> >  drivers/gpu/drm/i915/intel_ddi.c  | 23 -
> > >> >  drivers/gpu/drm/i915/intel_dp.c   | 74 
> > >> > +--
> > >> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> > >> >  drivers/gpu/drm/i915/intel_drv.h  |  5 +-
> > >> >  5 files changed, 110 insertions(+), 8 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > >> > b/drivers/gpu/drm/drm_atomic_helper.c
> > >> > index 75ad01d..a3df3a4 100644
> > >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > >> > @@ -519,6 +519,10 @@ static int handle_conflicting_encoders(struct 
> > >> > drm_atomic_state *state,
> > >> >   connector_state);
> > >> >if (ret)
> > >> >return ret;
> > >> > +
> > >> > +  crtc_state = drm_atomic_get_existing_crtc_state(state, 
> > >> > connector->state->crtc);
> > >> > +  if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > >> > +  crtc_state->connectors_changed = true;
> > >> >}
> > >> >  
> > >> >/*
> > >> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > >> > b/drivers/gpu/drm/i915/intel_ddi.c
> > >> > index 938ac4d..319eeca 100644
> > >> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > >> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > >> > @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > >> > intel_encoder *encoder,
> > >> >struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > >> >struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > >> >enum port port = intel_ddi_get_encoder_port(encoder);
> > >> > +  struct intel_connector *intel_connector = 
> > >> > intel_dp->attached_connector;
> > >> > +  struct drm_connector *connector = _connector->base;
> > >> >  
> > >> >intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> > >> > link_mst);
> > >> > @@ -1694,7 +1696,26 @@ static void intel_ddi_pre_enable_dp(struct 
> > >> > intel_encoder *encoder,
> > >> >intel_prepare_dp_ddi_buffers(encoder);
> > >> >intel_ddi_init_dp_buf_reg(encoder);
> > >> >intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > >> > -  intel_dp_start_link_train(intel_dp);
> > >> > +  if (!intel_dp_start_link_train(intel_dp)) {
> > >> > +  DRM_DEBUG_KMS("Link Training failed at link rate = %d, 
> > >> > lane count = %d",
> > >> > +link_rate, lane_count);
> > >> > +  intel_dp->link_train_failed = true;
> > >> > +  intel_dp_get_link_train_fallback_values(intel_dp, 
> > >> > link_rate,
> > >> > +  lane_count);
> > >> > +  /* Schedule a Hotplug Uevent to userspace to start 
> > >> > modeset */
> > >> > +  schedule_work(_connector->modeset_retry_work);
> > >> 
> > >> This is not just about DDI. Need to do this for the other cases too.
> > >>
> > >
> > > Yes, first series will g out for adding this support for DDI, then more 
> > > patches
> > > to expand it to non DDI platforms.
> > >
> > >  
> > >> > +  } else {
> > >> > +  DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, 
> > >> > Lane count = %d",
> > >> > +link_rate, lane_count);
> > >> > +  intel_dp->link_train_failed = false;
> > >> > +  intel_dp->fallback_link_rate_index = -1;
> > >> > 

[Intel-gfx] [PATCH 2/2] aubdump: Bump GTT size to 128MB.

[Francisco Jerez]

You can easily run out of GTT space with the current fixed allocation
of 64MB.  Bump it to 128MB to avoid sporadic page-fault errors with
the simulator.
---
 tools/aubdump.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index d0774c1..80c9d1c 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -151,8 +151,8 @@ data_out(const void *data, size_t size)
 static uint32_t
 gtt_size(void)
 {
-   /* Enough for 64MB assuming 4kB pages. */
-   const unsigned entries = 0x4000;
+   /* Enough for 128MB assuming 4kB pages. */
+   const unsigned entries = 0x8000;
return entries * (gen >= 8 ? 8 : 4);
 }
 
-- 
2.10.1

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

[Intel-gfx] [PATCH 1/2] aubdump: Fix GTT setup for Gen8+.

[Francisco Jerez]

Gen8+ have 64 bit GTT entries, so we need to allocate twice as much
space for the GTT table in order to cover the same number of GTT
pages.  Fixes sporadic page-fault crashes on the simulator.
---
 tools/aubdump.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index 30dc742..d0774c1 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -54,7 +54,6 @@ static char *filename;
 static FILE *file;
 static int gen = 0;
 static int verbose = 0;
-static const uint32_t gtt_size = 0x1;
 static bool device_override;
 static uint32_t device;
 
@@ -149,9 +148,18 @@ data_out(const void *data, size_t size)
fwrite(data, 1, size, file);
 }
 
+static uint32_t
+gtt_size(void)
+{
+   /* Enough for 64MB assuming 4kB pages. */
+   const unsigned entries = 0x4000;
+   return entries * (gen >= 8 ? 8 : 4);
+}
+
 static void
 write_header(void)
 {
+   const unsigned gtt_entry_size = gen >= 8 ? 8 : 4;
uint32_t entry = 0x23;
 
/* Start with a (required) version packet. */
@@ -171,11 +179,14 @@ write_header(void)
  AUB_TRACE_TYPE_NOTYPE | AUB_TRACE_OP_DATA_WRITE);
dword_out(0); /* subtype */
dword_out(0); /* offset */
-   dword_out(gtt_size); /* size */
+   dword_out(gtt_size()); /* size */
if (gen >= 8)
dword_out(0);
-   for (uint32_t i = 0; i < gtt_size; i += 4, entry += 0x1000)
-   dword_out(entry);
+   for (uint32_t i = 0; i * gtt_entry_size < gtt_size(); i++) {
+   dword_out(entry + 0x1000 * i);
+   if (gen >= 8)
+   dword_out(0);
+   }
 }
 
 /**
@@ -332,7 +343,7 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 
*execbuffer2)
struct drm_i915_gem_exec_object2 *exec_objects =
(struct drm_i915_gem_exec_object2 *) (uintptr_t) 
execbuffer2->buffers_ptr;
uint32_t ring_flag = execbuffer2->flags & I915_EXEC_RING_MASK;
-   uint32_t offset = gtt_size;
+   uint32_t offset = gtt_size();
struct drm_i915_gem_exec_object2 *obj;
struct bo *bo, *batch_bo;
void *data;
-- 
2.10.1

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

Re: [Intel-gfx] [PATCH v3 i-g-t 1/2] tools: intel_aubdump: pass configuration through file descriptor

[Gandikota, Sirisha]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Lionel Landwerlin
>Sent: Tuesday, November 01, 2016 11:15 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH v3 i-g-t 1/2] tools: intel_aubdump: pass 
>configuration
>through file descriptor
>
>This makes parsing options less complicated and easier to extend.
>
>v2: Fix device id parsing (atoi -> sscanf) (Sirisha)
>Combine with previous commit moving init function (Sirisha)
>
>v3: Fix behavior change between bash 4.3 & 4.4 in <<< with \n characters
>(Lionel)
>
>Signed-off-by: Lionel Landwerlin 
>---
> tools/aubdump.c| 58 
>--
> tools/intel_aubdump.in | 24 +++--
> 2 files changed, 59 insertions(+), 23 deletions(-)
>
>diff --git a/tools/aubdump.c b/tools/aubdump.c index 30dc742..f2cd2c1 100644
>--- a/tools/aubdump.c
>+++ b/tools/aubdump.c
>@@ -426,6 +426,46 @@ close(int fd)
>   return libc_close(fd);
> }
>
>+static void
>+maybe_init(void)
>+{
>+  static bool initialized = false;
>+  FILE *config;
>+  char *key, *value;
>+
>+  if (initialized)
>+  return;
>+
>+  initialized = true;
>+
>+  config = fdopen(3, "r");
>+  while (fscanf(config, "%m[^=]=%m[^\n]\n", , ) != EOF) {
>+  if (!strcmp(key, "verbose")) {
>+  verbose = 1;
>+  } else if (!strcmp(key, "device")) {
>+  fail_if(sscanf(value, "%i", ) != 1,
>+  "intel_aubdump: failed to parse device id '%s'",
>+  value);
>+  device_override = true;
>+  } else if (!strcmp(key, "file")) {
>+  filename = value;
>+  file = fopen(filename, "w+");
>+  fail_if(file == NULL,
>+  "intel_aubdump: failed to open file '%s'\n",
>+  filename);
>+  } else {
>+  fprintf(stderr, "intel_aubdump: unknown option '%s'\n",
>key);
>+  }
>+
>+  free(key);
>+  free(value);
>+  }
>+  fclose(config);
>+
>+  bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
>+  fail_if(bos == NULL, "intel_aubdump: out of memory\n"); }
>+
> int
> ioctl(int fd, unsigned long request, ...)  { @@ -447,6 +487,8 @@ ioctl(int fd,
>unsigned long request, ...)
>   }
>
>   if (fd == drm_fd) {
>+  maybe_init();
>+
>   switch (request) {
>   case DRM_IOCTL_I915_GETPARAM: {
>   struct drm_i915_getparam *getparam = argp; @@ -
>550,26 +592,10 @@ ioctl(int fd, unsigned long request, ...)  static void
> init(void)
> {
>-  const char *args = getenv("INTEL_AUBDUMP_ARGS");
>-
>   libc_close = dlsym(RTLD_NEXT, "close");
>   libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
>   fail_if(libc_close == NULL || libc_ioctl == NULL,
>   "intel_aubdump: failed to get libc ioctl or close\n");
>-
>-  if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
>- , , ) != 3)
>-  filename = strdup("intel.aub");
>-  fail_if(filename == NULL, "intel_aubdump: out of memory\n");
>-
>-  if (device)
>-  device_override = true;
>-
>-  bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
>-  fail_if(bos == NULL, "intel_aubdump: out of memory\n");
>-
>-  file = fopen(filename, "w+");
>-  fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n",
>filename);
> }
>
> static int
>diff --git a/tools/intel_aubdump.in b/tools/intel_aubdump.in index
>feee23a..18fd03b 100644
>--- a/tools/intel_aubdump.in
>+++ b/tools/intel_aubdump.in
>@@ -21,29 +21,38 @@ EOF
> exit 0
> }
>
>-verbose=0
>-device=0
>+args=""
>+command=""
>+file=""
>+
>+function add_arg() {
>+arg=$1
>+args="$args$arg\n"
>+}
>
> while true; do
>   case "$1" in
> -o)
> file=$2
>+add_arg "file=${f:-$(basename ${f}).aub}"
> shift 2
> ;;
> -v)
>-verbose=1
>+add_arg "verbose=1"
> shift 1
> ;;
> -o*)
> file=${1##-o}
>+add_arg "file=${file:-$(basename ${file}).aub}"
> shift
> ;;
> --output=*)
> file=${1##--output=}
>+add_arg "file=${file:-$(basename ${file}).aub}"
> shift
> ;;
> --device=*)
>-device=${1##--device=}
>+add_arg "device=${1##--device=}"
> shift
> ;;
> --help)
>@@ -66,12 +75,13 @@ done
>
> [ -z $1 ] && show_help
>
>-file=${file:-$(basename $1).aub}
>+[ -z $file ] && add_arg "file=intel.aub"
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=@libdir@
>
> LD_PRELOAD=${libdir}/intel_aubdump.so${LD_PPRELOAD:+:${LD_PRELOAD}} \
>-  

Re: [Intel-gfx] [PATCH v4 i-g-t 2/2] aubdump: add --command option to stream aubdump to another program

[Gandikota, Sirisha]

>-Original Message-
>From: Landwerlin, Lionel G
>Sent: Tuesday, November 01, 2016 11:15 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Landwerlin, Lionel G ; Gandikota, Sirisha
>
>Subject: [PATCH v4 i-g-t 2/2] aubdump: add --command option to stream
>aubdump to another program
>
>This comes handy if you want to look at your application output without having
>to save it into a file. For example, use this with aubinator from Mesa :
>
>$ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app
>
>v2: Fix handling empty command line option
>
>v3: Fix command line concatenation (again...)
>
>v4: Use execvp (Petri)
>Indentation (Petri)
>Allow recording to a file and stream to an external application (Lionel)
>
>Signed-off-by: Lionel Landwerlin 
>Cc: Sirisha Gandikota 
>---
> tools/aubdump.c| 83
>--
> tools/intel_aubdump.in | 26 +++-
> 2 files changed, 98 insertions(+), 11 deletions(-)
>
>diff --git a/tools/aubdump.c b/tools/aubdump.c index f2cd2c1..f7ef699 100644
>--- a/tools/aubdump.c
>+++ b/tools/aubdump.c
>@@ -43,6 +43,10 @@
> #include "intel_aub.h"
> #include "intel_chipset.h"
>
>+#ifndef ARRAY_SIZE
>+#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0])) #endif
>+
> static int close_init_helper(int fd);
> static int ioctl_init_helper(int fd, unsigned long request, ...);
>
>@@ -50,8 +54,8 @@ static int (*libc_close)(int fd) = close_init_helper;  
>static int
>(*libc_ioctl)(int fd, unsigned long request, ...) = ioctl_init_helper;
>
> static int drm_fd = -1;
>-static char *filename;
>-static FILE *file;
>+static char *filename = NULL;
>+static FILE *files[2] = { NULL, NULL };
> static int gen = 0;
> static int verbose = 0;
> static const uint32_t gtt_size = 0x1; @@ -140,13 +144,28 @@
>align_u64(uint64_t v, uint64_t a)  static void  dword_out(uint32_t data)  {
>-  fwrite(, 1, 4, file);
>+  for (int i = 0; i < ARRAY_SIZE (files); i++) {
>+  if (files[i] == NULL)
>+  continue;
>+
>+  fail_if(fwrite(, 1, 4, files[i]) == 0,
>+  "Writing to output failed\n");
>+  }
> }
>
> static void
> data_out(const void *data, size_t size)  {
>-  fwrite(data, 1, size, file);
>+  if (size == 0)
>+  return;
>+
>+  for (int i = 0; i < ARRAY_SIZE (files); i++) {
>+  if (files[i] == NULL)
>+  continue;
>+
>+  fail_if(fwrite(data, 1, size, files[i]) == 0,
>+  "Writing to output failed\n");
>+  }
> }
>
> static void
>@@ -393,7 +412,10 @@ dump_execbuffer2(int fd, struct
>drm_i915_gem_execbuffer2 *execbuffer2)
>   aub_dump_ringbuffer(batch_bo->offset + execbuffer2-
>>batch_start_offset,
>   offset, ring_flag);
>
>-  fflush(file);
>+  for (int i = 0; i < ARRAY_SIZE(files); i++) {
>+  if (files[i] != NULL)
>+  fflush(files[i]);
>+  }
> }
>
> static void
>@@ -426,6 +448,40 @@ close(int fd)
>   return libc_close(fd);
> }
>
>+static FILE *
>+launch_command(char *command)
>+{
>+  int i = 0, fds[2];
>+  char **args = calloc(strlen(command), sizeof(char *));
>+  char *iter = command;
>+
>+  args[i++] = iter = command;
>+
>+  while ((iter = strstr(iter, ",")) != NULL) {
>+  *iter = '\0';
>+  iter += 1;
>+  args[i++] = iter;
>+  }
>+
>+  if (pipe(fds) == -1)
>+  return NULL;
>+
>+  switch (fork()) {
>+  case 0:
>+  dup2(fds[0], 0);
>+  fail_if(execvp(args[0], args) == -1,
>+  "intel_aubdump: failed to launch child command\n");
>+  return NULL;
>+
>+  default:
>+  free(args);
>+  return fdopen(fds[1], "w");
>+
>+  case -1:
>+  return NULL;
>+  }
>+}
>+
> static void
> maybe_init(void)
> {
>@@ -448,11 +504,16 @@ maybe_init(void)
>   value);
>   device_override = true;
>   } else if (!strcmp(key, "file")) {
>-  filename = value;
>-  file = fopen(filename, "w+");
>-  fail_if(file == NULL,
>+  filename = strdup(value);
>+  files[0] = fopen(filename, "w+");
>+  fail_if(files[0] == NULL,
>   "intel_aubdump: failed to open file '%s'\n",
>   filename);
>+  } else if (!strcmp(key,  "command")) {
>+  files[1] = launch_command(value);
>+  fail_if(files[1] == NULL,
>+  "intel_aubdump: failed to launch command
>'%s'\n",
>+  value);
>   } else {
>   fprintf(stderr, 

Re: [Intel-gfx] [PATCH] drm/i915: Move hangcheck code out from i915_irq.c

[Chris Wilson]

On Tue, Nov 01, 2016 at 06:43:03PM +0200, Mika Kuoppala wrote:
> Create new file for hangcheck specific code, intel_hangcheck.c,
> and move all related code in it.
> 
> v2: s/intel_engine_hangcheck/intel_engine (Chris)
> 
> No functional changes.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

[Jani Nikula]

On Tue, 01 Nov 2016, "Pandiyan, Dhinakaran"  
wrote:
> On Tue, 2016-11-01 at 21:35 +0200, Jani Nikula wrote:
>> On Tue, 01 Nov 2016, Dhinakaran Pandiyan  
>> wrote:
>> > According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
>> > audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
>> > than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
>> > cycling on/off.
>> >
>> > Let's apply this work around to GEN9 platforms too, as it fixes the same
>> > issue.
>> 
>> I'm too tired to read bspec now, but is gen9 really the answer, or just
>> Skylake?
>> 
>> 
>
> Gen9, applies to BXT and KBL as well.

I'll take your word for it, and with that,

Reviewed-by: Jani Nikula 



>
> -DK
>
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
>> > Cc: sta...@vger.kernel.org
>> > Cc: Libin Yang 
>> > Signed-off-by: Dhinakaran Pandiyan 
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c | 6 --
>> >  1 file changed, 4 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index 37483ee..c0ae147 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -10264,8 +10264,10 @@ static void bxt_modeset_commit_cdclk(struct 
>> > drm_atomic_state *old_state)
>> >  static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
>> > *crtc_state,
>> >  int pixel_rate)
>> >  {
>> > +  struct drm_device *dev = crtc_state->base.crtc->dev;
>> 
>> Nitpick, I guess I'd make that
>> 
>>  struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>> 
>> but no big deal.
>> 
>> > +
>> >/* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
>> > -  if (crtc_state->ips_enabled)
>> > +  if (IS_BROADWELL(to_i915(dev)) && crtc_state->ips_enabled)
>> >pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
>> >  
>> >/* BSpec says "Do not use DisplayPort with CDCLK less than
>> > @@ -10307,7 +10309,7 @@ static int ilk_max_pixel_rate(struct 
>> > drm_atomic_state *state)
>> >  
>> >pixel_rate = ilk_pipe_pixel_rate(crtc_state);
>> >  
>> > -  if (IS_BROADWELL(dev_priv))
>> > +  if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
>> >pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
>> >pixel_rate);
>> 
>

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

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

[Pandiyan, Dhinakaran]

On Tue, 2016-11-01 at 21:35 +0200, Jani Nikula wrote:
> On Tue, 01 Nov 2016, Dhinakaran Pandiyan  
> wrote:
> > According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
> > audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
> > than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
> > cycling on/off.
> >
> > Let's apply this work around to GEN9 platforms too, as it fixes the same
> > issue.
> 
> I'm too tired to read bspec now, but is gen9 really the answer, or just
> Skylake?
> 
> 

Gen9, applies to BXT and KBL as well. 

-DK

> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > Cc: sta...@vger.kernel.org
> > Cc: Libin Yang 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 37483ee..c0ae147 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10264,8 +10264,10 @@ static void bxt_modeset_commit_cdclk(struct 
> > drm_atomic_state *old_state)
> >  static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> > *crtc_state,
> >   int pixel_rate)
> >  {
> > +   struct drm_device *dev = crtc_state->base.crtc->dev;
> 
> Nitpick, I guess I'd make that
> 
>   struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> 
> but no big deal.
> 
> > +
> > /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> > -   if (crtc_state->ips_enabled)
> > +   if (IS_BROADWELL(to_i915(dev)) && crtc_state->ips_enabled)
> > pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> >  
> > /* BSpec says "Do not use DisplayPort with CDCLK less than
> > @@ -10307,7 +10309,7 @@ static int ilk_max_pixel_rate(struct 
> > drm_atomic_state *state)
> >  
> > pixel_rate = ilk_pipe_pixel_rate(crtc_state);
> >  
> > -   if (IS_BROADWELL(dev_priv))
> > +   if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
> > pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
> > pixel_rate);
> 

___
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/dp: Extend BDW DP audio workaround to GEN9 platforms

[Jani Nikula]

On Tue, 01 Nov 2016, Dhinakaran Pandiyan  wrote:
> According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
> audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
> than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
> cycling on/off.
>
> Let's apply this work around to GEN9 platforms too, as it fixes the same
> issue.

I'm too tired to read bspec now, but is gen9 really the answer, or just
Skylake?


>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
> Cc: sta...@vger.kernel.org
> Cc: Libin Yang 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 37483ee..c0ae147 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10264,8 +10264,10 @@ static void bxt_modeset_commit_cdclk(struct 
> drm_atomic_state *old_state)
>  static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> *crtc_state,
> int pixel_rate)
>  {
> + struct drm_device *dev = crtc_state->base.crtc->dev;

Nitpick, I guess I'd make that

struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);

but no big deal.

> +
>   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> - if (crtc_state->ips_enabled)
> + if (IS_BROADWELL(to_i915(dev)) && crtc_state->ips_enabled)
>   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
>  
>   /* BSpec says "Do not use DisplayPort with CDCLK less than
> @@ -10307,7 +10309,7 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
> *state)
>  
>   pixel_rate = ilk_pipe_pixel_rate(crtc_state);
>  
> - if (IS_BROADWELL(dev_priv))
> + if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
>   pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
>   pixel_rate);

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Tue, Nov 01, 2016 at 09:16:28PM +0200, Jani Nikula wrote:
> On Tue, 01 Nov 2016, Manasi Navare  wrote:
> > On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote:
> >> On Sat, 29 Oct 2016, Manasi Navare  wrote:
> >> > If link training at a link rate optimal for a particular
> >> > mode fails during modeset's atomic commit phase, then we
> >> > let the modeset complete and then retry. We save the link rate
> >> > value at which link training failed, update the link status property
> >> > to "BAD" and use a lower link rate to prune the modes. It will redo
> >> > the modeset on the current mode at lower link rate or if the current
> >> > mode gets pruned due to lower link constraints then, it will send a
> >> > hotplug uevent for userspace to handle it.
> >> >
> >> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> >> > 4.3.1.6.
> >> >
> >> > v2:
> >> > * Squashed a few patches (Jani Nikula)
> >> >
> >> > Cc: Jani Nikula 
> >> > Cc: Daniel Vetter 
> >> > Cc: Ville Syrjala 
> >> > Signed-off-by: Manasi Navare 
> >> > ---
> >> >  drivers/gpu/drm/drm_atomic_helper.c   |  4 ++
> >> >  drivers/gpu/drm/i915/intel_ddi.c  | 23 -
> >> >  drivers/gpu/drm/i915/intel_dp.c   | 74 
> >> > +--
> >> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> >> >  drivers/gpu/drm/i915/intel_drv.h  |  5 +-
> >> >  5 files changed, 110 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >> > b/drivers/gpu/drm/drm_atomic_helper.c
> >> > index 75ad01d..a3df3a4 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> > @@ -519,6 +519,10 @@ static int handle_conflicting_encoders(struct 
> >> > drm_atomic_state *state,
> >> > connector_state);
> >> >  if (ret)
> >> >  return ret;
> >> > +
> >> > +crtc_state = drm_atomic_get_existing_crtc_state(state, 
> >> > connector->state->crtc);
> >> > +if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> >> > +crtc_state->connectors_changed = true;
> >> >  }
> >> >  
> >> >  /*
> >> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> > b/drivers/gpu/drm/i915/intel_ddi.c
> >> > index 938ac4d..319eeca 100644
> >> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> > @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct 
> >> > intel_encoder *encoder,
> >> >  struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> >> >  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >> >  enum port port = intel_ddi_get_encoder_port(encoder);
> >> > +struct intel_connector *intel_connector = 
> >> > intel_dp->attached_connector;
> >> > +struct drm_connector *connector = _connector->base;
> >> >  
> >> >  intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >> >   link_mst);
> >> > @@ -1694,7 +1696,26 @@ static void intel_ddi_pre_enable_dp(struct 
> >> > intel_encoder *encoder,
> >> >  intel_prepare_dp_ddi_buffers(encoder);
> >> >  intel_ddi_init_dp_buf_reg(encoder);
> >> >  intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> >> > -intel_dp_start_link_train(intel_dp);
> >> > +if (!intel_dp_start_link_train(intel_dp)) {
> >> > +DRM_DEBUG_KMS("Link Training failed at link rate = %d, 
> >> > lane count = %d",
> >> > +  link_rate, lane_count);
> >> > +intel_dp->link_train_failed = true;
> >> > +intel_dp_get_link_train_fallback_values(intel_dp, 
> >> > link_rate,
> >> > +lane_count);
> >> > +/* Schedule a Hotplug Uevent to userspace to start 
> >> > modeset */
> >> > +schedule_work(_connector->modeset_retry_work);
> >> 
> >> This is not just about DDI. Need to do this for the other cases too.
> >>
> >
> > Yes, first series will g out for adding this support for DDI, then more 
> > patches
> > to expand it to non DDI platforms.
> >
> >  
> >> > +} else {
> >> > +DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, 
> >> > Lane count = %d",
> >> > +  link_rate, lane_count);
> >> > +intel_dp->link_train_failed = false;
> >> > +intel_dp->fallback_link_rate_index = -1;
> >> > +intel_dp->fallback_link_rate = 0;
> >> > +intel_dp->fallback_lane_count = 0;
> >> > +connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
> >> > +

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: BDW cdclk fix for DP audio

[Jani Nikula]

On Tue, 01 Nov 2016, Dhinakaran Pandiyan  wrote:
> According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
> audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
> than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
> cycling on/off.
>
> From BSpec:
> "Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)]
> Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio
> enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may
> be audio corruption or screen corruption."
>
> Since, some DP configurations (e.g., MST) use port width x4 and HBR2
> link rate, let's increase the cdclk to >= 432 MHz to enable audio for those
> cases.
>
> v4: Changed commit message
> v3: Combine BDW pixel rate adjustments into a function (Jani)
> v2: Restrict fix to BDW
> Retain the set cdclk across modesets (Ville)
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Ville Syrjälä 
> Reviewed-by: Jani Nikula 

Yup.

> ---
>  drivers/gpu/drm/i915/intel_display.c | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 895b3dc..37483ee 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10261,6 +10261,27 @@ static void bxt_modeset_commit_cdclk(struct 
> drm_atomic_state *old_state)
>   bxt_set_cdclk(to_i915(dev), req_cdclk);
>  }
>  
> +static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state 
> *crtc_state,
> +   int pixel_rate)
> +{
> + /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> + if (crtc_state->ips_enabled)
> + pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> +
> + /* BSpec says "Do not use DisplayPort with CDCLK less than
> +  * 432 MHz, audio enabled, port width x4, and link rate
> +  * HBR2 (5.4 GHz), or else there may be audio corruption or
> +  * screen corruption."
> +  */
> + if (intel_crtc_has_dp_encoder(crtc_state) &&
> + crtc_state->has_audio &&
> + crtc_state->port_clock >= 54 &&
> + crtc_state->lane_count == 4)
> + pixel_rate = max(432000, pixel_rate);
> +
> + return pixel_rate;
> +}
> +
>  /* compute the max rate for new configuration */
>  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
>  {
> @@ -10286,9 +10307,9 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
> *state)
>  
>   pixel_rate = ilk_pipe_pixel_rate(crtc_state);
>  
> - /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> - if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> - pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
> + if (IS_BROADWELL(dev_priv))
> + pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
> + pixel_rate);
>  
>   intel_state->min_pixclk[i] = pixel_rate;
>   }

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Implement Link Rate fallback on Link training failure

[Jani Nikula]

On Tue, 01 Nov 2016, Manasi Navare  wrote:
> On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote:
>> On Sat, 29 Oct 2016, Manasi Navare  wrote:
>> > If link training at a link rate optimal for a particular
>> > mode fails during modeset's atomic commit phase, then we
>> > let the modeset complete and then retry. We save the link rate
>> > value at which link training failed, update the link status property
>> > to "BAD" and use a lower link rate to prune the modes. It will redo
>> > the modeset on the current mode at lower link rate or if the current
>> > mode gets pruned due to lower link constraints then, it will send a
>> > hotplug uevent for userspace to handle it.
>> >
>> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
>> > 4.3.1.6.
>> >
>> > v2:
>> > * Squashed a few patches (Jani Nikula)
>> >
>> > Cc: Jani Nikula 
>> > Cc: Daniel Vetter 
>> > Cc: Ville Syrjala 
>> > Signed-off-by: Manasi Navare 
>> > ---
>> >  drivers/gpu/drm/drm_atomic_helper.c   |  4 ++
>> >  drivers/gpu/drm/i915/intel_ddi.c  | 23 -
>> >  drivers/gpu/drm/i915/intel_dp.c   | 74 
>> > +--
>> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
>> >  drivers/gpu/drm/i915/intel_drv.h  |  5 +-
>> >  5 files changed, 110 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> > b/drivers/gpu/drm/drm_atomic_helper.c
>> > index 75ad01d..a3df3a4 100644
>> > --- a/drivers/gpu/drm/drm_atomic_helper.c
>> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> > @@ -519,6 +519,10 @@ static int handle_conflicting_encoders(struct 
>> > drm_atomic_state *state,
>> >   connector_state);
>> >if (ret)
>> >return ret;
>> > +
>> > +  crtc_state = drm_atomic_get_existing_crtc_state(state, 
>> > connector->state->crtc);
>> > +  if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
>> > +  crtc_state->connectors_changed = true;
>> >}
>> >  
>> >/*
>> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> > b/drivers/gpu/drm/i915/intel_ddi.c
>> > index 938ac4d..319eeca 100644
>> > --- a/drivers/gpu/drm/i915/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> > @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct 
>> > intel_encoder *encoder,
>> >struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>> >struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> >enum port port = intel_ddi_get_encoder_port(encoder);
>> > +  struct intel_connector *intel_connector = intel_dp->attached_connector;
>> > +  struct drm_connector *connector = _connector->base;
>> >  
>> >intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>> > link_mst);
>> > @@ -1694,7 +1696,26 @@ static void intel_ddi_pre_enable_dp(struct 
>> > intel_encoder *encoder,
>> >intel_prepare_dp_ddi_buffers(encoder);
>> >intel_ddi_init_dp_buf_reg(encoder);
>> >intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>> > -  intel_dp_start_link_train(intel_dp);
>> > +  if (!intel_dp_start_link_train(intel_dp)) {
>> > +  DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
>> > count = %d",
>> > +link_rate, lane_count);
>> > +  intel_dp->link_train_failed = true;
>> > +  intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
>> > +  lane_count);
>> > +  /* Schedule a Hotplug Uevent to userspace to start modeset */
>> > +  schedule_work(_connector->modeset_retry_work);
>> 
>> This is not just about DDI. Need to do this for the other cases too.
>>
>
> Yes, first series will g out for adding this support for DDI, then more 
> patches
> to expand it to non DDI platforms.
>
>  
>> > +  } else {
>> > +  DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
>> > count = %d",
>> > +link_rate, lane_count);
>> > +  intel_dp->link_train_failed = false;
>> > +  intel_dp->fallback_link_rate_index = -1;
>> > +  intel_dp->fallback_link_rate = 0;
>> > +  intel_dp->fallback_lane_count = 0;
>> > +  connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
>> > +  intel_dp_set_link_status_property(connector,
>> > +DRM_MODE_LINK_STATUS_GOOD);
>> 
>> Looks like you never actually read connector->link_status... Why do you
>> need both connector->link_status and intel_dp->link_train_failed? Do you
>> think you have 4 states? What are they? Can't this all be in sync with
>> the property?
>> 
>
> This connector->link_status member of drm_Connector gets read in
> drm_atomic_helper_check_modeset() in the 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio
URL   : https://patchwork.freedesktop.org/series/14688/
State : warning

== Summary ==

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

Test kms_busy:
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:181  dwarn:6   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 
2016y-11m-01d-16h-36m-25s UTC integration manifest
219db73 drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms
d674c15 drm/i915/dp: BDW cdclk fix for DP audio

== Logs ==

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

[Intel-gfx] [PATCH v4 1/2] drm/i915/dp: BDW cdclk fix for DP audio

[Dhinakaran Pandiyan]

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.

From BSpec:
"Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)]
Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio
enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may
be audio corruption or screen corruption."

Since, some DP configurations (e.g., MST) use port width x4 and HBR2
link rate, let's increase the cdclk to >= 432 MHz to enable audio for those
cases.

v4: Changed commit message
v3: Combine BDW pixel rate adjustments into a function (Jani)
v2: Restrict fix to BDW
Retain the set cdclk across modesets (Ville)
Cc: sta...@vger.kernel.org
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 895b3dc..37483ee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10261,6 +10261,27 @@ static void bxt_modeset_commit_cdclk(struct 
drm_atomic_state *old_state)
bxt_set_cdclk(to_i915(dev), req_cdclk);
 }
 
+static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state *crtc_state,
+ int pixel_rate)
+{
+   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
+   if (crtc_state->ips_enabled)
+   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
+
+   /* BSpec says "Do not use DisplayPort with CDCLK less than
+* 432 MHz, audio enabled, port width x4, and link rate
+* HBR2 (5.4 GHz), or else there may be audio corruption or
+* screen corruption."
+*/
+   if (intel_crtc_has_dp_encoder(crtc_state) &&
+   crtc_state->has_audio &&
+   crtc_state->port_clock >= 54 &&
+   crtc_state->lane_count == 4)
+   pixel_rate = max(432000, pixel_rate);
+
+   return pixel_rate;
+}
+
 /* compute the max rate for new configuration */
 static int ilk_max_pixel_rate(struct drm_atomic_state *state)
 {
@@ -10286,9 +10307,9 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
*state)
 
pixel_rate = ilk_pipe_pixel_rate(crtc_state);
 
-   /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
-   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
-   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
+   if (IS_BROADWELL(dev_priv))
+   pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
+   pixel_rate);
 
intel_state->min_pixclk[i] = pixel_rate;
}
-- 
2.7.4

___
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/dp: Extend BDW DP audio workaround to GEN9 platforms

[Dhinakaran Pandiyan]

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.

Let's apply this work around to GEN9 platforms too, as it fixes the same
issue.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
Cc: sta...@vger.kernel.org
Cc: Libin Yang 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_display.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 37483ee..c0ae147 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10264,8 +10264,10 @@ static void bxt_modeset_commit_cdclk(struct 
drm_atomic_state *old_state)
 static int bdw_adjust_min_pipe_pixel_rate(struct intel_crtc_state *crtc_state,
  int pixel_rate)
 {
+   struct drm_device *dev = crtc_state->base.crtc->dev;
+
/* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
-   if (crtc_state->ips_enabled)
+   if (IS_BROADWELL(to_i915(dev)) && crtc_state->ips_enabled)
pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
 
/* BSpec says "Do not use DisplayPort with CDCLK less than
@@ -10307,7 +10309,7 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
*state)
 
pixel_rate = ilk_pipe_pixel_rate(crtc_state);
 
-   if (IS_BROADWELL(dev_priv))
+   if (IS_BROADWELL(dev_priv) || IS_GEN9(dev_priv))
pixel_rate = bdw_adjust_min_pipe_pixel_rate(crtc_state,
pixel_rate);
 
-- 
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: warning for drm/i915: Move hangcheck code out from i915_irq.c

[Patchwork]

== Series Details ==

Series: drm/i915: Move hangcheck code out from i915_irq.c
URL   : https://patchwork.freedesktop.org/series/14685/
State : warning

== Summary ==

Series 14685v1 drm/i915: Move hangcheck code out from i915_irq.c
https://patchwork.freedesktop.org/api/1.0/series/14685/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:183  dwarn:4   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:226  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 
2016y-11m-01d-16h-36m-25s UTC integration manifest
3a0612c drm/i915: Move hangcheck code out from i915_irq.c

== Logs ==

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

[Intel-gfx] [PATCH v3 i-g-t 1/2] tools: intel_aubdump: pass configuration through file descriptor

[Lionel Landwerlin]

This makes parsing options less complicated and easier to extend.

v2: Fix device id parsing (atoi -> sscanf) (Sirisha)
Combine with previous commit moving init function (Sirisha)

v3: Fix behavior change between bash 4.3 & 4.4 in <<< with \n characters
(Lionel)

Signed-off-by: Lionel Landwerlin 
---
 tools/aubdump.c| 58 --
 tools/intel_aubdump.in | 24 +++--
 2 files changed, 59 insertions(+), 23 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index 30dc742..f2cd2c1 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -426,6 +426,46 @@ close(int fd)
return libc_close(fd);
 }

+static void
+maybe_init(void)
+{
+   static bool initialized = false;
+   FILE *config;
+   char *key, *value;
+
+   if (initialized)
+   return;
+
+   initialized = true;
+
+   config = fdopen(3, "r");
+   while (fscanf(config, "%m[^=]=%m[^\n]\n", , ) != EOF) {
+   if (!strcmp(key, "verbose")) {
+   verbose = 1;
+   } else if (!strcmp(key, "device")) {
+   fail_if(sscanf(value, "%i", ) != 1,
+   "intel_aubdump: failed to parse device id '%s'",
+   value);
+   device_override = true;
+   } else if (!strcmp(key, "file")) {
+   filename = value;
+   file = fopen(filename, "w+");
+   fail_if(file == NULL,
+   "intel_aubdump: failed to open file '%s'\n",
+   filename);
+   } else {
+   fprintf(stderr, "intel_aubdump: unknown option '%s'\n", 
key);
+   }
+
+   free(key);
+   free(value);
+   }
+   fclose(config);
+
+   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
+   fail_if(bos == NULL, "intel_aubdump: out of memory\n");
+}
+
 int
 ioctl(int fd, unsigned long request, ...)
 {
@@ -447,6 +487,8 @@ ioctl(int fd, unsigned long request, ...)
}

if (fd == drm_fd) {
+   maybe_init();
+
switch (request) {
case DRM_IOCTL_I915_GETPARAM: {
struct drm_i915_getparam *getparam = argp;
@@ -550,26 +592,10 @@ ioctl(int fd, unsigned long request, ...)
 static void
 init(void)
 {
-   const char *args = getenv("INTEL_AUBDUMP_ARGS");
-
libc_close = dlsym(RTLD_NEXT, "close");
libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
fail_if(libc_close == NULL || libc_ioctl == NULL,
"intel_aubdump: failed to get libc ioctl or close\n");
-
-   if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
-  , , ) != 3)
-   filename = strdup("intel.aub");
-   fail_if(filename == NULL, "intel_aubdump: out of memory\n");
-
-   if (device)
-   device_override = true;
-
-   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
-   fail_if(bos == NULL, "intel_aubdump: out of memory\n");
-
-   file = fopen(filename, "w+");
-   fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n", 
filename);
 }

 static int
diff --git a/tools/intel_aubdump.in b/tools/intel_aubdump.in
index feee23a..18fd03b 100644
--- a/tools/intel_aubdump.in
+++ b/tools/intel_aubdump.in
@@ -21,29 +21,38 @@ EOF
 exit 0
 }

-verbose=0
-device=0
+args=""
+command=""
+file=""
+
+function add_arg() {
+arg=$1
+args="$args$arg\n"
+}

 while true; do
   case "$1" in
  -o)
  file=$2
+ add_arg "file=${f:-$(basename ${f}).aub}"
  shift 2
  ;;
  -v)
- verbose=1
+ add_arg "verbose=1"
  shift 1
  ;;
  -o*)
  file=${1##-o}
+ add_arg "file=${file:-$(basename ${file}).aub}"
  shift
  ;;
  --output=*)
  file=${1##--output=}
+ add_arg "file=${file:-$(basename ${file}).aub}"
  shift
  ;;
  --device=*)
- device=${1##--device=}
+ add_arg "device=${1##--device=}"
  shift
  ;;
  --help)
@@ -66,12 +75,13 @@ done

 [ -z $1 ] && show_help

-file=${file:-$(basename $1).aub}
+[ -z $file ] && add_arg "file=intel.aub"

 prefix=@prefix@
 exec_prefix=@exec_prefix@
 libdir=@libdir@

 LD_PRELOAD=${libdir}/intel_aubdump.so${LD_PPRELOAD:+:${LD_PRELOAD}} \
- INTEL_AUBDUMP_ARGS="verbose=$verbose;file=$file;device=$device" \
- exec -- "$@"
+ exec -- "$@" 3

[Intel-gfx] [PATCH v4 i-g-t 2/2] aubdump: add --command option to stream aubdump to another program

[Lionel Landwerlin]

This comes handy if you want to look at your application output without
having to save it into a file. For example, use this with aubinator from
Mesa :

$ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app

v2: Fix handling empty command line option

v3: Fix command line concatenation (again...)

v4: Use execvp (Petri)
Indentation (Petri)
Allow recording to a file and stream to an external application (Lionel)

Signed-off-by: Lionel Landwerlin 
Cc: Sirisha Gandikota 
---
 tools/aubdump.c| 83 --
 tools/intel_aubdump.in | 26 +++-
 2 files changed, 98 insertions(+), 11 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index f2cd2c1..f7ef699 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -43,6 +43,10 @@
 #include "intel_aub.h"
 #include "intel_chipset.h"

+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
+#endif
+
 static int close_init_helper(int fd);
 static int ioctl_init_helper(int fd, unsigned long request, ...);

@@ -50,8 +54,8 @@ static int (*libc_close)(int fd) = close_init_helper;
 static int (*libc_ioctl)(int fd, unsigned long request, ...) = 
ioctl_init_helper;

 static int drm_fd = -1;
-static char *filename;
-static FILE *file;
+static char *filename = NULL;
+static FILE *files[2] = { NULL, NULL };
 static int gen = 0;
 static int verbose = 0;
 static const uint32_t gtt_size = 0x1;
@@ -140,13 +144,28 @@ align_u64(uint64_t v, uint64_t a)
 static void
 dword_out(uint32_t data)
 {
-   fwrite(, 1, 4, file);
+   for (int i = 0; i < ARRAY_SIZE (files); i++) {
+   if (files[i] == NULL)
+   continue;
+
+   fail_if(fwrite(, 1, 4, files[i]) == 0,
+   "Writing to output failed\n");
+   }
 }

 static void
 data_out(const void *data, size_t size)
 {
-   fwrite(data, 1, size, file);
+   if (size == 0)
+   return;
+
+   for (int i = 0; i < ARRAY_SIZE (files); i++) {
+   if (files[i] == NULL)
+   continue;
+
+   fail_if(fwrite(data, 1, size, files[i]) == 0,
+   "Writing to output failed\n");
+   }
 }

 static void
@@ -393,7 +412,10 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 
*execbuffer2)
aub_dump_ringbuffer(batch_bo->offset + execbuffer2->batch_start_offset,
offset, ring_flag);

-   fflush(file);
+   for (int i = 0; i < ARRAY_SIZE(files); i++) {
+   if (files[i] != NULL)
+   fflush(files[i]);
+   }
 }

 static void
@@ -426,6 +448,40 @@ close(int fd)
return libc_close(fd);
 }

+static FILE *
+launch_command(char *command)
+{
+   int i = 0, fds[2];
+   char **args = calloc(strlen(command), sizeof(char *));
+   char *iter = command;
+
+   args[i++] = iter = command;
+
+   while ((iter = strstr(iter, ",")) != NULL) {
+   *iter = '\0';
+   iter += 1;
+   args[i++] = iter;
+   }
+
+   if (pipe(fds) == -1)
+   return NULL;
+
+   switch (fork()) {
+   case 0:
+   dup2(fds[0], 0);
+   fail_if(execvp(args[0], args) == -1,
+   "intel_aubdump: failed to launch child command\n");
+   return NULL;
+
+   default:
+   free(args);
+   return fdopen(fds[1], "w");
+
+   case -1:
+   return NULL;
+   }
+}
+
 static void
 maybe_init(void)
 {
@@ -448,11 +504,16 @@ maybe_init(void)
value);
device_override = true;
} else if (!strcmp(key, "file")) {
-   filename = value;
-   file = fopen(filename, "w+");
-   fail_if(file == NULL,
+   filename = strdup(value);
+   files[0] = fopen(filename, "w+");
+   fail_if(files[0] == NULL,
"intel_aubdump: failed to open file '%s'\n",
filename);
+   } else if (!strcmp(key,  "command")) {
+   files[1] = launch_command(value);
+   fail_if(files[1] == NULL,
+   "intel_aubdump: failed to launch command 
'%s'\n",
+   value);
} else {
fprintf(stderr, "intel_aubdump: unknown option '%s'\n", 
key);
}
@@ -623,7 +684,9 @@ static void __attribute__ ((destructor))
 fini(void)
 {
free(filename);
-   if (file)
-   fclose(file);
+   for (int i = 0; i < ARRAY_SIZE(files); i++) {
+   if (files[i] != NULL)
+   fclose(files[i]);
+   }
free(bos);
 }
diff --git a/tools/intel_aubdump.in 

Re: [Intel-gfx] [PATCH] drm/i915/huc: Update the construction of file path for HuC similar to that of GuC

[Srivatsa, Anusha]

>-Original Message-
>From: Mcgee, Jeff
>Sent: Tuesday, November 1, 2016 11:22 AM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/i915/huc: Update the construction of file path for HuC
>similar to that of GuC
>
>On Mon, Oct 31, 2016 at 03:24:53PM -0700, Anusha Srivatsa wrote:
>> Update the file construction and specifying the required version
>> similar to that of GuC.Add an extra field for the build number.
>> Adopted the approach used in
>> https://patchwork.freedesktop.org/patch/104355/ 
>>
>> Cc: Jeff Mcgee 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  drivers/gpu/drm/i915/intel_huc_loader.c | 25
>> +++--
>>  1 file changed, 19 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
>> b/drivers/gpu/drm/i915/intel_huc_loader.c
>> index 2f5d9d9..419caae 100644
>> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
>> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
>> @@ -39,11 +39,24 @@
>>   *
>>   * Note that HuC firmware loading must be done before GuC loading.
>>   */
>> +#define SKL_FW_MAJOR 01
>> +#define SKL_FW_MINOR 07
>> +#define SKL_BLD_NUM 1398
>>
>> -#define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
>> +#define BXT_FW_MAJOR 01
>> +#define BXT_FW_MINOR 07
>> +#define BXT_BLD_NUM 1398
>> +
>> +#define HUC_FW_PATH(platform, major, minor, bld_num) \
>> +"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
>> +__stringify(minor) "_" __stringify(bld_num) ".bin"
>> +
>> +#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_FW_MAJOR, \
>> +SKL_FW_MINOR, SKL_BLD_NUM)
>>  MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
>>
>> -#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin"
>> +#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
>> +BXT_FW_MINOR, BXT_BLD_NUM)
>>  MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
>>
>>  /**
>> @@ -151,12 +164,12 @@ void intel_huc_init(struct drm_device *dev)
>>
>>  if (IS_SKYLAKE(dev_priv)) {
>>  fw_path = I915_SKL_HUC_UCODE;
>> -huc_fw->major_ver_wanted = 1;
>> -huc_fw->minor_ver_wanted = 7;
>> +huc_fw->major_ver_wanted = SKL_FW_MAJOR;
>> +huc_fw->minor_ver_wanted = SKL_FW_MINOR;
>>  } else if (IS_BROXTON(dev_priv)) {
>>  fw_path = I915_BXT_HUC_UCODE;
>> -huc_fw->major_ver_wanted = 1;
>> -huc_fw->minor_ver_wanted = 7;
>> +huc_fw->major_ver_wanted = BXT_FW_MAJOR;
>> +huc_fw->minor_ver_wanted = BXT_FW_MINOR;
>>  }
>>
>>  if (fw_path == NULL)
>> --
>> 2.7.4
>>
>
>Looks good but it would be far better to make these changes in the
>corresponding patches within the origin HuC patch set, rather than
>proposing a follow-up patch to correct issues in that set (which is
>not yet merged and can be updated).

Agreed. Thankyou for the review.

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

Re: [Intel-gfx] [PATCH] drm/i915/huc: Update the construction of file path for HuC similar to that of GuC

[Jeff McGee]

On Mon, Oct 31, 2016 at 03:24:53PM -0700, Anusha Srivatsa wrote:
> Update the file construction and specifying the required version
> similar to that of GuC.Add an extra field for the build number.
> Adopted the approach used in
> https://patchwork.freedesktop.org/patch/104355/ 
> 
> Cc: Jeff Mcgee 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_huc_loader.c | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 2f5d9d9..419caae 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -39,11 +39,24 @@
>   *
>   * Note that HuC firmware loading must be done before GuC loading.
>   */
> +#define SKL_FW_MAJOR 01
> +#define SKL_FW_MINOR 07
> +#define SKL_BLD_NUM 1398
>  
> -#define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
> +#define BXT_FW_MAJOR 01
> +#define BXT_FW_MINOR 07
> +#define BXT_BLD_NUM 1398
> +
> +#define HUC_FW_PATH(platform, major, minor, bld_num) \
> + "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
> + __stringify(minor) "_" __stringify(bld_num) ".bin"
> +
> +#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_FW_MAJOR, \
> + SKL_FW_MINOR, SKL_BLD_NUM)
>  MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
>  
> -#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin"
> +#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
> + BXT_FW_MINOR, BXT_BLD_NUM)
>  MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
>  
>  /**
> @@ -151,12 +164,12 @@ void intel_huc_init(struct drm_device *dev)
>  
>   if (IS_SKYLAKE(dev_priv)) {
>   fw_path = I915_SKL_HUC_UCODE;
> - huc_fw->major_ver_wanted = 1;
> - huc_fw->minor_ver_wanted = 7;
> + huc_fw->major_ver_wanted = SKL_FW_MAJOR;
> + huc_fw->minor_ver_wanted = SKL_FW_MINOR;
>   } else if (IS_BROXTON(dev_priv)) {
>   fw_path = I915_BXT_HUC_UCODE;
> - huc_fw->major_ver_wanted = 1;
> - huc_fw->minor_ver_wanted = 7;
> + huc_fw->major_ver_wanted = BXT_FW_MAJOR;
> + huc_fw->minor_ver_wanted = BXT_FW_MINOR;
>   }
>  
>   if (fw_path == NULL)
> -- 
> 2.7.4
> 

Looks good but it would be far better to make these changes in the
corresponding patches within the origin HuC patch set, rather than
proposing a follow-up patch to correct issues in that set (which is
not yet merged and can be updated).
-Jeff
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Move hangcheck code out from i915_irq.c

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Move hangcheck code out from 
i915_irq.c
URL   : https://patchwork.freedesktop.org/series/14682/
State : warning

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:181  dwarn:6   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

c5ad9c11e819eebcad5b9be5aa5e991e89b26965 drm-intel-nightly: 
2016y-11m-01d-16h-36m-25s UTC integration manifest
bd76e9b drm/i915: Move error state capture code out from i915_irq.c
f722ee3 drm/i915: Move hangcheck code out from i915_irq.c

== Logs ==

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

Re: [Intel-gfx] [PATCH v8 11/12] drm/i915: Add more Haswell OA metric sets

[Robert Bragg]

On Tue, Nov 1, 2016 at 2:57 PM, Chris Wilson 
wrote:

> On Fri, Oct 28, 2016 at 03:14:29AM +0100, Robert Bragg wrote:
> > This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
> > and 'sampler balance' metric sets for Haswell.
> >
> > The code is auto generated from an XML description of metric sets,
> > currently maintained in gputop, ref:
> >
> >  https://github.com/rib/gputop
> >  > gputop-data/oa-*.xml
> >  > scripts/i915-perf-kernelgen.py
> >
> >  $ make -C gputop-data -f Makefile.xml
> >
> > Signed-off-by: Robert Bragg 
> > Reviewed-by: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/i915_oa_hsw.c | 559 ++
> ++-
> >  1 file changed, 558 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c
> b/drivers/gpu/drm/i915/i915_oa_hsw.c
> > index 6af25cf..4ddf756 100644
> > --- a/drivers/gpu/drm/i915/i915_oa_hsw.c
> > +++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
> > @@ -31,9 +31,14 @@
> >
> >  enum metric_set_id {
> >   METRIC_SET_ID_RENDER_BASIC = 1,
> > + METRIC_SET_ID_COMPUTE_BASIC,
> > + METRIC_SET_ID_COMPUTE_EXTENDED,
> > + METRIC_SET_ID_MEMORY_READS,
> > + METRIC_SET_ID_MEMORY_WRITES,
> > + METRIC_SET_ID_SAMPLER_BALANCE,
> >  };
> >
> > -int i915_oa_n_builtin_metric_sets_hsw = 1;
> > +int i915_oa_n_builtin_metric_sets_hsw = 6;
> >
> >  static const struct i915_oa_reg b_counter_config_render_basic[] = {
> >   { _MMIO(0x2724), 0x0080 },
> > @@ -112,6 +117,298 @@ get_render_basic_mux_config(struct
> drm_i915_private *dev_priv,
> >   return mux_config_render_basic;
> >  }
> >
> > +static const struct i915_oa_reg b_counter_config_compute_basic[] = {
> > + { _MMIO(0x2710), 0x },
> > + { _MMIO(0x2714), 0x0080 },
> > + { _MMIO(0x2718), 0x },
> > + { _MMIO(0x271c), 0x },
> > + { _MMIO(0x2720), 0x },
> > + { _MMIO(0x2724), 0x0080 },
> > + { _MMIO(0x2728), 0x },
> > + { _MMIO(0x272c), 0x },
> > + { _MMIO(0x2740), 0x },
> > + { _MMIO(0x2744), 0x },
> > + { _MMIO(0x2748), 0x },
> > + { _MMIO(0x274c), 0x },
> > + { _MMIO(0x2750), 0x },
> > + { _MMIO(0x2754), 0x },
> > + { _MMIO(0x2758), 0x },
> > + { _MMIO(0x275c), 0x },
> > + { _MMIO(0x236c), 0x },
> > +};
> > +
> > +static const struct i915_oa_reg mux_config_compute_basic[] = {
> > + { _MMIO(0x253a4), 0x },
> > + { _MMIO(0x2681c), 0x01f00800 },
> > + { _MMIO(0x26820), 0x1000 },
> > + { _MMIO(0x2781c), 0x01f00800 },
> > + { _MMIO(0x26520), 0x0007 },
> > + { _MMIO(0x265a0), 0x0007 },
> > + { _MMIO(0x25380), 0x0010 },
> > + { _MMIO(0x2538c), 0x0030 },
> > + { _MMIO(0x25384), 0xaa8a },
> > + { _MMIO(0x25404), 0x },
> > + { _MMIO(0x26800), 0x4202 },
> > + { _MMIO(0x26808), 0x00605817 },
> > + { _MMIO(0x2680c), 0x10001005 },
> > + { _MMIO(0x26804), 0x },
> > + { _MMIO(0x27800), 0x0102 },
> > + { _MMIO(0x27808), 0x0c0701e0 },
> > + { _MMIO(0x2780c), 0x000200a0 },
> > + { _MMIO(0x27804), 0x },
> > + { _MMIO(0x26484), 0x4400 },
> > + { _MMIO(0x26704), 0x4400 },
> > + { _MMIO(0x26500), 0x0006 },
> > + { _MMIO(0x26510), 0x0001 },
> > + { _MMIO(0x26504), 0x8800 },
> > + { _MMIO(0x26580), 0x0006 },
> > + { _MMIO(0x26590), 0x0020 },
> > + { _MMIO(0x26584), 0x },
> > + { _MMIO(0x26104), 0x5582 },
> > + { _MMIO(0x26184), 0xaa86 },
> > + { _MMIO(0x25420), 0x08320c83 },
> > + { _MMIO(0x25424), 0x06820c83 },
> > + { _MMIO(0x2541c), 0x },
> > + { _MMIO(0x25428), 0x0c03 },
> > +};
> > +
> > +static const struct i915_oa_reg *
> > +get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
> > +  int *len)
> > +{
> > + *len = ARRAY_SIZE(mux_config_compute_basic);
> > + return mux_config_compute_basic;
> > +}
>
> > @@ -140,6 +437,106 @@ int i915_oa_select_metric_set_hsw(struct
> drm_i915_private *dev_priv)
> >   ARRAY_SIZE(b_counter_config_render_basic);
> >
> >   return 0;
> > + case METRIC_SET_ID_COMPUTE_BASIC:
> > + dev_priv->perf.oa.mux_regs =
> > + get_compute_basic_mux_config(dev_priv,
> > +
> _priv->perf.oa.mux_regs_len);
> > + if (!dev_priv->perf.oa.mux_regs) {
> > + DRM_DEBUG_DRIVER("No suitable MUX config for
> \"COMPUTE_BASIC\" metric set");
> > +
> > + /* EINVAL because *_register_sysfs already checked
> this
> > +  * and so it wouldn't have been advertised so
> userspace and
> > +  * so shouldn't have been requested
> > +  */
> > +  

[Intel-gfx] [PATCH] drm/i915: Move hangcheck code out from i915_irq.c

[Mika Kuoppala]

Create new file for hangcheck specific code, intel_hangcheck.c,
and move all related code in it.

v2: s/intel_engine_hangcheck/intel_engine (Chris)

No functional changes.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_drv.c|   1 +
 drivers/gpu/drm/i915/i915_drv.h|   1 +
 drivers/gpu/drm/i915/i915_irq.c| 417 --
 drivers/gpu/drm/i915/intel_engine_cs.c |   5 -
 drivers/gpu/drm/i915/intel_hangcheck.c | 450 +
 6 files changed, 453 insertions(+), 422 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hangcheck.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 240ce9a..0857e50 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -47,6 +47,7 @@ i915-y += i915_cmd_parser.o \
  i915_trace_points.o \
  intel_breadcrumbs.o \
  intel_engine_cs.o \
+ intel_hangcheck.o \
  intel_lrc.o \
  intel_mocs.o \
  intel_ringbuffer.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 48f4d21..9e5a547 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -830,6 +830,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
intel_irq_init(dev_priv);
+   intel_hangcheck_init(dev_priv);
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b8e72cd..6c0b0a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3002,6 +3002,7 @@ extern bool intel_has_gpu_reset(struct drm_i915_private 
*dev_priv);
 extern void i915_reset(struct drm_i915_private *dev_priv);
 extern int intel_guc_reset(struct drm_i915_private *dev_priv);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
+extern void intel_hangcheck_init(struct drm_i915_private *dev_priv);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
 extern unsigned long i915_mch_val(struct drm_i915_private *dev_priv);
 extern unsigned long i915_gfx_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ecd06d3..6d7505b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2848,420 +2848,6 @@ static void gen8_disable_vblank(struct drm_device *dev, 
unsigned int pipe)
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 }
 
-static bool
-ipehr_is_semaphore_wait(struct intel_engine_cs *engine, u32 ipehr)
-{
-   if (INTEL_GEN(engine->i915) >= 8) {
-   return (ipehr >> 23) == 0x1c;
-   } else {
-   ipehr &= ~MI_SEMAPHORE_SYNC_MASK;
-   return ipehr == (MI_SEMAPHORE_MBOX | MI_SEMAPHORE_COMPARE |
-MI_SEMAPHORE_REGISTER);
-   }
-}
-
-static struct intel_engine_cs *
-semaphore_wait_to_signaller_ring(struct intel_engine_cs *engine, u32 ipehr,
-u64 offset)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   struct intel_engine_cs *signaller;
-   enum intel_engine_id id;
-
-   if (INTEL_GEN(dev_priv) >= 8) {
-   for_each_engine(signaller, dev_priv, id) {
-   if (engine == signaller)
-   continue;
-
-   if (offset == 
signaller->semaphore.signal_ggtt[engine->hw_id])
-   return signaller;
-   }
-   } else {
-   u32 sync_bits = ipehr & MI_SEMAPHORE_SYNC_MASK;
-
-   for_each_engine(signaller, dev_priv, id) {
-   if(engine == signaller)
-   continue;
-
-   if (sync_bits == 
signaller->semaphore.mbox.wait[engine->hw_id])
-   return signaller;
-   }
-   }
-
-   DRM_DEBUG_DRIVER("No signaller ring found for %s, ipehr 0x%08x, offset 
0x%016llx\n",
-engine->name, ipehr, offset);
-
-   return ERR_PTR(-ENODEV);
-}
-
-static struct intel_engine_cs *
-semaphore_waits_for(struct intel_engine_cs *engine, u32 *seqno)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   void __iomem *vaddr;
-   u32 cmd, ipehr, head;
-   u64 offset = 0;
-   int i, backwards;
-
-   /*
-* This function does not support execlist mode - any attempt to
-* proceed further into this function will result in a kernel panic
-

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

[Chris Wilson]

On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote:
> 
> Merged to dinq, thanks for the review!

Almost as bad as me in forgetting to add the r-b. dim save us! :)
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move hangcheck code out from i915_irq.c

[Mika Kuoppala]

Chris Wilson  writes:

> On Tue, Nov 01, 2016 at 06:03:21PM +0200, Mika Kuoppala wrote:
>> Create new file for hangcheck specific code, intel_engine_hangcheck.c,
>> and move all the related code in it.
>> 
>> No functional changes.
>> 
>> Cc: Chris Wilson 
>> Cc: Joonas Lahtinen 
>> Cc: Tvrtko Ursulin 
>> Signed-off-by: Mika Kuoppala 
>> ---
>>  drivers/gpu/drm/i915/Makefile |   1 +
>>  drivers/gpu/drm/i915/i915_drv.c   |   1 +
>>  drivers/gpu/drm/i915/i915_drv.h   |   1 +
>>  drivers/gpu/drm/i915/i915_irq.c   | 417 
>>  drivers/gpu/drm/i915/intel_engine_cs.c|   5 -
>>  drivers/gpu/drm/i915/intel_engine_hangcheck.c | 450 
>> ++
>>  6 files changed, 453 insertions(+), 422 deletions(-)
>>  create mode 100644 drivers/gpu/drm/i915/intel_engine_hangcheck.c
>> 
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index 240ce9a..e772664 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -47,6 +47,7 @@ i915-y += i915_cmd_parser.o \
>>i915_trace_points.o \
>>intel_breadcrumbs.o \
>>intel_engine_cs.o \
>> +  intel_engine_hangcheck.o \
>
> Hmm. intel_engine_hangcheck. Please do include a signpost as to why this
> makes more sense than intel_hangcheck.c

intel_hangcheck.c makes more sense. New version soon.
-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] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

[Tvrtko Ursulin]

On 01/11/2016 16:16, Patchwork wrote:

== Series Details ==

Series: drm/i915: Allow shrinking of userptr objects once again (rev2)
URL   : https://patchwork.freedesktop.org/series/14675/
State : warning

== Summary ==

Series 14675v2 drm/i915: Allow shrinking of userptr objects once again
https://patchwork.freedesktop.org/api/1.0/series/14675/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)


DP bw issues..

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



fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21
fi-ilk-650   total:241  pass:182  dwarn:5   dfail:0   fail:0   skip:54
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34

659f3942757fa5e85f37a2cab9da8c94b8f16f7a drm-intel-nightly: 
2016y-11m-01d-14h-42m-02s UTC integration manifest
ec90e56 drm/i915: Allow shrinking of userptr objects once again


Merged to dinq, thanks for the review!

Regards,

Tvrtko

___
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 [1/2] drm/i915/gtt: Fix pte clear range (rev3)

[Mika Kuoppala]

Patchwork  writes:

> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev3)
> URL   : https://patchwork.freedesktop.org/series/14620/
> State : warning
>
> == Summary ==
>
> Series 14620v3 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/14620/revisions/3/mbox/
>
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> dmesg-warn -> PASS   (fi-ilk-650)
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)

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

>
> fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
> fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
> fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
> fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
> fi-ilk-650   total:241  pass:184  dwarn:3   dfail:0   fail:0   skip:54 
> fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
> fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
> fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
> fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
> fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
> fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
> fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
> fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 
>
> 659f3942757fa5e85f37a2cab9da8c94b8f16f7a drm-intel-nightly: 
> 2016y-11m-01d-14h-42m-02s UTC integration manifest
> b44a28b drm/i915/gtt: Mark tlbs dirty on clear
> de61fdd drm/i915/gtt: Fix pte clear range
>
> == Logs ==
>
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2876/
^^

This is awesome!

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Tue, Nov 01, 2016 at 10:49:14AM +0200, Jani Nikula wrote:
> On Sat, 29 Oct 2016, Manasi Navare  wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> > value at which link training failed, update the link status property
> > to "BAD" and use a lower link rate to prune the modes. It will redo
> > the modeset on the current mode at lower link rate or if the current
> > mode gets pruned due to lower link constraints then, it will send a
> > hotplug uevent for userspace to handle it.
> >
> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > 4.3.1.6.
> >
> > v2:
> > * Squashed a few patches (Jani Nikula)
> >
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c   |  4 ++
> >  drivers/gpu/drm/i915/intel_ddi.c  | 23 -
> >  drivers/gpu/drm/i915/intel_dp.c   | 74 
> > +--
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> >  drivers/gpu/drm/i915/intel_drv.h  |  5 +-
> >  5 files changed, 110 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 75ad01d..a3df3a4 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -519,6 +519,10 @@ static int handle_conflicting_encoders(struct 
> > drm_atomic_state *state,
> >connector_state);
> > if (ret)
> > return ret;
> > +
> > +   crtc_state = drm_atomic_get_existing_crtc_state(state, 
> > connector->state->crtc);
> > +   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > +   crtc_state->connectors_changed = true;
> > }
> >  
> > /*
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 938ac4d..319eeca 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > +   struct intel_connector *intel_connector = intel_dp->attached_connector;
> > +   struct drm_connector *connector = _connector->base;
> >  
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >  link_mst);
> > @@ -1694,7 +1696,26 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> > intel_ddi_init_dp_buf_reg(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > -   intel_dp_start_link_train(intel_dp);
> > +   if (!intel_dp_start_link_train(intel_dp)) {
> > +   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
> > count = %d",
> > + link_rate, lane_count);
> > +   intel_dp->link_train_failed = true;
> > +   intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
> > +   lane_count);
> > +   /* Schedule a Hotplug Uevent to userspace to start modeset */
> > +   schedule_work(_connector->modeset_retry_work);
> 
> This is not just about DDI. Need to do this for the other cases too.
>

Yes, first series will g out for adding this support for DDI, then more patches
to expand it to non DDI platforms.

 
> > +   } else {
> > +   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
> > count = %d",
> > + link_rate, lane_count);
> > +   intel_dp->link_train_failed = false;
> > +   intel_dp->fallback_link_rate_index = -1;
> > +   intel_dp->fallback_link_rate = 0;
> > +   intel_dp->fallback_lane_count = 0;
> > +   connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
> > +   intel_dp_set_link_status_property(connector,
> > + DRM_MODE_LINK_STATUS_GOOD);
> 
> Looks like you never actually read connector->link_status... Why do you
> need both connector->link_status and intel_dp->link_train_failed? Do you
> think you have 4 states? What are they? Can't this all be in sync with
> the property?
> 

This connector->link_status member of drm_Connector gets read in
drm_atomic_helper_check_modeset() in the driver where it reads this
and sets crtc_state->connector_Changed to true if this link_status
has changed.
This is required so that the driver does 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move hangcheck code out from i915_irq.c

[Chris Wilson]

On Tue, Nov 01, 2016 at 06:03:21PM +0200, Mika Kuoppala wrote:
> Create new file for hangcheck specific code, intel_engine_hangcheck.c,
> and move all the related code in it.
> 
> No functional changes.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/i915_drv.c   |   1 +
>  drivers/gpu/drm/i915/i915_drv.h   |   1 +
>  drivers/gpu/drm/i915/i915_irq.c   | 417 
>  drivers/gpu/drm/i915/intel_engine_cs.c|   5 -
>  drivers/gpu/drm/i915/intel_engine_hangcheck.c | 450 
> ++
>  6 files changed, 453 insertions(+), 422 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_engine_hangcheck.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 240ce9a..e772664 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -47,6 +47,7 @@ i915-y += i915_cmd_parser.o \
> i915_trace_points.o \
> intel_breadcrumbs.o \
> intel_engine_cs.o \
> +   intel_engine_hangcheck.o \

Hmm. intel_engine_hangcheck. Please do include a signpost as to why this
makes more sense than intel_hangcheck.c
-Chris

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move error state capture code out from i915_irq.c

[Chris Wilson]

On Tue, Nov 01, 2016 at 06:03:22PM +0200, Mika Kuoppala wrote:
> We have a place already for error handling and error
> state capture, i915_gpu_error.c. Move code to more
> appropriate file.

i915_gpu_error.c is conditionally compiled iff we want error capture. We
need reset handling irrespective of error capture. I don't think you
want that as your final destination.
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow shrinking of userptr objects once again (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Allow shrinking of userptr objects once again (rev2)
URL   : https://patchwork.freedesktop.org/series/14675/
State : warning

== Summary ==

Series 14675v2 drm/i915: Allow shrinking of userptr objects once again
https://patchwork.freedesktop.org/api/1.0/series/14675/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:182  dwarn:5   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

659f3942757fa5e85f37a2cab9da8c94b8f16f7a drm-intel-nightly: 
2016y-11m-01d-14h-42m-02s UTC integration manifest
ec90e56 drm/i915: Allow shrinking of userptr objects once again

== Logs ==

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

[Intel-gfx] [PATCH 1/2] drm/i915: Move hangcheck code out from i915_irq.c

[Mika Kuoppala]

Create new file for hangcheck specific code, intel_engine_hangcheck.c,
and move all the related code in it.

No functional changes.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_drv.c   |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |   1 +
 drivers/gpu/drm/i915/i915_irq.c   | 417 
 drivers/gpu/drm/i915/intel_engine_cs.c|   5 -
 drivers/gpu/drm/i915/intel_engine_hangcheck.c | 450 ++
 6 files changed, 453 insertions(+), 422 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_engine_hangcheck.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 240ce9a..e772664 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -47,6 +47,7 @@ i915-y += i915_cmd_parser.o \
  i915_trace_points.o \
  intel_breadcrumbs.o \
  intel_engine_cs.o \
+ intel_engine_hangcheck.o \
  intel_lrc.o \
  intel_mocs.o \
  intel_ringbuffer.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 48f4d21..9e5a547 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -830,6 +830,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
intel_irq_init(dev_priv);
+   intel_hangcheck_init(dev_priv);
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b8e72cd..6c0b0a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3002,6 +3002,7 @@ extern bool intel_has_gpu_reset(struct drm_i915_private 
*dev_priv);
 extern void i915_reset(struct drm_i915_private *dev_priv);
 extern int intel_guc_reset(struct drm_i915_private *dev_priv);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
+extern void intel_hangcheck_init(struct drm_i915_private *dev_priv);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
 extern unsigned long i915_mch_val(struct drm_i915_private *dev_priv);
 extern unsigned long i915_gfx_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ecd06d3..6d7505b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2848,420 +2848,6 @@ static void gen8_disable_vblank(struct drm_device *dev, 
unsigned int pipe)
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 }
 
-static bool
-ipehr_is_semaphore_wait(struct intel_engine_cs *engine, u32 ipehr)
-{
-   if (INTEL_GEN(engine->i915) >= 8) {
-   return (ipehr >> 23) == 0x1c;
-   } else {
-   ipehr &= ~MI_SEMAPHORE_SYNC_MASK;
-   return ipehr == (MI_SEMAPHORE_MBOX | MI_SEMAPHORE_COMPARE |
-MI_SEMAPHORE_REGISTER);
-   }
-}
-
-static struct intel_engine_cs *
-semaphore_wait_to_signaller_ring(struct intel_engine_cs *engine, u32 ipehr,
-u64 offset)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   struct intel_engine_cs *signaller;
-   enum intel_engine_id id;
-
-   if (INTEL_GEN(dev_priv) >= 8) {
-   for_each_engine(signaller, dev_priv, id) {
-   if (engine == signaller)
-   continue;
-
-   if (offset == 
signaller->semaphore.signal_ggtt[engine->hw_id])
-   return signaller;
-   }
-   } else {
-   u32 sync_bits = ipehr & MI_SEMAPHORE_SYNC_MASK;
-
-   for_each_engine(signaller, dev_priv, id) {
-   if(engine == signaller)
-   continue;
-
-   if (sync_bits == 
signaller->semaphore.mbox.wait[engine->hw_id])
-   return signaller;
-   }
-   }
-
-   DRM_DEBUG_DRIVER("No signaller ring found for %s, ipehr 0x%08x, offset 
0x%016llx\n",
-engine->name, ipehr, offset);
-
-   return ERR_PTR(-ENODEV);
-}
-
-static struct intel_engine_cs *
-semaphore_waits_for(struct intel_engine_cs *engine, u32 *seqno)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   void __iomem *vaddr;
-   u32 cmd, ipehr, head;
-   u64 offset = 0;
-   int i, backwards;
-
-   /*
-* This function does not support execlist mode - any attempt to
-* proceed further into this function will result in a kernel panic
- 

[Intel-gfx] [PATCH 2/2] drm/i915: Move error state capture code out from i915_irq.c

[Mika Kuoppala]

We have a place already for error handling and error
state capture, i915_gpu_error.c. Move code to more
appropriate file.

No functional changes.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c | 157 +-
 drivers/gpu/drm/i915/i915_irq.c   | 151 
 3 files changed, 155 insertions(+), 157 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6c0b0a6..88301fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3686,9 +3686,7 @@ static inline void i915_error_state_buf_release(
 {
kfree(eb->buf);
 }
-void i915_capture_error_state(struct drm_i915_private *dev_priv,
- u32 engine_mask,
- const char *error_msg);
+
 void i915_error_state_get(struct drm_device *dev,
  struct i915_error_state_file_priv *error_priv);
 void i915_error_state_put(struct i915_error_state_file_priv *error_priv);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 204093f..e307841 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1585,9 +1585,9 @@ static int capture(void *data)
  * out a structure which becomes available in debugfs for user level tools
  * to pick up.
  */
-void i915_capture_error_state(struct drm_i915_private *dev_priv,
- u32 engine_mask,
- const char *error_msg)
+static void i915_capture_error_state(struct drm_i915_private *dev_priv,
+u32 engine_mask,
+const char *error_msg)
 {
static bool warned;
struct drm_i915_error_state *error;
@@ -1640,6 +1640,108 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
}
 }
 
+static void i915_clear_error_registers(struct drm_i915_private *dev_priv)
+{
+   u32 eir;
+
+   if (!IS_GEN2(dev_priv))
+   I915_WRITE(PGTBL_ER, I915_READ(PGTBL_ER));
+
+   if (INTEL_GEN(dev_priv) < 4)
+   I915_WRITE(IPEIR, I915_READ(IPEIR));
+   else
+   I915_WRITE(IPEIR_I965, I915_READ(IPEIR_I965));
+
+   I915_WRITE(EIR, I915_READ(EIR));
+   eir = I915_READ(EIR);
+   if (eir) {
+   /*
+* some errors might have become stuck,
+* mask them.
+*/
+   DRM_DEBUG_DRIVER("EIR stuck: 0x%08x, masking\n", eir);
+   I915_WRITE(EMR, I915_READ(EMR) | eir);
+   I915_WRITE(IIR, I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT);
+   }
+}
+
+static void i915_error_wake_up(struct drm_i915_private *dev_priv)
+{
+   /*
+* Notify all waiters for GPU completion events that reset state has
+* been changed, and that they need to restart their wait after
+* checking for potential errors (and bail out to drop locks if there is
+* a gpu reset pending so that i915_error_work_func can acquire them).
+*/
+
+   /* Wake up __wait_seqno, potentially holding dev->struct_mutex. */
+   wake_up_all(_priv->gpu_error.wait_queue);
+
+   /* Wake up intel_crtc_wait_for_pending_flips, holding crtc->mutex. */
+   wake_up_all(_priv->pending_flip_queue);
+}
+
+/**
+ * i915_reset_and_wakeup - do process context error handling work
+ * @dev_priv: i915 device private
+ *
+ * Fire an error uevent so userspace can see that a hang or error
+ * was detected.
+ */
+static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv)
+{
+   struct kobject *kobj = _priv->drm.primary->kdev->kobj;
+   char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
+   char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
+   char *reset_done_event[] = { I915_ERROR_UEVENT "=0", NULL };
+
+   kobject_uevent_env(kobj, KOBJ_CHANGE, error_event);
+
+   DRM_DEBUG_DRIVER("resetting chip\n");
+   kobject_uevent_env(kobj, KOBJ_CHANGE, reset_event);
+
+   /*
+* In most cases it's guaranteed that we get here with an RPM
+* reference held, for example because there is a pending GPU
+* request that won't finish until the reset is done. This
+* isn't the case at least when we get here by doing a
+* simulated reset via debugs, so get an RPM reference.
+*/
+   intel_runtime_pm_get(dev_priv);
+   intel_prepare_reset(dev_priv);
+
+   do {
+   /*
+* All state reset _must_ be completed before we update the
+* reset counter, for otherwise waiters might miss the reset
+* pending state and not properly drop 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev3)
URL   : https://patchwork.freedesktop.org/series/14620/
State : warning

== Summary ==

Series 14620v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14620/revisions/3/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:184  dwarn:3   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

659f3942757fa5e85f37a2cab9da8c94b8f16f7a drm-intel-nightly: 
2016y-11m-01d-14h-42m-02s UTC integration manifest
b44a28b drm/i915/gtt: Mark tlbs dirty on clear
de61fdd drm/i915/gtt: Fix pte clear range

== Logs ==

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

Re: [Intel-gfx] [i-g-t PATCH v1 08/14] lib: Add igt_create_bo_with_dimensions

[Tvrtko Ursulin]

Hi,


On 02/03/16 14:00, Tomeu Vizoso wrote:

igt_create_bo_with_dimensions() is intended to abstract differences
between drivers in buffer object creation.

The driver-specific ioctls will be called if the driver that is being
tested can satisfy the needs of the calling subtest, or it will be
skipped otherwise.

Signed-off-by: Tomeu Vizoso 
---

 lib/igt_fb.c | 83 ++--
 lib/igt_fb.h |  6 +
 2 files changed, 65 insertions(+), 24 deletions(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index cd1605308308..0a3526f4e4ea 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -174,30 +174,66 @@ void igt_calc_fb_size(int fd, int width, int height, int 
bpp, uint64_t tiling,
*size_ret = size;
 }

+int igt_create_bo_with_dimensions(int fd, int width, int height,
+ uint32_t format, uint64_t modifier,
+ unsigned stride, unsigned *size_ret,
+ unsigned *stride_ret, bool *is_dumb)
+{
+   int bpp = igt_drm_format_to_bpp(format);
+   int bo;
+
+   igt_assert((modifier && stride) || (!modifier && !stride));
+
+   if (modifier) {
+   unsigned size, calculated_stride;
+
+   igt_calc_fb_size(fd, width, height, bpp, modifier, ,
+_stride);
+   if (stride == 0)
+   stride = calculated_stride;
+
+   if (is_dumb)
+   *is_dumb = false;
+
+   if (is_i915_device(fd)) {
+
+   bo = gem_create(fd, size);
+   gem_set_tiling(fd, bo, modifier, stride);


This is broken, gem_set_tiling does not take a fb modifier but an object 
tiling mode.


You can demonstrate the failure if you got a Skylake system with:

tests/kms_flip_tiling --r flip-changes-tiling-Yf

I would like to be able to tell you that all subtests there should pass, 
since they have been at some point, but I have a feeling that there are 
other breakages affecting it these days. :(


Regards,

Tvrtko



+
+   if (size_ret)
+   *size_ret = size;
+
+   if (stride_ret)
+   *stride_ret = stride;
+
+   return bo;
+   } else {
+   bool driver_has_tiling_support = false;
+
+   igt_require(driver_has_tiling_support);
+   return -EINVAL;
+   }
+   } else {
+   if (is_dumb)
+   *is_dumb = true;
+   return dumb_create(fd, width, height, bpp, stride_ret, 
size_ret);
+   }
+}
+
 /* helpers to create nice-looking framebuffers */
-static int create_bo_for_fb(int fd, int width, int height, int bpp,
+static int create_bo_for_fb(int fd, int width, int height, uint32_t format,
uint64_t tiling, unsigned bo_size,
unsigned bo_stride, uint32_t *gem_handle_ret,
-   unsigned *size_ret, unsigned *stride_ret)
+   unsigned *size_ret, unsigned *stride_ret,
+   bool *is_dumb)
 {
uint32_t gem_handle;
int ret = 0;
-   unsigned size, stride;
-
-   igt_calc_fb_size(fd, width, height, bpp, tiling, , );
-   if (bo_size == 0)
-   bo_size = size;
-   if (bo_stride == 0)
-   bo_stride = stride;
-
-   gem_handle = gem_create(fd, bo_size);

-   if (tiling == LOCAL_I915_FORMAT_MOD_X_TILED)
-   ret = __gem_set_tiling(fd, gem_handle, I915_TILING_X,
-  bo_stride);
+   gem_handle = igt_create_bo_with_dimensions(fd, width, height, format,
+  tiling, bo_stride, size_ret,
+  stride_ret, is_dumb);

-   *stride_ret = bo_stride;
-   *size_ret = bo_size;
*gem_handle_ret = gem_handle;

return ret;
@@ -501,17 +537,14 @@ igt_create_fb_with_bo_size(int fd, int width, int height,
   unsigned bo_stride)
 {
uint32_t fb_id;
-   int bpp;

memset(fb, 0, sizeof(*fb));

-   bpp = igt_drm_format_to_bpp(format);
-
-   igt_debug("%s(width=%d, height=%d, format=0x%x [bpp=%d], tiling=0x%"PRIx64", 
size=%d)\n",
- __func__, width, height, format, bpp, tiling, bo_size);
-   do_or_die(create_bo_for_fb(fd, width, height, bpp, tiling, bo_size,
+   igt_debug("%s(width=%d, height=%d, format=0x%x, tiling=0x%"PRIx64", 
size=%d)\n",
+ __func__, width, height, format, tiling, bo_size);
+   do_or_die(create_bo_for_fb(fd, width, height, format, tiling, bo_size,
   bo_stride, >gem_handle, >size,
-  >stride));
+   

[Intel-gfx] [RFC PATCH] drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs

[Jani Nikula]

If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to
check for the config everywhere.

Signed-off-by: Jani Nikula 

---

Just an idea on top of Patrik's patch.
---
 drivers/gpu/drm/arc/arcpgu_drv.c|  2 --
 drivers/gpu/drm/arm/hdlcd_drv.c |  2 --
 drivers/gpu/drm/arm/malidp_drv.c|  2 --
 drivers/gpu/drm/ast/ast_drv.c   |  2 --
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  2 --
 drivers/gpu/drm/bochs/bochs_drv.c   |  2 --
 drivers/gpu/drm/cirrus/cirrus_drv.c |  2 --
 drivers/gpu/drm/drm_fops.c  | 13 ++---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  2 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 --
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  2 --
 drivers/gpu/drm/gma500/psb_drv.c|  2 --
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
 drivers/gpu/drm/i810/i810_dma.c |  2 --
 drivers/gpu/drm/i810/i810_drv.c |  2 --
 drivers/gpu/drm/i915/i915_drv.c |  2 --
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  2 --
 drivers/gpu/drm/mgag200/mgag200_drv.c   |  2 --
 drivers/gpu/drm/msm/msm_drv.c   |  2 --
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  2 --
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  2 --
 drivers/gpu/drm/savage/savage_drv.c |  2 --
 drivers/gpu/drm/shmobile/shmob_drm_drv.c|  2 --
 drivers/gpu/drm/sis/sis_drv.c   |  2 --
 drivers/gpu/drm/sti/sti_drv.c   |  2 --
 drivers/gpu/drm/sun4i/sun4i_drv.c   |  2 --
 drivers/gpu/drm/tdfx/tdfx_drv.c |  2 --
 drivers/gpu/drm/tegra/drm.c |  2 --
 drivers/gpu/drm/tilcdc/tilcdc_drv.c |  2 --
 drivers/gpu/drm/udl/udl_drv.c   |  2 --
 drivers/gpu/drm/vc4/vc4_drv.c   |  2 --
 drivers/gpu/drm/via/via_drv.c   |  2 --
 drivers/gpu/drm/virtio/virtgpu_drv.c|  2 --
 include/drm/drmP.h  |  5 +
 35 files changed, 13 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 28e6471257d0..0b6eaa49a1db 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -65,9 +65,7 @@ static const struct file_operations arcpgu_drm_ops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = drm_ioctl,
-#ifdef CONFIG_COMPAT
.compat_ioctl = drm_compat_ioctl,
-#endif
.poll = drm_poll,
.read = drm_read,
.llseek = no_llseek,
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 6477d1a65266..59747ecaad54 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -268,9 +268,7 @@ static const struct file_operations fops = {
.open   = drm_open,
.release= drm_release,
.unlocked_ioctl = drm_ioctl,
-#ifdef CONFIG_COMPAT
.compat_ioctl   = drm_compat_ioctl,
-#endif
.poll   = drm_poll,
.read   = drm_read,
.llseek = noop_llseek,
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 9f4739452a25..d53b625b14fe 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -197,9 +197,7 @@ static const struct file_operations fops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = drm_ioctl,
-#ifdef CONFIG_COMPAT
.compat_ioctl = drm_compat_ioctl,
-#endif
.poll = drm_poll,
.read = drm_read,
.llseek = noop_llseek,
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index f54afd2113a9..fd7c9eec92e4 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -188,9 +188,7 @@ static const struct file_operations ast_fops = {
.unlocked_ioctl = drm_ioctl,
.mmap = ast_mmap,
.poll = drm_poll,
-#ifdef CONFIG_COMPAT
.compat_ioctl = drm_compat_ioctl,
-#endif
.read = drm_read,
 };
 
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 9f6222895212..cbd0070265c9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -749,9 +749,7 @@ static const struct file_operations fops = {
.open   = drm_open,
.release= drm_release,
.unlocked_ioctl = drm_ioctl,
-#ifdef CONFIG_COMPAT
.compat_ioctl   = drm_compat_ioctl,
-#endif
.poll   = drm_poll,
.read   = drm_read,
.llseek = no_llseek,
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 

Re: [Intel-gfx] [PATCH v2] drm/i915: Allow shrinking of userptr objects once again

[Chris Wilson]

On Tue, Nov 01, 2016 at 02:44:10PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects
> are backed by swap") stopped considering the userptr objects
> in shrinker callbacks.
> 
> Restore that so idle userptr objects can be discarded in order
> to free up memory.
> 
> One change further to what was introduced in 1bec9b0bda3d is
> to start considering userptr objects in oom but that should
> also be a correct thing to do.
> 
> v2: Introduce I915_GEM_OBJECT_IS_SHRINKABLE. (Chris Wilson)

I think dmabuf would benefit. Happy to have a followup (or sign off on
that myself).
 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by 
> swap")
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> Cc: 

Reviewed-by Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH v8 11/12] drm/i915: Add more Haswell OA metric sets

[Chris Wilson]

On Fri, Oct 28, 2016 at 03:14:29AM +0100, Robert Bragg wrote:
> This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
> and 'sampler balance' metric sets for Haswell.
> 
> The code is auto generated from an XML description of metric sets,
> currently maintained in gputop, ref:
> 
>  https://github.com/rib/gputop
>  > gputop-data/oa-*.xml
>  > scripts/i915-perf-kernelgen.py
> 
>  $ make -C gputop-data -f Makefile.xml
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_oa_hsw.c | 559 
> -
>  1 file changed, 558 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
> b/drivers/gpu/drm/i915/i915_oa_hsw.c
> index 6af25cf..4ddf756 100644
> --- a/drivers/gpu/drm/i915/i915_oa_hsw.c
> +++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
> @@ -31,9 +31,14 @@
>  
>  enum metric_set_id {
>   METRIC_SET_ID_RENDER_BASIC = 1,
> + METRIC_SET_ID_COMPUTE_BASIC,
> + METRIC_SET_ID_COMPUTE_EXTENDED,
> + METRIC_SET_ID_MEMORY_READS,
> + METRIC_SET_ID_MEMORY_WRITES,
> + METRIC_SET_ID_SAMPLER_BALANCE,
>  };
>  
> -int i915_oa_n_builtin_metric_sets_hsw = 1;
> +int i915_oa_n_builtin_metric_sets_hsw = 6;
>  
>  static const struct i915_oa_reg b_counter_config_render_basic[] = {
>   { _MMIO(0x2724), 0x0080 },
> @@ -112,6 +117,298 @@ get_render_basic_mux_config(struct drm_i915_private 
> *dev_priv,
>   return mux_config_render_basic;
>  }
>  
> +static const struct i915_oa_reg b_counter_config_compute_basic[] = {
> + { _MMIO(0x2710), 0x },
> + { _MMIO(0x2714), 0x0080 },
> + { _MMIO(0x2718), 0x },
> + { _MMIO(0x271c), 0x },
> + { _MMIO(0x2720), 0x },
> + { _MMIO(0x2724), 0x0080 },
> + { _MMIO(0x2728), 0x },
> + { _MMIO(0x272c), 0x },
> + { _MMIO(0x2740), 0x },
> + { _MMIO(0x2744), 0x },
> + { _MMIO(0x2748), 0x },
> + { _MMIO(0x274c), 0x },
> + { _MMIO(0x2750), 0x },
> + { _MMIO(0x2754), 0x },
> + { _MMIO(0x2758), 0x },
> + { _MMIO(0x275c), 0x },
> + { _MMIO(0x236c), 0x },
> +};
> +
> +static const struct i915_oa_reg mux_config_compute_basic[] = {
> + { _MMIO(0x253a4), 0x },
> + { _MMIO(0x2681c), 0x01f00800 },
> + { _MMIO(0x26820), 0x1000 },
> + { _MMIO(0x2781c), 0x01f00800 },
> + { _MMIO(0x26520), 0x0007 },
> + { _MMIO(0x265a0), 0x0007 },
> + { _MMIO(0x25380), 0x0010 },
> + { _MMIO(0x2538c), 0x0030 },
> + { _MMIO(0x25384), 0xaa8a },
> + { _MMIO(0x25404), 0x },
> + { _MMIO(0x26800), 0x4202 },
> + { _MMIO(0x26808), 0x00605817 },
> + { _MMIO(0x2680c), 0x10001005 },
> + { _MMIO(0x26804), 0x },
> + { _MMIO(0x27800), 0x0102 },
> + { _MMIO(0x27808), 0x0c0701e0 },
> + { _MMIO(0x2780c), 0x000200a0 },
> + { _MMIO(0x27804), 0x },
> + { _MMIO(0x26484), 0x4400 },
> + { _MMIO(0x26704), 0x4400 },
> + { _MMIO(0x26500), 0x0006 },
> + { _MMIO(0x26510), 0x0001 },
> + { _MMIO(0x26504), 0x8800 },
> + { _MMIO(0x26580), 0x0006 },
> + { _MMIO(0x26590), 0x0020 },
> + { _MMIO(0x26584), 0x },
> + { _MMIO(0x26104), 0x5582 },
> + { _MMIO(0x26184), 0xaa86 },
> + { _MMIO(0x25420), 0x08320c83 },
> + { _MMIO(0x25424), 0x06820c83 },
> + { _MMIO(0x2541c), 0x },
> + { _MMIO(0x25428), 0x0c03 },
> +};
> +
> +static const struct i915_oa_reg *
> +get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
> +  int *len)
> +{
> + *len = ARRAY_SIZE(mux_config_compute_basic);
> + return mux_config_compute_basic;
> +}

> @@ -140,6 +437,106 @@ int i915_oa_select_metric_set_hsw(struct 
> drm_i915_private *dev_priv)
>   ARRAY_SIZE(b_counter_config_render_basic);
>  
>   return 0;
> + case METRIC_SET_ID_COMPUTE_BASIC:
> + dev_priv->perf.oa.mux_regs =
> + get_compute_basic_mux_config(dev_priv,
> +  
> _priv->perf.oa.mux_regs_len);
> + if (!dev_priv->perf.oa.mux_regs) {
> + DRM_DEBUG_DRIVER("No suitable MUX config for 
> \"COMPUTE_BASIC\" metric set");
> +
> + /* EINVAL because *_register_sysfs already checked this
> +  * and so it wouldn't have been advertised so userspace 
> and
> +  * so shouldn't have been requested
> +  */
> + return -EINVAL;
> + }
> +
> + dev_priv->perf.oa.b_counter_regs =
> + b_counter_config_compute_basic;
> + dev_priv->perf.oa.b_counter_regs_len =
> + 

Re: [Intel-gfx] [PATCH 00/26] drm/i915: A game of OCD dominoes

[Ville Syrjälä]

On Mon, Oct 31, 2016 at 08:56:34PM +, Chris Wilson wrote:
> On Mon, Oct 31, 2016 at 10:36:59PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > I pretty much just wanted to store struct intel_crtc * instead
> > of struct drm_crtc * in pipe_to_crtc_mapping[] & co. but to
> > achieve it cleanly I ended up chasing quite few different things
> > that were accepting the wrong kind of type. And once I had
> > sorted out those mappign arrays, I had ended up in the old
> > watermark code which kept me busy for another good while.
> > Eventually I was able to claw my way back to sanity and I
> > decided to stop.
> > 
> > I'm going to blame Daniel for getting me on this track by
> > suggesting that I should pass dev_priv to the plane
> > constructos. That was enough of a trigger to get me started.
> > 
> > Entire series available here:
> > git://github.com/vsyrjala/linux.git dev_priv_intel_crtc_cleanup
> > 
> > Ville Syrjälä (26):
> >   drm/i915: Pass dev_priv to plane constructors
> >   drm/i915: Pass dev_priv to skl_init_scalers()
> >   drm/i915: Pass intel_crtc to intel_crtc_active()
> >   drm/i915: Pass intel_crtc to update_wm functions
> >   drm/i915: Use struct intel_crtc in legacy platform wm code
> >   drm/i915: Store struct intel_crtc * in {pipe,plane}_to_crtc_mapping[]
> >   drm/i915: Pass dev_priv to intel_wait_for_vblank()
> >   drm/i915: Pass dev_priv to vlv force pll functions
> >   drm/i915: Pass dev_priv to g4x wm functions
> >   drm/i915: Pass dev_priv to intel_get_crtc_for_pipe()
> >   drm/i915: Always use intel_get_crtc_for_pipe()
> >   drm/i915: Pass dev_priv to intel_crtc_init()
> >   drm/i915: Pass dev_priv to cdclk update funcs
> >   drm/i915: Pass dev_priv to .get_display_clock_speed()
> >   drm/i915: Pass dev_priv to IS_MOBILE()
> >   drm/i915: Pass dev_priv to IS_PINEVIEW()
> >   drm/i915: Pass dev_priv to i915_pineview_get_mem_freq() and
> > i915_ironlake_get_mem_freq()
> >   drm/i915: Pass dev_priv to .get_fifo_size()
> >   drm/i915: Pass dev_priv to HAS_FW_BLC
> >   drm/i915: Pass dev_priv to IS_BROADWATER/IS_CRESTLINE
> >   drm/i915: Pass dev_priv to rest of IS_FOO() macros for the old
> > platforms
> >   drm/i915: Pass dev_priv to single_enabled_crtc()
> >   drm/i915: Pass dev_priv to init_clock_gating
> >   drm/i915: Pass dev_priv to intel_suspend_hw()
> >   drm/i915: Pass dev_priv to ilk_setup_wm_latency() & co.
> >   drm/i915: Pass dev_priv to intel_init_pm()
> 
> All looked reasonable and beguiling in their simplicty. Nice trimming.
> Reviewed-by: Chris Wilson 

Entire series pushed to dinq. Thanks for the review.

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

[Intel-gfx] [PATCH v2] drm/i915: Allow shrinking of userptr objects once again

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects
are backed by swap") stopped considering the userptr objects
in shrinker callbacks.

Restore that so idle userptr objects can be discarded in order
to free up memory.

One change further to what was introduced in 1bec9b0bda3d is
to start considering userptr objects in oom but that should
also be a correct thing to do.

v2: Introduce I915_GEM_OBJECT_IS_SHRINKABLE. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Fixes: 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by 
swap")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: 
---
 drivers/gpu/drm/i915/i915_drv.h  | 7 +++
 drivers/gpu/drm/i915/i915_gem.c  | 3 ++-
 drivers/gpu/drm/i915/i915_gem_internal.c | 3 ++-
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem_userptr.c  | 3 ++-
 5 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 086396e16de7..0525e5b448b0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2181,6 +2181,7 @@ enum hdmi_force_audio {
 struct drm_i915_gem_object_ops {
unsigned int flags;
 #define I915_GEM_OBJECT_HAS_STRUCT_PAGE 0x1
+#define I915_GEM_OBJECT_IS_SHRINKABLE   0x2
 
/* Interface between the GEM object and its backing storage.
 * get_pages() is called once prior to the use of the associated set
@@ -2430,6 +2431,12 @@ i915_gem_object_has_struct_page(const struct 
drm_i915_gem_object *obj)
 }
 
 static inline bool
+i915_gem_object_is_shrinkable(const struct drm_i915_gem_object *obj)
+{
+   return obj->ops->flags & I915_GEM_OBJECT_IS_SHRINKABLE;
+}
+
+static inline bool
 i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
 {
return obj->active_count;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cbbfaa7761b9..e1bf456c62c3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4146,7 +4146,8 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
 }
 
 static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
-   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE,
+   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
+I915_GEM_OBJECT_IS_SHRINKABLE,
.get_pages = i915_gem_object_get_pages_gtt,
.put_pages = i915_gem_object_put_pages_gtt,
 };
diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c 
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 1b0607a44a9a..4b3ff3e5b911 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -132,7 +132,8 @@ static void i915_gem_object_put_pages_internal(struct 
drm_i915_gem_object *obj,
 }
 
 static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
-   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE,
+   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
+I915_GEM_OBJECT_IS_SHRINKABLE,
.get_pages = i915_gem_object_get_pages_internal,
.put_pages = i915_gem_object_put_pages_internal,
 };
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index f988652f1e26..87dd27d5146c 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -83,8 +83,8 @@ static bool can_release_pages(struct drm_i915_gem_object *obj)
if (!obj->mm.pages)
return false;
 
-   /* Only shmemfs objects are backed by swap */
-   if (!obj->base.filp)
+   /* Consider only shrinkable ojects. */
+   if (!i915_gem_object_is_shrinkable(obj))
return false;
 
/* Only report true if by unbinding the object and putting its pages
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 9bf44b5bca10..64261639f547 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -707,7 +707,8 @@ i915_gem_userptr_dmabuf_export(struct drm_i915_gem_object 
*obj)
 }
 
 static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
-   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE,
+   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
+I915_GEM_OBJECT_IS_SHRINKABLE,
.get_pages = i915_gem_userptr_get_pages,
.put_pages = i915_gem_userptr_put_pages,
.dmabuf_export = i915_gem_userptr_dmabuf_export,
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

[Chris Wilson]

On Tue, Nov 01, 2016 at 02:29:39PM +, Tvrtko Ursulin wrote:
> 
> On 01/11/2016 13:52, Chris Wilson wrote:
> >On Tue, Nov 01, 2016 at 01:28:06PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects
> >>are backed by swap") stopped considering the userptr objects
> >>in shrinker callbacks.
> >>
> >>Restore that so idle userptr objects can be discarded in order
> >>to free up memory.
> >>
> >>One change further to what was introduced in 1bec9b0bda3d is
> >>to start considering userptr objects in oom but that should
> >>also be a correct thing to do.
> >>
> >>Signed-off-by: Tvrtko Ursulin 
> >>Fixes: 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by 
> >>swap")
> >>Cc: Chris Wilson 
> >>Cc: Joonas Lahtinen 
> >>Cc: Mika Kuoppala 
> >>Cc: 
> >>---
> >> drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> >>b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> >>index 0993afc0e725..dfca1f6b3630 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> >>+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> >>@@ -83,8 +83,8 @@ static bool can_release_pages(struct drm_i915_gem_object 
> >>*obj)
> >>if (!obj->mm.pages)
> >>return false;
> >>
> >>-   /* Only shmemfs objects are backed by swap */
> >>-   if (!obj->base.filp)
> >>+   /* shmemfs and userptr objects are backed by swap */
> >>+   if (!obj->base.filp && !obj->userptr.mm)
> >
> >Hmm. Another sticking point if we want to use the union again.
> >
> >How about obj->ops->flags & I915_GEM_OBJECT_HAS_BACKING_STORE ?
> >Or I915_GEM_OBJECT_CAN_SWAP since we want this for i915_gem_internal.c
> >as well, and that techinically doesn't have a backing store but can be
> >reaped. Hmm.
> >
> >if (!(obj->ops->flags & I915_GEM_OBJECT_HAS_BACKING_STORE ||
> >  obj->mm.madv == I915_MADV_DONTNEED))
> 
> Hm I915_GEM_OBJECT_HAS_STRUCT_PAGE happens to be right - shm,
> userptr and internal. But that would be bad. Neither do I like
> HAS_BACKING_STORE.

Yeah, I was trying to keep the concept separate from has-struct-page
just in case it made it easier for future extension.
 
> Maybe I915_GEM_OBJECT_IS_SHRINKABLE, fully dumb and explicit?

Dumb describes me best, yup.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

[Tvrtko Ursulin]

On 01/11/2016 13:52, Chris Wilson wrote:

On Tue, Nov 01, 2016 at 01:28:06PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects
are backed by swap") stopped considering the userptr objects
in shrinker callbacks.

Restore that so idle userptr objects can be discarded in order
to free up memory.

One change further to what was introduced in 1bec9b0bda3d is
to start considering userptr objects in oom but that should
also be a correct thing to do.

Signed-off-by: Tvrtko Ursulin 
Fixes: 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by 
swap")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 0993afc0e725..dfca1f6b3630 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -83,8 +83,8 @@ static bool can_release_pages(struct drm_i915_gem_object *obj)
if (!obj->mm.pages)
return false;

-   /* Only shmemfs objects are backed by swap */
-   if (!obj->base.filp)
+   /* shmemfs and userptr objects are backed by swap */
+   if (!obj->base.filp && !obj->userptr.mm)


Hmm. Another sticking point if we want to use the union again.

How about obj->ops->flags & I915_GEM_OBJECT_HAS_BACKING_STORE ?
Or I915_GEM_OBJECT_CAN_SWAP since we want this for i915_gem_internal.c
as well, and that techinically doesn't have a backing store but can be
reaped. Hmm.

if (!(obj->ops->flags & I915_GEM_OBJECT_HAS_BACKING_STORE ||
  obj->mm.madv == I915_MADV_DONTNEED))


Hm I915_GEM_OBJECT_HAS_STRUCT_PAGE happens to be right - shm, userptr 
and internal. But that would be bad. Neither do I like HAS_BACKING_STORE.


Maybe I915_GEM_OBJECT_IS_SHRINKABLE, fully dumb and explicit?

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Export a function to flush the context upon pinning

[Chris Wilson]

On Mon, Oct 31, 2016 at 03:28:08PM +, Matthew Auld wrote:
> On 30 October 2016 at 13:28, Chris Wilson  wrote:
> > For legacy contexts we employ an optimisation to only flush the context
> > when binding into the global GTT. This avoids stalling onthe GPU when
> > reloading an active context. Wrap this detail up into a helper and
> > export it for a potential third user. (Longer term, context pinning
> > needs to be reworked as the current handling of switch context pins too
> > late and so risks eviction and corrupting the request. Plans, plans, plans.)
> >
> > Signed-off-by: Chris Wilson 
> s/onthe/on the/
> Reviewed-by: Matthew Auld 

Ta, one less thing for i915_perf.
-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] ✗ Fi.CI.BAT: warning for drm/i915: A game of OCD dominoes

[Ville Syrjälä]

On Tue, Nov 01, 2016 at 01:46:00PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: A game of OCD dominoes
> URL   : https://patchwork.freedesktop.org/series/14634/
> State : warning
> 
> == Summary ==
> 
> Series 14634v1 drm/i915: A game of OCD dominoes
> https://patchwork.freedesktop.org/api/1.0/series/14634/revisions/1/mbox/
> 
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-legacy:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_pipe_crc_basic:
> Subgroup bad-nb-words-3:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup bad-pipe:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup bad-source:
> pass   -> DMESG-WARN (fi-ilk-650)

Just wanted to double check if these remain during a second run and they
did.

[  229.222657] [drm:intel_dp_detect [i915]] [CONNECTOR:45:DP-1]
[  229.223142] [drm:intel_dp_read_dpcd [i915]] DPCD: 11 00 01 03 11 00 01 00 02 
02 06 00 00 00 00
[  229.223492] [drm:intel_dp_detect [i915]] Display Port TPS3 support: source 
no, sink no
[  229.223510] [drm:intel_dp_print_rates [i915]] source rates: 162000, 27
[  229.223511] [ cut here ]
[  229.223527] WARNING: CPU: 0 PID: 8223 at drivers/gpu/drm/i915/intel_dp.c:146 
intel_dp_max_link_bw.isra.7+0x28/0x50 [i915]
[  229.223528] invalid max DP link bw val 0, using 1.62Gbps

Dunno if the cable fell out part way or if they monitor is just rotting
from the inside, or why it seems to develop new symptoms every week.

> Subgroup hang-read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-a:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-ilk-650)
> 
> fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
> fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
> fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
> fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
> fi-ilk-650   total:241  pass:182  dwarn:5   dfail:0   fail:0   skip:54 
> fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
> fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
> fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
> fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
> fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
> fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
> fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
> fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 
> 
> f38d5bab1be4078239d2cf7b20c84a574e522263 drm-intel-nightly: 
> 2016y-11m-01d-11h-22m-30s UTC integration manifest
> 38b589a drm/i915: Pass dev_priv to intel_init_pm()
> b4990a3 drm/i915: Pass dev_priv to ilk_setup_wm_latency() & co.
> 556 drm/i915: Pass dev_priv to intel_suspend_hw()
> 8e2ab09 drm/i915: Pass dev_priv to init_clock_gating
> 2528ec4 drm/i915: Pass dev_priv to single_enabled_crtc()
> 90376f6 drm/i915: Pass dev_priv to rest of IS_FOO() macros for the old 
> platforms
> e0f8951 drm/i915: Pass dev_priv to IS_BROADWATER/IS_CRESTLINE
> f18fa92 drm/i915: Pass dev_priv to HAS_FW_BLC
> 7dcff24 drm/i915: Pass dev_priv to .get_fifo_size()
> a31ed64 drm/i915: Pass dev_priv to i915_pineview_get_mem_freq() and 
> i915_ironlake_get_mem_freq()
> 8a5014d drm/i915: Pass dev_priv to IS_PINEVIEW()
> 36eb40f drm/i915: Pass dev_priv to IS_MOBILE()
> 1f5f721 drm/i915: Pass dev_priv to .get_display_clock_speed()
> add61ef drm/i915: Pass dev_priv to cdclk update funcs
> 6bedc8a drm/i915: Pass dev_priv to intel_crtc_init()
> a2e526a drm/i915: Always use intel_get_crtc_for_pipe()
> 78997a8 drm/i915: Pass dev_priv to intel_get_crtc_for_pipe()
> ef10cbb drm/i915: Pass dev_priv to g4x wm functions
> 142de6f drm/i915: Pass dev_priv to vlv force pll functions
> ab8a43e drm/i915: Pass dev_priv to intel_wait_for_vblank()
> c9fbaa6 drm/i915: Store struct intel_crtc * in {pipe, plane}_to_crtc_mapping[]
> a5d258f drm/i915: Use struct intel_crtc in legacy platform wm code
> 4ac1197 drm/i915: Pass intel_crtc to update_wm functions
> bc7ad21 drm/i915: Pass intel_crtc to intel_crtc_active()
> 0200c1f drm/i915: Pass dev_priv to skl_init_scalers()
> 7ce6429 drm/i915: Pass dev_priv to plane constructors
> 
> == Logs ==
> 
> For more details see: 

Re: [Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

[Chris Wilson]

On Tue, Nov 01, 2016 at 01:28:06PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects
> are backed by swap") stopped considering the userptr objects
> in shrinker callbacks.
> 
> Restore that so idle userptr objects can be discarded in order
> to free up memory.
> 
> One change further to what was introduced in 1bec9b0bda3d is
> to start considering userptr objects in oom but that should
> also be a correct thing to do.
> 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by 
> swap")
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> Cc: 
> ---
>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 0993afc0e725..dfca1f6b3630 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -83,8 +83,8 @@ static bool can_release_pages(struct drm_i915_gem_object 
> *obj)
>   if (!obj->mm.pages)
>   return false;
>  
> - /* Only shmemfs objects are backed by swap */
> - if (!obj->base.filp)
> + /* shmemfs and userptr objects are backed by swap */
> + if (!obj->base.filp && !obj->userptr.mm)

Hmm. Another sticking point if we want to use the union again.

How about obj->ops->flags & I915_GEM_OBJECT_HAS_BACKING_STORE ?
Or I915_GEM_OBJECT_CAN_SWAP since we want this for i915_gem_internal.c
as well, and that techinically doesn't have a backing store but can be
reaped. Hmm.

if (!(obj->ops->flags & I915_GEM_OBJECT_HAS_BACKING_STORE ||
  obj->mm.madv == I915_MADV_DONTNEED))

-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A game of OCD dominoes

[Patchwork]

== Series Details ==

Series: drm/i915: A game of OCD dominoes
URL   : https://patchwork.freedesktop.org/series/14634/
State : warning

== Summary ==

Series 14634v1 drm/i915: A game of OCD dominoes
https://patchwork.freedesktop.org/api/1.0/series/14634/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-pipe:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:182  dwarn:5   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

f38d5bab1be4078239d2cf7b20c84a574e522263 drm-intel-nightly: 
2016y-11m-01d-11h-22m-30s UTC integration manifest
38b589a drm/i915: Pass dev_priv to intel_init_pm()
b4990a3 drm/i915: Pass dev_priv to ilk_setup_wm_latency() & co.
556 drm/i915: Pass dev_priv to intel_suspend_hw()
8e2ab09 drm/i915: Pass dev_priv to init_clock_gating
2528ec4 drm/i915: Pass dev_priv to single_enabled_crtc()
90376f6 drm/i915: Pass dev_priv to rest of IS_FOO() macros for the old platforms
e0f8951 drm/i915: Pass dev_priv to IS_BROADWATER/IS_CRESTLINE
f18fa92 drm/i915: Pass dev_priv to HAS_FW_BLC
7dcff24 drm/i915: Pass dev_priv to .get_fifo_size()
a31ed64 drm/i915: Pass dev_priv to i915_pineview_get_mem_freq() and 
i915_ironlake_get_mem_freq()
8a5014d drm/i915: Pass dev_priv to IS_PINEVIEW()
36eb40f drm/i915: Pass dev_priv to IS_MOBILE()
1f5f721 drm/i915: Pass dev_priv to .get_display_clock_speed()
add61ef drm/i915: Pass dev_priv to cdclk update funcs
6bedc8a drm/i915: Pass dev_priv to intel_crtc_init()
a2e526a drm/i915: Always use intel_get_crtc_for_pipe()
78997a8 drm/i915: Pass dev_priv to intel_get_crtc_for_pipe()
ef10cbb drm/i915: Pass dev_priv to g4x wm functions
142de6f drm/i915: Pass dev_priv to vlv force pll functions
ab8a43e drm/i915: Pass dev_priv to intel_wait_for_vblank()
c9fbaa6 drm/i915: Store struct intel_crtc * in {pipe, plane}_to_crtc_mapping[]
a5d258f drm/i915: Use struct intel_crtc in legacy platform wm code
4ac1197 drm/i915: Pass intel_crtc to update_wm functions
bc7ad21 drm/i915: Pass intel_crtc to intel_crtc_active()
0200c1f drm/i915: Pass dev_priv to skl_init_scalers()
7ce6429 drm/i915: Pass dev_priv to plane constructors

== Logs ==

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

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Ville Syrjälä]

On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
> > On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
> >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> >> replace the old for_each_xxx_in_state ones. This is useful for >1 flip
> >> depth and getting rid of all xxx->state dereferences.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/drm_atomic.c |  6 +++
> >>  drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
> >>  drivers/gpu/drm/i915/intel_display.c | 11 ++---
> >>  include/drm/drm_atomic.h | 81 
> >> ++--
> >>  include/drm/drm_atomic_helper.h  |  3 ++
> >>  5 files changed, 142 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 5dd70540219c..120775fcfb70 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state 
> >> *state,
> >>return ERR_PTR(-ENOMEM);
> >>  
> >>state->crtcs[index].state = crtc_state;
> >> +  state->crtcs[index].old_state = crtc->state;
> >> +  state->crtcs[index].new_state = crtc_state;
> >>state->crtcs[index].ptr = crtc;
> >>crtc_state->state = state;
> >>  
> >> @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
> >> *state,
> >>  
> >>state->planes[index].state = plane_state;
> >>state->planes[index].ptr = plane;
> >> +  state->planes[index].old_state = plane->state;
> >> +  state->planes[index].new_state = plane_state;
> >>plane_state->state = state;
> >>  
> >>DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
> >> @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> >> *state,
> >>  
> >>drm_connector_reference(connector);
> >>state->connectors[index].state = connector_state;
> >> +  state->connectors[index].old_state = connector->state;
> >> +  state->connectors[index].new_state = connector_state;
> >>state->connectors[index].ptr = connector;
> >>connector_state->state = state;
> >>  
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 07b432f43b98..fcb6e5b55217 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
> >>   *
> >>   * See also:
> >>   * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
> >> - * drm_atomic_helper_resume()
> >> + * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
> >>   */
> >>  struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
> >>  {
> >> @@ -2536,6 +2536,52 @@ unlock:
> >>  EXPORT_SYMBOL(drm_atomic_helper_suspend);
> >>  
> >>  /**
> >> + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
> >> + * @state: duplicated atomic state to commit
> >> + * @ctx: pointer to acquire_ctx to use for commit.
> >> + * @nonblock: commit the state non-blocking.
> >> + *
> >> + * The state returned by drm_atomic_helper_duplicate_state() and
> >> + * drm_atomic_helper_suspend() is partially invalid, and needs to
> >> + * be fixed up before commit.
> > So the old_state pointers are potentially invalid because whatever->state
> > may have changed since we duplicated the state?
> 
> Yes when you use drm_atomic_helper_duplicate_state, and commit a different 
> state before committing the duplicated state.
> This only happens during suspend/resume and gpu reset.

Should we maybe have something like drm_atomic_refresh_old_state(state)?
Would allow the caller then to check something in the old vs. new state
before committing?

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

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Maarten Lankhorst]

Op 01-11-16 om 14:09 schreef Ville Syrjälä:
> On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
>> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
>> replace the old for_each_xxx_in_state ones. This is useful for >1 flip
>> depth and getting rid of all xxx->state dereferences.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic.c |  6 +++
>>  drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
>>  drivers/gpu/drm/i915/intel_display.c | 11 ++---
>>  include/drm/drm_atomic.h | 81 
>> ++--
>>  include/drm/drm_atomic_helper.h  |  3 ++
>>  5 files changed, 142 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 5dd70540219c..120775fcfb70 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
>>  return ERR_PTR(-ENOMEM);
>>  
>>  state->crtcs[index].state = crtc_state;
>> +state->crtcs[index].old_state = crtc->state;
>> +state->crtcs[index].new_state = crtc_state;
>>  state->crtcs[index].ptr = crtc;
>>  crtc_state->state = state;
>>  
>> @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
>> *state,
>>  
>>  state->planes[index].state = plane_state;
>>  state->planes[index].ptr = plane;
>> +state->planes[index].old_state = plane->state;
>> +state->planes[index].new_state = plane_state;
>>  plane_state->state = state;
>>  
>>  DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
>> @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
>> *state,
>>  
>>  drm_connector_reference(connector);
>>  state->connectors[index].state = connector_state;
>> +state->connectors[index].old_state = connector->state;
>> +state->connectors[index].new_state = connector_state;
>>  state->connectors[index].ptr = connector;
>>  connector_state->state = state;
>>  
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 07b432f43b98..fcb6e5b55217 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
>>   *
>>   * See also:
>>   * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
>> - * drm_atomic_helper_resume()
>> + * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
>>   */
>>  struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
>>  {
>> @@ -2536,6 +2536,52 @@ unlock:
>>  EXPORT_SYMBOL(drm_atomic_helper_suspend);
>>  
>>  /**
>> + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
>> + * @state: duplicated atomic state to commit
>> + * @ctx: pointer to acquire_ctx to use for commit.
>> + * @nonblock: commit the state non-blocking.
>> + *
>> + * The state returned by drm_atomic_helper_duplicate_state() and
>> + * drm_atomic_helper_suspend() is partially invalid, and needs to
>> + * be fixed up before commit.
> So the old_state pointers are potentially invalid because whatever->state
> may have changed since we duplicated the state?

Yes when you use drm_atomic_helper_duplicate_state, and commit a different 
state before committing the duplicated state.
This only happens during suspend/resume and gpu reset.

~Maarten

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

[Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

[Mika Kuoppala]

Comparing pte index to a number of entries is wrong
when clearing a range of pte entries. Use end marker
of 'one past' to correctly point adequate number of
ptes to the scratch page.

v2: assert early instead of warning late (Chris)
v3: removed consts (Joonas)

Fixes: d209b9c3cd28 ("drm/i915/gtt: Split gen8_ppgtt_clear_pte_range")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98282
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michel Thierry 
Cc: Michał Winiarski 
Reported-by: Mike Lothian 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
Tested-by: Mike Lothian 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e7afad5..3b968ec 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -716,9 +716,9 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space 
*vm,
uint64_t length)
 {
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
-   unsigned int pte_start = gen8_pte_index(start);
unsigned int num_entries = gen8_pte_count(start, length);
-   uint64_t pte;
+   unsigned int pte = gen8_pte_index(start);
+   unsigned int pte_end = pte + num_entries;
gen8_pte_t *pt_vaddr;
gen8_pte_t scratch_pte = gen8_pte_encode(vm->scratch_page.daddr,
 I915_CACHE_LLC);
@@ -726,7 +726,9 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space 
*vm,
if (WARN_ON(!px_page(pt)))
return false;
 
-   bitmap_clear(pt->used_ptes, pte_start, num_entries);
+   GEM_BUG_ON(pte_end > GEN8_PTES);
+
+   bitmap_clear(pt->used_ptes, pte, num_entries);
 
if (bitmap_empty(pt->used_ptes, GEN8_PTES)) {
free_pt(vm->dev, pt);
@@ -735,8 +737,8 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space 
*vm,
 
pt_vaddr = kmap_px(pt);
 
-   for (pte = pte_start; pte < num_entries; pte++)
-   pt_vaddr[pte] = scratch_pte;
+   while (pte < pte_end)
+   pt_vaddr[pte++] = scratch_pte;
 
kunmap_px(ppgtt, pt_vaddr);
 
-- 
2.7.4

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

[Intel-gfx] [PATCH] drm/i915: Allow shrinking of userptr objects once again

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Commit 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects
are backed by swap") stopped considering the userptr objects
in shrinker callbacks.

Restore that so idle userptr objects can be discarded in order
to free up memory.

One change further to what was introduced in 1bec9b0bda3d is
to start considering userptr objects in oom but that should
also be a correct thing to do.

Signed-off-by: Tvrtko Ursulin 
Fixes: 1bec9b0bda3d ("drm/i915/shrinker: Only shmemfs objects are backed by 
swap")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 0993afc0e725..dfca1f6b3630 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -83,8 +83,8 @@ static bool can_release_pages(struct drm_i915_gem_object *obj)
if (!obj->mm.pages)
return false;
 
-   /* Only shmemfs objects are backed by swap */
-   if (!obj->base.filp)
+   /* shmemfs and userptr objects are backed by swap */
+   if (!obj->base.filp && !obj->userptr.mm)
return false;
 
/* Only report true if by unbinding the object and putting its pages
-- 
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: warning for drm/i915: Improve lockdep tracking for obj->mm.lock

[Patchwork]

== Series Details ==

Series: drm/i915: Improve lockdep tracking for obj->mm.lock
URL   : https://patchwork.freedesktop.org/series/14672/
State : warning

== Summary ==

Series 14672v1 drm/i915: Improve lockdep tracking for obj->mm.lock
https://patchwork.freedesktop.org/api/1.0/series/14672/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_flip:
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-pipe:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:180  dwarn:7   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

f38d5bab1be4078239d2cf7b20c84a574e522263 drm-intel-nightly: 
2016y-11m-01d-11h-22m-30s UTC integration manifest
7761d4a drm/i915: Improve lockdep tracking for obj->mm.lock

== Logs ==

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

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> replace the old for_each_xxx_in_state ones. This is useful for >1 flip
> depth and getting rid of all xxx->state dereferences.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic.c |  6 +++
>  drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
>  drivers/gpu/drm/i915/intel_display.c | 11 ++---
>  include/drm/drm_atomic.h | 81 
> ++--
>  include/drm/drm_atomic_helper.h  |  3 ++
>  5 files changed, 142 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5dd70540219c..120775fcfb70 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
>   return ERR_PTR(-ENOMEM);
>  
>   state->crtcs[index].state = crtc_state;
> + state->crtcs[index].old_state = crtc->state;
> + state->crtcs[index].new_state = crtc_state;
>   state->crtcs[index].ptr = crtc;
>   crtc_state->state = state;
>  
> @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
>  
>   state->planes[index].state = plane_state;
>   state->planes[index].ptr = plane;
> + state->planes[index].old_state = plane->state;
> + state->planes[index].new_state = plane_state;
>   plane_state->state = state;
>  
>   DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
> @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
>  
>   drm_connector_reference(connector);
>   state->connectors[index].state = connector_state;
> + state->connectors[index].old_state = connector->state;
> + state->connectors[index].new_state = connector_state;
>   state->connectors[index].ptr = connector;
>   connector_state->state = state;
>  
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 07b432f43b98..fcb6e5b55217 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
>   *
>   * See also:
>   * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
> - * drm_atomic_helper_resume()
> + * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
>   */
>  struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
>  {
> @@ -2536,6 +2536,52 @@ unlock:
>  EXPORT_SYMBOL(drm_atomic_helper_suspend);
>  
>  /**
> + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
> + * @state: duplicated atomic state to commit
> + * @ctx: pointer to acquire_ctx to use for commit.
> + * @nonblock: commit the state non-blocking.
> + *
> + * The state returned by drm_atomic_helper_duplicate_state() and
> + * drm_atomic_helper_suspend() is partially invalid, and needs to
> + * be fixed up before commit.

So the old_state pointers are potentially invalid because whatever->state
may have changed since we duplicated the state?

> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + *
> + * See also:
> + * drm_atomic_helper_suspend()
> + */
> +int drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
> +   struct drm_modeset_acquire_ctx 
> *ctx,
> +   bool nonblock)
> +{
> + int i;
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> +
> + state->acquire_ctx = ctx;
> +
> + for_each_new_plane_in_state(state, plane, plane_state, i)
> + state->planes[i].old_state = plane->state;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + state->crtcs[i].old_state = crtc->state;
> +
> + for_each_new_connector_in_state(state, connector, conn_state, i)
> + state->connectors[i].old_state = connector->state;
> +
> + if (nonblock)
> + return drm_atomic_nonblocking_commit(state);
> + else
> + return drm_atomic_commit(state);
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
> +
> +/**
>   * drm_atomic_helper_resume - subsystem-level resume helper
>   * @dev: DRM device
>   * @state: atomic state to resume to
> @@ -2558,9 +2604,9 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>   int err;
>  
>   drm_mode_config_reset(dev);
> +
>   drm_modeset_lock_all(dev);
> - state->acquire_ctx = config->acquire_ctx;
> - err = drm_atomic_commit(state);
> + err = 

Re: [Intel-gfx] [RESEND PATCH 5/6] drm/i915: Pass atomic state to verify_connector_state

[Ville Syrjälä]

On Wed, Oct 19, 2016 at 03:55:38PM +0200, Maarten Lankhorst wrote:
> This gets rid of a warning that the connectors are used without locking
> when doing a nonblocking modeset.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ba7f7be3aa4f..54a4b2704179 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13501,11 +13501,15 @@ static void verify_wm_state(struct drm_crtc *crtc,
>  }
>  
>  static void
> -verify_connector_state(struct drm_device *dev, struct drm_crtc *crtc)
> +verify_connector_state(struct drm_device *dev,
> +struct drm_atomic_state *state,
> +struct drm_crtc *crtc)
>  {
>   struct drm_connector *connector;
> + struct drm_connector_state *old_conn_state;
> + int i;
>  
> - drm_for_each_connector(connector, dev) {
> + for_each_connector_in_state(state, connector, old_conn_state, i) {
>   struct drm_encoder *encoder = connector->encoder;
>   struct drm_connector_state *state = connector->state;
>  
> @@ -13713,15 +13717,16 @@ verify_shared_dpll_state(struct drm_device *dev, 
> struct drm_crtc *crtc,
>  
>  static void
>  intel_modeset_verify_crtc(struct drm_crtc *crtc,
> -  struct drm_crtc_state *old_state,
> -  struct drm_crtc_state *new_state)
> +   struct drm_atomic_state *state,
> +   struct drm_crtc_state *old_state,
> +   struct drm_crtc_state *new_state)
>  {
>   if (!needs_modeset(new_state) &&
>   !to_intel_crtc_state(new_state)->update_pipe)
>   return;
>  
>   verify_wm_state(crtc, new_state);
> - verify_connector_state(crtc->dev, crtc);
> + verify_connector_state(crtc->dev, state, crtc);
>   verify_crtc_state(crtc, old_state, new_state);
>   verify_shared_dpll_state(crtc->dev, crtc, old_state, new_state);
>  }
> @@ -13737,10 +13742,11 @@ verify_disabled_dpll_state(struct drm_device *dev)
>  }
>  
>  static void
> -intel_modeset_verify_disabled(struct drm_device *dev)
> +intel_modeset_verify_disabled(struct drm_device *dev,
> +   struct drm_atomic_state *state)
>  {
>   verify_encoder_state(dev);
> - verify_connector_state(dev, NULL);
> + verify_connector_state(dev, state, NULL);
>   verify_disabled_dpll_state(dev);
>  }
>  
> @@ -14399,7 +14405,7 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   if (!intel_can_enable_sagv(state))
>   intel_disable_sagv(dev_priv);
>  
> - intel_modeset_verify_disabled(dev);
> + intel_modeset_verify_disabled(dev, state);
>   }
>  
>   /* Complete the events for pipes that have now been disabled */
> @@ -14451,7 +14457,7 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   if (put_domains[i])
>   modeset_put_power_domains(dev_priv, put_domains[i]);
>  
> - intel_modeset_verify_crtc(crtc, old_crtc_state, crtc->state);
> + intel_modeset_verify_crtc(crtc, state, old_crtc_state, 
> crtc->state);
>   }
>  
>   if (intel_state->modeset && intel_can_enable_sagv(state))
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

[Ville Syrjälä]

On Tue, Nov 01, 2016 at 02:40:35PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 01, 2016 at 09:57:43AM +0100, Maarten Lankhorst wrote:
> > Op 28-10-16 om 18:59 schreef ville.syrj...@linux.intel.com:
> > > From: Ville Syrjälä 
> > >
> > > When we end up not recomputing the cdclk, we need to populate
> > > intel_state->cdclk with the "atomic_cdclk_freq" instead of the
> > > current cdclk_freq. When no pipes are active, the actual cdclk_freq
> > > may be lower than what the configuration of the planes and
> > > pipes would require from the point of view of the software state.
> > >
> > > intel_state->dev_cdclk is the computed actual cdclk in such cases,
> > > so let's populate that with the current cdclk value. Although basically
> > > nothing should ever use dev_cdclk for any checks and whatnot.
> > >
> > > This fixes bogus WARNS from skl_max_scale() which is trying to check
> > > the plane software state against the cdclk frequency. So any time
> > > it got called during DPMS off for instance, we might have tripped
> > > the warn if the current mode would have required a higher than
> > > minimum cdclk.
> > >
> > > Cc: Maarten Lankhorst 
> > > Cc: Mika Kahola 
> > > Cc: bruno.pag...@ens-lyon.org
> > > Cc: Daniel J Blueman 
> > > Cc: Paul Bolle 
> > > Cc: Joseph Yasi 
> > > Tested-by: Paul Bolle 
> > > Tested-by: Joseph Yasi 
> > > Cc: sta...@vger.kernel.org
> > > Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's 
> > > were active.")
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 10 +++---
> > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 895b3dc50e3f..f010e154e33e 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -14040,8 +14040,10 @@ static int intel_modeset_checks(struct 
> > > drm_atomic_state *state)
> > >  
> > >   DRM_DEBUG_KMS("New cdclk calculated to be atomic %u, actual 
> > > %u\n",
> > > intel_state->cdclk, intel_state->dev_cdclk);
> > > - } else
> > > + } else {
> > >   to_intel_atomic_state(state)->cdclk = 
> > > dev_priv->atomic_cdclk_freq;
> > > + to_intel_atomic_state(state)->dev_cdclk = dev_priv->cdclk_freq;
> > > + }
> > This shouldn't be required in this case, but might as well do so since it 
> > doesn't hurt either.
> > >   intel_modeset_clear_plls(state);
> > >  
> > > @@ -14142,8 +14144,10 @@ static int intel_atomic_check(struct drm_device 
> > > *dev,
> > >  
> > >   if (ret)
> > >   return ret;
> > > - } else
> > > - intel_state->cdclk = dev_priv->cdclk_freq;
> > > + } else {
> > > + intel_state->cdclk = dev_priv->atomic_cdclk_freq;
> > > + intel_state->dev_cdclk = dev_priv->cdclk_freq;
> > > + }
> > We shouldn't rely on dev_cdclk being valid for the !modeset case.
> > Best to keep it zero there, the global cdclk can't be changed and the 
> > non-modeset case shouldn't rely on the current setting.
> 
> It should pretty much be protected by any of the crtc locks, at least
> for now since we don't allow changing it w/o modesetting all the pipes.
> But yeah, nothing should be using it for any checks so could just leave
> it unset.
> 
> But this got me thinking about dev_priv->atomic_cdclk_freq. Essentially
> that one is protected by connection_mutex, which we won't be holding
> for the !modeset case. So I think using it there is a bit dubious. I
> guess it would require a modeset on one pipe that doesn't actually
> end up changing the cdclk frequency but which changes atomic_cdclk_freq,
> and a parallel plane update on another pipe. I guess that would mean
> both pipes would have be !active at the time so that dev_cdclk remains
> stable. Seems to me that we'd need to lock all the crtcs (without
> forcing a modeset on them) when atomic_cdclk changes.

Something like this:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 093af6e4ab40..532a932a1ff9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13921,6 +13921,21 @@ static int haswell_mode_set_planes_workaround(struct 
drm_atomic_state *state)
return 0;
 }
 
+static int intel_lock_all_pipes(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+
+   /* add all pipes to the state */
+   for_each_crtc(state->dev, crtc) {
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state))
+   

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Store the vma in an rbtree under the object

[Patchwork]

== Series Details ==

Series: drm/i915: Store the vma in an rbtree under the object
URL   : https://patchwork.freedesktop.org/series/14671/
State : warning

== Summary ==

Series 14671v1 drm/i915: Store the vma in an rbtree under the object
https://patchwork.freedesktop.org/api/1.0/series/14671/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-kbl-7200u)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-edid:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-load-detect:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:183  dwarn:4   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:214  dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:218  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

f38d5bab1be4078239d2cf7b20c84a574e522263 drm-intel-nightly: 
2016y-11m-01d-11h-22m-30s UTC integration manifest
71de972 drm/i915: Store the vma in an rbtree under the object

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

[Ville Syrjälä]

On Tue, Nov 01, 2016 at 10:07:51AM +0100, Paul Bolle wrote:
> On Tue, 2016-11-01 at 09:57 +0100, Maarten Lankhorst wrote:
> > Otherwise looks sane, I have a similar patch in my tree. I didn't
> > submit it yet but the fix was similar. Except for the
> > dev_cdclk stuff.
> > 
> > With the last dev_cdclk assignment removed:
> > 
> > Reviewed-by: Maarten Lankhorst 
> 
> So I've been running this patch for a few days now. First I tested it
> on top of v4.8.4. Now I'm running it on top of v4.8.5.
> 
> My current v4.8.5 boot saw this new (for me) *ERROR*, twice:
>     <3>[43483.521341] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU 
> about cdclk change
> <3>[108639.090776] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform 
> PCU about cdclk change
> 
> Related or a coincidence?

Not directly related. That's actually a more serious problem we really
need to figure out. I already tried to fix it but apparently I failed.

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

[Ville Syrjälä]

On Tue, Nov 01, 2016 at 09:57:43AM +0100, Maarten Lankhorst wrote:
> Op 28-10-16 om 18:59 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä 
> >
> > When we end up not recomputing the cdclk, we need to populate
> > intel_state->cdclk with the "atomic_cdclk_freq" instead of the
> > current cdclk_freq. When no pipes are active, the actual cdclk_freq
> > may be lower than what the configuration of the planes and
> > pipes would require from the point of view of the software state.
> >
> > intel_state->dev_cdclk is the computed actual cdclk in such cases,
> > so let's populate that with the current cdclk value. Although basically
> > nothing should ever use dev_cdclk for any checks and whatnot.
> >
> > This fixes bogus WARNS from skl_max_scale() which is trying to check
> > the plane software state against the cdclk frequency. So any time
> > it got called during DPMS off for instance, we might have tripped
> > the warn if the current mode would have required a higher than
> > minimum cdclk.
> >
> > Cc: Maarten Lankhorst 
> > Cc: Mika Kahola 
> > Cc: bruno.pag...@ens-lyon.org
> > Cc: Daniel J Blueman 
> > Cc: Paul Bolle 
> > Cc: Joseph Yasi 
> > Tested-by: Paul Bolle 
> > Tested-by: Joseph Yasi 
> > Cc: sta...@vger.kernel.org
> > Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's 
> > were active.")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 895b3dc50e3f..f010e154e33e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14040,8 +14040,10 @@ static int intel_modeset_checks(struct 
> > drm_atomic_state *state)
> >  
> > DRM_DEBUG_KMS("New cdclk calculated to be atomic %u, actual 
> > %u\n",
> >   intel_state->cdclk, intel_state->dev_cdclk);
> > -   } else
> > +   } else {
> > to_intel_atomic_state(state)->cdclk = 
> > dev_priv->atomic_cdclk_freq;
> > +   to_intel_atomic_state(state)->dev_cdclk = dev_priv->cdclk_freq;
> > +   }
> This shouldn't be required in this case, but might as well do so since it 
> doesn't hurt either.
> > intel_modeset_clear_plls(state);
> >  
> > @@ -14142,8 +14144,10 @@ static int intel_atomic_check(struct drm_device 
> > *dev,
> >  
> > if (ret)
> > return ret;
> > -   } else
> > -   intel_state->cdclk = dev_priv->cdclk_freq;
> > +   } else {
> > +   intel_state->cdclk = dev_priv->atomic_cdclk_freq;
> > +   intel_state->dev_cdclk = dev_priv->cdclk_freq;
> > +   }
> We shouldn't rely on dev_cdclk being valid for the !modeset case.
> Best to keep it zero there, the global cdclk can't be changed and the 
> non-modeset case shouldn't rely on the current setting.

It should pretty much be protected by any of the crtc locks, at least
for now since we don't allow changing it w/o modesetting all the pipes.
But yeah, nothing should be using it for any checks so could just leave
it unset.

But this got me thinking about dev_priv->atomic_cdclk_freq. Essentially
that one is protected by connection_mutex, which we won't be holding
for the !modeset case. So I think using it there is a bit dubious. I
guess it would require a modeset on one pipe that doesn't actually
end up changing the cdclk frequency but which changes atomic_cdclk_freq,
and a parallel plane update on another pipe. I guess that would mean
both pipes would have be !active at the time so that dev_cdclk remains
stable. Seems to me that we'd need to lock all the crtcs (without
forcing a modeset on them) when atomic_cdclk changes.

> 
> Otherwise looks sane, I have a similar patch in my tree. I didn't submit it 
> yet but the fix was similar. Except for the
> dev_cdclk stuff.
> 
> With the last dev_cdclk assignment removed:
> 
> Reviewed-by: Maarten Lankhorst 

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

Re: [Intel-gfx] [PATCH v2.1 03/11] drm/i915/gen9+: Use for_each_intel_plane_on_crtc in skl_print_wm_changes, v2.

[Paulo Zanoni]

Em Ter, 2016-11-01 às 12:04 +0100, Maarten Lankhorst escreveu:
> Using for_each_intel_plane_on_crtc will allow us to find all
> allocations
> that may have changed, not just the one added by the atomic state.
> 
> This will print changes to plane allocations for crtc's when some
> planes are not added to the atomic state.
> 
> Changes since v1:
> - Rephrase commit message. (Ville)
> - Use plane->base.id and plane->name to kill off cursor special
>   case. (Matt)

Wasn't this Ville's suggestion? :)

> - Add intel_crtc to prevent a line wrap. (Paulo)

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
> Could I get a quick ack this version is good? Then I'll commit it.
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index e6e9cc563484..84db162cd30a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4090,45 +4090,31 @@ skl_print_wm_changes(const struct
> drm_atomic_state *state)
>   to_intel_atomic_state(state);
>   const struct drm_crtc *crtc;
>   const struct drm_crtc_state *cstate;
> - const struct drm_plane *plane;
>   const struct intel_plane *intel_plane;
> - const struct drm_plane_state *pstate;
>   const struct skl_ddb_allocation *old_ddb = _priv-
> >wm.skl_hw.ddb;
>   const struct skl_ddb_allocation *new_ddb = _state-
> >wm_results.ddb;
>   enum pipe pipe;
>   int id;
> - int i, j;
> + int i;
>  
>   for_each_crtc_in_state(state, crtc, cstate, i) {
> - pipe = to_intel_crtc(crtc)->pipe;
> + const struct intel_crtc *intel_crtc =
> to_intel_crtc(crtc);
> + pipe = intel_crtc->pipe;
>  
> - for_each_plane_in_state(state, plane, pstate, j) {
> + for_each_intel_plane_on_crtc(dev, intel_crtc,
> intel_plane) {
>   const struct skl_ddb_entry *old, *new;
>  
> - intel_plane = to_intel_plane(plane);
>   id = skl_wm_plane_id(intel_plane);
>   old = _ddb->plane[pipe][id];
>   new = _ddb->plane[pipe][id];
>  
> - if (intel_plane->pipe != pipe)
> - continue;
> -
>   if (skl_ddb_entry_equal(old, new))
>   continue;
>  
> - if (id != PLANE_CURSOR) {
> - DRM_DEBUG_ATOMIC("[PLANE:%d:plane
> %d%c] ddb (%d - %d) -> (%d - %d)\n",
> -  plane->base.id, id
> + 1,
> -  pipe_name(pipe),
> -  old->start, old-
> >end,
> -  new->start, new-
> >end);
> - } else {
> - DRM_DEBUG_ATOMIC("[PLANE:%d:cursor
> %c] ddb (%d - %d) -> (%d - %d)\n",
> -  plane->base.id,
> -  pipe_name(pipe),
> -  old->start, old-
> >end,
> -  new->start, new-
> >end);
> - }
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] ddb (%d -
> %d) -> (%d - %d)\n",
> +  intel_plane->base.base.id,
> intel_plane->base.name,
> +  old->start, old->end,
> +  new->start, new->end);
>   }
>   }
>  }
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Improve lockdep tracking for obj->mm.lock

[Joonas Lahtinen]

On ti, 2016-11-01 at 12:11 +, Chris Wilson wrote:
> The shrinker may appear to recurse into obj->mm.lock as the shrinker may
> be called from a direct reclaim path whilst handling get_pages. We
> filter out recursing on the same obj->mm.lock by inspecting
> obj->mm.pages, but we do want to take the lock on a second object in
> order to reap their pages. lockdep spots the recursion on the same
> lockclass and needs annotation to avoid a false positive. To keep the
> two paths distinct, create an enum to indicate which subclass of
> obj->mm.lock. This removes the false positive and avoids masking real
> bugs.
> 
> Suggested-by: Joonas Lahtinen 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence
URL   : https://patchwork.freedesktop.org/series/14669/
State : warning

== Summary ==

Series 14669v1 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init 
sequence
https://patchwork.freedesktop.org/api/1.0/series/14669/revisions/1/mbox/

Test kms_flip:
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-a:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:183  dwarn:4   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

f38d5bab1be4078239d2cf7b20c84a574e522263 drm-intel-nightly: 
2016y-11m-01d-11h-22m-30s UTC integration manifest
c5d6745 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Improve lockdep tracking for obj->mm.lock

[Chris Wilson]

The shrinker may appear to recurse into obj->mm.lock as the shrinker may
be called from a direct reclaim path whilst handling get_pages. We
filter out recursing on the same obj->mm.lock by inspecting
obj->mm.pages, but we do want to take the lock on a second object in
order to reap their pages. lockdep spots the recursion on the same
lockclass and needs annotation to avoid a false positive. To keep the
two paths distinct, create an enum to indicate which subclass of
obj->mm.lock. This removes the false positive and avoids masking real
bugs.

Suggested-by: Joonas Lahtinen 
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 7 ++-
 drivers/gpu/drm/i915/i915_gem.c  | 9 +
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem_userptr.c  | 2 +-
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9143129cd851..b93a37f5f4ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3287,7 +3287,12 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object 
*obj)
__i915_gem_object_unpin_pages(obj);
 }
 
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
+enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
+   I915_MM_NORMAL = 0,
+   I915_MM_SHRINKER
+};
+void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+enum i915_mm_subclass subclass);
 void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
 
 enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1568f6756430..cbbfaa7761b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -491,7 +491,7 @@ i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
if (ret)
return ret;
 
-   __i915_gem_object_put_pages(obj);
+   __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
if (obj->mm.pages)
return -EBUSY;
 
@@ -2181,7 +2181,8 @@ static void __i915_gem_object_reset_page_iter(struct 
drm_i915_gem_object *obj)
radix_tree_delete(>mm.get_page.radix, iter.index);
 }
 
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
+void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+enum i915_mm_subclass subclass)
 {
struct sg_table *pages;
 
@@ -2193,7 +2194,7 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj)
return;
 
/* May be called by shrinker from within get_pages() (on another bo) */
-   mutex_lock_nested(>mm.lock, SINGLE_DEPTH_NESTING);
+   mutex_lock_nested(>mm.lock, subclass);
if (unlikely(atomic_read(>mm.pages_pin_count)))
goto unlock;
 
@@ -4283,7 +4284,7 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
 
if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
atomic_set(>mm.pages_pin_count, 0);
-   __i915_gem_object_put_pages(obj);
+   __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
GEM_BUG_ON(obj->mm.pages);
 
if (obj->base.import_attach)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 0993afc0e725..f988652f1e26 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -111,7 +111,7 @@ static bool can_release_pages(struct drm_i915_gem_object 
*obj)
 static bool unsafe_drop_pages(struct drm_i915_gem_object *obj)
 {
if (i915_gem_object_unbind(obj) == 0)
-   __i915_gem_object_put_pages(obj);
+   __i915_gem_object_put_pages(obj, I915_MM_SHRINKER);
return !READ_ONCE(obj->mm.pages);
 }
 
@@ -225,7 +225,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
if (unsafe_drop_pages(obj)) {
/* May arrive from get_pages on another bo */
mutex_lock_nested(>mm.lock,
- SINGLE_DEPTH_NESTING);
+ I915_MM_SHRINKER);
if (!obj->mm.pages) {
__i915_gem_object_invalidate(obj);
list_del_init(>global_list);
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index c30d04f64670..9bf44b5bca10 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -75,7 +75,7 @@ static void cancel_userptr(struct work_struct *work)
 
/* We are inside a kthread context and can't be 

[Intel-gfx] [CI] drm/i915: Store the vma in an rbtree under the object

[Chris Wilson]

With full-ppgtt one of the main bottlenecks is the lookup of the VMA
underneath the object. For execbuf there is merit in having a very fast
direct lookup of ctx:handle to the vma using a hashtree, but that still
leaves a large number of other lookups. One way to speed up the lookup
would be to use a rhashtable, but that requires extra allocations and
may exhibit poor worse case behaviour. An alternative is to use an
embedded rbtree, i.e. no extra allocations and deterministic behaviour,
but at the slight cost of O(lgN) lookups (instead of O(1) for
rhashtable). The major of such tree will be very shallow and so not much
slower, and still scales much, much better than the current unsorted
list.

v2: Bump vma_compare() to return a long, as we return the result of
comparing two pointers.

References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c |  2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 80 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  1 +
 4 files changed, 59 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 539106a9c1af..9143129cd851 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2230,6 +2230,7 @@ struct drm_i915_gem_object {
 
/** List of VMAs backed by this object */
struct list_head vma_list;
+   struct rb_root vma_tree;
 
/** Stolen memory for this object, instead of being backed by shmem. */
struct drm_mm_node *stolen;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c9e52f75e1cb..1568f6756430 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4266,6 +4266,8 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
vma->flags &= ~I915_VMA_PIN_MASK;
i915_vma_close(vma);
}
+   GEM_BUG_ON(!list_empty(>vma_list));
+   GEM_BUG_ON(!RB_EMPTY_ROOT(>vma_tree));
 
list_del(>global_list);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e7afad585929..00606a27e9aa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3399,6 +3399,7 @@ void i915_vma_destroy(struct i915_vma *vma)
GEM_BUG_ON(!i915_vma_is_closed(vma));
GEM_BUG_ON(vma->fence);
 
+   rb_erase(>obj_node, >obj->vma_tree);
list_del(>vm_link);
if (!i915_vma_is_ggtt(vma))
i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));
@@ -3416,12 +3417,33 @@ void i915_vma_close(struct i915_vma *vma)
WARN_ON(i915_vma_unbind(vma));
 }
 
+static inline long vma_compare(struct i915_vma *vma,
+  struct i915_address_space *vm,
+  const struct i915_ggtt_view *view)
+{
+   GEM_BUG_ON(view && !i915_vma_is_ggtt(vma));
+
+   if (vma->vm != vm)
+   return vma->vm - vm;
+
+   if (!view)
+   return vma->ggtt_view.type;
+
+   if (vma->ggtt_view.type != view->type)
+   return vma->ggtt_view.type - view->type;
+
+   return memcmp(>ggtt_view.params,
+ >params,
+ sizeof(view->params));
+}
+
 static struct i915_vma *
 __i915_vma_create(struct drm_i915_gem_object *obj,
  struct i915_address_space *vm,
  const struct i915_ggtt_view *view)
 {
struct i915_vma *vma;
+   struct rb_node *rb, **p;
int i;
 
GEM_BUG_ON(vm->closed);
@@ -3455,33 +3477,28 @@ __i915_vma_create(struct drm_i915_gem_object *obj,
 
if (i915_is_ggtt(vm)) {
vma->flags |= I915_VMA_GGTT;
+   list_add(>obj_link, >vma_list);
} else {
i915_ppgtt_get(i915_vm_to_ppgtt(vm));
+   list_add_tail(>obj_link, >vma_list);
}
 
-   list_add_tail(>obj_link, >vma_list);
-   return vma;
-}
+   rb = NULL;
+   p = >vma_tree.rb_node;
+   while (*p) {
+   struct i915_vma *pos;
 
-static inline bool vma_matches(struct i915_vma *vma,
-  struct i915_address_space *vm,
-  const struct i915_ggtt_view *view)
-{
-   if (vma->vm != vm)
-   return false;
-
-   if (!i915_vma_is_ggtt(vma))
-   return true;
-
-   if (!view)
-   return vma->ggtt_view.type == 0;
-
-   if (vma->ggtt_view.type != view->type)
-   return false;
+   rb = *p;
+   pos = rb_entry(rb, struct i915_vma, obj_node);
+   if (vma_compare(pos, vm, view) < 0)
+   p = >rb_right;
+   

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

[Imre Deak]

On ti, 2016-11-01 at 13:11 +0200, Ander Conselvan de Oliveira wrote:
> Hardware engineers confirmed that writing to it has no effect, as implied by
> the FIXME comment.
> 
> Cc: Imre Deak 
> Signed-off-by: Ander Conselvan de Oliveira 
> 

You could also remove the corresponding comment
from bxt_ddi_phy_verify_state(), either way:

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 16 
>  1 file changed, 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 4a6164a..e95b291 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -365,22 +365,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
> *dev_priv,
>   I915_WRITE(BXT_PORT_CL2CM_DW6(phy), val);
>   }
>  
> - val = I915_READ(BXT_PORT_CL1CM_DW30(phy));
> - val &= ~OCL2_LDOFUSE_PWR_DIS;
> - /*
> -  * On PHY1 disable power on the second channel, since no port is
> -  * connected there. On PHY0 both channels have a port, so leave it
> -  * enabled.
> -  * TODO: port C is only connected on BXT-P, so on BXT0/1 we should
> -  * power down the second channel on PHY0 as well.
> -  *
> -  * FIXME: Clarify programming of the following, the register is
> -  * read-only with bit 6 fixed at 0 at least in stepping A.
> -  */
> - if (!phy_info->dual_channel)
> - val |= OCL2_LDOFUSE_PWR_DIS;
> - I915_WRITE(BXT_PORT_CL1CM_DW30(phy), val);
> -
>   if (phy_info->rcomp_phy != -1) {
>   uint32_t grc_code;
>   /*
___
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 drm/i915: A game of OCD dominoes

[Ville Syrjälä]

On Mon, Oct 31, 2016 at 09:16:10PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: A game of OCD dominoes
> URL   : https://patchwork.freedesktop.org/series/14634/
> State : warning
> 
> == Summary ==
> 
> Series 14634v1 drm/i915: A game of OCD dominoes
> https://patchwork.freedesktop.org/api/1.0/series/14634/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> SKIP   (fi-ivb-3520m)
> dmesg-warn -> PASS   (fi-ilk-650)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-ilk-650)
> Test kms_cursor_legacy:
> Subgroup basic-flip-after-cursor-varying-size:
> pass   -> DMESG-WARN (fi-ilk-650)

[  242.516457] [drm:intel_dp_detect [i915]] [CONNECTOR:45:DP-1]
[  242.516925] [drm:intel_dp_read_dpcd [i915]] DPCD: 11 11 11 11 11 11 11 11 11 
11 11 11 11 11 11
[  242.518513] [drm:intel_dp_detect [i915]] Display Port TPS3 support: source 
no, sink no
[  242.518531] [drm:intel_dp_print_rates [i915]] source rates: 162000, 27
[  242.518532] [ cut here ]
[  242.518548] WARNING: CPU: 0 PID: 8223 at drivers/gpu/drm/i915/intel_dp.c:146 
intel_dp_max_link_bw.isra.7+0x28/0x50 [i915]
[  242.518549] invalid max DP link bw val 11, using 1.62Gbps

DPCD went mad it seems. I wonder if this monitor might occasionally need the
dummy read wakeup trick we have for the HP ZR24w.

I see we also managed to read a corrupted EDID from this guy at some point:
[   17.753230] i915 :00:02.0: DP-1: EDID is invalid:
[   17.753235]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   17.753236]  [00] BAD  1f 17 01 04 a5 34 20 78 32 70 00 00 00 00 00 00
[   17.753237]  [00] BAD  12 50 54 ad a5 34 20 78 32 70 00 00 00 00 00 00
[   17.753238]  [00] BAD  b3 00 a9 40 d1 c0 20 78 32 70 00 00 00 00 00 00
[   17.753239]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   17.753240]  [00] BAD  4b 11 00 0a 20 20 20 20 20 70 00 00 00 00 00 00
[   17.753241]  [00] BAD  45 4e 20 4c 20 20 20 20 20 70 00 00 00 00 00 00
[   17.753242]  [00] BAD  00 56 4e 2d 31 33 31 37 31 37 00 00 00 00 00 00

Also other corrupted junk:
[  302.422296] [drm:intel_dp_read_desc [i915]] DP sink: OUI 11-11-11(NS) dev-ID 
\021\021\021\021\021\021 HW-rev 1.1 SW-rev 17.17
[  343.061189] [drm:intel_dp_read_desc [i915]] DP sink: OUI 00-00-00(NS) dev-ID 
 HW-rev 0.2 SW-rev 6.0
[  343.067738] [drm:intel_dp_read_desc [i915]] DP sink: OUI 00-00-00(NS) dev-ID 
 HW-rev 0.0 SW-rev 0.0

> Test kms_force_connector_basic:
> Subgroup force-connector-state:
> pass   -> DMESG-WARN (fi-snb-2520m)

[  395.168787] [drm:intel_hdmi_detect [i915]] [CONNECTOR:46:HDMI-A-1]
[  395.197422] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, 
remainder is 8

Hmm. I wonder what is going on with GMBUS. Did we break it recently or
was it already broken?

> Subgroup force-edid:
> dmesg-warn -> PASS   (fi-snb-2520m)
> Test kms_pipe_crc_basic:
> Subgroup bad-nb-words-3:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup bad-source:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup hang-read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)

Same corrupted DPCD stuff.

> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-ilk-650)
> 
> fi-bdw-5557u total:241  pass:225  dwarn:1   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
> fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
> fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
> fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
> fi-ilk-650   total:241  pass:183  dwarn:4   dfail:0   fail:0   skip:54 
> fi-ivb-3520m total:241  pass:217  dwarn:0   dfail:0   fail:0   skip:24 
> fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
> fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
> fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
> fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
> fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
> fi-snb-2520m total:241  pass:207  dwarn:1   dfail:0   

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915: Avoid accessing request->timeline outside of its lifetime

[Chris Wilson]

On Tue, Nov 01, 2016 at 10:46:07AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,1/2] drm/i915: Avoid accessing 
> request->timeline outside of its lifetime
> URL   : https://patchwork.freedesktop.org/series/14665/
> State : warning
> 
> == Summary ==
> 
> Series 14665v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/14665/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_busy:
> Subgroup basic-flip-default-a:
> dmesg-warn -> PASS   (fi-ilk-650)
> Test kms_cursor_legacy:
> Subgroup basic-flip-after-cursor-varying-size:
> dmesg-warn -> PASS   (fi-ilk-650)
> Test kms_force_connector_basic:
> Subgroup force-connector-state:
> pass   -> SKIP   (fi-ivb-3520m)
> Subgroup force-edid:
> pass   -> SKIP   (fi-ivb-3520m)
> Subgroup force-load-detect:
> pass   -> SKIP   (fi-ivb-3520m)
> Subgroup prune-stale-modes:
> pass   -> SKIP   (fi-ivb-3520m)
> Test kms_pipe_crc_basic:
> Subgroup bad-nb-words-1:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup bad-nb-words-3:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup bad-source:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (fi-snb-2520m)
> Subgroup read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ilk-650)

Unrelated skipped, pushed.
-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 igt 2/2] igt/kms_flip: Use the computed vblank interval for TS checking

[Chris Wilson]

Since the modeline may differ from actual hardware timings, do not rely
upon it but instead measure the actual and verify that it does not
change across the various flip/vblank configurations.

Signed-off-by: Chris Wilson 
---
 tests/kms_flip.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 74754d1..6a1549e 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -177,6 +177,8 @@ struct test_output {
int seq_step;
unsigned int pending_events;
int flip_count;
+
+   double vblank_interval;
 };
 
 
@@ -579,6 +581,12 @@ static double mode_frame_time(const struct test_output *o)
return 1000.0 * o->kmode[0].htotal * o->kmode[0].vtotal / 
o->kmode[0].clock;
 }
 
+static double actual_frame_time(const struct test_output *o)
+{
+   igt_assert(o->flags & TEST_CHECK_TS);
+   return o->vblank_interval;
+}
+
 static void *vblank_wait_thread_func(void *data)
 {
struct test_output *o = data;
@@ -687,12 +695,12 @@ static void check_state(const struct test_output *o, 
const struct event_state *e
  es->current_seq, es->last_seq);
}
 
-   if ((o->flags & TEST_CHECK_TS) && (!analog_tv_connector(o))) {
+   if (o->flags & TEST_CHECK_TS) {
double elapsed, expected;
 
timersub(>current_ts, >last_ts, );
elapsed = 1e6*diff.tv_sec + diff.tv_usec;
-   expected = (es->current_seq - es->last_seq) * 
mode_frame_time(o);
+   expected = (es->current_seq - es->last_seq) * 
actual_frame_time(o);
 
igt_debug("%s ts/seq: last %ld.%06ld/%u, current %ld.%06ld/%u: 
elapsed=%.1fus expected=%.1fus +- %.1fus, error %.1f%%\n",
  es->name, es->last_ts.tv_sec, es->last_ts.tv_usec, 
es->last_seq,
@@ -1192,17 +1200,17 @@ static void check_final_state(const struct test_output 
*o,
 
/* Verify we drop no frames, but only if it's not a TV encoder, since
 * those use some funny fake timings behind userspace's back. */
-   if (o->flags & TEST_CHECK_TS && !analog_tv_connector(o)) {
+   if (o->flags & TEST_CHECK_TS) {
int count = es->count * o->seq_step;
-   unsigned int min = mode_frame_time(o) * (count - 1);
-   unsigned int max = mode_frame_time(o) * (count + 1);
+   unsigned int min = actual_frame_time(o) * (count - 1);
+   unsigned int max = actual_frame_time(o) * (count + 1);
 
igt_debug("expected %d, counted %d, encoder type %d\n",
- (int)(elapsed / mode_frame_time(o)), count,
+ (int)(elapsed / actual_frame_time(o)), count,
  o->kencoder[0]->encoder_type);
igt_assert_f(elapsed >= min && elapsed <= max,
 "dropped frames, expected %d, counted %d, encoder 
type %d\n",
-(int)(elapsed / mode_frame_time(o)), count,
+(int)(elapsed / actual_frame_time(o)), count,
 o->kencoder[0]->encoder_type);
}
 }
@@ -1361,10 +1369,13 @@ static void calibrate_ts(struct test_output *o, int 
crtc_idx)
 expected, mean, stddev, 100 * 6 * stddev / mean);
igt_assert(6 * stddev / mean < 0.005); /* 99% accuracy within 0.5% */
 
-   igt_require_f(fabs(mean - expected) < 2*stddev,
- "vblank interval differs from modeline! expected %.1fus, 
measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma)\n",
- expected, mean, stddev,
- fabs(mean - expected), fabs(mean - expected) / stddev);
+   if (fabs(mean - expected) > 2*stddev) {
+   igt_warn("vblank interval differs from modeline! expected 
%.1fus, measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma)\n",
+   expected, mean, stddev,
+   fabs(mean - expected), fabs(mean - expected) / 
stddev);
+   }
+
+   o->vblank_interval = mean;
 }
 
 static void run_test_on_crtc_set(struct test_output *o, int *crtc_idxs,
-- 
2.10.2

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

[Intel-gfx] [PATCH igt 1/2] igt/kms_flip: Mark frame_time() as coming from the mode

[Chris Wilson]

Signed-off-by: Chris Wilson 
---
 tests/kms_flip.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 9829b35..74754d1 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -574,7 +574,7 @@ static void page_flip_handler(int fd, unsigned int frame, 
unsigned int sec,
event_handler(>flip_state, frame, sec, usec);
 }
 
-static double frame_time(const struct test_output *o)
+static double mode_frame_time(const struct test_output *o)
 {
return 1000.0 * o->kmode[0].htotal * o->kmode[0].vtotal / 
o->kmode[0].clock;
 }
@@ -588,7 +588,7 @@ static void *vblank_wait_thread_func(void *data)
for (i = 0; i < 32; i++) {
unsigned long start = gettime_us();
__wait_for_vblank(TEST_VBLANK_BLOCK, o->pipe, 20, (unsigned 
long)o, );
-   if (gettime_us() - start > 2 * frame_time(o))
+   if (gettime_us() - start > 2 * mode_frame_time(o))
return (void*)1;
}
 
@@ -692,7 +692,7 @@ static void check_state(const struct test_output *o, const 
struct event_state *e
 
timersub(>current_ts, >last_ts, );
elapsed = 1e6*diff.tv_sec + diff.tv_usec;
-   expected = (es->current_seq - es->last_seq) * frame_time(o);
+   expected = (es->current_seq - es->last_seq) * 
mode_frame_time(o);
 
igt_debug("%s ts/seq: last %ld.%06ld/%u, current %ld.%06ld/%u: 
elapsed=%.1fus expected=%.1fus +- %.1fus, error %.1f%%\n",
  es->name, es->last_ts.tv_sec, es->last_ts.tv_usec, 
es->last_seq,
@@ -729,7 +729,7 @@ static void check_state_correlation(struct test_output *o,
usec_diff = tv_diff.tv_sec * USEC_PER_SEC + tv_diff.tv_usec;
 
seq_diff = es2->current_seq - es1->current_seq;
-   ftime = frame_time(o);
+   ftime = mode_frame_time(o);
usec_diff -= seq_diff * ftime;
 
igt_assert_f(fabs(usec_diff) / ftime <= 0.005,
@@ -940,10 +940,10 @@ static unsigned int run_test_step(struct test_output *o)
 * we waited for two vblanks, so verify that
 * we were blocked for ~1-2 frames.
 */
-   igt_assert_f(end - start > 0.9 * frame_time(o) &&
-end - start < 2.1 * frame_time(o),
+   igt_assert_f(end - start > 0.9 * mode_frame_time(o) &&
+end - start < 2.1 * mode_frame_time(o),
 "wait for two vblanks took %lu usec (frame time %f 
usec)\n",
-end - start, frame_time(o));
+end - start, mode_frame_time(o));
join_vblank_wait_thread();
}
 
@@ -1194,15 +1194,15 @@ static void check_final_state(const struct test_output 
*o,
 * those use some funny fake timings behind userspace's back. */
if (o->flags & TEST_CHECK_TS && !analog_tv_connector(o)) {
int count = es->count * o->seq_step;
-   unsigned int min = frame_time(o) * (count - 1);
-   unsigned int max = frame_time(o) * (count + 1);
+   unsigned int min = mode_frame_time(o) * (count - 1);
+   unsigned int max = mode_frame_time(o) * (count + 1);
 
igt_debug("expected %d, counted %d, encoder type %d\n",
- (int)(elapsed / frame_time(o)), count,
+ (int)(elapsed / mode_frame_time(o)), count,
  o->kencoder[0]->encoder_type);
igt_assert_f(elapsed >= min && elapsed <= max,
 "dropped frames, expected %d, counted %d, encoder 
type %d\n",
-(int)(elapsed / frame_time(o)), count,
+(int)(elapsed / mode_frame_time(o)), count,
 o->kencoder[0]->encoder_type);
}
 }
@@ -1352,7 +1352,7 @@ static void calibrate_ts(struct test_output *o, int 
crtc_idx)
last_seq = ev.sequence;
}
 
-   expected = frame_time(o);
+   expected = mode_frame_time(o);
 
mean = igt_stats_get_mean();
stddev = igt_stats_get_std_deviation();
-- 
2.10.2

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

[Intel-gfx] [PATCH v2.1 03/11] drm/i915/gen9+: Use for_each_intel_plane_on_crtc in skl_print_wm_changes, v2.

[Maarten Lankhorst]

Using for_each_intel_plane_on_crtc will allow us to find all allocations
that may have changed, not just the one added by the atomic state.

This will print changes to plane allocations for crtc's when some
planes are not added to the atomic state.

Changes since v1:
- Rephrase commit message. (Ville)
- Use plane->base.id and plane->name to kill off cursor special
  case. (Matt)
- Add intel_crtc to prevent a line wrap. (Paulo)

Signed-off-by: Maarten Lankhorst 
---
Could I get a quick ack this version is good? Then I'll commit it.

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e6e9cc563484..84db162cd30a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4090,45 +4090,31 @@ skl_print_wm_changes(const struct drm_atomic_state 
*state)
to_intel_atomic_state(state);
const struct drm_crtc *crtc;
const struct drm_crtc_state *cstate;
-   const struct drm_plane *plane;
const struct intel_plane *intel_plane;
-   const struct drm_plane_state *pstate;
const struct skl_ddb_allocation *old_ddb = _priv->wm.skl_hw.ddb;
const struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
enum pipe pipe;
int id;
-   int i, j;
+   int i;
 
for_each_crtc_in_state(state, crtc, cstate, i) {
-   pipe = to_intel_crtc(crtc)->pipe;
+   const struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   pipe = intel_crtc->pipe;
 
-   for_each_plane_in_state(state, plane, pstate, j) {
+   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
const struct skl_ddb_entry *old, *new;
 
-   intel_plane = to_intel_plane(plane);
id = skl_wm_plane_id(intel_plane);
old = _ddb->plane[pipe][id];
new = _ddb->plane[pipe][id];
 
-   if (intel_plane->pipe != pipe)
-   continue;
-
if (skl_ddb_entry_equal(old, new))
continue;
 
-   if (id != PLANE_CURSOR) {
-   DRM_DEBUG_ATOMIC("[PLANE:%d:plane %d%c] ddb (%d 
- %d) -> (%d - %d)\n",
-plane->base.id, id + 1,
-pipe_name(pipe),
-old->start, old->end,
-new->start, new->end);
-   } else {
-   DRM_DEBUG_ATOMIC("[PLANE:%d:cursor %c] ddb (%d 
- %d) -> (%d - %d)\n",
-plane->base.id,
-pipe_name(pipe),
-old->start, old->end,
-new->start, new->end);
-   }
+   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] ddb (%d - %d) -> (%d - 
%d)\n",
+intel_plane->base.base.id, 
intel_plane->base.name,
+old->start, old->end,
+new->start, new->end);
}
}
 }

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

[Intel-gfx] [PATCH] drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence

[Ander Conselvan de Oliveira]

Hardware engineers confirmed that writing to it has no effect, as implied by
the FIXME comment.

Cc: Imre Deak 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_dpio_phy.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 4a6164a..e95b291 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -365,22 +365,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
*dev_priv,
I915_WRITE(BXT_PORT_CL2CM_DW6(phy), val);
}
 
-   val = I915_READ(BXT_PORT_CL1CM_DW30(phy));
-   val &= ~OCL2_LDOFUSE_PWR_DIS;
-   /*
-* On PHY1 disable power on the second channel, since no port is
-* connected there. On PHY0 both channels have a port, so leave it
-* enabled.
-* TODO: port C is only connected on BXT-P, so on BXT0/1 we should
-* power down the second channel on PHY0 as well.
-*
-* FIXME: Clarify programming of the following, the register is
-* read-only with bit 6 fixed at 0 at least in stepping A.
-*/
-   if (!phy_info->dual_channel)
-   val |= OCL2_LDOFUSE_PWR_DIS;
-   I915_WRITE(BXT_PORT_CL1CM_DW30(phy), val);
-
if (phy_info->rcomp_phy != -1) {
uint32_t grc_code;
/*
-- 
2.5.5

___
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 [CI,1/2] drm/i915: Avoid accessing request->timeline outside of its lifetime

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Avoid accessing 
request->timeline outside of its lifetime
URL   : https://patchwork.freedesktop.org/series/14665/
State : warning

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_busy:
Subgroup basic-flip-default-a:
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
dmesg-warn -> PASS   (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-edid:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-load-detect:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-snb-2520m)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:184  dwarn:3   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:214  dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:207  dwarn:1   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

fb93d4a3e20dd798eb684f79c9a44f767b37fdef drm-intel-nightly: 
2016y-11m-01d-09h-48m-15s UTC integration manifest
a839030 drm/i915: Track pages pinned due to swizzling quirk
3f13c6e drm/i915: Avoid accessing request->timeline outside of its lifetime

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

[Chris Wilson]

On Tue, Nov 01, 2016 at 12:22:45PM +0200, Mika Kuoppala wrote:
> Joonas Lahtinen  writes:
> >> @@ -735,8 +737,8 @@ static bool gen8_ppgtt_clear_pt(struct 
> >> i915_address_space *vm,
> >>  
> >>    pt_vaddr = kmap_px(pt);
> >>  
> >> -  for (pte = pte_start; pte < num_entries; pte++)
> >> -  pt_vaddr[pte] = scratch_pte;
> >> +  while (pte < pte_end)
> >> +  pt_vaddr[pte++] = scratch_pte;
> >
> > I'd prefer the for loop still. Just fix "pte < pte_end".
> >
> 
> I changed to this due to pte being already set and
> used before the loop, to get rid of superfluous pte_start.

Yes, I think the change to while() made sense with the new flow of pte
being used a few times before we set the scratch_pte.
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

[Mika Kuoppala]

Joonas Lahtinen  writes:

> On ma, 2016-10-31 at 17:55 +0200, Mika Kuoppala wrote:
>> @@ -712,13 +712,13 @@ static int gen8_48b_mm_switch(struct i915_hw_ppgtt 
>> *ppgtt,
>>   */
>>  static bool gen8_ppgtt_clear_pt(struct i915_address_space *vm,
>>  struct i915_page_table *pt,
>> -uint64_t start,
>> -uint64_t length)
>> +const uint64_t start,
>> +const uint64_t length)
>>  {
>
> I think const for integers is bit much, with that logic we should make
> the pointers const too (not the pointer destination).
>

It is more of a compiler guard of accidentally changing these
in the body. Separation of variants and invariants. But
if this not preferred, I can change them back.

>> @@ -735,8 +737,8 @@ static bool gen8_ppgtt_clear_pt(struct 
>> i915_address_space *vm,
>>  
>>  pt_vaddr = kmap_px(pt);
>>  
>> -for (pte = pte_start; pte < num_entries; pte++)
>> -pt_vaddr[pte] = scratch_pte;
>> +while (pte < pte_end)
>> +pt_vaddr[pte++] = scratch_pte;
>
> I'd prefer the for loop still. Just fix "pte < pte_end".
>

I changed to this due to pte being already set and
used before the loop, to get rid of superfluous pte_start.
-Mika


> 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] [CI 1/2] drm/i915: Avoid accessing request->timeline outside of its lifetime

[Chris Wilson]

Whilst waiting on a request, we may do so without holding any locks or
any guards beyond a reference to the request. In order to avoid taking
locks within request deallocation, we drop references to its timeline
(via the context and ppgtt) upon retirement. We should avoid chasing
such pointers outside of their control, in particular we inspect the
request->timeline to see if we may restore the RPS waitboost for a
client. If we instead look at the engine->timeline, we will have similar
behaviour on both full-ppgtt and !full-ppgtt systems and reduce the
amount of reward we give towards stalling clients (i.e. only if the
client stalls and the GPU is uncontended does it reclaim its boost).
This restores behaviour back to pre-timelines, whilst fixing:

[  645.078485] BUG: KASAN: use-after-free in 
i915_gem_object_wait_fence+0x1ee/0x2e0 at addr 8802335643a0
[  645.078577] Read of size 4 by task gem_exec_schedu/28408
[  645.078638] CPU: 1 PID: 28408 Comm: gem_exec_schedu Not tainted 4.9.0-rc2+ 
#64
[  645.078724] Hardware name:  /, BIOS 
PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[  645.078816]  88022daef9a0 8143d059 880235402a80 
880233564200
[  645.078998]  88022daef9c8 81229c5c 88022daefa48 
880233564200
[  645.079172]  880235402a80 88022daefa38 81229ef0 
8110a796
[  645.079345] Call Trace:
[  645.079404]  [] dump_stack+0x68/0x9f
[  645.079467]  [] kasan_object_err+0x1c/0x70
[  645.079534]  [] kasan_report_error+0x1f0/0x4b0
[  645.079601]  [] kasan_report+0x34/0x40
[  645.079676]  [] ? i915_gem_object_wait_fence+0x1ee/0x2e0
[  645.079741]  [] __asan_load4+0x61/0x80
[  645.079807]  [] i915_gem_object_wait_fence+0x1ee/0x2e0
[  645.079876]  [] i915_gem_object_wait+0x19f/0x590
[  645.079944]  [] ? i915_gem_object_wait_priority+0x500/0x500
[  645.080016]  [] ? debug_show_all_locks+0x1e0/0x1e0
[  645.080084]  [] ? check_chain_key+0x14c/0x210
[  645.080157]  [] ? __lock_is_held+0x46/0xc0
[  645.080226]  [] ? i915_gem_set_domain_ioctl+0x141/0x690
[  645.080296]  [] i915_gem_set_domain_ioctl+0x1a2/0x690
[  645.080366]  [] ? __might_fault+0x75/0xe0
[  645.080433]  [] drm_ioctl+0x327/0x640
[  645.080508]  [] ? 
i915_gem_obj_prepare_shmem_write+0x3a0/0x3a0
[  645.080603]  [] ? drm_ioctl_permit+0x120/0x120
[  645.080670]  [] ? check_chain_key+0x14c/0x210
[  645.080738]  [] do_vfs_ioctl+0x127/0xa20
[  645.080804]  [] ? do_mmap+0x47c/0x580
[  645.080871]  [] ? vm_mmap_pgoff+0x117/0x140
[  645.080938]  [] ? ioctl_preallocate+0x150/0x150
[  645.081011]  [] ? up_write+0x23/0x50
[  645.081078]  [] ? vm_mmap_pgoff+0x117/0x140
[  645.081145]  [] ? vma_is_stack_for_current+0x90/0x90
[  645.081214]  [] ? mark_held_locks+0x23/0xc0
[  645.082030]  [] ? __fget+0x168/0x250
[  645.082106]  [] ? entry_SYSCALL_64_fastpath+0x5/0xb1
[  645.082176]  [] ? __fget_light+0xa2/0xc0
[  645.082242]  [] SyS_ioctl+0x3c/0x70
[  645.082309]  [] entry_SYSCALL_64_fastpath+0x1c/0xb1
[  645.082374] Object at 880233564200, in cache kmalloc-8192 size: 8192
[  645.082431] Allocated:
[  645.082480] PID = 28408
[  645.082535]  [  645.082566] [] save_stack_trace+0x16/0x20
[  645.082623]  [  645.082656] [] save_stack+0x46/0xd0
[  645.082716]  [  645.082756] [] kasan_kmalloc+0xad/0xe0
[  645.082817]  [  645.082848] [] i915_ppgtt_create+0x52/0x220
[  645.082908]  [  645.082941] [] 
i915_gem_create_context+0x396/0x560
[  645.083027]  [  645.083059] [] 
i915_gem_context_create_ioctl+0x97/0xf0
[  645.083152]  [  645.083183] [] drm_ioctl+0x327/0x640
[  645.083243]  [  645.083274] [] do_vfs_ioctl+0x127/0xa20
[  645.083334]  [  645.083372] [] SyS_ioctl+0x3c/0x70
[  645.083432]  [  645.083464] [] 
entry_SYSCALL_64_fastpath+0x1c/0xb1
[  645.083551] Freed:
[  645.083599] PID = 27629
[  645.083648]  [  645.083676] [] save_stack_trace+0x16/0x20
[  645.083738]  [  645.083770] [] save_stack+0x46/0xd0
[  645.083830]  [  645.083862] [] kasan_slab_free+0x73/0xc0
[  645.083922]  [  645.083961] [] kfree+0xa9/0x170
[  645.084021]  [  645.084053] [] 
i915_ppgtt_release+0x100/0x180
[  645.084139]  [  645.084171] [] 
i915_gem_context_free+0x1b4/0x230
[  645.084257]  [  645.084288] [] 
intel_lr_context_unpin+0x192/0x230
[  645.084380]  [  645.084413] [] 
i915_gem_request_retire+0x620/0x630
[  645.084500]  [  645.085226] [] 
i915_gem_retire_requests+0x181/0x280
[  645.085313]  [  645.085352] [] 
i915_gem_retire_work_handler+0xca/0xe0
[  645.085440]  [  645.085471] [] process_one_work+0x4fb/0x920
[  645.085532]  [  645.085562] [] worker_thread+0x8d/0x840
[  645.085622]  [  645.085653] [] kthread+0x185/0x1b0
[  645.085718]  [  645.085750] [] ret_from_fork+0x27/0x40
[  645.085811] Memory state around the buggy address:
[  645.085869]  880233564280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  645.085956]  880233564300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  645.086053] >880233564380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  645.086138]

[Intel-gfx] [CI 2/2] drm/i915: Track pages pinned due to swizzling quirk

[Chris Wilson]

If we have a tiled object and an unknown CPU swizzle pattern, we pin the
pages to prevent the object from being swapped out (and us corrupting
the contents as we do not know the access pattern and so cannot convert
it to linear and back to tiled on reuse). This requires us to remember
to drop the extra pinning when freeing the object, or else we trigger
warnings about the pin leak. In commit fbbd37b36fa5 ("drm/i915: Move
object release to a freelist + worker"), the object free path was
deferred to a worker, but the unpinning of the quirk, along with marking
the object as reclaimable, was left on the immediate path (so that if
required we could reclaim the pages under memory pressure as early as
possible). However, this split introduced a bug where the pages were no
longer being unpinned if they were marked as unneeded.

[  231.800401] WARNING: CPU: 1 PID: 90 at drivers/gpu/drm/i915/i915_gem.c:4275 
__i915_gem_free_objects+0x326/0x3c0 [i915]
[  231.800403] WARN_ON(i915_gem_object_has_pinned_pages(obj))
[  231.800405] Modules linked in:
[  231.800406]  snd_hda_intel i915 snd_hda_codec_generic mei_me snd_hda_codec 
coretemp snd_hwdep mei lpc_ich snd_hda_core snd_pcm e1000e ptp pps_core [last 
unloaded: i915]
[  231.800426] CPU: 1 PID: 90 Comm: kworker/1:4 Tainted: G U  
4.9.0-rc2-CI-CI_DRM_1780+ #1
[  231.800428] Hardware name: LENOVO 7465CTO/7465CTO, BIOS 6DET44WW (2.08 ) 
04/22/2009
[  231.800456] Workqueue: events __i915_gem_free_work [i915]
[  231.800459]  c934fc80 8142dd65 c934fcd0 

[  231.800465]  c934fcc0 8107e4e6 10b30001 
1000
[  231.800469]  88011d3db740 880130ef  
880130ef5ea0
[  231.800474] Call Trace:
[  231.800479]  [] dump_stack+0x67/0x92
[  231.800484]  [] __warn+0xc6/0xe0
[  231.800487]  [] warn_slowpath_fmt+0x4a/0x50
[  231.800491]  [] ? kmem_cache_free+0x2dc/0x340
[  231.800520]  [] __i915_gem_free_objects+0x326/0x3c0 [i915]
[  231.800548]  [] __i915_gem_free_work+0x2e/0x50 [i915]
[  231.800552]  [] process_one_work+0x1ec/0x6b0
[  231.800555]  [] ? process_one_work+0x166/0x6b0
[  231.800558]  [] worker_thread+0x49/0x490
[  231.800561]  [] ? process_one_work+0x6b0/0x6b0
[  231.800563]  [] ? process_one_work+0x6b0/0x6b0
[  231.800566]  [] kthread+0xeb/0x110
[  231.800569]  [] ? kthread_park+0x60/0x60
[  231.800573]  [] ret_from_fork+0x27/0x40

Moving to a separate flag for tracking the quirked pin is overkill for
the bug (since we only have to interchange the two tests in
i915_gem_free_object) but it does reduce a complicated test on all
objects and provide a sanitycheck for uncommon code paths.

Fixes: fbbd37b36fa5 ("drm/i915: Move object release to a freelist + worker")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h|  6 ++
 drivers/gpu/drm/i915/i915_gem.c| 21 +
 drivers/gpu/drm/i915/i915_gem_tiling.c |  9 +++--
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51360d199263..539106a9c1af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2304,6 +2304,12 @@ struct drm_i915_gem_object {
 * pages were last acquired.
 */
bool dirty:1;
+
+   /**
+* This is set if the object has been pinned due to unknown
+* swizzling.
+*/
+   bool quirked:1;
} mm;
 
/** Breadcrumb of last rendering to the buffer.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6c51b21565d6..c9e52f75e1cb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2324,8 +2324,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
i915_gem_object_do_bit_17_swizzle(obj, st);
 
if (i915_gem_object_is_tiled(obj) &&
-   dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES)
+   dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
__i915_gem_object_pin_pages(obj);
+   obj->mm.quirked = true;
+   }
 
return st;
 
@@ -4091,10 +4093,15 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void 
*data,
if (obj->mm.pages &&
i915_gem_object_is_tiled(obj) &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
-   if (obj->mm.madv == I915_MADV_WILLNEED)
+   if (obj->mm.madv == I915_MADV_WILLNEED) {
+   GEM_BUG_ON(!obj->mm.quirked);
__i915_gem_object_unpin_pages(obj);
-   if (args->madv == I915_MADV_WILLNEED)
+   obj->mm.quirked = false;
+   }
+   if (args->madv == I915_MADV_WILLNEED) {
  

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

[Chris Wilson]

On Tue, Nov 01, 2016 at 09:43:53AM +, Tvrtko Ursulin wrote:
> 
> On 31/10/2016 10:26, Chris Wilson wrote:
> >With full-ppgtt one of the main bottlenecks is the lookup of the VMA
> >underneath the object. For execbuf there is merit in having a very fast
> >direct lookup of ctx:handle to the vma using a hashtree, but that still
> >leaves a large number of other lookups. One way to speed up the lookup
> >would be to use a rhashtable, but that requires extra allocations and
> >may exhibit poor worse case behaviour. An alternative is to use an
> >embedded rbtree, i.e. no extra allocations and deterministic behaviour,
> >but at the slight cost of O(lgN) lookups (instead of O(1) for
> >rhashtable). The major of such tree will be very shallow and so not much
> >slower, and still scales much, much better than the current unsorted
> >list.
> >
> >References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
> >Signed-off-by: Chris Wilson 
> >---
> > drivers/gpu/drm/i915/i915_drv.h |  1 +
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 80 
> > +
> > drivers/gpu/drm/i915/i915_gem_gtt.h |  1 +
> > 3 files changed, 57 insertions(+), 25 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index 7a18bf66f797..e923d6596cac 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -2230,6 +2230,7 @@ struct drm_i915_gem_object {
> >
> > /** List of VMAs backed by this object */
> > struct list_head vma_list;
> >+struct rb_root vma_tree;
> >
> > /** Stolen memory for this object, instead of being backed by shmem. */
> > struct drm_mm_node *stolen;
> >diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> >b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >index e7afad585929..aa2d21c41091 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >@@ -3399,6 +3399,7 @@ void i915_vma_destroy(struct i915_vma *vma)
> > GEM_BUG_ON(!i915_vma_is_closed(vma));
> > GEM_BUG_ON(vma->fence);
> >
> >+rb_erase(>obj_node, >obj->vma_tree);
> > list_del(>vm_link);
> > if (!i915_vma_is_ggtt(vma))
> > i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));
> >@@ -3416,12 +3417,33 @@ void i915_vma_close(struct i915_vma *vma)
> > WARN_ON(i915_vma_unbind(vma));
> > }
> >
> >+static inline int vma_compare(struct i915_vma *vma,
> >+  struct i915_address_space *vm,
> >+  const struct i915_ggtt_view *view)
> >+{
> >+GEM_BUG_ON(view && !i915_vma_is_ggtt(vma));
> >+
> >+if (vma->vm != vm)
> >+return vma->vm - vm;
> 
> This can theoretically overflow so I think long should be the return type.

Yeah, the same thought cross through my mind. gcc should be smart enough
to only use the cc flags, but still...

I miss the spaceship operator.
 
> >+
> >+if (!view)
> >+return vma->ggtt_view.type;
> >+
> >+if (vma->ggtt_view.type != view->type)
> >+return vma->ggtt_view.type - view->type;
> >+
> >+return memcmp(>ggtt_view.params,
> >+  >params,
> >+  sizeof(view->params));
> >+}
> >+
> > static struct i915_vma *
> > __i915_vma_create(struct drm_i915_gem_object *obj,
> >   struct i915_address_space *vm,
> >   const struct i915_ggtt_view *view)
> > {
> > struct i915_vma *vma;
> >+struct rb_node *rb, **p;
> > int i;
> >
> > GEM_BUG_ON(vm->closed);
> >@@ -3455,33 +3477,28 @@ __i915_vma_create(struct drm_i915_gem_object *obj,
> >
> > if (i915_is_ggtt(vm)) {
> > vma->flags |= I915_VMA_GGTT;
> >+list_add(>obj_link, >vma_list);
> > } else {
> > i915_ppgtt_get(i915_vm_to_ppgtt(vm));
> >+list_add_tail(>obj_link, >vma_list);
> > }
> 
> Will this make a difference to anything since it is not used for
> lookups? I suppose it makes a nicer debugfs output if nothing else
> so not complaining.

It does. The code assumes GGTT entries are first (some of my patches
came from a time before the regression was introduced by Daniel because
he claimed it made no difference but had not benchmarked it!).
-Chris

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

Re: [Intel-gfx] [PATCH 00/26] drm/i915: A game of OCD dominoes

[Ville Syrjälä]

On Mon, Oct 31, 2016 at 08:56:34PM +, Chris Wilson wrote:
> On Mon, Oct 31, 2016 at 10:36:59PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > I pretty much just wanted to store struct intel_crtc * instead
> > of struct drm_crtc * in pipe_to_crtc_mapping[] & co. but to
> > achieve it cleanly I ended up chasing quite few different things
> > that were accepting the wrong kind of type. And once I had
> > sorted out those mappign arrays, I had ended up in the old
> > watermark code which kept me busy for another good while.
> > Eventually I was able to claw my way back to sanity and I
> > decided to stop.
> > 
> > I'm going to blame Daniel for getting me on this track by
> > suggesting that I should pass dev_priv to the plane
> > constructos. That was enough of a trigger to get me started.
> > 
> > Entire series available here:
> > git://github.com/vsyrjala/linux.git dev_priv_intel_crtc_cleanup
> > 
> > Ville Syrjälä (26):
> >   drm/i915: Pass dev_priv to plane constructors
> >   drm/i915: Pass dev_priv to skl_init_scalers()
> >   drm/i915: Pass intel_crtc to intel_crtc_active()
> >   drm/i915: Pass intel_crtc to update_wm functions
> >   drm/i915: Use struct intel_crtc in legacy platform wm code
> >   drm/i915: Store struct intel_crtc * in {pipe,plane}_to_crtc_mapping[]
> >   drm/i915: Pass dev_priv to intel_wait_for_vblank()
> >   drm/i915: Pass dev_priv to vlv force pll functions
> >   drm/i915: Pass dev_priv to g4x wm functions
> >   drm/i915: Pass dev_priv to intel_get_crtc_for_pipe()
> >   drm/i915: Always use intel_get_crtc_for_pipe()
> >   drm/i915: Pass dev_priv to intel_crtc_init()
> >   drm/i915: Pass dev_priv to cdclk update funcs
> >   drm/i915: Pass dev_priv to .get_display_clock_speed()
> >   drm/i915: Pass dev_priv to IS_MOBILE()
> >   drm/i915: Pass dev_priv to IS_PINEVIEW()
> >   drm/i915: Pass dev_priv to i915_pineview_get_mem_freq() and
> > i915_ironlake_get_mem_freq()
> >   drm/i915: Pass dev_priv to .get_fifo_size()
> >   drm/i915: Pass dev_priv to HAS_FW_BLC
> >   drm/i915: Pass dev_priv to IS_BROADWATER/IS_CRESTLINE
> >   drm/i915: Pass dev_priv to rest of IS_FOO() macros for the old
> > platforms
> >   drm/i915: Pass dev_priv to single_enabled_crtc()
> >   drm/i915: Pass dev_priv to init_clock_gating
> >   drm/i915: Pass dev_priv to intel_suspend_hw()
> >   drm/i915: Pass dev_priv to ilk_setup_wm_latency() & co.
> >   drm/i915: Pass dev_priv to intel_init_pm()
> 
> All looked reasonable and beguiling in their simplicty. Nice trimming.
> Reviewed-by: Chris Wilson 
> 
> Are we still trimming the odd byte from object size?

-.text850282  0
+.text850218  0

:)

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

[Chris Wilson]

On Tue, Nov 01, 2016 at 09:20:33AM +, Tvrtko Ursulin wrote:
> 
> On 01/11/2016 09:06, Chris Wilson wrote:
> >On Tue, Nov 01, 2016 at 08:54:09AM +, Tvrtko Ursulin wrote:
> >>
> >>On 01/11/2016 08:50, Chris Wilson wrote:
> >>>On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote:
> 
> On 31/10/2016 10:26, Chris Wilson wrote:
> >With full-ppgtt one of the main bottlenecks is the lookup of the VMA
> >underneath the object. For execbuf there is merit in having a very fast
> >direct lookup of ctx:handle to the vma using a hashtree, but that still
> >leaves a large number of other lookups. One way to speed up the lookup
> >would be to use a rhashtable, but that requires extra allocations and
> >may exhibit poor worse case behaviour. An alternative is to use an
> >embedded rbtree, i.e. no extra allocations and deterministic behaviour,
> >but at the slight cost of O(lgN) lookups (instead of O(1) for
> >rhashtable). The major of such tree will be very shallow and so not much
> >slower, and still scales much, much better than the current unsorted
> >list.
> >
> >References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
> >Signed-off-by: Chris Wilson 
> 
> I suggest leaving this out of the mini-series which fixes the
> recently introduced bugs.
> >>>
> >>>Just review it now, it's a two year old bug that was impacting the test
> >>>cases I was running... :-p Then we won't have to review it next week ;)
> >>
> >>I'll review it, just split it out please so the CI fire can be
> >>extinguished first.
> >
> >Sure, I'm pushing the fixes as soon as they've been baked. There's a
> >regression fix that builds upon this patch for multiple timelines (the
> >linear walk in reservation_object is particularly nasty for scaling).
> 
> Which one is that, the reservation_object_get_fences_rcu in
> i915_gem_object_wait_reservation?

Mostly reservation_object_add_shared_fence()

The reservation object is not autopruning, those fences stay there until
replaced. So as an object is used by more and more contexts (such as
many GL clients sharing the same resource) that shared array keeps on
growing, and we have to walk over it on every execbuf, both to update
the fence and indeed often to compute the await.

We can use a radixtree/idr or a rhashtable here since they share the RCU
share lookup required for reservation_object (and couple in the seqlock
for update tracking), the stumbling point is the that
reservation_object_reserve_shared_fence() guarrantees the next
add_shared_fence() will not fail (ENOMEM). Both idr/radixtree have
preload, but both use per-cpu caches and so require preemption disabling
from the point of reservation to use; i.e. not suitable. Changing them
to preload onto a specific tree seems reasonably easy except for
convincing core of their merit. (There changing idr looks like it would
be easier.) radixtree is easier to use than idr, but iterating the
radixtree for (get_fences_rcu) is not as cheap as I expect. :|
-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 6/6] drm/i915: Store the vma in an rbtree under the object

[Tvrtko Ursulin]

On 31/10/2016 10:26, Chris Wilson wrote:

With full-ppgtt one of the main bottlenecks is the lookup of the VMA
underneath the object. For execbuf there is merit in having a very fast
direct lookup of ctx:handle to the vma using a hashtree, but that still
leaves a large number of other lookups. One way to speed up the lookup
would be to use a rhashtable, but that requires extra allocations and
may exhibit poor worse case behaviour. An alternative is to use an
embedded rbtree, i.e. no extra allocations and deterministic behaviour,
but at the slight cost of O(lgN) lookups (instead of O(1) for
rhashtable). The major of such tree will be very shallow and so not much
slower, and still scales much, much better than the current unsorted
list.

References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 80 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  1 +
 3 files changed, 57 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a18bf66f797..e923d6596cac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2230,6 +2230,7 @@ struct drm_i915_gem_object {

/** List of VMAs backed by this object */
struct list_head vma_list;
+   struct rb_root vma_tree;

/** Stolen memory for this object, instead of being backed by shmem. */
struct drm_mm_node *stolen;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e7afad585929..aa2d21c41091 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3399,6 +3399,7 @@ void i915_vma_destroy(struct i915_vma *vma)
GEM_BUG_ON(!i915_vma_is_closed(vma));
GEM_BUG_ON(vma->fence);

+   rb_erase(>obj_node, >obj->vma_tree);
list_del(>vm_link);
if (!i915_vma_is_ggtt(vma))
i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));
@@ -3416,12 +3417,33 @@ void i915_vma_close(struct i915_vma *vma)
WARN_ON(i915_vma_unbind(vma));
 }

+static inline int vma_compare(struct i915_vma *vma,
+ struct i915_address_space *vm,
+ const struct i915_ggtt_view *view)
+{
+   GEM_BUG_ON(view && !i915_vma_is_ggtt(vma));
+
+   if (vma->vm != vm)
+   return vma->vm - vm;


This can theoretically overflow so I think long should be the return type.


+
+   if (!view)
+   return vma->ggtt_view.type;
+
+   if (vma->ggtt_view.type != view->type)
+   return vma->ggtt_view.type - view->type;
+
+   return memcmp(>ggtt_view.params,
+ >params,
+ sizeof(view->params));
+}
+
 static struct i915_vma *
 __i915_vma_create(struct drm_i915_gem_object *obj,
  struct i915_address_space *vm,
  const struct i915_ggtt_view *view)
 {
struct i915_vma *vma;
+   struct rb_node *rb, **p;
int i;

GEM_BUG_ON(vm->closed);
@@ -3455,33 +3477,28 @@ __i915_vma_create(struct drm_i915_gem_object *obj,

if (i915_is_ggtt(vm)) {
vma->flags |= I915_VMA_GGTT;
+   list_add(>obj_link, >vma_list);
} else {
i915_ppgtt_get(i915_vm_to_ppgtt(vm));
+   list_add_tail(>obj_link, >vma_list);
}


Will this make a difference to anything since it is not used for 
lookups? I suppose it makes a nicer debugfs output if nothing else so 
not complaining.




-   list_add_tail(>obj_link, >vma_list);
-   return vma;
-}
+   rb = NULL;
+   p = >vma_tree.rb_node;
+   while (*p) {
+   struct i915_vma *pos;

-static inline bool vma_matches(struct i915_vma *vma,
-  struct i915_address_space *vm,
-  const struct i915_ggtt_view *view)
-{
-   if (vma->vm != vm)
-   return false;
-
-   if (!i915_vma_is_ggtt(vma))
-   return true;
-
-   if (!view)
-   return vma->ggtt_view.type == 0;
-
-   if (vma->ggtt_view.type != view->type)
-   return false;
+   rb = *p;
+   pos = rb_entry(rb, struct i915_vma, obj_node);
+   if (vma_compare(pos, vm, view) < 0)
+   p = >rb_right;
+   else
+   p = >rb_left;
+   }
+   rb_link_node(>obj_node, rb, p);
+   rb_insert_color(>obj_node, >vma_tree);

-   return memcmp(>ggtt_view.params,
- >params,
- sizeof(view->params)) == 0;
+   return vma;
 }

 struct i915_vma *
@@ -3501,11 +3518,22 @@ i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
const struct i915_ggtt_view *view)
 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Use the full hammer when shutting down the rcu tasks

[Chris Wilson]

On Tue, Nov 01, 2016 at 09:20:19AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,1/3] drm/i915: Use the full hammer when 
> shutting down the rcu tasks
> URL   : https://patchwork.freedesktop.org/series/14660/
> State : warning
> 
> == Summary ==
> 
> Series 14660v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/14660/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (fi-bdw-5557u)
> pass   -> SKIP   (fi-skl-6260u)
> Test kms_busy:
> Subgroup basic-flip-default-a:
> pass   -> DMESG-WARN (fi-ilk-650)
> Test kms_force_connector_basic:
> Subgroup force-edid:
> dmesg-warn -> PASS   (fi-snb-2520m)
> Test kms_pipe_crc_basic:
> Subgroup bad-nb-words-1:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup bad-nb-words-3:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup bad-source:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup hang-read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)

Onwards!
-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 6/6] drm/i915: Store the vma in an rbtree under the object

[Tvrtko Ursulin]

On 01/11/2016 09:06, Chris Wilson wrote:

On Tue, Nov 01, 2016 at 08:54:09AM +, Tvrtko Ursulin wrote:


On 01/11/2016 08:50, Chris Wilson wrote:

On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote:


On 31/10/2016 10:26, Chris Wilson wrote:

With full-ppgtt one of the main bottlenecks is the lookup of the VMA
underneath the object. For execbuf there is merit in having a very fast
direct lookup of ctx:handle to the vma using a hashtree, but that still
leaves a large number of other lookups. One way to speed up the lookup
would be to use a rhashtable, but that requires extra allocations and
may exhibit poor worse case behaviour. An alternative is to use an
embedded rbtree, i.e. no extra allocations and deterministic behaviour,
but at the slight cost of O(lgN) lookups (instead of O(1) for
rhashtable). The major of such tree will be very shallow and so not much
slower, and still scales much, much better than the current unsorted
list.

References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
Signed-off-by: Chris Wilson 


I suggest leaving this out of the mini-series which fixes the
recently introduced bugs.


Just review it now, it's a two year old bug that was impacting the test
cases I was running... :-p Then we won't have to review it next week ;)


I'll review it, just split it out please so the CI fire can be
extinguished first.


Sure, I'm pushing the fixes as soon as they've been baked. There's a
regression fix that builds upon this patch for multiple timelines (the
linear walk in reservation_object is particularly nasty for scaling).


Which one is that, the reservation_object_get_fences_rcu in 
i915_gem_object_wait_reservation?


Regards,

Tvrtko

___
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 [CI,1/3] drm/i915: Use the full hammer when shutting down the rcu tasks

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Use the full hammer when 
shutting down the rcu tasks
URL   : https://patchwork.freedesktop.org/series/14660/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-bdw-5557u)
pass   -> SKIP   (fi-skl-6260u)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_force_connector_basic:
Subgroup force-edid:
dmesg-warn -> PASS   (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup bad-nb-words-3:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup bad-source:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-ilk-650   total:241  pass:182  dwarn:5   dfail:0   fail:0   skip:54 
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34 

6a1197bcb5cc18a56ad4ae8e6d706a212bc3db7d drm-intel-nightly: 
2016y-10m-31d-14h-58m-16s UTC integration manifest
5d64aee drm/i915: Move the recently scanned objects to the tail after shrinking
1d206d0 drm/i915: Discard objects from mm global_list after being shrunk
cbd927d drm/i915: Use the full hammer when shutting down the rcu tasks

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

[Joonas Lahtinen]

On ti, 2016-11-01 at 09:15 +, Chris Wilson wrote:
> On Tue, Nov 01, 2016 at 11:10:31AM +0200, Joonas Lahtinen wrote:
> > 
> > On ma, 2016-10-31 at 12:40 +, Chris Wilson wrote:
> > As discussed in IRC, I think we rather should add a lock class to
> > obj->mm, to avoid chasing these in the future.
> 
> All ears :) The complicated one isn't obj->mm, but the timeline->lock.
> That we may do engine1->tl->lock, engine2->tl->lock, request->tl->lock,
> so far.

Just realized we would have to properly reboot the kernel after each
test not to run out of locking classes...

For timeline->lock, the same thing. Just assign each timeline its own
lock class. But no bonus until we reboot enough.

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

Re: [Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

[Chris Wilson]

On Tue, Nov 01, 2016 at 11:10:31AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-10-31 at 12:40 +, Chris Wilson wrote:
> As discussed in IRC, I think we rather should add a lock class to
> obj->mm, to avoid chasing these in the future.

All ears :) The complicated one isn't obj->mm, but the timeline->lock.
That we may do engine1->tl->lock, engine2->tl->lock, request->tl->lock,
so far.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

[Joonas Lahtinen]

On ma, 2016-10-31 at 12:40 +, Chris Wilson wrote:
> As we may allocate from within the obj->mm.lock we may enter the
> shrinker for direct reclaim. Operating on the current object is
> prevented by checking for obj->mm.pages (which is only set as the last
> operation in the allocation path). However, we need to identity the
> single recursion of accessing another object's obj->mm.lock as the two
> locks have identical class and so appear to be the same to lockdep,
> convincing it that a deadlock is possible. Use mutex_lock_nested() to
> remove the false positive.
> 
> [ 2165.945734] =
> [ 2165.945749] [ INFO: inconsistent lock state ]
> [ 2165.945765] 4.9.0-rc2+ #2 Tainted: GW
> [ 2165.945781] -
> [ 2165.945796] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
> [ 2165.945816] kswapd0/62 [HC0[0]:SC0[0]:HE1:SE1] takes: 
> (>mm.lock){+.+.?.}, at: [] i915_gem_shrink+0x29f/0x500 
> [i915]
> [ 2165.945904] {RECLAIM_FS-ON-W} state was registered at:
> [ 2165.945931] [] mark_held_locks+0x6f/0xa0
> [ 2165.945956] [] lockdep_trace_alloc+0x69/0xc0
> [ 2165.945982] [] kmem_cache_alloc_trace+0x33/0x2a0
> [ 2165.946019] [] 
> i915_gem_object_get_pages_stolen+0x6a/0xd0 [i915]
> [ 2165.946060] [] i915_gem_object_get_pages+0x20/0x60 
> [i915]
> [ 2165.946098] [] __i915_gem_object_get_pages+0x58/0x70 
> [i915]
> [ 2165.946138] [] _i915_gem_object_create_stolen+0xec/0x120 
> [i915]
> [ 2165.946177] [] 
> i915_gem_object_create_stolen_for_preallocated+0xf3/0x3f0 [i915]
> [ 2165.946222] [] 
> intel_alloc_initial_plane_obj.isra.125+0xd3/0x200 [i915]
> [ 2165.946266] [] intel_modeset_init+0x931/0x1530 [i915]
> [ 2165.946301] [] i915_driver_load+0xa14/0x14a0 [i915]
> [ 2165.946335] [] i915_pci_probe+0x4f/0x70 [i915]
> [ 2165.946362] [] local_pci_probe+0x42/0xa0
> [ 2165.946386] [] pci_device_probe+0x103/0x150
> [ 2165.946411] [] driver_probe_device+0x223/0x430
> [ 2165.946436] [] __driver_attach+0xe3/0xf0
> [ 2165.946461] [] bus_for_each_dev+0x73/0xc0
> [ 2165.946485] [] driver_attach+0x1e/0x20
> [ 2165.946508] [] bus_add_driver+0x173/0x270
> [ 2165.946533] [] driver_register+0x60/0xe0
> [ 2165.946557] [] __pci_register_driver+0x5d/0x60
> [ 2165.946606] [] soundcore_open+0x17/0x230 [soundcore]
> [ 2165.946636] [] do_one_initcall+0x50/0x180
> [ 2165.946661] [] do_init_module+0x5f/0x1f1
> [ 2165.946685] [] load_module+0x2174/0x2a80
> [ 2165.946709] [] SYSC_finit_module+0xdf/0x110
> [ 2165.946734] [] SyS_finit_module+0xe/0x10
> [ 2165.946758] [] entry_SYSCALL_64_fastpath+0x18/0xad
> [ 2165.946776] irq event stamp: 90871
> [ 2165.946788] hardirqs last  enabled at (90871):
> [ 2165.946805] [] __mutex_unlock_slowpath+0x11a/0x1c0
> [ 2165.946823] hardirqs last disabled at (90870):
> [ 2165.946839] [] __mutex_unlock_slowpath+0x5b/0x1c0
> [ 2165.946856] softirqs last  enabled at (90858):
> [ 2165.946872] [] __do_softirq+0x39a/0x4c6
> [ 2165.946887] softirqs last disabled at (90671):
> [ 2165.946902] [] irq_exit+0xea/0xf0
> [ 2165.946916] other info that might help us debug this:
> [ 2165.946936]  Possible unsafe locking scenario:
> [ 2165.946955]CPU0
> [ 2165.946965]
> [ 2165.946975]   lock(>mm.lock);
> [ 2165.947000]   
> [ 2165.947010] lock(>mm.lock);
> [ 2165.947035] *** DEADLOCK ***
> [ 2165.947054] 2 locks held by kswapd0/62:
> [ 2165.947067]  #0: (shrinker_rwsem){..}, at: [] 
> shrink_slab.part.40+0x5e/0x5d0
> [ 2165.947120]  #1: (>struct_mutex){+.+.+.}, at: [] 
> i915_gem_shrinker_lock+0x1b/0x60 [i915]
> [ 2165.948909] stack backtrace:
> [ 2165.950650] CPU: 2 PID: 62 Comm: kswapd0 Tainted: GW 4.9.0-rc2+ #2
> [ 2165.951587] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 
> 12/01/2015
> [ 2165.952484]  c9b5f8c8 b137f645 88016c5a2700 
> b25f20a0
> [ 2165.953395]  c9b5f918 b10bcecd  
> 88010001
> [ 2165.954305]  0001 000a 88016c5a2fd0 
> 88016c5a2700
> [ 2165.955240] Call Trace:
> [ 2165.956170]  [] dump_stack+0x68/0x93
> [ 2165.957071]  [] print_usage_bug+0x1dd/0x1f0
> [ 2165.957979]  [] mark_lock+0x559/0x5c0
> [ 2165.958875]  [] ?  
> print_shortest_lock_dependencies+0x1b0/0x1b0
> [ 2165.959829]  [] __lock_acquire+0x66d/0x12a0
> [ 2165.960729]  [] ? __slab_free+0xa1/0x340
> [ 2165.961625]  [] ?  debug_lockdep_rcu_enabled+0x1d/0x20
> [ 2165.962530]  [] ? mark_held_locks+0x6f/0xa0
> [ 2165.963457]  [] lock_acquire+0xf0/0x1f0
> [ 2165.964368]  [] ? i915_gem_shrink+0x29f/0x500 [i915]
> [ 2165.965269]  [] ? i915_gem_shrink+0x29f/0x500 [i915]
> [ 2165.966150]  [] mutex_lock_nested+0x77/0x420
> [ 2165.967030]  [] ? i915_gem_shrink+0x29f/0x500 [i915]
> [ 2165.967952]  [] ?  
> __i915_gem_object_put_pages.part.58+0x161/0x1b0 [i915]
> [ 2165.968835]  [] i915_gem_shrink+0x29f/0x500 [i915]
> [ 2165.969712]  [] i915_gem_shrinker_scan+0x70/0xb0 [i915]
> [ 2165.970591]  [] shrink_slab.part.40+0x1fe/0x5d0
> [ 

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

[Paul Bolle]

On Tue, 2016-11-01 at 09:57 +0100, Maarten Lankhorst wrote:
> Otherwise looks sane, I have a similar patch in my tree. I didn't
> submit it yet but the fix was similar. Except for the
> dev_cdclk stuff.
> 
> With the last dev_cdclk assignment removed:
> 
> Reviewed-by: Maarten Lankhorst 

So I've been running this patch for a few days now. First I tested it
on top of v4.8.4. Now I'm running it on top of v4.8.5.

My current v4.8.5 boot saw this new (for me) *ERROR*, twice:
    <3>[43483.521341] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU 
about cdclk change
<3>[108639.090776] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU 
about cdclk change

Related or a coincidence?

Thanks,


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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

[Chris Wilson]

On Tue, Nov 01, 2016 at 08:54:09AM +, Tvrtko Ursulin wrote:
> 
> On 01/11/2016 08:50, Chris Wilson wrote:
> >On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote:
> >>
> >>On 31/10/2016 10:26, Chris Wilson wrote:
> >>>With full-ppgtt one of the main bottlenecks is the lookup of the VMA
> >>>underneath the object. For execbuf there is merit in having a very fast
> >>>direct lookup of ctx:handle to the vma using a hashtree, but that still
> >>>leaves a large number of other lookups. One way to speed up the lookup
> >>>would be to use a rhashtable, but that requires extra allocations and
> >>>may exhibit poor worse case behaviour. An alternative is to use an
> >>>embedded rbtree, i.e. no extra allocations and deterministic behaviour,
> >>>but at the slight cost of O(lgN) lookups (instead of O(1) for
> >>>rhashtable). The major of such tree will be very shallow and so not much
> >>>slower, and still scales much, much better than the current unsorted
> >>>list.
> >>>
> >>>References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
> >>>Signed-off-by: Chris Wilson 
> >>
> >>I suggest leaving this out of the mini-series which fixes the
> >>recently introduced bugs.
> >
> >Just review it now, it's a two year old bug that was impacting the test
> >cases I was running... :-p Then we won't have to review it next week ;)
> 
> I'll review it, just split it out please so the CI fire can be
> extinguished first.

Sure, I'm pushing the fixes as soon as they've been baked. There's a
regression fix that builds upon this patch for multiple timelines (the
linear walk in reservation_object is particularly nasty for scaling).
-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 i-g-t v4] tests/kms_plane_multiple: CRC based atomic correctness test

[Mika Kahola]

On Tue, 2016-11-01 at 09:25 +0100, Maarten Lankhorst wrote:
> Op 20-10-16 om 11:27 schreef Mika Kahola:
> > 
> > This is a testcase with multiple planes. The idea here is the
> > following
> > 
> >  - draw a uniform frame with blue color
> >  - grab crc for reference
> >  - put planes randomly on top with the same blue color
> >  - punch holes with black color into the primary framebuffer
> >  - ideally the planes should cover these holes so that the output
> > is the
> >    identical to reference crc
> >  - composite all with one ioctl call
> >  - grab crc and verify that the reference crc is equal
> >  - repeat this for dozen iterations to maximize coverage
> > 
> > v4: For atomic test enable crc capturing before entering into a
> > iteration loop. After each iteration, check that page flip
> > didn't take no more than 1 vblank, fetch all crc's and check
> > the values.
> > 
> > Introduce new command line parameter for the number of
> > iterations.
> > The test run from 1 to 256 iterations.
> > 
> > v3: Cleanup by removing separate plane array
> > For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
> > Grab crc by using igt_pipe_crc_get_crc instead of
> > igt_pipe_crc_collect_crc
> > Rename nplanes variable to max_planes
> > To optimize test execution, run iterations after the modeset
> > 
> > v2: Keep a logfile on random number seeds per subtest that are not
> > skipped
> > due to unmet test requirements
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  tests/Makefile.sources |   1 +
> >  tests/kms_plane_multiple.c | 475
> > +
> >  2 files changed, 476 insertions(+)
> >  create mode 100644 tests/kms_plane_multiple.c
> > 
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 6d081c3..ffd59c1 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -105,6 +105,7 @@ TESTS_progs_M = \
> >     kms_pipe_color \
> >     kms_pipe_crc_basic \
> >     kms_plane \
> > +   kms_plane_multiple \
> >     kms_properties \
> >     kms_psr_sink_crc \
> >     kms_render \
> > diff --git a/tests/kms_plane_multiple.c
> > b/tests/kms_plane_multiple.c
> > new file mode 100644
> > index 000..a18cdff
> > --- /dev/null
> > +++ b/tests/kms_plane_multiple.c
> > @@ -0,0 +1,475 @@
> > +/*
> > + * Copyright © 2016 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > + * and/or sell copies of the Software, and to permit persons to
> > whom the
> > + * Software is furnished to do so, subject to the following
> > conditions:
> > + *
> > + * The above copyright notice and this permission notice
> > (including the next
> > + * paragraph) shall be included in all copies or substantial
> > portions of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > OTHER DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + */
> > +
> > +#include "igt.h"
> > +#include "drmtest.h"
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple
> > planes ");
> > +
> > +#define MAX_CRCS 1
> > +#define SIZE 128
> > +
> > +#define IN_RANGE(X, MIN, MAX) ((X) < (MIN) || (X) > (MAX) ? 16 :
> > X)
> 16 or MAX? anyway it's only used in one place, so might as well
> remove the macro.
> > 
> > +typedef struct {
> > +   float red;
> > +   float green;
> > +   float blue;
> > +} color_t;
> > +
> > +typedef struct {
> > +   int drm_fd;
> > +   igt_display_t display;
> > +   igt_pipe_crc_t *pipe_crc;
> > +   igt_plane_t *plane[IGT_MAX_PLANES];
> > +   struct igt_fb fb[IGT_MAX_PLANES];
> > +} data_t;
> > +
> > +typedef struct {
> > +   data_t *data;
> > +   igt_crc_t reference_crc;
> > +} test_position_t;
> > +
> > +/* Command line parameters. */
> > +struct {
> > +   unsigned iterations;
> > +   bool user_seed;
> > +   int seed;
> > +   bool user_logfile;
> > +   char logfile[SIZE];
> The logfile and its infrastructure could be removed if you print the
> seed in with igt_debug so you get it when you run with --debug, or
> igt_info if you always want to print it.
> 
> In general, it's best to keep tests as dumb as possible. It's easier
> to include a normal 

Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

[Maarten Lankhorst]

Op 28-10-16 om 18:59 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> When we end up not recomputing the cdclk, we need to populate
> intel_state->cdclk with the "atomic_cdclk_freq" instead of the
> current cdclk_freq. When no pipes are active, the actual cdclk_freq
> may be lower than what the configuration of the planes and
> pipes would require from the point of view of the software state.
>
> intel_state->dev_cdclk is the computed actual cdclk in such cases,
> so let's populate that with the current cdclk value. Although basically
> nothing should ever use dev_cdclk for any checks and whatnot.
>
> This fixes bogus WARNS from skl_max_scale() which is trying to check
> the plane software state against the cdclk frequency. So any time
> it got called during DPMS off for instance, we might have tripped
> the warn if the current mode would have required a higher than
> minimum cdclk.
>
> Cc: Maarten Lankhorst 
> Cc: Mika Kahola 
> Cc: bruno.pag...@ens-lyon.org
> Cc: Daniel J Blueman 
> Cc: Paul Bolle 
> Cc: Joseph Yasi 
> Tested-by: Paul Bolle 
> Tested-by: Joseph Yasi 
> Cc: sta...@vger.kernel.org
> Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were 
> active.")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 895b3dc50e3f..f010e154e33e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14040,8 +14040,10 @@ static int intel_modeset_checks(struct 
> drm_atomic_state *state)
>  
>   DRM_DEBUG_KMS("New cdclk calculated to be atomic %u, actual 
> %u\n",
> intel_state->cdclk, intel_state->dev_cdclk);
> - } else
> + } else {
>   to_intel_atomic_state(state)->cdclk = 
> dev_priv->atomic_cdclk_freq;
> + to_intel_atomic_state(state)->dev_cdclk = dev_priv->cdclk_freq;
> + }
This shouldn't be required in this case, but might as well do so since it 
doesn't hurt either.
>   intel_modeset_clear_plls(state);
>  
> @@ -14142,8 +14144,10 @@ static int intel_atomic_check(struct drm_device *dev,
>  
>   if (ret)
>   return ret;
> - } else
> - intel_state->cdclk = dev_priv->cdclk_freq;
> + } else {
> + intel_state->cdclk = dev_priv->atomic_cdclk_freq;
> + intel_state->dev_cdclk = dev_priv->cdclk_freq;
> + }
We shouldn't rely on dev_cdclk being valid for the !modeset case.
Best to keep it zero there, the global cdclk can't be changed and the 
non-modeset case shouldn't rely on the current setting.

Otherwise looks sane, I have a similar patch in my tree. I didn't submit it yet 
but the fix was similar. Except for the
dev_cdclk stuff.

With the last dev_cdclk assignment removed:

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

[Tvrtko Ursulin]

On 01/11/2016 08:50, Chris Wilson wrote:

On Tue, Nov 01, 2016 at 08:41:01AM +, Tvrtko Ursulin wrote:


On 31/10/2016 10:26, Chris Wilson wrote:

With full-ppgtt one of the main bottlenecks is the lookup of the VMA
underneath the object. For execbuf there is merit in having a very fast
direct lookup of ctx:handle to the vma using a hashtree, but that still
leaves a large number of other lookups. One way to speed up the lookup
would be to use a rhashtable, but that requires extra allocations and
may exhibit poor worse case behaviour. An alternative is to use an
embedded rbtree, i.e. no extra allocations and deterministic behaviour,
but at the slight cost of O(lgN) lookups (instead of O(1) for
rhashtable). The major of such tree will be very shallow and so not much
slower, and still scales much, much better than the current unsorted
list.

References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
Signed-off-by: Chris Wilson 


I suggest leaving this out of the mini-series which fixes the
recently introduced bugs.


Just review it now, it's a two year old bug that was impacting the test
cases I was running... :-p Then we won't have to review it next week ;)


I'll review it, just split it out please so the CI fire can be 
extinguished first.


Regards,

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

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Track pages pinned due to swizzling quirk

[Tvrtko Ursulin]

On 01/11/2016 08:48, Chris Wilson wrote:

On Tue, Nov 01, 2016 at 08:39:14AM +, Tvrtko Ursulin wrote:


On 31/10/2016 10:26, Chris Wilson wrote:

If we have a tiled object and an unknown CPU swizzle pattern, we pin the
pages to prevent the object from being swapped out (and us corrupting
the contents as we do not know the access pattern and so cannot convert
it to linear and back to tiled on reuse). This requires us to remember
to drop the extra pinning when freeing the object, or else we trigger
warnings about the pin leak. In commit fbbd37b36fa5 ("drm/i915: Move
object release to a freelist + worker"), the object free path was
deferred to a work, but the unpinning of the quirk, along with marking
the object as reclaimable, was left on the immediate path (so that if
required we could reclaim the pages under memory pressure as early as
possible). However, this split introduced a bug where the pages we no
longer being unpinned if they were marked as unneeded.


Last sentence is broken.


Almost the right words in the wrong order.


if (obj->mm.madv != __I915_MADV_PURGED)
@@ -4335,14 +4342,12 @@ void i915_gem_free_object(struct drm_gem_object 
*gem_obj)
{
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);

+   if (obj->mm.quirked)
+   __i915_gem_object_unpin_pages(obj);
+
if (discard_backing_storage(obj))
obj->mm.madv = I915_MADV_DONTNEED;

-   if (obj->mm.pages && obj->mm.madv == I915_MADV_WILLNEED &&
-   to_i915(obj->base.dev)->quirks & QUIRK_PIN_SWIZZLED_PAGES &&
-   i915_gem_object_is_tiled(obj))
-   __i915_gem_object_unpin_pages(obj);
-


This reordering would not have been enough to fix this?


Yes. I was trying to avoid the repeated if() conditions and thought a
flag would eliminate a few of them. It only managed to kill this one and
provide assertions elsewhere.

Still we reduce the 3 [of 4] tests done to one for all devices but some
odd gen3/gen4 (and gain a sanity check for uncommon code paths).


Okay then, with the commit message fix:

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Implement Link Rate fallback on Link training failure

[Jani Nikula]

On Sat, 29 Oct 2016, Manasi Navare  wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
>
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
>
> v2:
> * Squashed a few patches (Jani Nikula)
>
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c   |  4 ++
>  drivers/gpu/drm/i915/intel_ddi.c  | 23 -
>  drivers/gpu/drm/i915/intel_dp.c   | 74 
> +--
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
>  drivers/gpu/drm/i915/intel_drv.h  |  5 +-
>  5 files changed, 110 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 75ad01d..a3df3a4 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -519,6 +519,10 @@ static int handle_conflicting_encoders(struct 
> drm_atomic_state *state,
>  connector_state);
>   if (ret)
>   return ret;
> +
> + crtc_state = drm_atomic_get_existing_crtc_state(state, 
> connector->state->crtc);
> + if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> + crtc_state->connectors_changed = true;
>   }
>  
>   /*
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 938ac4d..319eeca 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = _connector->base;
>  
>   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>link_mst);
> @@ -1694,7 +1696,26 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder);
>   intel_ddi_init_dp_buf_reg(encoder);
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> - intel_dp_start_link_train(intel_dp);
> + if (!intel_dp_start_link_train(intel_dp)) {
> + DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
> count = %d",
> +   link_rate, lane_count);
> + intel_dp->link_train_failed = true;
> + intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
> + lane_count);
> + /* Schedule a Hotplug Uevent to userspace to start modeset */
> + schedule_work(_connector->modeset_retry_work);

This is not just about DDI. Need to do this for the other cases too.

> + } else {
> + DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
> count = %d",
> +   link_rate, lane_count);
> + intel_dp->link_train_failed = false;
> + intel_dp->fallback_link_rate_index = -1;
> + intel_dp->fallback_link_rate = 0;
> + intel_dp->fallback_lane_count = 0;
> + connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
> + intel_dp_set_link_status_property(connector,
> +   DRM_MODE_LINK_STATUS_GOOD);

Looks like you never actually read connector->link_status... Why do you
need both connector->link_status and intel_dp->link_train_failed? Do you
think you have 4 states? What are they? Can't this all be in sync with
the property?

> + }
> +
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fb4fcdd..d1f0e2c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -354,8 +354,14 @@ void intel_dp_get_link_train_fallback_values(struct 
> intel_dp *intel_dp,
>   target_clock = fixed_mode->clock;
>   }
>  
> - max_link_clock = intel_dp_max_link_rate(intel_dp);
> - 

[Intel-gfx] [CI 3/3] drm/i915: Move the recently scanned objects to the tail after shrinking

[Chris Wilson]

During shrinking, we walk over the list of objects searching for
victims. Any that are not removed are put back into the global list.
Currently, they are put back in order (at the front) which means they
will be first to be scanned again. If we instead move them to the rear
of the list, we will scan new potential victims on the next pass and
waste less time rescanning unshrinkable objects. Normally the lists are
kept in rough order to shrinking (with object least frequently used at
the start), by moving just scanned objects to the rear we are
acknowledging that they are still in use.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 9ace5f9f5317..0993afc0e725 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -234,7 +234,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
mutex_unlock(>mm.lock);
}
}
-   list_splice(_in_list, phase->list);
+   list_splice_tail(_in_list, phase->list);
}
 
if (flags & I915_SHRINK_BOUND)
-- 
2.10.2

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

[Intel-gfx] [CI 2/3] drm/i915: Discard objects from mm global_list after being shrunk

[Chris Wilson]

In the shrinker, we can safely remove an empty object (obj->mm.pages ==
NULL) after having discarded the pages because we are holding the
struct_mutex.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 0daa09cabbcc..9ace5f9f5317 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -228,6 +228,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
  SINGLE_DEPTH_NESTING);
if (!obj->mm.pages) {
__i915_gem_object_invalidate(obj);
+   list_del_init(>global_list);
count += obj->base.size >> PAGE_SHIFT;
}
mutex_unlock(>mm.lock);
-- 
2.10.2

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

[Intel-gfx] [CI 1/3] drm/i915: Use the full hammer when shutting down the rcu tasks

[Chris Wilson]

To flush all call_rcu() tasks (here from i915_gem_free_object()) we need
to call rcu_barrier() (not synchronize_rcu()). If we don't then we may
still have objects being freed as we continue to teardown the driver -
in particular, the recently released rings may race with the memory
manager shutdown resulting in sporadic:

[  142.217186] WARNING: CPU: 7 PID: 6185 at drivers/gpu/drm/drm_mm.c:932 
drm_mm_takedown+0x2e/0x40
[  142.217187] Memory manager not clean during takedown.
[  142.217187] Modules linked in: i915(-) x86_pkg_temp_thermal intel_powerclamp 
coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich 
snd_hda_codec_realtek snd_hda_codec_generic mei_me mei snd_hda_codec_hdmi 
snd_hda_codec snd_hwdep snd_hda_core snd_pcm e1000e ptp pps_core [last 
unloaded: snd_hda_intel]
[  142.217199] CPU: 7 PID: 6185 Comm: rmmod Not tainted 
4.9.0-rc2-CI-Trybot_242+ #1
[  142.217199] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS FBKT34AUS 
04/24/2013
[  142.217200]  c90002ecfce0 8142dd65 c90002ecfd30 

[  142.217202]  c90002ecfd20 8107e4e6 03a40778c2a8 
880401355c48
[  142.217204]  88040778c2a8 a040f3c0 a040f4a0 
5621fbf8b1f0
[  142.217206] Call Trace:
[  142.217209]  [] dump_stack+0x67/0x92
[  142.217211]  [] __warn+0xc6/0xe0
[  142.217213]  [] warn_slowpath_fmt+0x4a/0x50
[  142.217214]  [] drm_mm_takedown+0x2e/0x40
[  142.217236]  [] i915_gem_cleanup_stolen+0x1a/0x20 [i915]
[  142.217246]  [] i915_ggtt_cleanup_hw+0x31/0xb0 [i915]
[  142.217253]  [] i915_driver_cleanup_hw+0x31/0x40 [i915]
[  142.217260]  [] i915_driver_unload+0x141/0x1a0 [i915]
[  142.217268]  [] i915_pci_remove+0x14/0x20 [i915]
[  142.217269]  [] pci_device_remove+0x34/0xb0
[  142.217271]  [] __device_release_driver+0x9c/0x150
[  142.217272]  [] driver_detach+0xb6/0xc0
[  142.217273]  [] bus_remove_driver+0x53/0xd0
[  142.217274]  [] driver_unregister+0x27/0x50
[  142.217276]  [] pci_unregister_driver+0x25/0x70
[  142.217287]  [] i915_exit+0x1a/0x71 [i915]
[  142.217289]  [] SyS_delete_module+0x193/0x1e0
[  142.217291]  [] entry_SYSCALL_64_fastpath+0x1c/0xb1
[  142.217292] ---[ end trace 6fd164859c154772 ]---
[  142.217505] [drm:show_leaks] *ERROR* node [6b6b6b6b6b6b6b6b + 
6b6b6b6b6b6b6b6b]: inserted at
[] save_stack.isra.1+0x53/0xa0
[] 
drm_mm_insert_node_in_range_generic+0x2ad/0x360
[] 
i915_gem_stolen_insert_node_in_range+0x93/0xe0 [i915]
[] i915_gem_object_create_stolen+0x75/0xb0 
[i915]
[] intel_engine_create_ring+0x9a/0x140 [i915]
[] intel_init_ring_buffer+0xf1/0x440 [i915]
[] intel_init_render_ring_buffer+0xab/0x1b0 
[i915]
[] intel_engines_init+0xc8/0x210 [i915]
[] i915_gem_init+0xac/0xf0 [i915]
[] i915_driver_load+0x9c4/0x1430 [i915]
[] i915_pci_probe+0x28/0x40 [i915]
[] pci_device_probe+0x85/0xf0
[] driver_probe_device+0x21f/0x430
[] __driver_attach+0xde/0xe0

In particular note that the node was being poisoned as we inspected the
list, a  clear indication that the object is being freed as we make the
assertion.

v2: Don't loop, just assert that we do all the work required as that
will be better at detecting further errors.

Fixes: fbbd37b36fa5 ("drm/i915: Move object release to a freelist + worker")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 +-
 drivers/gpu/drm/i915/i915_gem.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6a99544c98d3..3b9bfd2cf0c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -544,7 +544,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_context_fini(_priv->drm);
mutex_unlock(_priv->drm.struct_mutex);
 
-   synchronize_rcu();
+   rcu_barrier();
flush_work(_priv->mm.free_work);
 
WARN_ON(!list_empty(_priv->context_list));
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1e5d2bf777e4..b51274562e79 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4787,6 +4787,8 @@ void i915_gem_load_cleanup(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
+   WARN_ON(!llist_empty(_priv->mm.free_list));
+
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
kmem_cache_destroy(dev_priv->objects);
-- 
2.10.2

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

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Track pages pinned due to swizzling quirk

[Chris Wilson]

On Tue, Nov 01, 2016 at 08:39:14AM +, Tvrtko Ursulin wrote:
> 
> On 31/10/2016 10:26, Chris Wilson wrote:
> >If we have a tiled object and an unknown CPU swizzle pattern, we pin the
> >pages to prevent the object from being swapped out (and us corrupting
> >the contents as we do not know the access pattern and so cannot convert
> >it to linear and back to tiled on reuse). This requires us to remember
> >to drop the extra pinning when freeing the object, or else we trigger
> >warnings about the pin leak. In commit fbbd37b36fa5 ("drm/i915: Move
> >object release to a freelist + worker"), the object free path was
> >deferred to a work, but the unpinning of the quirk, along with marking
> >the object as reclaimable, was left on the immediate path (so that if
> >required we could reclaim the pages under memory pressure as early as
> >possible). However, this split introduced a bug where the pages we no
> >longer being unpinned if they were marked as unneeded.
> 
> Last sentence is broken.

Almost the right words in the wrong order.

> > if (obj->mm.madv != __I915_MADV_PURGED)
> >@@ -4335,14 +4342,12 @@ void i915_gem_free_object(struct drm_gem_object 
> >*gem_obj)
> > {
> > struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
> >
> >+if (obj->mm.quirked)
> >+__i915_gem_object_unpin_pages(obj);
> >+
> > if (discard_backing_storage(obj))
> > obj->mm.madv = I915_MADV_DONTNEED;
> >
> >-if (obj->mm.pages && obj->mm.madv == I915_MADV_WILLNEED &&
> >-to_i915(obj->base.dev)->quirks & QUIRK_PIN_SWIZZLED_PAGES &&
> >-i915_gem_object_is_tiled(obj))
> >-__i915_gem_object_unpin_pages(obj);
> >-
> 
> This reordering would not have been enough to fix this?

Yes. I was trying to avoid the repeated if() conditions and thought a
flag would eliminate a few of them. It only managed to kill this one and
provide assertions elsewhere.

Still we reduce the 3 [of 4] tests done to one for all devices but some
odd gen3/gen4 (and gain a sanity check for uncommon code paths).
-Chris

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Avoid accessing request->timeline outside of its lifetime

[Tvrtko Ursulin]

On 31/10/2016 21:03, Chris Wilson wrote:

On Mon, Oct 31, 2016 at 05:35:50PM +, Tvrtko Ursulin wrote:


On 31/10/2016 10:26, Chris Wilson wrote:

Whilst waiting on a request, we may do so without holding any locks or
any guards beyond a reference to the request. In order to avoid taking
locks within request deallocation, we drop references to its timeline
(via the context and ppgtt) upon retirement. We should avoid chasing


Couldn't find that there is a reference taken (or dropped) on the
timeline when stored in a request. It looks like a borrowed pointer
to me?


The timeline is owned by the address space which is owned by either the
context or the device. The request holds a reference on the context (and
so indirectly onto the timeline, except for the device's which outlives
the request) up until we retire the request. (Retiring holds
struct_mutex so is earlier than freeing.)


+static inline u32 intel_engine_last_submit(struct intel_engine_cs *engine)
+{
+   return READ_ONCE(engine->timeline->last_submitted_seqno);
+}
+


Don't like that READ_ONCE gets sprinkled all over the place via call
sites. It should be extremely well defined and controlled from where
it is used. Otherwise it suggests READ_ONCE is not really
appropriate.


It actually is appropriate. last_submitted_seqno is under the timeline
spinlock, none of the callers take the appropriate guard. This is
trying to document that these callers don't call about fully
synchronising the last_submitted_seqno with the request list or last
request pointer. And we don't care to go full seqlock, since we really
are only peeking.


Ah my bad, I thought it was actually req->timeline->last_submitted_seqno.

In this case, assuming the seqno namespaces are correct:

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

[Tvrtko Ursulin]

On 31/10/2016 10:26, Chris Wilson wrote:

With full-ppgtt one of the main bottlenecks is the lookup of the VMA
underneath the object. For execbuf there is merit in having a very fast
direct lookup of ctx:handle to the vma using a hashtree, but that still
leaves a large number of other lookups. One way to speed up the lookup
would be to use a rhashtable, but that requires extra allocations and
may exhibit poor worse case behaviour. An alternative is to use an
embedded rbtree, i.e. no extra allocations and deterministic behaviour,
but at the slight cost of O(lgN) lookups (instead of O(1) for
rhashtable). The major of such tree will be very shallow and so not much
slower, and still scales much, much better than the current unsorted
list.

References: https://bugs.freedesktop.org/show_bug.cgi?id=87726
Signed-off-by: Chris Wilson 


I suggest leaving this out of the mini-series which fixes the recently 
introduced bugs.


Regards,

Tvrtko



---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 80 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  1 +
 3 files changed, 57 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a18bf66f797..e923d6596cac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2230,6 +2230,7 @@ struct drm_i915_gem_object {

/** List of VMAs backed by this object */
struct list_head vma_list;
+   struct rb_root vma_tree;

/** Stolen memory for this object, instead of being backed by shmem. */
struct drm_mm_node *stolen;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e7afad585929..aa2d21c41091 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3399,6 +3399,7 @@ void i915_vma_destroy(struct i915_vma *vma)
GEM_BUG_ON(!i915_vma_is_closed(vma));
GEM_BUG_ON(vma->fence);

+   rb_erase(>obj_node, >obj->vma_tree);
list_del(>vm_link);
if (!i915_vma_is_ggtt(vma))
i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));
@@ -3416,12 +3417,33 @@ void i915_vma_close(struct i915_vma *vma)
WARN_ON(i915_vma_unbind(vma));
 }

+static inline int vma_compare(struct i915_vma *vma,
+ struct i915_address_space *vm,
+ const struct i915_ggtt_view *view)
+{
+   GEM_BUG_ON(view && !i915_vma_is_ggtt(vma));
+
+   if (vma->vm != vm)
+   return vma->vm - vm;
+
+   if (!view)
+   return vma->ggtt_view.type;
+
+   if (vma->ggtt_view.type != view->type)
+   return vma->ggtt_view.type - view->type;
+
+   return memcmp(>ggtt_view.params,
+ >params,
+ sizeof(view->params));
+}
+
 static struct i915_vma *
 __i915_vma_create(struct drm_i915_gem_object *obj,
  struct i915_address_space *vm,
  const struct i915_ggtt_view *view)
 {
struct i915_vma *vma;
+   struct rb_node *rb, **p;
int i;

GEM_BUG_ON(vm->closed);
@@ -3455,33 +3477,28 @@ __i915_vma_create(struct drm_i915_gem_object *obj,

if (i915_is_ggtt(vm)) {
vma->flags |= I915_VMA_GGTT;
+   list_add(>obj_link, >vma_list);
} else {
i915_ppgtt_get(i915_vm_to_ppgtt(vm));
+   list_add_tail(>obj_link, >vma_list);
}

-   list_add_tail(>obj_link, >vma_list);
-   return vma;
-}
+   rb = NULL;
+   p = >vma_tree.rb_node;
+   while (*p) {
+   struct i915_vma *pos;

-static inline bool vma_matches(struct i915_vma *vma,
-  struct i915_address_space *vm,
-  const struct i915_ggtt_view *view)
-{
-   if (vma->vm != vm)
-   return false;
-
-   if (!i915_vma_is_ggtt(vma))
-   return true;
-
-   if (!view)
-   return vma->ggtt_view.type == 0;
-
-   if (vma->ggtt_view.type != view->type)
-   return false;
+   rb = *p;
+   pos = rb_entry(rb, struct i915_vma, obj_node);
+   if (vma_compare(pos, vm, view) < 0)
+   p = >rb_right;
+   else
+   p = >rb_left;
+   }
+   rb_link_node(>obj_node, rb, p);
+   rb_insert_color(>obj_node, >vma_tree);

-   return memcmp(>ggtt_view.params,
- >params,
- sizeof(view->params)) == 0;
+   return vma;
 }

 struct i915_vma *
@@ -3501,11 +3518,22 @@ i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
const struct i915_ggtt_view *view)
 {
-   struct i915_vma *vma;
+   struct rb_node *rb;
+
+   rb = obj->vma_tree.rb_node;
+   while (rb) {
+