[Intel-gfx] [PATCH v4 2/3] igt/gem_wait: Use new igt_spin_batch

[Abdiel Janulgue]

Cc: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Abdiel Janulgue 
---
 tests/gem_wait.c | 125 ---
 1 file changed, 7 insertions(+), 118 deletions(-)

diff --git a/tests/gem_wait.c b/tests/gem_wait.c
index b4127de..785bb14 100644
--- a/tests/gem_wait.c
+++ b/tests/gem_wait.c
@@ -27,18 +27,6 @@
 
 #include "igt.h"
 
-#include 
-#include 
-#include 
-
-#define gettid() syscall(__NR_gettid)
-#define sigev_notify_thread_id _sigev_un._tid
-
-#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
-#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
-
-#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
-
 static int __gem_wait(int fd, struct drm_i915_gem_wait *w)
 {
int err;
@@ -75,14 +63,6 @@ static void invalid_buf(int fd)
igt_assert_eq(__gem_wait(fd, ), -ENOENT);
 }
 
-static uint32_t *batch;
-
-static void sigiter(int sig, siginfo_t *info, void *arg)
-{
-   *batch = MI_BATCH_BUFFER_END;
-   __sync_synchronize();
-}
-
 #define MSEC_PER_SEC (1000)
 #define USEC_PER_SEC (1000 * MSEC_PER_SEC)
 #define NSEC_PER_SEC (1000 * USEC_PER_SEC)
