Re: [Intel-gfx] [PATCH v7 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Chris Wilson]

Quoting Jackie Li (2018-01-19 01:29:31)
> GuC WOPCM registers are write-once registers. Current driver code
> accesses these registers without checking the accessibility to these
> registers, this will lead unpredictable driver behaviors if these
> registers were touch by other components (such as faulty BIOS code).
> 
> This patch moves the GuC WOPCM register updating operations into
> intel_guc_wopcm.c and adds checks before and after the write to GuC
> WOPCM registers to make sure the driver is in a known state before
> and after writing to these write-once registers.
> 
> v6:
>  - Made sure module reloading won't bug the kernel while doing
>locking status checking
> 
> v7:
>  - Fixed patch format issues
> 
> Cc: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Signed-off-by: Jackie Li 
> ---
> +static inline bool __reg_locked(struct drm_i915_private *dev_priv,
> +   i915_reg_t reg)
> +{
> +   return !!(I915_READ(reg) & GUC_WOPCM_REG_LOCKED);

Why the double cast to bool?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Chris Wilson]

Quoting Jackie Li (2018-01-19 01:29:28)
> GuC related exported functions should start with "intel_guc_"
> prefix and pass intel_guc as the first parameter since its guc
> related. Current guc_ggtt_offset() failed to follow this code
> convention.

But it was not, and still does not operate on the guc. Is that changing?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

[Chris Wilson]

Quoting Jackie Li (2018-01-19 01:29:27)
> intel_guc_reg.h should only include definition for GuC registers
> and related register bits. GuC WOPCM related values should not
> be defined in intel_guc_reg.h

GuC registers does not include GuC WOPCM? The code does seem to suggest
they are related ;)
 
> This patch creates a better file structure by moving GuC WOPCM
> related definitions int to a new header intel_guc_wopcm.h
> and moving GuC WOPCM related functions to a new source file
> intel_guc_wopcm.c

Just needs one more sentence to sell this, perhaps "as future patches
will increase the complexity of determining the WOPCM layout".

One function per file is just crying out for LTO ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Sagar Arun Kamble]

On 1/19/2018 6:59 AM, Jackie Li wrote:

GuC related exported functions should start with "intel_guc_"
prefix and pass intel_guc as the first parameter since its guc
related. Current guc_ggtt_offset() failed to follow this code
convention.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset
and updates the related code to pass intel_guc pointer to
this function call. so that we have a unified coding style for
GuC code.

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
  drivers/gpu/drm/i915/intel_guc.c| 12 +++-
  drivers/gpu/drm/i915/intel_guc.h| 10 --
  drivers/gpu/drm/i915/intel_guc_ads.c| 25 +
  drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
  drivers/gpu/drm/i915/intel_guc_fw.c |  2 +-
  drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
  drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
  drivers/gpu/drm/i915/intel_huc.c|  6 --
  8 files changed, 42 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index b8b6d4a..e70885b 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -264,8 +264,10 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	/* If GuC submission is enabled, set up additional parameters here */

if (USES_GUC_SUBMISSION(dev_priv)) {
-   u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-   u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+   u32 ads = intel_guc_ggtt_offset(guc,
+   guc->ads_vma) >> PAGE_SHIFT;
+   u32 pgs = intel_guc_ggtt_offset(guc,
+   dev_priv->guc.stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
  
  		params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;

@@ -413,7 +415,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
  
  	return intel_guc_send(guc, data, ARRAY_SIZE(data));

  }
@@ -436,7 +438,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   data[6] = guc_ggtt_offset(guc->shared_data);
+   data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
  
  	return intel_guc_send(guc, data, ARRAY_SIZE(data));

  }
@@ -458,7 +460,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
  
  	data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;

data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
  
  	return intel_guc_send(guc, data, ARRAY_SIZE(data));

  }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9e0a97e..b7e2a18 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -101,13 +101,19 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
  }
  
-/*

Should add "/**" instead of removing "/*"

+/* intel_guc_ggtt_offset() - Get the GGTT offset of @vma.
I feel this function is more validating the offset so "Validate and get 
the ggtt offset of @vma" ?

+ * @guc: intel guc.
+ * @vma: i915 graphics virtual memory area.
+ *
   * GuC does not allow any gfx GGTT address that falls into range [0, 
WOPCM_TOP),
   * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address 
is
   * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
   * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets the GuC gfx address requirement.
   */
-static inline u32 guc_ggtt_offset(struct i915_vma *vma)
+static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc,
+   struct i915_vma *vma)
  {
u32 offset = i915_ggtt_offset(vma);
  
This function uses GUC_GGTT_TOP that is defined in guc_reg.h and I think 
we can move it to guc.h similar

to other WOPCM related moves in earlier patch.

diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c 
b/drivers/gpu/drm/i915/intel_guc_ads.c
index ac62753..7215594 100644
--- a/drivers/gpu/drm/i915/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/intel_guc_ads.c
@@ -113,17 +113,6 @@ int intel_guc_ads_create(struct intel_guc *guc)
blob->reg_state.white_list[engine->guc_id].count = 0;
}
  
-	/*

-* The GuC requires a "Golden Context" when it 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/ppgtt: Pin page directories before allocation

[Chris Wilson]

Quoting Matthew Auld (2018-01-31 22:48:14)
> On 31 January 2018 at 21:44, Chris Wilson  wrote:
> > Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
> > believed that because it did not insert its freshly allocated page
> > directory into the pd tree, it was safe from the shrinker. I failed to
> > heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap
> > tracking for used-ptes") that we need to pin all the levels in the tree
> > before hitting the shrinker or else the shrinker may free an upper layer
> > as we proceed to allocate the tree. Thus leaving dangling pointers
> > everywhere and a GPF should we hit direct reclaim at just the wrong
> > moment.
> >
> > Jan 24 10:32:48 eric-macbookpro kernel: CPU: 0 PID: 7374 Comm: chromium 
> > Tainted: P   O4.14.13-1-ARCH #1
> > Jan 24 10:32:48 eric-macbookpro kernel: Hardware name: Apple Inc. 
> > MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 
> > 06/18/2017
> > Jan 24 10:32:48 eric-macbookpro kernel: task: 994f696c2c40 task.stack: 
> > b1a789d4c000
> > Jan 24 10:32:48 eric-macbookpro kernel: RIP: 
> > 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel: RSP: 0018:b1a789d4f940 EFLAGS: 
> > 00010206
> > Jan 24 10:32:48 eric-macbookpro kernel: RAX: 81c1788cc4f68138 RBX: 
> > 994f54db8000 RCX: 994f696c2c40
> > Jan 24 10:32:48 eric-macbookpro kernel: RDX: 00023bc73003 RSI: 
> > 994d598b6b80 RDI: 994f54db8000
> > Jan 24 10:32:48 eric-macbookpro kernel: RBP: 994d598b6b80 R08: 
> >  R09: 
> > Jan 24 10:32:48 eric-macbookpro kernel: R10: b1a789d4f550 R11: 
> > 994eaf3c3208 R12: 0027
> > Jan 24 10:32:48 eric-macbookpro kernel: R13: 5000 R14: 
> > 04e8f000 R15: 994f54dba000
> > Jan 24 10:32:48 eric-macbookpro kernel: FS:  7f585886aa00() 
> > GS:994faec0() knlGS:
> > Jan 24 10:32:48 eric-macbookpro kernel: CS:  0010 DS:  ES:  CR0: 
> > 80050033
> > Jan 24 10:32:48 eric-macbookpro kernel: CR2: 004ac8e8 CR3: 
> > 0002552c8004 CR4: 003606f0
> > Jan 24 10:32:48 eric-macbookpro kernel: Call Trace:
> > Jan 24 10:32:48 eric-macbookpro kernel:  gen8_ppgtt_alloc_pdp+0x178/0x320 
> > [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  gen8_ppgtt_alloc_4lvl+0x5f/0x150 
> > [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  ppgtt_bind_vma+0x30/0x70 [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  i915_vma_bind+0x68/0xd0 [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  __i915_vma_do_pin+0x2d6/0x3a0 
> > [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  eb_lookup_vmas+0x7a2/0xb50 [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  
> > i915_gem_do_execbuffer+0x4d7/0x10e0 [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? sock_wfree+0x34/0x60
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? 
> > unix_stream_read_generic+0x1f9/0x7e0
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? import_iovec+0x37/0xd0
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer2+0x5d/0x390 
> > [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  i915_gem_execbuffer2+0x1b7/0x390 
> > [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer+0x2d0/0x2d0 
> > [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  drm_ioctl_kernel+0x59/0xb0 [drm]
> > Jan 24 10:32:48 eric-macbookpro kernel:  drm_ioctl+0x2d5/0x370 [drm]
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer+0x2d0/0x2d0 
> > [i915]
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? __seccomp_filter+0x3b/0x260
> > Jan 24 10:32:48 eric-macbookpro kernel:  do_vfs_ioctl+0xa1/0x610
> > Jan 24 10:32:48 eric-macbookpro kernel:  ? syscall_trace_enter+0xdb/0x2b0
> > Jan 24 10:32:48 eric-macbookpro kernel:  SyS_ioctl+0x74/0x80
> > Jan 24 10:32:48 eric-macbookpro kernel:  do_syscall_64+0x55/0x110
> > Jan 24 10:32:48 eric-macbookpro kernel:  entry_SYSCALL64_slow_path+0x25/0x25
> > Jan 24 10:32:48 eric-macbookpro kernel: RIP: 0033:0x7f584fa82d27
> > Jan 24 10:32:48 eric-macbookpro kernel: RSP: 002b:7ffee14a7828 EFLAGS: 
> > 0246 ORIG_RAX: 0010
> > Jan 24 10:32:48 eric-macbookpro kernel: RAX: ffda RBX: 
> > 03b0126a1030 RCX: 7f584fa82d27
> > Jan 24 10:32:48 eric-macbookpro kernel: RDX: 7ffee14a7870 RSI: 
> > 40406469 RDI: 0080
> > Jan 24 10:32:48 eric-macbookpro kernel: RBP: 7ffee14a7870 R08: 
> > 0002 R09: 0077
> > Jan 24 10:32:48 eric-macbookpro kernel: R10: 7f5839f2b780 R11: 
> > 0246 R12: 40406469
> > Jan 24 10:32:48 eric-macbookpro kernel: R13: 0080 R14: 
> > 7f5842b00040 R15: 
> > Jan 24 10:32:48 eric-macbookpro kernel: Code: 01 00 83 81 58 0a 00 00 01 48 
> > 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 
> > 0c 9d fd 

Re: [Intel-gfx] [PATCH 9/9] drm/i915/dp: Use the same aux retry interval as the core.

[Rodrigo Vivi]

On Sat, Jan 27, 2018 at 02:49:23AM +, Dhinakaran Pandiyan wrote:
> Keeps the wait times consistent.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 

in case the other one goes through:

Reviewed-by: Rodrigo Vivi 

;)

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 06619998b5a3..3c64b2e92575 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1145,9 +1145,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>   continue;
>  
>   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> - usleep_range(400, 500);
> + usleep_range(DP_AUX_RETRY_INTERVAL,
> +  DP_AUX_RETRY_INTERVAL + 100);
>   continue;
>   }
> +
>   if (status & DP_AUX_CH_CTL_DONE)
>   goto done;
>   }
> -- 
> 2.14.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

[Sagar Arun Kamble]

Patch looks good to me. Minor updates suggested below with r-b.


On 1/19/2018 6:59 AM, Jackie Li wrote:

intel_guc_reg.h should only include definition for GuC registers
and related register bits. GuC WOPCM related values should not
be defined in intel_guc_reg.h

This patch creates a better file structure by moving GuC WOPCM
related definitions int to a new header intel_guc_wopcm.h

typo "into"

and moving GuC WOPCM related functions to a new source file
intel_guc_wopcm.c

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/Makefile  |  1 +
  drivers/gpu/drm/i915/intel_guc.c   | 11 
  drivers/gpu/drm/i915/intel_guc.h   |  2 +-
  drivers/gpu/drm/i915/intel_guc_reg.h   |  4 ---
  drivers/gpu/drm/i915/intel_guc_wopcm.c | 47 ++
  drivers/gpu/drm/i915/intel_guc_wopcm.h | 39 
  drivers/gpu/drm/i915/intel_uc.c|  2 +-
  drivers/gpu/drm/i915/intel_uc_fw.c |  2 +-
  8 files changed, 90 insertions(+), 18 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c
  create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a..1dc9988 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,6 +88,7 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
+ intel_guc_wopcm.o \
  intel_huc.o
  
  # autogenerated null render state

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index ea30e7c..b8b6d4a 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -504,14 +504,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
i915_gem_object_put(obj);
return vma;
  }
-
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
-   u32 wopcm_size = GUC_WOPCM_TOP;
-
-   /* On BXT, the top of WOPCM is reserved for RC6 context */
-   if (IS_GEN9_LP(dev_priv))
-   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
-   return wopcm_size;
-}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..9e0a97e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -31,6 +31,7 @@
  #include "intel_guc_ct.h"
  #include "intel_guc_log.h"
  #include "intel_guc_reg.h"
+#include "intel_guc_wopcm.h"
  #include "intel_uc_fw.h"
  #include "i915_vma.h"
  
@@ -130,6 +131,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);

  int intel_guc_suspend(struct drm_i915_private *dev_priv);
  int intel_guc_resume(struct drm_i915_private *dev_priv);
  struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
  
  #endif

diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 19a9247..1f52fb8 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -68,7 +68,6 @@
  #define DMA_GUC_WOPCM_OFFSET  _MMIO(0xc340)
  #define   HUC_LOADING_AGENT_VCR (0<<1)
  #define   HUC_LOADING_AGENT_GUC (1<<1)
-#define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
  #define GUC_MAX_IDLE_COUNT_MMIO(0xC3E4)
  
  #define HUC_STATUS2 _MMIO(0xD3B0)

@@ -76,9 +75,6 @@
  
  /* Defines WOPCM space available to GuC firmware */

  #define GUC_WOPCM_SIZE_MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP  (0x80 << 12)/* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)/* 64KB  */
  
  /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */

  #define GUC_GGTT_TOP  0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
new file mode 100644
index 000..87643a0
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this 

Re: [Intel-gfx] [PATCH 8/9] drm/dp: Export AUX_RETRY_INTERVAL

[Rodrigo Vivi]

On Sat, Jan 27, 2018 at 02:49:22AM +, Dhinakaran Pandiyan wrote:
> Drivers can use this in their retry loops too.

with all this layers of retries it is good that we find some consistency 
somewhere

is this written down on any part of eDP spec?
Last time I saw there was different retries values on different cases.
So I'm afraid this here would confuse instead of helping.

> 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 12 +---
>  include/drm/drm_dp_helper.h |  2 ++
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index ffe14ec3e7f2..0a7c8d6e7d8c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -169,8 +169,6 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
>  }
>  EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>  
> -#define AUX_RETRY_INTERVAL 500 /* us */
> -
>  /**
>   * DOC: dp helpers
>   *
> @@ -206,8 +204,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>*/
>   for (retry = 0; retry < 32; retry++) {
>   if (ret != 0 && ret != -ETIMEDOUT) {
> - usleep_range(AUX_RETRY_INTERVAL,
> -  AUX_RETRY_INTERVAL + 100);
> + usleep_range(DP_AUX_RETRY_INTERVAL,
> +  DP_AUX_RETRY_INTERVAL + 100);
>   }
>  
>   ret = aux->transfer(aux, );
> @@ -718,7 +716,7 @@ static int drm_dp_i2c_retry_count(const struct 
> drm_dp_aux_msg *msg,
>   drm_dp_aux_reply_duration(msg);
>   int i2c_time_us = drm_dp_i2c_msg_duration(msg, i2c_speed_khz);
>  
> - return DIV_ROUND_UP(i2c_time_us, aux_time_us + AUX_RETRY_INTERVAL);
> + return DIV_ROUND_UP(i2c_time_us, aux_time_us + DP_AUX_RETRY_INTERVAL);
>  }
>  
>  /*
> @@ -795,7 +793,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>* For now just defer for long enough to hopefully be
>* safe for all use-cases.
>*/
> - usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 
> 100);
> + usleep_range(DP_AUX_RETRY_INTERVAL, 
> DP_AUX_RETRY_INTERVAL + 100);
>   continue;
>  
>   default:
> @@ -827,7 +825,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   aux->i2c_defer_count++;
>   if (defer_i2c < 7)
>   defer_i2c++;
> - usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 
> 100);
> + usleep_range(DP_AUX_RETRY_INTERVAL, 
> DP_AUX_RETRY_INTERVAL + 100);
>   drm_dp_i2c_msg_write_status_update(msg);
>  
>   continue;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c239e6e24a10..2eae1aed2d26 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -61,6 +61,8 @@
>  #define DP_AUX_I2C_REPLY_DEFER   (0x2 << 2)
>  #define DP_AUX_I2C_REPLY_MASK(0x3 << 2)
>  
> +#define DP_AUX_RETRY_INTERVAL500 /* us */
> +
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915/psr: Extract PSR DPCD initialization and move it to intel_psr.c

[Rodrigo Vivi]

On Wed, Jan 31, 2018 at 10:38:24AM +, David Weinehall wrote:
> On Fri, Jan 26, 2018 at 06:49:17PM -0800, Dhinakaran Pandiyan wrote:
> > intel_edp_init_dpcd() is cluttered with PSR specific DPCD checks and
> > intel_dp.c is huge.
> 
> Yes please!  Good idea.
> 
> > No functional change intended.
> 
> Reviewed-by: David Weinehall 

Acked-by: Rodrigo Vivi 

