[Intel-gfx] The latest Display Status
All, After a new round of display testing, some new bugs filed is as following table. The kernel is: The Linux Kernel, the operating system core itself Kernel: (drm-intel-fixes)d7d39e20cc5e44f915d6c5687f65839632c44381 Some additional commit info: Author: Jesse Barnes jbar...@virtuousgeek.org Date: Wed Aug 3 12:59:21 2011 -0700 drm/i915: enable/disable spread spectrum as needed on mode set 40031https://bugs.freedesktop.org/show_bug.cgi?id=40031 [Regression] testdisplay can't display correctly with 30 bpp 40011https://bugs.freedesktop.org/show_bug.cgi?id=40011 [SNB]testdisplay can't work with 32 bits depth of scanout buffer 40029https://bugs.freedesktop.org/show_bug.cgi?id=40029 [regression IronLake] blank screen while kms boots up 40030https://bugs.freedesktop.org/show_bug.cgi?id=40030 [regression IRL] hotplug causes LVDS black screen Thanks --Yi,Sun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 native backlight never got merged
Hi Keith all,
On Thu, 2011-08-11 at 15:28 -0700, Keith Packard wrote:
On Thu, 11 Aug 2011 21:36:38 +0200, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
Since there's no known regression introduced by Matthew's patch, could
it be merged? Feel free to add a
I've had to amend the patch a bit to get it to apply on top of
drm-intel-fixes; anyone care to take a look and see if it still looks
reasonable (and/or actually works?)
Matthew's last patch from July 16th applies without modification on top
of Linux 3.0 and 3.1-rc1, and applies with some offsets on top of
drm-intel-fixes.
I've eyeballed the code and they look identical apart from some lines
struct changes being transposed a bit, and intel_panel_init_backlight is
no longer static; please find the patch attached below (with my
Tested-by: added)
From fa7419eee713b989e2c268c7b06ec9a544a2b647 Mon Sep 17 00:00:00 2001
From: Matthew Garrett m...@redhat.com
Date: Sat, 16 Jul 2011 23:31:01 +1000
Subject: [PATCH] Not all systems expose a firmware or platform mechanism for
changing the backlight intensity on i915, so add native
driver support.
Signed-off-by: Matthew Garrett m...@redhat.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: David Airlie airl...@linux.ie
Cc: Alex Deucher alexdeuc...@gmail.com
Cc: Ben Skeggs bske...@redhat.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jesse Barnes jbar...@virtuousgeek.org
Tested-by: Sedat Dilek sedat.di...@googlemail.com
Tested-by: Michel Alexandre Salim sali...@fedoraproject.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/i915/i915_drv.h |4 ++
drivers/gpu/drm/i915/intel_dp.c |7 +++
drivers/gpu/drm/i915/intel_drv.h |3 +-
drivers/gpu/drm/i915/intel_lvds.c |5 ++
drivers/gpu/drm/i915/intel_opregion.c |1 -
drivers/gpu/drm/i915/intel_panel.c| 72 -
6 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6867e19..886bd29 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -36,6 +36,7 @@
#include linux/io-mapping.h
#include linux/i2c.h
#include drm/intel-gtt.h
+#include linux/backlight.h
/* General customization:
*/
@@ -689,6 +690,7 @@ typedef struct drm_i915_private {
int child_dev_num;
struct child_device_config *child_dev;
struct drm_connector *int_lvds_connector;
+ struct drm_connector *int_edp_connector;
bool mchbar_need_disable;
@@ -722,6 +724,8 @@ typedef struct drm_i915_private {
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
+ struct backlight_device *backlight;
+
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f797fb5..2cde606 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1811,6 +1811,11 @@ done:
static void
intel_dp_destroy (struct drm_connector *connector)
{
+ struct drm_device *dev = connector-dev;
+
+ if (intel_dpd_is_edp(dev))
+ intel_panel_destroy_backlight(dev);
+
drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(connector);
@@ -2043,6 +2048,8 @@ intel_dp_init(struct drm_device *dev, int output_reg)
DRM_MODE_TYPE_PREFERRED;
}
}
+ dev_priv-int_edp_connector = connector;
+ intel_panel_setup_backlight(dev);
}
intel_dp_add_properties(intel_dp, connector);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6e990f9..057e2bc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -274,9 +274,10 @@ extern void intel_pch_panel_fitting(struct drm_device *dev,
extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
extern u32 intel_panel_get_backlight(struct drm_device *dev);
extern void intel_panel_set_backlight(struct drm_device *dev, u32 level);
-extern void intel_panel_setup_backlight(struct drm_device *dev);
+extern int intel_panel_setup_backlight(struct drm_device *dev);
extern void intel_panel_enable_backlight(struct drm_device *dev);
extern void intel_panel_disable_backlight(struct drm_device *dev);
+extern void intel_panel_destroy_backlight(struct drm_device *dev);
extern enum drm_connector_status intel_panel_detect(struct drm_device *dev);
extern void intel_crtc_load_lut(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index b28f7bd..9104496 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -582,6 +582,8 @@ static void
Re: [Intel-gfx] missing acpi backlight bisected to 9661e92c10
On Mon, Aug 22, 2011 at 10:25:24AM +0430, Ali Gholami Rudi wrote: Yet, /sys/devices/virtual/backlight/acpi_video0/brightness only appears after the revert. Seems something changes its behavior if new_bd-dev.parent is not NULL in backlight_device_register(). Well, yes, if it has a parent it won't be under /sys/devices/virtual. Does it appear under /sys/class/backlight ? -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 native backlight never got merged
On Fri, 12 Aug 2011 12:11:33 +0200, Michel Alexandre Salim sali...@fedoraproject.org wrote: Matthew's last patch from July 16th applies without modification on top of Linux 3.0 and 3.1-rc1, and applies with some offsets on top of drm-intel-fixes. I must have skipped right over it somehow. I've eyeballed the code and they look identical apart from some lines struct changes being transposed a bit, and intel_panel_init_backlight is no longer static; please find the patch attached below (with my Tested-by: added) I'll merge this version, with the change to make intel_panel_init_backlight static (it's not declared in a header, and isn't used outside of intel_panel.c). Thanks for finding this version! -- keith.pack...@intel.com pgpAApgQuUBAH.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] The latest Display Status
On Fri, 12 Aug 2011 15:58:52 +0800, Sun, Yi yi@intel.com wrote: Non-text part: multipart/mixed Non-text part: multipart/alternative drm/i915: enable/disable spread spectrum as needed on mode set 40031https://bugs.freedesktop.org/show_bug.cgi?id=40031 [Regression] testdisplay can't display correctly with 30 bpp 40011https://bugs.freedesktop.org/show_bug.cgi?id=40011 [SNB]testdisplay can't work with 32 bits depth of scanout buffer 40029https://bugs.freedesktop.org/show_bug.cgi?id=40029 [regression IronLake] blank screen while kms boots up 40030https://bugs.freedesktop.org/show_bug.cgi?id=40030 [regression IRL] hotplug causes LVDS black screen Thanks for catching these before they were pushed upstream! -- keith.pack...@intel.com pgpwavugOCfgu.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 native backlight never got merged
On Fri, 2011-08-12 at 06:52 -0700, Keith Packard wrote: On Fri, 12 Aug 2011 12:11:33 +0200, Michel Alexandre Salim sali...@fedoraproject.org wrote: Matthew's last patch from July 16th applies without modification on top of Linux 3.0 and 3.1-rc1 [...] From fa7419eee713b989e2c268c7b06ec9a544a2b647 Mon Sep 17 00:00:00 2001 I'll merge this version, with the change to make intel_panel_init_backlight static (it's not declared in a header, and isn't used outside of intel_panel.c). That version works also works fine for me. Tested-by: Kamal Mostafa ka...@canonical.com -Kamal signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915: use PIPE_CONTROL for flushing on gen6+
I'm trying to figure out why this doesn't work. Anyone have ideas?
On gen6+ (well probably since Cantiga actually) we're supposed to use
PIPE_CONTROL rather than MI_FLUSH for flushing the pipeline and
caches. This patch doesn't cause hangs or crashes in my testing, but
does prevent glxgears from displaying anything.
The other worrying thing about this is that gen6+ has a command length
field of 3, but we're using 2 in the DRI driver, even on gen6.
Changing it doesn't seem to have any effect, but it's still of concern.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5baaef4..4a456a6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -236,6 +236,8 @@
#define DISPLAY_PLANE_A (020)
#define DISPLAY_PLANE_B (120)
#define GFX_OP_PIPE_CONTROL((0x329)|(0x327)|(0x224)|2)
+#define GFX_OP_PIPE_CONTROL_GEN6 ((0x329)|(0x327)|(0x224)|3)
+#define PIPE_CONTROL_CS_STALL (120)
#define PIPE_CONTROL_QW_WRITE(114)
#define PIPE_CONTROL_DEPTH_STALL (113)
#define PIPE_CONTROL_WC_FLUSH(112)
@@ -244,8 +246,8 @@
#define PIPE_CONTROL_ISP_DIS (19)
#define PIPE_CONTROL_NOTIFY (18)
#define PIPE_CONTROL_GLOBAL_GTT (12) /* in addr dword */
-#define PIPE_CONTROL_STALL_EN(11) /* in addr word, Ironlake+ only
*/
-
+#define PIPE_CONTROL_STALL_AT_SCOREBOARD (11) /* in addr word, Ironlake+
only */
+#define PIPE_CONTROL_DEPTH_FLUSH (10)
/*
* Reset registers
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 47b9b27..cecc1e1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -34,6 +34,16 @@
#include i915_trace.h
#include intel_drv.h
+/*
+ * 965+ support PIPE_CONTROL commands, which provide finer grained control
+ * over cache flushing.
+ */
+struct pipe_control {
+ struct drm_i915_gem_object *obj;
+ volatile u32 *cpu_page;
+ u32 gtt_offset;
+};
+
static inline int ring_space(struct intel_ring_buffer *ring)
{
int space = (ring-head HEAD_ADDR) - (ring-tail + 8);
@@ -123,6 +133,112 @@ render_ring_flush(struct intel_ring_buffer *ring,
return 0;
}
+/**
+ * Emits a PIPE_CONTROL with a non-zero post-sync operation, for
+ * implementing two workarounds on gen6. From section 1.4.7.1
+ * PIPE_CONTROL of the Sandy Bridge PRM volume 2 part 1:
+ *
+ * [DevSNB-C+{W/A}] Before any depth stall flush (including those
+ * produced by non-pipelined state commands), software needs to first
+ * send a PIPE_CONTROL with no bits set except Post-Sync Operation !=
+ * 0.
+ *
+ * [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable
+ * =1, a PIPE_CONTROL with any non-zero post-sync-op is required.
+ *
+ * And the workaround for these two requires this workaround first:
+ *
+ * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
+ * BEFORE the pipe-control with a post-sync op and no write-cache
+ * flushes.
+ *
+ * And this last workaround is tricky because of the requirements on
+ * that bit. From section 1.4.7.2.3 Stall of the Sandy Bridge PRM
+ * volume 2 part 1:
+ *
+ * 1 of the following must also be set:
+ * - Render Target Cache Flush Enable ([12] of DW1)
+ * - Depth Cache Flush Enable ([0] of DW1)
+ * - Stall at Pixel Scoreboard ([1] of DW1)
+ * - Depth Stall ([13] of DW1)
+ * - Post-Sync Operation ([13] of DW1)
+ * - Notify Enable ([8] of DW1)
+ *
+ * The cache flushes require the workaround flush that triggered this
+ * one, so we can't use it. Depth stall would trigger the same.
+ * Post-sync nonzero is what triggered this second workaround, so we
+ * can't use that one either. Notify enable is IRQs, which aren't
+ * really our business. That leaves only stall at scoreboard.
+ */
+static int
+intel_emit_post_sync_nonzero_flush(struct intel_ring_buffer *ring)
+{
+ struct pipe_control *pc = ring-private;
+ u32 scratch_addr = pc-gtt_offset + 128;
+ int ret;
+
+
+ ret = intel_ring_begin(ring, 6);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, GFX_OP_PIPE_CONTROL_GEN6);
+ intel_ring_emit(ring, PIPE_CONTROL_CS_STALL |
+ PIPE_CONTROL_STALL_AT_SCOREBOARD);
+ intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /*
address */
+ intel_ring_emit(ring, 0); /* low dword */
+ intel_ring_emit(ring, 0); /* high dword */
+ intel_ring_emit(ring, MI_NOOP);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 6);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, GFX_OP_PIPE_CONTROL_GEN6);
+ intel_ring_emit(ring, PIPE_CONTROL_QW_WRITE);
+ intel_ring_emit(ring, scratch_addr | PIPE_CONTROL_GLOBAL_GTT); /*
address */
+ intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, 0);
+
[Intel-gfx] [PATCH 1/2] drm/i915: clear GFX_MODE on IVB at init time
GFX_MODE controls important behavior like PPGTT, run lists, and TLB
invalidate behavior. On the SDV I'm using, the TLB invalidation mode
was defaulting to pipe control only which meant regular MI_FLUSHes
wouldn't actually flush the TLB, leading to all sorts of stale data
getting used.
So initialize it to 0 at ring buffer init time until we actually use
PIPE_CONTROL for TLB invalidation.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7033e01..9f3938c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -382,6 +382,8 @@
#define GFX_PSMI_GRANULARITY (110)
#define GFX_PPGTT_ENABLE (19)
+#define GFX_MODE_GEN7 0x0229c
+
#define SCPD0 0x0209c /* 915+ only */
#define IER0x020a0
#define IIR0x020a4
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 47b9b27..80fea69 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1293,6 +1293,8 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring-add_request = gen6_add_request;
ring-irq_get = gen6_render_ring_get_irq;
ring-irq_put = gen6_render_ring_put_irq;
+ if (IS_GEN7(dev))
+ I915_WRITE(GFX_MODE_GEN7, 0x);
} else if (IS_GEN5(dev)) {
ring-add_request = pc_render_add_request;
ring-get_seqno = pc_render_get_seqno;
--
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/2] drm/i915: suspend/resume rps and ring freq state on IVB
These are enabled at init time, but we need to save/restore them as well.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_suspend.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 87677d6..cd79e55 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -820,7 +820,7 @@ int i915_save_state(struct drm_device *dev)
if (IS_IRONLAKE_M(dev))
ironlake_disable_drps(dev);
- if (IS_GEN6(dev))
+ if (IS_GEN6(dev) || IS_GEN7(dev))
gen6_disable_rps(dev);
/* Cache mode state */
@@ -878,7 +878,7 @@ int i915_restore_state(struct drm_device *dev)
intel_init_emon(dev);
}
- if (IS_GEN6(dev)) {
+ if (IS_GEN6(dev) || IS_GEN7(dev)) {
gen6_enable_rps(dev_priv);
gen6_update_ring_freq(dev_priv);
}
--
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 1/2] drm/i915: clear GFX_MODE on IVB at init time
On Fri, 12 Aug 2011 14:55:32 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
GFX_MODE controls important behavior like PPGTT, run lists, and TLB
invalidate behavior. On the SDV I'm using, the TLB invalidation mode
was defaulting to pipe control only which meant regular MI_FLUSHes
wouldn't actually flush the TLB, leading to all sorts of stale data
getting used.
So initialize it to 0 at ring buffer init time until we actually use
PIPE_CONTROL for TLB invalidation.
Ignore this one, see below for an updated patch that uses bit
definitions and makes sure the register gets reset at GPU reset time as
well.
--
Jesse Barnes, Intel Open Source Technology Center
From ac1b88dc2f4cd3a00746063899c6e6be4d5f2065 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri, 12 Aug 2011 15:15:06 -0700
Subject: [PATCH] drm/i915: set GFX_MODE to pre-Ivybridge default value even on
Ivybridge
Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that
MI_FLUSH would flush the TLBs in addition to the rest of the caches
indicated in the MI_FLUSH command. However starting with Ivybridge, the
register defaults to 0x2800 out of reset, meaning that to invalidate the
TLB we need to use PIPE_CONTROL. Since we're not doing that yet, go
back to the old default so things work.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7033e01..26641ad 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -375,6 +375,7 @@
# define MI_FLUSH_ENABLE (1 11)
#define GFX_MODE 0x02520
+#define GFX_MODE_GEN7 0x0229c
#define GFX_RUN_LIST_ENABLE (115)
#define GFX_TLB_INVALIDATE_ALWAYS(113)
#define GFX_SURFACE_FAULT_ENABLE (112)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 47b9b27..6dad947 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -290,6 +290,9 @@ static int init_render_ring(struct intel_ring_buffer *ring)
if (IS_GEN6(dev) || IS_GEN7(dev))
mode |= MI_FLUSH_ENABLE 16 | MI_FLUSH_ENABLE;
I915_WRITE(MI_MODE, mode);
+ if (IS_GEN7(dev))
+ I915_WRITE(GFX_MODE_GEN7, (GFX_REPLAY_MODE 16) |
+ GFX_REPLAY_MODE);
}
if (INTEL_INFO(dev)-gen = 6) {
--
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 1/2] drm/i915: clear GFX_MODE on IVB at init time
On Fri, 12 Aug 2011 15:18:09 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 12 Aug 2011 14:55:32 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
GFX_MODE controls important behavior like PPGTT, run lists, and TLB
invalidate behavior. On the SDV I'm using, the TLB invalidation mode
was defaulting to pipe control only which meant regular MI_FLUSHes
wouldn't actually flush the TLB, leading to all sorts of stale data
getting used.
So initialize it to 0 at ring buffer init time until we actually use
PIPE_CONTROL for TLB invalidation.
Ignore this one, see below for an updated patch that uses bit
definitions and makes sure the register gets reset at GPU reset time as
well.
Ignore the last one too. Third time's the charm!
--
Jesse Barnes, Intel Open Source Technology Center
From 91f24a59e03b338e114ecafe5c589c1f36119c02 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri, 12 Aug 2011 15:15:06 -0700
Subject: [PATCH] drm/i915: set GFX_MODE to pre-Ivybridge default value even on
Ivybridge
Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that
MI_FLUSH would flush the TLBs in addition to the rest of the caches
indicated in the MI_FLUSH command. However starting with Ivybridge, the
register defaults to 0x2800 out of reset, meaning that to invalidate the
TLB we need to use PIPE_CONTROL. Since we're not doing that yet, go
back to the old default so things work.
v2: don't forget to actually *clear* the new bit
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7033e01..26641ad 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -375,6 +375,7 @@
# define MI_FLUSH_ENABLE (1 11)
#define GFX_MODE 0x02520
+#define GFX_MODE_GEN7 0x0229c
#define GFX_RUN_LIST_ENABLE (115)
#define GFX_TLB_INVALIDATE_ALWAYS(113)
#define GFX_SURFACE_FAULT_ENABLE (112)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 47b9b27..0b17036 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -290,6 +290,10 @@ static int init_render_ring(struct intel_ring_buffer *ring)
if (IS_GEN6(dev) || IS_GEN7(dev))
mode |= MI_FLUSH_ENABLE 16 | MI_FLUSH_ENABLE;
I915_WRITE(MI_MODE, mode);
+ if (IS_GEN7(dev))
+ I915_WRITE(GFX_MODE_GEN7, ((GFX_TLB_INVALIDATE_ALWAYS |
+ GFX_REPLAY_MODE) 16) |
+ GFX_REPLAY_MODE);
}
if (INTEL_INFO(dev)-gen = 6) {
--
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 1/2] drm/i915: clear GFX_MODE on IVB at init time
On Fri, 12 Aug 2011 15:28:32 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: I915_WRITE(MI_MODE, mode); + if (IS_GEN7(dev)) + I915_WRITE(GFX_MODE_GEN7, ((GFX_TLB_INVALIDATE_ALWAYS | + GFX_REPLAY_MODE) 16) | +GFX_REPLAY_MODE); That's maximally confusing indentation ;-) Also it reads like that is a chicken bit, as in order to invalidate always on flush we need to clear it? Can we play around with the name to avoid confusion in the code and confusion with the spec? #define ENABLE(x) ((x) 16 | (x)) #define DISABLE(x) ((x) 16 | 0) Granted finding good names for those is hard. Perhaps ENABLE_16(x), DISABLE_16(x) to indicate the mask size. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] non-blocking map
On Thu, 11 Aug 2011 18:19:40 -0700, Ben Widawsky b...@bwidawsk.net wrote: Non-text part: multipart/mixed Non-text part: multipart/signed On Thu, Aug 11, 2011 at 05:56:21PM -0700, Keith Packard wrote: On Thu, 11 Aug 2011 17:47:24 -0700, Ben Widawsky b...@bwidawsk.net wrote: These are dirty hacks just to enable testing write only non-blocking maps. I haven't yet created a good test, but maybe someone can shoot this down before I waste more time :). What's the planned usage? It's supposed to speed up things like map_range_buffer which tend to do write only operations and shouldn't have to do a blocking set domain for write only actions (read only from GPU). I think for write-only ARB_mbr we want to be using GTT mappings, not CPU mappings. pgpjiwzXLqACp.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: use PIPE_CONTROL for flushing on gen6+
On Fri, 12 Aug 2011 11:18:45 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: I'm trying to figure out why this doesn't work. Anyone have ideas? On gen6+ (well probably since Cantiga actually) we're supposed to use PIPE_CONTROL rather than MI_FLUSH for flushing the pipeline and caches. This patch doesn't cause hangs or crashes in my testing, but does prevent glxgears from displaying anything. The other worrying thing about this is that gen6+ has a command length field of 3, but we're using 2 in the DRI driver, even on gen6. Changing it doesn't seem to have any effect, but it's still of concern. From what I've read, the hardware tends to process shortened packets using some garbage in whatever fields were left out. I don't see why we'd need a separate object for the pipe control write destination. We could just drop it in some unused bit of the status page, right? I'd drop the scratch_addr from packets that don't do a post-sync write, for clarity. I don't see what's actually going wrong in this patch, though. pgp53LgcjoXJg.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] non-blocking map
On Fri, Aug 12, 2011 at 04:28:17PM -0700, Eric Anholt wrote: On Thu, 11 Aug 2011 18:19:40 -0700, Ben Widawsky b...@bwidawsk.net wrote: Non-text part: multipart/mixed Non-text part: multipart/signed On Thu, Aug 11, 2011 at 05:56:21PM -0700, Keith Packard wrote: On Thu, 11 Aug 2011 17:47:24 -0700, Ben Widawsky b...@bwidawsk.net wrote: These are dirty hacks just to enable testing write only non-blocking maps. I haven't yet created a good test, but maybe someone can shoot this down before I waste more time :). What's the planned usage? It's supposed to speed up things like map_range_buffer which tend to do write only operations and shouldn't have to do a blocking set domain for write only actions (read only from GPU). I think for write-only ARB_mbr we want to be using GTT mappings, not CPU mappings. I'm also planning to do this for GTT mappings, but that was harder and I thought this might also be of some benefit. pgpr6o0rOH0oJ.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
