Bug 45881 - [gm45] GMBUS fails to retrieve EDID for VGA
Summary: [gm45] GMBUS fails to retrieve EDID for VGA
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-11 16:45 UTC by Alex Ferrando
Modified: 2012-08-26 10:50 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.5.1
Tree: Mainline
Regression: Yes


Attachments
Dmesg output (68.79 KB, text/plain)
2012-08-11 16:46 UTC, Alex Ferrando
Details
Output of xrandr --verbose using 3.4.8 kernel (5.35 KB, text/plain)
2012-08-11 17:16 UTC, Alex Ferrando
Details
[PATCH 1/2] drm/i915: extract connector update from intel_ddc_get_modes() for reuse (2.73 KB, patch)
2012-08-13 14:41 UTC, Jani Nikula
Details | Diff
[PATCH 2/2] drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads (3.39 KB, patch)
2012-08-13 14:42 UTC, Jani Nikula
Details | Diff
dmesg output after applying the two proposed patches (72.61 KB, text/plain)
2012-08-16 11:27 UTC, Alex Ferrando
Details

Description Alex Ferrando 2012-08-11 16:45:45 UTC
Since the upgrade from kernel 3.4.x (the whole 3.4 series is fine) to the 3.5.1, whenever I plug my external VGA monitor to the laptop even if I do not set it to be used, the messages log gets spammed with fragments like this:

drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130    
[drm:drm_edid_block_valid] *ERROR* Raw EDID:                                    
<3>00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff  ................            
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................            
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................            
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................            
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................            
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................            
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................            
<3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................    

Also, the resolution at which I can set the screen has been redoced from
1280x1024 to 1024x768. I can force it to work at 1280x1024 using xrandr to add
a new mode but whenever I do this, the screen gets moved to the left, leaving a
black vertical artifact at the right of the VGA screen.

Also, the screen gets moved to the right like 120 px or something between 120 and 80 px

Aside from the external screen problem, everything else seems to work and no X
or kernel crashes have been suffered.

This bug report is almost a copy of a regression that also happened on 2.6.39 as the behaviour seems to be the same:

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

I'm already on bisecting between 3.4.8 and 3.5.1 to see where this got broken again.

In case I've left something out that should have been added here, please tell me.
Comment 1 Alex Ferrando 2012-08-11 16:46:38 UTC
Created attachment 77361 [details]
Dmesg output
Comment 2 Chris Wilson 2012-08-11 16:52:21 UTC
Can you attach an 'xrandr --verbose' for the working 3.4 setup?
Comment 3 Alex Ferrando 2012-08-11 17:16:31 UTC
Created attachment 77371 [details]
Output of xrandr --verbose using 3.4.8 kernel
Comment 4 Alex Ferrando 2012-08-11 17:17:18 UTC
Do you also want me to attach the output of 'xrandr --verbose' for the 3.5 kernel?
Comment 5 Chris Wilson 2012-08-11 17:28:06 UTC
(In reply to comment #4)
> Do you also want me to attach the output of 'xrandr --verbose' for the 3.5
> kernel?

No, I was curious as to what the EDID should be. :)
Comment 6 Daniel Vetter 2012-08-11 18:55:24 UTC
Already reported here: https://lkml.org/lkml/2012/7/25/77

