[bisected] offset display bug in i915

[bisected] offset display bug in i915

[Jon Masters]

Hi Chris,

The following patch that you recently committed breaks my ASUS Eee PC
1015PEM by causing the display to be offset by about 1 inch (a few
centimeters) when the mode is (re)set during boot. I previously posted
both photographs and video of the problem in another "PROBLEM" thread.

Here is the offending commit found through bisection:

219adae138513bae20b256f1946b9cb3b75ca05c is the first bad commit
commit 219adae138513bae20b256f1946b9cb3b75ca05c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Sep 16 23:05:10 2010 +0100

    drm/i915: Cache LVDS EDID
    
    We assume that the panel is permenantly connected and that the EDID
    data is consistent from boot, so simply cache the whole EDID for the
    panel.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I'll look at the patch. Either the EDID is *not* consistent (in which
case, why are we not seeing other bugs like this?) or there is something
specific to this system or panel used.

Jon.

Re: [Intel-gfx] [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 05:18 -0500, Jon Masters wrote:

> The following patch that you recently committed breaks my ASUS Eee PC
> 1015PEM by causing the display to be offset by about 1 inch (a few
> centimeters) when the mode is (re)set during boot. I previously posted
> both photographs and video of the problem in another "PROBLEM" thread.

Here's my bisection log, for the record.

git bisect start
# good: [f6f94e2ab1b33f0082ac22d71f66385a60d8157f] Linux 2.6.36
git bisect good f6f94e2ab1b33f0082ac22d71f66385a60d8157f
# bad: [c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4] Linux 2.6.37-rc1
git bisect bad c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4
# good: [33081adf8b89d5a716d7e1c60171768d39795b39] Merge branch
'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
git bisect good 33081adf8b89d5a716d7e1c60171768d39795b39
# bad: [00ebb6382b8d9c7c15b5f8ad230670d8161d38dd] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc
git bisect bad 00ebb6382b8d9c7c15b5f8ad230670d8161d38dd
# good: [520045db940a381d2bee1c1b2179f7921b40fb10] Merge branches
'upstream/xenfs' and 'upstream/core' of
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen
git bisect good 520045db940a381d2bee1c1b2179f7921b40fb10
# bad: [60ee6d5faf5f7920ba88b82c072864596f5b88af] ipmi: fix __init and
__exit attribute locations
git bisect bad 60ee6d5faf5f7920ba88b82c072864596f5b88af
# bad: [e6b46ee712b92db1cc2449cf4f65bc635366cad4] Merge branch
'drm-vmware-next' into drm-core-next
git bisect bad e6b46ee712b92db1cc2449cf4f65bc635366cad4
# good: [f7abfe8b281991c66406c42c1a6c6c9ee0daa0ff] drm/i915: Fix an
overlay regression from 7e7d76c
git bisect good f7abfe8b281991c66406c42c1a6c6c9ee0daa0ff
# bad: [9e0ae53404700f1e4ae1f33b0ff92948ae0e509d] drm/i915: Don't
overwrite the returned error-code
git bisect bad 9e0ae53404700f1e4ae1f33b0ff92948ae0e509d
# bad: [881f47b64723f4d697084533491a489e3e74b10f] drm/i915: add a new
BSD ring buffer for Sandybridge
git bisect bad 881f47b64723f4d697084533491a489e3e74b10f
# good: [f899fc64cda8569d0529452aafc0da31c042df2e] drm/i915: use GMBUS
to manage i2c links
git bisect good f899fc64cda8569d0529452aafc0da31c042df2e
# bad: [b84d5f0c22914d37d709add54c66e741c404fa56] drm/i915: Inline
i915_gem_ring_retire_request()
git bisect bad b84d5f0c22914d37d709add54c66e741c404fa56
# bad: [f49f0586191fe16140410db0a46d43bdc690d6af] drm/i915: Actually set
the reset bit in i965_reset.
git bisect bad f49f0586191fe16140410db0a46d43bdc690d6af
# bad: [219adae138513bae20b256f1946b9cb3b75ca05c] drm/i915: Cache LVDS
EDID
git bisect bad 219adae138513bae20b256f1946b9cb3b75ca05c
# good: [e9e5f8e8d373e72f5c39dafde1ce110fc7082118] Merge branch
'drm-intel-fixes' into HEAD
git bisect good e9e5f8e8d373e72f5c39dafde1ce110fc7082118

Jon.

Re: [bisected] offset display bug in i915

[Chris Wilson]

On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> Hi Chris,
> 
> The following patch that you recently committed breaks my ASUS Eee PC
> 1015PEM by causing the display to be offset by about 1 inch (a few
> centimeters) when the mode is (re)set during boot. I previously posted
> both photographs and video of the problem in another "PROBLEM" thread.

[snip]

> I'll look at the patch. Either the EDID is *not* consistent (in which
> case, why are we not seeing other bugs like this?) or there is something
> specific to this system or panel used.

Interesting. Or even downright bizarre! Can you disable the caching
(hopefully the patch is still revertible) and save the EDID
(/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to
dump the EDID every time we probe the LVDS if it has changed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 10:27 +0000, Chris Wilson wrote:
> On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> > Hi Chris,
> > 
> > The following patch that you recently committed breaks my ASUS Eee PC
> > 1015PEM by causing the display to be offset by about 1 inch (a few
> > centimeters) when the mode is (re)set during boot. I previously posted
> > both photographs and video of the problem in another "PROBLEM" thread.
> 
> [snip]
> 
> > I'll look at the patch. Either the EDID is *not* consistent (in which
> > case, why are we not seeing other bugs like this?) or there is something
> > specific to this system or panel used.
> 
> Interesting. Or even downright bizarre! Can you disable the caching
> (hopefully the patch is still revertible) and save the EDID
> (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to
> dump the EDID every time we probe the LVDS if it has changed.

Already onto it. It's 6am here so I'll sleep soon ;) but I just applied
the following patch and booted it/logged into X without the problem
(apologies if evolution corrupts it, I usually send patches with mutt):

>From c2fed0d864935603b1d71c71ae53d197f52e346f Mon Sep 17 00:00:00 2001
From: Jon Masters <jcm@jonmasters.org>
Date: Mon, 8 Nov 2010 05:39:42 -0500
Subject: [PATCH] drm/i915: revert LVDS EDID cacheing

The previous commit v2.6.36-rc5-173-g219adae changed the Intel i915
driver to cache the EDID result obtained from the panel, but in so
doing broke some systems by causing weird modesetting problems.

Signed-off-by: Jon Masters <jcm@jonmasters.org>
---
 drivers/gpu/drm/i915/intel_lvds.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index f1a6499..78153df 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -44,7 +44,7 @@
 struct intel_lvds {
 	struct intel_encoder base;
 
-	struct edid *edid;
+	bool edid_good;
 
 	int fitting_mode;
 	u32 pfit_control;
@@ -479,12 +479,14 @@ static int intel_lvds_get_modes(struct
drm_connector *connector)
 {
 	struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
 	struct drm_device *dev = connector->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct drm_display_mode *mode;
 
-	if (intel_lvds->edid) {
-		drm_mode_connector_update_edid_property(connector,
-							intel_lvds->edid);
-		return drm_add_edid_modes(connector, intel_lvds->edid);
+	if (intel_lvds->edid_good) {
+		int ret = intel_ddc_get_modes(connector,
+					      &dev_priv->gmbus[GMBUS_PORT_PANEL].adapter);
+		if (ret)
+			return ret;
 	}
 
 	mode = drm_mode_duplicate(dev, intel_lvds->fixed_mode);
@@ -937,10 +939,11 @@ void intel_lvds_init(struct drm_device *dev)
 	 * Attempt to get the fixed panel mode from DDC.  Assume that the
 	 * preferred mode is the right one.
 	 */
-	intel_lvds->edid = drm_get_edid(connector,
-					&dev_priv->gmbus[pin].adapter);
+	intel_lvds->edid_good = true;
+	if (!intel_ddc_get_modes(connector,
&dev_priv->gmbus[GMBUS_PORT_PANEL].adapter))
+		intel_lvds->edid_good = false;
 
-	if (!intel_lvds->edid) {
+	if (!intel_lvds->edid_good) {
 		/* Didn't get an EDID, so
 		 * Set wide sync ranges so we get all modes
 		 * handed to valid_mode for checking
-- 
1.7.3.2

Here is the EDID output after booting:

[jcm@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
0000010 141c 0301 1680 780d 860a 9426 5157 2790
0000020 4f21 0054 0000 0101 0101 0101 0101 0101
0000030 0101 0101 0101 1194 b000 5840 2019 2335
0000040 0045 81dc 0000 1900 1416 d800 5840 2026
0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
0000060 0000 0000 0000 0000 0000 0000 0000 fe00
0000070 0000 0000 0000 0000 0100 0000 0000 f200
0000080

Sounds like you are suggesting that I hack up the intel_lvds to just
printk the EDID when it is read? I can look at that, probably after
sleeping. Perhaps you can also send me a patch to get what you want? I'm
on IRC, and pingable later on today if you want me to try stuff.

Jon.

Re: [Intel-gfx] [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 05:54 -0500, Jon Masters wrote:

> Here is the EDID output after booting:
> 
> [jcm@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
> 0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
> 0000010 141c 0301 1680 780d 860a 9426 5157 2790
> 0000020 4f21 0054 0000 0101 0101 0101 0101 0101
> 0000030 0101 0101 0101 1194 b000 5840 2019 2335
> 0000040 0045 81dc 0000 1900 1416 d800 5840 2026
> 0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
> 0000060 0000 0000 0000 0000 0000 0000 0000 fe00
> 0000070 0000 0000 0000 0000 0100 0000 0000 f200
> 0000080

As I mentioned on IRC, I'm familiar with how I2C works electrically, and
therefore EDID implementation as a concept, but I am not really a
graphics hacker so I wasn't aware that you prefer edid-decode :)

Here is a decoded version of the output:

Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   22 64 e9 03 44 85 01 00 1c 14
version:         01 03
basic params:    80 16 0d 78 0a
chroma info:     86 26 94 57 51 90 27 21 4f 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    94 11 00 b0 40 58 19 20 35 23 45 00 dc 81 00 00 00 19
descriptor 2:    16 14 00 d8 40 58 26 20 5d 23 15 04 dc 81 00 00 00 00
descriptor 3:    00 00 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 4:    00 00 00 fe 00 00 00 00 00 00 00 00 00 01 00 00 00 00
extensions:      00
checksum:        f2

Manufacturer: HSD Model 3e9 Serial Number 99652
Made week 28 of 2010
EDID version: 1.3
Digital display
Maximum image size: 22 cm x 13 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 45.000 MHz, 220 mm x 129 mm
               1024 1077 1112 1200 hborder 0
                600  604  609  625 vborder 0
               -hsync -vsync
Detailed mode: Clock 51.420 MHz, 220 mm x 129 mm
               1024 1117 1152 1240 hborder 0
                600  617  622  638 vborder 0
               -hsync -vsync analog composite
ASCII string: ASCII string: Checksum: 0xf2
EDID block does NOT conform to EDID 1.3!
	Missing name descriptor
	Missing monitor ranges

If you send me a hacked up patch that dumps out whatever you want in the
kernel ringbugger, I'll build and run it for you. Presumably you are
expecting some of the reported geometry to vary, etc.

Here is the output from xrandr FWIW (but as I mentioned, this is
happening way before X gets its hands on the scene):

[jcm@monticello ~]$ xrandr --verbose
Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
LVDS1 connected 1024x600+0+0 (0x43) normal (normal left inverted right x
axis y axis) 220mm x 129mm
	Identifier: 0x41
	Timestamp:  337852
	Subpixel:   horizontal rgb
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       1
	CRTCs:      1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	EDID:
		00ffffffffffff002264e90344850100
		1c14010380160d780a86269457519027
		214f5400000001010101010101010101
		010101010101941100b0405819203523
		4500dc8100000019161400d840582620
		5d231504dc8100000000000000fe0000
		000000000000000000000000000000fe
		000000000000000000010000000000f2
	BACKLIGHT: 10 (0x0000000a)	range:  (0,10)
	Backlight: 10 (0x0000000a)	range:  (0,10)
	scaling mode:	Full aspect
		supported: None         Full         Center       Full aspect 
  1024x600 (0x43)   45.0MHz -HSync -VSync *current +preferred
        h: width  1024 start 1077 end 1112 total 1200 skew    0 clock
37.5KHz
        v: height  600 start  604 end  609 total  625           clock
60.0Hz
  1024x600 (0x44)   51.4MHz -HSync -VSync
        h: width  1024 start 1117 end 1152 total 1240 skew    0 clock
41.5KHz
        v: height  600 start  601 end  606 total  638           clock
65.0Hz
  800x600 (0x45)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock
37.9KHz
        v: height  600 start  601 end  605 total  628           clock
60.3Hz
  800x600 (0x46)   36.0MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock
35.2KHz
        v: height  600 start  601 end  603 total  625           clock
56.2Hz
  640x480 (0x47)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock
31.5KHz
        v: height  480 start  490 end  492 total  525           clock
59.9Hz
VGA1 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x42
	Timestamp:  337852
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 

Jon.

Re: [Intel-gfx] [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> On Mon, 2010-11-08 at 05:54 -0500, Jon Masters wrote:
> 
> > Here is the EDID output after booting:
> > 
> > [jcm@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
> > 0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
> > 0000010 141c 0301 1680 780d 860a 9426 5157 2790
> > 0000020 4f21 0054 0000 0101 0101 0101 0101 0101
> > 0000030 0101 0101 0101 1194 b000 5840 2019 2335
> > 0000040 0045 81dc 0000 1900 1416 d800 5840 2026
> > 0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
> > 0000060 0000 0000 0000 0000 0000 0000 0000 fe00
> > 0000070 0000 0000 0000 0000 0100 0000 0000 f200
> > 0000080
> 
> As I mentioned on IRC, I'm familiar with how I2C works electrically, and
> therefore EDID implementation as a concept, but I am not really a
> graphics hacker so I wasn't aware that you prefer edid-decode :)
> 
> Here is a decoded version of the output:

And here is an old file I had with the output when running a broken
kernel with the cacheing enabled:

Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
LVDS1 connected 1024x600+0+0 (0x43) normal (normal left inverted right x
axis y axis) 220mm x 129mm
	Identifier: 0x41
	Timestamp:  1402374
	Subpixel:   horizontal rgb
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       1
	CRTCs:      1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	EDID:
		00ffffffffffff002264e90344850100
		1c14010380160d780a86269457519027
		214f5400000001010101010101010101
		010101010101941100b0405819203523
		4500dc8100000019161400d840582620
		5d231504dc8100000000000000fe0000
		000000000000000000000000000000fe
		000000000000000000010000000000f2
	BACKLIGHT: 10 (0x0000000a)	range:  (0,10)
	Backlight: 10 (0x0000000a)	range:  (0,10)
	scaling mode:	Full aspect
		supported: None         Full         Center       Full aspect 
  1024x600 (0x43)   45.0MHz -HSync -VSync *current +preferred
        h: width  1024 start 1077 end 1112 total 1200 skew    0 clock
37.5KHz
        v: height  600 start  604 end  609 total  625           clock
60.0Hz
  1024x600 (0x44)   51.4MHz -HSync -VSync
        h: width  1024 start 1117 end 1152 total 1240 skew    0 clock
41.5KHz
        v: height  600 start  601 end  606 total  638           clock
65.0Hz
  800x600 (0x45)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock
37.9KHz
        v: height  600 start  601 end  605 total  628           clock
60.3Hz
  800x600 (0x46)   36.0MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock
35.2KHz
        v: height  600 start  601 end  603 total  625           clock
56.2Hz
  640x480 (0x47)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock
31.5KHz
        v: height  480 start  490 end  492 total  525           clock
59.9Hz
VGA1 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x42
	Timestamp:  1402374
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 

Jon.

Re: [Intel-gfx] [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 06:29 -0500, Jon Masters wrote:
> On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> > On Mon, 2010-11-08 at 05:54 -0500, Jon Masters wrote:
> > 
> > > Here is the EDID output after booting:
> > > 
> > > [jcm@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
> > > 0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
> > > 0000010 141c 0301 1680 780d 860a 9426 5157 2790
> > > 0000020 4f21 0054 0000 0101 0101 0101 0101 0101
> > > 0000030 0101 0101 0101 1194 b000 5840 2019 2335
> > > 0000040 0045 81dc 0000 1900 1416 d800 5840 2026
> > > 0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
> > > 0000060 0000 0000 0000 0000 0000 0000 0000 fe00
> > > 0000070 0000 0000 0000 0000 0100 0000 0000 f200
> > > 0000080
> > 
> > As I mentioned on IRC, I'm familiar with how I2C works electrically, and
> > therefore EDID implementation as a concept, but I am not really a
> > graphics hacker so I wasn't aware that you prefer edid-decode :)
> > 
> > Here is a decoded version of the output:
> 
> And here is an old file I had with the output when running a broken
> kernel with the cacheing enabled:
> 
> Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
> LVDS1 connected 1024x600+0+0 (0x43) normal (normal left inverted right x
> axis y axis) 220mm x 129mm
> 	Identifier: 0x41
> 	Timestamp:  1402374
> 	Subpixel:   horizontal rgb
> 	Gamma:      1.0:1.0:1.0
> 	Brightness: 1.0
> 	Clones:    
> 	CRTC:       1
> 	CRTCs:      1
> 	Transform:  1.000000 0.000000 0.000000
> 	            0.000000 1.000000 0.000000
> 	            0.000000 0.000000 1.000000
> 	           filter: 
> 	EDID:
> 		00ffffffffffff002264e90344850100
> 		1c14010380160d780a86269457519027
> 		214f5400000001010101010101010101
> 		010101010101941100b0405819203523
> 		4500dc8100000019161400d840582620
> 		5d231504dc8100000000000000fe0000
> 		000000000000000000000000000000fe
> 		000000000000000000010000000000f2
> 	BACKLIGHT: 10 (0x0000000a)	range:  (0,10)
> 	Backlight: 10 (0x0000000a)	range:  (0,10)
> 	scaling mode:	Full aspect
> 		supported: None         Full         Center       Full aspect 
>   1024x600 (0x43)   45.0MHz -HSync -VSync *current +preferred
>         h: width  1024 start 1077 end 1112 total 1200 skew    0 clock
> 37.5KHz
>         v: height  600 start  604 end  609 total  625           clock
> 60.0Hz
>   1024x600 (0x44)   51.4MHz -HSync -VSync
>         h: width  1024 start 1117 end 1152 total 1240 skew    0 clock
> 41.5KHz
>         v: height  600 start  601 end  606 total  638           clock
> 65.0Hz
>   800x600 (0x45)   40.0MHz +HSync +VSync
>         h: width   800 start  840 end  968 total 1056 skew    0 clock
> 37.9KHz
>         v: height  600 start  601 end  605 total  628           clock
> 60.3Hz
>   800x600 (0x46)   36.0MHz +HSync +VSync
>         h: width   800 start  824 end  896 total 1024 skew    0 clock
> 35.2KHz
>         v: height  600 start  601 end  603 total  625           clock
> 56.2Hz
>   640x480 (0x47)   25.2MHz -HSync -VSync
>         h: width   640 start  656 end  752 total  800 skew    0 clock
> 31.5KHz
>         v: height  480 start  490 end  492 total  525           clock
> 59.9Hz
> VGA1 disconnected (normal left inverted right x axis y axis)
> 	Identifier: 0x42
> 	Timestamp:  1402374
> 	Subpixel:   unknown
> 	Clones:    
> 	CRTCs:      0 1
> 	Transform:  1.000000 0.000000 0.000000
> 	            0.000000 1.000000 0.000000
> 	            0.000000 0.000000 1.000000
> 	           filter: 

FWIW I don't recall seeing any reported difference in xrandr. I think
what I need is a hacked up debug patch if you can spin me one. Night!

Jon.

Re: [Intel-gfx] [bisected] offset display bug in i915

[Chris Wilson]

On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> > As I mentioned on IRC, I'm familiar with how I2C works electrically, and
> > therefore EDID implementation as a concept, but I am not really a
> > graphics hacker so I wasn't aware that you prefer edid-decode :)
> > 
> > Here is a decoded version of the output:
> 
> And here is an old file I had with the output when running a broken
> kernel with the cacheing enabled:

They look to be identical. So it is not necessarily the caching that is
the issue, but that we now no longer do an essential step whilst bringing
up the lvds. Can you just check that the reported EDIDs are the same for
when it is behaving correctly and when the display is offset?

The secondary change in the commit was to use drm_get_edid() directly
during device detection which delayed setting the EDID property on the
connection until get_modes(). Does this make a difference?

diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds
index f1a6499..17bcb7d 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -940,7 +940,10 @@ void intel_lvds_init(struct drm_device *dev)
        intel_lvds->edid = drm_get_edid(connector,
                                        &dev_priv->gmbus[pin].adapter);
 
-       if (!intel_lvds->edid) {
+       if (intel_lvds->edid) {
+               drm_mode_connector_update_edid_property(connector,
+                                                       intel_lvds->edid);
+       } else {

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 12:13 +0000, Chris Wilson wrote:
> On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> > On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> > > As I mentioned on IRC, I'm familiar with how I2C works electrically, and
> > > therefore EDID implementation as a concept, but I am not really a
> > > graphics hacker so I wasn't aware that you prefer edid-decode :)
> > > 
> > > Here is a decoded version of the output:
> > 
> > And here is an old file I had with the output when running a broken
> > kernel with the cacheing enabled:
> 
> They look to be identical. So it is not necessarily the caching that is
> the issue, but that we now no longer do an essential step whilst bringing
> up the lvds. Can you just check that the reported EDIDs are the same for
> when it is behaving correctly and when the display is offset?

diff says they are the same. Here's the output from a broken kernel:

$ cat edid_broken_hexdump.txt 
0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
0000010 141c 0301 1680 780d 860a 9426 5157 2790
0000020 4f21 0054 0000 0101 0101 0101 0101 0101
0000030 0101 0101 0101 1194 b000 5840 2019 2335
0000040 0045 81dc 0000 1900 1416 d800 5840 2026
0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
0000060 0000 0000 0000 0000 0000 0000 0000 fe00
0000070 0000 0000 0000 0000 0100 0000 0000 f200
0000080

$ cat edid_broken_decode.txt
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   22 64 e9 03 44 85 01 00 1c 14
version:         01 03
basic params:    80 16 0d 78 0a
chroma info:     86 26 94 57 51 90 27 21 4f 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    94 11 00 b0 40 58 19 20 35 23 45 00 dc 81 00 00 00 19
descriptor 2:    16 14 00 d8 40 58 26 20 5d 23 15 04 dc 81 00 00 00 00
descriptor 3:    00 00 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 4:    00 00 00 fe 00 00 00 00 00 00 00 00 00 01 00 00 00 00
extensions:      00
checksum:        f2

Manufacturer: HSD Model 3e9 Serial Number 99652
Made week 28 of 2010
EDID version: 1.3
Digital display
Maximum image size: 22 cm x 13 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 45.000 MHz, 220 mm x 129 mm
               1024 1077 1112 1200 hborder 0
                600  604  609  625 vborder 0
               -hsync -vsync
Detailed mode: Clock 51.420 MHz, 220 mm x 129 mm
               1024 1117 1152 1240 hborder 0
                600  617  622  638 vborder 0
               -hsync -vsync analog composite
ASCII string: ASCII string: Checksum: 0xf2
EDID block does NOT conform to EDID 1.3!
	Missing name descriptor
	Missing monitor ranges

> The secondary change in the commit was to use drm_get_edid() directly
> during device detection which delayed setting the EDID property on the
> connection until get_modes(). Does this make a difference?
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds
> index f1a6499..17bcb7d 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -940,7 +940,10 @@ void intel_lvds_init(struct drm_device *dev)
>         intel_lvds->edid = drm_get_edid(connector,
>                                         &dev_priv->gmbus[pin].adapter);
>  
> -       if (!intel_lvds->edid) {
> +       if (intel_lvds->edid) {
> +               drm_mode_connector_update_edid_property(connector,
> +                                                       intel_lvds->edid);
> +       } else {

Nope. This makes no difference at all. Got anything else up your sleeve?

Jon.

Re: [Intel-gfx] [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 12:13 +0000, Chris Wilson wrote:
> On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> > On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> > > As I mentioned on IRC, I'm familiar with how I2C works electrically, and
> > > therefore EDID implementation as a concept, but I am not really a
> > > graphics hacker so I wasn't aware that you prefer edid-decode :)
> > > 
> > > Here is a decoded version of the output:
> > 
> > And here is an old file I had with the output when running a broken
> > kernel with the cacheing enabled:
> 
> They look to be identical. So it is not necessarily the caching that is
> the issue, but that we now no longer do an essential step whilst bringing
> up the lvds. Can you just check that the reported EDIDs are the same for
> when it is behaving correctly and when the display is offset?
> 
> The secondary change in the commit was to use drm_get_edid() directly
> during device detection which delayed setting the EDID property on the
> connection until get_modes(). Does this make a difference?
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds
> index f1a6499..17bcb7d 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -940,7 +940,10 @@ void intel_lvds_init(struct drm_device *dev)
>         intel_lvds->edid = drm_get_edid(connector,
>                                         &dev_priv->gmbus[pin].adapter);
>  
> -       if (!intel_lvds->edid) {
> +       if (intel_lvds->edid) {
> +               drm_mode_connector_update_edid_property(connector,
> +                                                       intel_lvds->edid);
> +       } else {

I tried this, which didn't work. Then I added this (ignore stupid
evolution formatting - convenient for email backlog, but not mutt):

diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 17bcb7d..a0bb443 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -462,6 +462,14 @@ intel_lvds_detect(struct drm_connector *connector,
bool force)
 {
        struct drm_device *dev = connector->dev;
        enum drm_connector_status status = connector_status_connected;
+       /* JCM - added this */
+       struct drm_i915_private *dev_priv = dev->dev_private;
+       u8 pin = GMBUS_PORT_PANEL;
+       struct edid *edid = drm_get_edid(connector,
&dev_priv->gmbus[pin].adapter);
+
+       /* I was asked to free in here */
+       if (edid)
+               kfree(edid);
 
        /* ACPI lid methods were generally unreliable in this
generation, so
         * don't even bother.

Which should have made the edid always get freed on detect. That didn't
work either. I might wind up learning something about the DRM stack.

Anyway. Here's the reg dumper output. First, for a busticated kernel:

[jcm@constitution ~]$ cat intel_regs_broken.txt 
                 DCC: 0x00200020 (single channel, XOR randomization:
enabled, XOR bit: 11)
           CHDECMISC: 0x42000064 (XOR bank, ch2 enh disabled, ch1 enh
disabled, ch0 enh enabled, flex disabled, ep not present)
              C0DRB0: 0x00200020 (0x0020)
              C0DRB1: 0x00200020 (0x0020)
              C0DRB2: 0x00200020 (0x0020)
              C0DRB3: 0x00880020 (0x0020)
              C1DRB0: 0x00000000 (0x0000)
              C1DRB1: 0x00000000 (0x0000)
              C1DRB2: 0x00000000 (0x0000)
              C1DRB3: 0x00000000 (0x0000)
             C0DRA01: 0x00000088 (0x0088)
             C0DRA23: 0x00000000 (0x0000)
             C1DRA01: 0x00000000 (0x0000)
             C1DRA23: 0x00000000 (0x0000)
          PGETBL_CTL: 0x00000001
   VCLK_DIVISOR_VGA0: 0x00200074 (n = 32, m1 = 0, m2 = 52)
   VCLK_DIVISOR_VGA1: 0x00200074 (n = 32, m1 = 0, m2 = 52)
       VCLK_POST_DIV: 0x00800100 (vga0 p1 = 2, p2 = 2, vga1 p1 = 3, p2 =
2)
           DPLL_TEST: 0x00010001 ()
        CACHE_MODE_0: 0x00006820
             D_STATE: 0x0000000b
       DSPCLK_GATE_D: 0x00000000 (clock gates disabled:)
      RENCLK_GATE_D1: 0x00000000
      RENCLK_GATE_D2: 0x00000000
               SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not
detected)
               SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not
detected)
             SDVOUDI: 0x00000000
              DSPARB: 0x00001d9c
              DSPFW1: 0xf1830f0f
              DSPFW2: 0x0000030f
              DSPFW3: 0x6700018f
                ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync)
                LVDS: 0xc0308300 (enabled, pipe B, 18 bit, 1 channel)
                DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync,
-vsync)
                DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync,
-vsync)
                DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync,
-vsync)
         DVOA_SRCDIM: 0x00000000
         DVOB_SRCDIM: 0x00000000
         DVOC_SRCDIM: 0x00000000
          PP_CONTROL: 0x00000001 (power target: on)
           PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
        PP_ON_DELAYS: 0x025807d0
       PP_OFF_DELAYS: 0x01f407d0
          PP_DIVISOR: 0x00209d05
        PFIT_CONTROL: 0x00000008
     PFIT_PGM_RATIOS: 0x00000000
     PORT_HOTPLUG_EN: 0x00000220
   PORT_HOTPLUG_STAT: 0x00001000
            DSPACNTR: 0xd9000000 (enabled, pipe B)
          DSPASTRIDE: 0x00001000 (4096 bytes)
             DSPAPOS: 0x00000000 (0, 0)
            DSPASIZE: 0x025703ff (1024, 600)
            DSPABASE: 0x00830000
            DSPASURF: 0x00000000
         DSPATILEOFF: 0x00000000
           PIPEACONF: 0x00000000 (disabled, single-wide)
            PIPEASRC: 0x027f01df (640, 480)
           PIPEASTAT: 0x00000000 (status:)
   PIPEA_GMCH_DATA_M: 0x00000000
   PIPEA_GMCH_DATA_N: 0x00000000
     PIPEA_DP_LINK_M: 0x00000000
     PIPEA_DP_LINK_N: 0x00000000
       CURSOR_A_BASE: 0x00000000
    CURSOR_A_CONTROL: 0x00000000
   CURSOR_A_POSITION: 0x00000000
                FPA0: 0x00200074 (n = 32, m1 = 0, m2 = 52)
                FPA1: 0x00200074 (n = 32, m1 = 0, m2 = 52)
              DPLL_A: 0x04800000 (disabled, non-dvo, VGA, default clock,
DAC/serial mode, p1 = 9, p2 = 10, SDVO mult 1)
           DPLL_A_MD: 0x00000000
            HTOTAL_A: 0x031f027f (640 active, 800 total)
            HBLANK_A: 0x03170287 (648 start, 792 end)
             HSYNC_A: 0x02ef028f (656 start, 752 end)
            VTOTAL_A: 0x020c01df (480 active, 525 total)
            VBLANK_A: 0x020401e7 (488 start, 517 end)
             VSYNC_A: 0x01eb01e9 (490 start, 492 end)
           BCLRPAT_A: 0x00000000
        VSYNCSHIFT_A: 0x00000000
            DSPBCNTR: 0x49000000 (disabled, pipe B)
          DSPBSTRIDE: 0x00000280 (640 bytes)
             DSPBPOS: 0x00000000 (0, 0)
            DSPBSIZE: 0x018f02cf (720, 400)
            DSPBBASE: 0x00000000
            DSPBSURF: 0x00000000
         DSPBTILEOFF: 0x00000000
           PIPEBCONF: 0x80000000 (enabled, single-wide)
            PIPEBSRC: 0x03ff0257 (1024, 600)
           PIPEBSTAT: 0x00400202 (status: LBLC_EVENT_ENABLE
VSYNC_INT_STATUS VBLANK_INT_STATUS)
   PIPEB_GMCH_DATA_M: 0x00000000
   PIPEB_GMCH_DATA_N: 0x00000000
     PIPEB_DP_LINK_M: 0x00000000
     PIPEB_DP_LINK_N: 0x00000000
       CURSOR_B_BASE: 0x00000000
    CURSOR_B_CONTROL: 0x10000000
   CURSOR_B_POSITION: 0x012801f9
                FPB0: 0x0020008c (n = 32, m1 = 0, m2 = 12)
                FPB1: 0x0020008c (n = 32, m1 = 0, m2 = 12)
              DPLL_B: 0x98020000 (enabled, non-dvo, default clock, LVDS
mode, p1 = 3, p2 = 14, SDVO mult 1)
           DPLL_B_MD: 0x00000000
            HTOTAL_B: 0x053f03ff (1024 active, 1344 total)
            HBLANK_B: 0x053f03ff (1024 start, 1344 end)
             HSYNC_B: 0x049f0417 (1048 start, 1184 end)
            VTOTAL_B: 0x03250257 (600 active, 806 total)
            VBLANK_B: 0x02d102ab (684 start, 722 end)
             VSYNC_B: 0x02c102bb (700 start, 706 end)
           BCLRPAT_B: 0x00000000
        VSYNCSHIFT_B: 0x00000000
   VCLK_DIVISOR_VGA0: 0x00200074
   VCLK_DIVISOR_VGA1: 0x00200074
       VCLK_POST_DIV: 0x00800100
            VGACNTRL: 0x80000000 (disabled)
              TV_CTL: 0x00000000
              TV_DAC: 0x00000000
            TV_CSC_Y: 0x00000000
           TV_CSC_Y2: 0x00000000
            TV_CSC_U: 0x00000000
           TV_CSC_U2: 0x00000000
            TV_CSC_V: 0x00000000
           TV_CSC_V2: 0x00000000
        TV_CLR_KNOBS: 0x00000000
        TV_CLR_LEVEL: 0x00000000
          TV_H_CTL_1: 0x00000000
          TV_H_CTL_2: 0x00000000
          TV_H_CTL_3: 0x00000000
          TV_V_CTL_1: 0x00000000
          TV_V_CTL_2: 0x00000000
          TV_V_CTL_3: 0x00000000
          TV_V_CTL_4: 0x00000000
          TV_V_CTL_5: 0x00000000
          TV_V_CTL_6: 0x00000000
          TV_V_CTL_7: 0x00000000
         TV_SC_CTL_1: 0x00000000
         TV_SC_CTL_2: 0x00000000
         TV_SC_CTL_3: 0x00000000
          TV_WIN_POS: 0x00000000
         TV_WIN_SIZE: 0x00000000
     TV_FILTER_CTL_1: 0x00000000
     TV_FILTER_CTL_2: 0x00000000
     TV_FILTER_CTL_3: 0x00000000
       TV_CC_CONTROL: 0x00000000
          TV_CC_DATA: 0x00000000
         TV_H_LUMA_0: 0x00000000
        TV_H_LUMA_59: 0x00000000
       TV_H_CHROMA_0: 0x00000000
      TV_H_CHROMA_59: 0x00000000
        FBC_CFB_BASE: 0xffffffff
         FBC_LL_BASE: 0xffffffff
         FBC_CONTROL: 0xffffffff
         FBC_COMMAND: 0xffffffff
          FBC_STATUS: 0xffffffff
        FBC_CONTROL2: 0xffffffff
       FBC_FENCE_OFF: 0xffffffff
         FBC_MOD_NUM: 0xffffffff
             MI_MODE: 0x00000200
        MI_ARB_STATE: 0x00000840
      MI_RDRET_STATE: 0x00000000
             ECOSKPD: 0x00000307
                DP_B: 0x00000000
      DPB_AUX_CH_CTL: 0x00000000
    DPB_AUX_CH_DATA1: 0x00000000
    DPB_AUX_CH_DATA2: 0x00000000
    DPB_AUX_CH_DATA3: 0x00000000
    DPB_AUX_CH_DATA4: 0x00000000
    DPB_AUX_CH_DATA5: 0x00000000
                DP_C: 0x00000000
      DPC_AUX_CH_CTL: 0x00000000
    DPC_AUX_CH_DATA1: 0x00000000
    DPC_AUX_CH_DATA2: 0x00000000
    DPC_AUX_CH_DATA3: 0x00000000
    DPC_AUX_CH_DATA4: 0x00000000
    DPC_AUX_CH_DATA5: 0x00000000
                DP_D: 0x00000000
      DPD_AUX_CH_CTL: 0x00000000
    DPD_AUX_CH_DATA1: 0x00000000
    DPD_AUX_CH_DATA2: 0x00000000
    DPD_AUX_CH_DATA3: 0x00000000
    DPD_AUX_CH_DATA4: 0x00000000
    DPD_AUX_CH_DATA5: 0x00000000
          AUD_CONFIG: 0x00000000
    AUD_HDMIW_STATUS: 0x00000000
      AUD_CONV_CHCNT: 0x00000000
       VIDEO_DIP_CTL: 0x00000000
       AUD_PINW_CNTR: 0x00000000
         AUD_CNTL_ST: 0x00000000
         AUD_PIN_CAP: 0x00000000
        AUD_PINW_CAP: 0x00000000
  AUD_PINW_UNSOLRESP: 0x00000000
    AUD_OUT_DIG_CNVT: 0x00000000
       AUD_OUT_CWCAP: 0x00000000
         AUD_GRP_CAP: 0x00000000
            FENCE  0: 0x00c00231 (enabled, X tiled, 4096 pitch,
0x00c00000 - 0x01000000 (4096kb))
            FENCE  1: 0x01000231 (enabled, X tiled, 4096 pitch,
0x01000000 - 0x01400000 (4096kb))
            FENCE  2: 0x00000000 (disabled)
            FENCE  3: 0x00000000 (disabled)
            FENCE  4: 0x00000000 (disabled)
            FENCE  5: 0x00000000 (disabled)
            FENCE  6: 0x00000000 (disabled)
            FENCE  7: 0x00000000 (disabled)
            FENCE  8: 0x00000000 (disabled)
            FENCE  9: 0x00000000 (disabled)
           FENCE  10: 0x00000000 (disabled)
           FENCE  11: 0x00000000 (disabled)
           FENCE  12: 0x00000000 (disabled)
           FENCE  13: 0x00000000 (disabled)
           FENCE  14: 0x00000000 (disabled)
           FENCE  15: 0x00000000 (disabled)
             INST_PM: 0x00000000
pipe A dot 25173 n 5 m1 0 m2 116 p1 9 p2 10
pipe B dot 64914 n 5 m1 0 m2 140 p1 3 p2 14

And here for a non-busticated kernel:

[jcm@constitution ~]$ cat intel_regs_works.txt 
                 DCC: 0x00200020 (single channel, XOR randomization:
enabled, XOR bit: 11)
           CHDECMISC: 0x42000064 (XOR bank, ch2 enh disabled, ch1 enh
disabled, ch0 enh enabled, flex disabled, ep not present)
              C0DRB0: 0x00200020 (0x0020)
              C0DRB1: 0x00200020 (0x0020)
              C0DRB2: 0x00200020 (0x0020)
              C0DRB3: 0x00880020 (0x0020)
              C1DRB0: 0x00000000 (0x0000)
              C1DRB1: 0x00000000 (0x0000)
              C1DRB2: 0x00000000 (0x0000)
              C1DRB3: 0x00000000 (0x0000)
             C0DRA01: 0x00000088 (0x0088)
             C0DRA23: 0x00000000 (0x0000)
             C1DRA01: 0x00000000 (0x0000)
             C1DRA23: 0x00000000 (0x0000)
          PGETBL_CTL: 0x00000001
   VCLK_DIVISOR_VGA0: 0x00200074 (n = 32, m1 = 0, m2 = 52)
   VCLK_DIVISOR_VGA1: 0x00200074 (n = 32, m1 = 0, m2 = 52)
       VCLK_POST_DIV: 0x00800100 (vga0 p1 = 2, p2 = 2, vga1 p1 = 3, p2 =
2)
           DPLL_TEST: 0x00010001 ()
        CACHE_MODE_0: 0x00006820
             D_STATE: 0x0000000b
       DSPCLK_GATE_D: 0x00000000 (clock gates disabled:)
      RENCLK_GATE_D1: 0x00000000
      RENCLK_GATE_D2: 0x00000000
               SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not
detected)
               SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not
detected)
             SDVOUDI: 0x00000000
              DSPARB: 0x00001d9c
              DSPFW1: 0xf1830f0f
              DSPFW2: 0x0000030f
              DSPFW3: 0x6700018f
                ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync)
                LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel)
                DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync,
-vsync)
                DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync,
-vsync)
                DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync,
-vsync)
         DVOA_SRCDIM: 0x00000000
         DVOB_SRCDIM: 0x00000000
         DVOC_SRCDIM: 0x00000000
          PP_CONTROL: 0x00000001 (power target: on)
           PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
        PP_ON_DELAYS: 0x025807d0
       PP_OFF_DELAYS: 0x01f407d0
          PP_DIVISOR: 0x00209d05
        PFIT_CONTROL: 0x00000008
     PFIT_PGM_RATIOS: 0x00000000
     PORT_HOTPLUG_EN: 0x00000220
   PORT_HOTPLUG_STAT: 0x00001000
            DSPACNTR: 0xd9000000 (enabled, pipe B)
          DSPASTRIDE: 0x00001000 (4096 bytes)
             DSPAPOS: 0x00000000 (0, 0)
            DSPASIZE: 0x025703ff (1024, 600)
            DSPABASE: 0x00830000
            DSPASURF: 0x00000000
         DSPATILEOFF: 0x00000000
           PIPEACONF: 0x00000000 (disabled, single-wide)
            PIPEASRC: 0x027f01df (640, 480)
           PIPEASTAT: 0x00000000 (status:)
   PIPEA_GMCH_DATA_M: 0x00000000
   PIPEA_GMCH_DATA_N: 0x00000000
     PIPEA_DP_LINK_M: 0x00000000
     PIPEA_DP_LINK_N: 0x00000000
       CURSOR_A_BASE: 0x00000000
    CURSOR_A_CONTROL: 0x00000000
   CURSOR_A_POSITION: 0x00000000
                FPA0: 0x00200074 (n = 32, m1 = 0, m2 = 52)
                FPA1: 0x00200074 (n = 32, m1 = 0, m2 = 52)
              DPLL_A: 0x04800000 (disabled, non-dvo, VGA, default clock,
DAC/serial mode, p1 = 9, p2 = 10, SDVO mult 1)
           DPLL_A_MD: 0x00000000
            HTOTAL_A: 0x031f027f (640 active, 800 total)
            HBLANK_A: 0x03170287 (648 start, 792 end)
             HSYNC_A: 0x02ef028f (656 start, 752 end)
            VTOTAL_A: 0x020c01df (480 active, 525 total)
            VBLANK_A: 0x020401e7 (488 start, 517 end)
             VSYNC_A: 0x01eb01e9 (490 start, 492 end)
           BCLRPAT_A: 0x00000000
        VSYNCSHIFT_A: 0x00000000
            DSPBCNTR: 0x49000000 (disabled, pipe B)
          DSPBSTRIDE: 0x00000280 (640 bytes)
             DSPBPOS: 0x00000000 (0, 0)
            DSPBSIZE: 0x018f02cf (720, 400)
            DSPBBASE: 0x00000000
            DSPBSURF: 0x00000000
         DSPBTILEOFF: 0x00000000
           PIPEBCONF: 0x80000000 (enabled, single-wide)
            PIPEBSRC: 0x03ff0257 (1024, 600)
           PIPEBSTAT: 0x00400202 (status: LBLC_EVENT_ENABLE
VSYNC_INT_STATUS VBLANK_INT_STATUS)
   PIPEB_GMCH_DATA_M: 0x00000000
   PIPEB_GMCH_DATA_N: 0x00000000
     PIPEB_DP_LINK_M: 0x00000000
     PIPEB_DP_LINK_N: 0x00000000
       CURSOR_B_BASE: 0x00000000
    CURSOR_B_CONTROL: 0x10000000
   CURSOR_B_POSITION: 0x012801f9
                FPB0: 0x00100067 (n = 16, m1 = 0, m2 = 39)
                FPB1: 0x00100067 (n = 16, m1 = 0, m2 = 39)
              DPLL_B: 0x98040000 (enabled, non-dvo, default clock, LVDS
mode, p1 = 4, p2 = 14, SDVO mult 1)
           DPLL_B_MD: 0x00000000
            HTOTAL_B: 0x04af03ff (1024 active, 1200 total)
            HBLANK_B: 0x04af03ff (1024 start, 1200 end)
             HSYNC_B: 0x04570434 (1077 start, 1112 end)
            VTOTAL_B: 0x02700257 (600 active, 625 total)
            VBLANK_B: 0x02700257 (600 start, 625 end)
             VSYNC_B: 0x0260025b (604 start, 609 end)
           BCLRPAT_B: 0x00000000
        VSYNCSHIFT_B: 0x00000000
   VCLK_DIVISOR_VGA0: 0x00200074
   VCLK_DIVISOR_VGA1: 0x00200074
       VCLK_POST_DIV: 0x00800100
            VGACNTRL: 0x80000000 (disabled)
              TV_CTL: 0x00000000
              TV_DAC: 0x00000000
            TV_CSC_Y: 0x00000000
           TV_CSC_Y2: 0x00000000
            TV_CSC_U: 0x00000000
           TV_CSC_U2: 0x00000000
            TV_CSC_V: 0x00000000
           TV_CSC_V2: 0x00000000
        TV_CLR_KNOBS: 0x00000000
        TV_CLR_LEVEL: 0x00000000
          TV_H_CTL_1: 0x00000000
          TV_H_CTL_2: 0x00000000
          TV_H_CTL_3: 0x00000000
          TV_V_CTL_1: 0x00000000
          TV_V_CTL_2: 0x00000000
          TV_V_CTL_3: 0x00000000
          TV_V_CTL_4: 0x00000000
          TV_V_CTL_5: 0x00000000
          TV_V_CTL_6: 0x00000000
          TV_V_CTL_7: 0x00000000
         TV_SC_CTL_1: 0x00000000
         TV_SC_CTL_2: 0x00000000
         TV_SC_CTL_3: 0x00000000
          TV_WIN_POS: 0x00000000
         TV_WIN_SIZE: 0x00000000
     TV_FILTER_CTL_1: 0x00000000
     TV_FILTER_CTL_2: 0x00000000
     TV_FILTER_CTL_3: 0x00000000
       TV_CC_CONTROL: 0x00000000
          TV_CC_DATA: 0x00000000
         TV_H_LUMA_0: 0x00000000
        TV_H_LUMA_59: 0x00000000
       TV_H_CHROMA_0: 0x00000000
      TV_H_CHROMA_59: 0x00000000
        FBC_CFB_BASE: 0xffffffff
         FBC_LL_BASE: 0xffffffff
         FBC_CONTROL: 0xffffffff
         FBC_COMMAND: 0xffffffff
          FBC_STATUS: 0xffffffff
        FBC_CONTROL2: 0xffffffff
       FBC_FENCE_OFF: 0xffffffff
         FBC_MOD_NUM: 0xffffffff
             MI_MODE: 0x00000200
        MI_ARB_STATE: 0x00000840
      MI_RDRET_STATE: 0x00000000
             ECOSKPD: 0x00000307
                DP_B: 0x00000000
      DPB_AUX_CH_CTL: 0x00000000
    DPB_AUX_CH_DATA1: 0x00000000
    DPB_AUX_CH_DATA2: 0x00000000
    DPB_AUX_CH_DATA3: 0x00000000
    DPB_AUX_CH_DATA4: 0x00000000
    DPB_AUX_CH_DATA5: 0x00000000
                DP_C: 0x00000000
      DPC_AUX_CH_CTL: 0x00000000
    DPC_AUX_CH_DATA1: 0x00000000
    DPC_AUX_CH_DATA2: 0x00000000
    DPC_AUX_CH_DATA3: 0x00000000
    DPC_AUX_CH_DATA4: 0x00000000
    DPC_AUX_CH_DATA5: 0x00000000
                DP_D: 0x00000000
      DPD_AUX_CH_CTL: 0x00000000
    DPD_AUX_CH_DATA1: 0x00000000
    DPD_AUX_CH_DATA2: 0x00000000
    DPD_AUX_CH_DATA3: 0x00000000
    DPD_AUX_CH_DATA4: 0x00000000
    DPD_AUX_CH_DATA5: 0x00000000
          AUD_CONFIG: 0x00000000
    AUD_HDMIW_STATUS: 0x00000000
      AUD_CONV_CHCNT: 0x00000000
       VIDEO_DIP_CTL: 0x00000000
       AUD_PINW_CNTR: 0x00000000
         AUD_CNTL_ST: 0x00000000
         AUD_PIN_CAP: 0x00000000
        AUD_PINW_CAP: 0x00000000
  AUD_PINW_UNSOLRESP: 0x00000000
    AUD_OUT_DIG_CNVT: 0x00000000
       AUD_OUT_CWCAP: 0x00000000
         AUD_GRP_CAP: 0x00000000
            FENCE  0: 0x00c00231 (enabled, X tiled, 4096 pitch,
0x00c00000 - 0x01000000 (4096kb))
            FENCE  1: 0x01000231 (enabled, X tiled, 4096 pitch,
0x01000000 - 0x01400000 (4096kb))
            FENCE  2: 0x01400231 (enabled, X tiled, 4096 pitch,
0x01400000 - 0x01800000 (4096kb))
            FENCE  3: 0x00000000 (disabled)
            FENCE  4: 0x00000000 (disabled)
            FENCE  5: 0x00000000 (disabled)
            FENCE  6: 0x00000000 (disabled)
            FENCE  7: 0x00000000 (disabled)
            FENCE  8: 0x00000000 (disabled)
            FENCE  9: 0x00000000 (disabled)
           FENCE  10: 0x00000000 (disabled)
           FENCE  11: 0x00000000 (disabled)
           FENCE  12: 0x00000000 (disabled)
           FENCE  13: 0x00000000 (disabled)
           FENCE  14: 0x00000000 (disabled)
           FENCE  15: 0x00000000 (disabled)
             INST_PM: 0x00000000
pipe A dot 25173 n 5 m1 0 m2 116 p1 9 p2 10
pipe B dot 45000 n 4 m1 0 m2 103 p1 4 p2 14

Here's the diff between the two:

[jcm@constitution ~]$ diff intel_regs_broken.txt intel_regs_works.txt 
33c33
<                 LVDS: 0xc0308300 (enabled, pipe B, 18 bit, 1 channel)
---
>                 LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel)
95,97c95,97
<                 FPB0: 0x0020008c (n = 32, m1 = 0, m2 = 12)
<                 FPB1: 0x0020008c (n = 32, m1 = 0, m2 = 12)
<               DPLL_B: 0x98020000 (enabled, non-dvo, default clock,
LVDS mode, p1 = 3, p2 = 14, SDVO mult 1)
---
>                 FPB0: 0x00100067 (n = 16, m1 = 0, m2 = 39)
>                 FPB1: 0x00100067 (n = 16, m1 = 0, m2 = 39)
>               DPLL_B: 0x98040000 (enabled, non-dvo, default clock,
LVDS mode, p1 = 4, p2 = 14, SDVO mult 1)
99,104c99,104
<             HTOTAL_B: 0x053f03ff (1024 active, 1344 total)
<             HBLANK_B: 0x053f03ff (1024 start, 1344 end)
<              HSYNC_B: 0x049f0417 (1048 start, 1184 end)
<             VTOTAL_B: 0x03250257 (600 active, 806 total)
<             VBLANK_B: 0x02d102ab (684 start, 722 end)
<              VSYNC_B: 0x02c102bb (700 start, 706 end)
---
>             HTOTAL_B: 0x04af03ff (1024 active, 1200 total)
>             HBLANK_B: 0x04af03ff (1024 start, 1200 end)
>              HSYNC_B: 0x04570434 (1077 start, 1112 end)
>             VTOTAL_B: 0x02700257 (600 active, 625 total)
>             VBLANK_B: 0x02700257 (600 start, 625 end)
>              VSYNC_B: 0x0260025b (604 start, 609 end)
192c192
<             FENCE  2: 0x00000000 (disabled)
---
>             FENCE  2: 0x01400231 (enabled, X tiled, 4096 pitch,
0x01400000 - 0x01800000 (4096kb))
208c208
< pipe B dot 64914 n 5 m1 0 m2 140 p1 3 p2 14
---
> pipe B dot 45000 n 4 m1 0 m2 103 p1 4 p2 14

Jon.

[PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1

[Chris Wilson]

Commit 219adae1 cached the EDID found during LVDS init, but in the
process prevented the init routine from discovering the preferred
fixed-mode for the panel. This was causing us to guess the correct mode,
which sometimes is wide of the mark.

Reported-by: Jon Masters <jonathan@jonmasters.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/intel_lvds.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index f1a6499..4324a32 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -481,11 +481,8 @@ static int intel_lvds_get_modes(struct drm_connector *connector)
 	struct drm_device *dev = connector->dev;
 	struct drm_display_mode *mode;
 
-	if (intel_lvds->edid) {
-		drm_mode_connector_update_edid_property(connector,
-							intel_lvds->edid);
+	if (intel_lvds->edid)
 		return drm_add_edid_modes(connector, intel_lvds->edid);
-	}
 
 	mode = drm_mode_duplicate(dev, intel_lvds->fixed_mode);
 	if (mode == 0)
@@ -939,7 +936,16 @@ void intel_lvds_init(struct drm_device *dev)
 	 */
 	intel_lvds->edid = drm_get_edid(connector,
 					&dev_priv->gmbus[pin].adapter);
-
+	if (intel_lvds->edid) {
+		if (drm_add_edid_modes(connector,
+				       intel_lvds->edid)) {
+			drm_mode_connector_update_edid_property(connector,
+								intel_lvds->edid);
+		} else {
+			kfree(intel_lvds->edid);
+			intel_lvds->edid = NULL;
+		}
+	}
 	if (!intel_lvds->edid) {
 		/* Didn't get an EDID, so
 		 * Set wide sync ranges so we get all modes
-- 
1.7.2.3

Re: [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1

[Jon Masters]

On Mon, 2010-11-08 at 23:24 +0000, Chris Wilson wrote:
> Commit 219adae1 cached the EDID found during LVDS init, but in the
> process prevented the init routine from discovering the preferred
> fixed-mode for the panel. This was causing us to guess the correct mode,
> which sometimes is wide of the mark.
> 
> Reported-by: Jon Masters <jonathan@jonmasters.org>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I have tested this patch, and my LVDS panel display on this Eee PC
1015PEM is now working correctly :) Obviously I suspect others will be
affected in due course, so hopefully this can make the next 2.6.37 RC.

Please add my:

Tested-by: Jon Masters <jonathan@jonmasters.org>

To this patch also.

Jon.

Re: [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1

[Jon Masters]

On Mon, 2010-11-08 at 23:24 +0000, Chris Wilson wrote:
> Commit 219adae1 cached the EDID found during LVDS init, but in the
> process prevented the init routine from discovering the preferred
> fixed-mode for the panel. This was causing us to guess the correct mode,
> which sometimes is wide of the mark.
> 
> Reported-by: Jon Masters <jonathan@jonmasters.org>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This is now being tracked at the following k.o BZ:

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

Please mark the BZ when you push the patch. Thanks.

Jon.

Re: [bisected] offset display bug in i915

[James Courtier-Dutton]

On 8 November 2010 10:54, Jon Masters <jonathan@jonmasters.org> wrote:
>
> Here is the EDID output after booting:
>
> [jcm@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
> 0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
> 0000010 141c 0301 1680 780d 860a 9426 5157 2790
> 0000020 4f21 0054 0000 0101 0101 0101 0101 0101
> 0000030 0101 0101 0101 1194 b000 5840 2019 2335
> 0000040 0045 81dc 0000 1900 1416 d800 5840 2026
> 0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
> 0000060 0000 0000 0000 0000 0000 0000 0000 fe00
> 0000070 0000 0000 0000 0000 0100 0000 0000 f200
> 0000080
>
hexdump -C  is a little easier to read and compare with other hexdumps.

Re: [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 11:33 +0000, James Courtier-Dutton wrote:
> On 8 November 2010 10:54, Jon Masters <jonathan@jonmasters.org> wrote:
> >
> > Here is the EDID output after booting:
> >
> > [jcm@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
> > 0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
> > 0000010 141c 0301 1680 780d 860a 9426 5157 2790
> > 0000020 4f21 0054 0000 0101 0101 0101 0101 0101
> > 0000030 0101 0101 0101 1194 b000 5840 2019 2335
> > 0000040 0045 81dc 0000 1900 1416 d800 5840 2026
> > 0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
> > 0000060 0000 0000 0000 0000 0000 0000 0000 fe00
> > 0000070 0000 0000 0000 0000 0100 0000 0000 f200
> > 0000080
> >
> hexdump -C  is a little easier to read and compare with other hexdumps.

Yea, but I already ran edid-decode for Chris.

Chris: I suggest your idea of hacking up edid-decode to also take
hexdumps is a good idea for the future. That way you can feed it the
output from xrandr, or from people who like me don't realize that it's
preferred to post the interpreted output.

Jon.

Re: [bisected] offset display bug in i915

[James Courtier-Dutton]

On 8 November 2010 10:27, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
>> Hi Chris,
>>
>> The following patch that you recently committed breaks my ASUS Eee PC
>> 1015PEM by causing the display to be offset by about 1 inch (a few
>> centimeters) when the mode is (re)set during boot. I previously posted
>> both photographs and video of the problem in another "PROBLEM" thread.
>
> [snip]
>
>> I'll look at the patch. Either the EDID is *not* consistent (in which
>> case, why are we not seeing other bugs like this?) or there is something
>> specific to this system or panel used.
>
> Interesting. Or even downright bizarre! Can you disable the caching
> (hopefully the patch is still revertible) and save the EDID
> (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to
> dump the EDID every time we probe the LVDS if it has changed.
> -Chris
>

Hi,

I have observed major corruption issues for kernel 2.6.37.
Going back to 2.6.36 stable restores things to normality.
I unfortunately do not have time to track down the problem, but I
thought I would mention it as it could be causing your problem.
My problems were:
Corrupting the library cache so that .so files failed to load any more.
Corrupting .o files during compilation so that the linker did not even
recognize them as .o files.
Corrupted data between a DVB card and the recording on the HD.
I am just mentioning it, because the cause might in fact be somewhere else.

Kind Regards

James

Re: [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 11:26 +0000, James Courtier-Dutton wrote:
> On 8 November 2010 10:27, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> >> Hi Chris,
> >>
> >> The following patch that you recently committed breaks my ASUS Eee PC
> >> 1015PEM by causing the display to be offset by about 1 inch (a few
> >> centimeters) when the mode is (re)set during boot. I previously posted
> >> both photographs and video of the problem in another "PROBLEM" thread.
> >
> > [snip]
> >
> >> I'll look at the patch. Either the EDID is *not* consistent (in which
> >> case, why are we not seeing other bugs like this?) or there is something
> >> specific to this system or panel used.
> >
> > Interesting. Or even downright bizarre! Can you disable the caching
> > (hopefully the patch is still revertible) and save the EDID
> > (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to
> > dump the EDID every time we probe the LVDS if it has changed.

> I have observed major corruption issues for kernel 2.6.37.

Sad to hear, but none of what you are describing is related to this bug.
This bug has to do specifically with a small patch that added cacheing
of EDID panel data under the assumption that it wouldn't change. It only
affects your display, not linker, library objects, file systems, or in
fact anything other than getting geometry and location on screen right.

> Going back to 2.6.36 stable restores things to normality.
> I unfortunately do not have time to track down the problem, but I
> thought I would mention it as it could be causing your problem.
> My problems were:
> Corrupting the library cache so that .so files failed to load any more.
> Corrupting .o files during compilation so that the linker did not even
> recognize them as .o files.
> Corrupted data between a DVB card and the recording on the HD.
> I am just mentioning it, because the cause might in fact be somewhere else.

You might have a bad compiler, be switching distro packages, who knows.
Perhaps you can file a detailed bug report explaining your problems on
the bugzilla.kernel.org, or followup with more detail (to a new thread).

Jon.