[Intel-gfx] [PATCH 1/2] drm/i915: enable vGPU detection for all

[Zhenyu Wang]

From: Ping Gao <ping.a@intel.com>

vGPU capability is handled by GVT-g host driver, not needed to
put extra HW check for vGPU detection. And we'll actually support
vGPU from BDW.

Signed-off-by: Ping Gao <ping.a@intel.com>
Signed-off-by: Zhenyu Wang <zhen...@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_vgpu.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index ca2e912..dae340c 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -65,9 +65,6 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
 
BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
 
-   if (!IS_HASWELL(dev_priv))
-   return;
-
magic = __raw_i915_read64(dev_priv, vgtif_reg(magic));
if (magic != VGT_MAGIC)
return;
-- 
2.9.3

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

Re: [Intel-gfx] [RFC 0/6] Non perf based Gen Graphics OA unit driver

[Zhenyu Wang]

On 2015.09.29 15:39:03 +0100, Robert Bragg wrote:
> 
> - Logistically it might be more practical to contain this to the
>   graphics stack.
> 
> It seems fair to consider that if we can't see a very compelling
> benefit to building on perf, then containing this work to
> drivers/gpu/drm/i915 may simplify the review process as well as
> future maintenance and development.
> 

I think even we all initially like to go with perf but it appears later
that we might need to stick this more close with i915 driver. Also think
about to enable global profiling for all graphics clients, extending or
enabling it within i915 specific interface seems more feasible instead of
trying to create another PMU driver like previous implementation attempt
to suit the need for different gfx perf data definition.

Robert, thanks for send and elaborate on this.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] New GTPin kit (5923)

[Zhenyu Wang]

On 2015.07.09 13:50:14 +0800, Zhenyu Wang wrote:
 
 GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing
 system for GT-Pin on Linux, we now have aligned kit release regularly.
 
 Please check wiki page for details and the link to download the kit.
 
 https://wiki.ith.intel.com/display/OTCGFXPERF/GT-Pin+for+Linux
 
 thanks.
 

Oops, sorry for wrong list! This is for internal only pls ignore.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] New GTPin kit (5923)

[Zhenyu Wang]

GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing
system for GT-Pin on Linux, we now have aligned kit release regularly.

Please check wiki page for details and the link to download the kit.

https://wiki.ith.intel.com/display/OTCGFXPERF/GT-Pin+for+Linux

thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add soft-pinning API for execbuffer

[Zhenyu Wang]

On 2015.03.06 09:44:07 +, Chris Wilson wrote:
 Userspace can pass in an offset that it presumes the object is located
 at. The kernel will then do its utmost to fit the object into that
 location. The assumption is that userspace is handling its own object
 locations (for example along with full-ppgtt) and that the kernel will
 rarely have to make space for the user's requests.
 

Chris, would you add libdrm support for this? e.g beignet doesn't
handle exec object itself but use libdrm.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] tools/intel_audio_dump: add support for Skylake

[Zhenyu Wang]

On 2015.02.12 08:41:59 +0800, han...@intel.com wrote:
 From: Lu, Han han...@intel.com
 
 This patch adds support for dumping audio registers of Skylake.
 
 Signed-off-by: Lu, Han han...@intel.com
 

Just pushed this. Thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] tools/intel_audio_dump: add details dump for Cherryview

[Zhenyu Wang]

On 2015.01.26 01:15:36 +, Yang, Libin wrote:
 Any comments?
 

Looks fine to me. Reviewed-by: Zhenyu Wang zhen...@linux.intel.com

I will help to push this later.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] intel: Fix GTT entry setup for aub dump

[Zhenyu Wang]

On recent emulator GTT entry setup for aub dump needs mem type as
GTT_ENTRY instead of NONLOCAL. NONLOCAL would write data in main
memory space which is wrong with new memory layout. GTT_ENTRY write
would setup GTT memory pool and other required internal buffers. With
this I can run aub dump on latest release without crash.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 intel/intel_bufmgr_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

I've done more testings about this on more hosts. No regression found
on older HW with previous emulator with memory type change. And verify
this on more recent emulators that without crash and produce result
fine.

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 14e92c9..cf85bb8 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3180,7 +3180,8 @@ drm_intel_bufmgr_gem_set_aub_dump(drm_intel_bufmgr 
*bufmgr, int enable)
 
/* Set up the GTT. The max we can handle is 256M */
aub_out(bufmgr_gem, CMD_AUB_TRACE_HEADER_BLOCK | ((bufmgr_gem-gen = 8 
? 6 : 5) - 2));
-   aub_out(bufmgr_gem, AUB_TRACE_MEMTYPE_NONLOCAL | 0 | 
AUB_TRACE_OP_DATA_WRITE);
+   /* Need to use GTT_ENTRY type for recent emulator */
+   aub_out(bufmgr_gem, AUB_TRACE_MEMTYPE_GTT_ENTRY | 0 | 
AUB_TRACE_OP_DATA_WRITE);
aub_out(bufmgr_gem, 0); /* subtype */
aub_out(bufmgr_gem, 0); /* offset */
aub_out(bufmgr_gem, gtt_size); /* size */
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] intel_audio_dump: add support for Cherryview

[Zhenyu Wang]

On 2015.01.12 01:38:34 +, Yang, Libin wrote:
 From ebfde852d9efbd7213c391e91be9d0741813bb16 Mon Sep 17 00:00:00 2001
 From: Libin Yang libin.y...@intel.com
 Date: Wed, 7 Jan 2015 10:56:18 +0800
 Subject: [PATCH] intel_audio_dump: add support for Cherryview
 
 This patch adds support for dumping audio registers of Cherryview.
 
 Signed-off-by: Libin Yang libin.y...@intel.com

Just clean up your commit message and pushed the patch.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel: Export GT config attributes

[Zhenyu Wang]

On 2014.12.18 12:12:33 -0600, jeff.mc...@intel.com wrote:
 diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
 index 15dd01d..be38adf 100644
 --- a/include/drm/i915_drm.h
 +++ b/include/drm/i915_drm.h
 @@ -340,6 +340,10 @@ typedef struct drm_i915_irq_wait {
  #define I915_PARAM_HAS_EXEC_HANDLE_LUT   26
  #define I915_PARAM_HAS_WT 27
  #define I915_PARAM_CMD_PARSER_VERSION 28
 +#define I915_PARAM_SLICE_TOTAL30
 +#define I915_PARAM_SUBSLICE_TOTAL 31
 +#define I915_PARAM_EU_TOTAL   32
 +#define I915_PARAM_THREADS_PER_EU 33
  
  typedef struct drm_i915_getparam {
   int param;
 diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
 index be83a56..90e535d 100644
 --- a/intel/intel_bufmgr.h
 +++ b/intel/intel_bufmgr.h
 @@ -264,6 +264,11 @@ int drm_intel_get_reset_stats(drm_intel_context *ctx,
 uint32_t *active,
 uint32_t *pending);
  
 +int drm_intel_get_slice_total(int fd, unsigned int *slice_total);
 +int drm_intel_get_subslice_total(int fd, unsigned int *subslice_total);
 +int drm_intel_get_eu_total(int fd, unsigned int *eu_total);
 +int drm_intel_get_threads_per_eu(int fd, unsigned int *threads_per_eu);
 +

I think we normally use drm_intel_bufmgr in API instead of fd directly.
And this config info can be initialized when bufmgr init, so later request
can get info without calling ioctl everytime.

Also please cc intel-gfx list for any intel related patch.

thanks.

  /** @{ Compatibility defines to keep old code building despite the symbol 
 rename
   * from dri_* to drm_intel_*
   */
 diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
 index 14e92c9..e0b13e7 100644
 --- a/intel/intel_bufmgr_gem.c
 +++ b/intel/intel_bufmgr_gem.c
 @@ -3293,6 +3293,69 @@ drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
   return ret;
  }
  
 +drm_public int
 +drm_intel_get_slice_total(int fd, unsigned int *slice_total)
 +{
 + drm_i915_getparam_t gp;
 + int ret;
 +
 + VG_CLEAR(gp);
 + gp.value = (int*)slice_total;
 + gp.param = I915_PARAM_SLICE_TOTAL;
 + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
 + if (ret)
 + return -errno;
 +
 + return 0;
 +}
 +
 +drm_public int
 +drm_intel_get_subslice_total(int fd, unsigned int *subslice_total)
 +{
 + drm_i915_getparam_t gp;
 + int ret;
 +
 + VG_CLEAR(gp);
 + gp.value = (int*)subslice_total;
 + gp.param = I915_PARAM_SUBSLICE_TOTAL;
 + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
 + if (ret)
 + return -errno;
 +
 + return 0;
 +}
 +
 +drm_public int
 +drm_intel_get_eu_total(int fd, unsigned int *eu_total)
 +{
 + drm_i915_getparam_t gp;
 + int ret;
 +
 + VG_CLEAR(gp);
 + gp.value = (int*)eu_total;
 + gp.param = I915_PARAM_EU_TOTAL;
 + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
 + if (ret)
 + return -errno;
 +
 + return 0;
 +}
 +
 +drm_public int
 +drm_intel_get_threads_per_eu(int fd, unsigned int *threads_per_eu)
 +{
 + drm_i915_getparam_t gp;
 + int ret;
 +
 + VG_CLEAR(gp);
 + gp.value = (int*)threads_per_eu;
 + gp.param = I915_PARAM_THREADS_PER_EU;
 + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
 + if (ret)
 + return -errno;
 +
 + return 0;
 +}
  
  /**
   * Annotate the given bo for use in aub dumping.
 -- 
 2.2.0
 
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] intel: Fix GTT entry setup for aub dump on recent fulsim

[Zhenyu Wang]

On recent fulsim GTT entry setup for aub dump seems to need mem type
as GTT_ENTRY instead of NONLOCAL. NONLOCAL would write data in main
memory space which seems wrong on recent fulsim. GTT_ENTRY write would
setup GTT memory pool and other required internal buffers. With this
I can run aub dump on latest fulsim release without crash.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 intel/intel_bufmgr_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 14e92c9..3076111 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3180,7 +3180,8 @@ drm_intel_bufmgr_gem_set_aub_dump(drm_intel_bufmgr 
*bufmgr, int enable)
 
/* Set up the GTT. The max we can handle is 256M */
aub_out(bufmgr_gem, CMD_AUB_TRACE_HEADER_BLOCK | ((bufmgr_gem-gen = 8 
? 6 : 5) - 2));
-   aub_out(bufmgr_gem, AUB_TRACE_MEMTYPE_NONLOCAL | 0 | 
AUB_TRACE_OP_DATA_WRITE);
+   /* Need to use GTT_ENTRY type for recent fulsim */
+   aub_out(bufmgr_gem, AUB_TRACE_MEMTYPE_GTT_ENTRY | 0 | 
AUB_TRACE_OP_DATA_WRITE);
aub_out(bufmgr_gem, 0); /* subtype */
aub_out(bufmgr_gem, 0); /* offset */
aub_out(bufmgr_gem, gtt_size); /* size */
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 1/3] lib: rename igt_media_fillfunc_t typedef to igt_fillfunc_t

[Zhenyu Wang]

On 2014.12.03 15:26:13 +0100, Daniel Vetter wrote:
 On Wed, Dec 03, 2014 at 07:11:17PM +0800, Zhenyu Wang wrote:
  This makes fill function more general to prepare for other
  fill method using GPGPU pipeline.
  
  Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
 
 Series lgtm, please push.

Just pushed, thanks for the review.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] tests: Add gem_gpgpu_fill

[Zhenyu Wang]

This is simply a copy of gem_media_fill but using new
GPGPU fill operation.

v2: Use general fill func pointer.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 tests/Makefile.sources |   1 +
 tests/gem_gpgpu_fill.c | 141 +
 2 files changed, 142 insertions(+)
 create mode 100644 tests/gem_gpgpu_fill.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2677bf7..ac9b794 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -112,6 +112,7 @@ TESTS_progs = \