> 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 64 +
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  drivers/gpu/drm/i915/intel_psr.c | 68 
> > 
> >  3 files changed, 70 insertions(+), 63 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index a2e88715..2454326690fb 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3135,35 +3135,6 @@ intel_dp_get_link_status(struct intel_dp *intel_dp, 
> > uint8_t link_status[DP_LINK_
> > DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> >  }
> >  
> > -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> > -{
> > -   uint8_t psr_caps = 0;
> > -
> > -   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
> > -   return false;
> > -   return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
> > -}
> > -
> > -static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
> > -{
> > -   uint8_t dprx = 0;
> > -
> > -   if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
> > - ) != 1)
> > -   return false;
> > -   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
> > -}
> > -
> > -static bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
> > -{
> > -   uint8_t alpm_caps = 0;
> > -
> > -   if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
> > - _caps) != 1)
> > -   return false;
> > -   return alpm_caps & DP_ALPM_CAP;
> > -}
> > -
> >  /* These are source-specific values. */
> >  uint8_t
> >  intel_dp_voltage_max(struct intel_dp *intel_dp)
> > @@ -3714,40 +3685,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
> > DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
> >  
> > -   /* Check if the panel supports PSR */
> > -   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
> > -intel_dp->psr_dpcd,
> > -sizeof(intel_dp->psr_dpcd));
> > -   if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > -   dev_priv->psr.sink_support = true;
> > -   DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > -   }
> > -
> > -   if (INTEL_GEN(dev_priv) >= 9 &&
> > -   (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > -   uint8_t frame_sync_cap;
> > -
> > -   dev_priv->psr.sink_support = true;
> > -   if (drm_dp_dpcd_readb(_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > - _sync_cap) != 1)
> > -   frame_sync_cap = 0;
> > -   dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
> > -   /* PSR2 needs frame sync as well */
> > -   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> > -   DRM_DEBUG_KMS("PSR2 %s on sink",
> > - dev_priv->psr.psr2_support ? "supported" : "not 
> > supported");
> > -
> > -   if (dev_priv->psr.psr2_support) {
> > -   dev_priv->psr.y_cord_support =
> > -   intel_dp_get_y_cord_status(intel_dp);
> > -   dev_priv->psr.colorimetry_support =
> > -   intel_dp_get_colorimetry_status(intel_dp);
> > -   dev_priv->psr.alpm =
> > -   intel_dp_get_alpm_status(intel_dp);
> > -   }
> > -
> > -   }
> > +   intel_psr_init_dpcd(intel_dp);
> >  
> > /*
> >  * Read the eDP display control registers.
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 3cee54bc0352..a340bc04dad8 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1851,6 +1851,7 @@ bool is_hdcp_supported(struct drm_i915_private 
> > *dev_priv, enum port port);
> >  
> >  /* intel_psr.c */
> >  #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
> > +void intel_psr_init_dpcd(struct intel_dp *intel_dp);
> >  void intel_psr_enable(struct intel_dp *intel_dp,
> >   const struct intel_crtc_state *crtc_state);
> >  void intel_psr_disable(struct intel_dp *intel_dp,
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 

Re: [Intel-gfx] [PATCH 1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.

[Rodrigo Vivi]

On Sat, Jan 27, 2018 at 02:49:15AM +, Dhinakaran Pandiyan wrote:
> There is no corresponding invalidate call before the buffer is written
> to, this results in screen freezing sometime after switching to console
> mode with PSR enabled. Invalidating the front buffer in the fbdev call
> backs won't work either as some of them are called in atomic contexts and
> {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index e9feffdea899..c12af1118647 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   if (!CAN_PSR(dev_priv))
>   return;
>  
> + if (origin == ORIGIN_DIRTYFB)
> + return;
> +

I'd like Paulo to take a look here.

What I'm confused now is who (what fbt bit) is actually blocking PSR to work
on fbdev.

And what would be the risks of other corner cases or the risk of this
not getting psr re-enabled until next reboot...

>   mutex_lock(_priv->psr.lock);
>   if (!dev_priv->psr.enabled) {
>   mutex_unlock(_priv->psr.lock);
> -- 
> 2.14.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/9] drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.

[Rodrigo Vivi]

On Sat, Jan 27, 2018 at 02:49:18AM +, Dhinakaran Pandiyan wrote:
> The cap check should be specifically for bit 0 instead of any bit.
> 

Any "Fixes:" ?

> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 


Reviewed-by: Rodrigo Vivi 


> ---
>  drivers/gpu/drm/i915/intel_psr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index a1b878449e83..83874bcd1142 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -107,7 +107,7 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> _sync_cap) != 1)
>   frame_sync_cap = 0;
> - dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
> + dev_priv->psr.aux_frame_sync = frame_sync_cap & 
> DP_AUX_FRAME_SYNC_CAP;
>   /* PSR2 needs frame sync as well */
>   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
>   DRM_DEBUG_KMS("PSR2 %s on sink",
> -- 
> 2.14.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/9] drm/i915/frontbuffer: Mark frontbuffer flush and invalidate with might_sleep()

[Rodrigo Vivi]

On Sat, Jan 27, 2018 at 02:49:16AM +, Dhinakaran Pandiyan wrote:
> Frontbuffer flush and invalidate call psr, fbc and drrs functions that use
> mutexes but they can be called in atomic contexts in the fbdev path. The
> point where the spinlocks are acquired is up in the call stack that is not
> entirely easy to spot, so annotate with might_sleep().
>

makes sense

> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_frontbuffer.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
> b/drivers/gpu/drm/i915/intel_frontbuffer.c
> index fcfc217e754e..3a8d3d06c26a 100644
> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> @@ -79,6 +79,7 @@ void __intel_fb_obj_invalidate(struct drm_i915_gem_object 
> *obj,
>   spin_unlock(_priv->fb_tracking.lock);
>   }
>  
> + might_sleep();
>   intel_psr_invalidate(dev_priv, frontbuffer_bits);
>   intel_edp_drrs_invalidate(dev_priv, frontbuffer_bits);
>   intel_fbc_invalidate(dev_priv, frontbuffer_bits, origin);
> @@ -108,6 +109,7 @@ static void intel_frontbuffer_flush(struct 
> drm_i915_private *dev_priv,
>   if (!frontbuffer_bits)
>   return;
>  
> + might_sleep();
>   intel_edp_drrs_flush(dev_priv, frontbuffer_bits);
>   intel_psr_flush(dev_priv, frontbuffer_bits, origin);
>   intel_fbc_flush(dev_priv, frontbuffer_bits, origin);
> -- 
> 2.14.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Respect VBT max dp rate.

[Pandiyan, Dhinakaran]

On Wed, 2018-01-31 at 21:22 -0800, Rodrigo Vivi wrote:
> On Thu, Feb 01, 2018 at 02:53:20AM +, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Wed, 2018-01-31 at 13:20 -0800, Rodrigo Vivi wrote:
> > > Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link
> > > rate to VBT child device struct")' we have the new entry
> > > defined for max dp rate that is in use for CNL.
> > > 
> > > Let's start using it for all VBT 216+ and
> > > also organize the cnl adjusted rates in terms of rate
> > > and not array size.
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > >  drivers/gpu/drm/i915/intel_bios.c |  3 +++
> > >  drivers/gpu/drm/i915/intel_dp.c   | 37 
> > > +
> > >  3 files changed, 33 insertions(+), 8 deletions(-)
> > 
> > 
> > 
> > > +static int intel_dp_adjusted_max_rate(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > > + const struct ddi_vbt_port_info *info =
> > > + _priv->vbt.ddi_port_info[dig_port->base.port];
> > > +
> > > + if (info->dp_max_link_rate)
> > > + return info->dp_max_link_rate;
> > 
> > What if this value is higher than cnl_adjusted_max_rate() ?
> 
> Then VBT knows something about that SKU that we don't?! *shrug*
> 

I have very little idea of how reliable VBT's are on SDP's or if they
are always updated with the correct values. Having those fall back
checks based on SKU and ports, which we know are definite HW limits, I
feel is safer. However, I'll leave this to you as my knowledge is fairly
limited.

> My understanding is that the purpose of that new VBT field is
>  to workaround bugs they know for certain combination and limit
>  the max rate even more.
> 
> bugs like the one I had in a part here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=103963
> 
> in this case flicker was gone by limiting the max rate.
> 
> But yeap, maybe vbt is bugged, so are you suggesting min(vbt, bspec) ?

Yes.

> 
> > 
> > -DK
> > 
> > 
> > > +
> > > + if (IS_CANNONLAKE(dev_priv))
> > > + return cnl_adjusted_max_rate(intel_dp);
> > > +
> > > + return INT_MAX; /* No adjusted limit */
> > >  }
> > >  
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] CI igt-all on drm-intel-next-fixes gem_exec_* and other gem_*

[Rodrigo Vivi]

Hi guys,

As we run more rounds of CI on drm-intel-next-fixes
a standard gets visible there.

This round of dinf started with CI_DINF_90.

Specially gem_exec_* but also other gem_* tests fails randomly
on gen9 platforms:

https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/shards.html
(last 5 columns of gen9 platforms)

while it is pure clean green on drm-tip:

https://intel-gfx-ci.01.org/tree/drm-tip/shards-all.html

From the logs I looked it seems that it is always during hibernation
and most of the times some strange page faults and also not
only i915:

<6>[   36.647941] PM: Image saving progress:  70%
<3>[   36.707234] e1000e :00:1f.6 eno1: Detected Hardware Unit Hang:

Do you know what could justify this difference?

Is there anything we could we be missing on our side?

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Respect VBT max dp rate.

[Pandiyan, Dhinakaran]

On Wed, 2018-01-31 at 13:20 -0800, Rodrigo Vivi wrote:
> Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link
> rate to VBT child device struct")' we have the new entry
> defined for max dp rate that is in use for CNL.
> 
> Let's start using it for all VBT 216+ and
> also organize the cnl adjusted rates in terms of rate
> and not array size.
> 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c |  3 +++
>  drivers/gpu/drm/i915/intel_dp.c   | 37 +
>  3 files changed, 33 insertions(+), 8 deletions(-)



> +static int intel_dp_adjusted_max_rate(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[dig_port->base.port];
> +
> + if (info->dp_max_link_rate)
> + return info->dp_max_link_rate;

What if this value is higher than cnl_adjusted_max_rate() ?

-DK


> +
> + if (IS_CANNONLAKE(dev_priv))
> + return cnl_adjusted_max_rate(intel_dp);
> +
> + return INT_MAX; /* No adjusted limit */
>  }
>  

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

[Intel-gfx] [PATCH v10] drm/i915/icl: Gen11 forcewake support

[Michel Thierry]

From: Daniele Ceraolo Spurio 

The main difference with previous GENs is that starting from Gen11
each VCS and VECS engine has its own power well, which only exist
if the related engine exists in the HW.
The fallback forcewake request workaround is only needed on gen9
according to the HSDES WA entry (1604254524), so we can go back to using
the simpler fw_domains_get/put functions.

BSpec: 18331

v2: fix fwtable, use array to test shadow tables, create new
accessors to avoid check on every access (Tvrtko)
v3 (from Paulo): Rebase.
v4:
  - Range 09400-097FF should be FORCEWAKE_ALL (Daniele)
  - Use the BIT macro for forcewake domains (Daniele)
  - Add a comment about the range ordering (Oscar)
  - Updated commit message (Oscar)
v5: Rebased
v6: Use I915_MAX_VCS/VECS (Michal)
v7: translate FORCEWAKE_ALL to available domains
v8: rebase, add clarification on fallback ack in commit message.
v9: fix rebase issue, change check in fw_domains_init from IS_GEN11
to GEN >= 11
v10: Generate is_genX_shadowed with a macro (Daniele)
 Include gen11_fw_ranges in the selftest (Michel)

Cc: Michal Wajdeczko 
Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Acked-by: Michel Thierry 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Michel Thierry 
---

 drivers/gpu/drm/i915/i915_reg.h   |   4 +
 drivers/gpu/drm/i915/intel_uncore.c   | 155 --
 drivers/gpu/drm/i915/intel_uncore.h   |  27 -
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  31 --
 4 files changed, 193 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d29e8a0e2ca3..eaca12292ffe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8015,9 +8015,13 @@ enum {
 #define   VLV_GTLC_PW_RENDER_STATUS_MASK   (1 << 7)
 #define  FORCEWAKE_MT  _MMIO(0xa188) /* multi-threaded 
*/
 #define  FORCEWAKE_MEDIA_GEN9  _MMIO(0xa270)
+#define  FORCEWAKE_MEDIA_VDBOX_GEN11(n)_MMIO(0xa540 + (n) * 4)
+#define  FORCEWAKE_MEDIA_VEBOX_GEN11(n)_MMIO(0xa560 + (n) * 4)
 #define  FORCEWAKE_RENDER_GEN9 _MMIO(0xa278)
 #define  FORCEWAKE_BLITTER_GEN9_MMIO(0xa188)
 #define  FORCEWAKE_ACK_MEDIA_GEN9  _MMIO(0x0D88)
+#define  FORCEWAKE_ACK_MEDIA_VDBOX_GEN11(n)_MMIO(0x0D50 + (n) * 4)
+#define  FORCEWAKE_ACK_MEDIA_VEBOX_GEN11(n)_MMIO(0x0D70 + (n) * 4)
 #define  FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0x0D84)
 #define  FORCEWAKE_ACK_BLITTER_GEN9_MMIO(0x130044)
 #define   FORCEWAKE_KERNEL BIT(0)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 164dbb8cfa36..c1953043604b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -37,6 +37,12 @@ static const char * const forcewake_domain_names[] = {
"render",
"blitter",
"media",
+   "vdbox0",
+   "vdbox1",
+   "vdbox2",
+   "vdbox3",
+   "vebox0",
+   "vebox1",
 };
 
 const char *
@@ -773,6 +779,8 @@ void assert_forcewakes_active(struct drm_i915_private 
*dev_priv,
 
 /* We give fast paths for the really cool registers */
 #define NEEDS_FORCE_WAKE(reg) ((reg) < 0x4)
+#define GEN11_NEEDS_FORCE_WAKE(reg) \
+   ((reg) < 0x4 || ((reg) >= 0x1c && (reg) < 0x1dc000))
 
 #define __gen6_reg_read_fw_domains(offset) \
 ({ \
@@ -826,6 +834,14 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32 
offset)
if (!entry)
return 0;
 
+   /*
+* The list of FW domains depends on the SKU in gen11+ so we
+* can't determine it statically. We use FORCEWAKE_ALL and
+* translate it here to the list of available domains.
+*/
+   if (entry->domains == FORCEWAKE_ALL)
+   return dev_priv->uncore.fw_domains;
+
WARN(entry->domains & ~dev_priv->uncore.fw_domains,
 "Uninitialized forcewake domain(s) 0x%x accessed at 0x%x\n",
 entry->domains & ~dev_priv->uncore.fw_domains, offset);
@@ -860,6 +876,14 @@ static const struct intel_forcewake_range 
__vlv_fw_ranges[] = {
__fwd; \
 })
 
+#define __gen11_fwtable_reg_read_fw_domains(offset) \
+({ \
+   enum forcewake_domains __fwd = 0; \
+   if (GEN11_NEEDS_FORCE_WAKE((offset))) \
+   __fwd = find_fw_domain(dev_priv, offset); \
+   __fwd; \
+})
+
 /* *Must* be sorted by offset! See intel_shadow_table_check(). */
 static const i915_reg_t gen8_shadowed_regs[] = {
RING_TAIL(RENDER_RING_BASE),/* 0x2000 (base) */
@@ -871,6 +895,20 @@ static const i915_reg_t gen8_shadowed_regs[] = {

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/ppgtt: Pin page directories before allocation

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/ppgtt: Pin page directories before 
allocation
URL   : https://patchwork.freedesktop.org/series/37443/
State : success

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-pgflip-blt:
fail   -> PASS   (shard-apl) fdo#101623 +2
Subgroup fbc-rgb101010-draw-mmap-gtt:
skip   -> PASS   (shard-apl)
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#103167 +1
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_vblank:
Subgroup crtc-id:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-ts-continuation-suspend:
dmesg-warn -> PASS   (shard-apl)
Subgroup pipe-a-query-busy:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-accuracy-idle:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-wait-forked-busy:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-atomic:
skip   -> PASS   (shard-apl)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (shard-apl) fdo#102670
Test kms_cursor_crc:
Subgroup cursor-128x42-random:
skip   -> PASS   (shard-apl)
Subgroup cursor-256x256-rapid-movement:
skip   -> PASS   (shard-apl) fdo#103326
Subgroup cursor-256x256-dpms:
skip   -> PASS   (shard-apl)
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676 +1
Test kms_plane_multiple:
Subgroup atomic-pipe-b-tiling-yf:
fail   -> PASS   (shard-apl)
Subgroup legacy-pipe-a-tiling-x:
skip   -> PASS   (shard-apl)
Test kms_flip:
Subgroup basic-plain-flip:
skip   -> PASS   (shard-apl)
Test kms_draw_crc:
Subgroup draw-method-xrgb-render-untiled:
skip   -> PASS   (shard-apl)
Subgroup draw-method-xrgb2101010-render-xtiled:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-a-ctm-0-75:
skip   -> PASS   (shard-apl)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (shard-apl) fdo#103481
Subgroup read-crc-pipe-c:
skip   -> PASS   (shard-apl) fdo#103191
Subgroup read-crc-pipe-a:
skip   -> PASS   (shard-apl)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
skip   -> PASS   (shard-apl)
Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
skip   -> PASS   (shard-apl) fdo#103336
Test kms_plane_scaling:
Subgroup pipe-c-plane-scaling:
skip   -> PASS   (shard-apl)
Test kms_rotation_crc:
Subgroup primary-rotation-90-y-tiled:
skip   -> PASS   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-bottom-edge:
skip   -> PASS   (shard-apl)
Test kms_rmfb:
Subgroup rmfb-ioctl:
skip   -> PASS   (shard-apl)
Test kms_ccs:
Subgroup pipe-b-bad-pixel-format:
skip   -> PASS   (shard-apl)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103336 https://bugs.freedesktop.org/show_bug.cgi?id=103336

shard-apltotal:2838 pass:1749 dwarn:1   dfail:0   fail:24  skip:1064 
time:12591s
shard-hswtotal:2838 pass:1734 dwarn:1   dfail:0   fail:12  skip:1090 
time:11981s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6536s
Blacklisted hosts:
shard-kbltotal:2838 pass:1860 dwarn:11  dfail:0   fail:24  skip:943 
time:9703s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7845/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Respect VBT max dp rate.

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Respect VBT max dp rate.
URL   : https://patchwork.freedesktop.org/series/37441/
State : success

== Summary ==

Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-snb) fdo#103060 +1
Subgroup basic-plain-flip:
skip   -> PASS   (shard-apl)
Subgroup wf_vblank-ts-check-interruptible:
fail   -> PASS   (shard-apl) fdo#100368
Test gem_eio:
Subgroup in-flight-suspend:
pass   -> FAIL   (shard-hsw) fdo#104676 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-pgflip-blt:
fail   -> PASS   (shard-apl) fdo#101623 +2
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#103167 +1
Subgroup fbc-rgb101010-draw-mmap-gtt:
skip   -> PASS   (shard-apl)
Test kms_plane_multiple:
Subgroup atomic-pipe-b-tiling-yf:
fail   -> PASS   (shard-apl)
Subgroup legacy-pipe-a-tiling-x:
skip   -> PASS   (shard-apl)
Test perf:
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_vblank:
Subgroup pipe-c-ts-continuation-suspend:
dmesg-warn -> PASS   (shard-apl)
Subgroup pipe-a-query-busy:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-accuracy-idle:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-wait-forked-busy:
skip   -> PASS   (shard-apl)
Subgroup crtc-id:
skip   -> PASS   (shard-apl)
Test kms_draw_crc:
Subgroup draw-method-xrgb-render-untiled:
skip   -> PASS   (shard-apl)
Subgroup draw-method-xrgb2101010-render-xtiled:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-a-ctm-0-75:
skip   -> PASS   (shard-apl)
Test kms_cursor_crc:
Subgroup cursor-256x256-rapid-movement:
skip   -> PASS   (shard-apl) fdo#103326
Subgroup cursor-256x256-dpms:
skip   -> PASS   (shard-apl)
Subgroup cursor-128x42-random:
skip   -> PASS   (shard-apl)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (shard-apl) fdo#103481
Subgroup read-crc-pipe-c:
skip   -> PASS   (shard-apl) fdo#103191
Subgroup read-crc-pipe-a:
skip   -> PASS   (shard-apl)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
skip   -> PASS   (shard-apl)
Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
skip   -> PASS   (shard-apl) fdo#103336
Test kms_plane_scaling:
Subgroup pipe-c-plane-scaling:
skip   -> PASS   (shard-apl)
Test kms_rotation_crc:
Subgroup primary-rotation-90-y-tiled:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (shard-apl) fdo#102670
Subgroup cursora-vs-flipa-atomic:
skip   -> PASS   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-bottom-edge:
skip   -> PASS   (shard-apl)
Test kms_rmfb:
Subgroup rmfb-ioctl:
skip   -> PASS   (shard-apl)
Test kms_ccs:
Subgroup pipe-b-bad-pixel-format:
skip   -> PASS   (shard-apl)

fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103336 https://bugs.freedesktop.org/show_bug.cgi?id=103336
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670

shard-apltotal:2838 pass:1750 dwarn:1   dfail:0   fail:23  skip:1064 
time:12621s
shard-hswtotal:2838 pass:1733 dwarn:1   dfail:0   fail:13 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/ppgtt: Pin page directories before allocation

[Matthew Auld]

On 31 January 2018 at 21:44, Chris Wilson  wrote:
> Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
> believed that because it did not insert its freshly allocated page
> directory into the pd tree, it was safe from the shrinker. I failed to
> heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap
> tracking for used-ptes") that we need to pin all the levels in the tree
> before hitting the shrinker or else the shrinker may free an upper layer
> as we proceed to allocate the tree. Thus leaving dangling pointers
> everywhere and a GPF should we hit direct reclaim at just the wrong
> moment.
>
> Jan 24 10:32:48 eric-macbookpro kernel: CPU: 0 PID: 7374 Comm: chromium 
> Tainted: P   O4.14.13-1-ARCH #1
> Jan 24 10:32:48 eric-macbookpro kernel: Hardware name: Apple Inc. 
> MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 
> 06/18/2017
> Jan 24 10:32:48 eric-macbookpro kernel: task: 994f696c2c40 task.stack: 
> b1a789d4c000
> Jan 24 10:32:48 eric-macbookpro kernel: RIP: 
> 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915]
> Jan 24 10:32:48 eric-macbookpro kernel: RSP: 0018:b1a789d4f940 EFLAGS: 
> 00010206
> Jan 24 10:32:48 eric-macbookpro kernel: RAX: 81c1788cc4f68138 RBX: 
> 994f54db8000 RCX: 994f696c2c40
> Jan 24 10:32:48 eric-macbookpro kernel: RDX: 00023bc73003 RSI: 
> 994d598b6b80 RDI: 994f54db8000
> Jan 24 10:32:48 eric-macbookpro kernel: RBP: 994d598b6b80 R08: 
>  R09: 
> Jan 24 10:32:48 eric-macbookpro kernel: R10: b1a789d4f550 R11: 
> 994eaf3c3208 R12: 0027
> Jan 24 10:32:48 eric-macbookpro kernel: R13: 5000 R14: 
> 04e8f000 R15: 994f54dba000
> Jan 24 10:32:48 eric-macbookpro kernel: FS:  7f585886aa00() 
> GS:994faec0() knlGS:
> Jan 24 10:32:48 eric-macbookpro kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jan 24 10:32:48 eric-macbookpro kernel: CR2: 004ac8e8 CR3: 
> 0002552c8004 CR4: 003606f0
> Jan 24 10:32:48 eric-macbookpro kernel: Call Trace:
> Jan 24 10:32:48 eric-macbookpro kernel:  gen8_ppgtt_alloc_pdp+0x178/0x320 
> [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  gen8_ppgtt_alloc_4lvl+0x5f/0x150 
> [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  ppgtt_bind_vma+0x30/0x70 [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  i915_vma_bind+0x68/0xd0 [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  __i915_vma_do_pin+0x2d6/0x3a0 [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  eb_lookup_vmas+0x7a2/0xb50 [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  i915_gem_do_execbuffer+0x4d7/0x10e0 
> [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  ? sock_wfree+0x34/0x60
> Jan 24 10:32:48 eric-macbookpro kernel:  ? 
> unix_stream_read_generic+0x1f9/0x7e0
> Jan 24 10:32:48 eric-macbookpro kernel:  ? import_iovec+0x37/0xd0
> Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer2+0x5d/0x390 
> [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  i915_gem_execbuffer2+0x1b7/0x390 
> [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer+0x2d0/0x2d0 
> [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  drm_ioctl_kernel+0x59/0xb0 [drm]
> Jan 24 10:32:48 eric-macbookpro kernel:  drm_ioctl+0x2d5/0x370 [drm]
> Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer+0x2d0/0x2d0 
> [i915]
> Jan 24 10:32:48 eric-macbookpro kernel:  ? __seccomp_filter+0x3b/0x260
> Jan 24 10:32:48 eric-macbookpro kernel:  do_vfs_ioctl+0xa1/0x610
> Jan 24 10:32:48 eric-macbookpro kernel:  ? syscall_trace_enter+0xdb/0x2b0
> Jan 24 10:32:48 eric-macbookpro kernel:  SyS_ioctl+0x74/0x80
> Jan 24 10:32:48 eric-macbookpro kernel:  do_syscall_64+0x55/0x110
> Jan 24 10:32:48 eric-macbookpro kernel:  entry_SYSCALL64_slow_path+0x25/0x25
> Jan 24 10:32:48 eric-macbookpro kernel: RIP: 0033:0x7f584fa82d27
> Jan 24 10:32:48 eric-macbookpro kernel: RSP: 002b:7ffee14a7828 EFLAGS: 
> 0246 ORIG_RAX: 0010
> Jan 24 10:32:48 eric-macbookpro kernel: RAX: ffda RBX: 
> 03b0126a1030 RCX: 7f584fa82d27
> Jan 24 10:32:48 eric-macbookpro kernel: RDX: 7ffee14a7870 RSI: 
> 40406469 RDI: 0080
> Jan 24 10:32:48 eric-macbookpro kernel: RBP: 7ffee14a7870 R08: 
> 0002 R09: 0077
> Jan 24 10:32:48 eric-macbookpro kernel: R10: 7f5839f2b780 R11: 
> 0246 R12: 40406469
> Jan 24 10:32:48 eric-macbookpro kernel: R13: 0080 R14: 
> 7f5842b00040 R15: 
> Jan 24 10:32:48 eric-macbookpro kernel: Code: 01 00 83 81 58 0a 00 00 01 48 
> 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 
> 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 
> 02 f3 c3
> Jan 24 10:32:48 eric-macbookpro kernel: RIP: 
> gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: b1a789d4f940
>
> Bugzilla: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/ppgtt: Pin page directories before allocation

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/ppgtt: Pin page directories before 
allocation
URL   : https://patchwork.freedesktop.org/series/37443/
State : success

== Summary ==

Series 37443v1 series starting with [1/2] drm/i915/ppgtt: Pin page directories 
before allocation
https://patchwork.freedesktop.org/api/1.0/series/37443/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> PASS   (fi-pnv-d510) fdo#101600
Test kms_chamelium:
Subgroup common-hpd-after-suspend:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#104108

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:494s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-pnv-d510  total:288  pass:223  dwarn:0   dfail:0   fail:0   skip:65  
time:558s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:522s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC 
integration manifest
add3c702303a drm/i915/selftests: add missing gtt shrinker test
3cdd2f49d2d9 drm/i915/ppgtt: Pin page directories before allocation

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7845/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Respect VBT max dp rate.

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Respect VBT max dp rate.
URL   : https://patchwork.freedesktop.org/series/37441/
State : success

== Summary ==

Series 37441v1 drm/i915/cnl: Respect VBT max dp rate.
https://patchwork.freedesktop.org/api/1.0/series/37441/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_chamelium:
Subgroup common-hpd-after-suspend:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#104108
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:463s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:298s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:550s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:402s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:465s

ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC 
integration manifest
bd80bbf3d0d9 drm/i915/cnl: Respect VBT max dp rate.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7844/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: add missing gtt shrinker test

[Chris Wilson]

From: Matthew Auld 

Try to catch a bug we've seen in the wild where the shrinker purges the
pd/pdp from under us while allocating our paging structures.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104773
Signed-off-by: Matthew Auld 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180131191453.12676-1-matthew.a...@intel.com
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 84 +++
 1 file changed, 84 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index bb7cf998fc65..a40a2a7514fd 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -885,6 +885,84 @@ static int shrink_hole(struct drm_i915_private *i915,
return err;
 }
 
+static int shrink_boom(struct drm_i915_private *i915,
+  struct i915_address_space *vm,
+  u64 hole_start, u64 hole_end,
+  unsigned long end_time)
+{
+   unsigned int sizes[] = {SZ_2M, SZ_1G};
+   struct drm_i915_gem_object *purge;
+   struct drm_i915_gem_object *explode;
+   struct i915_vma *vma;
+   unsigned int flags = PIN_USER | PIN_OFFSET_FIXED;
+   int err;
+   int i;
+
+   /*
+* Catch the case which shrink_hole seems to miss. The setup here
+* requires invoking the shrinker as we do the alloc_pt/alloc_pd, while
+* ensuring that all vma assiocated with the respective pd/pdp are
+* unpinned at the time.
+*/
+
+   for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
+   unsigned int size = sizes[i];
+
+   purge = fake_dma_object(i915, size);
+   if (IS_ERR(purge))
+   return PTR_ERR(purge);
+
+   vma = i915_vma_instance(purge, vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_purge;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, flags);
+   if (err)
+   goto err_purge;
+
+   /* Should now be ripe for purging */
+   i915_vma_unpin(vma);
+
+   explode = fake_dma_object(i915, size);
+   if (IS_ERR(explode)) {
+   err = PTR_ERR(purge);
+   goto err_purge;
+   }
+
+   vm->fault_attr.probability = 100;
+   vm->fault_attr.interval = 1;
+   atomic_set(>fault_attr.times, -1);
+
+   vma = i915_vma_instance(explode, vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_explode;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, flags | size);
+   if (err)
+   goto err_explode;
+
+   i915_vma_unpin(vma);
+
+   i915_gem_object_put(purge);
+   i915_gem_object_put(explode);
+
+   memset(>fault_attr, 0, sizeof(vm->fault_attr));
+   }
+
+   return 0;
+
+err_explode:
+   i915_gem_object_put(explode);
+err_purge:
+   i915_gem_object_put(purge);
+
+   return err;
+}
+
 static int exercise_ppgtt(struct drm_i915_private *dev_priv,
  int (*func)(struct drm_i915_private *i915,
  struct i915_address_space *vm,
@@ -953,6 +1031,11 @@ static int igt_ppgtt_shrink(void *arg)
return exercise_ppgtt(arg, shrink_hole);
 }
 
+static int igt_ppgtt_shrink_boom(void *arg)
+{
+   return exercise_ppgtt(arg, shrink_boom);
+}
+
 static int sort_holes(void *priv, struct list_head *A, struct list_head *B)
 {
struct drm_mm_node *a = list_entry(A, typeof(*a), hole_stack);
@@ -1577,6 +1660,7 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private 
*i915)
SUBTEST(igt_ppgtt_pot),
SUBTEST(igt_ppgtt_fill),
SUBTEST(igt_ppgtt_shrink),
+   SUBTEST(igt_ppgtt_shrink_boom),
SUBTEST(igt_ggtt_lowlevel),
SUBTEST(igt_ggtt_drunk),
SUBTEST(igt_ggtt_walk),
-- 
2.15.1

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

[Intel-gfx] [PATCH 1/2] drm/i915/ppgtt: Pin page directories before allocation

[Chris Wilson]

Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
believed that because it did not insert its freshly allocated page
directory into the pd tree, it was safe from the shrinker. I failed to
heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap
tracking for used-ptes") that we need to pin all the levels in the tree
before hitting the shrinker or else the shrinker may free an upper layer
as we proceed to allocate the tree. Thus leaving dangling pointers
everywhere and a GPF should we hit direct reclaim at just the wrong
moment.

Jan 24 10:32:48 eric-macbookpro kernel: CPU: 0 PID: 7374 Comm: chromium 
Tainted: P   O4.14.13-1-ARCH #1
Jan 24 10:32:48 eric-macbookpro kernel: Hardware name: Apple Inc. 
MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 
06/18/2017
Jan 24 10:32:48 eric-macbookpro kernel: task: 994f696c2c40 task.stack: 
b1a789d4c000
Jan 24 10:32:48 eric-macbookpro kernel: RIP: 
0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915]
Jan 24 10:32:48 eric-macbookpro kernel: RSP: 0018:b1a789d4f940 EFLAGS: 
00010206
Jan 24 10:32:48 eric-macbookpro kernel: RAX: 81c1788cc4f68138 RBX: 
994f54db8000 RCX: 994f696c2c40
Jan 24 10:32:48 eric-macbookpro kernel: RDX: 00023bc73003 RSI: 
994d598b6b80 RDI: 994f54db8000
Jan 24 10:32:48 eric-macbookpro kernel: RBP: 994d598b6b80 R08: 
 R09: 
Jan 24 10:32:48 eric-macbookpro kernel: R10: b1a789d4f550 R11: 
994eaf3c3208 R12: 0027
Jan 24 10:32:48 eric-macbookpro kernel: R13: 5000 R14: 
04e8f000 R15: 994f54dba000
Jan 24 10:32:48 eric-macbookpro kernel: FS:  7f585886aa00() 
GS:994faec0() knlGS:
Jan 24 10:32:48 eric-macbookpro kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Jan 24 10:32:48 eric-macbookpro kernel: CR2: 004ac8e8 CR3: 
0002552c8004 CR4: 003606f0
Jan 24 10:32:48 eric-macbookpro kernel: Call Trace:
Jan 24 10:32:48 eric-macbookpro kernel:  gen8_ppgtt_alloc_pdp+0x178/0x320 [i915]
Jan 24 10:32:48 eric-macbookpro kernel:  gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915]
Jan 24 10:32:48 eric-macbookpro kernel:  ppgtt_bind_vma+0x30/0x70 [i915]
Jan 24 10:32:48 eric-macbookpro kernel:  i915_vma_bind+0x68/0xd0 [i915]
Jan 24 10:32:48 eric-macbookpro kernel:  __i915_vma_do_pin+0x2d6/0x3a0 [i915]
Jan 24 10:32:48 eric-macbookpro kernel:  eb_lookup_vmas+0x7a2/0xb50 [i915]
Jan 24 10:32:48 eric-macbookpro kernel:  i915_gem_do_execbuffer+0x4d7/0x10e0 
[i915]
Jan 24 10:32:48 eric-macbookpro kernel:  ? sock_wfree+0x34/0x60
Jan 24 10:32:48 eric-macbookpro kernel:  ? unix_stream_read_generic+0x1f9/0x7e0
Jan 24 10:32:48 eric-macbookpro kernel:  ? import_iovec+0x37/0xd0
Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer2+0x5d/0x390 
[i915]
Jan 24 10:32:48 eric-macbookpro kernel:  i915_gem_execbuffer2+0x1b7/0x390 [i915]
Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer+0x2d0/0x2d0 
[i915]
Jan 24 10:32:48 eric-macbookpro kernel:  drm_ioctl_kernel+0x59/0xb0 [drm]
Jan 24 10:32:48 eric-macbookpro kernel:  drm_ioctl+0x2d5/0x370 [drm]
Jan 24 10:32:48 eric-macbookpro kernel:  ? i915_gem_execbuffer+0x2d0/0x2d0 
[i915]
Jan 24 10:32:48 eric-macbookpro kernel:  ? __seccomp_filter+0x3b/0x260
Jan 24 10:32:48 eric-macbookpro kernel:  do_vfs_ioctl+0xa1/0x610
Jan 24 10:32:48 eric-macbookpro kernel:  ? syscall_trace_enter+0xdb/0x2b0
Jan 24 10:32:48 eric-macbookpro kernel:  SyS_ioctl+0x74/0x80
Jan 24 10:32:48 eric-macbookpro kernel:  do_syscall_64+0x55/0x110
Jan 24 10:32:48 eric-macbookpro kernel:  entry_SYSCALL64_slow_path+0x25/0x25
Jan 24 10:32:48 eric-macbookpro kernel: RIP: 0033:0x7f584fa82d27
Jan 24 10:32:48 eric-macbookpro kernel: RSP: 002b:7ffee14a7828 EFLAGS: 
0246 ORIG_RAX: 0010
Jan 24 10:32:48 eric-macbookpro kernel: RAX: ffda RBX: 
03b0126a1030 RCX: 7f584fa82d27
Jan 24 10:32:48 eric-macbookpro kernel: RDX: 7ffee14a7870 RSI: 
40406469 RDI: 0080
Jan 24 10:32:48 eric-macbookpro kernel: RBP: 7ffee14a7870 R08: 
0002 R09: 0077
Jan 24 10:32:48 eric-macbookpro kernel: R10: 7f5839f2b780 R11: 
0246 R12: 40406469
Jan 24 10:32:48 eric-macbookpro kernel: R13: 0080 R14: 
7f5842b00040 R15: 
Jan 24 10:32:48 eric-macbookpro kernel: Code: 01 00 83 81 58 0a 00 00 01 48 2b 
05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d 
fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 
c3
Jan 24 10:32:48 eric-macbookpro kernel: RIP: 
gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: b1a789d4f940

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773
Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
References: dd19674bacba ("drm/i915: Remove bitmap tracking for used-ptes")
Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom)

[Intel-gfx] [PATCH] drm/i915/cnl: Respect VBT max dp rate.

[Rodrigo Vivi]

Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link
rate to VBT child device struct")' we have the new entry
defined for max dp rate that is in use for CNL.

Let's start using it for all VBT 216+ and
also organize the cnl adjusted rates in terms of rate
and not array size.

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c |  3 +++
 drivers/gpu/drm/i915/intel_dp.c   | 37 +
 3 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c676269ed843..66dea5c9b10e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1282,6 +1282,7 @@ struct ddi_vbt_port_info {
 
uint8_t dp_boost_level;
uint8_t hdmi_boost_level;
+   uint8_t dp_max_link_rate;
 };
 
 enum psr_lines_to_wait {
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index cf3f8f1ba6f7..c885daf4cc8d 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1230,6 +1230,9 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
info->alternate_aux_channel = aux_channel;
 
sanitize_aux_ch(dev_priv, port);
+
+   if (bdb_version >= 216 && child->dp_max_link_rate)
+   info->dp_max_link_rate = child->dp_max_link_rate;
}
 
if (bdb_version >= 158) {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 03d86ff9b805..1e34d7954355 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -220,7 +220,7 @@ intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
return max_dotclk;
 }
 
-static int cnl_adjusted_max_rate(struct intel_dp *intel_dp, int size)
+static int cnl_adjusted_max_rate(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
@@ -230,17 +230,33 @@ static int cnl_adjusted_max_rate(struct intel_dp 
*intel_dp, int size)
 
/* Low voltage SKUs are limited to max of 5.4G */
if (voltage == VOLTAGE_INFO_0_85V)
-   return size - 2;
+   return 54;
 
/* For this SKU 8.1G is supported in all ports */
if (IS_CNL_WITH_PORT_F(dev_priv))
-   return size;
+   return 81;
 
/* For other SKUs, max rate on ports A and B is 5.4G */
if (port == PORT_A || port == PORT_D)
-   return size - 2;
+   return 54;
 
-   return size;
+   return 81;
+}
+
+static int intel_dp_adjusted_max_rate(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   const struct ddi_vbt_port_info *info =
+   _priv->vbt.ddi_port_info[dig_port->base.port];
+
+   if (info->dp_max_link_rate)
+   return info->dp_max_link_rate;
+
+   if (IS_CANNONLAKE(dev_priv))
+   return cnl_adjusted_max_rate(intel_dp);
+
+   return INT_MAX; /* No adjusted limit */
 }
 
 static void
@@ -249,7 +265,8 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
const int *source_rates;
-   int size;
+   int i, size;
+   int max_rate = intel_dp_adjusted_max_rate(intel_dp);
 
/* This should only be done once */
WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
@@ -259,7 +276,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
size = ARRAY_SIZE(bxt_rates);
} else if (IS_CANNONLAKE(dev_priv)) {
source_rates = cnl_rates;
-   size = cnl_adjusted_max_rate(intel_dp, ARRAY_SIZE(cnl_rates));
+   size = ARRAY_SIZE(cnl_rates);
} else if (IS_GEN9_BC(dev_priv)) {
source_rates = skl_rates;
size = ARRAY_SIZE(skl_rates);
@@ -272,8 +289,12 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
size = ARRAY_SIZE(default_rates) - 1;
}
 
+   for (i = 0; i < size; i++)
+   if (source_rates[i] > max_rate)
+   break;
+
+   intel_dp->num_source_rates = i;
intel_dp->source_rates = source_rates;
-   intel_dp->num_source_rates = size;
 }
 
 static int intersect_rates(const int *source_rates, int source_len,
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915/selftests: add missing gtt shrinker test

[Chris Wilson]

Quoting Matthew Auld (2018-01-31 19:14:53)
> Try to catch a bug we've seen in the wild where the shrinker purges the
> pd/pdp from under us while allocating our paging structures.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=104773
> Signed-off-by: Matthew Auld 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 84 
> +++
>  1 file changed, 84 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index bb7cf998fc65..a40a2a7514fd 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -885,6 +885,84 @@ static int shrink_hole(struct drm_i915_private *i915,
> return err;
>  }
>  
> +static int shrink_boom(struct drm_i915_private *i915,
> +  struct i915_address_space *vm,
> +  u64 hole_start, u64 hole_end,
> +  unsigned long end_time)
> +{
> +   unsigned int sizes[] = {SZ_2M, SZ_1G};
> +   struct drm_i915_gem_object *purge;
> +   struct drm_i915_gem_object *explode;
> +   struct i915_vma *vma;
> +   unsigned int flags = PIN_USER | PIN_OFFSET_FIXED;
> +   int err;
> +   int i;
> +
> +   /*
> +* Catch the case which shrink_hole seems to miss. The setup here
> +* requires invoking the shrinker as we do the alloc_pt/alloc_pd, 
> while
> +* ensuring that all vma assiocated with the respective pd/pdp are
> +* unpinned at the time.
> +*/

Question for everyone: can we see more holes in shrink_hole?

> +
> +   for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
> +   unsigned int size = sizes[i];
> +
> +   purge = fake_dma_object(i915, size);
> +   if (IS_ERR(purge))
> +   return PTR_ERR(purge);
> +
> +   vma = i915_vma_instance(purge, vm, NULL);
> +   if (IS_ERR(vma)) {
> +   err = PTR_ERR(vma);
> +   goto err_purge;
> +   }
> +
> +   err = i915_vma_pin(vma, 0, 0, flags);
> +   if (err)
> +   goto err_purge;
> +
> +   /* Should now be ripe for purging */
> +   i915_vma_unpin(vma);
> +
> +   explode = fake_dma_object(i915, size);
> +   if (IS_ERR(explode)) {
> +   err = PTR_ERR(purge);
> +   goto err_purge;
> +   }
> +
> +   vm->fault_attr.probability = 100;
> +   vm->fault_attr.interval = 1;
> +   atomic_set(>fault_attr.times, -1);
> +
> +   vma = i915_vma_instance(explode, vm, NULL);
> +   if (IS_ERR(vma)) {
> +   err = PTR_ERR(vma);
> +   goto err_explode;
> +   }
> +
> +   err = i915_vma_pin(vma, 0, 0, flags | size);
> +   if (err)
> +   goto err_explode;
> +
> +   i915_vma_unpin(vma);
> +
> +   i915_gem_object_put(purge);
> +   i915_gem_object_put(explode);
> +
> +   memset(>fault_attr, 0, sizeof(vm->fault_attr));
> +   }
> +
> +   return 0;
> +
> +err_explode:
> +   i915_gem_object_put(explode);
> +err_purge:
> +   i915_gem_object_put(purge);
> +
> +   return err;
> +}

As this demonstrates a shrinker bug we missed in the test intended to
find all shrinker bugs,
Reviewed-by: Chris Wilson 

Just worrying about how deep the iceberg goes. (Though more about
catching tomorrow's bug as we should have this one fixed pretty shortly.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/selftests: add missing gtt shrinker test

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: add missing gtt shrinker test
URL   : https://patchwork.freedesktop.org/series/37432/
State : warning

== Summary ==

Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676 +1
Test kms_flip:
Subgroup flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-apl) fdo#102887
Subgroup basic-plain-flip:
skip   -> PASS   (shard-apl)
Test kms_plane_multiple:
Subgroup atomic-pipe-b-tiling-yf:
fail   -> PASS   (shard-apl)
Subgroup legacy-pipe-a-tiling-x:
skip   -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-c-ts-continuation-suspend:
dmesg-warn -> PASS   (shard-apl)
Subgroup pipe-a-query-busy:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-accuracy-idle:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-wait-forked-busy:
skip   -> PASS   (shard-apl)
Subgroup crtc-id:
skip   -> PASS   (shard-apl)
Test kms_draw_crc:
Subgroup draw-method-xrgb-render-untiled:
skip   -> PASS   (shard-apl)
Subgroup draw-method-xrgb2101010-render-xtiled:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-a-ctm-0-75:
skip   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#103167 +1
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
skip   -> PASS   (shard-apl) fdo#101623 +2
Subgroup fbc-rgb101010-draw-mmap-gtt:
skip   -> PASS   (shard-apl)
Test kms_cursor_crc:
Subgroup cursor-256x256-rapid-movement:
skip   -> PASS   (shard-apl) fdo#103326
Subgroup cursor-256x256-dpms:
skip   -> PASS   (shard-apl)
Subgroup cursor-128x42-random:
skip   -> PASS   (shard-apl)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (shard-apl) fdo#103481
Subgroup read-crc-pipe-c:
skip   -> PASS   (shard-apl) fdo#103191
Subgroup read-crc-pipe-a:
skip   -> PASS   (shard-apl)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
skip   -> PASS   (shard-apl)
Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
skip   -> PASS   (shard-apl) fdo#103336
Test kms_plane_scaling:
Subgroup pipe-c-plane-scaling:
skip   -> PASS   (shard-apl)
Test kms_rotation_crc:
Subgroup primary-rotation-90-y-tiled:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (shard-apl) fdo#102670
Subgroup cursora-vs-flipa-atomic:
skip   -> PASS   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-bottom-edge:
skip   -> PASS   (shard-apl)
Test kms_rmfb:
Subgroup rmfb-ioctl:
skip   -> PASS   (shard-apl)
Test kms_ccs:
Subgroup pipe-b-bad-pixel-format:
skip   -> PASS   (shard-apl)
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test drv_selftest:
Subgroup live_gtt:
pass   -> DMESG-FAIL (shard-apl) fdo#103927 +1
Subgroup live_evict:
pass   -> SKIP   (shard-apl)
Subgroup live_contexts:
pass   -> SKIP   (shard-apl)
Subgroup live_hangcheck:
pass   -> SKIP   (shard-apl) fdo#104262 +1
Subgroup live_guc:
pass   -> SKIP   (shard-apl)

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103336 

Re: [Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints

[Chris Wilson]

Quoting Michal Wajdeczko (2018-01-31 18:23:47)
> Our inject_load_failure functionality allows to insert one
> failure during driver load, but it is hard to guess which
> number should passed as modparam to select specific checkpoint.
> 
> Use negative number as option to list all available failure
> checkpoints without triggering any failure.

Hmm, it was only intended for use with the coupled igt test. Mind
expanding upon the use case you have? Could you not use that iterative
search for finding the injection value you want for repeated runs? For
the bisect case, do you not want to keep it iterating over all in case
the value changes? How stable do you want the modparam?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Chris Wilson]

Quoting Chris Wilson (2018-01-31 20:40:03)
> Quoting Chris Wilson (2018-01-31 17:30:46)
> > Quoting Tvrtko Ursulin (2018-01-31 17:18:55)
> > > 
> > > On 22/01/2018 15:41, Chris Wilson wrote:
> > > > +static struct drm_i915_gem_request *first_signal(struct 
> > > > intel_breadcrumbs *b)
> > > > +{
> > > > + /*
> > > > +  * See the big warnings for i915_gem_active_get_rcu() and 
> > > > similarly
> > > > +  * for dma_fence_get_rcu_safe() that explain the intricacies 
> > > > involved
> > > > +  * here with defeating CPU/compiler speculation and enforcing
> > > > +  * the required memory barriers.
> > > > +  */
> > > > + do {
> > > > + struct drm_i915_gem_request *request;
> > > > +
> > > > + request = rcu_dereference(b->first_signal);
> > > > + if (request)
> > > > + request = i915_gem_request_get_rcu(request);
> > > > +
> > > > + barrier();
> > > > +
> > > > + if (!request || request == 
> > > > rcu_access_pointer(b->first_signal))
> > > > + return rcu_pointer_handoff(request);
> > > > +
> > > > + i915_gem_request_put(request);
> > > > + } while (1);
> > > > +}
> > > > +
> > > >   static int intel_breadcrumbs_signaler(void *arg)
> > > >   {
> > > >   struct intel_engine_cs *engine = arg;
> > > > @@ -667,41 +715,21 @@ static int intel_breadcrumbs_signaler(void *arg)
> > > >* a new client.
> > > >*/
> > > >   rcu_read_lock();
> > > > - request = rcu_dereference(b->first_signal);
> > > > - if (request)
> > > > - request = i915_gem_request_get_rcu(request);
> > > > + request = first_signal(b);
> > > 
> > > get_ prefix would be good to signify a get vs peek. Maybe even _rcu 
> > > suffix.
> > 
> > Sold.
> 
> Whilst you are looking at this, I should just say that first_signal() is
> what we should have been doing all this time; it's really a very obscure
> bug fix. And fwiw, the s/rbtree/list/ patch eliminates it.

Hmm, actually no, no underlying bug here as the reference was previously
carried by the signaler, and with its removal do we need to do the
double dance. (It's a bad sign when I can remember having that exact
conversation with myself; and forgot until too late.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Chris Wilson]

Quoting Chris Wilson (2018-01-31 17:30:46)
> Quoting Tvrtko Ursulin (2018-01-31 17:18:55)
> > 
> > On 22/01/2018 15:41, Chris Wilson wrote:
> > > +static struct drm_i915_gem_request *first_signal(struct 
> > > intel_breadcrumbs *b)
> > > +{
> > > + /*
> > > +  * See the big warnings for i915_gem_active_get_rcu() and similarly
> > > +  * for dma_fence_get_rcu_safe() that explain the intricacies 
> > > involved
> > > +  * here with defeating CPU/compiler speculation and enforcing
> > > +  * the required memory barriers.
> > > +  */
> > > + do {
> > > + struct drm_i915_gem_request *request;
> > > +
> > > + request = rcu_dereference(b->first_signal);
> > > + if (request)
> > > + request = i915_gem_request_get_rcu(request);
> > > +
> > > + barrier();
> > > +
> > > + if (!request || request == 
> > > rcu_access_pointer(b->first_signal))
> > > + return rcu_pointer_handoff(request);
> > > +
> > > + i915_gem_request_put(request);
> > > + } while (1);
> > > +}
> > > +
> > >   static int intel_breadcrumbs_signaler(void *arg)
> > >   {
> > >   struct intel_engine_cs *engine = arg;
> > > @@ -667,41 +715,21 @@ static int intel_breadcrumbs_signaler(void *arg)
> > >* a new client.
> > >*/
> > >   rcu_read_lock();
> > > - request = rcu_dereference(b->first_signal);
> > > - if (request)
> > > - request = i915_gem_request_get_rcu(request);
> > > + request = first_signal(b);
> > 
> > get_ prefix would be good to signify a get vs peek. Maybe even _rcu suffix.
> 
> Sold.

Whilst you are looking at this, I should just say that first_signal() is
what we should have been doing all this time; it's really a very obscure
bug fix. And fwiw, the s/rbtree/list/ patch eliminates it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add option to list load failure checkpoints

[Patchwork]

== Series Details ==

Series: drm/i915: Add option to list load failure checkpoints
URL   : https://patchwork.freedesktop.org/series/37427/
State : failure

== Summary ==

Test kms_flip:
Subgroup wf_vblank-ts-check-interruptible:
fail   -> PASS   (shard-apl) fdo#100368 +3
Subgroup basic-plain-flip:
skip   -> PASS   (shard-apl)
Subgroup flip-vs-panning-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Test kms_plane_multiple:
Subgroup legacy-pipe-c-tiling-none:
pass   -> FAIL   (shard-apl)
Subgroup legacy-pipe-a-tiling-x:
skip   -> PASS   (shard-apl)
Subgroup atomic-pipe-b-tiling-yf:
fail   -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-c-ts-continuation-suspend:
dmesg-warn -> PASS   (shard-apl)
Subgroup pipe-a-query-busy:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-accuracy-idle:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-wait-forked-busy:
skip   -> PASS   (shard-apl)
Subgroup crtc-id:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-ts-continuation-dpms-suspend:
pass   -> DMESG-WARN (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-xrgb-render-untiled:
skip   -> PASS   (shard-apl)
Subgroup draw-method-xrgb2101010-render-xtiled:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-a-ctm-0-75:
skip   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#103167 +1
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
skip   -> PASS   (shard-apl) fdo#101623 +2
Subgroup fbc-rgb101010-draw-mmap-gtt:
skip   -> PASS   (shard-apl)
Test kms_cursor_crc:
Subgroup cursor-256x256-rapid-movement:
skip   -> PASS   (shard-apl) fdo#103326
Subgroup cursor-256x256-dpms:
skip   -> PASS   (shard-apl)
Subgroup cursor-128x42-random:
skip   -> PASS   (shard-apl)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (shard-apl) fdo#103481
Subgroup read-crc-pipe-c:
skip   -> PASS   (shard-apl) fdo#103191
Subgroup read-crc-pipe-a:
skip   -> PASS   (shard-apl)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
skip   -> PASS   (shard-apl)
Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
skip   -> PASS   (shard-apl) fdo#103336
Test kms_plane_scaling:
Subgroup pipe-c-plane-scaling:
skip   -> PASS   (shard-apl)
Test kms_rotation_crc:
Subgroup primary-rotation-90-y-tiled:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (shard-apl) fdo#102670
Subgroup cursora-vs-flipa-atomic:
skip   -> PASS   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-bottom-edge:
skip   -> PASS   (shard-apl)
Test kms_rmfb:
Subgroup rmfb-ioctl:
skip   -> PASS   (shard-apl)
Test kms_ccs:
Subgroup pipe-b-bad-pixel-format:
skip   -> PASS   (shard-apl)
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test gem_eio:
Subgroup in-flight-suspend:
pass   -> FAIL   (shard-hsw) fdo#104676
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103336 https://bugs.freedesktop.org/show_bug.cgi?id=103336
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:2838 pass:1750 dwarn:1   dfail:0   fail:23  skip:1064 
time:12621s
shard-hsw

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Harry Wentland]

On 2018-01-30 05:28 AM, Maarten Lankhorst wrote:
> Op 29-01-18 om 16:41 schreef Leo Li:
>> Updated IGT results seem sane:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
>>
>> Would someone be able to apply this patch?
>>
> Thanks for the reminder, pushed.
> 

Thanks, Maarten. I see it in drm-misc-next.

Would someone be able to pull this into drm-misc-fixes as well, or can I just I 
apply this myself with the following dim commands?

dim checkout drm-misc-fixes
dim cherry-pick 1c6c6ebb
dim push-branch

Harry


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: add missing gtt shrinker test

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: add missing gtt shrinker test
URL   : https://patchwork.freedesktop.org/series/37432/
State : success

== Summary ==

Series 37432v1 drm/i915/selftests: add missing gtt shrinker test
https://patchwork.freedesktop.org/api/1.0/series/37432/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> FAIL   (fi-elk-e7500) fdo#103989 +1
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup common-hpd-after-suspend:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#104108
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:478s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:224  pass:167  dwarn:10  dfail:0   fail:1   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s

ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC 
integration manifest
6939c297c5bd drm/i915/selftests: add missing gtt shrinker test

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7843/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/selftests: add missing gtt shrinker test

[Matthew Auld]

Try to catch a bug we've seen in the wild where the shrinker purges the
pd/pdp from under us while allocating our paging structures.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104773
Signed-off-by: Matthew Auld 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 84 +++
 1 file changed, 84 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index bb7cf998fc65..a40a2a7514fd 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -885,6 +885,84 @@ static int shrink_hole(struct drm_i915_private *i915,
return err;
 }
 
+static int shrink_boom(struct drm_i915_private *i915,
+  struct i915_address_space *vm,
+  u64 hole_start, u64 hole_end,
+  unsigned long end_time)
+{
+   unsigned int sizes[] = {SZ_2M, SZ_1G};
+   struct drm_i915_gem_object *purge;
+   struct drm_i915_gem_object *explode;
+   struct i915_vma *vma;
+   unsigned int flags = PIN_USER | PIN_OFFSET_FIXED;
+   int err;
+   int i;
+
+   /*
+* Catch the case which shrink_hole seems to miss. The setup here
+* requires invoking the shrinker as we do the alloc_pt/alloc_pd, while
+* ensuring that all vma assiocated with the respective pd/pdp are
+* unpinned at the time.
+*/
+
+   for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
+   unsigned int size = sizes[i];
+
+   purge = fake_dma_object(i915, size);
+   if (IS_ERR(purge))
+   return PTR_ERR(purge);
+
+   vma = i915_vma_instance(purge, vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_purge;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, flags);
+   if (err)
+   goto err_purge;
+
+   /* Should now be ripe for purging */
+   i915_vma_unpin(vma);
+
+   explode = fake_dma_object(i915, size);
+   if (IS_ERR(explode)) {
+   err = PTR_ERR(purge);
+   goto err_purge;
+   }
+
+   vm->fault_attr.probability = 100;
+   vm->fault_attr.interval = 1;
+   atomic_set(>fault_attr.times, -1);
+
+   vma = i915_vma_instance(explode, vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_explode;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, flags | size);
+   if (err)
+   goto err_explode;
+
+   i915_vma_unpin(vma);
+
+   i915_gem_object_put(purge);
+   i915_gem_object_put(explode);
+
+   memset(>fault_attr, 0, sizeof(vm->fault_attr));
+   }
+
+   return 0;
+
+err_explode:
+   i915_gem_object_put(explode);
+err_purge:
+   i915_gem_object_put(purge);
+
+   return err;
+}
+
 static int exercise_ppgtt(struct drm_i915_private *dev_priv,
  int (*func)(struct drm_i915_private *i915,
  struct i915_address_space *vm,
@@ -953,6 +1031,11 @@ static int igt_ppgtt_shrink(void *arg)
return exercise_ppgtt(arg, shrink_hole);
 }
 
+static int igt_ppgtt_shrink_boom(void *arg)
+{
+   return exercise_ppgtt(arg, shrink_boom);
+}
+
 static int sort_holes(void *priv, struct list_head *A, struct list_head *B)
 {
struct drm_mm_node *a = list_entry(A, typeof(*a), hole_stack);
@@ -1577,6 +1660,7 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private 
*i915)
SUBTEST(igt_ppgtt_pot),
SUBTEST(igt_ppgtt_fill),
SUBTEST(igt_ppgtt_shrink),
+   SUBTEST(igt_ppgtt_shrink_boom),
SUBTEST(igt_ggtt_lowlevel),
SUBTEST(igt_ggtt_drunk),
SUBTEST(igt_ggtt_walk),
-- 
2.14.3

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add option to list load failure checkpoints

[Patchwork]

== Series Details ==

Series: drm/i915: Add option to list load failure checkpoints
URL   : https://patchwork.freedesktop.org/series/37427/
State : success

== Summary ==

Series 37427v1 drm/i915: Add option to list load failure checkpoints
https://patchwork.freedesktop.org/api/1.0/series/37427/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup common-hpd-after-suspend:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#104108
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:369s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:461s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:389s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:571s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:520s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:465s

ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC 
integration manifest
879ec7a733e0 drm/i915: Add option to list load failure checkpoints

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7842/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints

[Michal Wajdeczko]

Our inject_load_failure functionality allows to insert one
failure during driver load, but it is hard to guess which
number should passed as modparam to select specific checkpoint.

Use negative number as option to list all available failure
checkpoints without triggering any failure.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c| 18 +++---
 drivers/gpu/drm/i915/i915_params.c |  6 --
 drivers/gpu/drm/i915/i915_params.h |  2 +-
 3 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ec12ad..0992301 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -55,16 +55,21 @@
 
 static struct drm_driver driver;
 
-static unsigned int i915_load_fail_count;
+static int i915_load_fail_count = 0;
 
 bool __i915_inject_load_failure(const char *func, int line)
 {
-   if (i915_load_fail_count >= i915_modparams.inject_load_failure)
+   ++i915_load_fail_count;
+
+   if (unlikely(i915_modparams.inject_load_failure < 0)) {
+   DRM_NOTE("[i915] load checkpoint %d [%s:%d]\n",
+i915_load_fail_count, func, line);
return false;
+   }
 
-   if (++i915_load_fail_count == i915_modparams.inject_load_failure) {
-   DRM_INFO("Injecting failure at checkpoint %u [%s:%d]\n",
-i915_modparams.inject_load_failure, func, line);
+   if (i915_modparams.inject_load_failure == i915_load_fail_count) {
+   DRM_INFO("Injecting failure at checkpoint %d [%s:%d]\n",
+i915_load_fail_count, func, line);
return true;
}
 
@@ -107,8 +112,7 @@ bool __i915_inject_load_failure(const char *func, int line)
 
 static bool i915_error_injected(struct drm_i915_private *dev_priv)
 {
-   return i915_modparams.inject_load_failure &&
-  i915_load_fail_count == i915_modparams.inject_load_failure;
+   return i915_modparams.inject_load_failure >= i915_load_fail_count;
 }
 
 #define i915_load_error(dev_priv, fmt, ...) \
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 0b553a8..e5ab69c 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -167,8 +167,10 @@ struct i915_params i915_modparams __read_mostly = {
 i915_param_named_unsafe(enable_dp_mst, bool, 0600,
"Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");
 
-i915_param_named_unsafe(inject_load_failure, uint, 0400,
-   "Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
+i915_param_named_unsafe(inject_load_failure, int, 0400,
+   "Force an error after a number of failure check points. "
+   "(-1=list check points, 0=disabled [default], "
+   "N=force failure at the Nth failure check point)");
 
 i915_param_named(enable_dpcd_backlight, bool, 0600,
"Enable support for DPCD backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..6ed799f 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -54,7 +54,7 @@
param(int, mmio_debug, 0) \
param(int, edp_vswing, 0) \
param(int, reset, 2) \
-   param(unsigned int, inject_load_failure, 0) \
+   param(int, inject_load_failure, 0) \
/* leave bools at the end to not create holes */ \
param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \
param(bool, enable_cmd_parser, true) \
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/pmu: Micro-optimize sampling loop

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Micro-optimize sampling loop
URL   : https://patchwork.freedesktop.org/series/37420/
State : warning

== Summary ==

Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-legacy:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_atomic_interruptible:
Subgroup legacy-cursor:
pass   -> SKIP   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-cpu:
pass   -> SKIP   (shard-snb) fdo#101623
Test drv_suspend:
Subgroup sysfs-reader-hibernate:
fail   -> SKIP   (shard-hsw) fdo#103375
Test perf_pmu:
Subgroup semaphore-wait-bcs0:
fail   -> PASS   (shard-apl) fdo#104829

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829

shard-apltotal:2838 pass:1748 dwarn:2   dfail:0   fail:23  skip:1064 
time:12578s
shard-hswtotal:2838 pass:1734 dwarn:1   dfail:0   fail:11  skip:1091 
time:11946s
shard-snbtotal:2838 pass:1328 dwarn:1   dfail:0   fail:10  skip:1499 
time:6614s
Blacklisted hosts:
shard-kbltotal:2838 pass:1870 dwarn:4   dfail:0   fail:22  skip:942 
time:9731s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7840/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/uc: Add few more load failure checkpoints

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915/uc: Add few more load failure 
checkpoints
URL   : https://patchwork.freedesktop.org/series/37425/
State : failure

== Summary ==

Series 37425v1 series starting with [1/5] drm/i915/uc: Add few more load 
failure checkpoints
https://patchwork.freedesktop.org/api/1.0/series/37425/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +3
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-threads:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-files:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default-heavy:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-default:
pass   -> SKIP   (fi-skl-gvtdvm)
WARNING: Long output truncated

ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC 
integration manifest
8f4dbd51e218 HAX: Enable GuC for CI
2c3f53721546 drm/i915/guc: Don't try to create log runtime if there is no log
7d73ec81b603 drm/i915/guc: Use correct error code for GuC initialization failure
c484a76baebc drm/i915/guc: Don't forget to free GuC error log
095bb2376c30 drm/i915/uc: Add few more load failure checkpoints

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7841/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/5] drm/i915/guc: Don't try to create log runtime if there is no log

[Michal Wajdeczko]

In case of GuC initialization failure we may continue with driver
load, but we wrongly assume that GuC is fully functional. This
leads to the BUG as we attempt to access non-existing log vma.

[26386.121085] BUG: unable to handle kernel NULL pointer dereference at 
00a0
[26386.121225] IP: guc_log_runtime_create+0x23/0xe0 [i915]
[26386.121763] Call Trace:
[26386.121870]  guc_log_late_setup+0xfd/0x140 [i915]
[26386.121969]  i915_driver_load+0x7ab/0x1730 [i915]
[26386.122069]  i915_pci_probe+0x2d/0x90 [i915]
[26386.122089]  pci_device_probe+0x9c/0x120
[26386.122107]  driver_probe_device+0x2a9/0x490
[26386.122126]  __driver_attach+0xd9/0xe0
[26386.122143]  ? driver_probe_device+0x490/0x490
[26386.122158]  bus_for_each_dev+0x57/0x90
[26386.122175]  bus_add_driver+0x1eb/0x260
[26386.122190]  ? 0xa069a000
[26386.122206]  driver_register+0x52/0xc0
[26386.10]  ? 0xa069a000
[26386.122234]  do_one_initcall+0x39/0x170
[26386.122252]  ? kmem_cache_alloc_trace+0x1fd/0x2e0
[26386.122273]  do_init_module+0x56/0x1ec
[26386.122289]  load_module+0x219e/0x2550
[26386.122309]  ? vfs_read+0x121/0x140
[26386.122331]  ? SyS_finit_module+0xa5/0xe0
[26386.122346]  SyS_finit_module+0xa5/0xe0
[26386.122371]  entry_SYSCALL_64_fastpath+0x22/0x8f

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Michal Winiarski 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 3fbe93a..fdb1895 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -395,6 +395,9 @@ static int guc_log_runtime_create(struct intel_guc *guc)
void *vaddr;
int ret;
 
+   if (!guc->log.vma)
+   return -ENODEV;
+
lockdep_assert_held(_priv->drm.struct_mutex);
 
GEM_BUG_ON(guc_log_has_runtime(guc));
-- 
1.9.1

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

[Intel-gfx] [PATCH 5/5] HAX: Enable GuC for CI

[Michal Wajdeczko]

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 5ac8882..0a63f59 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/5] drm/i915/guc: Use correct error code for GuC initialization failure

[Michal Wajdeczko]

Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EIO).

Unfortunately since commit 121981fafe ("drm/i915/guc: Combine
enable_guc_loading|submission modparams") we stopped using that
error code to avoid unwanted fallback to execlist submission mode.

In result any GuC initialization failure was treated as non-recoverable
error leading to driver load abort, so we could not even read related
GuC error log to investigate cause of the problem.

Fix that by always returning -EIO on uC hardware related failure.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Michal Winiarski 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 3a13cbb..1547e16 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -432,11 +432,8 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * Note that there is no fallback as either user explicitly asked for
 * the GuC or driver default option was to run with the GuC enabled.
 */
-   if (GEM_WARN_ON(ret == -EIO))
-   ret = -EINVAL;
-
dev_err(dev_priv->drm.dev, "GuC initialization failed %d\n", ret);
-   return ret;
+   return -EIO; /* We want to disable GPU submission but keep KMS alive */
 }
 
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/5] drm/i915/guc: Don't forget to free GuC error log

[Michal Wajdeczko]

We're freeing GuC error log in uc_fini_hw() that matches
corresponding uc_init_hw() but we missed the point that this
log object is copied on error path and in case of failure in
uc_init_hw() we will leak this object as uc_fini_hw() is
never called.

If we free this log object as part of the late uC cleanup, where
we also release other firmware objects, we can avoid this BUG:

[70841.001413] BUG drm_i915_gem_object (Tainted: G U  W   ): Objects 
remaining in drm_i915_gem_object on __kmem_cache_shutdown()
[70841.001436] INFO: Slab 0xc94e41af objects=21 used=1 
fp=0x1d60c40a flags=0x80008100

[70841.001466] Call Trace:
[70841.001471]  dump_stack+0x5e/0x8e
[70841.001476]  slab_err+0x99/0xb0
[70841.001483]  ? __slab_alloc.isra.24.constprop.29+0x62/0x70
[70841.001491]  ? __kmalloc+0x1f5/0x320
[70841.001497]  __kmem_cache_shutdown+0x18b/0x400
[70841.001505]  shutdown_cache+0x13/0x1c0
[70841.001511]  kmem_cache_destroy+0x1c2/0x240
[70841.001517]  ? __mutex_unlock_slowpath+0x38/0x270
[70841.001559]  i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.001595]  i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.001630]  i915_driver_load+0x708/0x1720 [i915]
[70841.001638]  ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.001673]  i915_pci_probe+0x2d/0x90 [i915]
[70841.001680]  pci_device_probe+0x9c/0x120
[70841.001687]  driver_probe_device+0x2a9/0x490
[70841.001694]  __driver_attach+0xd9/0xe0
[70841.001700]  ? driver_probe_device+0x490/0x490
[70841.001705]  bus_for_each_dev+0x57/0x90
[70841.001712]  bus_add_driver+0x1eb/0x260
[70841.001717]  ? 0xa0685000
[70841.001723]  driver_register+0x52/0xc0
[70841.001728]  ? 0xa0685000
[70841.001733]  do_one_initcall+0x39/0x170
[70841.001739]  ? rcu_read_lock_sched_held+0x6f/0x80
[70841.001746]  ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.001753]  do_init_module+0x56/0x1ec
[70841.001759]  load_module+0x219e/0x2550
[70841.001766]  ? vfs_read+0x121/0x140
[70841.001774]  ? SyS_finit_module+0xa5/0xe0
[70841.001779]  SyS_finit_module+0xa5/0xe0
[70841.001788]  entry_SYSCALL_64_fastpath+0x22/0x8f

[70841.001806] INFO: Object 0xeab7ed96 @offset=6208
[70841.001850] INFO: Allocated in i915_gem_object_create.part.32+0x1f/0x260 
[i915] age=38 cpu=0 pid=2708
[70841.001861]  kmem_cache_alloc+0x23d/0x2d0
[70841.001897]  i915_gem_object_create.part.32+0x1f/0x260 [i915]
[70841.001937]  intel_guc_allocate_vma+0x15/0x100 [i915]
[70841.001977]  intel_guc_log_create+0x34/0x1c0 [i915]
[70841.002014]  intel_guc_init+0x5a/0x100 [i915]
[70841.002051]  intel_uc_init+0x3e/0xb0 [i915]
[70841.002089]  i915_gem_init+0x18e/0x540 [i915]
[70841.002123]  i915_driver_load+0xa7a/0x1720 [i915]
[70841.002159]  i915_pci_probe+0x2d/0x90 [i915]
[70841.002165]  pci_device_probe+0x9c/0x120
[70841.002171]  driver_probe_device+0x2a9/0x490
[70841.002177]  __driver_attach+0xd9/0xe0
[70841.002182]  bus_for_each_dev+0x57/0x90
[70841.002188]  bus_add_driver+0x1eb/0x260
[70841.002193]  driver_register+0x52/0xc0
[70841.002198]  do_one_initcall+0x39/0x170
[70841.002462] kmem_cache_destroy drm_i915_gem_object: Slab cache still has 
objects

[70841.002491] Call Trace:
[70841.002497]  dump_stack+0x5e/0x8e
[70841.002503]  kmem_cache_destroy+0x1e0/0x240
[70841.002509]  ? __mutex_unlock_slowpath+0x38/0x270
[70841.002551]  i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.002586]  i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.002621]  i915_driver_load+0x708/0x1720 [i915]
[70841.002629]  ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.002664]  i915_pci_probe+0x2d/0x90 [i915]
[70841.002671]  pci_device_probe+0x9c/0x120
[70841.002678]  driver_probe_device+0x2a9/0x490
[70841.002684]  __driver_attach+0xd9/0xe0
[70841.002690]  ? driver_probe_device+0x490/0x490
[70841.002696]  bus_for_each_dev+0x57/0x90
[70841.002702]  bus_add_driver+0x1eb/0x260
[70841.002708]  ? 0xa0685000
[70841.002713]  driver_register+0x52/0xc0
[70841.002719]  ? 0xa0685000
[70841.002724]  do_one_initcall+0x39/0x170
[70841.002731]  ? rcu_read_lock_sched_held+0x6f/0x80
[70841.002737]  ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.002745]  do_init_module+0x56/0x1ec
[70841.002751]  load_module+0x219e/0x2550
[70841.002758]  ? vfs_read+0x121/0x140
[70841.002766]  ? SyS_finit_module+0xa5/0xe0
[70841.002772]  SyS_finit_module+0xa5/0xe0
[70841.002781]  entry_SYSCALL_64_fastpath+0x22/0x8f

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2f80cab..3a13cbb 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -27,6 +27,8 @@
 #include "intel_guc.h"
 #include "i915_drv.h"
 
+static void 

[Intel-gfx] [PATCH 1/5] drm/i915/uc: Add few more load failure checkpoints

[Michal Wajdeczko]

Additional load failure checkpoints added into uC initialization
sequence should help us verify correctness of error handling.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e3f3509..2f80cab 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -287,6 +287,9 @@ int intel_uc_init(struct drm_i915_private *dev_priv)
if (!HAS_GUC(dev_priv))
return -ENODEV;
 
+   if (i915_inject_load_failure())
+   return -ENODEV;
+
ret = intel_guc_init(guc);
if (ret)
return ret;
@@ -330,6 +333,11 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (!USES_GUC(dev_priv))
return 0;
 
+   if (i915_inject_load_failure()) {
+   ret = -ECANCELED;
+   goto err_out;
+   }
+
GEM_BUG_ON(!HAS_GUC(dev_priv));
 
guc_disable_communication(guc);
@@ -371,6 +379,9 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 "retry %d more time(s)\n", ret, attempts);
}
 
+   if (i915_inject_load_failure())
+   ret = -ECANCELED;
+
/* Did we succeded or run out of retries? */
if (ret)
goto err_log_capture;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-31 17:18:55)
> 
> On 22/01/2018 15:41, Chris Wilson wrote:
> > +static void __intel_engine_remove_signal(struct intel_engine_cs *engine,
> > +  struct drm_i915_gem_request *request)
> > +{
> > + struct intel_breadcrumbs *b = >breadcrumbs;
> > +
> > + lockdep_assert_held(>rb_lock);
> > +
> > + /*
> > +  * Wake up all other completed waiters and select the
> > +  * next bottom-half for the next user interrupt.
> > +  */
> > + __intel_engine_remove_wait(engine, >signaling.wait);
> > +
> > + /*
> > +  * Find the next oldest signal. Note that as we have
> > +  * not been holding the lock, another client may
> 
> Which lock, request-lock? b->first_signal seems to always be updated 
> under the b->rb_lock, so I am not sure of the 
> request->signaling.wait.seqno check.
> 
> wait.seqno is also updated without the request->lock below, so maybe you 
> were talking about the rb_lock after all?

What it means here is that since we took b->first_signal without
holding the rb_lock, by the time we get to here (and have taken the
rb_lock) b->first_signal may have changed and indeed someone else may
have already retired the request and canceled the signaling. Or inserted
a new signal into the tree. (iirc, this comment is unmodified.)
 
> How does wait.seqno becomes 0 outside the rb_lock? Is it due RCU 
> business this patch adds? Like it is retired before the signaler runs?

Not outside of the rb_lock, just before we notice.
 
> > +  * have installed an even older signal than the one
> > +  * we just completed - so double check we are still
> > +  * the oldest before picking the next one.
> > +  */
> > + if (request->signaling.wait.seqno) {
> > + if (request == rcu_access_pointer(b->first_signal)) {
> > + struct rb_node *rb = 
> > rb_next(>signaling.node);
> > + rcu_assign_pointer(b->first_signal,
> > +rb ? to_signaler(rb) : NULL);
> > + }
> > +
> > + rb_erase(>signaling.node, >signals);
> > + request->signaling.wait.seqno = 0;
> > + }
> > +}
> > +
> > +static struct drm_i915_gem_request *first_signal(struct intel_breadcrumbs 
> > *b)
> > +{
> > + /*
> > +  * See the big warnings for i915_gem_active_get_rcu() and similarly
> > +  * for dma_fence_get_rcu_safe() that explain the intricacies involved
> > +  * here with defeating CPU/compiler speculation and enforcing
> > +  * the required memory barriers.
> > +  */
> > + do {
> > + struct drm_i915_gem_request *request;
> > +
> > + request = rcu_dereference(b->first_signal);
> > + if (request)
> > + request = i915_gem_request_get_rcu(request);
> > +
> > + barrier();
> > +
> > + if (!request || request == 
> > rcu_access_pointer(b->first_signal))
> > + return rcu_pointer_handoff(request);
> > +
> > + i915_gem_request_put(request);
> > + } while (1);
> > +}
> > +
> >   static int intel_breadcrumbs_signaler(void *arg)
> >   {
> >   struct intel_engine_cs *engine = arg;
> > @@ -667,41 +715,21 @@ static int intel_breadcrumbs_signaler(void *arg)
> >* a new client.
> >*/
> >   rcu_read_lock();
> > - request = rcu_dereference(b->first_signal);
> > - if (request)
> > - request = i915_gem_request_get_rcu(request);
> > + request = first_signal(b);
> 
> get_ prefix would be good to signify a get vs peek. Maybe even _rcu suffix.

Sold.

> >   rcu_read_unlock();
> >   if (signal_complete(request)) {
> > - local_bh_disable();
> > - dma_fence_signal(>fence);
> > - local_bh_enable(); /* kick start the tasklets */
> > -
> > - spin_lock_irq(>rb_lock);
> > -
> > - /* Wake up all other completed waiters and select the
> > -  * next bottom-half for the next user interrupt.
> > -  */
> > - __intel_engine_remove_wait(engine,
> > ->signaling.wait);
> > -
> > - /* Find the next oldest signal. Note that as we have
> > -  * not been holding the lock, another client may
> > -  * have installed an even older signal than the one
> > -  * we just completed - so double check we are still
> > -  * the oldest before picking the next one.
> > -  */
> > - if (request == rcu_access_pointer(b->first_signal)) {
> > - struct rb_node *rb =
> > - rb_next(>signaling.node);
> > -

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Tvrtko Ursulin]

On 22/01/2018 15:41, Chris Wilson wrote:

If we remember to cancel the signaler on a request when retiring it
(after we know that the request has been signaled), we do not need to
carry an additional request in the signaler itself. This prevents an
issue whereby the signaler threads may be delayed and hold on to
thousands of request references, causing severe memory fragmentation and
premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL
and frequent use of inter-engine fences).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem_request.c  |   6 +-
  drivers/gpu/drm/i915/intel_breadcrumbs.c | 149 +--
  2 files changed, 85 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a0f451b4a4e8..e4eca6ba0d05 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -441,7 +441,10 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
spin_lock_irq(>lock);
if (request->waitboost)
atomic_dec(>i915->gt_pm.rps.num_waiters);
-   dma_fence_signal_locked(>fence);
+   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+   dma_fence_signal_locked(>fence);
+   if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+   intel_engine_cancel_signaling(request);
spin_unlock_irq(>lock);
  
  	i915_priotree_fini(request->i915, >priotree);

@@ -738,6 +741,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
  
  	/* No zalloc, must clear what we need by hand */

req->global_seqno = 0;
+   req->signaling.wait.seqno = 0;
req->file_priv = NULL;
req->batch = NULL;
req->capture_list = NULL;
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 86acac010bb8..e3667dc1e96d 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -235,7 +235,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs 
*engine)
struct intel_wait *wait, *n;
  
  	if (!b->irq_armed)

-   goto wakeup_signaler;
+   return;
  
  	/*

 * We only disarm the irq when we are idle (all requests completed),
@@ -260,14 +260,6 @@ void intel_engine_disarm_breadcrumbs(struct 
intel_engine_cs *engine)
b->waiters = RB_ROOT;
  
  	spin_unlock_irq(>rb_lock);

-
-   /*
-* The signaling thread may be asleep holding a reference to a request,
-* that had its signaling cancelled prior to being preempted. We need
-* to kick the signaler, just in case, to release any such reference.
-*/
-wakeup_signaler:
-   wake_up_process(b->signaler);
  }
  
  static bool use_fake_irq(const struct intel_breadcrumbs *b)

