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 at 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 at ffwll.ch
Mobile: +41 (0)79 365 57 48