I've volunteered Jani to implement the workaround for it. Unfortunately he's not yet on kernel bugzilla, I'll yell at him a bit.
Comment 7 Alex Ferrando 2012-08-11 21:25:01 UTC
the patch suggested in the mailing list's thread solves the problem for me.
Comment 8 Jani Nikula 2012-08-13 11:39:46 UTC
(In reply to comment #6)
> I've volunteered Jani to implement the workaround for it. Unfortunately he's
> not yet on kernel bugzilla, I'll yell at him a bit.

Yessir! I'm here now.

(In reply to comment #7)
> the patch suggested in the mailing list's thread solves the problem for me.

Please try the polished version posted in the list, and let use have your tested-by. Thanks.
Comment 9 Alex Ferrando 2012-08-13 13:41:46 UTC
I'll try to test it as soon as possible, but I'm not sure I'll be able to test it before Thursday.
Comment 10 Jani Nikula 2012-08-13 14:41:52 UTC
Created attachment 77621 [details]
[PATCH 1/2] drm/i915: extract connector update from intel_ddc_get_modes() for reuse
Comment 11 Jani Nikula 2012-08-13 14:42:31 UTC
Created attachment 77631 [details]
[PATCH 2/2] drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
Comment 12 Alex Ferrando 2012-08-16 10:37:10 UTC
second patch fails to apply HUNK #2 because there is a comment block between

i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
edid = drm_get_edid(connector, i2c);

and 

if (edid) {
 		bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL;


Anyway, changed manually that part and I'm currently building the kernel.
Comment 13 Alex Ferrando 2012-08-16 11:26:51 UTC
Problem seems to be solved with those two patches, however dmesg still gets "spammed" with [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130

I'll attach the output of dmesg
Comment 14 Alex Ferrando 2012-08-16 11:27:57 UTC
Created attachment 77801 [details]
dmesg output after applying the two proposed patches
Comment 15 Jani Nikula 2012-08-16 12:12:46 UTC
Thanks for the testing!

(In reply to comment #12)
> second patch fails to apply HUNK #2 because there is a comment block between
> 
> i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
> edid = drm_get_edid(connector, i2c);
> 
> and 
> 
> if (edid) {
>          bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL;
> 
> 
> Anyway, changed manually that part and I'm currently building the kernel.

I think this means you're applying the patch on top of kernel 3.5. Is that right? Before we apply the fix, I think it would be useful if you could test this on current master, or better yet, drm-intel-fixes branch of git://people.freedesktop.org/~danvet/drm-intel repo. Without and with the patches.

(In reply to comment #13)
> Problem seems to be solved with those two patches, however dmesg still gets
> "spammed" with [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> remainder is 130

This is the GMBUS failure as before, but the patches add a fallback mechanism to use in this failure mode. If tried with the drm.debug=0xe module parameter, I think you'd see the "CRT GMBUS EDID read failed, retry using GPIO bit-banging" debug message.
Comment 16 Alex Ferrando 2012-08-16 12:50:25 UTC
Yes, I was applying the patch on top of 3.5, specifically 3.5.2 ( latest stable release)

I'll test it with drm-intel-fixes branch as soon as I can, but I fear it could not be possible until tomorrow.
Comment 17 Alex Ferrando 2012-08-16 14:12:48 UTC
Well, tested drm-intel-fixes branch from the git repo you posted and:

unpatched: dmesg gets spammed and the issue reported at the beginning of the thread exists.

patched: dmesg still gets spammed about the EDID checksum, but issue is gone
Comment 18 Jani Nikula 2012-08-16 15:11:29 UTC
(In reply to comment #17)
> Well, tested drm-intel-fixes branch from the git repo you posted and:
> 
> unpatched: dmesg gets spammed and the issue reported at the beginning of the
> thread exists.
> 
> patched: dmesg still gets spammed about the EDID checksum, but issue is gone

Thanks again for testing. Daniel has queued the fix, and the dmesg spam will be looked into separately.
Comment 19 Alex Ferrando 2012-08-16 15:20:00 UTC
(In reply to comment #18)
> Thanks again for testing. Daniel has queued the fix, and the dmesg spam will
> be
> looked into separately.

Thank you for your time solving the issue. I'm glad I've been able to help
Comment 20 Daniel Vetter 2012-08-22 08:53:12 UTC
The fix landed in 3.6-rc2, cc: stable.

commit f1a2f5b7c5f0941d23eef0a095c0b99bf8d051e6
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Aug 13 13:22:35 2012 +0300

    drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
Comment 21 Florian Mickler 2012-08-26 10:50:06 UTC
A patch referencing this bug report has been merged in Linux v3.6-rc3:

commit 4eab81366465aedcfd26de960c595bc03599c09f
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Aug 13 13:22:34 2012 +0300

    drm/i915: extract connector update from intel_ddc_get_modes() for reuse

Note You need to log in before you can comment on or make changes to this bug.