@@ -644,6 +636,62 @@ static void signaler_set_rtpriority(void)
 sched_setscheduler_nocheck(current, SCHED_FIFO, );
  }
  
+static void __intel_engine_remove_signal(struct intel_engine_cs *engine,

+struct drm_i915_gem_request *request)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   lockdep_assert_held(>rb_lock);
+
+   /*
+* Wake up all other completed waiters and select the
+* next bottom-half for the next user interrupt.
+*/
+   __intel_engine_remove_wait(engine, >signaling.wait);
+
+   /*
+* Find the next oldest signal. Note that as we have
+* not been holding the lock, another client may


Which lock, request-lock? b->first_signal seems to always be updated 
under the b->rb_lock, so I am not sure of the 
request->signaling.wait.seqno check.


wait.seqno is also updated without the request->lock below, so maybe you 
were talking about the rb_lock after all?


How does wait.seqno becomes 0 outside the rb_lock? Is it due RCU 
business this patch adds? Like it is retired before the signaler runs?



+* have installed an even older signal than the one
+* we just completed - so double check we are still
+* the oldest before picking the next one.
+*/
+   if (request->signaling.wait.seqno) {
+   if (request == rcu_access_pointer(b->first_signal)) {
+   struct rb_node *rb = rb_next(>signaling.node);
+   rcu_assign_pointer(b->first_signal,
+  rb ? to_signaler(rb) : NULL);
+   }
+
+   rb_erase(>signaling.node, >signals);
+   request->signaling.wait.seqno = 0;
+   }
+}
+
+static struct drm_i915_gem_request *first_signal(struct intel_breadcrumbs *b)
+{
+   /*
+* See the big warnings for i915_gem_active_get_rcu() and similarly
+* for dma_fence_get_rcu_safe() that explain the intricacies involved
+  

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/7] drm/i915: Don't set cursor pipe select bits on g4x+ (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Don't set cursor pipe select bits 
on g4x+ (rev2)
URL   : https://patchwork.freedesktop.org/series/37362/
State : success

== Summary ==

Test perf_pmu:
Subgroup semaphore-wait-bcs0:
fail   -> PASS   (shard-apl) fdo#104829
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

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

shard-apltotal:2838 pass:1749 dwarn:1   dfail:0   fail:23  skip:1064 
time:12633s
shard-hswtotal:2838 pass:1736 dwarn:1   dfail:0   fail:10  skip:1090 
time:11990s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6629s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7839/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"

[Lionel Landwerlin]

On 31/01/18 02:15, Rodrigo Vivi wrote:

On Tue, Jan 30, 2018 at 08:44:46AM +, Jani Nikula wrote:

On Mon, 29 Jan 2018, Jani Nikula  wrote:

On Mon, 29 Jan 2018, Lionel Landwerlin  wrote:

On 29/01/18 09:02, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-01-29 08:33:46)

This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.

   Conflicts:
  drivers/gpu/drm/i915/i915_pci.c

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

Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with __initconst")

So it ends up in the right place.
-Chris


Thanks, pushed.

Please *always* wait for the full IGT results before pushing.

Please *always* include a self-contained reason *why* in the commit
message instead of relying on Bugzilla: link only.

Please run 'dim fixes ' to get the proper tags; now Cc: stable
is missing. Fixes: alone doesn't cut it now that v4.15 has been
released.

Rodrigo, please pick this up to drm-intel-next-fixes.

This particular one conflicted with the icl ones:

++<<< HEAD
++===
+ #define GEN11_FEATURES \
+   GEN10_FEATURES, \
+   .gen = 11, \
+   .ddb_size = 2048, \
+   .has_csr = 0
+
+ static const struct intel_device_info intel_icelake_11_info = {
+   GEN11_FEATURES,
+   .platform = INTEL_ICELAKE,
+   .is_alpha_support = 1,
+   .has_resource_streamer = 0,
+ };
+
++>>> 5db47e37b387... Revert "drm/i915: mark all device info struct with 
__initconst"

So I'm assuming it is just a matter to remember to fix the next confclit 
removing initconst from icl?


Yep, sorry for the conflict.



Thanks for this and all other heads up.


BR,
Jani.



No patch needs to be merged within an hour. There's never such a
rush. Please let's give more people a chance to look at the patches
before they get merged.


Thanks,
Jani.



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

--
Jani Nikula, Intel Open Source Technology Center



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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL 
(rev2)
URL   : https://patchwork.freedesktop.org/series/37395/
State : success

== Summary ==

Test perf_pmu:
Subgroup semaphore-wait-bcs0:
fail   -> PASS   (shard-apl) fdo#104829
Test gem_eio:
Subgroup in-flight-suspend:
pass   -> FAIL   (shard-hsw) fdo#104676

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

shard-apltotal:1638 pass:1017 dwarn:1   dfail:0   fail:16  skip:604 
time:7460s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:11  skip:1090 
time:11932s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6594s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7838/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Micro-optimize sampling loop

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Micro-optimize sampling loop
URL   : https://patchwork.freedesktop.org/series/37420/
State : success

== Summary ==

Series 37420v1 drm/i915/pmu: Micro-optimize sampling loop
https://patchwork.freedesktop.org/api/1.0/series/37420/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:450s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:446s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:523s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:520s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

badc0398a06018a07f6f50a1ff5a5fd8a30b9944 drm-tip: 2018y-01m-31d-12h-17m-12s UTC 
integration manifest
ef8f136b87be drm/i915/pmu: Micro-optimize sampling loop

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7840/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915/pmu: Micro-optimize sampling loop

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-31 16:02:38)
> From: Tvrtko Ursulin 
> 
> By carefully chosing slightly unsynchronized values for timer frequency
> and period, we can remove the multiplications from the sampling loop and
> replace them with shifts only.
> 
> Downside is that the counter read callback now has to do a divide with a
> non-power-of-two, but the rationale is that sampling loop which runs at
> ~200 Hz, multiplied by number of engines, is more important than less
> frequent counter read-out. Furthermore, the divide in counter read-out
> seems to be optimized by the compiler to some shifts and multiply.
> 
> We can only do all this at the expense of introducing a systematic error
> to the sampling counters to the amount of 0.18%. At the same time we are
> increasing the sampling rate from 200 to 238 Hz which may cancel some of
> this out.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> ---
> Motivated by Chris' insisting to use power-of-two scale factor in the
> engine queue depth PMU series. I was actually reluctant to give in there
> so this is even more questionable. :)
> 
> I have no idea if it is cheaper to run the sampling timer at 200Hz with
> some multiplies, or run it at 238Hz with only shifts.

I can't say I have any insight into the timer wheel or hrtimer either.
Let's watch.

> FWIW 0.18% systematic error at least doesn't sound like a big deal when
> sampling counters are concerned.

Yeah, since even pinning it down to a 5% systematic error is hard, but
we'll see if this 0.18% is the straw that breaks CI back!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] drm/i915/pmu: Micro-optimize sampling loop

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

By carefully chosing slightly unsynchronized values for timer frequency
and period, we can remove the multiplications from the sampling loop and
replace them with shifts only.

Downside is that the counter read callback now has to do a divide with a
non-power-of-two, but the rationale is that sampling loop which runs at
~200 Hz, multiplied by number of engines, is more important than less
frequent counter read-out. Furthermore, the divide in counter read-out
seems to be optimized by the compiler to some shifts and multiply.

We can only do all this at the expense of introducing a systematic error
to the sampling counters to the amount of 0.18%. At the same time we are
increasing the sampling rate from 200 to 238 Hz which may cancel some of
this out.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
Motivated by Chris' insisting to use power-of-two scale factor in the
engine queue depth PMU series. I was actually reluctant to give in there
so this is even more questionable. :)

I have no idea if it is cheaper to run the sampling timer at 200Hz with
some multiplies, or run it at 238Hz with only shifts.

FWIW 0.18% systematic error at least doesn't sound like a big deal when
sampling counters are concerned.
---
 drivers/gpu/drm/i915/i915_pmu.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 3e1edc26f252..af732c086b86 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -29,9 +29,19 @@
 #include "i915_pmu.h"
 #include "intel_ringbuffer.h"
 
-/* Frequency for the sampling timer for events which need it. */
-#define FREQUENCY 200
-#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY)
+/*
+ * Frequency for the sampling timer for events which need it.
+ *
+ * The relationship between frequency and period is:
+ *   PERIOD(ns) = 1e9 / FREQUENCY(Hz)
+ *
+ * We set the period to a power-of-two value 0x40 for simpler computations
+ * inside the sampling timer, at the expense of introducting a systematic error
+ * of 0.18%. This is caused by frequency (using as divisor for reading out
+ * certain counters) being rounded to 238, while 1e9 / 0x40 = 
238.418579102.
+ */
+#define FREQUENCY 238
+#define PERIOD 0x40
 
 #define ENGINE_SAMPLE_MASK \
(BIT(I915_SAMPLE_BUSY) | \
-- 
2.14.1

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

Re: [Intel-gfx] [PULL] drm-misc-fixes

[Gustavo Padovan]

So I've made an error when sending this out, it includes some stuff
that is already on 4.15. Sorry about that, the only one that is needs
to go in is this one:

 Daniel Vetter (1):
   drm/cirrus: Load lut in crtc_commit

The pull request is fine, just the generated e-mail is wrong.

Thanks!

2018-01-31 Gustavo Padovan :

> Hi Dave,
> 
> This one got applied late to drm-misc-fixes, it should go to 4.16
> anyway. Please pull, Thanks.
> 
> Gustavo
> 
> drm-misc-fixes-2018-01-31:
> - fix lut loading for cirrus
> The following changes since commit a8750ddca918032d6349adbf9a4b6555e7db20da:
> 
>   Linux 4.15-rc8 (2018-01-14 15:32:30 -0800)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-01-31
> 
> for you to fetch changes up to 745fd50f3b044db6a3922e1718306555613164b0:
> 
>   drm/cirrus: Load lut in crtc_commit (2018-01-31 13:14:33 +0100)
> 
> 
> - fix lut loading for cirrus
> 
> 
> Boris Brezillon (1):
>   drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
> 
> Daniel Vetter (1):
>   drm/cirrus: Load lut in crtc_commit
> 
> Dave Airlie (2):
>   Merge branch 'vmwgfx-fixes-4.15' of 
> git://people.freedesktop.org/~thomash/linux into drm-fixes
>   Merge tag 'drm-misc-fixes-2018-01-17' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
> 
> Eric Anholt (1):
>   drm/vc4: Flush the caches before the bin jobs, as well.
> 
> Jonathan Liu (3):
>   drm/sun4i: hdmi: Check for unset best_parent in 
> sun4i_tmds_determine_rate
>   drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate
>   drm/sun4i: hdmi: Add missing rate halving check in 
> sun4i_tmds_determine_rate
> 
> Rob Clark (1):
>   drm/vmwgfx: fix memory corruption with legacy/sou connectors
> 
> Woody Suwalski (1):
>   drm/vmwgfx: Fix a boot time warning
> 
>  drivers/gpu/drm/cirrus/cirrus_mode.c| 40 
> +
>  drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c |  9 ---
>  drivers/gpu/drm/vc4/vc4_gem.c   | 33 +++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  4 +--
>  6 files changed, 61 insertions(+), 31 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Only allocate preempt context when required

[Chris Wilson]

Quoting Mika Kuoppala (2018-01-31 14:38:02)
> > @@ -1988,6 +1988,11 @@ static int logical_ring_init(struct intel_engine_cs 
> > *engine)
> >   engine->execlists.elsp =
> >   engine->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));
> >  
> > + engine->execlists.preempt_complete_status = ~0u;
> 
> This is to ensure that we catch a rogue status? Atleast we will
> bug on of preempting with this status as the EXECLIST_ACTIVE_PREEMPT
> will be false.

