edp backtrace spam on MacBookAir4,1

edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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 ;-)
-- 
Daniel Vetter
daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: edp backtrace spam on MacBookAir4,1

[Linus Torvalds]

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

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: edp backtrace spam on MacBookAir4,1

[Linus Torvalds]

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

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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;
 }
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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;
 }
-- 
1.7.10

-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: edp backtrace spam on MacBookAir4,1

[Paul Menzel]

[-- Attachment #1.1: Type: text/plain, Size: 1039 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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;
 }
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

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
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48