gem_lut_handle \
gem_mmap_offset_exhaustion \
gem_media_fill \
+   gem_gpgpu_fill \
gem_pin \
gem_reg_read \
gem_render_copy \
diff --git a/tests/gem_gpgpu_fill.c b/tests/gem_gpgpu_fill.c
new file mode 100644
index 000..df0d7c8
--- /dev/null
+++ b/tests/gem_gpgpu_fill.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Damien Lespiau damien.lesp...@intel.com
+ *Xiang, Haihao haihao.xi...@intel.com
+ */
+
+/*
+ * This file is a basic test for the gpgpu_fill() function, a very simple
+ * workload for the GPGPU pipeline.
+ */
+
+#include stdbool.h
+#include unistd.h
+#include stdlib.h
+#include sys/ioctl.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/time.h
+#include drm.h
+#include ioctl_wrappers.h
+#include drmtest.h
+#include intel_bufmgr.h
+#include intel_batchbuffer.h
+#include intel_io.h
+#include intel_chipset.h
+
+#define WIDTH 64
+#define HEIGHT 64
+#define STRIDE (WIDTH)
+#define SIZE (HEIGHT*STRIDE)
+
+#define COLOR_C4   0xc4
+#define COLOR_4C   0x4c
+
+typedef struct {
+   int drm_fd;
+   uint32_t devid;
+   drm_intel_bufmgr *bufmgr;
+   uint8_t linear[WIDTH * HEIGHT];
+} data_t;
+
+static void scratch_buf_init(data_t *data, struct igt_buf *buf,
+   int width, int height, int stride, uint8_t color)
+{
+   drm_intel_bo *bo;
+   int i;
+
+   bo = drm_intel_bo_alloc(data-bufmgr, , SIZE, 4096);
+   for (i = 0; i  width * height; i++)
+   data-linear[i] = color;
+   gem_write(data-drm_fd, bo-handle, 0, data-linear,
+   sizeof(data-linear));
+
+   buf-bo = bo;
+   buf-stride = stride;
+   buf-tiling = I915_TILING_NONE;
+   buf-size = SIZE;
+}
+
+static void
+scratch_buf_check(data_t *data, struct igt_buf *buf, int x, int y,
+   uint8_t color)
+{
+   uint8_t val;
+
+   gem_read(data-drm_fd, buf-bo-handle, 0,
+   data-linear, sizeof(data-linear));
+   val = data-linear[y * WIDTH + x];
+   igt_assert_f(val == color,
+Expected 0x%02x, found 0x%02x at (%d,%d)\n,
+color, val, x, y);
+}
+
+igt_simple_main
+{
+   data_t data = {0, };
+   struct intel_batchbuffer *batch = NULL;
+   struct igt_buf dst;
+   igt_fillfunc_t gpgpu_fill = NULL;
+   int i, j;
+
+   data.drm_fd = drm_open_any_render();
+   data.devid = intel_get_drm_devid(data.drm_fd);
+
+   data.bufmgr = drm_intel_bufmgr_gem_init(data.drm_fd, 4096);
+   igt_assert(data.bufmgr);
+
+   gpgpu_fill = igt_get_gpgpu_fillfunc(data.devid);
+
+   igt_require_f(gpgpu_fill,
+ no gpgpu-fill function\n);
+
+   batch = intel_batchbuffer_alloc(data.bufmgr, data.devid);
+   igt_assert(batch);
+
+   scratch_buf_init(data, dst, WIDTH, HEIGHT, STRIDE, COLOR_C4);
+
+   for (i = 0; i  WIDTH; i++) {
+   for (j = 0; j  HEIGHT; j++) {
+   scratch_buf_check(data, dst, i, j, COLOR_C4);
+   }
+   }
+
+   gpgpu_fill(batch,
+  dst, 0, 0, WIDTH / 2, HEIGHT / 2,
+  COLOR_4C);
+
+   for (i = 0; i  WIDTH; i

[Intel-gfx] [PATCH 1/3] lib: rename igt_media_fillfunc_t typedef to igt_fillfunc_t

[Zhenyu Wang]

This makes fill function more general to prepare for other
fill method using GPGPU pipeline.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 lib/intel_batchbuffer.c |  4 ++--
 lib/intel_batchbuffer.h | 24 
 tests/gem_media_fill.c  |  2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index 30ef2cf..4b3a5b8 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -496,9 +496,9 @@ igt_render_copyfunc_t igt_get_render_copyfunc(int devid)
  * The platform-specific media fill function pointer for the device specified
  * with @devid. Will return NULL when no media fill function is implemented.
  */
-igt_media_fillfunc_t igt_get_media_fillfunc(int devid)
+igt_fillfunc_t igt_get_media_fillfunc(int devid)
 {
-   igt_media_fillfunc_t fill = NULL;
+   igt_fillfunc_t fill = NULL;
 
if (IS_GEN9(devid))
fill = gen9_media_fillfunc;
diff --git a/lib/intel_batchbuffer.h b/lib/intel_batchbuffer.h
index 0ec6601..f0e21ea 100644
--- a/lib/intel_batchbuffer.h
+++ b/lib/intel_batchbuffer.h
@@ -195,7 +195,7 @@ void intel_copy_bo(struct intel_batchbuffer *batch,
  *
  * This is a i-g-t buffer object wrapper structure which augments the baseline
  * libdrm buffer object with suitable data needed by the render copy and the
- * media fill functions.
+ * fill functions.
  */
 struct igt_buf {
 drm_intel_bo *bo;
@@ -240,7 +240,7 @@ typedef void (*igt_render_copyfunc_t)(struct 
intel_batchbuffer *batch,
 igt_render_copyfunc_t igt_get_render_copyfunc(int devid);
 
 /**
- * igt_media_fillfunc_t:
+ * igt_fillfunc_t:
  * @batch: batchbuffer object
  * @dst: destination i-g-t buffer object
  * @x: destination pixel x-coordination
@@ -249,19 +249,19 @@ igt_render_copyfunc_t igt_get_render_copyfunc(int devid);
  * @height: height of the filled rectangle
  * @color: fill color to use
  *
- * This is the type of the per-platform media fill functions. The
- * platform-specific implementation can be obtained by calling
- * igt_get_media_fillfunc().
+ * This is the type of the per-platform fill functions using media
+ * pipeline. The platform-specific implementation can be obtained
+ * by calling igt_get_media_fillfunc().
  *
- * A media fill function will emit a batchbuffer to the kernel which executes
+ * A fill function will emit a batchbuffer to the kernel which executes
  * the specified blit fill operation using the media engine.
  */
-typedef void (*igt_media_fillfunc_t)(struct intel_batchbuffer *batch,
-struct igt_buf *dst,
-unsigned x, unsigned y,
-unsigned width, unsigned height,
-uint8_t color);
+typedef void (*igt_fillfunc_t)(struct intel_batchbuffer *batch,
+  struct igt_buf *dst,
+  unsigned x, unsigned y,
+  unsigned width, unsigned height,
+  uint8_t color);
 
-igt_media_fillfunc_t igt_get_media_fillfunc(int devid);
+igt_fillfunc_t igt_get_media_fillfunc(int devid);
 
 #endif
diff --git a/tests/gem_media_fill.c b/tests/gem_media_fill.c
index b06a556..3067317 100644
--- a/tests/gem_media_fill.c
+++ b/tests/gem_media_fill.c
@@ -101,7 +101,7 @@ igt_simple_main
data_t data = {0, };
struct intel_batchbuffer *batch = NULL;
struct igt_buf dst;
-   igt_media_fillfunc_t media_fill = NULL;
+   igt_fillfunc_t media_fill = NULL;
int i, j;
 
data.drm_fd = drm_open_any_render();
-- 
2.1.3

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

[Intel-gfx] [PATCH 2/3] lib: Add GPGPU fill

[Zhenyu Wang]

This is to add fill operation using GPGPU pipeline which is similar to
current media fill. This can be used to simply verify GPGPU pipeline
and help to enable it on newer HW, currently it works on Gen7 only and
will add support on later platform.

Now this sets very simply thread group dispatch for one thread per
thread group on SIMD16 dispatch. So the fill shader just uses thread
group ID for buffer offset.

v2: No new fill func typedef but adapt to igt_fillfunc_t.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 lib/gen7_media.h |   2 +
 lib/intel_batchbuffer.c  |  19 +
 lib/intel_batchbuffer.h  |   7 +-
 lib/media_fill.h |   7 ++
 lib/media_fill_gen7.c| 161 +--
 shaders/gpgpu/README |   4 ++
 shaders/gpgpu/gpgpu_fill.gxa |  51 ++
 7 files changed, 244 insertions(+), 7 deletions(-)
 create mode 100644 shaders/gpgpu/README
 create mode 100644 shaders/gpgpu/gpgpu_fill.gxa

diff --git a/lib/gen7_media.h b/lib/gen7_media.h
index d5f9921..91294d2 100644
--- a/lib/gen7_media.h
+++ b/lib/gen7_media.h
@@ -179,6 +179,7 @@
 #define GEN7_PIPELINE_SELECT   GFXPIPE(1, 1, 4)
 # define PIPELINE_SELECT_3D(0  0)
 # define PIPELINE_SELECT_MEDIA (1  0)
+# define PIPELINE_SELECT_GPGPU (2  0)
 
 #define GEN7_STATE_BASE_ADDRESSGFXPIPE(0, 1, 1)
 # define BASE_ADDRESS_MODIFY   (1  0)
@@ -187,6 +188,7 @@
 #define GEN7_MEDIA_CURBE_LOAD  GFXPIPE(2, 0, 1)
 #define GEN7_MEDIA_INTERFACE_DESCRIPTOR_LOAD   GFXPIPE(2, 0, 2)
 #define GEN7_MEDIA_OBJECT  GFXPIPE(2, 1, 0)
+#define GEN7_GPGPU_WALKER   GFXPIPE(2, 1, 5)
 
 struct gen7_interface_descriptor_data
 {
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index 4b3a5b8..c70f6d8 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -511,3 +511,22 @@ igt_fillfunc_t igt_get_media_fillfunc(int devid)
 
return fill;
 }
+
+/**
+ * igt_get_gpgpu_fillfunc:
+ * @devid: pci device id
+ *
+ * Returns:
+ *
+ * The platform-specific gpgpu fill function pointer for the device specified
+ * with @devid. Will return NULL when no gpgpu fill function is implemented.
+ */
+igt_fillfunc_t igt_get_gpgpu_fillfunc(int devid)
+{
+   igt_fillfunc_t fill = NULL;
+
+   if (IS_GEN7(devid))
+   fill = gen7_gpgpu_fillfunc;
+
+   return fill;
+}
diff --git a/lib/intel_batchbuffer.h b/lib/intel_batchbuffer.h
index f0e21ea..12f7be1 100644
--- a/lib/intel_batchbuffer.h
+++ b/lib/intel_batchbuffer.h
@@ -250,11 +250,11 @@ igt_render_copyfunc_t igt_get_render_copyfunc(int devid);
  * @color: fill color to use
  *
  * This is the type of the per-platform fill functions using media
- * pipeline. The platform-specific implementation can be obtained
- * by calling igt_get_media_fillfunc().
+ * or gpgpu pipeline. The platform-specific implementation can be obtained
+ * by calling igt_get_media_fillfunc() or igt_get_gpgpu_fillfunc().
  *
  * A fill function will emit a batchbuffer to the kernel which executes
- * the specified blit fill operation using the media engine.
+ * the specified blit fill operation using the media/gpgpu engine.
  */
 typedef void (*igt_fillfunc_t)(struct intel_batchbuffer *batch,
   struct igt_buf *dst,
@@ -263,5 +263,6 @@ typedef void (*igt_fillfunc_t)(struct intel_batchbuffer 
*batch,
   uint8_t color);
 
 igt_fillfunc_t igt_get_media_fillfunc(int devid);
+igt_fillfunc_t igt_get_gpgpu_fillfunc(int devid);
 
 #endif
diff --git a/lib/media_fill.h b/lib/media_fill.h
index 226489c..2a30055 100644
--- a/lib/media_fill.h
+++ b/lib/media_fill.h
@@ -32,4 +32,11 @@ gen9_media_fillfunc(struct intel_batchbuffer *batch,
 unsigned width, unsigned height,
 uint8_t color);
 
+void
+gen7_gpgpu_fillfunc(struct intel_batchbuffer *batch,
+   struct igt_buf *dst,
+   unsigned x, unsigned y,
+   unsigned width, unsigned height,
+   uint8_t color);
+
 #endif /* RENDE_MEDIA_FILL_H */
diff --git a/lib/media_fill_gen7.c b/lib/media_fill_gen7.c
index 5a23b7d..7113fda 100644
--- a/lib/media_fill_gen7.c
+++ b/lib/media_fill_gen7.c
@@ -8,7 +8,6 @@
 
 #include assert.h
 
-
 static const uint32_t media_kernel[][4] = {
{ 0x0041, 0x20200231, 0x0020, 0x },
{ 0x0061, 0x20800021, 0x008d, 0x },
@@ -23,6 +22,23 @@ static const uint32_t media_kernel[][4] = {
{ 0x07800031, 0x20001ca8, 0x0e00, 0x8210 },
 };
 
+/* shaders/gpgpu/gpgpu_fill.gxa */
+static const uint32_t gpgpu_kernel[][4] = {
+   { 0x0041, 0x20200231, 0x0020, 0x },
+   { 0x0041, 0x20400c21, 0x0004, 0x0010 },
+   { 0x0001, 0x20440021, 0x0018, 0x },
+   { 0x0061, 0x20800021

[Intel-gfx] [PATCH 1/2] lib: Add GPGPU fill

[Zhenyu Wang]

This is to add fill operation using GPGPU pipeline which is similar to
current media fill. This can be used to simply verify GPGPU pipeline
and help to enable it on newer HW, currently it works on Gen7 only and
will add support on later platform.

Now this sets very simply thread group dispatch for one thread per
thread group on SIMD16 dispatch. So the fill shader just uses thread
group ID for buffer offset.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 lib/gen7_media.h |   2 +
 lib/intel_batchbuffer.c  |  19 +
 lib/intel_batchbuffer.h  |  25 +++
 lib/media_fill.h |   7 ++
 lib/media_fill_gen7.c| 161 +--
 shaders/gpgpu/README |   4 ++
 shaders/gpgpu/gpgpu_fill.gxa |  51 ++
 7 files changed, 265 insertions(+), 4 deletions(-)
 create mode 100644 shaders/gpgpu/README
 create mode 100644 shaders/gpgpu/gpgpu_fill.gxa

diff --git a/lib/gen7_media.h b/lib/gen7_media.h
index d5f9921..91294d2 100644
--- a/lib/gen7_media.h
+++ b/lib/gen7_media.h
@@ -179,6 +179,7 @@
 #define GEN7_PIPELINE_SELECT   GFXPIPE(1, 1, 4)
 # define PIPELINE_SELECT_3D(0  0)
 # define PIPELINE_SELECT_MEDIA (1  0)
+# define PIPELINE_SELECT_GPGPU (2  0)
 
 #define GEN7_STATE_BASE_ADDRESSGFXPIPE(0, 1, 1)
 # define BASE_ADDRESS_MODIFY   (1  0)
@@ -187,6 +188,7 @@
 #define GEN7_MEDIA_CURBE_LOAD  GFXPIPE(2, 0, 1)
 #define GEN7_MEDIA_INTERFACE_DESCRIPTOR_LOAD   GFXPIPE(2, 0, 2)
 #define GEN7_MEDIA_OBJECT  GFXPIPE(2, 1, 0)
+#define GEN7_GPGPU_WALKER   GFXPIPE(2, 1, 5)
 
 struct gen7_interface_descriptor_data
 {
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index 30ef2cf..18b0ef3 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -511,3 +511,22 @@ igt_media_fillfunc_t igt_get_media_fillfunc(int devid)
 
return fill;
 }
+
+/**
+ * igt_get_gpgpu_fillfunc:
+ * @devid: pci device id
+ *
+ * Returns:
+ *
+ * The platform-specific media fill function pointer for the device specified
+ * with @devid. Will return NULL when no media fill function is implemented.
+ */
+igt_gpgpu_fillfunc_t igt_get_gpgpu_fillfunc(int devid)
+{
+   igt_gpgpu_fillfunc_t fill = NULL;
+
+   if (IS_GEN7(devid))
+   fill = gen7_gpgpu_fillfunc;
+
+   return fill;
+}
diff --git a/lib/intel_batchbuffer.h b/lib/intel_batchbuffer.h
index 0ec6601..b5d697f 100644
--- a/lib/intel_batchbuffer.h
+++ b/lib/intel_batchbuffer.h
@@ -264,4 +264,29 @@ typedef void (*igt_media_fillfunc_t)(struct 
intel_batchbuffer *batch,
 
 igt_media_fillfunc_t igt_get_media_fillfunc(int devid);
 
+/**
+ * igt_gpgpu_fillfunc_t:
+ * @batch: batchbuffer object
+ * @dst: destination i-g-t buffer object
+ * @x: destination pixel x-coordination
+ * @y: destination pixel y-coordination
+ * @width: width of the filled rectangle
+ * @height: height of the filled rectangle
+ * @color: fill color to use
+ *
+ * This is the type of the per-platform media fill functions. The
+ * platform-specific implementation can be obtained by calling
+ * igt_get_gpgpu_fillfunc().
+ *
+ * A media fill function will emit a batchbuffer to the kernel which executes
+ * the specified blit fill operation using the media engine.
+ */
+typedef void (*igt_gpgpu_fillfunc_t)(struct intel_batchbuffer *batch,
+struct igt_buf *dst,
+unsigned x, unsigned y,
+unsigned width, unsigned height,
+uint8_t color);
+
+igt_gpgpu_fillfunc_t igt_get_gpgpu_fillfunc(int devid);
+
 #endif
diff --git a/lib/media_fill.h b/lib/media_fill.h
index 226489c..2a30055 100644
--- a/lib/media_fill.h
+++ b/lib/media_fill.h
@@ -32,4 +32,11 @@ gen9_media_fillfunc(struct intel_batchbuffer *batch,
 unsigned width, unsigned height,
 uint8_t color);
 
+void
+gen7_gpgpu_fillfunc(struct intel_batchbuffer *batch,
+   struct igt_buf *dst,
+   unsigned x, unsigned y,
+   unsigned width, unsigned height,
+   uint8_t color);
+
 #endif /* RENDE_MEDIA_FILL_H */
diff --git a/lib/media_fill_gen7.c b/lib/media_fill_gen7.c
index 5a23b7d..7113fda 100644
--- a/lib/media_fill_gen7.c
+++ b/lib/media_fill_gen7.c
@@ -8,7 +8,6 @@
 
 #include assert.h
 
-
 static const uint32_t media_kernel[][4] = {
{ 0x0041, 0x20200231, 0x0020, 0x },
{ 0x0061, 0x20800021, 0x008d, 0x },
@@ -23,6 +22,23 @@ static const uint32_t media_kernel[][4] = {
{ 0x07800031, 0x20001ca8, 0x0e00, 0x8210 },
 };
 
+/* shaders/gpgpu/gpgpu_fill.gxa */
+static const uint32_t gpgpu_kernel[][4] = {
+   { 0x0041, 0x20200231, 0x0020, 0x },
+   { 0x0041, 0x20400c21, 0x0004

[Intel-gfx] [PATCH 2/2] tests: Add gem_gpgpu_fill

[Zhenyu Wang]

This is simply a copy of gem_media_fill but using new
GPGPU fill operation.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 tests/Makefile.sources |   1 +
 tests/gem_gpgpu_fill.c | 141 +
 2 files changed, 142 insertions(+)
 create mode 100644 tests/gem_gpgpu_fill.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2677bf7..ac9b794 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -112,6 +112,7 @@ TESTS_progs = \
gem_lut_handle \
gem_mmap_offset_exhaustion \
gem_media_fill \
+   gem_gpgpu_fill \
gem_pin \
gem_reg_read \
gem_render_copy \
diff --git a/tests/gem_gpgpu_fill.c b/tests/gem_gpgpu_fill.c
new file mode 100644
index 000..258b741
--- /dev/null
+++ b/tests/gem_gpgpu_fill.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Damien Lespiau damien.lesp...@intel.com
+ *Xiang, Haihao haihao.xi...@intel.com
+ */
+
+/*
+ * This file is a basic test for the gpgpu_fill() function, a very simple
+ * workload for the GPGPU pipeline.
+ */
+
+#include stdbool.h
+#include unistd.h
+#include stdlib.h
+#include sys/ioctl.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/time.h
+#include drm.h
+#include ioctl_wrappers.h
+#include drmtest.h
+#include intel_bufmgr.h
+#include intel_batchbuffer.h
+#include intel_io.h
+#include intel_chipset.h
+
+#define WIDTH 64
+#define HEIGHT 64
+#define STRIDE (WIDTH)
+#define SIZE (HEIGHT*STRIDE)
+
+#define COLOR_C4   0xc4
+#define COLOR_4C   0x4c
+
+typedef struct {
+   int drm_fd;
+   uint32_t devid;
+   drm_intel_bufmgr *bufmgr;
+   uint8_t linear[WIDTH * HEIGHT];
+} data_t;
+
+static void scratch_buf_init(data_t *data, struct igt_buf *buf,
+   int width, int height, int stride, uint8_t color)
+{
+   drm_intel_bo *bo;
+   int i;
+
+   bo = drm_intel_bo_alloc(data-bufmgr, , SIZE, 4096);
+   for (i = 0; i  width * height; i++)
+   data-linear[i] = color;
+   gem_write(data-drm_fd, bo-handle, 0, data-linear,
+   sizeof(data-linear));
+
+   buf-bo = bo;
+   buf-stride = stride;
+   buf-tiling = I915_TILING_NONE;
+   buf-size = SIZE;
+}
+
+static void
+scratch_buf_check(data_t *data, struct igt_buf *buf, int x, int y,
+   uint8_t color)
+{
+   uint8_t val;
+
+   gem_read(data-drm_fd, buf-bo-handle, 0,
+   data-linear, sizeof(data-linear));
+   val = data-linear[y * WIDTH + x];
+   igt_assert_f(val == color,
+Expected 0x%02x, found 0x%02x at (%d,%d)\n,
+color, val, x, y);
+}
+
+igt_simple_main
+{
+   data_t data = {0, };
+   struct intel_batchbuffer *batch = NULL;
+   struct igt_buf dst;
+   igt_gpgpu_fillfunc_t gpgpu_fill = NULL;
+   int i, j;
+
+   data.drm_fd = drm_open_any_render();
+   data.devid = intel_get_drm_devid(data.drm_fd);
+
+   data.bufmgr = drm_intel_bufmgr_gem_init(data.drm_fd, 4096);
+   igt_assert(data.bufmgr);
+
+   gpgpu_fill = igt_get_gpgpu_fillfunc(data.devid);
+
+   igt_require_f(gpgpu_fill,
+ no gpgpu-fill function\n);
+
+   batch = intel_batchbuffer_alloc(data.bufmgr, data.devid);
+   igt_assert(batch);
+
+   scratch_buf_init(data, dst, WIDTH, HEIGHT, STRIDE, COLOR_C4);
+
+   for (i = 0; i  WIDTH; i++) {
+   for (j = 0; j  HEIGHT; j++) {
+   scratch_buf_check(data, dst, i, j, COLOR_C4);
+   }
+   }
+
+   gpgpu_fill(batch,
+  dst, 0, 0, WIDTH / 2, HEIGHT / 2,
+  COLOR_4C);
+
+   for (i = 0; i  WIDTH; i++) {
+   for (j = 0; j  HEIGHT; j

Re: [Intel-gfx] [PATCH] drm/i915: Add RCS General Purpose Registers to parser whitelist

[Zhenyu Wang]

On 2014.09.23 10:38:49 +0200, Daniel Vetter wrote:
 On Tue, Sep 23, 2014 at 12:41:50AM +0200, Michał Winiarski wrote:
  These registers are used as a temporary storage by MI_MATH command when
  performing ALU operations.
  
  Signed-off-by: Michał Winiarski michal.winiar...@intel.com
 
 Needs to come with corresponding userspace using this. Also we need to rev
 the cmd parser revision so that userspace can figure out whether a given
 feature might work, see i915_cmd_parser_get_version.
 -Daniel
 

FYI. I played with those ALU operation before as in
http://cgit.freedesktop.org/~zhen/intel-gpu-tools/commit/?h=cs_aluid=768669791fee0846dc19a38a16e58508ac7c791b

Maybe we can tweak that with more tests for MI_MATH and ALU regs?

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Zhenyu Wang]

On 2014.06.19 17:53:51 +0800, Tiejun Chen wrote:
 Originally the reason to probe ISA bridge instead of Dev31:Fun0
 is to make graphics device passthrough work easy for VMM, that
 only need to expose ISA bridge to let driver know the real
 hardware underneath. This is a requirement from virtualization
 team. Especially in that virtualized environments, XEN, there
 is irrelevant ISA bridge in the system with that legacy qemu
 version specific to xen, qemu-xen-traditional. So to work
 reliably, we should scan through all the ISA bridge devices
 and check for the first match, instead of only checking the
 first one.
 
 But actually, qemu-xen-traditional, is always enumerated with
 Dev31:Fun0, 00:1f.0 as follows:
 
 hw/pt-graphics.c:
 
 intel_pch_init()
 |
 + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);
 
 so this mean that isa bridge is still represented with Dev31:Func0
 like the native OS. Furthermore, currently we're pushing VGA
 passthrough support into qemu upstream, and with some discussion,
 we wouldn't set the bridge class type and just expose this devfn.
 
 So we just go back to check devfn to make life normal.
 
 Signed-off-by: Tiejun Chen tiejun.c...@intel.com

This was added historically when supporting graphics device passthrough.
Looks qemu upstream can't accept multiple ISA bridge and our PCH is always
on device 31: func0 as far as I know. Looks good to me.

Reviewed-by: Zhenyu Wang zhen...@linux.intel.com 

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Track OACONTROL register enable/disable during parsing

[Zhenyu Wang]

On 2014.03.28 10:21:50 -0700, bradley.d.vol...@intel.com wrote:
 From: Brad Volkin bradley.d.vol...@intel.com
 
 There is some thought that the data from the performance counters enabled
 via OACONTROL should only be available to the process that enabled counting.
 To limit snooping, require that any batch buffer which sets OACONTROL to a
 non-zero value also sets it back to 0 before the end of the batch.
 

I think this might be too strict although there's good point in this.
But it makes almost impossible to insert mi report count command to probe
GPU statistics from kind of third-party tool or lib.

Could we have a i915.enable_cmd_parser config that can disable this?

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Track OACONTROL register enable/disable during parsing

[Zhenyu Wang]

On 2014.04.10 08:43:40 +0200, Daniel Vetter wrote:
 
 At least in the case of mesa you _must_ use mesa (or whatever your gl
 library is) to insert the MI_PERF cmd at just the rigth spots in the
 command stream and ofc flush all outstanding vertices and similar things.
 
 If you want a global perf sampling support then I think we need to wire up
 the time-based sampling the hw provides to the perf subsystem. And figure
 out how to coordinate between mesa wanting to use OA and perf (probably
 just reject mesa batches or something like that).
 

yeah, that'll be an interesting direction.

  Could we have a i915.enable_cmd_parser config that can disable this?
 
 As is I don't see a compelling reason. Also if you require the users of
 your perf tuning tooling to use a module option, you're doing it wrong.
 This stuff should Just Work.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix drain latency precision multipler for VLV

[Zhenyu Wang]

On 2014.03.05 18:51:48 +0200, Ville Syrjälä wrote:
  entries = (clock / 1000) * pixel_size;
  *plane_prec_mult = (entries  256) ?
 
 The threshold should also be reduced to 128 entries.
 

hmm, I'll double check if this is really required or not.

  -   DRAIN_LATENCY_PRECISION_32 : DRAIN_LATENCY_PRECISION_16;
  +   DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
  *plane_dl = (64 * (*plane_prec_mult) * 4) / ((clock / 1000) *
   pixel_size);
 ^
 Maybe replace the divisor here w/ just 'entrie' since it's same thing.
 Makes it a bit easier to see the relationship between this and the way
 the precision is selected.
 

yeah, but that might be another seperate patch besides the precision
multipler this one trys to fix.

Thanks for review this.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Make num_sprites a per-pipe value

[Zhenyu Wang]

On 2014.02.28 16:42:15 +, Damien Lespiau wrote:
 In the future, we need to be able to specify per-pipe number of
 planes/sprites. Let's start today!
 

The number of sprite planes on each pipe is always fixed in our HW.
Do we really need this in the future?

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] sna: Add multiple planes support for Xv video on sprite

[Zhenyu Wang]

On VLV there're two sprite planes for each pipe that both can be
used simultaneously for Xv video. This one trys to expose those
capability through multiple Xv ports on sprite video adaptor.

I've tried to use this to validate new two sprite planes for
single pipe on VLV which works fine.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 src/sna/sna.h  |   5 ++-
 src/sna/sna_display.c  | 106 ++---
 src/sna/sna_video_sprite.c |  87 -
 3 files changed, 131 insertions(+), 67 deletions(-)

diff --git a/src/sna/sna.h b/src/sna/sna.h
index 4651632..ce51fef 100644
--- a/src/sna/sna.h
+++ b/src/sna/sna.h
@@ -285,6 +285,7 @@ struct sna {
unsigned num_real_crtc;
unsigned num_real_output;
unsigned num_fake;
+   unsigned num_sprite;
} mode;
 
struct sna_dri {
@@ -442,9 +443,9 @@ static inline void sna_dri_close(struct sna *sna, ScreenPtr 
pScreen) { }
 #endif
 void sna_dri_pixmap_update_bo(struct sna *sna, PixmapPtr pixmap);
 
-extern bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, uint32_t rotation);
+extern bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, XvPortPtr port, 
uint32_t rotation);
 extern int sna_crtc_to_pipe(xf86CrtcPtr crtc);
-extern uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc);
+extern uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc, XvPortPtr port);
 extern uint32_t sna_crtc_id(xf86CrtcPtr crtc);
 
 CARD32 sna_format_for_depth(int depth);
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index de08cb9..2e05733 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -100,13 +100,19 @@ struct rotation {
uint32_t current;
 };
 
+struct sna_crtc_sprite {
+   uint32_t id;
+   struct rotation sprite_rotation;
+};
+
 struct sna_crtc {
struct drm_mode_modeinfo kmode;
int dpms_mode;
PixmapPtr scanout_pixmap;
struct kgem_bo *bo, *shadow_bo;
uint32_t cursor;
-   uint32_t sprite;
+   int num_sprite;
+   struct sna_crtc_sprite *sprite;
bool shadow;
bool fallback_shadow;
bool transform;
@@ -115,7 +121,6 @@ struct sna_crtc {
 
uint32_t rotation;
struct rotation primary_rotation;
-   struct rotation sprite_rotation;
 };
 
 struct sna_property {
@@ -200,9 +205,24 @@ int sna_crtc_to_pipe(xf86CrtcPtr crtc)
return to_sna_crtc(crtc)-pipe;
 }
 
-uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc)
+static int sna_sprite_num(XvPortPtr port)
 {
-   return to_sna_crtc(crtc)-sprite;
+   XvAdaptorPtr adaptor = port-pAdaptor;
+   int i;
+
+   for (i = 0; i  adaptor-nPorts; i++) {
+   if (port == adaptor-pPorts[i])
+   return i;
+   }
+   return 0;
+}
+
+uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc, XvPortPtr port)
+{
+   struct sna_crtc *sna_crtc = to_sna_crtc(crtc);
+   int num = sna_sprite_num(port);
+
+   return sna_crtc-sprite[num].id;
 }
 
 #ifndef NDEBUG
@@ -674,15 +694,18 @@ rotation_reset(struct rotation *r)
r-current = 0;
 }
 
-bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, uint32_t rotation)
+bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, XvPortPtr port, uint32_t 
rotation)
 {
+   struct sna_crtc *sna_crtc = to_sna_crtc(crtc);
+   int num = sna_sprite_num(port);
+
DBG((%s: CRTC:%d [pipe=%d], sprite=%u set-rotation=%x\n,
 __FUNCTION__,
-to_sna_crtc(crtc)-id, to_sna_crtc(crtc)-pipe, 
to_sna_crtc(crtc)-sprite,
+sna_crtc-id, sna_crtc-pipe, sna_crtc-sprite[num].id,
 rotation));
 
return rotation_set(to_sna(crtc-scrn),
-   to_sna_crtc(crtc)-sprite_rotation,
+   sna_crtc-sprite[num].sprite_rotation,
rotation);
 }
 
@@ -1717,6 +1740,7 @@ sna_crtc_destroy(xf86CrtcPtr crtc)
sna_crtc_hide_cursor(crtc);
gem_close(to_sna(crtc-scrn)-kgem.fd, sna_crtc-cursor);
 
+   free(sna_crtc-sprite);
free(sna_crtc);
crtc-driver_private = NULL;
 }
@@ -1750,32 +1774,39 @@ static const xf86CrtcFuncsRec sna_crtc_funcs = {
 #endif
 };
 
-static int
-sna_crtc_find_sprite(struct sna *sna, int pipe)
+static void
+sna_crtc_find_sprite(struct sna *sna, struct sna_crtc *sna_crtc, int pipe)
 {
 #ifdef DRM_IOCTL_MODE_GETPLANERESOURCES
struct drm_mode_get_plane_res r;
-   uint32_t *planes, id = 0;
+   uint32_t *planes, *id;
int i;
 
VG_CLEAR(r);
r.count_planes = 0;
if (drmIoctl(sna-kgem.fd, DRM_IOCTL_MODE_GETPLANERESOURCES, r))
-   return 0;
+   return;
 
if (!r.count_planes)
-   return 0;
+   return;
 
planes = malloc(sizeof(uint32_t)*r.count_planes);
-   if (planes == NULL)
-   return 0;
+   id = malloc(sizeof(uint32_t)*r.count_planes);
+   if (planes

[Intel-gfx] [PATCH] drm/i915: Fix drain latency precision multipler for VLV

[Zhenyu Wang]

From spec the drain latency precision multipler is either 32 or 64 for VLV.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h | 18 +-
 drivers/gpu/drm/i915/intel_pm.c | 12 ++--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2f564ce..cb6509c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3381,19 +3381,19 @@
 
 /* drain latency register values*/
 #define DRAIN_LATENCY_PRECISION_32 32
-#define DRAIN_LATENCY_PRECISION_16 16
+#define DRAIN_LATENCY_PRECISION_64 64
 #define VLV_DDL1   (VLV_DISPLAY_BASE + 0x70050)
-#define DDL_CURSORA_PRECISION_32   (131)
-#define DDL_CURSORA_PRECISION_16   (031)
+#define DDL_CURSORA_PRECISION_64   (131)
+#define DDL_CURSORA_PRECISION_32   (031)
 #define DDL_CURSORA_SHIFT  24
-#define DDL_PLANEA_PRECISION_32(17)
-#define DDL_PLANEA_PRECISION_16(07)
+#define DDL_PLANEA_PRECISION_64(17)
+#define DDL_PLANEA_PRECISION_32(07)
 #define VLV_DDL2   (VLV_DISPLAY_BASE + 0x70054)
-#define DDL_CURSORB_PRECISION_32   (131)
-#define DDL_CURSORB_PRECISION_16   (031)
+#define DDL_CURSORB_PRECISION_64   (131)
+#define DDL_CURSORB_PRECISION_32   (031)
 #define DDL_CURSORB_SHIFT  24
-#define DDL_PLANEB_PRECISION_32(17)
-#define DDL_PLANEB_PRECISION_16(07)
+#define DDL_PLANEB_PRECISION_64(17)
+#define DDL_PLANEB_PRECISION_32(07)
 
 /* FIFO watermark sizes etc */
 #define G4X_FIFO_LINE_SIZE 64
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a6b877a..b17b396 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1248,13 +1248,13 @@ static bool vlv_compute_drain_latency(struct drm_device 
*dev,
 
entries = (clock / 1000) * pixel_size;
*plane_prec_mult = (entries  256) ?
-   DRAIN_LATENCY_PRECISION_32 : DRAIN_LATENCY_PRECISION_16;
+   DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
*plane_dl = (64 * (*plane_prec_mult) * 4) / ((clock / 1000) *
 pixel_size);
 
entries = (clock / 1000) * 4;   /* BPP is always 4 for cursor */
*cursor_prec_mult = (entries  256) ?
-   DRAIN_LATENCY_PRECISION_32 : DRAIN_LATENCY_PRECISION_16;
+   DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
*cursor_dl = (64 * (*cursor_prec_mult) * 4) / ((clock / 1000) * 4);
 
return true;
@@ -1280,9 +1280,9 @@ static void vlv_update_drain_latency(struct drm_device 
*dev)
if (vlv_compute_drain_latency(dev, 0, plane_prec_mult, planea_dl,
  cursor_prec_mult, cursora_dl)) {
cursora_prec = (cursor_prec_mult == DRAIN_LATENCY_PRECISION_32) 
?
-   DDL_CURSORA_PRECISION_32 : DDL_CURSORA_PRECISION_16;
+   DDL_CURSORA_PRECISION_32 : DDL_CURSORA_PRECISION_64;
planea_prec = (plane_prec_mult == DRAIN_LATENCY_PRECISION_32) ?
-   DDL_PLANEA_PRECISION_32 : DDL_PLANEA_PRECISION_16;
+   DDL_PLANEA_PRECISION_32 : DDL_PLANEA_PRECISION_64;
 
I915_WRITE(VLV_DDL1, cursora_prec |
(cursora_dl  DDL_CURSORA_SHIFT) |
@@ -1293,9 +1293,9 @@ static void vlv_update_drain_latency(struct drm_device 
*dev)
if (vlv_compute_drain_latency(dev, 1, plane_prec_mult, planeb_dl,
  cursor_prec_mult, cursorb_dl)) {
cursorb_prec = (cursor_prec_mult == DRAIN_LATENCY_PRECISION_32) 
?
-   DDL_CURSORB_PRECISION_32 : DDL_CURSORB_PRECISION_16;
+   DDL_CURSORB_PRECISION_32 : DDL_CURSORB_PRECISION_64;
planeb_prec = (plane_prec_mult == DRAIN_LATENCY_PRECISION_32) ?
-   DDL_PLANEB_PRECISION_32 : DDL_PLANEB_PRECISION_16;
+   DDL_PLANEB_PRECISION_32 : DDL_PLANEB_PRECISION_64;
 
I915_WRITE(VLV_DDL2, cursorb_prec |
(cursorb_dl  DDL_CURSORB_SHIFT) |
-- 
1.9.0

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

[Intel-gfx] [PATCH] intel: make sure VG_CLEAR() will always do memory clear

[Zhenyu Wang]

If valgrind is not available, current VG_CLEAR() would just ignore
memory clear operation which might make invalid ioctl argument. So
make sure VG_CLEAR() will always clear memory.
---
 intel/intel_bufmgr_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..389f73a 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -74,7 +74,7 @@
 #define VG(x)
 #endif
 
-#define VG_CLEAR(s) VG(memset(s, 0, sizeof(s)))
+#define VG_CLEAR(s) (memset(s, 0, sizeof(s)))
 
 #define DBG(...) do {  \
if (bufmgr_gem-bufmgr.debug)   \
-- 
1.8.4.3

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

Re: [Intel-gfx] [PATCH] intel: make sure VG_CLEAR() will always do memory clear

[Zhenyu Wang]

On 2013.11.20 11:36:20 +, Damien Lespiau wrote:
 On Wed, Nov 20, 2013 at 05:22:48PM +0800, Zhenyu Wang wrote:
  If valgrind is not available, current VG_CLEAR() would just ignore
  memory clear operation which might make invalid ioctl argument. So
  make sure VG_CLEAR() will always clear memory.
  ---
   intel/intel_bufmgr_gem.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
  index df6fcec..389f73a 100644
  --- a/intel/intel_bufmgr_gem.c
  +++ b/intel/intel_bufmgr_gem.c
  @@ -74,7 +74,7 @@
   #define VG(x)
   #endif
   
  -#define VG_CLEAR(s) VG(memset(s, 0, sizeof(s)))
  +#define VG_CLEAR(s) (memset(s, 0, sizeof(s)))
 
 VG_CLEAR() is really just for valgrind. If you need to set some specific
 variable/field to 0 then you need to set it to 0 and not rely on
 VG_CLEAR() to do it for you.
 

ok, in valgrind case it does memory clear for ioctl args which I think is
good behavior in non-valgrind case too.

 What's the actual issue you have?
 

During testing on recent get reset status ioctl, if !HAVE_VALGRIND, stats
argument is not cleared, which failed in kernel check.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel: make sure VG_CLEAR() will always do memory clear

[Zhenyu Wang]

On 2013.11.20 16:59:22 +, Damien Lespiau wrote:
 Right, so the fix is (was) to zero the fields checked by the kernel
 explicitely, not change the VG() macro, which is just used in testing
 (and it should this way).
 

That's fine. Thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V3 3/3] i915: introduce modeset_on_resume

[Zhenyu Wang]

On 2013.01.24 19:49:40 +0800, Zhang Rui wrote:
 I need some graphics experts' comments before sending it out.
 

Please send to intel-gfx@lists.freedesktop.org for i915 specific issue.

 On Thu, 2013-01-24 at 19:43 +0800, Zhang Rui wrote:
  i915 driver needs to do modeset when
  1. system resumes from sleep
  2. lid is opened
  
  When resuming from PM_SUSPEND_MEM state, all the GPEs are cleared,
  thus it is the i915_resume code does the modeset rather than 
  intel_lid_notify().
  
  But when in FREEZE state, system is still resposive to the lid events.
  1. i915_suspend() clears modeset_on_lid.
  2. When we close the lid, intel_lid_notify() sets modeset_on_lid.
  3. When we reopen the lid, intel_lid_notify() will do a modeset,
 before the system is resumed.
  
  here is the error log I got,
  
  [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
  intel_wait_for_pipe_off+0x184/0x190 [i915]()
  [92146.548076] Hardware name: VGN-Z540N
  [92146.548078] pipe_off wait timed out
  [92146.548167] Modules linked in: hid_generic usbhid hid 
  snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep 
  ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy 
  mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor 
  drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm 
  btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev 
  snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc 
  sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore 
  snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf 
  processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci 
  thermal e1000e
  [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: GW
  3.8.0-rc3-s0i3-v3-test+ #9
  [92146.548175] Call Trace:
  [92146.548189]  [c10378e2] warn_slowpath_common+0x72/0xa0
  [92146.548227]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548263]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548270]  [c10379b3] warn_slowpath_fmt+0x33/0x40
  [92146.548307]  [f86398b4] intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548344]  [f86399c2] intel_disable_pipe+0x102/0x190 [i915]
  [92146.548380]  [f8639ea4] ? intel_disable_plane+0x64/0x80 [i915]
  [92146.548417]  [f8639f7c] i9xx_crtc_disable+0xbc/0x150 [i915]
  [92146.548456]  [f863ebee] intel_crtc_update_dpms+0x5e/0x90 [i915]
  [92146.548493]  [f86437cf] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
  [92146.548535]  [f8645b0b] intel_lid_notify+0x9b/0xc0 [i915]
  [92146.548543]  [c15610d3] notifier_call_chain+0x43/0x60
  [92146.548550]  [c105d1e1] __blocking_notifier_call_chain+0x41/0x80
  [92146.548556]  [c105d23f] blocking_notifier_call_chain+0x1f/0x30
  [92146.548563]  [c131a684] acpi_lid_send_state+0x78/0xa4
  [92146.548569]  [c131aa9e] acpi_button_notify+0x3b/0xf1
  [92146.548577]  [c12df56a] ? acpi_os_execute+0x17/0x19
  [92146.548582]  [c12e591a] ? acpi_ec_sync_query+0xa5/0xbc
  [92146.548589]  [c12e2b82] acpi_device_notify+0x16/0x18
  [92146.548595]  [c12f4904] acpi_ev_notify_dispatch+0x38/0x4f
  [92146.548600]  [c12df0e8] acpi_os_execute_deferred+0x20/0x2b
  [92146.548607]  [c1051208] process_one_work+0x128/0x3f0
  [92146.548613]  [c1564f73] ? common_interrupt+0x33/0x38
  [92146.548618]  [c104f8c0] ? wake_up_worker+0x30/0x30
  [92146.548624]  [c12df0c8] ? acpi_os_wait_events_complete+0x1e/0x1e
  [92146.548629]  [c10524f9] worker_thread+0x119/0x3b0
  [92146.548634]  [c10523e0] ? manage_workers+0x240/0x240
  [92146.548640]  [c1056e84] kthread+0x94/0xa0
  [92146.548647]  [c106] ? 
  ftrace_raw_output_sched_stat_runtime+0x70/0xf0
  [92146.548652]  [c15649b7] ret_from_kernel_thread+0x1b/0x28
  [92146.548658]  [c1056df0] ? kthread_create_on_node+0xc0/0xc0
  
  Introduce a new flag modeset_on_resume to ignore the lid events during 
  suspend.
  
  Signed-off-by: Zhang Rui rui.zh...@intel.com
  ---
   drivers/gpu/drm/i915/i915_drv.c   |2 ++
   drivers/gpu/drm/i915/i915_drv.h   |1 +
   drivers/gpu/drm/i915/intel_lvds.c |2 ++
   3 files changed, 5 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/i915_drv.c 
  b/drivers/gpu/drm/i915/i915_drv.c
  index 1172658..0f990e1 100644
  --- a/drivers/gpu/drm/i915/i915_drv.c
  +++ b/drivers/gpu/drm/i915/i915_drv.c
  @@ -494,6 +494,7 @@ static int i915_drm_freeze(struct drm_device *dev)
   
  /* Modeset on resume, not lid events */
  dev_priv-modeset_on_lid = 0;
  +   dev_priv-modeset_on_resume = 1;
   
  console_lock();
  intel_fbdev_set_suspend(dev, 1);
  @@ -570,6 +571,7 @@ static int __i915_drm_thaw(struct drm_device *dev)
  intel_opregion_init(dev);
   
  dev_priv-modeset_on_lid = 0;
  +   dev_priv-modeset_on_resume = 0;
   
  /*
   * The console lock can be pretty contented on resume due
  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
  b/drivers/gpu/drm/i915/i915_drv.h
  index 

[Intel-gfx] [PATCH] drm/i915: Fix missed needs_dmar setting

[Zhenyu Wang]

From Ben's AGP dependence removal change, needs_dmar flag has not
been properly setup for new chips using new GTT init function. This
one adds missed setting of that flag to make sure we do pci mappings
with IOMMU enabled.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_gem_gtt.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index cc1be53..9ae588a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -665,6 +665,10 @@ int i915_gem_gtt_init(struct drm_device *dev)
if (!pci_set_dma_mask(dev-pdev, DMA_BIT_MASK(40)))
pci_set_consistent_dma_mask(dev-pdev, DMA_BIT_MASK(40));
 
+#ifdef CONFIG_INTEL_IOMMU
+   dev_priv-mm.gtt-needs_dmar = 1;
+#endif
+
/* For GEN6+ the PTEs for the ggtt live at 2MB + BAR0 */
gtt_bus_addr = pci_resource_start(dev-pdev, 0) + (220);
dev_priv-mm.gtt-gma_bus_addr = pci_resource_start(dev-pdev, 2);
-- 
1.7.10.4

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

[Intel-gfx] [PATCH] drm/i915: Fix HSW power well control state read

[Zhenyu Wang]

Fix power well control state by reading real register offset.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_pm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 838d67d..3bcaad6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3812,7 +3812,7 @@ void intel_init_power_wells(struct drm_device *dev)
 
if ((well  HSW_PWR_WELL_STATE) == 0) {
I915_WRITE(power_wells[i], well  HSW_PWR_WELL_ENABLE);
-   if (wait_for(I915_READ(power_wells[i]  
HSW_PWR_WELL_STATE), 20))
+   if (wait_for((I915_READ(power_wells[i])  
HSW_PWR_WELL_STATE), 20))
DRM_ERROR(Error enabling power well %lx\n, 
power_wells[i]);
}
}
-- 
1.7.10.4

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

Re: [Intel-gfx] NM10 chipset with GMA3600

[Zhenyu Wang]

On 2012.05.03 12:16:26 +, lbg_...@bluebottle.com wrote:
 Hello everyone,
 
 I'm writing to this list, hoping not to be in the wrong place. The subject is 
 a GMA 3600 graphic controller which I have on a D2500CC Mini-ITX Intel board. 
 My operating system is Debian Wheezy with latest stable 3.3.4 kernel (GMA3600 
 option compiled in).
 

You might send kernel log to Alan, and describe what's your display
configuration, upstream kernel should have basic display support.

Or maybe I guess your board might have unsupported pci ids, cedarview
has so many variants.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] HDMI monitor hot remove handling

[Zhenyu Wang]

On 2011.11.11 16:50:41 +0800, Wu Fengguang wrote:
I still think you should do those in hot_plug(), to call detect() for 
current
status, write eld and set specific audio enable/disable bit for all 
audio stuff.
Just my sense, you may send RFC patch for other's comment. 
 
  yeah, mode_set() will only be in normal mode setting path and taking current
  monitor's audio capability, but not on hot removal path. And if connector's 
  DPMS off,
  does audio need to care? I think no, as user might still like to hear 
  sound, right? ;)
  
  So looks currently nobody cares for hot removal, you need to set that by
  yourself somewhere.
 
 Zhenyu, according to your comments, here is the patch, tested OK on
 HDMI :)  DP not tested yet.

Well, I don't think I suggested a new hook for hot removal. ;)

You know that hot_plug() hook is intel encoder thing, which is the place
I think you can do audio config stuff. 

 
 This notifies the audio driver of the HDMI/DP monitor hot removal
 event.
 
 - clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
 - clear ELD Valid bit
 
 Signed-off-by: Wu Fengguang fengguang...@intel.com
 ---
  drivers/gpu/drm/drm_crtc_helper.c |4 
  drivers/gpu/drm/i915/intel_dp.c   |   19 +++
  drivers/gpu/drm/i915/intel_drv.h  |4 
  drivers/gpu/drm/i915/intel_hdmi.c |   17 +
  include/drm/drm_crtc.h|1 +
  5 files changed, 45 insertions(+)
 
 --- linux.orig/drivers/gpu/drm/i915/intel_dp.c2011-11-11 
 16:42:58.0 +0800
 +++ linux/drivers/gpu/drm/i915/intel_dp.c 2011-11-11 16:42:59.0 
 +0800
 @@ -1984,6 +1984,24 @@ intel_dp_detect(struct drm_connector *co
   return connector_status_connected;
  }
  
 +static void intel_dp_hot_remove(struct drm_connector *connector)
 +{
 + struct intel_dp *intel_dp = intel_attached_dp(connector);
 + struct drm_device *dev = intel_dp-base.base.dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct drm_crtc *crtc = intel_dp-base.base.crtc;
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 +
 + intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
 + I915_WRITE(intel_dp-output_reg, intel_dp-DP);
 + POSTING_READ(intel_dp-output_reg);
 + intel_wait_for_vblank(dev, intel_crtc-pipe);
 +
 + connector-eld[0] = 0;
 + if (dev_priv-display.write_eld)
 + dev_priv-display.write_eld(connector, crtc);
 +}
 +
  static int intel_dp_get_modes(struct drm_connector *connector)
  {
   struct intel_dp *intel_dp = intel_attached_dp(connector);
 @@ -2143,6 +2161,7 @@ static const struct drm_connector_funcs 
   .detect = intel_dp_detect,
   .fill_modes = drm_helper_probe_single_connector_modes,
   .set_property = intel_dp_set_property,
 + .hot_remove = intel_dp_hot_remove,
   .destroy = intel_dp_destroy,
  };
  
 --- linux.orig/drivers/gpu/drm/i915/intel_drv.h   2011-11-11 
 16:42:58.0 +0800
 +++ linux/drivers/gpu/drm/i915/intel_drv.h2011-11-11 16:42:59.0 
 +0800
 @@ -382,6 +382,10 @@ extern void intel_fb_restore_mode(struct
  extern void intel_init_clock_gating(struct drm_device *dev);
  extern void intel_write_eld(struct drm_encoder *encoder,
   struct drm_display_mode *mode);
 +extern void intel_hotplug_status(struct drm_device *dev,
 +   struct drm_connector *connector,
 +   struct drm_crtc *crtc,
 +   enum drm_connector_status status);
  extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
  
  #endif /* __INTEL_DRV_H__ */
 --- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c  2011-11-11 
 16:42:58.0 +0800
 +++ linux/drivers/gpu/drm/i915/intel_hdmi.c   2011-11-11 16:42:59.0 
 +0800
 @@ -352,6 +352,22 @@ intel_hdmi_detect(struct drm_connector *
   return status;
  }
  
 +static void intel_hdmi_hot_remove(struct drm_connector *connector)
 +{
 + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 + struct drm_i915_private *dev_priv = connector-dev-dev_private;
 + u32 temp;
 +
 + temp = I915_READ(intel_hdmi-sdvox_reg);
 + I915_WRITE(intel_hdmi-sdvox_reg, temp  ~SDVO_AUDIO_ENABLE);
 + POSTING_READ(intel_hdmi-sdvox_reg);
 +
 + connector-eld[0] = 0;
 + if (dev_priv-display.write_eld)
 + dev_priv-display.write_eld(connector,
 + intel_hdmi-base.base.crtc);
 +}
 +
  static int intel_hdmi_get_modes(struct drm_connector *connector)
  {
   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 @@ -461,6 +477,7 @@ static const struct drm_connector_funcs 
   .detect = intel_hdmi_detect,
   .fill_modes = drm_helper_probe_single_connector_modes,
   .set_property = intel_hdmi_set_property,
 + .hot_remove = intel_hdmi_hot_remove,
   .destroy = intel_hdmi_destroy,
  };
  
 --- linux.orig/drivers/gpu/drm/drm_crtc_helper.c  2011-11-11 
 

Re: [Intel-gfx] [PATCH] Revert drm/i915: Don't save/restore hardware status page address register

[Zhenyu Wang]

On 2011.03.23 18:16:55 +, Chris Wilson wrote:
 This reverts commit a7a75c8f70d6f6a2f16c9f627f938bbee2d32718.
 
 There are two different variations on how Intel hardware addresses the
 Hardware Status Page. One as a location in physical memory and the
 other as an offset into the virtual memory of the GPU, used in more
 recent chipsets. (The HWS itself is a cacheable region of memory which
 the GPU can write to without requiring CPU synchronisation, used for
 updating various details of hardware state, such as the position of
 the GPU head in the ringbuffer, the last breadcrumb seqno, etc).
 
 These two types of addresses were updated in different locations of code
 - one inline with the ringbuffer initialisation, and the other during
 device initialisation. (The HWS page is logically associated with
 the rings, and there is one HWS page per ring.) During resume, only the
 ringbuffers were being re-initialised along with the virtual HWS page,
 leaving the older physical address HWS untouched. This then caused a
 hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried
 to synchronise the GPU as the breadcrumbs were never being updated.

oops, right, I ignored those old devices.

 
 Reported-by: Linus Torvalds torva...@linux-foundation.org
 Reported-by: Jan Niehusmann j...@gondor.com
 Reported-by: Justin P. Mattock justinmatt...@gmail.com
 Reported-and-tested-by: Michael brot Groh b...@minad.de
 Cc: Zhenyu Wang zhen...@linux.intel.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_drv.h |1 +
  drivers/gpu/drm/i915/i915_suspend.c |6 ++
  2 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 4496505..5004724 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -383,6 +383,7 @@ typedef struct drm_i915_private {
   u32 saveDSPACNTR;
   u32 saveDSPBCNTR;
   u32 saveDSPARB;
 + u32 saveHWS;
   u32 savePIPEACONF;
   u32 savePIPEBCONF;
   u32 savePIPEASRC;
 diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
 b/drivers/gpu/drm/i915/i915_suspend.c
 index 7e992a8..da47415 100644
 --- a/drivers/gpu/drm/i915/i915_suspend.c
 +++ b/drivers/gpu/drm/i915/i915_suspend.c
 @@ -796,6 +796,9 @@ int i915_save_state(struct drm_device *dev)
  
   pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
  
 + /* Hardware status page */
 + dev_priv-saveHWS = I915_READ(HWS_PGA);
 +
   i915_save_display(dev);
  
   /* Interrupt state */
 @@ -842,6 +845,9 @@ int i915_restore_state(struct drm_device *dev)
  
   pci_write_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
  
 + /* Hardware status page */
 + I915_WRITE(HWS_PGA, dev_priv-saveHWS);
 +

We'd better only save/restore this for !I915_NEED_GFX_HWS(dev),
note that HWS_PGA is not valid hw status register for new chip, e.g gen6.

   i915_restore_display(dev);
  
   /* Interrupt state */
 -- 
 1.7.4.1

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/4 rev2] Sandybridge suspend/resume fixes

[Zhenyu Wang]

I've done more testing with below patches, eliminated some in first
patch set that doesn't affect suspend issue it seems.

The test was done with one rev9 SNB on two boards DH67GD and DQ67SW
with latest bios. And it both passed over 100 cycles of S3 testing.
Without these, upstream kernel still hang quickly on them.

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

[Intel-gfx] [PATCH 1/4] drm/i915: clock gating fix for gen5 and gen6

[Zhenyu Wang]

Some bits should only be set when enable FBC.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h  |4 +++-
 drivers/gpu/drm/i915/intel_display.c |   27 ++-
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2abe240..b0aabe4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2771,8 +2771,10 @@
 #define  ILK_eDP_A_DISABLE (124)
 #define  ILK_DESKTOP   (123)
 #define ILK_DSPCLK_GATE0x42020
-#define  ILK_DPARB_CLK_GATE(15)
+#define  ILK_DPFC_CLK_GATE (19)
+#define  ILK_DPFCR_CLK_GATE(18)
 #define  ILK_DPFD_CLK_GATE (17)
+#define  ILK_DPARB_CLK_GATE(15)
 
 /* According to spec this bit 7/8/9 of 0x42020 should be set to enable FBC */
 #define   ILK_CLK_FBC  (17)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 49fb54f..b7d1101 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6452,7 +6452,7 @@ void intel_enable_clock_gating(struct drm_device *dev)
   ILK_FBCQ_DIS);
I915_WRITE(ILK_DISPLAY_CHICKEN2,
   I915_READ(ILK_DISPLAY_CHICKEN2) |
-  ILK_DPARB_GATE);
+  ILK_DPARB_GATE | ILK_ELPIN_409_SELECT);
I915_WRITE(ILK_DSPCLK_GATE,
   I915_READ(ILK_DSPCLK_GATE) |
   ILK_DPFC_DIS1 |
@@ -6460,10 +6460,6 @@ void intel_enable_clock_gating(struct drm_device *dev)
   ILK_CLK_FBC);
}
 
-   I915_WRITE(ILK_DISPLAY_CHICKEN2,
-  I915_READ(ILK_DISPLAY_CHICKEN2) |
-  ILK_ELPIN_409_SELECT);
-
if (IS_GEN5(dev)) {
I915_WRITE(_3D_CHICKEN2,
   _3D_CHICKEN2_WM_READ_PIPELINED  16 |
@@ -6484,16 +6480,21 @@ void intel_enable_clock_gating(struct drm_device *dev)
 * The bit14 of 0x70180
 * The bit14 of 0x71180
 */
-   I915_WRITE(ILK_DISPLAY_CHICKEN1,
-  I915_READ(ILK_DISPLAY_CHICKEN1) |
-  ILK_FBCQ_DIS | ILK_PABSTRETCH_DIS);
+   if (I915_HAS_FBC(dev)  i915_powersave) {
+   I915_WRITE(ILK_DISPLAY_CHICKEN1,
+  I915_READ(ILK_DISPLAY_CHICKEN1) |
+  ILK_FBCQ_DIS | ILK_PABSTRETCH_DIS);
+   I915_WRITE(ILK_DSPCLK_GATE,
+  I915_READ(ILK_DSPCLK_GATE) |
+  ILK_DPFC_CLK_GATE | 
ILK_DPFCR_CLK_GATE);
+   } else
+   I915_WRITE(ILK_DISPLAY_CHICKEN1,
+  I915_READ(ILK_DISPLAY_CHICKEN1) |
+  ILK_PABSTRETCH_DIS);
+
I915_WRITE(ILK_DISPLAY_CHICKEN2,
   I915_READ(ILK_DISPLAY_CHICKEN2) |
-  ILK_DPARB_GATE | ILK_VSDPFD_FULL);
-   I915_WRITE(ILK_DSPCLK_GATE,
-  I915_READ(ILK_DSPCLK_GATE) |
-  ILK_DPARB_CLK_GATE  |
-  ILK_DPFD_CLK_GATE);
+  ILK_VSDPFD_FULL | ILK_ELPIN_409_SELECT);
 
I915_WRITE(DSPACNTR,
   I915_READ(DSPACNTR) |
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 2/4] drm/i915: save/restore DSPARB only for chips before gen4 but not for G33

[Zhenyu Wang]

DSPARB is reserved on G33 and not available on Gen6.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_suspend.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 0521ecf..8d165c4 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -603,7 +603,8 @@ void i915_save_display(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
 
/* Display arbitration control */
-   dev_priv-saveDSPARB = I915_READ(DSPARB);
+   if (dev_priv-info-gen  4  !IS_G33(dev))
+   dev_priv-saveDSPARB = I915_READ(DSPARB);
 
/* This is only meaningful in non-KMS mode */
/* Don't save them in KMS mode */
@@ -695,7 +696,8 @@ void i915_restore_display(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
 
/* Display arbitration */
-   I915_WRITE(DSPARB, dev_priv-saveDSPARB);
+   if (dev_priv-info-gen  4  !IS_G33(dev))
+   I915_WRITE(DSPARB, dev_priv-saveDSPARB);
 
/* Display port ratios (must be done before clock is set) */
if (SUPPORTS_INTEGRATED_DP(dev)) {
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 4/4] drm/i915: move sandybridge RC6 enable in resume after ring initialization

[Zhenyu Wang]

Move RC6 enable after we reset rings for all regines, if e.g render ring
is disabled when RC6 enable on Sandybridge, hw won't save render context
image if any chance when enter RC6. Also match the order like we do in
driver load.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c |3 +++
 drivers/gpu/drm/i915/i915_suspend.c |3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 22ec066..e675ba9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -378,6 +378,9 @@ static int i915_drm_thaw(struct drm_device *dev)
 
if (IS_IRONLAKE_M(dev))
ironlake_enable_rc6(dev);
+
+   if (IS_GEN6(dev))
+   gen6_enable_rps(dev_priv);
}
 
intel_opregion_init(dev);
diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index bce24d8..08c1d04 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -875,9 +875,6 @@ int i915_restore_state(struct drm_device *dev)
intel_init_emon(dev);
}
 
-   if (IS_GEN6(dev))
-   gen6_enable_rps(dev_priv);
-
/* Cache mode state */
I915_WRITE (CACHE_MODE_0, dev_priv-saveCACHE_MODE_0 | 0x);
 
-- 
1.7.4.1

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: save/restore DSPARB only for chips before gen4 but not for G33

[Zhenyu Wang]

On 2011.03.23 12:03:41 +0900, Keith Packard wrote:
 On Wed, 23 Mar 2011 10:21:07 +0800, Zhenyu Wang zhen...@linux.intel.com 
 wrote:
 
  DSPARB is reserved on G33 and not available on Gen6.
 
 Does this fix a reported problem? Or just spec compliance?
 

I didn't verify if this one is really related, but save/restore
an arbitrary undefined reg seems wrong to me. ;)

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/8] Patches for Sandybridge suspend/resume fixes

[Zhenyu Wang]

Below patches aim to fix https://bugs.freedesktop.org/show_bug.cgi?id=35462.
With them I've been able to run many cycles of S3 tests on two SNB/CPT boards
here, which would hang immediately after S3 resume with upstream kernel.

It still needs more testing, I'd like to get them reviewed first.

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

[Intel-gfx] [PATCH 1/8] drm/i915: clock gating fix for gen5 and gen6

[Zhenyu Wang]

Some bits should only be set when enable FBC.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_reg.h  |4 +++-
 drivers/gpu/drm/i915/intel_display.c |   27 ++-
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2abe240..b0aabe4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2771,8 +2771,10 @@
 #define  ILK_eDP_A_DISABLE (124)
 #define  ILK_DESKTOP   (123)
 #define ILK_DSPCLK_GATE0x42020
-#define  ILK_DPARB_CLK_GATE(15)
+#define  ILK_DPFC_CLK_GATE (19)
+#define  ILK_DPFCR_CLK_GATE(18)
 #define  ILK_DPFD_CLK_GATE (17)
+#define  ILK_DPARB_CLK_GATE(15)
 
 /* According to spec this bit 7/8/9 of 0x42020 should be set to enable FBC */
 #define   ILK_CLK_FBC  (17)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 232c4ec..13b17e0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6461,7 +6461,7 @@ void intel_enable_clock_gating(struct drm_device *dev)
   ILK_FBCQ_DIS);
I915_WRITE(ILK_DISPLAY_CHICKEN2,
   I915_READ(ILK_DISPLAY_CHICKEN2) |
-  ILK_DPARB_GATE);
+  ILK_DPARB_GATE | ILK_ELPIN_409_SELECT);
I915_WRITE(ILK_DSPCLK_GATE,
   I915_READ(ILK_DSPCLK_GATE) |
   ILK_DPFC_DIS1 |
@@ -6469,10 +6469,6 @@ void intel_enable_clock_gating(struct drm_device *dev)
   ILK_CLK_FBC);
}
 
-   I915_WRITE(ILK_DISPLAY_CHICKEN2,
-  I915_READ(ILK_DISPLAY_CHICKEN2) |
-  ILK_ELPIN_409_SELECT);
-
if (IS_GEN5(dev)) {
I915_WRITE(_3D_CHICKEN2,
   _3D_CHICKEN2_WM_READ_PIPELINED  16 |
@@ -6493,16 +6489,21 @@ void intel_enable_clock_gating(struct drm_device *dev)
 * The bit14 of 0x70180
 * The bit14 of 0x71180
 */
-   I915_WRITE(ILK_DISPLAY_CHICKEN1,
-  I915_READ(ILK_DISPLAY_CHICKEN1) |
-  ILK_FBCQ_DIS | ILK_PABSTRETCH_DIS);
+   if (I915_HAS_FBC(dev)  i915_powersave) {
+   I915_WRITE(ILK_DISPLAY_CHICKEN1,
+  I915_READ(ILK_DISPLAY_CHICKEN1) |
+  ILK_FBCQ_DIS | ILK_PABSTRETCH_DIS);
+   I915_WRITE(ILK_DSPCLK_GATE,
+  I915_READ(ILK_DSPCLK_GATE) |
+  ILK_DPFC_CLK_GATE | 
ILK_DPFCR_CLK_GATE);
+   } else
+   I915_WRITE(ILK_DISPLAY_CHICKEN1,
+  I915_READ(ILK_DISPLAY_CHICKEN1) |
+  ILK_PABSTRETCH_DIS);
+
I915_WRITE(ILK_DISPLAY_CHICKEN2,
   I915_READ(ILK_DISPLAY_CHICKEN2) |
-  ILK_DPARB_GATE | ILK_VSDPFD_FULL);
-   I915_WRITE(ILK_DSPCLK_GATE,
-  I915_READ(ILK_DSPCLK_GATE) |
-  ILK_DPARB_CLK_GATE  |
-  ILK_DPFD_CLK_GATE);
+  ILK_VSDPFD_FULL | ILK_ELPIN_409_SELECT);
 
I915_WRITE(DSPACNTR,
   I915_READ(DSPACNTR) |
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 2/8] drm/i915: remove LBB config save/restore

[Zhenyu Wang]

we don't use it anywhere.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_suspend.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 0521ecf..422981b 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -795,8 +795,6 @@ int i915_save_state(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int i;
 
-   pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
-
/* Hardware status page */
dev_priv-saveHWS = I915_READ(HWS_PGA);
 
@@ -844,8 +842,6 @@ int i915_restore_state(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int i;
 
-   pci_write_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
-
/* Hardware status page */
I915_WRITE(HWS_PGA, dev_priv-saveHWS);
 
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 3/8] drm/i915: save/restore DSPARB only for chip before gen4

[Zhenyu Wang]

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_suspend.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 422981b..7f00f8b 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -603,7 +603,8 @@ void i915_save_display(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
 
/* Display arbitration control */
-   dev_priv-saveDSPARB = I915_READ(DSPARB);
+   if (dev_priv-info-gen  4)
+   dev_priv-saveDSPARB = I915_READ(DSPARB);
 
/* This is only meaningful in non-KMS mode */
/* Don't save them in KMS mode */
@@ -695,7 +696,8 @@ void i915_restore_display(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
 
/* Display arbitration */
-   I915_WRITE(DSPARB, dev_priv-saveDSPARB);
+   if (dev_priv-info-gen  4)
+   I915_WRITE(DSPARB, dev_priv-saveDSPARB);
 
/* Display port ratios (must be done before clock is set) */
if (SUPPORTS_INTEGRATED_DP(dev)) {
@@ -795,9 +797,6 @@ int i915_save_state(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int i;
 
-   /* Hardware status page */
-   dev_priv-saveHWS = I915_READ(HWS_PGA);
-
i915_save_display(dev);
 
/* Interrupt state */
@@ -842,9 +841,6 @@ int i915_restore_state(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int i;
 
-   /* Hardware status page */
-   I915_WRITE(HWS_PGA, dev_priv-saveHWS);
-
i915_restore_display(dev);
 
/* Interrupt state */
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 4/8] drm/i915: remove CACHE_MODE_0 save/restore

[Zhenyu Wang]

we don't use it anywhere.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_suspend.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 7f00f8b..11e61a3 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -819,9 +819,6 @@ int i915_save_state(struct drm_device *dev)
if (IS_GEN6(dev))
gen6_disable_rps(dev);
 
-   /* Cache mode state */
-   dev_priv-saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0);
-
/* Memory Arbitration state */
dev_priv-saveMI_ARB_STATE = I915_READ(MI_ARB_STATE);
 
@@ -867,9 +864,6 @@ int i915_restore_state(struct drm_device *dev)
if (IS_GEN6(dev))
gen6_enable_rps(dev_priv);
 
-   /* Cache mode state */
-   I915_WRITE (CACHE_MODE_0, dev_priv-saveCACHE_MODE_0 | 0x);
-
/* Memory arbitration state */
I915_WRITE (MI_ARB_STATE, dev_priv-saveMI_ARB_STATE | 0x);
 
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 5/8] drm/i915: save/restore MI_ARB_STATE only for gen3

[Zhenyu Wang]

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_suspend.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 11e61a3..26387c3 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -820,7 +820,8 @@ int i915_save_state(struct drm_device *dev)
gen6_disable_rps(dev);
 
/* Memory Arbitration state */
-   dev_priv-saveMI_ARB_STATE = I915_READ(MI_ARB_STATE);
+   if (IS_GEN3(dev))
+   dev_priv-saveMI_ARB_STATE = I915_READ(MI_ARB_STATE);
 
/* Scratch space */
for (i = 0; i  16; i++) {
@@ -865,7 +866,8 @@ int i915_restore_state(struct drm_device *dev)
gen6_enable_rps(dev_priv);
 
/* Memory arbitration state */
-   I915_WRITE (MI_ARB_STATE, dev_priv-saveMI_ARB_STATE | 0x);
+   if (IS_GEN3(dev))
+   I915_WRITE (MI_ARB_STATE, dev_priv-saveMI_ARB_STATE | 
0x);
 
for (i = 0; i  16; i++) {
I915_WRITE(SWF00 + (i  2), dev_priv-saveSWF0[i]);
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 6/8] drm/i915: change force wake order for GT read

[Zhenyu Wang]

Move FORCEWAKE_ACK == 0 wait after setting force wake to 0. This is
another way to set force wake for GT read from spec. And also this
makes RC6 setting order strictly follow spec.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dd8bd5c..a55b71d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -264,10 +264,6 @@ void __gen6_gt_force_wake_get(struct drm_i915_private 
*dev_priv)
 {
int count;
 
-   count = 0;
-   while (count++  50  (I915_READ_NOTRACE(FORCEWAKE_ACK)  1))
-   udelay(10);
-
I915_WRITE_NOTRACE(FORCEWAKE, 1);
POSTING_READ(FORCEWAKE);
 
@@ -278,8 +274,15 @@ void __gen6_gt_force_wake_get(struct drm_i915_private 
*dev_priv)
 
 void __gen6_gt_force_wake_put(struct drm_i915_private *dev_priv)
 {
+   int count;
+
I915_WRITE_NOTRACE(FORCEWAKE, 0);
POSTING_READ(FORCEWAKE);
+
+   count = 0;
+   while (count++  50  (I915_READ_NOTRACE(FORCEWAKE_ACK)  1))
+   udelay(10);
+
 }
 
 void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
-- 
1.7.4.1

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

[Intel-gfx] [PATCH 7/8] drm/i915: move sandybridge RC6 enable in resume after ring initialization

[Zhenyu Wang]

Move RC6 enable after we reset rings for all regines, as RC6 on
Sandybridge would setup ring idle state, so I assume we should have
setup rings already.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c |4 
 drivers/gpu/drm/i915/i915_suspend.c |3 ---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a55b71d..b40f3ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -384,6 +384,10 @@ static int i915_drm_thaw(struct drm_device *dev)
 
if (IS_IRONLAKE_M(dev))
ironlake_enable_rc6(dev);
+
+   if (IS_GEN6(dev))
+   gen6_enable_rps(dev_priv);
+
}
 
intel_opregion_init(dev);
diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 26387c3..8e6aa8c 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -862,9 +862,6 @@ int i915_restore_state(struct drm_device *dev)
intel_init_emon(dev);
}
 
-   if (IS_GEN6(dev))
-   gen6_enable_rps(dev_priv);
-
/* Memory arbitration state */
if (IS_GEN3(dev))
I915_WRITE (MI_ARB_STATE, dev_priv-saveMI_ARB_STATE | 
0x);
-- 
1.7.4.1

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915: remove CACHE_MODE_0 save/restore

[Zhenyu Wang]

On 2011.03.21 10:40:51 -0700, Jesse Barnes wrote:
 On Mon, 21 Mar 2011 17:27:15 +0800
 Zhenyu Wang zhen...@linux.intel.com wrote:
 
  we don't use it anywhere.
  
  Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
  ---
   drivers/gpu/drm/i915/i915_suspend.c |6 --
   1 files changed, 0 insertions(+), 6 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
  b/drivers/gpu/drm/i915/i915_suspend.c
  index 7f00f8b..11e61a3 100644
  --- a/drivers/gpu/drm/i915/i915_suspend.c
  +++ b/drivers/gpu/drm/i915/i915_suspend.c
  @@ -819,9 +819,6 @@ int i915_save_state(struct drm_device *dev)
  if (IS_GEN6(dev))
  gen6_disable_rps(dev);
   
  -   /* Cache mode state */
  -   dev_priv-saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0);
  -
  /* Memory Arbitration state */
  dev_priv-saveMI_ARB_STATE = I915_READ(MI_ARB_STATE);
   
  @@ -867,9 +864,6 @@ int i915_restore_state(struct drm_device *dev)
  if (IS_GEN6(dev))
  gen6_enable_rps(dev_priv);
   
  -   /* Cache mode state */
  -   I915_WRITE (CACHE_MODE_0, dev_priv-saveCACHE_MODE_0 | 0x);
  -
  /* Memory arbitration state */
  I915_WRITE (MI_ARB_STATE, dev_priv-saveMI_ARB_STATE | 0x);
 
 I'd be fine with this if we actually set CACHE_MODE_0 to a reasonable
 value somewhere else.  But right now we rely on the BIOS settings and
 for the BIOS to reprogram it at resume, which may or may not be
 reliable.
 

I think if we don't touch it in driver we might just keep as it,
but your concern seems reasonable as well... I'll test to see if this
really impacts on suspend issue.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/8] drm/i915: change force wake order for GT read

[Zhenyu Wang]

On 2011.03.21 09:46:20 +, Chris Wilson wrote:
 On Mon, 21 Mar 2011 17:27:17 +0800, Zhenyu Wang zhen...@linux.intel.com 
 wrote:
  Move FORCEWAKE_ACK == 0 wait after setting force wake to 0. This is
  another way to set force wake for GT read from spec. And also this
  makes RC6 setting order strictly follow spec.
 
 The spec does indeed give both methods. So do you have any reason to
 change to the slower variant?

Just mean to follow the doc, it matches the sequence of RC6 enabling steps
from GT PM programming doc, not sure if it's strictly required.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm/i915: remove LBB config save/restore

[Zhenyu Wang]

On 2011.03.21 10:36:01 -0700, Jesse Barnes wrote:
 On Mon, 21 Mar 2011 17:27:13 +0800
 Zhenyu Wang zhen...@linux.intel.com wrote:
 
  we don't use it anywhere.
  
  Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
  ---
   drivers/gpu/drm/i915/i915_suspend.c |4 
   1 files changed, 0 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
  b/drivers/gpu/drm/i915/i915_suspend.c
  index 0521ecf..422981b 100644
  --- a/drivers/gpu/drm/i915/i915_suspend.c
  +++ b/drivers/gpu/drm/i915/i915_suspend.c
  @@ -795,8 +795,6 @@ int i915_save_state(struct drm_device *dev)
  struct drm_i915_private *dev_priv = dev-dev_private;
  int i;
   
  -   pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
  -
  /* Hardware status page */
  dev_priv-saveHWS = I915_READ(HWS_PGA);
   
  @@ -844,8 +842,6 @@ int i915_restore_state(struct drm_device *dev)
  struct drm_i915_private *dev_priv = dev-dev_private;
  int i;
   
  -   pci_write_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
  -
  /* Hardware status page */
  I915_WRITE(HWS_PGA, dev_priv-saveHWS);
 
 This may affect older platforms and prevent backlight save/restore?  At
 least I think that's why we added it in the first place...
 

oh, I just grep it's not used any more, or we plan to add it back?

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/8] drm/i915: save/restore DSPARB only for chip before gen4

[Zhenyu Wang]

On 2011.03.21 10:39:54 -0700, Jesse Barnes wrote:
 On Mon, 21 Mar 2011 17:27:14 +0800
 Zhenyu Wang zhen...@linux.intel.com wrote:
 
  Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
  ---
   drivers/gpu/drm/i915/i915_suspend.c |   12 
   1 files changed, 4 insertions(+), 8 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
  b/drivers/gpu/drm/i915/i915_suspend.c
  index 422981b..7f00f8b 100644
  --- a/drivers/gpu/drm/i915/i915_suspend.c
  +++ b/drivers/gpu/drm/i915/i915_suspend.c
  @@ -603,7 +603,8 @@ void i915_save_display(struct drm_device *dev)
  struct drm_i915_private *dev_priv = dev-dev_private;
   
  /* Display arbitration control */
  -   dev_priv-saveDSPARB = I915_READ(DSPARB);
  +   if (dev_priv-info-gen  4)
  +   dev_priv-saveDSPARB = I915_READ(DSPARB);
   
  /* This is only meaningful in non-KMS mode */
  /* Don't save them in KMS mode */
  @@ -695,7 +696,8 @@ void i915_restore_display(struct drm_device *dev)
  struct drm_i915_private *dev_priv = dev-dev_private;
   
  /* Display arbitration */
  -   I915_WRITE(DSPARB, dev_priv-saveDSPARB);
  +   if (dev_priv-info-gen  4)
  +   I915_WRITE(DSPARB, dev_priv-saveDSPARB);
 
 Was it Cantiga that started doing automatic FIFO sizing for us?
 Checking the docs...  Yeah, only Bearlake-C (G33?) and Cantiga do this
 automatically.  So a blanket gen4 check probably isn't right.
 

I just saw we only use it for gen  4 chips, also including G33 (gen=3)...


   
  /* Display port ratios (must be done before clock is set) */
  if (SUPPORTS_INTEGRATED_DP(dev)) {
  @@ -795,9 +797,6 @@ int i915_save_state(struct drm_device *dev)
  struct drm_i915_private *dev_priv = dev-dev_private;
  int i;
   
  -   /* Hardware status page */
  -   dev_priv-saveHWS = I915_READ(HWS_PGA);
  -
  i915_save_display(dev);
   
  /* Interrupt state */
  @@ -842,9 +841,6 @@ int i915_restore_state(struct drm_device *dev)
  struct drm_i915_private *dev_priv = dev-dev_private;
  int i;
   
  -   /* Hardware status page */
  -   I915_WRITE(HWS_PGA, dev_priv-saveHWS);
  -
  i915_restore_display(dev);
   
  /* Interrupt state */
 
 
 These hunks are unrelated to DSPARB; assuming we actually want to do
 this it should be a separate patch.  Based on earlier reports, it
 sounds like we're not properly idling across suspend/resume, in that
 we're trying to execute commands at resume before setting up the HWS
 again.
 

sorry, it's already in Chris's tree, but not in Linus's yet.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/8] drm/i915: move sandybridge RC6 enable in resume after ring initialization

[Zhenyu Wang]

On 2011.03.21 10:46:53 -0700, Jesse Barnes wrote:
 On Mon, 21 Mar 2011 17:27:18 +0800
 Zhenyu Wang zhen...@linux.intel.com wrote:
 
  Move RC6 enable after we reset rings for all regines, as RC6 on
  Sandybridge would setup ring idle state, so I assume we should have
  setup rings already.
 
 So you're seeing the idle value get clobbered?  Otherwise it's it
 better to set the ring idle value before actually starting the ring?
 

Don't know, but I can ask if we should do like that or not. I had more
stable test result with this.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: remove unused old i915_write()

[Zhenyu Wang]

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h |   21 -
 1 files changed, 0 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65dfe81..fe2a596 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1369,27 +1369,6 @@ static inline u32 i915_safe_read(struct drm_i915_private 
*dev_priv, u32 reg)
return val;
 }
 
-static inline void
-i915_write(struct drm_i915_private *dev_priv, u32 reg, u64 val, int len)
-{
-   /* Trace down the write operation before the real write */
-   trace_i915_reg_rw('W', reg, val, len);
-   switch (len) {
-   case 8:
-   writeq(val, dev_priv-regs + reg);
-   break;
-   case 4:
-   writel(val, dev_priv-regs + reg);
-   break;
-   case 2:
-   writew(val, dev_priv-regs + reg);
-   break;
-   case 1:
-   writeb(val, dev_priv-regs + reg);
-   break;
-   }
-}
-
 /**
  * Reads a dword out of the status page, which is written to from the command
  * queue by automatic updates, MI_REPORT_HEAD, MI_STORE_DATA_INDEX, or
-- 
1.7.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: Don't save/restore hardware status page address register

[Zhenyu Wang]

It's cleaned before saving and re-initialized after restoring.
So don't need to save/restore it. And also new chip has new address
for hardware status page register, don't write to old address.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_suspend.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index 0521ecf..2f6c061 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -797,9 +797,6 @@ int i915_save_state(struct drm_device *dev)
 
pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
 
-   /* Hardware status page */
-   dev_priv-saveHWS = I915_READ(HWS_PGA);
-
i915_save_display(dev);
 
/* Interrupt state */
@@ -846,9 +843,6 @@ int i915_restore_state(struct drm_device *dev)
 
pci_write_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
 
-   /* Hardware status page */
-   I915_WRITE(HWS_PGA, dev_priv-saveHWS);
-
i915_restore_display(dev);
 
/* Interrupt state */
-- 
1.7.1

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

Re: [Intel-gfx] [PATCH] intel: Add AUB file dump support

[Zhenyu Wang]

On 2011.02.22 09:33:22 -0800, Eric Anholt wrote:
 While I originally hacked it up this way where libdrm intuits what kind
 of buffer it is from the name of the buffer, it's a bad way to design an
 interface.  We should really have a command that marks (an area) of a
 buffer object as being a particular AUB type, and Mesa would use that
 command to mark its buffers as appropriate.  Particularly since we're
 moving to streaming more of our state buffers into larger buffer
 objects.

ok, if our plan is to move into larger buffer, current method is just
hairy. Like I didn't hack up surface state and some others, coz it's 
twisted to convert current batch ending space usage into real bo for 
matching the name for trace block types.

 
 We also can't commit code to Mesa that just writes into some arbitrary
 file based on an environment variable -- keep in mind that our Mesa
 driver is loaded from the X Server which is running as root.

yeah, I wasn't aware of this, any comment for how to dump the file?

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel: Add AUB file dump support

[Zhenyu Wang]

On 2011.02.22 14:51:33 +0800, Xiang, Haihao wrote:
  oh, right, I see. You still need subtype as kernel.
  
  How about 'MEDIA_PROG'? Or what's the name for your current kernel?
 'MEDIA_PROG' is ok for me
 

New libdrm patch for aub dump attached. Please help to test.

Thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
From 804328390488f76c1bda02cdf0a4081e55657ff9 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang zhen...@linux.intel.com
Date: Tue, 22 Feb 2011 14:53:42 +0800
Subject: [PATCH] intel: Add AUB file dump support

This adds AUB file dump support to generate execution
trace for internal GPU simulator.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 intel/Makefile.am|3 +-
 intel/intel_bufmgr.h |   40 +
 intel/intel_bufmgr_gem.c |  397 ++
 3 files changed, 439 insertions(+), 1 deletions(-)

diff --git a/intel/Makefile.am b/intel/Makefile.am
index 1ae92f8..398cd2f 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -41,7 +41,8 @@ libdrm_intel_la_SOURCES = \
 	intel_bufmgr_gem.c \
 	intel_chipset.h \
 	mm.c \
-	mm.h
+	mm.h \
+	intel_aub.h
 
 libdrm_intelincludedir = ${includedir}/libdrm
 libdrm_intelinclude_HEADERS = intel_bufmgr.h
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index daa18b4..4eee7ac 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -35,6 +35,7 @@
 #define INTEL_BUFMGR_H
 
 #include stdint.h
+#include stdio.h
 
 struct drm_clip_rect;
 
@@ -83,6 +84,41 @@ struct _drm_intel_bo {
 	int handle;
 };
 
+enum drm_intel_aub_bmp_format {
+	AUB_DUMP_BMP_LEGACY,
+	AUB_DUMP_BMP_8BIT,
+	AUB_DUMP_BMP_ARGB_0555,
+	AUB_DUMP_BMP_ARGB_0565,
+	AUB_DUMP_BMP_ARGB_,
+	AUB_DUMP_BMP_ARGB_1555,
+	AUB_DUMP_BMP_ARGB_0888,
+	AUB_DUMP_BMP_ARGB_,
+	AUB_DUMP_BMP_YCRCB_SWAPY,
+	AUB_DUMP_BMP_YCRCB_NORMAL,
+	AUB_DUMP_BMP_YCRCB_SWAPUV,
+	AUB_DUMP_BMP_YCRCB_SWAPUVY,
+	AUB_DUMP_BMP_ABGR_,
+};
+
+/*
+ * The information needed by aub DUMP_BMP command
+ *
+ * NOTE: this is for aub dump
+ */
+struct drm_intel_aub_surface_bmp {
+	uint16_t x_offset;
+	uint16_t y_offset;
+	uint16_t pitch;
+	uint8_t bits_per_pixel;
+	uint8_t format;
+	uint16_t width;
+	uint16_t height;
+	uint32_t tiling_walk_y:1;
+	uint32_t tiling:1;
+	uint32_t pad:30;
+};
+
+
 #define BO_ALLOC_FOR_RENDER (10)
 
 drm_intel_bo *drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
@@ -150,6 +186,10 @@ int drm_intel_gem_bo_unmap_gtt(drm_intel_bo *bo);
 void drm_intel_gem_bo_start_gtt_access(drm_intel_bo *bo, int write_enable);
 
 int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr *bufmgr, int crtc_id);
+void drm_intel_bufmgr_gem_set_aubfile(drm_intel_bufmgr *bufmgr, FILE *file);
+void drm_intel_bufmgr_gem_stop_aubfile(drm_intel_bufmgr *bufmgr);
+int drm_intel_gem_aub_dump_bmp(drm_intel_bufmgr *bufmgr, drm_intel_bo *bo,
+			   struct drm_intel_aub_surface_bmp *bmp);
 
 /* drm_intel_bufmgr_fake.c */
 drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3cdffce..53392c9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -57,6 +57,7 @@
 #include intel_bufmgr.h
 #include intel_bufmgr_priv.h
 #include intel_chipset.h
+#include intel_aub.h
 #include string.h
 
 #include i915_drm.h
@@ -75,6 +76,12 @@ struct drm_intel_gem_bo_bucket {
 	unsigned long size;
 };
 
+struct drm_intel_aub_bmp {
+	drm_intel_bo *bo;
+	struct drm_intel_aub_surface_bmp bmp;
+	struct drm_intel_aub_bmp *next;
+};
+
 typedef struct _drm_intel_bufmgr_gem {
 	drm_intel_bufmgr bufmgr;
 
@@ -106,6 +113,10 @@ typedef struct _drm_intel_bufmgr_gem {
 	unsigned int has_relaxed_fencing : 1;
 	unsigned int bo_reuse : 1;
 	char fenced_relocs;
+
+	FILE *aub_file;
+	uint32_t aub_offset;
+	struct drm_intel_aub_bmp *aub_bmp;
 } drm_intel_bufmgr_gem;
 
 #define DRM_INTEL_RELOC_FENCE (10)
@@ -195,8 +206,392 @@ struct _drm_intel_bo_gem {
 	 * relocations.
 	 */
 	int reloc_tree_fences;
+
+	uint32_t aub_offset;
 };
 
+/* AUB trace dump support */
+
+static void
+aub_out(drm_intel_bufmgr_gem *bufmgr_gem, uint32_t data)
+{
+	fwrite(data, 1, 4, bufmgr_gem-aub_file);
+}
+
+static void
+aub_out_data(drm_intel_bufmgr_gem *bufmgr_gem, void *data, size_t size)
+{
+	fwrite(data, 1, size, bufmgr_gem-aub_file);
+}
+
+static void
+aub_write_bo_data(drm_intel_bo *bo, uint32_t offset, uint32_t size)
+{
+	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
+	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+	uint32_t *data;
+	unsigned int i;
+
+	data = malloc(bo-size);
+	drm_intel_bo_get_subdata(bo, offset, size, data);
+
+	/* Easy mode: write out bo with no relocations */
+	if (!bo_gem-reloc_count) {
+		aub_out_data(bufmgr_gem, data, size);
+		free(data);
+		return;
+	}
+
+	/* Otherwise, handle the relocations while writing. */
+	for (i = 0; i  size / 4; i++) {
+		int r;
+		for (r = 0; r  bo_gem-reloc_count; r++) {
+			struct

Re: [Intel-gfx] [intel-gpu-tools] intel_audio_dump problem with GEN5 devices

[Zhenyu Wang]

On 2011.02.15 17:41:20 +, Diego Celix wrote:
 Hi!,
 
 When I run the intel_audio_dump tool with my laptop (Core i5 Intel HD
 Graphics) seems that it is not correctly fetching the data.
 
 This is a piece of the source, in which the HAS_PCH_SPLIT macro is
 called (Line 1197, intel_audio_dump.c)
 
 if (HAS_PCH_SPLIT(devid) || getenv(HAS_PCH_SPLIT)) {
 intel_check_pch();
 dump_cpt();
 } else if (IS_GEN5(devid))
 dump_ironlake();
 else
 dump_eaglelake();
 
 
 In the HAS_PCH_SPLIT macro is also checked if the device is GEN5, so
 in my case, I will never reach the second statement.
 I've checked the output of the dump_ironlake() function, and seems to be ok.
 
 As in other files the HAS_PCH_SPLIT macro is used, I'm not pretty sure
 about the best solution here.
 I simply checked if it is a GEN6 device instead of using the
 HAS_PCH_SPLIT macro.
 
 I have attached the change I made.
 

cc Fengguang.

dump_ironlake() should be for Ibexpeak PCH with Ironlake, which is
your case I think. Looks needing to fix by check pch type properly.


 From 11ecef0c415e20c1b377bf9bb93dcc4b1ab283c0 Mon Sep 17 00:00:00 2001
 From: Diego Celix dce...@gmail.com
 Date: Tue, 15 Feb 2011 17:17:41 +
 Subject: [PATCH] intel_audio_dump: Removed repeated check for GEN5
 
 In main(), there is a repeated check for a GEN5 device.
 The first one is inside the HAS_PCH_SPLIT macro wich prevents reaching the
 correct option.
 ---
  tools/intel_audio_dump.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
 index ef81b6a..c3204a2 100644
 --- a/tools/intel_audio_dump.c
 +++ b/tools/intel_audio_dump.c
 @@ -1194,7 +1194,7 @@ int main(int argc, char **argv)
   else
   intel_get_mmio(pci_dev);
  
 - if (HAS_PCH_SPLIT(devid) || getenv(HAS_PCH_SPLIT)) {
 + if (IS_GEN6(devid) || getenv(HAS_PCH_SPLIT)) {
   intel_check_pch();
   dump_cpt();
   } else if (IS_GEN5(devid))
 -- 
 1.7.3.4
 

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


-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] AUB file dump support patches

[Zhenyu Wang]

AUB file is the input data for internal GenX GPU simulator,
which has been proved really helpful when debugging for new
GenX architecture. AUB file itself actually contains different
kinds of trace blocks for GPU execution, e.g batch/ring buffer,
surface states, pipeline FF states, etc.

This series contain patches again libdrm and mesa to add AUB
file dump support. Thanks to Eric and Yuanhan who did most of
the hard work.

First one is for libdrm, which has new API definition for enable
aub file dump, and BMP dump for required surface. Note that we just
use a fake GTT space in AUB dump, which is not necessarily equal
to real GTT address.

Following ones are for mesa, which should be simple enough.

After applying these patches, do 'export INTEL_DEBUG=aub'.
'intel.aub' file will be generated when you run some 3D test.
How to use it? For example,

AubList intel.aub : generate intel.lst which 3D state info and
ring/batch commands

AubLoad intel.aub -device sbrD0 : start fulsim to run the aub as
  Sandybridge D0.

Please help to review.

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

[Intel-gfx] [PATCH] intel: Add AUB file dump support

[Zhenyu Wang]

This adds AUB file dump support to generate execution
trace for internal GPU simulator.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 intel/Makefile.am|3 +-
 intel/intel_bufmgr.h |   38 +
 intel/intel_bufmgr_gem.c |  402 ++
 3 files changed, 442 insertions(+), 1 deletions(-)

diff --git a/intel/Makefile.am b/intel/Makefile.am
index 1ae92f8..398cd2f 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -41,7 +41,8 @@ libdrm_intel_la_SOURCES = \
intel_bufmgr_gem.c \
intel_chipset.h \
mm.c \
-   mm.h
+   mm.h \
+   intel_aub.h
 
 libdrm_intelincludedir = ${includedir}/libdrm
 libdrm_intelinclude_HEADERS = intel_bufmgr.h
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index daa18b4..bb4158a 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -35,6 +35,7 @@
 #define INTEL_BUFMGR_H
 
 #include stdint.h
+#include stdio.h
 
 struct drm_clip_rect;
 
@@ -83,6 +84,39 @@ struct _drm_intel_bo {
int handle;
 };
 
+enum drm_intel_aub_bmp_format {
+   AUB_DUMP_BMP_LEGACY,
+   AUB_DUMP_BMP_8BIT,
+   AUB_DUMP_BMP_ARGB_0555,
+   AUB_DUMP_BMP_ARGB_0565,
+   AUB_DUMP_BMP_ARGB_,
+   AUB_DUMP_BMP_ARGB_1555,
+   AUB_DUMP_BMP_ARGB_0888,
+   AUB_DUMP_BMP_ARGB_,
+   AUB_DUMP_BMP_YCRCB_SWAPY,
+   AUB_DUMP_BMP_YCRCB_NORMAL,
+   AUB_DUMP_BMP_YCRCB_SWAPUV,
+   AUB_DUMP_BMP_YCRCB_SWAPUVY,
+   AUB_DUMP_BMP_ABGR_,
+};
+
+/*
+ * surface info needed by aub DUMP_BMP block
+ */
+struct drm_intel_aub_surface_bmp {
+   uint16_t x_offset;
+   uint16_t y_offset;
+   uint16_t pitch;
+   uint8_t bits_per_pixel;
+   uint8_t format;
+   uint16_t width;
+   uint16_t height;
+   uint32_t tiling_walk_y:1;
+   uint32_t tiling:1;
+   uint32_t pad:30;
+};
+
+
 #define BO_ALLOC_FOR_RENDER (10)
 
 drm_intel_bo *drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
@@ -150,6 +184,10 @@ int drm_intel_gem_bo_unmap_gtt(drm_intel_bo *bo);
 void drm_intel_gem_bo_start_gtt_access(drm_intel_bo *bo, int write_enable);
 
 int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr *bufmgr, int crtc_id);
+void drm_intel_bufmgr_gem_set_aubfile(drm_intel_bufmgr *bufmgr, FILE *file);
+void drm_intel_bufmgr_gem_stop_aubfile(drm_intel_bufmgr *bufmgr);
+int drm_intel_gem_aub_dump_bmp(drm_intel_bufmgr *bufmgr, drm_intel_bo *bo,
+  unsigned int offset, struct 
drm_intel_aub_surface_bmp *bmp);
 
 /* drm_intel_bufmgr_fake.c */
 drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3cdffce..654bc31 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -57,6 +57,7 @@
 #include intel_bufmgr.h
 #include intel_bufmgr_priv.h
 #include intel_chipset.h
+#include intel_aub.h
 #include string.h
 
 #include i915_drm.h
@@ -75,6 +76,13 @@ struct drm_intel_gem_bo_bucket {
unsigned long size;
 };
 
+struct drm_intel_aub_bmp {
+   drm_intel_bo *bo; /* surface bo */
+   unsigned int offset;
+   struct drm_intel_aub_surface_bmp bmp;
+   struct drm_intel_aub_bmp *next;
+};
+
 typedef struct _drm_intel_bufmgr_gem {
drm_intel_bufmgr bufmgr;
 
@@ -106,6 +114,10 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_relaxed_fencing : 1;
unsigned int bo_reuse : 1;
char fenced_relocs;
+
+   FILE *aub_file;
+   uint32_t aub_offset;
+   struct drm_intel_aub_bmp *aub_bmp;
 } drm_intel_bufmgr_gem;
 
 #define DRM_INTEL_RELOC_FENCE (10)
@@ -195,8 +207,396 @@ struct _drm_intel_bo_gem {
 * relocations.
 */
int reloc_tree_fences;
+
+   uint32_t aub_offset;
 };
 
+/* AUB trace dump support */
+
+static void
+aub_out(drm_intel_bufmgr_gem *bufmgr_gem, uint32_t data)
+{
+   fwrite(data, 1, 4, bufmgr_gem-aub_file);
+}
+
+static void
+aub_out_data(drm_intel_bufmgr_gem *bufmgr_gem, void *data, size_t size)
+{
+   fwrite(data, 1, size, bufmgr_gem-aub_file);
+}
+
+static void
+aub_write_bo_data(drm_intel_bo *bo, uint32_t offset, uint32_t size)
+{
+   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
+   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+   uint32_t *data;
+   unsigned int i;
+
+   data = malloc(bo-size);
+   drm_intel_bo_get_subdata(bo, offset, size, data);
+
+   /* Easy mode: write out bo with no relocations */
+   if (!bo_gem-reloc_count) {
+   aub_out_data(bufmgr_gem, data, size);
+   free(data);
+   return;
+   }
+
+   /* Otherwise, handle the relocations while writing. */
+   for (i = 0; i  size / 4; i++) {
+   int r;
+   for (r = 0; r  bo_gem-reloc_count; r++) {
+   struct drm_i915_gem_relocation_entry *reloc;
+   drm_intel_reloc_target *info

[Intel-gfx] [PATCH 1/3] intel: new debug option for aub file dump

[Zhenyu Wang]

New INTEL_DEBUG option to enable aub file dump with intel drm.
---
 src/mesa/drivers/dri/intel/intel_context.c |   10 ++
 src/mesa/drivers/dri/intel/intel_context.h |2 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
b/src/mesa/drivers/dri/intel/intel_context.c
index 65c4148..45e9915 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -522,6 +522,7 @@ static const struct dri_debug_control debug_control[] = {
{ urb,   DEBUG_URB },
{ vs,DEBUG_VS },
{ clip,  DEBUG_CLIP },
+   { aub,   DEBUG_AUB },
{ NULL,0 }
 };
 
@@ -863,6 +864,15 @@ intelInitContext(struct intel_context *intel,
if (INTEL_DEBUG  DEBUG_BUFMGR)
   dri_bufmgr_set_debug(intel-bufmgr, GL_TRUE);
 
+   if (INTEL_DEBUG  DEBUG_AUB) {
+   fprintf(stderr, Enable Aub file dump.\n);
+   intel-aub_file = fopen(intel.aub, w);
+   if (intel-aub_file)
+  drm_intel_bufmgr_gem_set_aubfile(intel-bufmgr, intel-aub_file);
+   else
+  fprintf(stderr, Fail to create aub file.\n);
+   }
+
intel-batch = intel_batchbuffer_alloc(intel);
 
intel_fbo_init(intel);
diff --git a/src/mesa/drivers/dri/intel/intel_context.h 
b/src/mesa/drivers/dri/intel/intel_context.h
index 134e07e..c3c83e4 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -267,6 +267,7 @@ struct intel_context
 * Configuration cache
 */
driOptionCache optionCache;
+   FILE *aub_file;
 };
 
 extern char *__progname;
@@ -360,6 +361,7 @@ extern int INTEL_DEBUG;
 #define DEBUG_URB   0x100
 #define DEBUG_VS0x200
 #define DEBUG_CLIP  0x800
+#define DEBUG_AUB  0x1000
 
 #define DBG(...) do {  \
if (unlikely(INTEL_DEBUG  FILE_DEBUG_FLAG))\
-- 
1.7.2.3

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

Re: [Intel-gfx] [PATCH] drm/i915: skip FDI PCH enabling for DP_A

[Zhenyu Wang]

On 2011.01.05 10:31:48 -0800, Jesse Barnes wrote:
 eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
 problems.  So avoid FDI training and PCH PLL enabling in that case.
 

Right, I think that's what I did during early eDP enabling.
Yuanhan, please test this on sandybridge eDP panel.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_display.c |   97 
 +-
  1 files changed, 60 insertions(+), 37 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 395acb8..2441a00 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -2616,49 +2616,21 @@ static bool intel_crtc_driving_pch(struct drm_crtc 
 *crtc)
   return true;
  }
  
 -static void ironlake_crtc_enable(struct drm_crtc *crtc)
 +/*
 + * Enable PCH resources required for PCH ports:
 + *   - PCH PLLs
 + *   - FDI training  RX/TX
 + *   - update transcoder timings
 + *   - DP transcoding bits
 + *   - transcoder
 + */
 +static void ironlake_pch_enable(struct drm_crtc *crtc)
  {
   struct drm_device *dev = crtc-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
   int pipe = intel_crtc-pipe;
 - int plane = intel_crtc-plane;
   u32 reg, temp;
 - bool is_pch_port;
 -
 - if (intel_crtc-active)
 - return;
 -
 - intel_crtc-active = true;
 - intel_update_watermarks(dev);
 -
 - if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
 - temp = I915_READ(PCH_LVDS);
 - if ((temp  LVDS_PORT_EN) == 0)
 - I915_WRITE(PCH_LVDS, temp | LVDS_PORT_EN);
 - }
 -
 - ironlake_fdi_enable(crtc);
 -
 - /* Enable panel fitting for LVDS */
 - if (dev_priv-pch_pf_size 
 - (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) || HAS_eDP)) {
 - /* Force use of hard-coded filter coefficients
 -  * as some pre-programmed values are broken,
 -  * e.g. x201.
 -  */
 - I915_WRITE(pipe ? PFB_CTL_1 : PFA_CTL_1,
 -PF_ENABLE | PF_FILTER_MED_3x3);
 - I915_WRITE(pipe ? PFB_WIN_POS : PFA_WIN_POS,
 -dev_priv-pch_pf_pos);
 - I915_WRITE(pipe ? PFB_WIN_SZ : PFA_WIN_SZ,
 -dev_priv-pch_pf_size);
 - }
 -
 - is_pch_port = intel_crtc_driving_pch(crtc);
 -
 - intel_enable_pipe(dev_priv, pipe, is_pch_port);
 - intel_enable_plane(dev_priv, plane, pipe);
  
   /* For PCH output, training FDI link */
   if (IS_GEN6(dev))
 @@ -2727,6 +2699,57 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
   }
  
   intel_enable_transcoder(dev_priv, pipe);
 +}
 +
 +static void ironlake_crtc_enable(struct drm_crtc *crtc)
 +{
 + struct drm_device *dev = crtc-dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 + int pipe = intel_crtc-pipe;
 + int plane = intel_crtc-plane;
 + u32 temp;
 + bool is_pch_port;
 +
 + if (intel_crtc-active)
 + return;
 +
 + intel_crtc-active = true;
 + intel_update_watermarks(dev);
 +
 + if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
 + temp = I915_READ(PCH_LVDS);
 + if ((temp  LVDS_PORT_EN) == 0)
 + I915_WRITE(PCH_LVDS, temp | LVDS_PORT_EN);
 + }
 +
 + is_pch_port = intel_crtc_driving_pch(crtc);
 +
 + if (is_pch_port)
 + ironlake_fdi_enable(crtc);
 + else
 + ironlake_fdi_disable(crtc);
 +
 + /* Enable panel fitting for LVDS */
 + if (dev_priv-pch_pf_size 
 + (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) || HAS_eDP)) {
 + /* Force use of hard-coded filter coefficients
 +  * as some pre-programmed values are broken,
 +  * e.g. x201.
 +  */
 + I915_WRITE(pipe ? PFB_CTL_1 : PFA_CTL_1,
 +PF_ENABLE | PF_FILTER_MED_3x3);
 + I915_WRITE(pipe ? PFB_WIN_POS : PFA_WIN_POS,
 +dev_priv-pch_pf_pos);
 + I915_WRITE(pipe ? PFB_WIN_SZ : PFA_WIN_SZ,
 +dev_priv-pch_pf_size);
 + }
 +
 + intel_enable_pipe(dev_priv, pipe, is_pch_port);
 + intel_enable_plane(dev_priv, plane, pipe);
 +
 + if (is_pch_port)
 + ironlake_pch_enable(crtc);
  
   intel_crtc_load_lut(crtc);
   intel_update_fbc(dev);
 -- 
 1.7.0.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature

Re: [Intel-gfx] pipe control notify removed?

[Zhenyu Wang]

On 2010.12.15 10:05:01 +, Chris Wilson wrote:
 On Wed, 15 Dec 2010 11:14:53 +0800, Zhenyu Wang zhen...@linux.intel.com 
 wrote:
  
  Chris, just notice you removed pipe control notify entirely on -next,
  that seems wrong to me. In Ironlake time, we've seen interrupt stall issue
  with user interrupt, and be warned user interrupt is deprecated, so we moved
  on to use pipe control notify, although there's a workaround later covered
  that's required on Ironlake. But it's stable finally. And for sandybridge, 
  there's no such workaround needed.
 
 The answer to this is to make sure that such details are kept in the
 code comments, especially if such information is not readily available
 in the documentation.

yeah, also our spec might not have been updated as well...I'll send the BUN
doc for that to you.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: add 'reset' parameter

[Zhenyu Wang]

Useful for debugging hang bug that not require GPU auto reset,
to grab INSTDONE bits and make aub dump life easy.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.c |3 +++
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/i915_irq.c |2 +-
 3 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5f20cd9..d052807 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,9 @@ module_param_named(powersave, i915_powersave, int, 0600);
 unsigned int i915_lvds_downclock = 0;
 module_param_named(lvds_downclock, i915_lvds_downclock, int, 0400);
 
+unsigned int i915_do_reset = 1;
+module_param_named(reset, i915_do_reset, int, 0600);
+
 static struct drm_driver driver;
 extern int intel_agp_enabled;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30780f2..9126282 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -950,6 +950,7 @@ extern int i915_max_ioctl;
 extern unsigned int i915_fbpercrtc;
 extern unsigned int i915_powersave;
 extern unsigned int i915_lvds_downclock;
+extern unsigned int i915_do_reset;
 
 extern int i915_suspend(struct drm_device *dev, pm_message_t state);
 extern int i915_resume(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 02e4dd8..6058b46 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -414,7 +414,7 @@ static void i915_error_work_func(struct work_struct *work)
 
kobject_uevent_env(dev-primary-kdev.kobj, KOBJ_CHANGE, error_event);
 
-   if (atomic_read(dev_priv-mm.wedged)) {
+   if (atomic_read(dev_priv-mm.wedged)  i915_do_reset) {
DRM_DEBUG_DRIVER(resetting chip\n);
kobject_uevent_env(dev-primary-kdev.kobj, KOBJ_CHANGE, 
reset_event);
if (!i915_reset(dev, GRDOM_RENDER)) {
-- 
1.7.1

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

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

[Zhenyu Wang]

On 2010.12.14 21:47:45 +, Chris Wilson wrote:
 On Tue, 14 Dec 2010 20:59:09 +, david may david.ma...@ntlworld.com 
 wrote:
  Hello Eric,
  
  Tuesday, December 14, 2010, 5:58:58 PM, you wrote:
  
   Why don't we just keep all of our BOs LLC cached?  This was supposed to
   be a big win of the new chipset, as it means we don't need to clflush.
  
  Ohh,the implication here is that people are/have been writing the
  code,But Not bothering Actually benching/Profiling it to see if it actually 
  is faster and
   better throughput than before, that seems wrong, especially given sandy 
  bridge is
   supposed to be better, i Do Hope you are/will be testing/benching/Profiling
to see if it/all SB Code is actually  a big win one way or the other 
  before passing for
   release.
 
 No, the default on SNB was changed back to uncached in order to fix some
 coherency issues in the short term. Correctness first.
 

yeah, it's short term, coherent issue would be fixed by GFDT bit.
I was done that partly before, but seems fallback to old behavior
is the easiest way to fix current correction issue.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

[Zhenyu Wang]

On 2010.12.14 19:13:22 +0100, Daniel Vetter wrote:
 On Tue, Dec 14, 2010 at 12:55:59PM +0800, Zhenyu Wang wrote:
  It appears Sandybridge PIPE_CONTROL write out buffer need
  to be set as cached, currently LLC cached, in order to read
  back correct counter. Otherwise I can always be possible to
  get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write.
  
  So below patches try to add new flag during bo create with
  cacheable type, to be sure that GTT entry's cache bits would
  be setup for that.
  
  This fixes occlusion query piglit test and mesa demos on my
  sandybridge. Note that below patches don't include necessary
  component version check changes.
 
 General comment on the introduction of a new flag for bo creation:
 
 If I'm not mistaken, all the query objects are relocated as read_domain =
 I915_GEM_DOMAIN_INSTRUCTION, write_domain = I915_GEM_DOMAIN_INSTRUCTION,
 i.e. we already have an api for userspace to tell us that a PIPE_CONTROL
 command will write to this buffer. Why can't we use that one and remap
 the bo with the correct caching flags on execbuf time (on gen6)?

True, that's the other way I thought about.

 
 I simply fear that introducing a hacky ad-hoc abi complicates matters when
 we introduce real llc/mlc caching for general stuff. Especially since
 there's seems to be an existing thing already available. I'm still
 fighting the fallout from the incoherent multiple rings introduction and I
 just don't want to repeat such a goof-up.
 

yeah, it's quick hack. I would take the way to fix caching instead.

thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] pipe control notify removed?

[Zhenyu Wang]

Chris, just notice you removed pipe control notify entirely on -next,
that seems wrong to me. In Ironlake time, we've seen interrupt stall issue
with user interrupt, and be warned user interrupt is deprecated, so we moved
on to use pipe control notify, although there's a workaround later covered
that's required on Ironlake. But it's stable finally. And for sandybridge, 
there's no such workaround needed.

btw, could you also send mails for changes on -next? It'll be easy to be
notified.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ignore cached memory flag in i965_write_entry()?

[Zhenyu Wang]

Looks from a6963596a13e62f8e65b1cf3403a330ff2db407c, setting
GTT entry on i965-ish totally ignored cached memory flag?
That might break r/w consistent for pages like hw status.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Add cached bo create interface

[Zhenyu Wang]

Some BO is required to have cached attribute in GTT, e.g PIPE_CONTROL
store DW buffer used for occlusion query function. This one adds new
flags for that within bo create ioctl.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_dma.c |3 +++
 drivers/gpu/drm/i915/i915_gem.c |4 
 include/drm/i915_drm.h  |5 -
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e9fb895..df5a248 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -778,6 +778,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_COHERENT_RINGS:
value = 1;
break;
+   case I915_PARAM_HAS_CREATE_CACHED:
+   value = 1;
+   break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
 param-param);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 27fa2a1..8bc5d05 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -216,6 +216,10 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
return ret;
}
 
+   /* Setup required CPU cached bit for bo, e.g query obj */
+   if (args-flags == DRM_I915_GEM_CREATE_CACHED)
+   obj-agp_type = AGP_USER_CACHED_MEMORY;
+
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference(obj-base);
trace_i915_gem_object_create(obj);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index a2776e2..b34db99 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -289,6 +289,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_BLT  11
 #define I915_PARAM_HAS_RELAXED_FENCING  12
 #define I915_PARAM_HAS_COHERENT_RINGS   13
+#define I915_PARAM_HAS_CREATE_CACHED14
 
 typedef struct drm_i915_getparam {
int param;
@@ -370,6 +371,8 @@ struct drm_i915_gem_init {
__u64 gtt_end;
 };
 
+#define DRM_I915_GEM_CREATE_CACHED 1
+
 struct drm_i915_gem_create {
/**
 * Requested size for the object.
@@ -383,7 +386,7 @@ struct drm_i915_gem_create {
 * Object handles are nonzero.
 */
__u32 handle;
-   __u32 pad;
+   __u32 flags;
 };
 
 struct drm_i915_gem_pread {
-- 
1.7.1

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

[Intel-gfx] patches for occlusion query fix on sandybridge

[Zhenyu Wang]

It appears Sandybridge PIPE_CONTROL write out buffer need
to be set as cached, currently LLC cached, in order to read
back correct counter. Otherwise I can always be possible to
get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write.

So below patches try to add new flag during bo create with
cacheable type, to be sure that GTT entry's cache bits would
be setup for that.

This fixes occlusion query piglit test and mesa demos on my
sandybridge. Note that below patches don't include necessary
component version check changes.

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

[Intel-gfx] [PATCH] i965: alloc cached bo for query object on Sandybridge

[Zhenyu Wang]

Use new interface for cached bo create for query object on Sandybridge,
which is required for PIPE_CONTROL store buffer to be CPU cacheable.
---
 src/mesa/drivers/dri/i965/brw_queryobj.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index f28f286..8c639de 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -231,7 +231,11 @@ brw_prepare_query_begin(struct brw_context *brw)
   drm_intel_bo_unreference(brw-query.bo);
   brw-query.bo = NULL;
 
-  brw-query.bo = drm_intel_bo_alloc(intel-bufmgr, query, 4096, 1);
+  /* Sandybridge requires PIPE_CONTROL write DW to be LLC cached. */
+  if (intel-gen = 6)
+ brw-query.bo = drm_intel_gem_bo_alloc_cached(intel-bufmgr, query, 
4096, 1);
+  else
+ brw-query.bo = drm_intel_bo_alloc(intel-bufmgr, query, 4096, 1);
   brw-query.index = 0;
}
 
-- 
1.7.1

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

Re: [Intel-gfx] ignore cached memory flag in i965_write_entry()?

[Zhenyu Wang]

On 2010.12.14 11:03:53 +0800, Zhenyu Wang wrote:
 
 Looks from a6963596a13e62f8e65b1cf3403a330ff2db407c, setting
 GTT entry on i965-ish totally ignored cached memory flag?
 That might break r/w consistent for pages like hw status.
 

This should recover that.

From ca8cca3ffe03353c4bacdb30d77ff9c10ff0e4e0 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang zhen...@linux.intel.com
Date: Tue, 14 Dec 2010 11:17:32 +0800
Subject: [PATCH] agp/intel: Fix missed cached memory flags setting in GTT entry 
write

This fixes regression from a6963596a13e62f8e65b1cf3403a330ff2db407c,
that missed to set cached memory type in GTT entry.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/char/agp/intel-gtt.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 326ca2e..c7fe85d 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1138,9 +1138,15 @@ static void i9xx_chipset_flush(void)
 static void i965_write_entry(dma_addr_t addr, unsigned int entry,
 unsigned int flags)
 {
+   int pte_flags = I810_PTE_VALID;
+
/* Shift high bits down */
addr |= (addr  28)  0xf0;
-   writel(addr | I810_PTE_VALID, intel_private.gtt + entry);
+
+   if (flags == AGP_USER_CACHED_MEMORY)
+   pte_flags |= I830_PTE_SYSTEM_CACHED;
+
+   writel(addr | pte_flags, intel_private.gtt + entry);
 }
 
 static bool gen6_check_flags(unsigned int flags)
-- 
1.7.1

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] piglit regression on sandybridge

[Zhenyu Wang]

Eric,

Looks the culprit for recent piglit regression on sandybridge
that caused hang is bisected to

commit 9effc1adf1e7ba57fb3b10909762b76c1ae12f61
Author: Eric Anholt e...@anholt.net
Date:   Mon Oct 11 16:02:08 2010 -0700

i965: re-enable gen6 IF statements in the fragment shader.

IF statements were getting flattened while they were broken.  With
Zhenyu's last fix for ENDIF's type, everything appears to have lined
up to actually work.

This regresses two tests:
glsl1-! (not) operator (1, fail)
glsl1-! (not) operator (1, pass)

but fixes tests that couldn't work before because the IFs couldn't
be flattened:
glsl-fs-discard-01
occlusion-query-discard

(and, naturally, this should be a performance improvement for apps
 that actually use IF statements to avoid executing a bunch of code).

What may go wrong with this? QA is stalled on this to continue on
running piglit..

thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] piglit regression on sandybridge

[Zhenyu Wang]

On 2010.11.29 11:02:26 -0800, Ian Romanick wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 11/29/2010 12:52 AM, Zhenyu Wang wrote:
 
  Looks the culprit for recent piglit regression on sandybridge
  that caused hang is bisected to
 
 Could you be more specific about the regression?  The commit message
 mentions two tests that regress with this change.  Are there other
 regressions?  If yes, what are they?
 

Sorry I missed that point. It's piglit shaders/glsl-fs-convolution-2
that caused hang now.

  commit 9effc1adf1e7ba57fb3b10909762b76c1ae12f61
  Author: Eric Anholt e...@anholt.net
  Date:   Mon Oct 11 16:02:08 2010 -0700
  
  i965: re-enable gen6 IF statements in the fragment shader.
  
  IF statements were getting flattened while they were broken.  With
  Zhenyu's last fix for ENDIF's type, everything appears to have lined
  up to actually work.
  
  This regresses two tests:
  glsl1-! (not) operator (1, fail)
  glsl1-! (not) operator (1, pass)
  
  but fixes tests that couldn't work before because the IFs couldn't
  be flattened:
  glsl-fs-discard-01
  occlusion-query-discard
  
  (and, naturally, this should be a performance improvement for apps
   that actually use IF statements to avoid executing a bunch of code).
  
  What may go wrong with this? QA is stalled on this to continue on
  running piglit..
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAkzz+L8ACgkQX1gOwKyEAw9OMwCgmWz6YYEkX0glsmf4wSngfi1x
 dFYAn0F0d5AzQJCxhlBHTjZb/U+CYkC4
 =Qt8Y
 -END PGP SIGNATURE-
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [bisected] commit 176f28eb breaks my Sandybridge

[Zhenyu Wang]

On 2010.11.04 16:52:51 -0700, Carl Worth wrote:
  Having the error there was to make sure people noticed and I
  could find out just how many SNB revisions failed. I presume you have a
  rev 8?
 
 Yes, rev 8 here.
 

FYI, rev 9 desktop sandybridge doesn't show this issue so far.
It just reads back correct values.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix KMS regression on Sandybridge/CPT

[Zhenyu Wang]

On 2010.11.04 13:50:24 +0800, Zhenyu Wang wrote:
 On 2010.11.04 02:23:46 +, Chris Wilson wrote:
  On Tue, 2 Nov 2010 14:24:22 +0800, Zhenyu Wang zhen...@linux.intel.com 
  wrote:
   I don't think transcoder bpc setting should matter, but sorry that I'm 
   short
   of time to track down which one extra read made the difference, my 
   sandybridge
   laptop normally refuse to boot on first time.. ;)
   
   The code operation is same as what we have in .36 kernel, so could you 
   restore 
   behavior back first?
  
  The original patch was unacceptable since it did more than it claimed to
  in its changelog. Just disabling the Ironlake workaround and restoring the
  FDI normal train on crtc disable is insufficient. I remain dubious that
  adding the POSTING_READs is sufficient without at least some explanation
  and some testing.
  
 
 Chris, I try to retest your changed version on drm-intel-staging.
 It looks things work fine now with that. ;)
 
 Sorry that I'm not quite sure why my last test failed...please pick that
 one to -fixes, so QA team could pick it up for validation. 
 
 Thanks.
 