0 is the value for the i915->kernel_context. ~0u is currently invalid
and that looks to be the case (that at least it will never match an
active context) for the near future.

> > + if (engine->i915->preempt_context)
> > + engine->execlists.preempt_complete_status =
> > + 
> > upper_32_bits(engine->i915->preempt_context->engine[engine->id].lrc_desc);
> 
> 
> We have not upgraded the descriptor yet, so just use preempt_context->hw_id;

The upper_32_bits should be set; and I think it is important that the
usage is consistent. If we change the upper_32_bits later, we should try
to remember to update the preempt_complete_status. I.e. I feel it is
vital to remember that the complete_status is the
upper_32_bits(lrc_desc) that just happens to be hw_id due to our limited
definition today.

> I would also like duplicate, from i915_gem_context.c, the assertion that
> hw_id needs to be <= INT_MAX but didn't find a good spot.

For what purpose? When defining lrc_desc checking that hw_id fits within
the field width would be sensible.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-fixes

[Gustavo Padovan]

Hi Dave,

This one got applied late to drm-misc-fixes, it should go to 4.16
anyway. Please pull, Thanks.

Gustavo

drm-misc-fixes-2018-01-31:
- fix lut loading for cirrus
The following changes since commit a8750ddca918032d6349adbf9a4b6555e7db20da:

  Linux 4.15-rc8 (2018-01-14 15:32:30 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-01-31

for you to fetch changes up to 745fd50f3b044db6a3922e1718306555613164b0:

  drm/cirrus: Load lut in crtc_commit (2018-01-31 13:14:33 +0100)


- fix lut loading for cirrus


Boris Brezillon (1):
  drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()

Daniel Vetter (1):
  drm/cirrus: Load lut in crtc_commit

Dave Airlie (2):
  Merge branch 'vmwgfx-fixes-4.15' of 
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2018-01-17' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Eric Anholt (1):
  drm/vc4: Flush the caches before the bin jobs, as well.

Jonathan Liu (3):
  drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
  drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate
  drm/sun4i: hdmi: Add missing rate halving check in 
sun4i_tmds_determine_rate

Rob Clark (1):
  drm/vmwgfx: fix memory corruption with legacy/sou connectors

Woody Suwalski (1):
  drm/vmwgfx: Fix a boot time warning

 drivers/gpu/drm/cirrus/cirrus_mode.c| 40 +
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c |  9 ---
 drivers/gpu/drm/vc4/vc4_gem.c   | 33 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  4 +--
 6 files changed, 61 insertions(+), 31 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-next-fixes

[Gustavo Padovan]

Hi Dave,

two fixes for the 4.16 cycle from the drm-misc-next-fixes.

drm-misc-next-fixes-2018-01-31:
This contains a fix to restrict what lessee can do with masters and
another one when waiting for timeouts on reservation objects.
The following changes since commit 341a0ffceaa44660c43d219a3b2569ebbd7d3ad1:

  drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig 
(2018-01-17 10:10:18 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-01-31

for you to fetch changes up to 761e05a702f5d537ffcca1ba933f9f0a968aa022:

  drm: Check for lessee in DROP_MASTER ioctl (2018-01-31 09:27:51 +0100)


This contains a fix to restrict what lessee can do with masters and
another one when waiting for timeouts on reservation objects.


Christian König (1):
  dma-buf: fix reservation_object_wait_timeout_rcu once more v2

Keith Packard (1):
  drm: Check for lessee in DROP_MASTER ioctl

 drivers/dma-buf/reservation.c | 8 +---
 drivers/gpu/drm/drm_auth.c| 6 ++
 2 files changed, 11 insertions(+), 3 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Don't set cursor pipe select bits on g4x+ (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/7] drm/i915: Don't set cursor pipe select bits 
on g4x+ (rev2)
URL   : https://patchwork.freedesktop.org/series/37362/
State : success

== Summary ==

Series 37362v2 series starting with [1/7] drm/i915: Don't set cursor pipe 
select bits on g4x+
https://patchwork.freedesktop.org/api/1.0/series/37362/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104162
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:109  pass:105  dwarn:0   dfail:0   fail:0   skip:3  
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:490s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:478s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:471s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:463s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:417s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s

badc0398a06018a07f6f50a1ff5a5fd8a30b9944 drm-tip: 2018y-01m-31d-12h-17m-12s UTC 
integration manifest
a6b40df641b0 drm/i915: s/plane/i9xx_plane/
309c54212a22 drm/i915: Drop WaDoubleCursorLP3Latency:ivb
ab266dd84d7a drm/i915: Disable trickle feed for SNB/IVB cursors
45da2273b46f drm/i915: Clean up cursor defines
8948a9152607 drm/i915: Have plane->get_hw_state() return the current pipe
db3c2d0815ab drm/i915: Set the primary plane pipe select bits on gen4
45bad81fbb4c drm/i915: Don't set cursor pipe select bits on g4x+

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7839/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Only allocate preempt context when required

[Mika Kuoppala]

Chris Wilson  writes:

> If we remove some hardcoded assumptions about the preempt context having
> a fixed id, reserved from use by normal user contexts, we may only
> allocate the i915_gem_context when required. Then the subsequent
> decisions on using preemption reduce to having the preempt context
> available.
>
> Signed-off-by: Chris Wilson 
> Cc: Michal Winiarski 
> Cc: Tvrtko Ursulin 
> Cc: Arkadiusz Hiler 
> Cc: Mika Kuoppala 
> Cc: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/i915_gem_context.c  | 29 
> 
>  drivers/gpu/drm/i915/intel_engine_cs.c   |  6 ++---
>  drivers/gpu/drm/i915/intel_guc_submission.c  | 24 +++-
>  drivers/gpu/drm/i915/intel_lrc.c | 17 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.h  |  5 
>  drivers/gpu/drm/i915/selftests/mock_gem_device.c |  6 -
>  6 files changed, 46 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 648e7536ff51..d69c8f1a4e78 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -449,10 +449,14 @@ destroy_kernel_context(struct i915_gem_context **ctxp)
>   i915_gem_context_free(ctx);
>  }
>  
> +static bool needs_preempt_context(struct drm_i915_private *i915)
> +{
> + return HAS_LOGICAL_RING_PREEMPTION(i915);
> +}
> +
>  int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
>  {
>   struct i915_gem_context *ctx;
> - int err;
>  
>   GEM_BUG_ON(dev_priv->kernel_context);

Please consider adding
GEM_BUG_ON(dev_priv->preempt_context);

here even tho the kernel_context should act as a master guard for init ordering
errors. Even if no other than documenting that we expect a clean slate
in this regard also.

>  
> @@ -468,8 +472,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
> *dev_priv)
>   ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_MIN);
>   if (IS_ERR(ctx)) {
>   DRM_ERROR("Failed to create default global context\n");
> - err = PTR_ERR(ctx);
> - goto err;
> + return PTR_ERR(ctx);
>   }
>   /*
>* For easy recognisablity, we want the kernel context to be 0 and then
> @@ -479,23 +482,18 @@ int i915_gem_contexts_init(struct drm_i915_private 
> *dev_priv)
>   dev_priv->kernel_context = ctx;
>  
>   /* highest priority; preempting task */
> - ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX);
> - if (IS_ERR(ctx)) {
> - DRM_ERROR("Failed to create default preempt context\n");
> - err = PTR_ERR(ctx);
> - goto err_kernel_context;

It seems this error path has been wrong all along.

> + if (needs_preempt_context(dev_priv)) {
> + ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX);
> + if (!IS_ERR(ctx))
> + dev_priv->preempt_context = ctx;
> + else
> + DRM_ERROR("Failed to create preempt context; disabling 
> preemption\n");
>   }
> - dev_priv->preempt_context = ctx;
>  
>   DRM_DEBUG_DRIVER("%s context support initialized\n",
>dev_priv->engine[RCS]->context_size ? "logical" :
>"fake");
>   return 0;
> -
> -err_kernel_context:
> - destroy_kernel_context(_priv->kernel_context);
> -err:
> - return err;
>  }
>  
>  void i915_gem_contexts_lost(struct drm_i915_private *dev_priv)
> @@ -521,7 +519,8 @@ void i915_gem_contexts_fini(struct drm_i915_private *i915)
>  {
>   lockdep_assert_held(>drm.struct_mutex);
>  
> - destroy_kernel_context(>preempt_context);
> + if (i915->preempt_context)
> + destroy_kernel_context(>preempt_context);
>   destroy_kernel_context(>kernel_context);
>  
>   /* Must free all deferred contexts (via flush_workqueue) first */
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 7eebfbb95e89..bf634432c9c6 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -631,7 +631,7 @@ int intel_engine_init_common(struct intel_engine_cs 
> *engine)
>* Similarly the preempt context must always be available so that
>* we can interrupt the engine at any time.
>*/
> - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) {
> + if (engine->i915->preempt_context) {
>   ring = engine->context_pin(engine,
>  engine->i915->preempt_context);
>   if (IS_ERR(ring)) {
> @@ -656,7 +656,7 @@ int intel_engine_init_common(struct intel_engine_cs 
> *engine)
>  err_breadcrumbs:
>   

[Intel-gfx] [PATCH v2 4/7] drm/i915: Clean up cursor defines

[Ville Syrjala]

From: Ville Syrjälä 

Use MCURSOR_ instead of CURSOR_ as the prefix for the non-845/865
cursor defines consistently, and move the pipe CSC enable bit next
to the other non-845/865 cursor defines.

v2: Take care of gvt uses as well

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gvt/fb_decoder.c | 12 ++--
 drivers/gpu/drm/i915/i915_reg.h   | 22 +++---
 drivers/gpu/drm/i915/intel_display.c  | 16 
 3 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c 
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
index 6b50fe78dc1b..73c0c2096a62 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -303,16 +303,16 @@ static int cursor_mode_to_drm(int mode)
int cursor_pixel_formats_index = 4;
 
switch (mode) {
-   case CURSOR_MODE_128_ARGB_AX:
+   case MCURSOR_MODE_128_ARGB_AX:
cursor_pixel_formats_index = 0;
break;
-   case CURSOR_MODE_256_ARGB_AX:
+   case MCURSOR_MODE_256_ARGB_AX:
cursor_pixel_formats_index = 1;
break;
-   case CURSOR_MODE_64_ARGB_AX:
+   case MCURSOR_MODE_64_ARGB_AX:
cursor_pixel_formats_index = 2;
break;
-   case CURSOR_MODE_64_32B_AX:
+   case MCURSOR_MODE_64_32B_AX:
cursor_pixel_formats_index = 3;
break;
 
@@ -345,8 +345,8 @@ int intel_vgpu_decode_cursor_plane(struct intel_vgpu *vgpu,
return -ENODEV;
 
val = vgpu_vreg_t(vgpu, CURCNTR(pipe));
-   mode = val & CURSOR_MODE;
-   plane->enabled = (mode != CURSOR_MODE_DISABLE);
+   mode = val & MCURSOR_MODE;
+   plane->enabled = (mode != MCURSOR_MODE_DISABLE);
if (!plane->enabled)
return -ENODEV;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ebb41f279134..dbcb4de92a63 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5891,7 +5891,6 @@ enum {
 #define   CURSOR_GAMMA_ENABLE  0x4000
 #define   CURSOR_STRIDE_SHIFT  28
 #define   CURSOR_STRIDE(x) ((ffs(x)-9) << CURSOR_STRIDE_SHIFT) /* 
256,512,1k,2k */
-#define   CURSOR_PIPE_CSC_ENABLE (1<<24)
 #define   CURSOR_FORMAT_SHIFT  24
 #define   CURSOR_FORMAT_MASK   (0x07 << CURSOR_FORMAT_SHIFT)
 #define   CURSOR_FORMAT_2C (0x00 << CURSOR_FORMAT_SHIFT)
@@ -5900,20 +5899,21 @@ enum {
 #define   CURSOR_FORMAT_ARGB   (0x04 << CURSOR_FORMAT_SHIFT)
 #define   CURSOR_FORMAT_XRGB   (0x05 << CURSOR_FORMAT_SHIFT)
 /* New style CUR*CNTR flags */
-#define   CURSOR_MODE  0x27
-#define   CURSOR_MODE_DISABLE   0x00
-#define   CURSOR_MODE_128_32B_AX 0x02
-#define   CURSOR_MODE_256_32B_AX 0x03
-#define   CURSOR_MODE_64_32B_AX 0x07
-#define   CURSOR_MODE_128_ARGB_AX ((1 << 5) | CURSOR_MODE_128_32B_AX)
-#define   CURSOR_MODE_256_ARGB_AX ((1 << 5) | CURSOR_MODE_256_32B_AX)
-#define   CURSOR_MODE_64_ARGB_AX ((1 << 5) | CURSOR_MODE_64_32B_AX)
+#define   MCURSOR_MODE 0x27
+#define   MCURSOR_MODE_DISABLE   0x00
+#define   MCURSOR_MODE_128_32B_AX 0x02
+#define   MCURSOR_MODE_256_32B_AX 0x03
+#define   MCURSOR_MODE_64_32B_AX 0x07
+#define   MCURSOR_MODE_128_ARGB_AX ((1 << 5) | MCURSOR_MODE_128_32B_AX)
+#define   MCURSOR_MODE_256_ARGB_AX ((1 << 5) | MCURSOR_MODE_256_32B_AX)
+#define   MCURSOR_MODE_64_ARGB_AX ((1 << 5) | MCURSOR_MODE_64_32B_AX)
 #define   MCURSOR_PIPE_SELECT_MASK (0x3 << 28)
 #define   MCURSOR_PIPE_SELECT_SHIFT28
 #define   MCURSOR_PIPE_SELECT(pipe)((pipe) << 28)
 #define   MCURSOR_GAMMA_ENABLE  (1 << 26)
-#define   CURSOR_ROTATE_180(1<<15)
-#define   CURSOR_TRICKLE_FEED_DISABLE  (1 << 14)
+#define   MCURSOR_PIPE_CSC_ENABLE (1<<24)
+#define   MCURSOR_ROTATE_180   (1<<15)
+#define   MCURSOR_TRICKLE_FEED_DISABLE (1 << 14)
 #define _CURABASE  0x70084
 #define _CURAPOS   0x70088
 #define   CURSOR_POS_MASK   0x007FF
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index feae6bd51a44..0cf02f226fd4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9549,20 +9549,20 @@ static u32 i9xx_cursor_ctl(const struct 
intel_crtc_state *crtc_state,
cntl = MCURSOR_GAMMA_ENABLE;
 
if (HAS_DDI(dev_priv))
-   cntl |= CURSOR_PIPE_CSC_ENABLE;
+   cntl |= MCURSOR_PIPE_CSC_ENABLE;
 
if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv))
cntl |= MCURSOR_PIPE_SELECT(crtc->pipe);
 
switch (plane_state->base.crtc_w) {
case 64:
-   cntl |= CURSOR_MODE_64_ARGB_AX;
+   cntl |= MCURSOR_MODE_64_ARGB_AX;
break;
case 128:
-   cntl |= CURSOR_MODE_128_ARGB_AX;
+   cntl |= MCURSOR_MODE_128_ARGB_AX;
break;
case 256:
-   

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/ast: Load lut in crtc_commit

[Patchwork]

== Series Details ==

Series: drm/ast: Load lut in crtc_commit
URL   : https://patchwork.freedesktop.org/series/37398/
State : failure

== Summary ==

Test perf_pmu:
Subgroup most-busy-check-all-vecs0:
incomplete -> PASS   (shard-apl)
Test kms_flip:
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup 2x-dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Test gem_eio:
Subgroup in-flight-suspend:
pass   -> FAIL   (shard-hsw) fdo#104676

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676

shard-apltotal:1321 pass:823  dwarn:1   dfail:0   fail:11  skip:486 
time:6183s
shard-hswtotal:2838 pass:1733 dwarn:1   dfail:0   fail:13  skip:1090 
time:11938s
shard-snbtotal:2838 pass:1328 dwarn:1   dfail:0   fail:11  skip:1498 
time:6572s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7837/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Drop WaDoubleCursorLP3Latency:ivb

[Mika Kahola]

On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> WaDoubleCursorLP3Latency was meant for pre-production hardware.
> Drop it.
> 
Reviewed-by: Mika Kahola 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 0b92ea1dbd40..8eac3895ea9a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2916,10 +2916,6 @@ static void intel_fixup_cur_wm_latency(struct
> drm_i915_private *dev_priv,
>   /* ILK cursor LP0 latency is 1300 ns */
>   if (IS_GEN5(dev_priv))
>   wm[0] = 13;
> -
> - /* WaDoubleCursorLP3Latency:ivb */
> - if (IS_IVYBRIDGE(dev_priv))
> - wm[3] *= 2;
>  }
>  
>  int ilk_wm_max_level(const struct drm_i915_private *dev_priv)
-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Move the scheduler feature bits into the purview of the engines

[Mika Kuoppala]

Chris Wilson  writes:

> Rather than having the high level ioctl interface guess the underlying
> implementation details, having the implementation declare what
> capabilities it exports. We define an intel_driver_caps, similar to the
> intel_device_info, which instead of trying to describe the HW gives
> details on what the driver itself supports. This is then populated by
> the engine backend for the new scheduler capability field for use
> elsewhere.
>
> Signed-off-by: Chris Wilson 
> Cc: Tomasz Lis 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Cc: Michal Wajdeczko 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  | 8 +---
>  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
>  drivers/gpu/drm/i915/i915_gem.c  | 3 +++
>  drivers/gpu/drm/i915/i915_gpu_error.c| 7 +--
>  drivers/gpu/drm/i915/intel_device_info.c | 6 ++
>  drivers/gpu/drm/i915/intel_device_info.h | 7 +++
>  drivers/gpu/drm/i915/intel_lrc.c | 6 ++
>  7 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1ec12add34b2..733f71637914 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -372,13 +372,7 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   value = i915_gem_mmap_gtt_version();
>   break;
>   case I915_PARAM_HAS_SCHEDULER:
> - value = 0;
> - if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule) {
> - value |= I915_SCHEDULER_CAP_ENABLED;
> - value |= I915_SCHEDULER_CAP_PRIORITY;
> - if (HAS_LOGICAL_RING_PREEMPTION(dev_priv))
> - value |= I915_SCHEDULER_CAP_PREEMPTION;
> - }
> + value = dev_priv->caps.scheduler;

Use the shiny CAP_PRIORITY instead of rcs->schedule on the
I915_CONTEXT_PARAM_PRIORITY validation?

-Mika

>   break;
>  
>   case I915_PARAM_MMAP_VERSION:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 388b72cccde4..ae434c9d2b4f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -468,6 +468,7 @@ struct i915_gpu_state {
>   u32 reset_count;
>   u32 suspend_count;
>   struct intel_device_info device_info;
> + struct intel_driver_caps driver_caps;
>   struct i915_params params;
>  
>   struct i915_error_uc {
> @@ -1808,6 +1809,7 @@ struct drm_i915_private {
>   struct kmem_cache *priorities;
>  
>   const struct intel_device_info info;
> + struct intel_driver_caps caps;
>  
>   /**
>* Data Stolen Memory - aka "i915 stolen memory" gives us the start and
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 062b21408698..ad7bd0dc57ee 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3223,8 +3223,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>* start to complete all requests.
>*/
>   engine->submit_request = nop_complete_submit_request;
> + engine->schedule = NULL;
>   }
>  
> + i915->caps.scheduler = 0;
> +
>   /*
>* Make sure no request can slip through without getting completed by
>* either this call here to intel_engine_init_global_seqno, or the one
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index a81351d9e3a6..a92b0c0377c7 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -573,11 +573,13 @@ static void print_error_obj(struct 
> drm_i915_error_state_buf *m,
>  }
>  
>  static void err_print_capabilities(struct drm_i915_error_state_buf *m,
> -const struct intel_device_info *info)
> +const struct intel_device_info *info,
> +const struct intel_driver_caps *caps)
>  {
>   struct drm_printer p = i915_error_printer(m);
>  
>   intel_device_info_dump_flags(info, );
> + intel_driver_caps_print(caps, );
>  }
>  
>  static void err_print_params(struct drm_i915_error_state_buf *m,
> @@ -800,7 +802,7 @@ int i915_error_state_to_str(struct 
> drm_i915_error_state_buf *m,
>   if (error->display)
>   intel_display_print_error_state(m, error->display);
>  
> - err_print_capabilities(m, >device_info);
> + err_print_capabilities(m, >device_info, >driver_caps);
>   err_print_params(m, >params);
>   err_print_uc(m, >uc);
>  
> @@ -1731,6 +1733,7 @@ static void i915_capture_gen_state(struct 
> drm_i915_private *dev_priv,
>   memcpy(>device_info,
>  

Re: [Intel-gfx] [PATCH igt] tools/intel_reg: Add reading and writing registers through engine

[Mika Kuoppala]

Jani Nikula  writes:

> On Mon, 22 Jan 2018, Mika Kuoppala  wrote:
>> Jani Nikula  writes:
>>
>>> On Mon, 08 Jan 2018, Mika Kuoppala  wrote:
 Add option to specify engine for register read/write operation.
 If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
 to write and read register using a batch targeted at that engine.
>>>
>>> Copy-pasting from the man page, we already have the notation:
>>>
>>> "Registers are defined as 
>>> [(PORTNAME|PORTNUM|MMIO-OFFSET):](REGNAME|REGADDR)."
>>>
>>> Why don't we add this as ENGINE:REGNAME or something instead of an extra
>>> --engine parameter? As a "port". Sure, it's more work, but I really like
>>> the current possibility of reading all types of registers at once. Now
>>> you prevent dumps that would contain both mmio and batch based reads.
>>>
>>
>> Are you ok with the latest version? As discussed in irc, there are
>> problems with trying to add engines as ports, due to dynamic nature
>> and also that the existing infra relies on PORTNAME being mmio
>> for symbolic register dumping to work correctly.
>>
>> for the wart of if (reg->engine) in read/write paths
>> we gain the benefits of mmio dumps with engines.
>
> Can't say I would've reviewed all the engine bits and pieces, but
>
> Acked-by: Jani Nikula 

Thanks for ack and review. Pushed.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Ville Syrjälä]

On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Doing link retraining from the short pulse handler is problematic since
> > that might introduce deadlocks with MST sideband processing. Currently
> > we don't retrain MST links from this code, but we want to change that.
> > So better to move the entire thing to the hotplug work. We can utilize
> > the new encoder->hotplug() hook for this.
> > 
> > The only thing we leave in the short pulse handler is the link status
> > check. That one still depends on the link parameters stored under
> > intel_dp, so no locking around that but races should be mostly harmless
> > as the actual retraining code will recheck the link state if we
> > end up there by mistake.
> > 
> > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > Check the connector type to figure out if we should do
> > the HDMI thing or the DP think for DDI
> > 
> > Cc: Manasi Navare 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> >  drivers/gpu/drm/i915/intel_dp.c  | 196 ++--
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> >  3 files changed, 120 insertions(+), 88 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 25793bdc692f..5f3d58f1ae6e 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct intel_encoder
> > *encoder,
> > drm_modeset_acquire_init(, 0);
> >  
> > for (;;) {
> > -   ret = intel_hdmi_reset_link(encoder, );
> > +   if (connector->base.connector_type ==
> > DRM_MODE_CONNECTOR_HDMIA)
> > +   ret = intel_hdmi_reset_link(encoder, );
> > +   else
> > +   ret = intel_dp_retrain_link(encoder, );
> >  
> > if (ret == -EDEADLK) {
> > drm_modeset_backoff();
> > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct drm_i915_private 
> > *dev_priv,
> > enum port port)
> > drm_encoder_init(_priv->drm, encoder, _ddi_funcs,
> >  DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
> >  
> > -   if (init_hdmi)
> > -   intel_encoder->hotplug = intel_ddi_hotplug;
> > -   else
> > -   intel_encoder->hotplug = intel_encoder_hotplug;
> > +   intel_encoder->hotplug = intel_ddi_hotplug;
> > intel_encoder->compute_output_type = intel_ddi_compute_output_type;
> > intel_encoder->compute_config = intel_ddi_compute_config;
> > intel_encoder->enable = intel_enable_ddi;
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 6bbf14410c2a..152016e09a11 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> > return -EINVAL;
> >  }
> >  
> > -static void
> > -intel_dp_retrain_link(struct intel_dp *intel_dp)
> > +static bool
> > +intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > +{
> > +   u8 link_status[DP_LINK_STATUS_SIZE];
> > +
> > +   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > +   DRM_ERROR("Failed to get link status\n");
> > +   return false;
> > +   }
> > +
> > +   /*
> > +* Validate the cached values of intel_dp->link_rate and
> > +* intel_dp->lane_count before attempting to retrain.
> > +*/
> > +   if (!intel_dp_link_params_valid(intel_dp, intel_dp->link_rate,
> > +   intel_dp->lane_count))
> > +   return false;
> > +
> > +   /* Retrain if Channel EQ or CR not ok */
> > +   return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> > +}
> > +
> > +/*
> > + * If display is now connected check links status,
> > + * there has been known issues of link loss triggering
> > + * long pulse.
> > + *
> > + * Some sinks (eg. ASUS PB287Q) seem to perform some
> > + * weird HPD ping pong during modesets. So we can apparently
> > + * end up with HPD going low during a modeset, and then
> > + * going back up soon after. And once that happens we must
> > + * retrain the link to get a picture. That's in case no
> > + * userspace component reacted to intermittent HPD dip.
> > + */
> > +int intel_dp_retrain_link(struct intel_encoder *encoder,
> > + struct drm_modeset_acquire_ctx *ctx)
> >  {
> > -   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> > +   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > +   struct intel_connector 

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Allow preempt-client to be NULL

[Mika Kuoppala]

Chris Wilson  writes:

> In the next patch, we may only conditionally allocate the preempt-client
> if there is a global preempt context and so we need to be prepared in
> case the preempt-client itself is NULL.
>
> v2: Grep for more preempt_client.
>
> Signed-off-by: Chris Wilson 
> Cc: Michal Winiarski 
> Cc: Arkadiusz Hiler 
> Cc: Daniele Ceraolo Spurio 
> Cc: Michel Thierry 
> Cc: Michal Wajdeczko 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  8 +---
>  drivers/gpu/drm/i915/intel_guc_submission.c | 27 +--
>  drivers/gpu/drm/i915/selftests/intel_guc.c  | 20 +++-
>  3 files changed, 33 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3849ded354e3..9e44adef30f0 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2338,7 +2338,6 @@ static int i915_guc_info(struct seq_file *m, void *data)
>   return -ENODEV;
>  
>   GEM_BUG_ON(!guc->execbuf_client);
> - GEM_BUG_ON(!guc->preempt_client);
>  
>   seq_printf(m, "Doorbell map:\n");
>   seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
> @@ -2346,8 +2345,11 @@ static int i915_guc_info(struct seq_file *m, void 
> *data)
>  
>   seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
>   i915_guc_client_info(m, dev_priv, guc->execbuf_client);
> - seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client);
> - i915_guc_client_info(m, dev_priv, guc->preempt_client);
> + if (guc->preempt_client) {
> + seq_printf(m, "\nGuC preempt client @ %p:\n",
> +guc->preempt_client);
> + i915_guc_client_info(m, dev_priv, guc->preempt_client);
> + }
>  
>   i915_guc_log_info(m, dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/intel_guc_submission.c
> index 1f3a8786bbdc..4ea65df05e02 100644
> --- a/drivers/gpu/drm/i915/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/intel_guc_submission.c
> @@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc 
> *guc)
>   if (ret)
>   return ret;
>  
> - ret = create_doorbell(guc->preempt_client);
> - if (ret) {
> - destroy_doorbell(guc->execbuf_client);
> - return ret;
> + if (guc->preempt_client) {
> + ret = create_doorbell(guc->preempt_client);
> + if (ret) {
> + destroy_doorbell(guc->execbuf_client);
> + return ret;
> + }
>   }
>  
>   return 0;
> @@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc 
> *guc)
>* Instead of trying (in vain) to communicate with it, let's just
>* cleanup the doorbell HW and our internal state.
>*/
> - __destroy_doorbell(guc->preempt_client);
> - __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID);
> + if (guc->preempt_client) {
> + __destroy_doorbell(guc->preempt_client);
> + __update_doorbell_desc(guc->preempt_client,
> +GUC_DOORBELL_INVALID);
> + }
>   __destroy_doorbell(guc->execbuf_client);
>   __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
>  }
> @@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc)
>  {
>   struct intel_guc_client *client;
>  
> - client = fetch_and_zero(>execbuf_client);
> - guc_client_free(client);
> -
>   client = fetch_and_zero(>preempt_client);
> + if (client)
> + guc_client_free(client);
> +
> + client = fetch_and_zero(>execbuf_client);
>   guc_client_free(client);
>  }
>  
> @@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>   GEM_BUG_ON(!guc->execbuf_client);
>  
>   guc_reset_wq(guc->execbuf_client);
> - guc_reset_wq(guc->preempt_client);
> + if (guc->preempt_client)
> + guc_reset_wq(guc->preempt_client);
>  
>   err = intel_guc_sample_forcewake(guc);
>   if (err)
> diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c 
> b/drivers/gpu/drm/i915/selftests/intel_guc.c
> index 3f9016466dea..fb74e2cf8a0a 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_guc.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
> @@ -87,7 +87,7 @@ static int validate_client(struct intel_guc_client *client,
>  
>  static bool client_doorbell_in_sync(struct intel_guc_client *client)
>  {
> - return doorbell_ok(client->guc, client->doorbell_id);
> + return !client || doorbell_ok(client->guc, client->doorbell_id);
>  }
>  
>  /*

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3)
URL   : https://patchwork.freedesktop.org/series/37342/
State : success

== Summary ==

Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-snb) fdo#103060
Test gem_eio:
Subgroup in-flight:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test perf:
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> SKIP   (shard-snb) fdo#103375

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:1401 pass:878  dwarn:1   dfail:0   fail:12  skip:510 
time:6184s
shard-hswtotal:2838 pass:1736 dwarn:1   dfail:0   fail:10  skip:1090 
time:12019s
shard-snbtotal:2838 pass:1328 dwarn:1   dfail:0   fail:11  skip:1498 
time:6653s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7835/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL 
(rev2)
URL   : https://patchwork.freedesktop.org/series/37395/
State : success

== Summary ==

Series 37395v2 series starting with [v2] drm/i915/guc: Allow preempt-client to 
be NULL
https://patchwork.freedesktop.org/api/1.0/series/37395/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:389s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:493s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:572s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

badc0398a06018a07f6f50a1ff5a5fd8a30b9944 drm-tip: 2018y-01m-31d-12h-17m-12s UTC 
integration manifest
b566d4c192e0 drm/i915: Only allocate preempt context when required
9d317ed56342 drm/i915: Move the scheduler feature bits into the purview of the 
engines
c74489d84b5e drm/i915/guc: Allow preempt-client to be NULL

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7838/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] tools/intel_reg: Add reading and writing registers through engine

[Jani Nikula]

On Mon, 22 Jan 2018, Mika Kuoppala  wrote:
> Jani Nikula  writes:
>
>> On Mon, 08 Jan 2018, Mika Kuoppala  wrote:
>>> Add option to specify engine for register read/write operation.
>>> If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
>>> to write and read register using a batch targeted at that engine.
>>
>> Copy-pasting from the man page, we already have the notation:
>>
>> "Registers are defined as 
>> [(PORTNAME|PORTNUM|MMIO-OFFSET):](REGNAME|REGADDR)."
>>
>> Why don't we add this as ENGINE:REGNAME or something instead of an extra
>> --engine parameter? As a "port". Sure, it's more work, but I really like
>> the current possibility of reading all types of registers at once. Now
>> you prevent dumps that would contain both mmio and batch based reads.
>>
>
> Are you ok with the latest version? As discussed in irc, there are
> problems with trying to add engines as ports, due to dynamic nature
> and also that the existing infra relies on PORTNAME being mmio
> for symbolic register dumping to work correctly.
>
> for the wart of if (reg->engine) in read/write paths
> we gain the benefits of mmio dumps with engines.

Can't say I would've reviewed all the engine bits and pieces, but

Acked-by: Jani Nikula 


>
> -Mika
>
>> BR,
>> Jani.
>>
>>
>>>
>>> v2: no MI_NOOP after BBE (Chris)
>>> v3: use modern engine names (Chris), use global fd
>>>
>>> Cc: Jani Nikula 
>>> Cc: Chris Wilson 
>>> CC: Joonas Lahtinen 
>>> Signed-off-by: Mika Kuoppala 
>>> ---
>>>  tools/intel_reg.c | 156 
>>> +-
>>>  1 file changed, 154 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
>>> index 00d2a4a1..7f3494ef 100644
>>> --- a/tools/intel_reg.c
>>> +++ b/tools/intel_reg.c
>>> @@ -33,6 +33,7 @@
>>>  #include 
>>>  
>>>  #include "igt.h"
>>> +#include "igt_gt.h"
>>>  #include "intel_io.h"
>>>  #include "intel_chipset.h"
>>>  
>>> @@ -73,6 +74,11 @@ struct config {
>>>  
>>> /* register spec */
>>> char *specfile;
>>> +
>>> +   /* engine to use for lri (write) and srm (read) */
>>> +   char *engine;
>>> +   int fd;
>>> +
>>> struct reg *regs;
>>> ssize_t regcount;
>>>  
>>> @@ -236,13 +242,140 @@ static void dump_decode(struct config *config, 
>>> struct reg *reg, uint32_t val)
>>> }
>>>  }
>>>  
>>> +static const struct intel_execution_engine2 *find_engine(const char *name,
>>> +bool *secure)
>>> +{
>>> +   const struct intel_execution_engine2 *e;
>>> +
>>> +   if (strlen(name) < 2)
>>> +   goto out;
>>> +
>>> +   if (name[0] == '-') {
>>> +   *secure = false;
>>> +   name++;
>>> +   } else {
>>> +   *secure = true;
>>> +   }
>>> +
>>> +   for (e = intel_execution_engines2; e->name; e++) {
>>> +   if (!strcmp(e->name, name))
>>> +   return e;
>>> +   }
>>> +
>>> +out:
>>> +   fprintf(stderr, "no such engine as '%s'\n", name);
>>> +
>>> +   fprintf(stderr, "valid engines:");
>>> +   for (e = intel_execution_engines2; e->name; e++)
>>> +   fprintf(stderr, " %s", e->name);
>>> +
>>> +   fprintf(stderr, "\n");
>>> +
>>> +   exit(EXIT_FAILURE);
>>> +}
>>> +
>>> +static int register_srm(struct config *config, struct reg *reg,
>>> +   uint32_t *val_in)
>>> +{
>>> +   const int gen = intel_gen(config->devid);
>>> +   const bool r64b = gen >= 8;
>>> +   const uint32_t ctx = 0;
>>> +   struct drm_i915_gem_exec_object2 obj[2];
>>> +   struct drm_i915_gem_relocation_entry reloc[1];
>>> +   struct drm_i915_gem_execbuffer2 execbuf;
>>> +   uint32_t *batch, *r;
>>> +   const struct intel_execution_engine2 *engine;
>>> +   bool secure;
>>> +   int fd, i;
>>> +   uint32_t val;
>>> +
>>> +   if (config->fd == -1) {
>>> +   config->fd = __drm_open_driver(DRIVER_INTEL);
>>> +   if (config->fd == -1) {
>>> +   fprintf(stderr, "Error opening driver: %s",
>>> +   strerror(errno));
>>> +   exit(EXIT_FAILURE);
>>> +   }
>>> +   }
>>> +
>>> +   fd = config->fd;
>>> +   engine = find_engine(config->engine, );
>>> +
>>> +   memset(obj, 0, sizeof(obj));
>>> +   obj[0].handle = gem_create(fd, 4096);
>>> +   obj[1].handle = gem_create(fd, 4096);
>>> +   obj[1].relocs_ptr = to_user_pointer(reloc);
>>> +   obj[1].relocation_count = 1;
>>> +
>>> +   batch = gem_mmap__cpu(fd, obj[1].handle, 0, 4096, PROT_WRITE);
>>> +   gem_set_domain(fd, obj[1].handle,
>>> +  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
>>> +
>>> +   i = 0;
>>> +   if (val_in) {
>>> +   batch[i++] = MI_NOOP;
>>> +   batch[i++] = MI_NOOP;
>>> +
>>> +   batch[i++] = MI_LOAD_REGISTER_IMM;
>>> +   

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-01-31 11:31:09)
>> Chris Wilson  writes:
>> 
>> > In the next patch, we may only conditionally allocate the preempt-client
>> > if there is a global preempt context and so we need to be prepared in
>> > case the preempt-client itself is NULL.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Cc: Michal Winiarski 
>> > Cc: Arkadiusz Hiler 
>> > Cc: Daniele Ceraolo Spurio 
>> > Cc: Michel Thierry 
>> > Cc: Michal Wajdeczko 
>> > ---
>> >  drivers/gpu/drm/i915/intel_guc_submission.c | 27 
>> > +--
>> >  1 file changed, 17 insertions(+), 10 deletions(-)
>> >
>> 
>> You need to prepare the debugfs to handle the null also.
>> 
>> Does our simple igt/debugfs test include reading through all the nodes
>> it finds?
>
> It does, but we don't actually end up with NULLs.

Not with this patch alone but the commit message promises
that we prepare for it :)

-Mika

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

Re: [Intel-gfx] [PATCH 02/16] drm/i915/skl+: refactor WM calculation for NV12

[Maarten Lankhorst]

Op 22-01-18 om 13:03 schreef Vidya Srinivas:
> From: Mahesh Kumar 
>
> Current code calculates DDB for planar formats in such a way that we
> store DDB of plane-0 in plane 1 & vice-versa.
> In order to make this clean this patch refactors WM/DDB calculation for
> NV12 planar formats.
>
> v2: Addressed review comments by Maarten
>
> Reviewed-by: Maarten Lankhorst 
> Signed-off-by: Mahesh Kumar 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   4 +-
>  drivers/gpu/drm/i915/intel_drv.h |   1 +
>  drivers/gpu/drm/i915/intel_pm.c  | 121 
> ---
>  3 files changed, 64 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d440a11..df91904 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1433,8 +1433,8 @@ static inline bool skl_ddb_entry_equal(const struct 
> skl_ddb_entry *e1,
>  }
>  
>  struct skl_ddb_allocation {
> - struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
> packed/uv */
> - struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
> + struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
> packed/y */
> + struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
>  };
>  
>  struct skl_ddb_values {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5391c77..fc48697 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -592,6 +592,7 @@ struct intel_pipe_wm {
>  struct skl_plane_wm {
>   struct skl_wm_level wm[8];
>   struct skl_wm_level trans_wm;
> + bool is_nv12;
>  };
>  
>  struct skl_pipe_wm {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b4cb21d..bed5de0 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4004,9 +4004,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
> *intel_crtc,
>  static unsigned int
>  skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
>const struct drm_plane_state *pstate,
> -  int y)
> +  const int plane)
>  {
> - struct intel_plane *plane = to_intel_plane(pstate->plane);
> + struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
>   struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
>   uint32_t data_rate;
>   uint32_t width = 0, height = 0;
> @@ -4020,9 +4020,9 @@ skl_plane_relative_data_rate(const struct 
> intel_crtc_state *cstate,
>   fb = pstate->fb;
>   format = fb->format->format;
>  
> - if (plane->id == PLANE_CURSOR)
> + if (intel_plane->id == PLANE_CURSOR)
>   return 0;
> - if (y && format != DRM_FORMAT_NV12)
> + if (plane == 1 && format != DRM_FORMAT_NV12)
>   return 0;
>  
>   /*
> @@ -4033,19 +4033,14 @@ skl_plane_relative_data_rate(const struct 
> intel_crtc_state *cstate,
>   width = drm_rect_width(_pstate->base.src) >> 16;
>   height = drm_rect_height(_pstate->base.src) >> 16;
>  
> - /* for planar format */
> - if (format == DRM_FORMAT_NV12) {
> - if (y)  /* y-plane data rate */
> - data_rate = width * height *
> - fb->format->cpp[0];
> - else/* uv-plane data rate */
> - data_rate = (width / 2) * (height / 2) *
> - fb->format->cpp[1];
> - } else {
> - /* for packed formats */
> - data_rate = width * height * fb->format->cpp[0];
> + /* UV plane does 1/2 pixel sub-sampling */
> + if (plane == 1 && format == DRM_FORMAT_NV12) {
> + width /= 2;
> + height /= 2;
>   }
>  
> + data_rate = width * height * fb->format->cpp[plane];
> +
>   down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
>  
>   return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
> @@ -4058,8 +4053,8 @@ skl_plane_relative_data_rate(const struct 
> intel_crtc_state *cstate,
>   */
>  static unsigned int
>  skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
> -  unsigned *plane_data_rate,
> -  unsigned *plane_y_data_rate)
> +  unsigned int *plane_data_rate,
> +  unsigned int *uv_plane_data_rate)
>  {
>   struct drm_crtc_state *cstate = _cstate->base;
>   struct drm_atomic_state *state = cstate->state;
> @@ -4075,17 +4070,17 @@ skl_get_total_relative_data_rate(struct 
> intel_crtc_state *intel_cstate,
>   enum plane_id plane_id = to_intel_plane(plane)->id;
>   unsigned int rate;
>  
> - 

[Intel-gfx] [PATCH v2] drm/i915/guc: Allow preempt-client to be NULL

[Chris Wilson]

In the next patch, we may only conditionally allocate the preempt-client
if there is a global preempt context and so we need to be prepared in
case the preempt-client itself is NULL.

v2: Grep for more preempt_client.

Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Arkadiusz Hiler 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  8 +---
 drivers/gpu/drm/i915/intel_guc_submission.c | 27 +--
 drivers/gpu/drm/i915/selftests/intel_guc.c  | 20 +++-
 3 files changed, 33 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3849ded354e3..9e44adef30f0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2338,7 +2338,6 @@ static int i915_guc_info(struct seq_file *m, void *data)
return -ENODEV;
 
GEM_BUG_ON(!guc->execbuf_client);
-   GEM_BUG_ON(!guc->preempt_client);
 
seq_printf(m, "Doorbell map:\n");
seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
@@ -2346,8 +2345,11 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
-   seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client);
-   i915_guc_client_info(m, dev_priv, guc->preempt_client);
+   if (guc->preempt_client) {
+   seq_printf(m, "\nGuC preempt client @ %p:\n",
+  guc->preempt_client);
+   i915_guc_client_info(m, dev_priv, guc->preempt_client);
+   }
 
i915_guc_log_info(m, dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 1f3a8786bbdc..4ea65df05e02 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc 
*guc)
if (ret)
return ret;
 
-   ret = create_doorbell(guc->preempt_client);
-   if (ret) {
-   destroy_doorbell(guc->execbuf_client);
-   return ret;
+   if (guc->preempt_client) {
+   ret = create_doorbell(guc->preempt_client);
+   if (ret) {
+   destroy_doorbell(guc->execbuf_client);
+   return ret;
+   }
}
 
return 0;
@@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc 
*guc)
 * Instead of trying (in vain) to communicate with it, let's just
 * cleanup the doorbell HW and our internal state.
 */
-   __destroy_doorbell(guc->preempt_client);
-   __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID);
+   if (guc->preempt_client) {
+   __destroy_doorbell(guc->preempt_client);
+   __update_doorbell_desc(guc->preempt_client,
+  GUC_DOORBELL_INVALID);
+   }
__destroy_doorbell(guc->execbuf_client);
__update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
 }
@@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc)
 {
struct intel_guc_client *client;
 
-   client = fetch_and_zero(>execbuf_client);
-   guc_client_free(client);
-
client = fetch_and_zero(>preempt_client);
+   if (client)
+   guc_client_free(client);
+
+   client = fetch_and_zero(>execbuf_client);
guc_client_free(client);
 }
 
@@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
GEM_BUG_ON(!guc->execbuf_client);
 
guc_reset_wq(guc->execbuf_client);
-   guc_reset_wq(guc->preempt_client);
+   if (guc->preempt_client)
+   guc_reset_wq(guc->preempt_client);
 
err = intel_guc_sample_forcewake(guc);
if (err)
diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c 
b/drivers/gpu/drm/i915/selftests/intel_guc.c
index 3f9016466dea..fb74e2cf8a0a 100644
--- a/drivers/gpu/drm/i915/selftests/intel_guc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
@@ -87,7 +87,7 @@ static int validate_client(struct intel_guc_client *client,
 
 static bool client_doorbell_in_sync(struct intel_guc_client *client)
 {
-   return doorbell_ok(client->guc, client->doorbell_id);
+   return !client || doorbell_ok(client->guc, client->doorbell_id);
 }
 
 /*
@@ -137,7 +137,6 @@ static int igt_guc_clients(void *args)
goto unlock;
}
GEM_BUG_ON(!guc->execbuf_client);
-   GEM_BUG_ON(!guc->preempt_client);
 
err = validate_client(guc->execbuf_client,
   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/ast: Load lut in crtc_commit

[Patchwork]

== Series Details ==

Series: drm/ast: Load lut in crtc_commit
URL   : https://patchwork.freedesktop.org/series/37398/
State : success

== Summary ==

Series 37398v1 drm/ast: Load lut in crtc_commit
https://patchwork.freedesktop.org/api/1.0/series/37398/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104162

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162

fi-bdw-5557u total:245  pass:227  dwarn:0   dfail:0   fail:0   skip:17 
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:369s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:574s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:523s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cnl-y2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:506s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:466s

a2fbc800025405dbe0dc0820eab5d0ec3d636e55 drm-tip: 2018y-01m-31d-10h-50m-08s UTC 
integration manifest
25e14725ff3b drm/ast: Load lut in crtc_commit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7837/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/guc: Fix return from guc_log_relay_file_create

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915/guc: Fix return from 
guc_log_relay_file_create
URL   : https://patchwork.freedesktop.org/series/37382/
State : failure

== Summary ==

Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-legacy:
fail   -> PASS   (shard-hsw) fdo#104873
Test kms_flip:
Subgroup 2x-flip-vs-modeset-interruptible:
pass   -> INCOMPLETE (shard-hsw) fdo#102614
Subgroup wf_vblank-ts-check-interruptible:
fail   -> PASS   (shard-snb) fdo#100368
Subgroup 2x-flip-vs-modeset-vs-hang:
pass   -> DMESG-WARN (shard-hsw)
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test perf_pmu:
Subgroup all-busy-check-all:
pass   -> FAIL   (shard-apl)
Test pm_rc6_residency:
Subgroup rc6-accuracy:
skip   -> PASS   (shard-snb)
Test gem_exec_schedule:
Subgroup smoketest-bsd:
pass   -> INCOMPLETE (shard-apl) fdo#102848
Subgroup smoketest-vebox:
pass   -> INCOMPLETE (shard-apl)
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-apltotal:1040 pass:648  dwarn:2   dfail:0   fail:11  skip:377 
time:5125s
shard-hswtotal:2818 pass:1724 dwarn:2   dfail:0   fail:9   skip:1081 
time:11559s
shard-snbtotal:2838 pass:1331 dwarn:1   dfail:0   fail:10  skip:1496 
time:6682s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7834/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL

[Chris Wilson]

Quoting Mika Kuoppala (2018-01-31 11:31:09)
> Chris Wilson  writes:
> 
> > In the next patch, we may only conditionally allocate the preempt-client
> > if there is a global preempt context and so we need to be prepared in
> > case the preempt-client itself is NULL.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Michal Winiarski 
> > Cc: Arkadiusz Hiler 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Michel Thierry 
> > Cc: Michal Wajdeczko 
> > ---
> >  drivers/gpu/drm/i915/intel_guc_submission.c | 27 
> > +--
> >  1 file changed, 17 insertions(+), 10 deletions(-)
> >
> 
> You need to prepare the debugfs to handle the null also.
> 
> Does our simple igt/debugfs test include reading through all the nodes
> it finds?

It does, but we don't actually end up with NULLs.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL

[Mika Kuoppala]

Chris Wilson  writes:

> In the next patch, we may only conditionally allocate the preempt-client
> if there is a global preempt context and so we need to be prepared in
> case the preempt-client itself is NULL.
>
> Signed-off-by: Chris Wilson 
> Cc: Michal Winiarski 
> Cc: Arkadiusz Hiler 
> Cc: Daniele Ceraolo Spurio 
> Cc: Michel Thierry 
> Cc: Michal Wajdeczko 
> ---
>  drivers/gpu/drm/i915/intel_guc_submission.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)
>

You need to prepare the debugfs to handle the null also.

Does our simple igt/debugfs test include reading through all the nodes
it finds?

-Mika

> diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/intel_guc_submission.c
> index 1f3a8786bbdc..4ea65df05e02 100644
> --- a/drivers/gpu/drm/i915/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/intel_guc_submission.c
> @@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc 
> *guc)
>   if (ret)
>   return ret;
>  
> - ret = create_doorbell(guc->preempt_client);
> - if (ret) {
> - destroy_doorbell(guc->execbuf_client);
> - return ret;
> + if (guc->preempt_client) {
> + ret = create_doorbell(guc->preempt_client);
> + if (ret) {
> + destroy_doorbell(guc->execbuf_client);
> + return ret;
> + }
>   }
>  
>   return 0;
> @@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc 
> *guc)
>* Instead of trying (in vain) to communicate with it, let's just
>* cleanup the doorbell HW and our internal state.
>*/
> - __destroy_doorbell(guc->preempt_client);
> - __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID);
> + if (guc->preempt_client) {
> + __destroy_doorbell(guc->preempt_client);
> + __update_doorbell_desc(guc->preempt_client,
> +GUC_DOORBELL_INVALID);
> + }
>   __destroy_doorbell(guc->execbuf_client);
>   __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
>  }
> @@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc)
>  {
>   struct intel_guc_client *client;
>  
> - client = fetch_and_zero(>execbuf_client);
> - guc_client_free(client);
> -
>   client = fetch_and_zero(>preempt_client);
> + if (client)
> + guc_client_free(client);
> +
> + client = fetch_and_zero(>execbuf_client);
>   guc_client_free(client);
>  }
>  
> @@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>   GEM_BUG_ON(!guc->execbuf_client);
>  
>   guc_reset_wq(guc->execbuf_client);
> - guc_reset_wq(guc->preempt_client);
> + if (guc->preempt_client)
> + guc_reset_wq(guc->preempt_client);
>  
>   err = intel_guc_sample_forcewake(guc);
>   if (err)
> -- 
> 2.15.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt v2 1/1] tools/intel_guc_logger: Send GuC log level in new i915 expected format

[Sagar Arun Kamble]

i915 expects GuC log level to be specified as:
0: disabled
1: enabled (verbosity level 0 = min)
2: enabled (verbosity level 1)
3: enabled (verbosity level 2)
4: enabled (verbosity level 3 = max)

Remove the earlier internal layout based logging control from
guc_log_control and send new expected values.

v2: log_level assert in guc_log_control, cleaner level setup (Michal)
added missing copyright header. (Sagar)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Michal Winiarski 
Reviewed-by: Michal Wajdeczko 
---
 tools/intel_guc_logger.c | 41 +
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/tools/intel_guc_logger.c b/tools/intel_guc_logger.c
index 031fd84..5f1de8d 100644
--- a/tools/intel_guc_logger.c
+++ b/tools/intel_guc_logger.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2014-2018 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 
 #include 
@@ -51,17 +74,27 @@ uint32_t test_duration, max_filesize;
 pthread_cond_t underflow_cond, overflow_cond;
 bool stop_logging, discard_oldlogs, capturing_stopped;
 
-static void guc_log_control(bool enable_logging)
+static void guc_log_control(bool enable, uint32_t log_level)
 {
int control_fd;
char data[19];
uint64_t val;
int ret;
 
+   igt_assert_lte(log_level, 3);
+
control_fd = igt_debugfs_open(-1, CONTROL_FILE_NAME, O_WRONLY);
igt_assert_f(control_fd >= 0, "couldn't open the guc log control 
file\n");
 
-   val = enable_logging ? ((verbosity_level << 4) | 0x1) : 0;
+   /*
+* i915 expects GuC log level to be specified as:
+* 0: disabled
+* 1: enabled (verbosity level 0 = min)
+* 2: enabled (verbosity level 1)
+* 3: enabled (verbosity level 2)
+* 4: enabled (verbosity level 3 = max)
+*/
+   val = enable ? log_level + 1 : 0;
 
ret = snprintf(data, sizeof(data), "0x%" PRIx64, val);
igt_assert(ret > 2 && ret < sizeof(data));
@@ -288,7 +321,7 @@ static void init_main_thread(void)
/* Enable the logging, it may not have been enabled from boot and so
 * the relay file also wouldn't have been created.
 */
-   guc_log_control(true);
+   guc_log_control(true, verbosity_level);
 
open_relay_file();
open_output_file();
@@ -420,7 +453,7 @@ int main(int argc, char **argv)
} while (!stop_logging);
 
/* Pause logging on the GuC side */
-   guc_log_control(false);
+   guc_log_control(false, 0);
 
/* Signal flusher thread to make an exit */
capturing_stopped = 1;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup

[Sagar Arun Kamble]

On 1/31/2018 4:07 PM, Michał Winiarski wrote:

On Wed, Jan 31, 2018 at 11:44:38AM +0530, Sagar Arun Kamble wrote:

On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available.
movntdqa is needed for efficient capture of the logs from uncached GuC
log buffer. GuC init was tied with this support and other setup needed
for interrupt based GuC log capture like relay channel/file support and
uncached mapping support. With this patch, GuC init is now unblocked from
lack of this support.
SSE and relay support init/fini is now being done by new functions
intel_guc_log_init|fini_runtime() which makes relay functions static.
We have introduced two states "supported" and "enabled". Supported is set
when we have SSE4.1 support and have relay, GuC log, WC mapping available.
Enabled is set when support is present and user has requested logging
through i915_modparams.guc_log_level.
While at this change, fixed unwind order in intel_uc_fini_misc.

Or, we could rework GuC log a bit.
We could change the meaning of guc_log_level - it would only affect the
"internal" GuC state (verbosity - in other words, the content of buffer used by
GuC). This allows userspace to inspect the content of GuC buffer
(i915_guc_log_dump), but i915 is not copying the data to the relay (we're
ignoring the interrupts recieved from GuC).

This means that we need to introduce alternative way of controling the relay,
let's say another file called "i915_guc_log_relay". Opening this file causes the
relay to be created, we can throw an error if we don't have SSE4.1 there.
(well - the whole runtime is created actually, things are quite badly named
today, runtime means mapping of buffer shared with GuC, relay is the buffer
"shared" with userspace, functions operating on "runtime" should probably setup
both of those rather than just the mapping).
True. Setup spread over different stages of load made it little 
complicated to change and your change will help.

We're also solving the problem of overflows if GuC is loaded with
"guc_log_level > 0" while nobody is consuming the data from the relay.
And we don't really need to handle the "runtime" at module load time at all,
which simplifies things.

Yes. Agree on this approach. Thanks.

I'm working on a series that does all of the above.

-Michał


Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_guc.c |  2 +-
  drivers/gpu/drm/i915/intel_guc_log.c | 97 ++--
  drivers/gpu/drm/i915/intel_guc_log.h | 16 +-
  drivers/gpu/drm/i915/intel_uc.c  | 14 ++
  4 files changed, 90 insertions(+), 39 deletions(-)


--
Thanks,
Sagar

___
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 [v2,1/3] drm/i915/guc: Allow preempt-client to be NULL

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915/guc: Allow preempt-client to be 
NULL
URL   : https://patchwork.freedesktop.org/series/37395/
State : warning

== Summary ==

Series 37395v1 series starting with [v2,1/3] drm/i915/guc: Allow preempt-client 
to be NULL
https://patchwork.freedesktop.org/api/1.0/series/37395/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +6
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#104058
Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-each:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-many-each:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-store-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-store-each:
pass   -> SKIP   (fi-elk-e7500)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-elk-e7500)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-elk-e7500)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-await-all:
pass   -> SKIP   (fi-elk-e7500)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:229  pass:161  dwarn:7   dfail:1   fail:0   skip:59 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:444s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:496s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:574s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

5d84aeda7cd418fe9d81419a42d1e7a46264e209 drm-tip: 2018y-01m-31d-10h-16m-14s UTC 
integration manifest
d7ab3f9a2164 drm/i915: Only allocate preempt context when required
b7a9c5fa91e5 drm/i915: Move the scheduler feature bits into the purview of the 

Re: [Intel-gfx] [PATCH] drm/i915: Flush ggtt writes through the old fenced vma before changing fences

[Lahtinen, Joonas]

On Tue, 2018-01-30 at 16:44 +, Chris Wilson wrote:
> This is a precautionary measure as I have no evidence to suggest we've
> hit a bug here (I was hoping this might explain gdg's odd behaviour, but
> alas), but given that we have a function to flush the ggtt writes it
> seems prudent to use it prior to changing the fence register. Due to the
> intrinsic nature of the GTT often operating as an independent mmio path,
> we should not just rely on the write to the fence acting as a full flush
> for GTT writes.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup

[Chris Wilson]

Quoting Michał Winiarski (2018-01-31 10:37:20)
> On Wed, Jan 31, 2018 at 11:44:38AM +0530, Sagar Arun Kamble wrote:
> > On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available.
> > movntdqa is needed for efficient capture of the logs from uncached GuC
> > log buffer. GuC init was tied with this support and other setup needed
> > for interrupt based GuC log capture like relay channel/file support and
> > uncached mapping support. With this patch, GuC init is now unblocked from
> > lack of this support.
> > SSE and relay support init/fini is now being done by new functions
> > intel_guc_log_init|fini_runtime() which makes relay functions static.
> > We have introduced two states "supported" and "enabled". Supported is set
> > when we have SSE4.1 support and have relay, GuC log, WC mapping available.
> > Enabled is set when support is present and user has requested logging
> > through i915_modparams.guc_log_level.
> > While at this change, fixed unwind order in intel_uc_fini_misc.
> 
> Or, we could rework GuC log a bit.
> We could change the meaning of guc_log_level - it would only affect the
> "internal" GuC state (verbosity - in other words, the content of buffer used 
> by
> GuC). This allows userspace to inspect the content of GuC buffer
> (i915_guc_log_dump), but i915 is not copying the data to the relay (we're
> ignoring the interrupts recieved from GuC).
> 
> This means that we need to introduce alternative way of controling the relay,
> let's say another file called "i915_guc_log_relay". Opening this file causes 
> the
> relay to be created, we can throw an error if we don't have SSE4.1 there.
> (well - the whole runtime is created actually, things are quite badly named
> today, runtime means mapping of buffer shared with GuC, relay is the buffer
> "shared" with userspace, functions operating on "runtime" should probably 
> setup
> both of those rather than just the mapping).
> 
> We're also solving the problem of overflows if GuC is loaded with
> "guc_log_level > 0" while nobody is consuming the data from the relay.
> And we don't really need to handle the "runtime" at module load time at all,
> which simplifies things.
> 
> I'm working on a series that does all of the above.

I'll push the 1st patch (the -EEXISTS fix) and we can come back for the
rest.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/9] drm/i915/dp: Remove redundant sleep after AUX transaction length check.

