Bug 47271

Could you please attach the following items:
- output of the 'dmesg' command
- output of the 'lspci -v' command
- output of the 'xrandr --verbose' command
- version of the xf86-video-intel package
- /var/log/Xorg.0.log file
- a picture of how the display is shifted

please?

Also, additionally, could you please attach the output of 'intel_reg_dumper' application from the http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ package with both working and non-working vbios version?

Created attachment 58414 [details]
offset log and picture

Attached is the dmesg, lspci -v, xrandr --verbose information and /var/log/Xorg.0.log

But there is no xf86-video-intel package

It will be OK after S3 resume.

(In reply to comment #4)
> It will be OK after S3 resume.

Then please do the following:
- follow Eugeni's request on comment #2
- then, also get the output of intel_reg_dumper on the new bios after S3 resume.

This way we can compare the "working old bios", the "new bios in a non-working state" and the "new bios in a working state".

http://intellinuxgraphics.org/intel_reg_dumper.html

Dear Paulo Zanoni,

I can't compile the intel-gpu-tools-1.1 successfully.it need libdrm-intel >= 2.4.23 libdrm, but I can't find the libdrm-intel package, but only libdrm package.

Could you provide libdrm-intel >= 2.4.23  package? 

We base on Fedora 16, or could you provide the binary tools/intel_reg_dumper?

Thanks!!

Created attachment 58514 [details]
intel_reg_dumper

OK, I compiled the tools, please help to check.

intel_reg_dumper.after.s3.txt  (It is OK after S3 with new vbios)
intel_reg_dumper.before.s3.txt  (new vbios Fail)
intel_reg_dumper.old.vbios.txt  (old vbios OK)

In both cases, this part of the diff seems to be the important part:

--- intel_reg_dumper.before.s3.txt      2012-03-15 15:41:11.000000000 +0100
+++ intel_reg_dumper.after.s3.txt       2012-03-15 15:41:11.000000000 +0100
@@ -11,7 +11,7 @@
        DISPLAY_PORT_PLL_BIOS_1: 0x00000000
        DISPLAY_PORT_PLL_BIOS_2: 0x00000000
               FDI_PLL_FREQ_CTL: 0x00000000
-                     PIPEACONF: 0xd8000050 (enabled, active, 6bpc)
+                     PIPEACONF: 0xc0000050 (enabled, active, 6bpc)
                       HTOTAL_A: 0x06170555 (1366 active, 1560 total)
                       HBLANK_A: 0x06170555 (1366 start, 1560 end)
                        HSYNC_A: 0x05b50574 (1397 start, 1462 end)

Ah. The bios leaves the pipeconf in a debug setup:

"Frame_Start_Delay(Debug):

Used to delay the frame start signal that is sent to the display planes.  Care must be taken to insure that there are enough lines during VBLANK to support this setting."

And of course, we expect a sane register configuration during modesetting. Lets see if by clearing this field everything works again...

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f59cd3a..e65fb20 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2385,6 +2385,7 @@
 #define   PIPECONF_DISABLE	0
 #define   PIPECONF_DOUBLE_WIDE	(1<<30)
 #define   I965_PIPECONF_ACTIVE	(1<<30)
+#define   PIPECONF_FRAME_START_DELAY_MASK (3<<27)
 #define   PIPECONF_SINGLE_WIDE	0
 #define   PIPECONF_PIPE_UNLOCKED 0
 #define   PIPECONF_PIPE_LOCKED	(1<<25)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 2942e02..7ea5d4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7673,6 +7673,12 @@ static void intel_sanitize_modesetting(struct drm_device *dev,
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	u32 reg, val;
 
+	/* Clear any frame start delays used for debugging left by the BIOS */
+	for_each_pipe(pipe) {
+		reg = PIPECONF(pipe);
+		I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
+	}
+
 	if (HAS_PCH_SPLIT(dev))
 		return;

Gosh, if you set the importance this high, I pretty much expect quicker turn-around for testing patches ...

HP has confirmed Chris's patch solves shift right and split screen bugs they had faced with 2132 VBIOS.

Dear Olivia,

好像他们有patch 可以解决了。

FYR.

Could you provide the patch to us, I will check at our side? Thanks!!

(In reply to comment #14)
> Could you provide the patch to us, I will check at our side? Thanks!!

See comment 10, or http://lists.freedesktop.org/archives/intel-gfx/2012-March/015696.html

Dear Chris Wilson,

The patch is OK at VBIOS 2132.

Would this patch bring side effect at other version VBIOS?

Will new VBIOS fix this issue?

Thanks!!

> --- Comment #16 from EvaWang <evawang@linpus.com> 2012-03-31 22:29:58 PDT ---
> Would this patch bring side effect at other version VBIOS?

No, no side effects expected. We'll merge this patch into our -fixes tree,
from where it will get backported to older kernels.

commit f47166d2b0001fcb752b40c5a2d4db986dfbea6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Mar 22 15:00:50 2012 +0000

    drm/i915: Sanitize BIOS debugging bits from PIPECONF
    
    Quoting the BSpec from time immemorial:
    
      PIPEACONF, bits 28:27: Frame Start Delay (Debug)
    
      Used to delay the frame start signal that is sent to the display planes.
      Care must be taken to insure that there are enough lines during VBLANK
      to support this setting.
    
    An instance of the BIOS leaving these bits set was found in the wild,
    where it caused our modesetting to go all squiffy and skewiff.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
    Reported-and-tested-by: Eva Wang <evawang@linpus.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
    Reported-and-tested-by: Carl Richell <carl@system76.com>
    Cc: stable@kernel.org
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Just to complement:
This wont be fixed on VBIOS. They VBIOS 2132 is setting Frame Start Delay in PIPE CONFIG to Fourth frame. That is causing this issue. However, this is needed to support DUAL RR LVDS.
This patch in the best solution.

A patch referencing this bug report has been merged in Linux v3.4-rc2:

commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Mar 22 15:00:50 2012 +0000

    drm/i915: Sanitize BIOS debugging bits from PIPECONF

A patch referencing a commit referencing this bug report has been merged in Linux v3.5-rc1:

commit a9dcf84b14ef4e9a609910367576995e6f32f3dc
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 13 22:29:25 2012 +0200

    drm/i915: don't clobber the pipe param in sanitize_modesetting