oops, this was rejected, now with correct subscribed mail address to the list..

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix KMS regression on Sandybridge/CPT

[Zhenyu Wang]

On 2010.10.29 09:52:31 +0100, Chris Wilson wrote:
 On Fri, 29 Oct 2010 10:34:51 +0800, Zhenyu Wang zhen...@linux.intel.com 
 wrote:
  On 2010.10.28 10:50:04 +0100, Chris Wilson wrote:
   I've shrunk the patch to just the FDI portion, pushed to staging for
   review. 
  
  Current drm-intel-staging still fails unfortunately..
 
 I'm very interested to know which was the magic bit then. :)
 
 Did we lose the transcoder bpc setting? Is an extra READ masking a missing
 delay? Is the break-scanline-wait fouling gen6?

I don't think transcoder bpc setting should matter, but sorry that I'm short
of time to track down which one extra read made the difference, my sandybridge
laptop normally refuse to boot on first time.. ;)

The code operation is same as what we have in .36 kernel, so could you restore 
behavior back first?

thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] agp/intel: fix cache control for sandybridge

[Zhenyu Wang]

This is broken from 97ef1bdd0bc75bce7b2058e9c432b6c277dcf4d3.
Let's set the correct bit for LLC+MLC and LLC only.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/char/agp/intel-gtt.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 6b6760e..125cd0b 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1213,11 +1213,11 @@ static void gen6_write_entry(dma_addr_t addr, unsigned 
int entry,
if (type_mask == AGP_USER_UNCACHED_MEMORY)
pte_flags = GEN6_PTE_UNCACHED | I810_PTE_VALID;
else if (type_mask == AGP_USER_CACHED_MEMORY_LLC_MLC) {
-   pte_flags = GEN6_PTE_LLC | I810_PTE_VALID;
+   pte_flags = GEN6_PTE_LLC_MLC | I810_PTE_VALID;
if (gfdt)
pte_flags |= GEN6_PTE_GFDT;
} else { /* set 'normal'/'cached' to LLC by default */
-   pte_flags = GEN6_PTE_LLC_MLC | I810_PTE_VALID;
+   pte_flags = GEN6_PTE_LLC | I810_PTE_VALID;
if (gfdt)
pte_flags |= GEN6_PTE_GFDT;
}
-- 
1.7.1

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