[David Weinehall]

On Fri, Jan 26, 2018 at 06:49:20PM -0800, Dhinakaran Pandiyan wrote:
> The core already takes care of the delay before retrying. The delay now
> changes to (500, 600)us instead of (500 + 1000, 600 + 1500)us.

Reviewed-by: David Weinehall 

> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2454326690fb..97a4557053db 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1189,14 +1189,6 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>   if (recv_bytes == 0 || recv_bytes > 20) {
>   DRM_DEBUG_KMS("Forbidden recv_bytes = %d on aux transaction\n",
> recv_bytes);
> - /*
> -  * FIXME: This patch was created on top of a series that
> -  * organize the retries at drm level. There EBUSY should
> -  * also take care for 1ms wait before retrying.
> -  * That aux retries re-org is still needed and after that is
> -  * merged we remove this sleep from here.
> -  */
> - usleep_range(1000, 1500);
>   ret = -EBUSY;
>   goto out;
>   }
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/9] drm/i915/dp: Move comment about hw timeout to the right place.

[David Weinehall]

On Fri, Jan 26, 2018 at 06:49:21PM -0800, Dhinakaran Pandiyan wrote:
> No functional change.
> 
> Signed-off-by: Dhinakaran Pandiyan 

Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 97a4557053db..06619998b5a3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1136,14 +1136,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  DP_AUX_CH_CTL_TIME_OUT_ERROR |
>  DP_AUX_CH_CTL_RECEIVE_ERROR);
>  
> - if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> - continue;
> -
>   /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
>*   400us delay required for errors and timeouts
>*   Timeout errors from the HW already meet this
>*   requirement so skip to next iteration
>*/
> + if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> + continue;
> +
>   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
>   usleep_range(400, 500);
>   continue;
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915/psr: Extract PSR DPCD initialization and move it to intel_psr.c