@@ -91,113 +71,26 @@ static void sigiter(int sig, siginfo_t *info, void *arg)
 #define HANG 2
 static void basic(int fd, unsigned engine, unsigned flags)
 {
-   const int gen = intel_gen(intel_get_drm_devid(fd));
-   struct drm_i915_gem_exec_object2 obj;
-   struct drm_i915_gem_relocation_entry reloc;
-   struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_wait wait;
-   unsigned engines[16];
-   unsigned nengine;
-   int i, timeout;
-
-   nengine = 0;
-   if (engine == -1) {
-   for_each_engine(fd, engine)
-   if (engine) engines[nengine++] = engine;
-   } else {
-   igt_require(gem_has_ring(fd, engine));
-   engines[nengine++] = engine;
-   }
-   igt_require(nengine);
-
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = (uintptr_t)
-   execbuf.buffer_count = 1;
-
-   memset(, 0, sizeof(obj));
-   obj.handle = gem_create(fd, 4096);
-
-   obj.relocs_ptr = (uintptr_t)
-   obj.relocation_count = 1;
-   memset(, 0, sizeof(reloc));
-
-   batch = gem_mmap__gtt(fd, obj.handle, 4096, PROT_WRITE);
-   gem_set_domain(fd, obj.handle,
-   I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
-
-   reloc.target_handle = obj.handle; /* recurse */
-   reloc.presumed_offset = 0;
-   reloc.offset = sizeof(uint32_t);
-   reloc.delta = 0;
-   reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
-   reloc.write_domain = 0;
-
-   i = 0;
-   batch[i] = MI_BATCH_BUFFER_START;
-   if (gen >= 8) {
-   batch[i] |= 1 << 8 | 1;
-   batch[++i] = 0;
-   batch[++i] = 0;
-   } else if (gen >= 6) {
-   batch[i] |= 1 << 8;
-   batch[++i] = 0;
-   } else {
-   batch[i] |= 2 << 6;
-   batch[++i] = 0;
-   if (gen < 4) {
-   batch[i] |= 1;
-   reloc.delta = 1;
-   }
-   }
-
-   for (i = 0; i < nengine; i++) {
-   execbuf.flags &= ~ENGINE_MASK;
-   execbuf.flags |= engines[i];
-   gem_execbuf(fd, );
-   }
+   int wait_s = (flags == 0) ? NSEC_PER_SEC : 0;
+   wait_s = ((flags & HANG) == 0) ? wait_s : -1;
+   igt_spin_t spin = igt_spin_batch(fd, wait_s, engine, 0);
+   int timeout;
 
memset(, 0, sizeof(wait));
-   wait.bo_handle = obj.handle;
-   igt_assert_eq(__gem_wait(fd, ), -ETIME);
+   wait.bo_handle = spin.handle;
 
if (flags & BUSY) {
struct timespec tv;
 
timeout = 120;
-   if ((flags & HANG) == 0) {
-   *batch = MI_BATCH_BUFFER_END;
-   __sync_synchronize();
+   if ((flags & HANG) == 0)
timeout = 1;
-   }
 
memset(, 0, sizeof(tv));
while (__gem_wait(fd, ) == -ETIME)
igt_assert(igt_seconds_elapsed() < timeout);
} else {
-   timer_t timer;
-
-   if ((flags & HANG) == 0) {
-   struct sigevent sev;
-   struct sigaction act;
-   struct itimerspec its;
-
-   memset(, 0, sizeof(sev));
-   sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
-   sev.sigev_notify_thread_id = gettid();
-   sev.sigev_signo = SIGRTMIN + 1;
-   igt_assert(timer_create(CLOCK_MONOTONIC, , ) 
== 0);
-
-   memset(, 0, sizeof(act));
-   act.sa_sigaction = sigiter;
-   act.sa_flags = 

[Intel-gfx] [PATCH v4 1/3] lib: add igt_dummyload

[Abdiel Janulgue]

A lot of igt testcases need some GPU workload to make sure a race
window is big enough. Unfortunately having a fixed amount of
workload leads to spurious test failures or overtly long runtimes
on some fast/slow platforms. This library contains functionality
to submit GPU workloads that should consume exactly a specific
amount of time.

v2 : Add recursive batch feature from Chris
v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch
 by adding a dummy reloc to the bo as suggested by Ville.
v4:  Fix dependency reloc as write instead of read (Ville).
 Fix wrong handling of batchbuffer start on ILK causing
 test failure

Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Signed-off-by: Abdiel Janulgue 
---
 lib/Makefile.sources |   2 +
 lib/igt.h|   1 +
 lib/igt_dummyload.c  | 274 +++
 lib/igt_dummyload.h  |  42 
 4 files changed, 319 insertions(+)
 create mode 100644 lib/igt_dummyload.c
 create mode 100644 lib/igt_dummyload.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index e8e277b..7fc5ec2 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -75,6 +75,8 @@ lib_source_list = \
igt_draw.h  \
igt_pm.c\
igt_pm.h\
+   igt_dummyload.c \
+   igt_dummyload.h \
uwildmat/uwildmat.h \
uwildmat/uwildmat.c \
$(NULL)
diff --git a/lib/igt.h b/lib/igt.h
index d751f24..a0028d5 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -32,6 +32,7 @@
 #include "igt_core.h"
 #include "igt_debugfs.h"
 #include "igt_draw.h"
+#include "igt_dummyload.h"
 #include "igt_fb.h"
 #include "igt_gt.h"
 #include "igt_kms.h"
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
new file mode 100644
index 000..2d05594
--- /dev/null
+++ b/lib/igt_dummyload.c
@@ -0,0 +1,274 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "igt_dummyload.h"
+#include 
+#include 
+#include 
+
+/**
+ * SECTION:igt_dummyload
+ * @short_description: Library for submitting GPU workloads
+ * @title: Dummyload
+ * @include: igt.h
+ *
+ * A lot of igt testcases need some GPU workload to make sure a race window is
+ * big enough. Unfortunately having a fixed amount of workload leads to
+ * spurious test failures or overtly long runtimes on some fast/slow platforms.
+ * This library contains functionality to submit GPU workloads that should
+ * consume exactly a specific amount of time.
+ */
+
+#define NSEC_PER_SEC 10L
+
+#define gettid() syscall(__NR_gettid)
+#define sigev_notify_thread_id _sigev_un._tid
+
+#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
+#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
+
+#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+
+static void
+fill_object(struct drm_i915_gem_exec_object2 *obj, uint32_t gem_handle,
+   struct drm_i915_gem_relocation_entry *relocs, uint32_t count)
+{
+   memset(obj, 0, sizeof(*obj));
+   obj->handle = gem_handle;
+   obj->relocation_count = count;
+   obj->relocs_ptr = (uintptr_t)relocs;
+}
+
+static void
+fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
+  uint32_t gem_handle, uint32_t offset,
+  uint32_t read_domains, uint32_t write_domains)
+{
+   reloc->target_handle = gem_handle;
+   reloc->delta = 0;
+   reloc->offset = offset * sizeof(uint32_t);
+   reloc->presumed_offset = 0;
+   reloc->read_domains = read_domains;
+   reloc->write_domain = write_domains;
+}
+
+
+static uint32_t *batch;
+
+static uint32_t emit_recursive_batch(int fd, int engine, unsigned dep_handle)
+{
+   const int gen 

[Intel-gfx] [PATCH v4 3/3] igt/kms_flip: Use new igt_spin_batch

[Abdiel Janulgue]

Cc: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Abdiel Janulgue 
---
 tests/kms_flip.c | 185 ++-
 1 file changed, 4 insertions(+), 181 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6a1549e..79cb783 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -191,109 +191,6 @@ static unsigned long gettime_us(void)
return ts.tv_sec * 100 + ts.tv_nsec / 1000;
 }
 
-static int calibrate_dummy_load(struct test_output *o,
-   const char *ring_name,
-   int (*emit)(struct test_output *o, int limit, 
int timeout))
-{
-   unsigned long start;
-   int ops = 1;
-
-   start = gettime_us();
-
-   do {
-   unsigned long diff;
-   int ret;
-
-   ret = emit(o, (ops+1)/2, 10);
-   diff = gettime_us() - start;
-
-   if (ret || diff / USEC_PER_SEC >= 1)
-   break;
-
-   ops += ops;
-   } while (ops < 10);
-
-   igt_debug("%s dummy load calibrated: %d operations / second\n",
- ring_name, ops);
-
-   return ops;
-}
-
-static void blit_copy(drm_intel_bo *dst, drm_intel_bo *src,
- unsigned int width, unsigned int height,
- unsigned int dst_pitch, unsigned int src_pitch)
-{
-   BLIT_COPY_BATCH_START(0);
-   OUT_BATCH((3 << 24) | /* 32 bits */
- (0xcc << 16) | /* copy ROP */
- dst_pitch);
-   OUT_BATCH(0 << 16 | 0);
-   OUT_BATCH(height << 16 | width);
-   OUT_RELOC_FENCED(dst, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 
0);
-   OUT_BATCH(0 << 16 | 0);
-   OUT_BATCH(src_pitch);
-   OUT_RELOC_FENCED(src, I915_GEM_DOMAIN_RENDER, 0, 0);
-   ADVANCE_BATCH();
-
-   if (batch->gen >= 6) {
-   BEGIN_BATCH(3, 0);
-   OUT_BATCH(XY_SETUP_CLIP_BLT_CMD);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   ADVANCE_BATCH();
-   }
-}
-
-static int _emit_dummy_load__bcs(struct test_output *o, int limit, int timeout)
-{
-   int i, ret = 0;
-   drm_intel_bo *src_bo, *dst_bo, *fb_bo;
-   struct igt_fb *fb_info = >fb_info[o->current_fb_id];
-
-   igt_require(bufmgr);
-
-   src_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(src_bo);
-
-   dst_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(dst_bo);
-
-   fb_bo = gem_handle_to_libdrm_bo(bufmgr, drm_fd, "imported", 
fb_info->gem_handle);
-   igt_assert(fb_bo);
-
-   for (i = 0; i < limit; i++) {
-   blit_copy(dst_bo, src_bo,
- 2048, 2048,
- 2048*4, 2048*4);
-
-   igt_swap(src_bo, dst_bo);
-   }
-   blit_copy(fb_bo, src_bo,
- min(o->fb_width, 2048), min(o->fb_height, 2048),
- fb_info->stride, 2048*4);
-   intel_batchbuffer_flush(batch);
-
-   if (timeout > 0)
-   ret = drm_intel_gem_bo_wait(fb_bo, timeout * NSEC_PER_SEC);
-
-   drm_intel_bo_unreference(src_bo);
-   drm_intel_bo_unreference(dst_bo);
-   drm_intel_bo_unreference(fb_bo);
-
-   return ret;
-}
-
-static void emit_dummy_load__bcs(struct test_output *o, int seconds)
-{
-   static int ops_per_sec;
-
-   if (ops_per_sec == 0)
-   ops_per_sec = calibrate_dummy_load(o, "bcs",
-  _emit_dummy_load__bcs);
-
-   _emit_dummy_load__bcs(o, seconds * ops_per_sec, 0);
-}
-
 static void emit_fence_stress(struct test_output *o)
 {
const int num_fences = gem_available_fences(drm_fd);
@@ -338,82 +235,6 @@ static void emit_fence_stress(struct test_output *o)
free(exec);
 }
 
-static int _emit_dummy_load__rcs(struct test_output *o, int limit, int timeout)
-{
-   const struct igt_fb *fb_info = >fb_info[o->current_fb_id];
-   igt_render_copyfunc_t copyfunc;
-   struct igt_buf sb[3], *src, *dst, *fb;
-   int i, ret = 0;
-
-   igt_require(bufmgr);
-
-   copyfunc = igt_get_render_copyfunc(devid);
-   if (copyfunc == NULL)
-   return _emit_dummy_load__bcs(o, limit, timeout);
-
-   sb[0].bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(sb[0].bo);
-   sb[0].size = sb[0].bo->size;
-   sb[0].tiling = I915_TILING_NONE;
-   sb[0].data = NULL;
-   sb[0].num_tiles = sb[0].bo->size;
-   sb[0].stride = 4 * 2048;
-
-   sb[1].bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(sb[1].bo);
-   sb[1].size = sb[1].bo->size;
-   sb[1].tiling = I915_TILING_NONE;
-   sb[1].data = NULL;
-   sb[1].num_tiles = sb[1].bo->size;
-   sb[1].stride = 4 * 2048;
-
-   sb[2].bo = 

Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

[Christian König]

Am 07.11.2016 um 01:48 schrieb Eric Engestrom:

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

 drm: make drm_get_format_name thread-safe

 Signed-off-by: Eric Engestrom 
 [danvet: Clarify that the returned pointer must be freed with
 kfree().]
 Signed-off-by: Daniel Vetter 

Cc: Rob Clark 
Cc: Christian König 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 

Acked-by: Christian König .


---

v2: use single-field struct instead of typedef to let the compiler
 enforce the type (Christian König)

---
  include/drm/drm_fourcc.h| 10 +-
  drivers/gpu/drm/drm_fourcc.c| 14 +++--
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
  drivers/gpu/drm/drm_atomic.c|  7 +++--
  drivers/gpu/drm/drm_crtc.c  |  7 +++--
  drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
  drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
  drivers/gpu/drm/drm_plane.c |  7 +++--
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
  drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
  drivers/gpu/drm/i915/intel_display.c| 41 ++---
  drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
  17 files changed, 80 insertions(+), 86 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..4b03ca0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -45,6 +45,14 @@ struct drm_format_info {
u8 vsub;
  };
  
+/**

+ * struct drm_format_name_buf - name of a DRM format
+ * @str: string buffer containing the format name
+ */
+struct drm_format_name_buf {
+   char str[32];
+};
+
  const struct drm_format_info *__drm_format_info(u32 format);
  const struct drm_format_info *drm_format_info(u32 format);
  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
@@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
  int drm_format_vert_chroma_subsampling(uint32_t format);
  int drm_format_plane_width(int width, uint32_t format, int plane);
  int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
  
  #endif /* __DRM_FOURCC_H__ */

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..99b0b60 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
  EXPORT_SYMBOL(drm_mode_legacy_fb_format);
  
  /**

- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
   * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
   */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
  {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf->str, sizeof(buf->str),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
  
-	return buf;

+   return buf->str;
  }
  EXPORT_SYMBOL(drm_get_format_name);
  
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c

index 199d3f7..2924cdd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   struct drm_format_name_buf format_name;
  
  	/* no fb bound */

if (!atomic && !crtc->primary->fb) {
@@ -2144,9 +2144,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   DRM_ERROR("Unsupported screen format %s\n", format_name);
+ 

Re: [Intel-gfx] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio

[Pierre-Louis Bossart]

On 11/3/16 5:01 PM, Daniel Vetter wrote:

On Sat, Oct 1, 2016 at 2:22 AM, Jerome Anand  wrote:

Legacy Hdmi audio drivers are added.
Added support for audio/ gfx interface using irq chip framework


Just discussed this with Rakesh here at LPC and also with Mark Brown
and since earlier this years there's no a standard way to do this in
include/sound/hdmi-codec.h. I think it'd be good to port this over to
this new interface before merging. And if it makes sense (and ofc
afterwards when there's time) to port over the existing
i915_component.h to hdmi-codec.h.


I am all for convergence when it makes sense but I don't see how 
hdmi-codec.h provides equivalent functionality for BYT/CHT with what was 
suggested in this patchset -derived from VED patches- and discussed 
earlier with intel-gfx folks, specifically how LPE pipe interrupts are 
masked/unmasked and passed to the audio driver? The BYT/CHT HDMI 
functionality is also not modeled as an ASoC codec - which seems a 
dependency from the comments in hdmi-codec.h - since it's really part of 
the i915 hardware and exposed only as a set of registers+DMA, without 
any serial link interface typically needed for an external device or the 
internal HDAudio-display link.


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

[Intel-gfx] [PATCH] shmem: fix pageflags after swapping DMA32 object

[Hugh Dickins]

If shmem_alloc_page() does not set PageLocked and PageSwapBacked, then
shmem_replace_page() needs to do so for itself.  Without this, it puts
newpage on the wrong lru, re-unlocks the unlocked newpage, and system
descends into "Bad page" reports and freeze; or if CONFIG_DEBUG_VM=y,
it hits an earlier VM_BUG_ON_PAGE(!PageLocked), depending on config.

But shmem_replace_page() is not a common path: it's only called when
swapin (or swapoff) finds the page was already read into an unsuitable
zone: usually all zones are suitable, but gem objects for a few drm
devices (gma500, omapdrm, crestline, broadwater) require zone DMA32
if there's more than 4GB of ram.

Fixes: 800d8c63b2e9 ("shmem: add huge pages support")
Cc: sta...@vger.kernel.org # v4.8
Signed-off-by: Hugh Dickins 
---

 mm/shmem.c |2 ++
 1 file changed, 2 insertions(+)

--- 4.9-rc4/mm/shmem.c  2016-10-15 12:52:13.157533478 -0700
+++ linux/mm/shmem.c2016-11-06 12:45:49.626193769 -0800
@@ -1483,6 +1483,8 @@ static int shmem_replace_page(struct pag
copy_highpage(newpage, oldpage);
flush_dcache_page(newpage);
 
+   __SetPageLocked(newpage);
+   __SetPageSwapBacked(newpage);
SetPageUptodate(newpage);
set_page_private(newpage, swap_index);
SetPageSwapCache(newpage);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: move allocation out of drm_get_format_name() (rev2)

[Patchwork]

== Series Details ==

Series: drm: move allocation out of drm_get_format_name() (rev2)
URL   : https://patchwork.freedesktop.org/series/14873/
State : warning

== Summary ==

Series 14873v2 drm: move allocation out of drm_get_format_name()
https://patchwork.freedesktop.org/api/1.0/series/14873/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test gem_sync:
Subgroup basic-store-all:
fail   -> PASS   (fi-hsw-4770r)
Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> DMESG-WARN (fi-snb-2520m)

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

49a651a2e66ef603995f88a470d0986c2ef8b5b8 drm-intel-nightly: 
2016y-11m-04d-18h-04m-36s UTC integration manifest
6300c7f drm: move allocation out of drm_get_format_name()

== Logs ==

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

[Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

[Eric Engestrom]

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

drm: make drm_get_format_name thread-safe

Signed-off-by: Eric Engestrom 
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter 

Cc: Rob Clark 
Cc: Christian König 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 
---

v2: use single-field struct instead of typedef to let the compiler
enforce the type (Christian König)

---
 include/drm/drm_fourcc.h| 10 +-
 drivers/gpu/drm/drm_fourcc.c| 14 +++--
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
 drivers/gpu/drm/drm_atomic.c|  7 +++--
 drivers/gpu/drm/drm_crtc.c  |  7 +++--
 drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
 drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
 drivers/gpu/drm/drm_plane.c |  7 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
 drivers/gpu/drm/i915/intel_display.c| 41 ++---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
 17 files changed, 80 insertions(+), 86 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..4b03ca0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -45,6 +45,14 @@ struct drm_format_info {
u8 vsub;
 };
 
+/**
+ * struct drm_format_name_buf - name of a DRM format
+ * @str: string buffer containing the format name
+ */
+struct drm_format_name_buf {
+   char str[32];
+};
+
 const struct drm_format_info *__drm_format_info(u32 format);
 const struct drm_format_info *drm_format_info(u32 format);
 uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
@@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
 
 #endif /* __DRM_FOURCC_H__ */
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..99b0b60 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
 EXPORT_SYMBOL(drm_mode_legacy_fb_format);
 
 /**
- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
  */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf->str, sizeof(buf->str),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
 
-   return buf;
+   return buf->str;
 }
 EXPORT_SYMBOL(drm_get_format_name);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 199d3f7..2924cdd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   struct drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -2144,9 +2144,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   DRM_ERROR("Unsupported screen format %s\n", format_name);
+   DRM_ERROR("Unsupported screen format %s\n",
+ drm_get_format_name(target_fb->pixel_format, 
_name));
- 

Re: [Intel-gfx] [PATCH] drm: move allocation out of drm_get_format_name()

[Eric Engestrom]

On Sunday, 2016-11-06 08:03:47 -0500, Rob Clark wrote:
> On Sun, Nov 6, 2016 at 4:47 AM, Christian König
>  wrote:
> > Am 05.11.2016 um 17:49 schrieb Rob Clark:
> >>
> >> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom  wrote:
> >>>
> >>> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
> 
>  Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
> >
> > +typedef char drm_format_name_buf[32];
> 
>  Please don't use a typedef for this, just define the maximum size of
>  characters the function might write somewhere.
> 
>  See the kernel coding style as well:
> >
> > In general, a pointer, or a struct that has elements that can
> > reasonably
> > be directly accessed should **never** be a typedef.
> >>>
> >>> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
> >>> them way too much), and your way was what I wrote at first, but Rob
> >>> Clark's
> >>> typedef idea makes it much harder for someone to allocate a buffer of
> >>> the wrong size, which IMO is good thing here.
> >>
> >> IMHO I would make a small test program to verify this actually helps
> >> the compiler catch problems.  And if it does, I would stick with it.
> >> The coding-style should be guidelines, not something that supersedes
> >> common sense / practicality.
> >
> >
> > Well completely agree that we should be able to question the coding style
> > rules, but when we do it we discuss this on a the mailing list first and
> > then start to use it in code. Not the other way around.
> 
> if I'm not mistaken, that is what we are doing ;-)
> 
> >>
> >> That is my $0.02 anyways.. if others vehemently disagree and want to
> >> dogmatically stick to the coding-style guidelines, ok then.  OTOH, if
> >> this approach doesn't help the compiler catch issues, then it isn't
> >> worth it.
> >
> >
> > Yeah, exactly that's the point. If I'm not completely mistaken the compiler
> > won't issue a warning here if you pass an array with the wrong size.
> >
> > I think you need something like "struct drm_format_name_buf { char str[32];
> > };" to trigger this.
> 
> hmm, actually the struct is a nice idea then if the compiler wouldn't
> catch the wrong-size-array

Sending the patch in a minute.

> 
> > apart from that is this function really called so often that using
> > kasprintf() is a problem here? or is there another motivation behind the
> > change?
> 
> two things trouble me about the kasprintf approach.. (ignoring the
> fact that atm it is not gfp_atomic)
> 1) you can't do drm_debug("format: %s\n", drm_get_format_name(..)) so
> it pulls the memory allocation and sprintf outside of the drm_debug
> check
> 2) seems awfully easy to forget the kfree...

I actually found a couple of these memory leaks while doing this patch,
look for files where i don't remove kfree :)
(eg. vmwgfx at the end of the patch)

> i wouldn't have even
> known that now you need to free the result (with some patches i'm
> working on) if it weren't for the fact that lockdep alerted me to the
> gfp_kernel allocation in atomic ctx ;-)
> 
> br,
> -r
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [Regression report] Weekly regression report WW45

[Jairo Miramontes]

Total regressions: 48

This week regressions:2
+---+--+++
| BugId | Summary | Created on | Bisect |
+---+--+++
| 98553 | [IVB HSW] [Basic] performance failure when running kms_setmode 
basic | 2016-11-02 | No |
| 98517 | Skylake gen6 suspend/resume video regression 
4.9 | 2016-10-31 | No |

+---+--+++

Previous regressions:46
+---+--+++
| BugId | Summary | Created on | Bisect |
+---+--+++
| 98462 | [KBL] [IGT] [regression] kms_3d [drm:drm_dp_dpcd_access] Too 
many retries, givin | 2016-10-27 | No |
| 98460 | [SNB] [regression] [igt] gem_busy@extended-parallel-render  
Failed assertion: !" | 2016-10-27 | No |
| 98402 | [HSW] [regression] 4.9-rc1 shows corruption with mpv's 
vaapi-copy| 2016-10-23 | No |
| 98289 | [BDW] kms_flip / vblank-vs-suspend-interruptible is 
failing  | 2016-10-17 | No |
| 98290 | [BDW] kms_frontbuffer_tracking fbc-suspend 
fails | 2016-10-17 | No |
| 98211 | i915 / drm crash when undocking from DP 
monitors | 2016-10-12 | No |
| 98036 | [BYT] constant screen flicker and rendering errors 
[regression]  | 2016-10-03 | Yes|
| 97994 | [REGRESS] [BISECT] [i915] Monitor resolution 
lost| 2016-09-30 | Yes|
| 97918 | [bdw regression 4.8] Severe graphics regression, rainbow 
glitching and flickerin | 2016-09-25 | No |
| 97878 | [SKL][REGRESSION][BISECTED] Dropped frames and FIFO underruns 
when moving mouse  | 2016-09-20 | Yes|
| 97867 | [HSW][Regression] 4.6.7 and beyond causes screen flickering 
whereas 4.5.5 works  | 2016-09-19 | No |
| 97666 | Kernel "NULL pointer dereference" with MST monitor on 
HSW| 2016-09-08 | Yes|
| 97017 | [SKL GT3e guc bisected] ~10% performance drop in most 
benchmarks | 2016-07-21 | Yes|
| 96938 | [HSW modeset regression] i915/drm locks up when quitting X and 
returning to fbde | 2016-07-15 | No |
| 96916 | Regression: screen flashes with PSR 
enabled  | 2016-07-13 | No |
| 96736 | kernel 4.6 regression: PSR causes screen to 
flash| 2016-06-29 | Yes|
| 96704 | kernel 4.6 regression: PSR on Haswell causes screen to 
flash | 2016-06-28 | Yes|
| 96645 | [regression 4.7] [BISECT]Low package c-states used only after 
forcing DPMS to of | 2016-06-22 | Yes|
| 96428 | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR* dp aux hw did not 
signal timeout (h | 2016-06-07 | Yes|
| 95736 | [IVB bisected] *ERROR* uncleared fifo underrun on pipe 
A | 2016-05-24 | Yes|
| 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode 
8:2:0xfffe | 2016-04-28 | No |
| 95097 | [hdmi regression ilk] no signal to 
TV| 2016-04-24 | No |
| 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend 
regression   | 2016-03-17 | No |
| 94430 | [HSW+nvidia] regression: display becomes "disconnected" while 
suspended  | 2016-03-07 | No |
| 94337 | Linux 4.5 regression: FIFO underruns on 
Skylake  | 2016-02-29 | No |
| 93971 | video framerate performance regression with 
UXA  | 2016-02-02 | Yes|
| 93802 | [IVB bisected] switching to tty1 causes fifo underrun on pipe 
B and pipe C   | 2016-01-20 | Yes|
| 93782 | [i9xx TV][BISECT] vblank wait timeout on 
crtc| 2016-01-19 | Yes|
| 93486 | [HP Compaq dc7800 Small Form Factor PC][REGRESSION] 
suspend/resume failure   | 2015-12-23 | No |
| 93393 | Regression for Skylake modesetting in kernel 4.4 with 2 
Displays of different re | 2015-12-16 | No |
| 93361 | 12bpc hdmi causes wrong real refresh rate (swapbuffers return 
time)  | 2015-12-12 | Yes|
| 93263 | 945GM regression since 
4.3   | 2015-12-05 | 
No |
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will not stay in S3 
suspend [REGRESSION] | 2015-10-10 | Yes|
| 92237 | [SNB]Horrible noise (audio) via DisplayPort 
[regression] | 2015-10-02 | No |
| 92050 | [regression]/bug introduced by commit 
[0e572fe7383a376992364914694c39aa7fe44c1d] | 2015-09-19 | Yes|
| 91974 | [bisected] unrecoverable black 

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Sonntag, 6. November 2016, 17:25:15 CET schrieb Mihai Donțu:
> On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > > So it's once again a Saturday afternoon rather than Sunday, this time
> > > because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
> 
> The proposed patch appears to be:
> https://patchwork.freedesktop.org/patch/116808/
> 
> Have not tested it yet.

This patch does not fix the issue for me. Still the same graphical glitches.

Thanks,
Martin

> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).


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

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Sonntag, 6. November 2016, 17:25:15 CET schrieb Mihai Donțu:
> On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > > So it's once again a Saturday afternoon rather than Sunday, this time
> > > because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
> 
> The proposed patch appears to be:
> https://patchwork.freedesktop.org/patch/116808/
> 
> Have not tested it yet.

Thank you.

It applies cleanly. I think I get a chance to test it this week.

Thanks,
Martin

> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).


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

Re: [Intel-gfx] [ANNOUNCE] 2016-Q3 release of KVMGT (Was Re: KVMGT - the implementation of ...)

[Jike Song]

Hi all,

While spending efforts for upstreaming, we are pleased to announce another 
update of Intel GVT-g for KVM.

Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core(TM) processors 
with Intel Graphics processors.  A virtual GPU instance is maintained for each 
VM, with part of performance critical resources directly assigned. The 
capability of running native graphics driver inside a VM, without hypervisor 
intervention in performance critical paths, achieves a good balance among 
performance, feature, and sharing capability.

Repositories:

-Kernel: https://github.com/01org/igvtg-kernel (2016q3-4.3.0 branch)
-Qemu: https://github.com/01org/igvtg-qemu (2016q3-2.3.0 branch)

This update consists of:
-Preliminary support new platform: KabyLake, for windows OS, it only 
supports Win10 RedStone 64 bit.
-Windows 10 RedStone guest Support
-Windows Guest QoS preliminary support:  Administrators now are able to 
control the maximum amount of vGPU resource to be consumed by each VM from 
value 1% ~ 99%"
-Display virtualization preliminary support: Besides the tracking of 
display register visit in guest VM, removing irrelative display pipeline info 
between host and guest VM
-Live Migration and savevm/restorevm preliminary support on BDW with 2D/3D 
workload running

Known issues:
-   At least 2GB memory is suggested for Guest Virtual Machine (win7-32/64, 
win8.1-64, win10-64) to run most 3D workloads
-   Windows8 and later Windows fast boot is not supported, the workaround is to 
disable power S3/S4 in HVM file by adding "acpi_S3=0, acpi_S4=0"
-   Sometimes when dom0 and guest has heavy workload, i915 in dom0 will trigger 
a false-alarmed TDR. The workaround is to disable dom0 hangcheck in dom0 grub 
file by adding "i915.enable_hangcheck=0"
-   Stability: When QoS feature is enabled, Windows guest full GPU reset is 
often trigger during MTBF test.  This bug will be fixed in next release
-   Windows guest running OpenCL allocations occurs to host crash; the 
workaround is to disable logd in dom0 grub file by adding "i915.logd_enable=0"

Please subscribe the mailing list: https://lists.01.org/mailman/listinfo/igvt-g

Official iGVT-g portal: https://01.org/igvt-g

More information about background, architecture and others about Intel GVT-g, 
can be found at:

http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian


Note:
The KVMGT project should be considered a work in progress. As such it is not a 
complete product nor should it be considered one. Extra care should be taken 
when testing and configuring a system to use the KVMGT project.

--
Thanks,
Jike

On 07/20/2016 12:52 PM, Jike Song wrote:
> Hi all,
> 
> We are pleased to announce another update of Intel GVT-g for KVM.
> 
> Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
> mediated pass-through, starting from 5th generation Intel Core™ processors 
> with Intel Graphics processors.  A virtual GPU instance is maintained for 
> each VM, with part of performance critical resources directly assigned. The 
> capability of running native graphics driver inside a VM, without hypervisor 
> intervention in performance critical paths, achieves a good balance among 
> performance, feature, and sharing capability.
> 
> Repositories:
> 
>- Kernel: https://github.com/01org/igvtg-kernel (2016q2-4.3.0 branch)
>- Qemu: https://github.com/01org/igvtg-qemu (2016q2-2.3.0 branch)
> 
> This update consists of:
>- KVMGT stable release for Xeon E3 v4 (Broadwell), E3 v5(Skylake), Intel 
> Core™ processors 5th generation (Boadwell) , 6th generation (Skylake)
>- 2D/3D/Media workloads can run simultaneously in multiple guests
> 
> Known issues:
>- At least 2GB memory is suggested for Guest Virtual Machine (VM) to run 
> most 3D workloads.
>- Using Windows Media Player play videos may cause host crash. Using VLC 
> to play .ogg file may cause mosaic or slow response.
>- Suggest to X window mode like xinit instead of lightdm to launch host if 
> running heavy workload in both guest and host for more than 6 hours.
>- Change i915.preemption_policy=3 in host kernel cmdline, if you see 
> problem when running heavy 3D workloads in multiple Guests (>=3) in some 
> extreme stress configuration.
> 
> 
> Please subscribe to join the mailing list:
>- https://lists.01.org/mailman/listinfo/igvt-g
> 
> Official iGVT-g portal:
>- https://01.org/igvt-g
> 
> More information about background, architecture and others about Intel GVT-g, 
> can be found at:
> 
> http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
> 
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> 
> 
> Note:
> The KVMGT project should be considered a work in progress. As such it is not 
> a complete product nor 

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Mihai Donțu]