[Intel-gfx] [PATCH 2/2] agp/intel: restore cache behavior on sandybridge

[Zhenyu Wang]

This restores cache behavior for default AGP_USER_MEMORY as
uncached, and leave default AGP_USER_CACHED_MEMORY as LLC only.
I've seen different cache behavior on one sandybridge desktop CPU vs.
another mobile CPU. Until we figure out how to detect the real cache
config, restore back to the original behavior now.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/char/agp/intel-gtt.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 125cd0b..9272c38 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1210,7 +1210,7 @@ static void gen6_write_entry(dma_addr_t addr, unsigned 
int entry,
unsigned int gfdt = flags  AGP_USER_CACHED_MEMORY_GFDT;
u32 pte_flags;
 
-   if (type_mask == AGP_USER_UNCACHED_MEMORY)
+   if (type_mask == AGP_USER_MEMORY)
pte_flags = GEN6_PTE_UNCACHED | I810_PTE_VALID;
else if (type_mask == AGP_USER_CACHED_MEMORY_LLC_MLC) {
pte_flags = GEN6_PTE_LLC_MLC | I810_PTE_VALID;
-- 
1.7.1

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

[Intel-gfx] [PATCH v2] drm/i915: set scanout buffer as uncached on Sandybridge

[Zhenyu Wang]

Display engine on Sandybridge is not coherent with LLC, so
try to always bind display buffer as uncached on Sandybridge.
Old AGP_USER_MEMORY is bound as uncached by default, as Sandybridge
buffer would try to live in LLC with CPU as possible, so it uses
new flag AGP_USER_UNCACHED_MEMORY for uncached binding.

This is based on review and comment from Chris Wilson.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/i915_gem.c  |   20 
 drivers/gpu/drm/i915/intel_display.c |   10 ++
 3 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c2c19b..5948e05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1025,6 +1025,7 @@ void i915_gem_object_unpin(struct drm_gem_object *obj);
 int i915_gem_object_unbind(struct drm_gem_object *obj);
 void i915_gem_release_mmap(struct drm_gem_object *obj);
 void i915_gem_lastclose(struct drm_device *dev);
+int i915_gem_object_enable_scanout(struct drm_gem_object *obj);
 
 /**
  * Returns true if seq1 is later than seq2.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8eb8453..78f6789 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4028,6 +4028,26 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
 }
 
 int
+i915_gem_object_enable_scanout(struct drm_gem_object *obj)
+{
+   struct drm_device *dev = obj-dev;
+   struct drm_i915_gem_object *obj_priv = to_intel_bo(obj);
+   int type = IS_GEN6(dev) ? AGP_USER_UNCACHED_MEMORY : AGP_USER_MEMORY;
+
+   if (obj_priv-agp_type == type)
+   return 0;
+
+   if (obj_priv-gtt_space) {
+   int ret = i915_gem_object_unbind(obj);
+   if (ret)
+   return ret;
+   }
+
+   obj_priv-agp_type = type;
+   return 0;
+}
+
+int
 i915_gem_object_pin(struct drm_gem_object *obj, uint32_t alignment)
 {
struct drm_device *dev = obj-dev;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 990f065..a413db6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1461,6 +1461,10 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
BUG();
}
 
+   ret = i915_gem_object_enable_scanout(obj);
+   if (ret)
+   return ret;
+
ret = i915_gem_object_pin(obj, alignment);
if (ret)
return ret;
@@ -5482,6 +5486,12 @@ intel_user_framebuffer_create(struct drm_device *dev,
if (!intel_fb)
return ERR_PTR(-ENOMEM);
 
+   ret = i915_gem_object_enable_scanout(obj);
+   if (ret) {
+   kfree(intel_fb);
+   return ERR_PTR(ret);
+   }
+
ret = intel_framebuffer_init(dev, intel_fb,
 mode_cmd, obj);
if (ret) {
-- 
1.7.1

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

[Intel-gfx] [PATCH] drm/i915: Fix KMS regression on Sandybridge/CPT

[Zhenyu Wang]

We should enable FDI normal training on Sandybridge/CPT system
as well. Also restore back some original register posting read
that got removed. LVDS/VGA/HDMI seems back to life but DP still
fails.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |   80 +++---
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5948e05..228c571 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1322,6 +1322,7 @@ static inline void i915_write(struct drm_i915_private 
*dev_priv, u32 reg,
 
 #define INTEL_PCH_TYPE(dev) (((struct drm_i915_private 
*)(dev)-dev_private)-pch_type)
 #define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
+#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
 
 #define PRIMARY_RINGBUFFER_SIZE (128*1024)
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a413db6..b6f977b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1685,6 +1685,37 @@ static void ironlake_set_pll_edp(struct drm_crtc *crtc, 
int clock)
udelay(500);
 }
 
+static void intel_fdi_normal_train(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   int pipe = intel_crtc-pipe;
+   u32 reg, temp;
+
+   /* enable normal train */
+   reg = FDI_TX_CTL(pipe);
+   temp = I915_READ(reg);
+   temp = ~FDI_LINK_TRAIN_NONE;
+   temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
+   I915_WRITE(reg, temp);
+
+   reg = FDI_RX_CTL(pipe);
+   temp = I915_READ(reg);
+   if (HAS_PCH_CPT(dev)) {
+   temp = ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
+   temp |= FDI_LINK_TRAIN_NORMAL_CPT;
+   } else {
+   temp = ~FDI_LINK_TRAIN_NONE;
+   temp |= FDI_LINK_TRAIN_NONE;
+   }
+   I915_WRITE(reg, temp | FDI_RX_ENHANCE_FRAME_ENABLE);
+
+   /* wait one idle pattern time */
+   POSTING_READ(reg);
+   udelay(1000);
+}
+
 /* The FDI link training functions for ILK/Ibexpeak. */
 static void ironlake_fdi_link_train(struct drm_crtc *crtc)
 {
@@ -1771,27 +1802,6 @@ static void ironlake_fdi_link_train(struct drm_crtc 
*crtc)
 
DRM_DEBUG_KMS(FDI train done\n);
 
-   /* enable normal train */
-   reg = FDI_TX_CTL(pipe);
-   temp = I915_READ(reg);
-   temp = ~FDI_LINK_TRAIN_NONE;
-   temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
-   I915_WRITE(reg, temp);
-
-   reg = FDI_RX_CTL(pipe);
-   temp = I915_READ(reg);
-   if (HAS_PCH_CPT(dev)) {
-   temp = ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
-   temp |= FDI_LINK_TRAIN_NORMAL_CPT;
-   } else {
-   temp = ~FDI_LINK_TRAIN_NONE;
-   temp |= FDI_LINK_TRAIN_NONE;
-   }
-   I915_WRITE(reg, temp | FDI_RX_ENHANCE_FRAME_ENABLE);
-
-   /* wait one idle pattern time */
-   POSTING_READ(reg);
-   udelay(1000);
 }
 
 static const int const snb_b_fdi_train_param [] = {
@@ -1980,7 +1990,7 @@ static void intel_clear_scanline_wait(struct drm_device 
*dev)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 tmp;
 
-   if (IS_GEN2(dev))
+   if (IS_GEN2(dev) || IS_GEN6(dev))
/* Can't break the hang on i8xx */
return;
 
@@ -2022,8 +2032,10 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
 
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
temp = I915_READ(PCH_LVDS);
-   if ((temp  LVDS_PORT_EN) == 0)
+   if ((temp  LVDS_PORT_EN) == 0) {
I915_WRITE(PCH_LVDS, temp | LVDS_PORT_EN);
+   POSTING_READ(PCH_LVDS);
+   }
}
 
ironlake_fdi_enable(crtc);
@@ -2083,6 +2095,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
else if (pipe == 1  (temp  TRANSB_DPLL_ENABLE) == 0)
temp |= (TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL);
I915_WRITE(PCH_DPLL_SEL, temp);
+   POSTING_READ(PCH_DPLL_SEL);
}
 