[David Weinehall]

On Fri, Jan 26, 2018 at 06:49:17PM -0800, Dhinakaran Pandiyan wrote:
> intel_edp_init_dpcd() is cluttered with PSR specific DPCD checks and
> intel_dp.c is huge.

Yes please!  Good idea.

> No functional change intended.

Reviewed-by: David Weinehall 

> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 64 +
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 68 
> 
>  3 files changed, 70 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a2e88715..2454326690fb 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3135,35 +3135,6 @@ intel_dp_get_link_status(struct intel_dp *intel_dp, 
> uint8_t link_status[DP_LINK_
>   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
>  }
>  
> -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> -{
> - uint8_t psr_caps = 0;
> -
> - if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
> - return false;
> - return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
> -}
> -
> -static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
> -{
> - uint8_t dprx = 0;
> -
> - if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
> -   ) != 1)
> - return false;
> - return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
> -}
> -
> -static bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
> -{
> - uint8_t alpm_caps = 0;
> -
> - if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
> -   _caps) != 1)
> - return false;
> - return alpm_caps & DP_ALPM_CAP;
> -}
> -
>  /* These are source-specific values. */
>  uint8_t
>  intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3714,40 +3685,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
>   DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
>  
> - /* Check if the panel supports PSR */
> - drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
> -  intel_dp->psr_dpcd,
> -  sizeof(intel_dp->psr_dpcd));
> - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> - dev_priv->psr.sink_support = true;
> - DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> - }
> -
> - if (INTEL_GEN(dev_priv) >= 9 &&
> - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> - uint8_t frame_sync_cap;
> -
> - dev_priv->psr.sink_support = true;
> - if (drm_dp_dpcd_readb(_dp->aux,
> -   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> -   _sync_cap) != 1)
> - frame_sync_cap = 0;
> - dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
> - /* PSR2 needs frame sync as well */
> - dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> - DRM_DEBUG_KMS("PSR2 %s on sink",
> -   dev_priv->psr.psr2_support ? "supported" : "not 
> supported");
> -
> - if (dev_priv->psr.psr2_support) {
> - dev_priv->psr.y_cord_support =
> - intel_dp_get_y_cord_status(intel_dp);
> - dev_priv->psr.colorimetry_support =
> - intel_dp_get_colorimetry_status(intel_dp);
> - dev_priv->psr.alpm =
> - intel_dp_get_alpm_status(intel_dp);
> - }
> -
> - }
> + intel_psr_init_dpcd(intel_dp);
>  
>   /*
>* Read the eDP display control registers.
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3cee54bc0352..a340bc04dad8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1851,6 +1851,7 @@ bool is_hdcp_supported(struct drm_i915_private 
> *dev_priv, enum port port);
>  
>  /* intel_psr.c */
>  #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
> +void intel_psr_init_dpcd(struct intel_dp *intel_dp);
>  void intel_psr_enable(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state);
>  void intel_psr_disable(struct intel_dp *intel_dp,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c12af1118647..a1b878449e83 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -56,6 +56,74 @@
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> +static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> +{
> + 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup

[Michał Winiarski]

On Wed, Jan 31, 2018 at 11:44:38AM +0530, Sagar Arun Kamble wrote:
> On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available.
> movntdqa is needed for efficient capture of the logs from uncached GuC
> log buffer. GuC init was tied with this support and other setup needed
> for interrupt based GuC log capture like relay channel/file support and
> uncached mapping support. With this patch, GuC init is now unblocked from
> lack of this support.
> SSE and relay support init/fini is now being done by new functions
> intel_guc_log_init|fini_runtime() which makes relay functions static.
> We have introduced two states "supported" and "enabled". Supported is set
> when we have SSE4.1 support and have relay, GuC log, WC mapping available.
> Enabled is set when support is present and user has requested logging
> through i915_modparams.guc_log_level.
> While at this change, fixed unwind order in intel_uc_fini_misc.

Or, we could rework GuC log a bit.
We could change the meaning of guc_log_level - it would only affect the
"internal" GuC state (verbosity - in other words, the content of buffer used by
GuC). This allows userspace to inspect the content of GuC buffer
(i915_guc_log_dump), but i915 is not copying the data to the relay (we're
ignoring the interrupts recieved from GuC).

This means that we need to introduce alternative way of controling the relay,
let's say another file called "i915_guc_log_relay". Opening this file causes the
relay to be created, we can throw an error if we don't have SSE4.1 there.
(well - the whole runtime is created actually, things are quite badly named
today, runtime means mapping of buffer shared with GuC, relay is the buffer
"shared" with userspace, functions operating on "runtime" should probably setup
both of those rather than just the mapping).

We're also solving the problem of overflows if GuC is loaded with
"guc_log_level > 0" while nobody is consuming the data from the relay.
And we don't really need to handle the "runtime" at module load time at all,
which simplifies things.

I'm working on a series that does all of the above.

-Michał

> 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Cc: Michal Wajdeczko 
> Cc: Michal Winiarski 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/intel_guc.c |  2 +-
>  drivers/gpu/drm/i915/intel_guc_log.c | 97 
> ++--
>  drivers/gpu/drm/i915/intel_guc_log.h | 16 +-
>  drivers/gpu/drm/i915/intel_uc.c  | 14 ++
>  4 files changed, 90 insertions(+), 39 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/ast: Load lut in crtc_commit

[Daniel Vetter]

In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But since

commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin 
Date:   Tue Jul 4 12:36:57 2017 +0200

drm/fb-helper: factor out pseudo-palette

that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.

Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin 
Cc: Daniel Vetter 
Cc:  # v4.14+
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Cc: Bill Fraser 
Reported-and-Tested-by: Bill Fraser 
Tested-by: Konstantin Khlebnikov 
Tested-by: Paul Tobias 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/ast/ast_mode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 9555a3542022..831b73392d82 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -644,6 +644,7 @@ static void ast_crtc_commit(struct drm_crtc *crtc)
 {
struct ast_private *ast = crtc->dev->dev_private;
ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0);
+   ast_crtc_load_lut(crtc);
 }
 
 
-- 
2.15.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3)
URL   : https://patchwork.freedesktop.org/series/37342/
State : success

== Summary ==

Series 37342v3 drm/i915: Use the correct maximum in skl_compute_plane_wm
https://patchwork.freedesktop.org/api/1.0/series/37342/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:434s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

7dc5917dc7dddff0c7f2a0361c8698030c6899fc drm-tip: 2018y-01m-31d-09h-37m-52s UTC 
integration manifest
2292a62dd685 drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7835/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Always run hangcheck while the GPU is busy

[Chris Wilson]

Quoting Mika Kuoppala (2018-01-31 09:41:35)
> Chris Wilson  writes:
> 
> > Previously, we relied on only running the hangcheck while somebody was
> > waiting on the GPU, in order to minimise the amount of time hangcheck
> > had to run. (If nobody was watching the GPU, nobody would notice if the
> > GPU wasn't responding -- eventually somebody would care and so kick
> > hangcheck into action.) However, this falls apart from around commit
> > 4680816be336 ("drm/i915: Wait first for submission, before waiting for
> > request completion"), as not all waiters declare themselves to hangcheck
> > and so we could switch off hangcheck and miss GPU hangs even when
> > waiting under the struct_mutex.
> >
> > If we enable hangcheck from the first request submission, and let it run
> > until the GPU is idle again, we forgo all the complexity involved with
> > only enabling around waiters. Instead we have to be careful that we do
> > not declare a GPU hang when idly waiting for the next request to be come
> > ready.
> >
> > Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting 
> > for request completion"
> > Signed-off-by: Chris Wilson 
> > Cc: Chris Wilson 
> > Cc: Mika Kuoppala 
> 
> Reviewed-by: Mika Kuoppala 

Rewrote the last paragraph to try and make it clear what I was hinting
at, and so it doesn't sound like a description of what this patch is
doing but the background mechanics that this patch relies upon.

Thanks for the review and discussion,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Chris Wilson]

Quoting Chris Wilson (2018-01-22 15:41:06)
> If we remember to cancel the signaler on a request when retiring it
> (after we know that the request has been signaled), we do not need to
> carry an additional request in the signaler itself. This prevents an
> issue whereby the signaler threads may be delayed and hold on to
> thousands of request references, causing severe memory fragmentation and
> premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL
> and frequent use of inter-engine fences).
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

