On Mon, May 28, 2012 at 1:09 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
A new worry about excessively verbose i915 driver "errors" that don't actually seem to be errors.
I got myself a micro-DP to VGA adapter so that I can use my Macbook Air for presentations.
And testing it, hotplugging seems to work very nicely, and gone are the days when you had to do xrandr and crap. Things "JustWork(tm)".
Goodie.
Until you start looking at the dmesg log. Then it gets ugly. It's full of scary-looking stuff like
------------[ cut here ]------------ WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() Hardware name: MacBookAir4,1 eDP powered off while attempting aux channel communication. Modules linked in: fuse rfcomm bnep nf_conntrack_netbios_ns nf_conntrack_broadcast .. Pid: 2126, comm: kworker/0:0 Tainted: G W 3.4.0-08209-gae32adc #9 Call Trace: warn_slowpath_common+0x7a/0xb0 warn_slowpath_fmt+0x41/0x50 intel_dp_check_edp+0x5d/0xb0 intel_dp_aux_ch+0x3f/0x330 intel_dp_aux_native_read_retry+0xad/0x130 intel_dp_detect+0x240/0x2c0 output_poll_execute+0xba/0x1a0 process_one_work+0x11b/0x3c0 worker_thread+0x12e/0x2d0 kthread+0x8e/0xa0 kernel_thread_helper+0x4/0x10 ---[ end trace 5756a4d08d9e2a83 ]---
which seems a bit extreme. I just unplugged the connector, I don't think it should necessarily make quite this big a deal over it. What does the WARN_ON() with the full call trace really buy us?
Well, all these edp checks (I presume all the other WARN backtraces yell around about edp, too) ensure that we have edp vdd or the panel power on while we try to do dp aux channel communication. And because we do need to talk to the monitor at tons of places, the backtrace is actually really useful to debug such edp vdd confusions.
The real problem here is that we think that the DP connector on your MBA is connected to an edp panel, which is pretty bogus. Cc'ing Chris and Keith who have the hw. Btw, you don't see all that dmesg spam until you connect something real because we check the hotplug pin status before we try to do use the dp aux channel (to get at the edid).
Yours, Daniel
PS: Add cc's and changed the subject, I've figured you wanted to bash me in public ;-)
On Mon, May 28, 2012 at 08:51:51PM +0200, Daniel Vetter wrote:
On Mon, May 28, 2012 at 1:09 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
A new worry about excessively verbose i915 driver "errors" that don't actually seem to be errors.
I got myself a micro-DP to VGA adapter so that I can use my Macbook Air for presentations.
And testing it, hotplugging seems to work very nicely, and gone are the days when you had to do xrandr and crap. Things "JustWork(tm)".
Goodie.
Until you start looking at the dmesg log. Then it gets ugly. It's full of scary-looking stuff like
------------[ cut here ]------------ WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() Hardware name: MacBookAir4,1 eDP powered off while attempting aux channel communication. Modules linked in: fuse rfcomm bnep nf_conntrack_netbios_ns nf_conntrack_broadcast .. Pid: 2126, comm: kworker/0:0 Tainted: G W 3.4.0-08209-gae32adc #9 Call Trace: warn_slowpath_common+0x7a/0xb0 warn_slowpath_fmt+0x41/0x50 intel_dp_check_edp+0x5d/0xb0 intel_dp_aux_ch+0x3f/0x330 intel_dp_aux_native_read_retry+0xad/0x130 intel_dp_detect+0x240/0x2c0 output_poll_execute+0xba/0x1a0 process_one_work+0x11b/0x3c0 worker_thread+0x12e/0x2d0 kthread+0x8e/0xa0 kernel_thread_helper+0x4/0x10 ---[ end trace 5756a4d08d9e2a83 ]---
which seems a bit extreme. I just unplugged the connector, I don't think it should necessarily make quite this big a deal over it. What does the WARN_ON() with the full call trace really buy us?
Well, all these edp checks (I presume all the other WARN backtraces yell around about edp, too) ensure that we have edp vdd or the panel power on while we try to do dp aux channel communication. And because we do need to talk to the monitor at tons of places, the backtrace is actually really useful to debug such edp vdd confusions.
The real problem here is that we think that the DP connector on your MBA is connected to an edp panel, which is pretty bogus. Cc'ing Chris and Keith who have the hw. Btw, you don't see all that dmesg spam until you connect something real because we check the hotplug pin status before we try to do use the dp aux channel (to get at the edid).
Ok, Chris couldn't reproduce this on his mba. Can you please boot with drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Thanks, Daniel
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter daniel@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is related to that. However, I suspect it's more likely that it's some race condition, because when I got it, I got a *lot* of it, but they were all very tightly bunched together:
[ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0()
ie that's 12 of those warnings (each of them with that huge backtrace etc), but they are all within 0.03 seconds of each other. So I suspect it needs to hit some particular timing window, and I was just (un)lucky.
Because when I try it now with DRM debugging, I can't hit it. And just to make sure, I re-did the test without debugging too (in case the debugging would have changed timing), but can't reproduce it that way either.
Linus
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter daniel@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is related to that. However, I suspect it's more likely that it's some race condition, because when I got it, I got a *lot* of it, but they were all very tightly bunched together:
[ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0()
ie that's 12 of those warnings (each of them with that huge backtrace etc), but they are all within 0.03 seconds of each other. So I suspect it needs to hit some particular timing window, and I was just (un)lucky.
Because when I try it now with DRM debugging, I can't hit it. And just to make sure, I re-did the test without debugging too (in case the debugging would have changed timing), but can't reproduce it that way either.
Hm, that's pretty strange that you can't reproduce this any more. We check this has_edp stuff once at boot and then never touch it again. Getting all these backtraces in close bunches is expected, because we have a lot of these checks - because we've had a lot of bugs :(. Did you by chance upgrade the firmware or switch from efi booting to bios booting - we use the vbios to detect part of the edp configuration?
The only other thing I could think of is whether disabling the internal panel changes anything. Iirc that's an edp panel on macbook airs, so this could paper over most of the warnings if it's enabled. -Daniel
On Wed, May 30, 2012 at 9:00 AM, Daniel Vetter daniel@ffwll.ch wrote:
Hm, that's pretty strange that you can't reproduce this any more. We check this has_edp stuff once at boot and then never touch it again.
Actually, I think I just figured out how to reproduce it: try to suspend with the micro-DP <-> VGA dongle, and attached to the screen. The suspend will fail, and the VGA screen does *not* come on again, and the messages happen.
But I didn't have drm.debug on this time - but I suspect that Chris will now be able to reproduce it easily with that information.
This time it also seems to be preceded by this message:
[drm:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck
but that didn't happen last time so it may or may not be related.
Linus
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter daniel@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is related to that. However, I suspect it's more likely that it's some race condition, because when I got it, I got a *lot* of it, but they were all very tightly bunched together:
[ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0()
ie that's 12 of those warnings (each of them with that huge backtrace etc), but they are all within 0.03 seconds of each other. So I suspect it needs to hit some particular timing window, and I was just (un)lucky.
Because when I try it now with DRM debugging, I can't hit it. And just to make sure, I re-did the test without debugging too (in case the debugging would have changed timing), but can't reproduce it that way either.
Meh, I've been totally blind. Note to self: Next time around actually look at the backtrace. And I dunno how that escaped our dear QA that long ...
Below patch should shut this up (and might even fix an edp panel not getting up again after having been switched off).
Yours, Daniel ---
From c56769c92f684d708b05052ec4f4555ea25da4de Mon Sep 17 00:00:00 2001
From: Daniel Vetter daniel.vetter@ffwll.ch Date: Thu, 7 Jun 2012 08:59:49 +0200 Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect
We need this for dp aux communication. This issue can fill the dmesg with WARN spam when the panel is disable (e.g. while reconfiguring the mode or while resuming).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808 Reported-by: Linus Torvalds torvalds@linux-foundation.org Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695 Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter daniel.vetter@ffwll.ch --- drivers/gpu/drm/i915/intel_dp.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 296cfc2..9a7edcf 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2165,6 +2165,7 @@ intel_dp_detect(struct drm_connector *connector, bool force) if (status != connector_status_connected) return status;
+ ironlake_edp_panel_vdd_on(intel_dp); intel_dp_probe_oui(intel_dp);
if (intel_dp->force_audio != HDMI_AUDIO_AUTO) { @@ -2177,6 +2178,7 @@ intel_dp_detect(struct drm_connector *connector, bool force) kfree(edid); } } + ironlake_edp_panel_vdd_off(intel_dp, false);
return connector_status_connected; }
On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter daniel@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is related to that. However, I suspect it's more likely that it's some race condition, because when I got it, I got a *lot* of it, but they were all very tightly bunched together:
[ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0()
ie that's 12 of those warnings (each of them with that huge backtrace etc), but they are all within 0.03 seconds of each other. So I suspect it needs to hit some particular timing window, and I was just (un)lucky.
Because when I try it now with DRM debugging, I can't hit it. And just to make sure, I re-did the test without debugging too (in case the debugging would have changed timing), but can't reproduce it that way either.
Meh, I've been totally blind. Note to self: Next time around actually look at the backtrace. And I dunno how that escaped our dear QA that long ...
Even more meh, this patch might actually work a bit better.
/me doesn't have an edp panel to test this
-Daniel ---
From 709e3d49d83fb7f1c297c7c0d9e994af6571bbdb Mon Sep 17 00:00:00 2001
From: Daniel Vetter daniel.vetter@ffwll.ch Date: Thu, 7 Jun 2012 08:59:49 +0200 Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect
We need this for dp aux communication. This issue can fill the dmesg with WARN spam when the panel is disable (e.g. while reconfiguring the mode or while resuming).
v2: Actually enable edp vdd early enough. I've missed one dp aux channel thingy ...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808 Reported-by: Linus Torvalds torvalds@linux-foundation.org Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695 Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter daniel.vetter@ffwll.ch --- drivers/gpu/drm/i915/intel_dp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 296cfc2..547cdc6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2152,6 +2152,7 @@ intel_dp_detect(struct drm_connector *connector, bool force)
intel_dp->has_audio = false;
+ ironlake_edp_panel_vdd_on(intel_dp); if (HAS_PCH_SPLIT(dev)) status = ironlake_dp_detect(intel_dp); else @@ -2162,8 +2163,10 @@ intel_dp_detect(struct drm_connector *connector, bool force) intel_dp->dpcd[3], intel_dp->dpcd[4], intel_dp->dpcd[5], intel_dp->dpcd[6], intel_dp->dpcd[7]);
- if (status != connector_status_connected) + if (status != connector_status_connected) { + ironlake_edp_panel_vdd_off(intel_dp, false); return status; + }
intel_dp_probe_oui(intel_dp);
@@ -2177,6 +2180,7 @@ intel_dp_detect(struct drm_connector *connector, bool force) kfree(edid); } } + ironlake_edp_panel_vdd_off(intel_dp, false);
return connector_status_connected; }
Am Donnerstag, den 07.06.2012, 09:26 +0200 schrieb Daniel Vetter:
[…]
From 709e3d49d83fb7f1c297c7c0d9e994af6571bbdb Mon Sep 17 00:00:00 2001 From: Daniel Vetter daniel.vetter@ffwll.ch Date: Thu, 7 Jun 2012 08:59:49 +0200 Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect
We need this for dp aux communication. This issue can fill the dmesg
What issue?
with WARN spam when the panel is disable (e.g. while reconfiguring the
disable*d*
mode or while resuming).
v2: Actually enable edp vdd early enough. I've missed one dp aux channel thingy ...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808 Reported-by: Linus Torvalds torvalds@linux-foundation.org Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695 Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter daniel.vetter@ffwll.ch
drivers/gpu/drm/i915/intel_dp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
[…]
Thanks,
Paul
On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
Meh, I've been totally blind. Note to self: Next time around actually look at the backtrace. And I dunno how that escaped our dear QA that long ...
Even more meh, this patch might actually work a bit better.
/me doesn't have an edp panel to test this
Please disregard this patch, too, QA says it's not yet working. And after some more reading of the various codepaths I agree.
/me goes back to the drawing board. -Daniel
On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter daniel@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is related to that. However, I suspect it's more likely that it's some race condition, because when I got it, I got a *lot* of it, but they were all very tightly bunched together:
[ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0()
ie that's 12 of those warnings (each of them with that huge backtrace etc), but they are all within 0.03 seconds of each other. So I suspect it needs to hit some particular timing window, and I was just (un)lucky.
Because when I try it now with DRM debugging, I can't hit it. And just to make sure, I re-did the test without debugging too (in case the debugging would have changed timing), but can't reproduce it that way either.
Meh, I've been totally blind. Note to self: Next time around actually look at the backtrace. And I dunno how that escaped our dear QA that long ...
Even more meh, this patch might actually work a bit better.
/me doesn't have an edp panel to test this
v3 is tested by our QA and hopefully works. I'll send it to Dave for -fixes in a few days, attached below just in case. Please yell if this doesn't fix your edp dmesg spam.
Thanks, Daniel ---
From 2b64c5549c000a1c552b8c617129569e3784336f Mon Sep 17 00:00:00 2001
From: Daniel Vetter daniel.vetter@ffwll.ch Date: Thu, 7 Jun 2012 08:59:49 +0200 Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect
We need this for dp aux communication. This issue can fill the dmesg with WARN spam when the panel is disable (e.g. while reconfiguring the mode or while resuming).
v2: Actually enable edp vdd early enough. I've missed one dp aux channel thingy ...
v3: We also enable/disable vdd in get_edid, which is called from within ->detect if a monitor is connected. But because we do some more dp aux transfers afterwards, vdd is actually off and we hit the WARN again. Hence move vdd enabling/disabling out of get_edid into the callsite.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808 Reported-by: Linus Torvalds torvalds@linux-foundation.org Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695 Tested-by: Yang Guang guang.a.yang@intel.com Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter daniel.vetter@ffwll.ch --- drivers/gpu/drm/i915/intel_dp.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 296cfc2..941edbf 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2114,13 +2114,7 @@ g4x_dp_detect(struct intel_dp *intel_dp) static struct edid * intel_dp_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter) { - struct intel_dp *intel_dp = intel_attached_dp(connector); - struct edid *edid; - - ironlake_edp_panel_vdd_on(intel_dp); - edid = drm_get_edid(connector, adapter); - ironlake_edp_panel_vdd_off(intel_dp, false); - return edid; + return drm_get_edid(connector, adapter); }
static int @@ -2152,6 +2146,7 @@ intel_dp_detect(struct drm_connector *connector, bool force)
intel_dp->has_audio = false;
+ ironlake_edp_panel_vdd_on(intel_dp); if (HAS_PCH_SPLIT(dev)) status = ironlake_dp_detect(intel_dp); else @@ -2162,8 +2157,10 @@ intel_dp_detect(struct drm_connector *connector, bool force) intel_dp->dpcd[3], intel_dp->dpcd[4], intel_dp->dpcd[5], intel_dp->dpcd[6], intel_dp->dpcd[7]);
- if (status != connector_status_connected) + if (status != connector_status_connected) { + ironlake_edp_panel_vdd_off(intel_dp, false); return status; + }
intel_dp_probe_oui(intel_dp);
@@ -2177,6 +2174,7 @@ intel_dp_detect(struct drm_connector *connector, bool force) kfree(edid); } } + ironlake_edp_panel_vdd_off(intel_dp, false);
return connector_status_connected; } @@ -2235,6 +2233,7 @@ intel_dp_detect_audio(struct drm_connector *connector) struct edid *edid; bool has_audio = false;
+ ironlake_edp_panel_vdd_on(intel_dp); edid = intel_dp_get_edid(connector, &intel_dp->adapter); if (edid) { has_audio = drm_detect_monitor_audio(edid); @@ -2242,6 +2241,7 @@ intel_dp_detect_audio(struct drm_connector *connector) connector->display_info.raw_edid = NULL; kfree(edid); } + ironlake_edp_panel_vdd_off(intel_dp, false);
return has_audio; }
On Mon, Jun 11, 2012 at 09:20:00AM +0200, Daniel Vetter wrote:
On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter daniel@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is related to that. However, I suspect it's more likely that it's some race condition, because when I got it, I got a *lot* of it, but they were all very tightly bunched together:
[ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0() [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 intel_dp_check_edp+0x5d/0xb0()
ie that's 12 of those warnings (each of them with that huge backtrace etc), but they are all within 0.03 seconds of each other. So I suspect it needs to hit some particular timing window, and I was just (un)lucky.
Because when I try it now with DRM debugging, I can't hit it. And just to make sure, I re-did the test without debugging too (in case the debugging would have changed timing), but can't reproduce it that way either.
Meh, I've been totally blind. Note to self: Next time around actually look at the backtrace. And I dunno how that escaped our dear QA that long ...
Even more meh, this patch might actually work a bit better.
/me doesn't have an edp panel to test this
v3 is tested by our QA and hopefully works. I'll send it to Dave for -fixes in a few days, attached below just in case. Please yell if this doesn't fix your edp dmesg spam.
... and that one died in review. v4 is in the works and going through QA atm. -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Daniel Vetter -
Linus Torvalds -
Paul Menzel