On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> Hi.
> 
> Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > So it's once again a Saturday afternoon rather than Sunday, this time
> > because I felt this rc was already big enough.  
> 
> With kernel 4.9-rc4 I saw gfx corruptions like
> 
> https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> 
> in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the 
> point of not being able to use these applications in a meaningful way.
> 
> I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet 
> after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx 
> glitches like that anymore.
> 
> Anything known about this?

https://bugzilla.kernel.org/show_bug.cgi?id=177701

The proposed patch appears to be:
https://patchwork.freedesktop.org/patch/116808/

Have not tested it yet.

> Machine is ThinkPad T520 with Sandybridge graphics.
> 
> Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> 
> Next week and weekend will be pretty busy and this is a production machine, 
> so 
> bisection or any other time-consuming work on this is out of question for me. 
> I can provide additional details in case they are easy and quick enough to 
> obtain.
> 
> 
> System information (now back on 4.8 kernel):
> 
> # phoronix-test-suite system-info
> 
> Phoronix Test Suite v5.2.1
> System Information
> 
> Hardware:
> Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
> 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
> Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
> Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
> Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> 
> Software:
> OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks 
> 5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, 
> OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, 
> Screen Resolution: 3840x1080
> 
> 
> # apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> core)" | grep amd64
> libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> 
> 
> Excerpt of glxinfo:
> 
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: Intel Open Source Technology Center (0x8086)
> Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> Version: 12.0.3
> Accelerated: yes
> Video memory: 1536MB
> Unified memory: yes
> Preferred profile: core (0x1)
> Max core profile version: 3.3
> Max compat profile version: 3.0
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.0
> 
> X.org runs with modesetting driver (default was changed in Debian Sid a while 
> back).

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

Re: [Intel-gfx] [Announcement] 2016-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Jike Song]

Hi all,

We are pleased to announce another update of Intel GVT-g for Xen.

Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
starting from 4th generation Intel Core(TM) processors with Intel Graphics 
processors. A virtual GPU instance is maintained for each VM, with part of 
performance critical resources directly assigned. The capability of running 
native graphics driver inside a VM, without hypervisor intervention in 
performance critical paths, achieves a good balance among performance, feature, 
and sharing capability. Xen is currently supported on Intel Processor Graphics 
(a.k.a. XenGT).


Repositories

-Xen: https://github.com/01org/igvtg-xen (2016q3-4.6 branch)
-Kernel: https://github.com/01org/igvtg-kernel (2016q3-4.3.0 branch)
-Qemu: https://github.com/01org/igvtg-qemu (2016q3-2.3.0 branch)


This update consists of:

-Preliminary support new platform: 7th generation Intel® Core™ processors. 
For windows OS, it only supports Win10 RedStone 64 bit.

-Windows 10 RedStone guest Support

-Windows Guest QoS preliminary support:  Administrators now are able to 
control the maximum amount of vGPU resource to be consumed by each VM from 
value 1% ~ 99%”

-Display virtualization preliminary support: Besides the tracking of 
display register visit in guest VM, removing irrelative display pipeline info 
between host and guest VM

-Live Migration and savevm/restorevm preliminary support on BDW with 2D/3D 
workload running



Known issues:

-   At least 2GB memory is suggested for Guest Virtual Machine (win7-32/64, 
win8.1-64, win10-64) to run most 3D workloads

-   Windows8 and later Windows fast boot is not supported, the workaround is to 
disable power S3/S4 in HVM file by adding “acpi_S3=0, acpi_S4=0”

-   Sometimes when dom0 and guest has heavy workload, i915 in dom0 will trigger 
a false-alarmed TDR. The workaround is to disable dom0 hangcheck in dom0 grub 
file by adding “i915.enable_hangcheck=0”

-   Stability: When QoS feature is enabled, Windows guest full GPU reset is 
often trigger during MTBF test.  This bug will be fixed in next release

-   Windows guest running OpenCL allocations occurs to host crash; the 
workaround is to disable logd in dom0 grub file by adding “i915. logd_enable =0”


Next update will be around early Jan, 2017.


GVT-g project portal: https://01.org/igvt-g
Please subscribe mailing list: https://lists.01.org/mailman/listinfo/igvt-g


More information about background, architecture and others about Intel GVT-g, 
can be found at:

https://01.org/igvt-g
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-REWRITE%203RD%20v4.pdf
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt


Note: The XenGT project should be considered a work in progress. As such it is 
not a complete product nor should it be considered one. Extra care should be 
taken when testing and configuring a system to use the XenGT project.

--
Thanks,
Jike

On 07/22/2016 01:42 PM, Jike Song wrote:
> Hi all,
> 
> We are pleased to announce another update of Intel GVT-g for Xen.
> 
> Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
> starting from 4th generation Intel Core(TM) processors with Intel Graphics 
> processors. A virtual GPU instance is maintained for each VM, with part of 
> performance critical resources directly assigned. The capability of running 
> native graphics driver inside a VM, without hypervisor intervention in 
> performance critical paths, achieves a good balance among performance, 
> feature, and sharing capability. Xen is currently supported on Intel 
> Processor Graphics (a.k.a. XenGT).
> 
> Repositories
> -Xen: https://github.com/01org/igvtg-xen (2016q2-4.6 branch)
> -Kernel: https://github.com/01org/igvtg-kernel (2016q2-4.3.0 branch)
> -Qemu: https://github.com/01org/igvtg-qemu (2016q2-2.3.0 branch)
> 
> This update consists of:
> -Support Windows 10 guest
> -Support Windows Graphics driver installation on both Windows Normal mode 
> and Safe mode
> 
> Known issues:
> -   At least 2GB memory is suggested for Guest Virtual Machine (VM) to run 
> most 3D workloads
> -   Dom0 S3 related feature is not supported
> -   Windows 8 and later versions: fast boot is not supported, the workaround 
> is to disable power S3/S4 in HVM file by adding "acpi_S3=0, acpi_S4=0"
> -   Using Windows Media Player play videos may cause host crash. Using VLC to 
> play .ogg file may cause mosaic or slow response.
> -   Sometimes when both dom0 and guest have heavy workloads, i915 in dom0 
> will trigger a false graphics reset,
> the workaround is to disable dom0 hangcheck in grub file by adding 
> "i915.enable_hangcheck=0".
> 
> Next update will be around early Oct, 

[Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Hi.

Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> So it's once again a Saturday afternoon rather than Sunday, this time
> because I felt this rc was already big enough.

With kernel 4.9-rc4 I saw gfx corruptions like

https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png

in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the 
point of not being able to use these applications in a meaningful way.

I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet 
after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx 
glitches like that anymore.

Anything known about this?

Machine is ThinkPad T520 with Sandybridge graphics.

Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.

Next week and weekend will be pretty busy and this is a production machine, so 
bisection or any other time-consuming work on this is out of question for me. 
I can provide additional details in case they are easy and quick enough to 
obtain.


System information (now back on 4.8 kernel):

# phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks 
5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, 
OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, 
Screen Resolution: 3840x1080


# apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
core)" | grep amd64
libdrm-intel1:amd64/sid 2.4.71-1 uptodate
libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate


Excerpt of glxinfo:

Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
Version: 12.0.3
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0

X.org runs with modesetting driver (default was changed in Debian Sid a while 
back).

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Remove chipset flush after cache flush

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Remove chipset flush after cache 
flush
URL   : https://patchwork.freedesktop.org/series/14897/
State : success

== Summary ==

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

Test gem_sync:
Subgroup basic-store-all:
fail   -> PASS   (fi-hsw-4770r)

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

49a651a2e66ef603995f88a470d0986c2ef8b5b8 drm-intel-nightly: 
2016y-11m-04d-18h-04m-36s UTC integration manifest
c1d20e5 drm/i915: Mark all skipped clflushes as leaving the CPU cache dirty
2f4ce55 drm/i915: Always flush the dirty CPU cache when pinning the scanout
51df37f drm/i915: Remove chipset flush after cache flush

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm: move allocation out of drm_get_format_name()

[Rob Clark]

On Sun, Nov 6, 2016 at 4:47 AM, Christian König
 wrote:
> Am 05.11.2016 um 17:49 schrieb Rob Clark:
>>
>> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom  wrote:
>>>
>>> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:

 Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
>
> +typedef char drm_format_name_buf[32];

 Please don't use a typedef for this, just define the maximum size of
 characters the function might write somewhere.

 See the kernel coding style as well:
>
> In general, a pointer, or a struct that has elements that can
> reasonably
> be directly accessed should **never** be a typedef.
>>>
>>> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
>>> them way too much), and your way was what I wrote at first, but Rob
>>> Clark's
>>> typedef idea makes it much harder for someone to allocate a buffer of
>>> the wrong size, which IMO is good thing here.
>>
>> IMHO I would make a small test program to verify this actually helps
>> the compiler catch problems.  And if it does, I would stick with it.
>> The coding-style should be guidelines, not something that supersedes
>> common sense / practicality.
>
>
> Well completely agree that we should be able to question the coding style
> rules, but when we do it we discuss this on a the mailing list first and
> then start to use it in code. Not the other way around.

if I'm not mistaken, that is what we are doing ;-)

>>
>> That is my $0.02 anyways.. if others vehemently disagree and want to
>> dogmatically stick to the coding-style guidelines, ok then.  OTOH, if
>> this approach doesn't help the compiler catch issues, then it isn't
>> worth it.
>
>
> Yeah, exactly that's the point. If I'm not completely mistaken the compiler
> won't issue a warning here if you pass an array with the wrong size.
>
> I think you need something like "struct drm_format_name_buf { char str[32];
> };" to trigger this.

hmm, actually the struct is a nice idea then if the compiler wouldn't
catch the wrong-size-array

> Apart from that is this function really called so often that using
> kasprintf() is a problem here? Or is there another motivation behind the
> change?

Two things trouble me about the kasprintf approach.. (ignoring the
fact that atm it is not GFP_ATOMIC)
1) you can't do DRM_DEBUG("format: %s\n", drm_get_format_name(..)) so
it pulls the memory allocation and sprintf outside of the drm_debug
check
2) seems awfully easy to forget the kfree...  I wouldn't have even
known that now you need to free the result (with some patches I'm
working on) if it weren't for the fact that lockdep alerted me to the
GFP_KERNEL allocation in atomic ctx ;-)

BR,
-R

> Regards,
> Christian.
>
>
>>
>> BR,
>> -R
>>
>>> I can rewrite the typedef out if you think it's better.
>>>
>>> Cheers,
>>>Eric
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915: Remove chipset flush after cache flush

[Chris Wilson]

We always flush the chipset prior to executing with the GPU, so we can
skip the flush during ordinary domain management.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 23 ---
 2 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4735b4177100..b35f96315930 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3405,7 +3405,7 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
 
 void i915_gem_reset(struct drm_i915_private *dev_priv);
 void i915_gem_set_wedged(struct drm_i915_private *dev_priv);
-bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
+void i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
 int __must_check i915_gem_init(struct drm_device *dev);
 int __must_check i915_gem_init_hw(struct drm_device *dev);
 void i915_gem_init_swizzling(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0dbf38c51d14..d48509783e41 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3179,23 +3179,22 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
return ret;
 }
 
-bool
-i915_gem_clflush_object(struct drm_i915_gem_object *obj,
-   bool force)
+void i915_gem_clflush_object(struct drm_i915_gem_object *obj,
+bool force)
 {
/* If we don't have a page list set up, then we're not pinned
 * to GPU, and we can ignore the cache flush because it'll happen
 * again at bind time.
 */
if (!obj->mm.pages)
-   return false;
+   return;
 
/*
 * Stolen memory is always coherent with the GPU as it is explicitly
 * marked as wc by the system, or the system is cache-coherent.
 */
if (obj->stolen || obj->phys_handle)
-   return false;
+   return;
 
/* If the GPU is snooping the contents of the CPU cache,
 * we do not need to manually clear the CPU cache lines.  However,
@@ -3207,14 +3206,12 @@ i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 */
if (!force && cpu_cache_is_coherent(obj->base.dev, obj->cache_level)) {
obj->cache_dirty = true;
-   return false;
+   return;
}
 
trace_i915_gem_object_clflush(obj);
drm_clflush_sg(obj->mm.pages);
obj->cache_dirty = false;
-
-   return true;
 }
 
 /** Flushes the GTT write domain for the object if it's dirty. */
@@ -3260,9 +3257,7 @@ i915_gem_object_flush_cpu_write_domain(struct 
drm_i915_gem_object *obj)
if (obj->base.write_domain != I915_GEM_DOMAIN_CPU)
return;
 
-   if (i915_gem_clflush_object(obj, obj->pin_display))
-   i915_gem_chipset_flush(to_i915(obj->base.dev));
-
+   i915_gem_clflush_object(obj, obj->pin_display);
intel_fb_obj_flush(obj, false, ORIGIN_CPU);
 
obj->base.write_domain = 0;
@@ -3469,10 +3464,8 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
 * object is now coherent at its new cache level (with respect
 * to the access domain).
 */
-   if (obj->cache_dirty && cpu_write_needs_clflush(obj)) {
-   if (i915_gem_clflush_object(obj, true))
-   i915_gem_chipset_flush(to_i915(obj->base.dev));
-   }
+   if (obj->cache_dirty && cpu_write_needs_clflush(obj))
+   i915_gem_clflush_object(obj, true);
 
return 0;
 }
-- 
2.10.2

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

[Intel-gfx] [PATCH 3/3] drm/i915: Mark all skipped clflushes as leaving the CPU cache dirty

[Chris Wilson]

Currently, we may skip the clflush on an object if the object has not
yet allocated any pages. However, the object may still be polluting the
CPU cache and may now be in a coherent uncached domain - and so no
longer generating clflushing.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6845cf03287c..e43fad3ccf24 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3182,20 +3182,25 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
 void i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 bool force)
 {
-   /* If we don't have a page list set up, then we're not pinned
-* to GPU, and we can ignore the cache flush because it'll happen
-* again at bind time.
-*/
-   if (!obj->mm.pages)
-   return;
-
/*
 * Stolen memory is always coherent with the GPU as it is explicitly
 * marked as wc by the system, or the system is cache-coherent.
+* Similarly, we only access struct pages through the CPU cache, so
+* anything not backed by physical memory we consider to be always
+* coherent and not need clflushing.
 */
-   if (obj->stolen || obj->phys_handle)
+   if (!i915_gem_object_has_struct_page(obj))
return;
 
+   /* If we don't have a page list set up, then we're not pinned
+* to GPU, and we can ignore the cache flush because it'll happen
+* again at bind time.
+*/
+   if (!obj->mm.pages) {
+   obj->cache_dirty = true;
+   return;
+   }
+
/* If the GPU is snooping the contents of the CPU cache,
 * we do not need to manually clear the CPU cache lines.  However,
 * the caches are only snooped when the render cache is
-- 
2.10.2

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

[Intel-gfx] [PATCH 2/3] drm/i915: Always flush the dirty CPU cache when pinning the scanout

[Chris Wilson]

Currently we only clflush the scanout if it is in the CPU domain. Also
flush if we have a pending CPU clflush. We also want to treat the
dirtyfb path similar, and flush any pending writes there as well.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c  | 9 +
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d48509783e41..6845cf03287c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3356,12 +3356,12 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
enum i915_cache_level cache_level)
 {
struct i915_vma *vma;
-   int ret = 0;
+   int ret;
 
lockdep_assert_held(>base.dev->struct_mutex);
 
if (obj->cache_level == cache_level)
-   goto out;
+   return 0;
 
/* Inspect the list of currently bound VMA and unbind any that would
 * be invalid given the new cache-level. This is principally to
@@ -3459,7 +3459,6 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
vma->node.color = cache_level;
obj->cache_level = cache_level;
 
-out:
/* Flush the dirty CPU caches to the backing storage so that the
 * object is now coherent at its new cache level (with respect
 * to the access domain).
@@ -3608,7 +3607,9 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
 
-   i915_gem_object_flush_cpu_write_domain(obj);
+   if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+   i915_gem_clflush_object(obj, true);
+   intel_fb_obj_flush(obj, false, ORIGIN_CPU);
 
old_write_domain = obj->base.write_domain;
old_read_domains = obj->base.read_domains;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 92ab01f33208..47233b242c99 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15698,6 +15698,8 @@ static int intel_user_framebuffer_dirty(struct 
drm_framebuffer *fb,
struct drm_i915_gem_object *obj = intel_fb->obj;
 
mutex_lock(>struct_mutex);
+   if (obj->pin_display && obj->cache_dirty)
+   i915_gem_clflush_object(obj, true);
intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
mutex_unlock(>struct_mutex);
 
-- 
2.10.2

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

Re: [Intel-gfx] [PATCH] drm: move allocation out of drm_get_format_name()

[Christian König]

Am 05.11.2016 um 17:49 schrieb Rob Clark:

On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom  wrote:

On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:

Am 05.11.2016 um 02:33 schrieb Eric Engestrom:

+typedef char drm_format_name_buf[32];

Please don't use a typedef for this, just define the maximum size of
characters the function might write somewhere.

See the kernel coding style as well:

In general, a pointer, or a struct that has elements that can reasonably
be directly accessed should **never** be a typedef.

I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
them way too much), and your way was what I wrote at first, but Rob Clark's
typedef idea makes it much harder for someone to allocate a buffer of
the wrong size, which IMO is good thing here.

IMHO I would make a small test program to verify this actually helps
the compiler catch problems.  And if it does, I would stick with it.
The coding-style should be guidelines, not something that supersedes
common sense / practicality.


Well completely agree that we should be able to question the coding 
style rules, but when we do it we discuss this on a the mailing list 
first and then start to use it in code. Not the other way around.




That is my $0.02 anyways.. if others vehemently disagree and want to
dogmatically stick to the coding-style guidelines, ok then.  OTOH, if
this approach doesn't help the compiler catch issues, then it isn't
worth it.


Yeah, exactly that's the point. If I'm not completely mistaken the 
compiler won't issue a warning here if you pass an array with the wrong 
size.


I think you need something like "struct drm_format_name_buf { char 
str[32]; };" to trigger this.


Apart from that is this function really called so often that using 
kasprintf() is a problem here? Or is there another motivation behind the 
change?


Regards,
Christian.



BR,
-R


I can rewrite the typedef out if you think it's better.

Cheers,
   Eric
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



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