/* set transcoder timing */
@@ -2094,6 +2107,8 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
I915_WRITE(TRANS_VBLANK(pipe), I915_READ(VBLANK(pipe)));
I915_WRITE(TRANS_VSYNC(pipe),  I915_READ(VSYNC(pipe)));
 
+   intel_fdi_normal_train(crtc);
+
/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev) 
intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
@@ -2204,9 +2219,10 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
udelay(100);
 
/* Ironlake workaround, disable clock pointer

Re: [Intel-gfx] [PATCH] drm/i915: Fix KMS regression on Sandybridge/CPT

[Zhenyu Wang]

On 2010.10.28 10:50:04 +0100, Chris Wilson wrote:
 
 The POSTING_READs you added are no-ops since they are all followed by a
 read. The transconf should have the bpc in the register at this point or
 else we should have bugged much earlier. The break-exec-wait condition is
 still documented for gen6, augmented with an additional break-sempahore-wait
 and obviously per-ring, but this is unrelated to the changelog.
 
 I've shrunk the patch to just the FDI portion, pushed to staging for
 review. 

Current drm-intel-staging still fails unfortunately..

 Let's try to keep patches as minimal as possible and addressing
 a single issue. (I'm as guilty of violating that as anyone.) Mostly so
 that we have a clear history of why/how the code works (and I don't break
 it later).

yeah, will do that, thanks for remind.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: set scan-buffer as uncached on Sandybridge

[Zhenyu Wang]

Display engine on Sandybridge is not coherent with LLC, so
try to always bind display buffer as uncached on Sandybridge.
This fixed screen artifacts seen by using blit engine on Sandybridge.

Cc: stable team sta...@kernel.org
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |8 
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a98bea..5200ee3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -34,6 +34,7 @@
 #include intel_bios.h
 #include intel_ringbuffer.h
 #include linux/io-mapping.h
+#include linux/intel-gtt.h
 
 /* General customization:
  */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9792285..46d724f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1579,6 +1579,14 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
obj = intel_fb-obj;
obj_priv = to_intel_bo(obj);
 
+   /* 
+*  Set uncacheable for scan-out buffer on Sandybridge.
+*  Display engine is non-coherent with LLC, and read from
+*  main memory only. This ensures data is coherent with display.
+*/
+   if (IS_GEN6(dev))
+   obj_priv-agp_type = AGP_USER_UNCACHED_MEMORY;
+
mutex_lock(dev-struct_mutex);
ret = intel_pin_and_fence_fb_obj(dev, obj);
if (ret != 0) {
-- 
1.7.1

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

[Intel-gfx] [PATCH -next 2/2] drm/i915: Fix GPIO pin to register mapping

[Zhenyu Wang]

In i2c GPIO fallback, index 6 is reserved for nothing.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_i2c.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 2449a74..2be4f72 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -155,6 +155,7 @@ intel_gpio_create(struct drm_i915_private *dev_priv, u32 
pin)
GPIOC,
GPIOD,
GPIOE,
+   0,
GPIOF,
};
struct intel_gpio *gpio;
-- 
1.7.0.4

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

Re: [Intel-gfx] [PATCH -next 1/2] drm/i915: restore FDI link rate on sandybridge

[Zhenyu Wang]

On 2010.10.13 09:00:37 -0700, Jesse Barnes wrote:
 
 So this gets the display working again with current bits?
 

No, these two are the fixes coming out during my bisect, as
it looks we have multiple regression commits...

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] intel: new blitter ring support from Sandybridge

[Zhenyu Wang]

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 include/drm/i915_drm.h   |2 ++
 intel/intel_bufmgr_gem.c |   12 +---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 7594413..694fb24 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -276,6 +276,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_PAGEFLIPPING 8
 #define I915_PARAM_HAS_EXECBUF2  9
 #define I915_PARAM_HAS_BSD  10
+#define I915_PARAM_HAS_BLIT_SPLIT   11
 
 typedef struct drm_i915_getparam {
int param;
@@ -619,6 +620,7 @@ struct drm_i915_gem_execbuffer2 {
__u64 cliprects_ptr;
 #define I915_EXEC_RENDER (10)
 #define I915_EXEC_BSD(11)
+#define I915_EXEC_BLIT   (12)
__u64 flags;
__u64 rsvd1;
__u64 rsvd2;
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 60174e1..57229e9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1545,7 +1545,8 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used,
struct drm_i915_gem_execbuffer2 execbuf;
int ret, i;
 
-   if ((ring_flag != I915_EXEC_RENDER)  (ring_flag != I915_EXEC_BSD))
+   if ((ring_flag != I915_EXEC_RENDER)  (ring_flag != I915_EXEC_BSD) 
+   (ring_flag != I915_EXEC_BLIT))
return -EINVAL;
 
pthread_mutex_lock(bufmgr_gem-lock);
@@ -2054,7 +2055,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
struct drm_i915_gem_get_aperture aperture;
drm_i915_getparam_t gp;
int ret;
-   int exec2 = 0, has_bsd = 0;
+   int exec2 = 0, has_bsd = 0, blit_split = 0;
 
bufmgr_gem = calloc(1, sizeof(*bufmgr_gem));
if (bufmgr_gem == NULL)
@@ -2110,6 +2111,11 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
if (!ret)
has_bsd = 1;
 
+   gp.param = I915_PARAM_HAS_BLIT_SPLIT;
+   ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
+   if (!ret)
+   blit_split = *gp.value;
+
if (bufmgr_gem-gen  4) {
gp.param = I915_PARAM_NUM_FENCES_AVAIL;
gp.value = bufmgr_gem-available_fences;
@@ -2165,7 +2171,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
/* Use the new one if available */
if (exec2) {
bufmgr_gem-bufmgr.bo_exec = drm_intel_gem_bo_exec2;
-   if (has_bsd)
+   if (has_bsd || blit_split)
bufmgr_gem-bufmgr.bo_mrb_exec = 
drm_intel_gem_bo_mrb_exec2;
} else
bufmgr_gem-bufmgr.bo_exec = drm_intel_gem_bo_exec;
-- 
1.7.0.4

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

Re: [Intel-gfx] 2.6.36-rc5 i915 regression

[Zhenyu Wang]

On 2010.10.01 22:27:45 +0200, Seblu wrote:
 On Fri, Oct 1, 2010 at 3:22 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
  On Fri, 1 Oct 2010 12:55:56 + (UTC), Seblu se...@seblu.net wrote:
  I've the same kind trouble with -rc6 and my dell e6410. When module i915 is
  loaded screen become black and i loose the hand on the system.
 
  Nope, completely different bug. eDP being the issue here. Though I think
  the Dell 6410 is one of the few that Jesse has been able to get working
  (in drm-intel--next)
 
 You speek about eDP, but i don't use the external DisplayPort. Despite
 that you think, this can be linked?

eDP is embedded DP link to your laptop panel, it's an alternative replacement
for LVDS.

 
 I have to add, that with 2.6.33 to 2.6.35.7 host start and drm/intel
 works well ! I was so happy :)

yeah, that time I did borrow one e6410 and it's working. Then it left
me and I got regression report on eDP from PCH DP port.

 
 If you need i report something i can do it, but at the moment,
 starting with 2.6.36-rc6 produce no usable output for debug or
 understanding what goes wrong.
 

I sent mail before to ask if ajax's eDP connector type change for PCH/eDP
has caused regression for that, but one e6410 owner replied no effect by
revert that patch. You may help by bisect drm/i915.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Time to wrap up -next

[Zhenyu Wang]

On 2010.09.28 23:13:07 +0100, Chris Wilson wrote:
 Just a reminder that I am in the process of checking through -next for any
 major outstanding issues before sending it off to Dave Airlie. If you have
 any code for 2.6.37 that you have not yet sent to the list, you are
 running out of time.
 

No new stuff for now, but FYI current -next has kms regression for me
and haihao on sandybridge's LVDS and VGA, -fixes works fine.

I haven't done bisect yet.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/4] updated patches for KMS audio

[Zhenyu Wang]

I found my check for audio capability within CEA extension might
has some conflict with Adam's patch to add more detailed mode from
CEA ext block. But I haven't found Adam's patch in next tree, so I
just kept my current change.

This fixed incorrect probe for DP monitor's audio. Fengguang helped
to test this set. We got correct DP sound on Eizo EV2333W, and HDMI
audio also worked with no regression found.

Patch is against Chris's drm-intel-next branch.

thanks.

Zhenyu Wang (4):
  drm/edid: add helper function to detect monitor audio capability
  drm/i915: Enable DisplayPort audio
  drm/i915: Enable HDMI audio for monitor with audio support
  drm/i915: add new param to force audio on or off for HDMI/DP port

 drivers/gpu/drm/drm_edid.c|   92 +++--
 drivers/gpu/drm/i915/i915_drv.c   |3 +
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/intel_dp.c   |   64 +++--
 drivers/gpu/drm/i915/intel_hdmi.c |   13 --
 include/drm/drm_crtc.h|1 +
 6 files changed, 130 insertions(+), 44 deletions(-)

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

[Intel-gfx] [PATCH 1/4] drm/edid: add helper function to detect monitor audio capability

[Zhenyu Wang]

To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.

Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/drm_edid.c |   92 +---
 include/drm/drm_crtc.h |1 +
 2 files changed, 79 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96e9631..7f356af 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1268,34 +1268,51 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 }
 
 #define HDMI_IDENTIFIER 0x000C03
+#define AUDIO_BLOCK0x01
 #define VENDOR_BLOCK0x03
+#define EDID_BASIC_AUDIO   (1  6)
+
 /**
- * drm_detect_hdmi_monitor - detect whether monitor is hdmi.
- * @edid: monitor EDID information
- *
- * Parse the CEA extension according to CEA-861-B.
- * Return true if HDMI, false if not or unknown.
+ * Search EDID for CEA extension block.
  */
-bool drm_detect_hdmi_monitor(struct edid *edid)
+static u8 *drm_find_cea_extension(struct edid *edid)
 {
-   char *edid_ext = NULL;
-   int i, hdmi_id;
-   int start_offset, end_offset;
-   bool is_hdmi = false;
+   u8 *edid_ext = NULL;
+   int i;
 
/* No EDID or EDID extensions */
if (edid == NULL || edid-extensions == 0)
-   goto end;
+   return NULL;
 
/* Find CEA extension */
for (i = 0; i  edid-extensions; i++) {
-   edid_ext = (char *)edid + EDID_LENGTH * (i + 1);
-   /* This block is CEA extension */
-   if (edid_ext[0] == 0x02)
+   edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
+   if (edid_ext[0] == CEA_EXT)
break;
}
 
if (i == edid-extensions)
+   return NULL;
+
+   return edid_ext;
+}
+
+/**
+ * drm_detect_hdmi_monitor - detect whether monitor is hdmi.
+ * @edid: monitor EDID information
+ *
+ * Parse the CEA extension according to CEA-861-B.
+ * Return true if HDMI, false if not or unknown.
+ */
+bool drm_detect_hdmi_monitor(struct edid *edid)
+{
+   u8 *edid_ext;
+   int i, hdmi_id;
+   int start_offset, end_offset;
+   bool is_hdmi = false;
+
+   edid_ext = drm_find_cea_extension(edid);
+   if (!edid_ext)
goto end;
 
/* Data block offset in CEA extension block */
@@ -1326,6 +1343,53 @@ end:
 EXPORT_SYMBOL(drm_detect_hdmi_monitor);
 
 /**
+ * drm_detect_monitor_audio - check monitor audio capability
+ *
+ * Monitor should have CEA extension block.
+ * If monitor has 'basic audio', but no CEA audio blocks, it's 'basic
+ * audio' only. If there is any audio extension block and supported
+ * audio format, assume at least 'basic audio' support, even if 'basic
+ * audio' is not defined in EDID.
+ *
+ */
+bool drm_detect_monitor_audio(struct edid *edid)
+{
+   u8 *edid_ext;
+   int i, j;
+   bool has_audio = false;
+   int start_offset, end_offset;
+
+   edid_ext = drm_find_cea_extension(edid);
+   if (!edid_ext)
+   goto end;
+
+   has_audio = ((edid_ext[3]  EDID_BASIC_AUDIO) != 0);
+
+   if (has_audio) {
+   DRM_DEBUG_KMS(Monitor has basic audio support\n);
+   goto end;
+   }
+
+   /* Data block offset in CEA extension block */
+   start_offset = 4;
+   end_offset = edid_ext[2];
+
+   for (i = start_offset; i  end_offset;
+   i += ((edid_ext[i]  0x1f) + 1)) {
+   if ((edid_ext[i]  5) == AUDIO_BLOCK) {
+   has_audio = true;
+   for (j = 1; j  (edid_ext[i]  0x1f); j += 3)
+   DRM_DEBUG_KMS(CEA audio format %d\n,
+ (edid_ext[i + j]  3)  0xf);
+   goto end;
+   }
+   }
+end:
+   return has_audio;
+}
+EXPORT_SYMBOL(drm_detect_monitor_audio);
+
+/**
  * drm_add_edid_modes - add modes from EDID data, if available
  * @connector: connector we're probing
  * @edid: edid data
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c9f3cc5..284ca90 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -754,6 +754,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device *dev,
 extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern bool drm_detect_hdmi_monitor(struct edid *edid);
+extern bool drm_detect_monitor_audio(struct edid *edid);
 extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
-- 
1.7.1

___
Intel-gfx

[Intel-gfx] [PATCH 2/4] drm/i915: Enable DisplayPort audio

[Zhenyu Wang]

This will turn on DP audio output by checking monitor's audio
capability.

Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   61 +++
 1 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 208a4ec..81fca1e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1444,39 +1444,50 @@ intel_dp_detect(struct drm_connector *connector)
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t temp, bit;
enum drm_connector_status status;
+   struct edid *edid = NULL;
 
intel_dp-has_audio = false;
 
-   if (HAS_PCH_SPLIT(dev))
-   return ironlake_dp_detect(connector);
+   if (HAS_PCH_SPLIT(dev)) {
+   status = ironlake_dp_detect(connector);
+   } else {
+   switch (intel_dp-output_reg) {
+   case DP_B:
+   bit = DPB_HOTPLUG_INT_STATUS;
+   break;
+   case DP_C:
+   bit = DPC_HOTPLUG_INT_STATUS;
+   break;
+   case DP_D:
+   bit = DPD_HOTPLUG_INT_STATUS;
+   break;
+   default:
+   return connector_status_unknown;
+   }
 
-   switch (intel_dp-output_reg) {
-   case DP_B:
-   bit = DPB_HOTPLUG_INT_STATUS;
-   break;
-   case DP_C:
-   bit = DPC_HOTPLUG_INT_STATUS;
-   break;
-   case DP_D:
-   bit = DPD_HOTPLUG_INT_STATUS;
-   break;
-   default:
-   return connector_status_unknown;
-   }
+   temp = I915_READ(PORT_HOTPLUG_STAT);
 
-   temp = I915_READ(PORT_HOTPLUG_STAT);
+   if ((temp  bit) == 0)
+   return connector_status_disconnected;
 
-   if ((temp  bit) == 0)
-   return connector_status_disconnected;
+   status = connector_status_disconnected;
+   if (intel_dp_aux_native_read(intel_dp, 0x000, intel_dp-dpcd,
+sizeof (intel_dp-dpcd)) == sizeof 
(intel_dp-dpcd))
+   {
+   if (intel_dp-dpcd[0] != 0)
+   status = connector_status_connected;
+   }
+   }
 
-   status = connector_status_disconnected;
-   if (intel_dp_aux_native_read(intel_dp,
-0x000, intel_dp-dpcd,
-sizeof (intel_dp-dpcd)) == sizeof 
(intel_dp-dpcd))
-   {
-   if (intel_dp-dpcd[0] != 0)
-   status = connector_status_connected;
+   if (status == connector_status_connected) {
+   edid = drm_get_edid(connector, intel_dp-base.ddc_bus);
+   if (edid) {
+   intel_dp-has_audio = drm_detect_monitor_audio(edid);
+   connector-display_info.raw_edid = NULL;
+   kfree(edid);
+   }
}
+
return status;
 }
 
-- 
1.7.1

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

[Intel-gfx] [PATCH 3/4] drm/i915: Enable HDMI audio for monitor with audio support

[Zhenyu Wang]

Rely on monitor's audio capability to turn on audio output for HDMI.

Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_hdmi.c |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 783924c..90184e6 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -41,6 +41,7 @@ struct intel_hdmi {
struct intel_encoder base;
u32 sdvox_reg;
bool has_hdmi_sink;
+   bool has_audio;
 };
 
 static struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder)
@@ -71,11 +72,12 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder,
if (adjusted_mode-flags  DRM_MODE_FLAG_PHSYNC)
sdvox |= SDVO_HSYNC_ACTIVE_HIGH;
 
-   if (intel_hdmi-has_hdmi_sink) {
+   /* Required on CPT */
+   if (intel_hdmi-has_hdmi_sink  HAS_PCH_CPT(dev))
+   sdvox |= HDMI_MODE_SELECT;
+
+   if (intel_hdmi-has_audio)
sdvox |= SDVO_AUDIO_ENABLE;
-   if (HAS_PCH_CPT(dev))
-   sdvox |= HDMI_MODE_SELECT;
-   }
 
if (intel_crtc-pipe == 1) {
if (HAS_PCH_CPT(dev))
@@ -152,12 +154,14 @@ intel_hdmi_detect(struct drm_connector *connector)
enum drm_connector_status status = connector_status_disconnected;
 
intel_hdmi-has_hdmi_sink = false;
+   intel_hdmi-has_audio = false;
edid = drm_get_edid(connector, intel_hdmi-base.ddc_bus);
 
if (edid) {
if (edid-input  DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
intel_hdmi-has_hdmi_sink = 
drm_detect_hdmi_monitor(edid);
+   intel_hdmi-has_audio = drm_detect_monitor_audio(edid);
}
connector-display_info.raw_edid = NULL;
kfree(edid);
-- 
1.7.1

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

Re: [Intel-gfx] [PATCH 1/4] drm/edid: add helper function to detect monitor audio capability

[Zhenyu Wang]

On 2010.09.19 08:38:07 +0100, Chris Wilson wrote:
 
 This should be cc'ed for Adam Jackson's attention as well.

yep, I think I cc-ed ajax in git-send-mail command line...I'll amend the commit.

  +bool drm_detect_monitor_audio(struct edid *edid)
 
 drm_edid_has_monitor_audio()? That is a little more self-descriptive.
 (I also think drm_detect_hdmi_monitor is poorly named.)

yeah, that looks better. thanks.

 The last time Adam had a chance to comment on this EDID check, he
 suggested that we cannot rely on has_audio being a reliable indicator of
 the sink's properties. If the EDID has no audio support, then return
 early, otherwise perform the secondary check that extension block contains
 audio data.

That's also the problem we stuck for quite some time, and until recently
we got reply on this issue. Adam is right, 'basic audio' bit might not be
reliable, so we try to search audio block too, if there's any existence,
we will accept 'basic audio' support as well.

Thanks for the review!

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Enable DisplayPort audio

[Zhenyu Wang]

On 2010.09.16 14:31:31 +0800, Zhenyu Wang wrote:
 This will turn on DP audio output by checking monitor's audio
 capability.
 

oops, please ignore this one. Check EDID data after it's already
freed...

 Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 208a4ec..4a14727 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -1485,6 +1485,7 @@ static int intel_dp_get_modes(struct drm_connector 
 *connector)
   struct intel_dp *intel_dp = intel_attached_dp(connector);
   struct drm_device *dev = intel_dp-base.base.dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
 + struct edid *edid;
   int ret;
  
   /* We should parse the EDID data and find out if it has an audio sink
 @@ -1505,6 +1506,9 @@ static int intel_dp_get_modes(struct drm_connector 
 *connector)
   }
   }
  
 + edid = (struct edid *)connector-display_info.raw_edid;
 + intel_dp-has_audio = drm_detect_monitor_audio(edid);
 +
   return ret;
   }
  
 -- 
 1.7.1
 
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm: add helper function to detect monitor audio capability

[Zhenyu Wang]

To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.

Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/drm_edid.c |   85 ++-
 include/drm/drm_crtc.h |1 +
 2 files changed, 76 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96e9631..e34e0d1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1268,24 +1268,21 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 }
 
 #define HDMI_IDENTIFIER 0x000C03
+#define AUDIO_BLOCK0x01
 #define VENDOR_BLOCK0x03
+#define EDID_BASIC_AUDIO   (1  6)
+
 /**
- * drm_detect_hdmi_monitor - detect whether monitor is hdmi.
- * @edid: monitor EDID information
- *
- * Parse the CEA extension according to CEA-861-B.
- * Return true if HDMI, false if not or unknown.
+ * Search EDID for CEA extension block.
  */
-bool drm_detect_hdmi_monitor(struct edid *edid)
+static char *drm_find_cea_extension(struct edid *edid)
 {
char *edid_ext = NULL;
-   int i, hdmi_id;
-   int start_offset, end_offset;
-   bool is_hdmi = false;
+   int i;
 
/* No EDID or EDID extensions */
if (edid == NULL || edid-extensions == 0)
-   goto end;
+   return NULL;
 
/* Find CEA extension */
for (i = 0; i  edid-extensions; i++) {
@@ -1296,6 +1293,27 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
}
 
if (i == edid-extensions)
+   return NULL;
+
+   return edid_ext;
+}
+
+/**
+ * drm_detect_hdmi_monitor - detect whether monitor is hdmi.
+ * @edid: monitor EDID information
+ *
+ * Parse the CEA extension according to CEA-861-B.
+ * Return true if HDMI, false if not or unknown.
+ */
+bool drm_detect_hdmi_monitor(struct edid *edid)
+{
+   char *edid_ext;
+   int i, hdmi_id;
+   int start_offset, end_offset;
+   bool is_hdmi = false;
+
+   edid_ext = drm_find_cea_extension(edid);
+   if (!edid_ext)
goto end;
 
/* Data block offset in CEA extension block */
@@ -1326,6 +1344,53 @@ end:
 EXPORT_SYMBOL(drm_detect_hdmi_monitor);
 
 /**
+ * drm_detect_monitor_audio - check monitor audio capability
+ *
+ * Monitor should have CEA extension block.
+ * If monitor has 'basic audio', but no CEA audio blocks, it's 'basic
+ * audio' only. If there is any audio extension block and supported
+ * audio format, assume at least 'basic audio' support, even if 'basic
+ * audio' is not defined in EDID.
+ *
+ */
+bool drm_detect_monitor_audio(struct edid *edid)
+{
+   char *edid_ext;
+   int i, j;
+   bool has_audio = false;
+   int start_offset, end_offset;
+
+   edid_ext = drm_find_cea_extension(edid);
+   if (!edid_ext)
+   goto end;
+
+   has_audio = ((edid_ext[3]  EDID_BASIC_AUDIO) != 0);
+
+   if (has_audio) {
+   DRM_DEBUG_KMS(Monitor has basic audio support\n);
+   goto end;
+   }
+
+   /* Data block offset in CEA extension block */
+   start_offset = 4;
+   end_offset = edid_ext[2];
+
+   for (i = start_offset; i  end_offset;
+   i += ((edid_ext[i]  0x1f) + 1)) {
+   if ((edid_ext[i]  5) == AUDIO_BLOCK) {
+   has_audio = true;
+   for (j = 1; j  (edid_ext[i]  0x1f); j += 3)
+   DRM_DEBUG_KMS(CEA audio format %d\n,
+ (edid_ext[i + j]  3)  0xf);
+   goto end;
+   }
+   }
+end:
+   return has_audio;
+}
+EXPORT_SYMBOL(drm_detect_monitor_audio);
+
+/**
  * drm_add_edid_modes - add modes from EDID data, if available
  * @connector: connector we're probing
  * @edid: edid data
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c9f3cc5..284ca90 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -754,6 +754,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device *dev,
 extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern bool drm_detect_hdmi_monitor(struct edid *edid);
+extern bool drm_detect_monitor_audio(struct edid *edid);
 extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
-- 
1.7.1

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

[Intel-gfx] [PATCH 2/3] drm/i915: Enable DisplayPort audio

[Zhenyu Wang]

This will turn on DP audio output by checking monitor's audio
capability.

Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 208a4ec..4a14727 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1485,6 +1485,7 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_device *dev = intel_dp-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+   struct edid *edid;
int ret;
 
/* We should parse the EDID data and find out if it has an audio sink
@@ -1505,6 +1506,9 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
}
}
 
+   edid = (struct edid *)connector-display_info.raw_edid;
+   intel_dp-has_audio = drm_detect_monitor_audio(edid);
+
return ret;
}
 
-- 
1.7.1

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

[Intel-gfx] [PATCH 3/3] drm/i915: Enable HDMI audio for monitor with audio support

[Zhenyu Wang]

Rely on monitor's audio capability to turn on audio output for HDMI.

Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_hdmi.c |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 783924c..90184e6 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -41,6 +41,7 @@ struct intel_hdmi {
struct intel_encoder base;
u32 sdvox_reg;
bool has_hdmi_sink;
+   bool has_audio;
 };
 
 static struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder)
@@ -71,11 +72,12 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder,
if (adjusted_mode-flags  DRM_MODE_FLAG_PHSYNC)
sdvox |= SDVO_HSYNC_ACTIVE_HIGH;
 
-   if (intel_hdmi-has_hdmi_sink) {
+   /* Required on CPT */
+   if (intel_hdmi-has_hdmi_sink  HAS_PCH_CPT(dev))
+   sdvox |= HDMI_MODE_SELECT;
+
+   if (intel_hdmi-has_audio)
sdvox |= SDVO_AUDIO_ENABLE;
-   if (HAS_PCH_CPT(dev))
-   sdvox |= HDMI_MODE_SELECT;
-   }
 
if (intel_crtc-pipe == 1) {
if (HAS_PCH_CPT(dev))
@@ -152,12 +154,14 @@ intel_hdmi_detect(struct drm_connector *connector)
enum drm_connector_status status = connector_status_disconnected;
 
intel_hdmi-has_hdmi_sink = false;
+   intel_hdmi-has_audio = false;
edid = drm_get_edid(connector, intel_hdmi-base.ddc_bus);
 
if (edid) {
if (edid-input  DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
intel_hdmi-has_hdmi_sink = 
drm_detect_hdmi_monitor(edid);
+   intel_hdmi-has_audio = drm_detect_monitor_audio(edid);
}
connector-display_info.raw_edid = NULL;
kfree(edid);
-- 
1.7.1

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

Re: [Intel-gfx] [PATCH] drm/1915: save the right fence registers for Sandybridge

[Zhenyu Wang]

On 2010.09.16 15:59:29 +0800, Yuanhan Liu wrote:
 Sandybridge uses different address offset(0x10) for fence table registers,
 so make sure we save the right fence registers before suspend.
 
 This would fix bug: https://bugs.freedesktop.org/show_bug.cgi?id=30199
 

Nice catch! But fence reg only changed on sandybridge, shouldn't use
HAS_PCH_SPLIT.

 Signed-off-by: Yuanhan Liu yuanhan@intel.com
 ---
  drivers/gpu/drm/i915/i915_suspend.c |   10 --
  1 files changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
 b/drivers/gpu/drm/i915/i915_suspend.c
 index 2c6b98f..ea09375 100644
 --- a/drivers/gpu/drm/i915/i915_suspend.c
 +++ b/drivers/gpu/drm/i915/i915_suspend.c
 @@ -789,7 +789,10 @@ int i915_save_state(struct drm_device *dev)
   dev_priv-saveSWF2[i] = I915_READ(SWF30 + (i  2));
  
   /* Fences */
 - if (IS_I965G(dev)) {
 + if (HAS_PCH_SPLIT(dev)) {
 + for (i = 0; i  16; i++)
 + dev_priv-saveFENCE[i] = 
 I915_READ64(FENCE_REG_SANDYBRIDGE_0 + (i * 8));
 + } else if (IS_I965G(dev)) {
   for (i = 0; i  16; i++)
   dev_priv-saveFENCE[i] = I915_READ64(FENCE_REG_965_0 + 
 (i * 8));
   } else {
 @@ -815,7 +818,10 @@ int i915_restore_state(struct drm_device *dev)
   I915_WRITE(HWS_PGA, dev_priv-saveHWS);
  
   /* Fences */
 - if (IS_I965G(dev)) {
 + if (HAS_PCH_SPLIT(dev)) {
 + for (i = 0; i  16; i++)
 + I915_WRITE64(FENCE_REG_SANDYBRIDGE_0 + (i * 8), 
 dev_priv-saveFENCE[i]);
 + } else if (IS_I965G(dev)) {
   for (i = 0; i  16; i++)
   I915_WRITE64(FENCE_REG_965_0 + (i * 8), 
 dev_priv-saveFENCE[i]);
   } else {
 -- 
 1.7.2.2
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Inter-gfx][PATCH][v3 3/4] drm/i915: add set_tail hook in struct intel_ring_buffer

[Zhenyu Wang]

On 2010.09.16 10:43:12 +0800, Xiang, Haihao wrote:
 This is prepared for video codec ring buffer on Sandybridge. It is
 needed to read/write more than one register to move the tail pointer of
 the video codec ring on Sandybridge.

Do we really need new 'set_tail'? Isn't advance_ring used for set ring tail?

Sandybridge workaround can be put into advance_ring, so your 'set_tail''s only
left usage is for initialization. Is that workaround even needed for initial
0 setting? Or can't that be done in init function by using advance_ring?

 
 Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/intel_ringbuffer.c |   22 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++
  2 files changed, 19 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
 b/drivers/gpu/drm/i915/intel_ringbuffer.c
 index a9d4f5b..0a65182 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 @@ -134,6 +134,12 @@ static unsigned int render_ring_get_tail(struct 
 drm_device *dev,
   return I915_READ(PRB0_TAIL)  TAIL_ADDR;
  }
  
 +static inline void render_ring_set_tail(struct drm_device *dev, u32 value)
 +{
 + drm_i915_private_t *dev_priv = dev-dev_private;
 + I915_WRITE(PRB0_TAIL, value);
 +}
 +
  static unsigned int render_ring_get_active_head(struct drm_device *dev,
   struct intel_ring_buffer *ring)
  {
 @@ -146,8 +152,7 @@ static unsigned int render_ring_get_active_head(struct 
 drm_device *dev,
  static void render_ring_advance_ring(struct drm_device *dev,
   struct intel_ring_buffer *ring)
  {
 - drm_i915_private_t *dev_priv = dev-dev_private;
 - I915_WRITE(PRB0_TAIL, ring-tail);
 + render_ring_set_tail(dev, ring-tail);
  }
  
  static int init_ring_common(struct drm_device *dev,
 @@ -161,7 +166,7 @@ static int init_ring_common(struct drm_device *dev,
   /* Stop the ring if it's running. */
   I915_WRITE(ring-regs.ctl, 0);
   I915_WRITE(ring-regs.head, 0);
 - I915_WRITE(ring-regs.tail, 0);
 + ring-set_tail(dev, 0);
  
   /* Initialize the ring. */
   I915_WRITE(ring-regs.start, obj_priv-gtt_offset);
 @@ -404,6 +409,12 @@ static inline unsigned int bsd_ring_get_tail(struct 
 drm_device *dev,
   return I915_READ(BSD_RING_TAIL)  TAIL_ADDR;
  }
  
 +static inline void bsd_ring_set_tail(struct drm_device *dev, u32 value)
 +{
 + drm_i915_private_t *dev_priv = dev-dev_private;
 + I915_WRITE(BSD_RING_TAIL, value);
 +}
 +
  static inline unsigned int bsd_ring_get_active_head(struct drm_device *dev,
   struct intel_ring_buffer *ring)
  {
 @@ -414,8 +425,7 @@ static inline unsigned int 
 bsd_ring_get_active_head(struct drm_device *dev,
  static inline void bsd_ring_advance_ring(struct drm_device *dev,
   struct intel_ring_buffer *ring)
  {
 - drm_i915_private_t *dev_priv = dev-dev_private;
 - I915_WRITE(BSD_RING_TAIL, ring-tail);
 + bsd_ring_set_tail(dev, ring-tail);
  }
  
  static int init_bsd_ring(struct drm_device *dev,
 @@ -820,6 +830,7 @@ static struct intel_ring_buffer render_ring = {
   .init   = init_render_ring,
   .get_head   = render_ring_get_head,
   .get_tail   = render_ring_get_tail,
 + .set_tail   = render_ring_set_tail,
   .get_active_head= render_ring_get_active_head,
   .advance_ring   = render_ring_advance_ring,
   .flush  = render_ring_flush,
 @@ -857,6 +868,7 @@ static struct intel_ring_buffer bsd_ring = {
   .init   = init_bsd_ring,
   .get_head   = bsd_ring_get_head,
   .get_tail   = bsd_ring_get_tail,
 + .set_tail   = bsd_ring_set_tail,
   .get_active_head= bsd_ring_get_active_head,
   .advance_ring   = bsd_ring_advance_ring,
   .flush  = bsd_ring_flush,
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
 b/drivers/gpu/drm/i915/intel_ringbuffer.h
 index df7acc5..f89e528 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
 @@ -44,6 +44,8 @@ struct  intel_ring_buffer {
   struct intel_ring_buffer *ring);
   unsigned int(*get_tail)(struct drm_device *dev,
   struct intel_ring_buffer *ring);
 + void(*set_tail)(struct drm_device *dev,
 + u32 value);
   unsigned int(*get_active_head)(struct drm_device *dev,
   struct intel_ring_buffer *ring);
   void(*advance_ring)(struct drm_device *dev,
 -- 
 1.7.0.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver 

Re: [Intel-gfx] [Inter-gfx][PATCH][v3 3/4] drm/i915: add set_tail hook in struct intel_ring_buffer

[Zhenyu Wang]

On 2010.09.16 13:10:29 +0800, Xiang, Haihao wrote:
  Or can't that be done in init function by using advance_ring?
 advance_ring uses ring-tail to set TAIL register, i965_reset() also
 invokes ring-init() to re-init ring buffer, how to guarantee ring-tail
 is 0? BTW advance_ring can be implemented as set_tail(dev, ring-tail).
 

oh, that's bad, not only just for render ring, but ring tail should
always be inited correctly, not just in static variable..

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [intel-gfx][PATCH 2/2] drm/i915: Add a new ring buffer on Sandybridge

[Zhenyu Wang]

On 2010.09.03 09:57:37 +0800, Xiang, Haihao wrote:
  
  If I'm not completely mistaken, all these ringbuffer register have the
  same offsets over a common base: 0x02000 for the render ring, 0x04000 for
  bsd on gen5, 0x12000 for bsd on gen6.
 Some registers (e.g. HSW_PGA) don't follow this rule.

which you can explicitly note it in ring struct.

 Even if the register follows the above rule, we can not expect to use
 the same function to access this register. E.g. Setting TAIL for this
 new ring buffer must follow a special sequence on Sandybridge.
 

you only need to handle it specially in ring advance function. I'd like
to only leave ring specific functions as

- ring cache flush
- ring new request
- ring seqno state
- ring irq handling

others are so common for all rings.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx