* [bisected] offset display bug in i915
@ 2010-11-08 10:18 Jon Masters
2010-11-08 10:20 ` [Intel-gfx] " Jon Masters
2010-11-08 10:27 ` Chris Wilson
0 siblings, 2 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 10:18 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915
2010-11-08 10:18 [bisected] offset display bug in i915 Jon Masters
@ 2010-11-08 10:20 ` Jon Masters
2010-11-08 10:27 ` Chris Wilson
1 sibling, 0 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 10:20 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bisected] offset display bug in i915
2010-11-08 10:18 [bisected] offset display bug in i915 Jon Masters
2010-11-08 10:20 ` [Intel-gfx] " Jon Masters
@ 2010-11-08 10:27 ` Chris Wilson
2010-11-08 10:54 ` Jon Masters
2010-11-08 11:26 ` James Courtier-Dutton
1 sibling, 2 replies; 17+ messages in thread
From: Chris Wilson @ 2010-11-08 10:27 UTC (permalink / raw)
To: Jon Masters; +Cc: intel-gfx, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bisected] offset display bug in i915
2010-11-08 10:27 ` Chris Wilson
@ 2010-11-08 10:54 ` Jon Masters
2010-11-08 11:22 ` [Intel-gfx] " Jon Masters
2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton
2010-11-08 11:26 ` James Courtier-Dutton
1 sibling, 2 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 10:54 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915
2010-11-08 10:54 ` Jon Masters
@ 2010-11-08 11:22 ` Jon Masters
2010-11-08 11:29 ` Jon Masters
2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton
1 sibling, 1 reply; 17+ messages in thread
From: Jon Masters @ 2010-11-08 11:22 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bisected] offset display bug in i915
2010-11-08 10:27 ` Chris Wilson
2010-11-08 10:54 ` Jon Masters
@ 2010-11-08 11:26 ` James Courtier-Dutton
2010-11-08 11:34 ` Jon Masters
1 sibling, 1 reply; 17+ messages in thread
From: James Courtier-Dutton @ 2010-11-08 11:26 UTC (permalink / raw)
To: Chris Wilson; +Cc: Jon Masters, intel-gfx, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915
2010-11-08 11:22 ` [Intel-gfx] " Jon Masters
@ 2010-11-08 11:29 ` Jon Masters
2010-11-08 11:36 ` Jon Masters
2010-11-08 12:13 ` Chris Wilson
0 siblings, 2 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 11:29 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bisected] offset display bug in i915
2010-11-08 10:54 ` Jon Masters
2010-11-08 11:22 ` [Intel-gfx] " Jon Masters
@ 2010-11-08 11:33 ` James Courtier-Dutton
2010-11-08 11:38 ` Jon Masters
1 sibling, 1 reply; 17+ messages in thread
From: James Courtier-Dutton @ 2010-11-08 11:33 UTC (permalink / raw)
To: Jon Masters; +Cc: Chris Wilson, intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bisected] offset display bug in i915
2010-11-08 11:26 ` James Courtier-Dutton
@ 2010-11-08 11:34 ` Jon Masters
0 siblings, 0 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 11:34 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: Chris Wilson, intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915
2010-11-08 11:29 ` Jon Masters
@ 2010-11-08 11:36 ` Jon Masters
2010-11-08 12:13 ` Chris Wilson
1 sibling, 0 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 11:36 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bisected] offset display bug in i915
2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton
@ 2010-11-08 11:38 ` Jon Masters
0 siblings, 0 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 11:38 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: Chris Wilson, intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915
2010-11-08 11:29 ` Jon Masters
2010-11-08 11:36 ` Jon Masters
@ 2010-11-08 12:13 ` Chris Wilson
2010-11-08 17:58 ` Jon Masters
2010-11-08 23:08 ` Jon Masters
1 sibling, 2 replies; 17+ messages in thread
From: Chris Wilson @ 2010-11-08 12:13 UTC (permalink / raw)
To: Jon Masters; +Cc: intel-gfx, Linux Kernel Mailing List
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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915
2010-11-08 12:13 ` Chris Wilson
@ 2010-11-08 17:58 ` Jon Masters
2010-11-08 23:08 ` Jon Masters
1 sibling, 0 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-08 17:58 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915
2010-11-08 12:13 ` Chris Wilson
2010-11-08 17:58 ` Jon Masters
@ 2010-11-08 23:08 ` Jon Masters
2010-11-08 23:24 ` [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 Chris Wilson
1 sibling, 1 reply; 17+ messages in thread
From: Jon Masters @ 2010-11-08 23:08 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
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.
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1
2010-11-08 23:08 ` Jon Masters
@ 2010-11-08 23:24 ` Chris Wilson
2010-11-09 0:16 ` Jon Masters
2010-11-11 8:39 ` Jon Masters
0 siblings, 2 replies; 17+ messages in thread
From: Chris Wilson @ 2010-11-08 23:24 UTC (permalink / raw)
To: Jon Masters; +Cc: linux-kernel, 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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1
2010-11-08 23:24 ` [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 Chris Wilson
@ 2010-11-09 0:16 ` Jon Masters
2010-11-11 8:39 ` Jon Masters
1 sibling, 0 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-09 0:16 UTC (permalink / raw)
To: Chris Wilson; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1
2010-11-08 23:24 ` [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 Chris Wilson
2010-11-09 0:16 ` Jon Masters
@ 2010-11-11 8:39 ` Jon Masters
1 sibling, 0 replies; 17+ messages in thread
From: Jon Masters @ 2010-11-11 8:39 UTC (permalink / raw)
To: Chris Wilson; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-11-11 8:39 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-08 10:18 [bisected] offset display bug in i915 Jon Masters
2010-11-08 10:20 ` [Intel-gfx] " Jon Masters
2010-11-08 10:27 ` Chris Wilson
2010-11-08 10:54 ` Jon Masters
2010-11-08 11:22 ` [Intel-gfx] " Jon Masters
2010-11-08 11:29 ` Jon Masters
2010-11-08 11:36 ` Jon Masters
2010-11-08 12:13 ` Chris Wilson
2010-11-08 17:58 ` Jon Masters
2010-11-08 23:08 ` Jon Masters
2010-11-08 23:24 ` [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 Chris Wilson
2010-11-09 0:16 ` Jon Masters
2010-11-11 8:39 ` Jon Masters
2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton
2010-11-08 11:38 ` Jon Masters
2010-11-08 11:26 ` James Courtier-Dutton
2010-11-08 11:34 ` Jon Masters
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).