Poke. I've been staring at this problem since December, it would be nice
to get some resolution :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup

[Sagar Arun Kamble]

On 1/31/2018 3:08 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-31 06:14:38)

On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available.
movntdqa is needed for efficient capture of the logs from uncached GuC
log buffer. GuC init was tied with this support and other setup needed
for interrupt based GuC log capture like relay channel/file support and
uncached mapping support. With this patch, GuC init is now unblocked from
lack of this support.
SSE and relay support init/fini is now being done by new functions
intel_guc_log_init|fini_runtime() which makes relay functions static.
We have introduced two states "supported" and "enabled". Supported is set
when we have SSE4.1 support and have relay, GuC log, WC mapping available.
Enabled is set when support is present and user has requested logging
through i915_modparams.guc_log_level.
While at this change, fixed unwind order in intel_uc_fini_misc.

Downside would appear to be the loss of feedback in i915.guc_log_level
when it fail?
This patch decouples the guc_log_level from only interrupt based log 
support.
We can continue to use/know guc_log_level to send the verbosity to GuC 
still.
Have to rely only on static dumps like i915_guc_log_dump or 
error_uc->guc_log wherever runtime logging is off.

  Otherwise, looks tidy enough.
-Chris


--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Fix return from guc_log_relay_file_create

[Sagar Arun Kamble]

On 1/31/2018 3:06 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-31 06:14:37)

guc_log_relay_file_create will return -EEXIST if we invoke
relay_late_setup_files multiple times as part of i915_guc_log_control.
However this is to be not cosidered as fail and need to return 0.
This was mistakenly introduced in the below commit. Fix it.

Fixes: 70deeaddc6e6 "drm/i915/guc: Fix lockdep due to log relay channel handling 
under struct_mutex"
Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 

Testcase?

Yes. will include.
Thanks for the review.

Reviewed-by: Chris Wilson 
-Chris


--
Thanks,
Sagar

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

[Intel-gfx] [PATCH v2 2/3] drm/i915: Move the scheduler feature bits into the purview of the engines

[Chris Wilson]

Rather than having the high level ioctl interface guess the underlying
implementation details, having the implementation declare what
capabilities it exports. We define an intel_driver_caps, similar to the
intel_device_info, which instead of trying to describe the HW gives
details on what the driver itself supports. This is then populated by
the engine backend for the new scheduler capability field for use
elsewhere.

Signed-off-by: Chris Wilson 
Cc: Tomasz Lis 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_drv.c  | 8 +---
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 drivers/gpu/drm/i915/i915_gem.c  | 3 +++
 drivers/gpu/drm/i915/i915_gpu_error.c| 7 +--
 drivers/gpu/drm/i915/intel_device_info.c | 6 ++
 drivers/gpu/drm/i915/intel_device_info.h | 7 +++
 drivers/gpu/drm/i915/intel_lrc.c | 6 ++
 7 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ec12add34b2..733f71637914 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -372,13 +372,7 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
value = i915_gem_mmap_gtt_version();
break;
case I915_PARAM_HAS_SCHEDULER:
-   value = 0;
-   if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule) {
-   value |= I915_SCHEDULER_CAP_ENABLED;
-   value |= I915_SCHEDULER_CAP_PRIORITY;
-   if (HAS_LOGICAL_RING_PREEMPTION(dev_priv))
-   value |= I915_SCHEDULER_CAP_PREEMPTION;
-   }
+   value = dev_priv->caps.scheduler;
break;
 
case I915_PARAM_MMAP_VERSION:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 388b72cccde4..ae434c9d2b4f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -468,6 +468,7 @@ struct i915_gpu_state {
u32 reset_count;
u32 suspend_count;
struct intel_device_info device_info;
+   struct intel_driver_caps driver_caps;
struct i915_params params;
 
struct i915_error_uc {
@@ -1808,6 +1809,7 @@ struct drm_i915_private {
struct kmem_cache *priorities;
 
const struct intel_device_info info;
+   struct intel_driver_caps caps;
 
/**
 * Data Stolen Memory - aka "i915 stolen memory" gives us the start and
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 062b21408698..ad7bd0dc57ee 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3223,8 +3223,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 * start to complete all requests.
 */
engine->submit_request = nop_complete_submit_request;
+   engine->schedule = NULL;
}
 
+   i915->caps.scheduler = 0;
+
/*
 * Make sure no request can slip through without getting completed by
 * either this call here to intel_engine_init_global_seqno, or the one
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a81351d9e3a6..a92b0c0377c7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -573,11 +573,13 @@ static void print_error_obj(struct 
drm_i915_error_state_buf *m,
 }
 
 static void err_print_capabilities(struct drm_i915_error_state_buf *m,
-  const struct intel_device_info *info)
+  const struct intel_device_info *info,
+  const struct intel_driver_caps *caps)
 {
struct drm_printer p = i915_error_printer(m);
 
intel_device_info_dump_flags(info, );
+   intel_driver_caps_print(caps, );
 }
 
 static void err_print_params(struct drm_i915_error_state_buf *m,
@@ -800,7 +802,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
if (error->display)
intel_display_print_error_state(m, error->display);
 
-   err_print_capabilities(m, >device_info);
+   err_print_capabilities(m, >device_info, >driver_caps);
err_print_params(m, >params);
err_print_uc(m, >uc);
 
@@ -1731,6 +1733,7 @@ static void i915_capture_gen_state(struct 
drm_i915_private *dev_priv,
memcpy(>device_info,
   INTEL_INFO(dev_priv),
   sizeof(error->device_info));
+   error->driver_caps = dev_priv->caps;
 }
 
 static __always_inline void dup_param(const char *type, void *x)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 

[Intel-gfx] [PATCH v2 3/3] drm/i915: Only allocate preempt context when required

[Chris Wilson]

If we remove some hardcoded assumptions about the preempt context having
a fixed id, reserved from use by normal user contexts, we may only
allocate the i915_gem_context when required. Then the subsequent
decisions on using preemption reduce to having the preempt context
available.

Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Tvrtko Ursulin 
Cc: Arkadiusz Hiler 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gem_context.c  | 29 
 drivers/gpu/drm/i915/intel_engine_cs.c   |  6 ++---
 drivers/gpu/drm/i915/intel_guc_submission.c  | 24 +++-
 drivers/gpu/drm/i915/intel_lrc.c | 17 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  5 
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  6 -
 6 files changed, 46 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 648e7536ff51..d69c8f1a4e78 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -449,10 +449,14 @@ destroy_kernel_context(struct i915_gem_context **ctxp)
i915_gem_context_free(ctx);
 }
 
+static bool needs_preempt_context(struct drm_i915_private *i915)
+{
+   return HAS_LOGICAL_RING_PREEMPTION(i915);
+}
+
 int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
 {
struct i915_gem_context *ctx;
-   int err;
 
GEM_BUG_ON(dev_priv->kernel_context);
 
@@ -468,8 +472,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_MIN);
if (IS_ERR(ctx)) {
DRM_ERROR("Failed to create default global context\n");
-   err = PTR_ERR(ctx);
-   goto err;
+   return PTR_ERR(ctx);
}
/*
 * For easy recognisablity, we want the kernel context to be 0 and then
@@ -479,23 +482,18 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
dev_priv->kernel_context = ctx;
 
/* highest priority; preempting task */
-   ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX);
-   if (IS_ERR(ctx)) {
-   DRM_ERROR("Failed to create default preempt context\n");
-   err = PTR_ERR(ctx);
-   goto err_kernel_context;
+   if (needs_preempt_context(dev_priv)) {
+   ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX);
+   if (!IS_ERR(ctx))
+   dev_priv->preempt_context = ctx;
+   else
+   DRM_ERROR("Failed to create preempt context; disabling 
preemption\n");
}
-   dev_priv->preempt_context = ctx;
 
DRM_DEBUG_DRIVER("%s context support initialized\n",
 dev_priv->engine[RCS]->context_size ? "logical" :
 "fake");
return 0;
-
-err_kernel_context:
-   destroy_kernel_context(_priv->kernel_context);
-err:
-   return err;
 }
 
 void i915_gem_contexts_lost(struct drm_i915_private *dev_priv)
@@ -521,7 +519,8 @@ void i915_gem_contexts_fini(struct drm_i915_private *i915)
 {
lockdep_assert_held(>drm.struct_mutex);
 
-   destroy_kernel_context(>preempt_context);
+   if (i915->preempt_context)
+   destroy_kernel_context(>preempt_context);
destroy_kernel_context(>kernel_context);
 
/* Must free all deferred contexts (via flush_workqueue) first */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7eebfbb95e89..bf634432c9c6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -631,7 +631,7 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
 * Similarly the preempt context must always be available so that
 * we can interrupt the engine at any time.
 */
-   if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) {
+   if (engine->i915->preempt_context) {
ring = engine->context_pin(engine,
   engine->i915->preempt_context);
if (IS_ERR(ring)) {
@@ -656,7 +656,7 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
 err_breadcrumbs:
intel_engine_fini_breadcrumbs(engine);
 err_unpin_preempt:
-   if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
+   if (engine->i915->preempt_context)
engine->context_unpin(engine, engine->i915->preempt_context);
 err_unpin_kernel:
engine->context_unpin(engine, engine->i915->kernel_context);
@@ -686,7 +686,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs 
*engine)
if (engine->default_state)

[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL

[Chris Wilson]

In the next patch, we may only conditionally allocate the preempt-client
if there is a global preempt context and so we need to be prepared in
case the preempt-client itself is NULL.

Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Arkadiusz Hiler 
Cc: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 1f3a8786bbdc..4ea65df05e02 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc 
*guc)
if (ret)
return ret;
 
-   ret = create_doorbell(guc->preempt_client);
-   if (ret) {
-   destroy_doorbell(guc->execbuf_client);
-   return ret;
+   if (guc->preempt_client) {
+   ret = create_doorbell(guc->preempt_client);
+   if (ret) {
+   destroy_doorbell(guc->execbuf_client);
+   return ret;
+   }
}
 
return 0;
@@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc 
*guc)
 * Instead of trying (in vain) to communicate with it, let's just
 * cleanup the doorbell HW and our internal state.
 */
-   __destroy_doorbell(guc->preempt_client);
-   __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID);
+   if (guc->preempt_client) {
+   __destroy_doorbell(guc->preempt_client);
+   __update_doorbell_desc(guc->preempt_client,
+  GUC_DOORBELL_INVALID);
+   }
__destroy_doorbell(guc->execbuf_client);
__update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
 }
@@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc)
 {
struct intel_guc_client *client;
 
-   client = fetch_and_zero(>execbuf_client);
-   guc_client_free(client);
-
client = fetch_and_zero(>preempt_client);
+   if (client)
+   guc_client_free(client);
+
+   client = fetch_and_zero(>execbuf_client);
guc_client_free(client);
 }
 
@@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
GEM_BUG_ON(!guc->execbuf_client);
 
guc_reset_wq(guc->execbuf_client);
-   guc_reset_wq(guc->preempt_client);
+   if (guc->preempt_client)
+   guc_reset_wq(guc->preempt_client);
 
err = intel_guc_sample_forcewake(guc);
if (err)
-- 
2.15.1

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

[Intel-gfx] [(rebase for CI) PATCH] drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm

[Maarten Lankhorst]

According to bspec, result_lines > 31 is only a maximum for latency
level 1 through 7.

For level 0 the number of lines is ignored, so always write 0 there
to prevent overflowing the 5 bits value.

This is required to make NV12 work.

Signed-off-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b92ea1dbd40..e33368c870b1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4554,6 +4554,10 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
}
 
+   /* The number of lines are ignored for the level 0 watermark. */
+   if (!level)
+   res_lines = 0;
+
if (res_blocks >= ddb_allocation || res_lines > 31) {
*enabled = false;
 
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Always run hangcheck while the GPU is busy

[Mika Kuoppala]

Chris Wilson  writes:

> Previously, we relied on only running the hangcheck while somebody was
> waiting on the GPU, in order to minimise the amount of time hangcheck
> had to run. (If nobody was watching the GPU, nobody would notice if the
> GPU wasn't responding -- eventually somebody would care and so kick
> hangcheck into action.) However, this falls apart from around commit
> 4680816be336 ("drm/i915: Wait first for submission, before waiting for
> request completion"), as not all waiters declare themselves to hangcheck
> and so we could switch off hangcheck and miss GPU hangs even when
> waiting under the struct_mutex.
>
> If we enable hangcheck from the first request submission, and let it run
> until the GPU is idle again, we forgo all the complexity involved with
> only enabling around waiters. Instead we have to be careful that we do
> not declare a GPU hang when idly waiting for the next request to be come
> ready.
>
> Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for 
> request completion"
> Signed-off-by: Chris Wilson 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem.c  |  7 +++
>  drivers/gpu/drm/i915/i915_gem_request.c  |  2 ++
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 11 ---
>  drivers/gpu/drm/i915/intel_hangcheck.c   |  7 +--
>  4 files changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 062b21408698..63308ec016a3 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3322,16 +3322,15 @@ i915_gem_retire_work_handler(struct work_struct *work)
>   mutex_unlock(>struct_mutex);
>   }
>  
> - /* Keep the retire handler running until we are finally idle.
> + /*
> +  * Keep the retire handler running until we are finally idle.
>* We do not need to do this test under locking as in the worst-case
>* we queue the retire worker once too often.
>*/
> - if (READ_ONCE(dev_priv->gt.awake)) {
> - i915_queue_hangcheck(dev_priv);
> + if (READ_ONCE(dev_priv->gt.awake))
>   queue_delayed_work(dev_priv->wq,
>  _priv->gt.retire_work,
>  round_jiffies_up_relative(HZ));
> - }
>  }
>  
>  static void shrink_caches(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 9b02310307fc..6cacd78cc849 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -393,6 +393,8 @@ static void mark_busy(struct drm_i915_private *i915)
>  
>   intel_engines_unpark(i915);
>  
> + i915_queue_hangcheck(i915);
> +
>   queue_delayed_work(i915->wq,
>  >gt.retire_work,
>  round_jiffies_up_relative(HZ));
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index 86acac010bb8..62b2a20bc24e 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -149,17 +149,6 @@ static void intel_breadcrumbs_fake_irq(struct timer_list 
> *t)
>   return;
>  
>   mod_timer(>fake_irq, jiffies + 1);
> -
> - /* Ensure that even if the GPU hangs, we get woken up.
> -  *
> -  * However, note that if no one is waiting, we never notice
> -  * a gpu hang. Eventually, we will have to wait for a resource
> -  * held by the GPU and so trigger a hangcheck. In the most
> -  * pathological case, this will be upon memory starvation! To
> -  * prevent this, we also queue the hangcheck from the retire
> -  * worker.
> -  */
> - i915_queue_hangcheck(engine->i915);
>  }
>  
>  static void irq_enable(struct intel_engine_cs *engine)
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 31f01d64c021..348a4f7ffb67 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -411,7 +411,6 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>   struct intel_engine_cs *engine;
>   enum intel_engine_id id;
>   unsigned int hung = 0, stuck = 0;
> - int busy_count = 0;
>  
>   if (!i915_modparams.enable_hangcheck)
>   return;
> @@ -429,7 +428,6 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>   intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
>  
>   for_each_engine(engine, dev_priv, id) {
> - const bool busy = intel_engine_has_waiter(engine);
>   struct intel_engine_hangcheck hc;
>  
>   

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-01-31 06:14:38)
> On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available.
> movntdqa is needed for efficient capture of the logs from uncached GuC
> log buffer. GuC init was tied with this support and other setup needed
> for interrupt based GuC log capture like relay channel/file support and
> uncached mapping support. With this patch, GuC init is now unblocked from
> lack of this support.
> SSE and relay support init/fini is now being done by new functions
> intel_guc_log_init|fini_runtime() which makes relay functions static.
> We have introduced two states "supported" and "enabled". Supported is set
> when we have SSE4.1 support and have relay, GuC log, WC mapping available.
> Enabled is set when support is present and user has requested logging
> through i915_modparams.guc_log_level.
> While at this change, fixed unwind order in intel_uc_fini_misc.

Downside would appear to be the loss of feedback in i915.guc_log_level
when it fail? Otherwise, looks tidy enough.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Fix return from guc_log_relay_file_create

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-01-31 06:14:37)
> guc_log_relay_file_create will return -EEXIST if we invoke
> relay_late_setup_files multiple times as part of i915_guc_log_control.
> However this is to be not cosidered as fail and need to return 0.
> This was mistakenly introduced in the below commit. Fix it.
> 
> Fixes: 70deeaddc6e6 "drm/i915/guc: Fix lockdep due to log relay channel 
> handling under struct_mutex"
> Signed-off-by: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Cc: Michal Wajdeczko 

Testcase?
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] lib: Avoid rcu_barrier() for gem_quiescent_gpu()

[Chris Wilson]

Using DROP_FREED invokes an rcu_barrier() to ensure that all RCU
protected objects are freed before it returns. rcu_barrier() is a very
high latency operation (~50ms at best) which is only required under
specific circumstances such as when we need a stable object count. By
removing it from gem_quiescent_gpu() we can save over 10s across a BAT
run.

Signed-off-by: Chris Wilson 
---
 lib/drmtest.c |  3 +--
 lib/igt_debugfs.c | 14 --
 lib/intel_os.c| 15 +--
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index fd11f5f58..40bd6fec8 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -163,8 +163,7 @@ void gem_quiescent_gpu(int fd)
 {
igt_terminate_spin_batches();
 
-   igt_drop_caches_set(fd,
-   DROP_ACTIVE | DROP_RETIRE | DROP_IDLE | DROP_FREED);
+   igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE | DROP_IDLE);
 }
 
 /**
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 1aec079c5..6d9d27d9c 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -977,13 +977,15 @@ static int get_object_count(int fd)
  */
 int igt_get_stable_obj_count(int driver)
 {
-   int obj_count;
-   gem_quiescent_gpu(driver);
-   obj_count = get_object_count(driver);
-   /* The test relies on the system being in the same state before and
+   /*
+* The test relies on the system being in the same state before and
 * after the test so any difference in the object count is a result of
-* leaks during the test. */
-   return obj_count;
+* leaks during the test.
+* */
+   igt_drop_caches_set(driver,
+   DROP_ACTIVE | DROP_RETIRE | DROP_IDLE | DROP_FREED);
+
+   return get_object_count(driver);
 }
 
 void igt_debugfs_dump(int device, const char *filename)
diff --git a/lib/intel_os.c b/lib/intel_os.c
index bb2c16bf3..b5d9888d8 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -96,11 +96,6 @@ intel_get_avail_ram_mb(void)
 
 #ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */
struct sysinfo sysinf;
-   int fd;
-
-   fd = drm_open_driver(DRIVER_INTEL);
-   intel_purge_vm_caches(fd);
-   close(fd);
 
igt_assert(sysinfo() == 0);
retval = sysinf.freeram;
@@ -281,6 +276,12 @@ void intel_require_memory(uint64_t count, uint64_t size, 
unsigned mode)
 {
uint64_t required, total;
 
+   if (!__intel_check_memory(count, size, mode, , )) {
+   int fd = drm_open_driver(DRIVER_INTEL);
+   intel_purge_vm_caches(fd);
+   close(fd);
+   }
+
igt_require_f(__intel_check_memory(count, size, mode,
, ),
  "Estimated that we need %'llu objects and %'llu MiB for 
the test, but only have %'llu MiB available (%s%s) and a maximum of %'llu 
objects\n",
@@ -298,7 +299,9 @@ void intel_purge_vm_caches(int drm_fd)
 {
int fd;
 
-   igt_drop_caches_set(drm_fd, DROP_SHRINK_ALL | DROP_IDLE | DROP_FREED);
+   igt_drop_caches_set(drm_fd,
+   DROP_ACTIVE | DROP_RETIRE | DROP_IDLE |
+   DROP_SHRINK_ALL | DROP_FREED);
 
fd = open("/proc/sys/vm/drop_caches", O_WRONLY);
if (fd >= 0) {
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Optimize drop-caches

[Chris Wilson]

Quoting Chris Wilson (2018-01-30 15:44:12)
> @@ -4084,8 +4088,9 @@ i915_drop_caches_set(void *data, u64 val)
> drain_delayed_work(_priv->gt.idle_work);
>  
> if (val & DROP_FREED) {
> -   synchronize_rcu();
> -   i915_gem_drain_freed_objects(dev_priv);
> +   synchronize_rcu_expedited();

So sync_rcu is not enough to process the call_rcu. Hmm.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx