login
Search
Hi,
In recent kernels, my X display (running with a KMS-enabled X server)
has been very jittery and with lots of glitching and tearing --- sorry
if this isn't the correct technical term, not sure what it is --- on my
T400 Lenovo laptop. It seems related to what is on the desktop, and
moving the mouse does seem to affect the rate and percentage of the
screen which jitters --- which is enough to be very distracting,
although I can still read the contents of the windows where the screen
is tearing/glitching/flashing.
I bisected it down to this commit:
74dff282237ea8c0a5df1afd8526eac4b6cee063 is the first bad commit
commit 74dff282237ea8c0a5df1afd8526eac4b6cee063
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Mon Sep 14 15:39:40 2009 -0700
drm/i915: framebuffer compression for GM45+
Add support for framebuffer compression on GM45 and above. Removes
some unnecessary I915_HAS_FBC checks as well (this is now part of the
FBC display function).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
... and taking the latest git mainline, and I confirmed that the problem
was still present, and then after reverting this commit, the problem
went away.
I've included my Xorg.0.log file in case that's helpful. Please let me
know if there's anything else you need.
Thanks, regards,
- Ted
X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-24-server i686 Ubuntu
Current Operating System: Linux closure 2.6.32-rc2-00197-g7ef68a2 #24 SMP Fri Oct 2 18:11:14 EDT 2009 i686
Kernel command line: root=/dev/mapper/ssd-root rootfstype=ext4 ro
Build Date: 05 August 2009 11:48:50AM
xorg-server 2:1.6.3-1ubuntu1 (buildd@rothera.buildd)
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command ...On Fri, 02 Oct 2009 18:40:27 -0400 Yeah I've had a couple of other reports of flicker pointing to this commit... I'll be able to look into it next week. -- Jesse Barnes, Intel Open Source Technology Center --
Disabling compression works fine (as temporary workaround until the issue is
solved).
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a5fb79..075092b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4165,7 +4165,7 @@ static void intel_init_display(struct drm_device *dev)
/* Only mobile has FBC, leave pointers NULL for other chips */
if (IS_MOBILE(dev)) {
- if (IS_GM45(dev)) {
+ if (0 && IS_GM45(dev)) {
dev_priv->display.fbc_enabled = g4x_fbc_enabled;
dev_priv->display.enable_fbc = g4x_enable_fbc;
dev_priv->display.disable_fbc = g4x_disable_fbc;
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
--
On Fri, 02 Oct 2009 18:40:27 -0400
I still haven't seen this issue myself, so I'm not sure if this patch
will help. I think it's a necessary one nonetheless though.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6035d3d..5dd5354 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -342,6 +342,7 @@ typedef struct drm_i915_private {
u32 savePFIT_CONTROL;
u32 save_palette_a[256];
u32 save_palette_b[256];
+ u32 saveDPFC_CB_BASE;
u32 saveFBC_CFB_BASE;
u32 saveFBC_LL_BASE;
u32 saveFBC_CONTROL;
diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c
index bd6d8d9..660c5f3 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -437,10 +437,14 @@ void i915_save_display(struct drm_device *dev)
/* FIXME: save TV & SDVO state */
/* FBC state */
- dev_priv->saveFBC_CFB_BASE = I915_READ(FBC_CFB_BASE);
- dev_priv->saveFBC_LL_BASE = I915_READ(FBC_LL_BASE);
- dev_priv->saveFBC_CONTROL2 = I915_READ(FBC_CONTROL2);
- dev_priv->saveFBC_CONTROL = I915_READ(FBC_CONTROL);
+ if (IS_GM45(dev)) {
+ dev_priv->saveDPFC_CB_BASE = I915_READ(DPFC_CB_BASE);
+ } else {
+ dev_priv->saveFBC_CFB_BASE = I915_READ(FBC_CFB_BASE);
+ dev_priv->saveFBC_LL_BASE = I915_READ(FBC_LL_BASE);
+ dev_priv->saveFBC_CONTROL2 = I915_READ(FBC_CONTROL2);
+ dev_priv->saveFBC_CONTROL = I915_READ(FBC_CONTROL);
+ }
/* VGA state */
dev_priv->saveVGA0 = I915_READ(VGA0);
@@ -511,10 +515,16 @@ void i915_restore_display(struct drm_device *dev)
/* FIXME: restore TV & SDVO state */
/* FBC info */
- I915_WRITE(FBC_CFB_BASE, dev_priv->saveFBC_CFB_BASE);
- I915_WRITE(FBC_LL_BASE, dev_priv->saveFBC_LL_BASE);
- I915_WRITE(FBC_CONTROL2, dev_priv->saveFBC_CONTROL2);
- I915_WRITE(FBC_CONTROL, dev_priv->saveFBC_CONTROL);
+ if (IS_GM45(dev)) {
+ g4x_disable_fbc(dev);
+ I915_WRITE(DPFC_CB_BASE, dev_priv->saveDPFC_CB_BASE);
+ } else ...On Fri, 02 Oct 2009 18:40:27 -0400 Can you give this patch a try? It seems to work for Keith at least, and it sounds like he was seeing the same problem. -- 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 0466ddb..3bef091 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1791,6 +1791,7 @@ #define DSPFW1 0x70034 #define DSPFW2 0x70038 +#define G4X_FBC_WM_EN (1<<31) /* GM45+ only */ #define DSPFW3 0x7003c #define IGD_SELF_REFRESH_EN (1<<30) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7a5fb79..be1fb2b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1061,6 +1061,9 @@ static void g4x_enable_fbc(struct drm_crtc *crtc, unsigned long interval) (interval << DPFC_RECOMP_TIMER_COUNT_SHIFT)); I915_WRITE(DPFC_FENCE_YOFF, crtc->y); + /* Use FBC watermark calculations */ + I915_WRITE(DSPFW2, I915_READ(DSPFW2) | G4X_FBC_WM_EN); + /* enable it... */ I915_WRITE(DPFC_CONTROL, I915_READ(DPFC_CONTROL) | DPFC_CTL_EN); @@ -1078,6 +1081,8 @@ void g4x_disable_fbc(struct drm_device *dev) I915_WRITE(DPFC_CONTROL, dpfc_ctl); intel_wait_for_vblank(dev); + I915_WRITE(DSPFW2, I915_READ(DSPFW2) & ~G4X_FBC_WM_EN); + DRM_DEBUG("disabled FBC\n"); } --
Nope, unfortunately, it's not helping on my T400 laptop. I'm still
getting huge amounts of glitching and tearing with this patch applied
against -rc3.
What I'm using for now to fix up my system is this patch.
- Ted
commit 4e3166295914308c5a5910a93dec5596c94c5128
Author: Theodore Ts'o <tytso@mit.edu>
Date: Fri Oct 2 21:35:06 2009 -0400
Revert "drm/i915: framebuffer compression for GM45+"
This reverts commit 74dff282237ea8c0a5df1afd8526eac4b6cee063.
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 45d507e..560ddea 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1126,47 +1126,34 @@ static void i915_setup_compression(struct drm_device *dev, int size)
return;
}
- cfb_base = i915_gtt_to_phys(dev, compressed_fb->start);
- if (!cfb_base) {
- DRM_ERROR("failed to get stolen phys addr, disabling FBC\n");
- drm_mm_put_block(compressed_fb);
+ compressed_llb = drm_mm_search_free(&dev_priv->vram, 4096, 4096, 0);
+ if (!compressed_llb) {
+ i915_warn_stolen(dev);
+ return;
}
- if (!IS_GM45(dev)) {
- compressed_llb = drm_mm_search_free(&dev_priv->vram, 4096,
- 4096, 0);
- if (!compressed_llb) {
- i915_warn_stolen(dev);
- return;
- }
-
- compressed_llb = drm_mm_get_block(compressed_llb, 4096, 4096);
- if (!compressed_llb) {
- i915_warn_stolen(dev);
- return;
- }
-
- ll_base = i915_gtt_to_phys(dev, compressed_llb->start);
- if (!ll_base) {
- DRM_ERROR("failed to get stolen phys addr, disabling FBC\n");
- drm_mm_put_block(compressed_fb);
- drm_mm_put_block(compressed_llb);
- }
+ compressed_llb = drm_mm_get_block(compressed_llb, 4096, 4096);
+ if (!compressed_llb) {
+ i915_warn_stolen(dev);
+ return;
}
dev_priv->cfb_size = size;
- if (IS_GM45(dev)) {
- g4x_disable_fbc(dev);
- I915_WRITE(DPFC_CB_BASE, compressed_fb->start);
- } else ...On Sat, 10 Oct 2009 16:41:06 -0400
How about this one? I have one more idea to try out if this doesn't
work (hacking on it now).
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 7a5fb79..1451945 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1047,7 +1047,7 @@ static void g4x_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
dev_priv->cfb_fence = obj_priv->fence_reg;
dev_priv->cfb_plane = intel_crtc->plane;
- dpfc_ctl = plane | DPFC_SR_EN | DPFC_CTL_LIMIT_1X;
+ dpfc_ctl = plane | DPFC_CTL_LIMIT_1X;
if (obj_priv->tiling_mode != I915_TILING_NONE) {
dpfc_ctl |= DPFC_CTL_FENCE_EN | dev_priv->cfb_fence;
I915_WRITE(DPFC_CHICKEN, DPFC_HT_MODIFY);
--
I was also experiencing something very similar to Theodore's bug report and, at least for me, the patch below fixed the issue (the --
On Mon, 12 Oct 2009 20:46:51 +0200
Cool, good to hear. Hopefully Ted and Keith will confirm too.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 7a5fb79..1451945 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1047,7 +1047,7 @@ static void g4x_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
dev_priv->cfb_fence = obj_priv->fence_reg;
dev_priv->cfb_plane = intel_crtc->plane;
- dpfc_ctl = plane | DPFC_SR_EN | DPFC_CTL_LIMIT_1X;
+ dpfc_ctl = plane | DPFC_CTL_LIMIT_1X;
if (obj_priv->tiling_mode != I915_TILING_NONE) {
dpfc_ctl |= DPFC_CTL_FENCE_EN | dev_priv->cfb_fence;
I915_WRITE(DPFC_CHICKEN, DPFC_HT_MODIFY);
--
Hmm, the amount of tearing seems to be a bit less frequent, but it's definitely still happening with this patch applied. Sorry.... --
On Mon, 12 Oct 2009 22:31:46 -0400 Arg, I'm running out of ideas... How about this hack? I'll chat with the chipset guys to see if we can figure out what's going on here... -- 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 0466ddb..d5ec112 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -352,13 +352,24 @@ #define FBC_LL_SIZE (1536) -/* Framebuffer compression for GM45+ */ +/* + * Framebuffer compression for GM45+ + * + * GM45+ support tracking of a back buffer for use with page flipping. + * In this case, the "persistent" bit should be set and both nuke disable + * bits should be set as well. The back buffer is tracked by setting the + * HT fence bit in the chicken bit reg and pointing the CPU fence at the + * back buffer for tracking. + */ #define DPFC_CB_BASE 0x3200 #define DPFC_CONTROL 0x3208 #define DPFC_CTL_EN (1<<31) #define DPFC_CTL_PLANEA (0<<30) #define DPFC_CTL_PLANEB (1<<30) #define DPFC_CTL_FENCE_EN (1<<29) +#define DPFC_CTL_CSNUKE_DIS (1<<27) +#define DPFC_CTL_MMIONUKE_DIS (1<<26) +#define DPFC_CTL_PERSISTENT (1<<25) #define DPFC_SR_EN (1<<10) #define DPFC_CTL_LIMIT_1X (0<<6) #define DPFC_CTL_LIMIT_2X (1<<6) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7a5fb79..ea808a9 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2441,6 +2441,8 @@ static void g4x_update_wm(struct drm_device *dev, int unused, int unused2, else fw_blc_self &= ~FW_BLC_SELF_EN; I915_WRITE(FW_BLC_SELF, fw_blc_self); + I915_WRITE(DSPFW1, (8 << 23) | (8 << 16) | (8 << 8) | (8 << 0)); + I915_WRITE(DSPFW2, (1 << 31) | (8 << 28) | (8 << 8) | (8 << 0)); } static void i965_update_wm(struct drm_device *dev, int unused, int unused2, --
Thanks, should I apply this on top of your previous patch, or on a completely virgin 2.6.32-rc3 tree? I don't know if this helps, but the amount of tearing seems to be roughly proportional to how many "white" pixels are on the screen. There isn't much tearing if I just have my (brown) Ubuntu 9.04 default background image. There is a bit more tearing on the virtual desktop once I open an 80x52 black-on-white gnome-terminal window, so that 45% of my widescreen has white pixels due to the backgrouin of the gnome-terminal. On the virtual desktop where my firefox browser is opened, the tearing/glitching is much more frequent. And where the tearing/glitching is seems to be be roughly related to where the mouse cursor happens to be. (Usually starting at the horizontol row of pixels where the mouse is going down towards the bottom of the screen; although sometimes if the mouse is very close to the bottom of the screen, there is some tearing at the top of the screen as well.) Does this description help at all? Would a video clip of the tearing/glitching be useful? - Ted --
On Tue, 13 Oct 2009 15:00:55 -0400 Either way should be fine, since the previous patches don't appear to Thanks for the description, it matches what I've seen on Eric and Ian's machines, though I can't reproduce it myself. According to the chipset team that form of display corruption is likely related to RAM self-refresh... Sounds like the display plane isn't getting its memory requests serviced fast enough when in self-refresh mode, which might mean we have to program the self-refresh watermarks more aggressively on GM45. -- Jesse Barnes, Intel Open Source Technology Center --
On Tue, 13 Oct 2009 12:14:26 -0700
Ok, like any good bug there was more than one thing wrong:
- we weren't setting up a fence for the object before enabling FBC.
Chris caught this and posted a patch to
intel-gfx@lists.freedesktop.org titled "drm/i915: Install a fence
register for fbc on g4x" (attached for convenience)
- turns out we *do* need to set watermarks on G4x, despite some hw
documentation indicating otherwise, patch for that attached
Hopefully with these two you'll have a solid display and some power
saving!
--
Jesse Barnes, Intel Open Source Technology Center
With these two patches (and none of your prior ones) applied to 2.6.32-rc3, things are definitely better. I'm still seeing a few glitches (one as mutt was loading my Maildir inbox) and one as I was typing this message in emacs, but it's at best one minor every 5-10 minutes. It's rare enough to be at most a wee bit distracting (*lots* better than before), and I can see the power savings. If I need to live with a display glitch every 5-10 minutes or so to get better power savings, I'll take it.... - Ted --
While mail reading and composing responses in a tty based mail reader (mutt/emacs -nw), I'm seeing display glitches every 3-5 minutes. Each time it's quite minor so it's the sort of thing which is definitely "blink at the wrong time and you'll miss it". Being a battery lifetime freak, I'll definitely take the tradeoff, but given that it occurs even when I'm plugged into AC mains, I could see some users being annoyed by it, and I could see them wanting to be able to switch off the feature when they are on AC, if we find a complete fix. - Ted --
On Thu, 15 Oct 2009 00:02:04 -0400 Ok, hopefully this is the "correct" patch. It works for me, can you give it a try? Thanks, Jesse From d645f010b1089b324c7bbf70b424334365867c56 Mon Sep 17 00:00:00 2001 From: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon, 19 Oct 2009 09:52:15 +0900 Subject: [PATCH] drm/i915: add FIFO watermark support for G4x Turns out G4x needs to have sensible watermarks set, especially for self-refresh enabled modes. Add support for it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/gpu/drm/i915/i915_reg.h | 25 ++++++++++- drivers/gpu/drm/i915/intel_display.c | 85 +++++++++++++++++++++++++++++---- 2 files changed, 98 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 0466ddb..b0c4996 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -352,13 +352,24 @@ #define FBC_LL_SIZE (1536) -/* Framebuffer compression for GM45+ */ +/* + * Framebuffer compression for GM45+ + * + * GM45+ support tracking of a back buffer for use with page flipping. + * In this case, the "persistent" bit should be set and both nuke disable + * bits should be set as well. The back buffer is tracked by setting the + * HT fence bit in the chicken bit reg and pointing the CPU fence at the + * back buffer for tracking. + */ #define DPFC_CB_BASE 0x3200 #define DPFC_CONTROL 0x3208 #define DPFC_CTL_EN (1<<31) #define DPFC_CTL_PLANEA (0<<30) #define DPFC_CTL_PLANEB (1<<30) #define DPFC_CTL_FENCE_EN (1<<29) +#define DPFC_CTL_CSNUKE_DIS (1<<27) +#define DPFC_CTL_MMIONUKE_DIS (1<<26) +#define DPFC_CTL_PERSISTENT (1<<25) #define DPFC_SR_EN (1<<10) #define DPFC_CTL_LIMIT_1X (0<<6) #define DPFC_CTL_LIMIT_2X (1<<6) @@ -1790,17 +1801,29 @@ #define DSPARB_AEND_SHIFT 0 #define DSPFW1 0x70034 +#define DSPFW_SR_SHIFT 23 +#define DSPFW_CURSORB_SHIFT 16 +#define DSPFW_PLANEB_SHIFT 8 #define ...
On Mon, 19 Oct 2009 10:04:37 +0900 Here's an even more "final" patchset with some spurious hunks removed. Thanks, Jesse
This seems to work for me, thanks!!! - Ted --
Hello, On Mon, 19 Oct 2009 10:15:26 +0900 This is also fixing the problem I had with my Vostro !:) Thanks Frans for pointing my to this patches. Tested-By: Paul Rolland <rol@as2917.net> Regards, Paul --
These patches solve the problems with severe screen flickering I experienced on a "Mobile 4 Series Chipset" (rev07) and bisected down to the "drm/i915: framebuffer compression for GM45+" commit (74dff282237). The flickering was most easily triggered by closing and opening the lid, and was reduced or temporarily stopped by moving the mouse or pressing a key. Tested-by: Johan Hovold <jhovold@gmail.com> Thanks, Johan --
On Wed, 14 Oct 2009 22:26:45 -0400 Oh I think we can do better than that. The hardcoded values I put in for the watermarks are almost certainly wrong. I should be able to reproduce what you're seeing (anything that takes a lot of memory bandwidth will probably cause flicker) and adjust the watermarks to the correct values to avoid that. I'll try to find time in Japan to do that... -- Jesse Barnes, Intel Open Source Technology Center --
So the first patch plus this second patch actually made things *worse* on the T400. I'll try adding the 3rd patch now. - Ted --
Hi Jesse. Sorry to jump in but I also had issues with -32rc (i915 chip) and this patch seems to have resolved all problems. I don't know how to describe in english what happened to my desktop but probably "glitches" and "tearings" could be the correct words. Also sometimes the screen went blank and needed to switch to terminal console and back to return to the normal X screen. Nothing in the logs, neither messages nor Xorg.0.log. Regards, Fabio --
The patch below should have only affected GM45 chipsets, what chipset do you have (lspci -vvv -s 02.0 should tell you). Sounds like this patch was good enough for both you and Carlos, but not sufficient for Ted or Keith. What resolution are you running? Jesse On Tue, 13 Oct 2009 21:19:32 +0200 -- Jesse Barnes, Intel Open Source Technology Center --
Hi. Very strange because it's a 915: 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 82d9 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f7f00000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at ec00 [size=8] Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M] Region 3: Memory at f7ec0000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at <unassigned> [disabled] Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- It's an Asus eeePC 900 @ 1024x600 BTW, the patch really helps, usually I experienced problems after 3/4 minutes of work and sometimes I couldn't recover form the blank screen. Now it's more than 1h 30' I'm at the laptop and everything is Regards, --