Bug 45671 - [IVB edp] Blank screen on boot for MacBookAir5,1 (June 2012)
[IVB edp] Blank screen on boot for MacBookAir5,1 (June 2012)
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel)
All Linux
: P1 normal
Assigned To: drivers_video-dri-intel@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-07 03:44 UTC by Roberto Romero
Modified: 2012-08-21 06:51 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.2.20 to 3.5
Tree: Mainline
Regression: Yes


Attachments
Results of git bisect (1.80 KB, text/plain)
2012-08-07 03:44 UTC, Roberto Romero
Details
Output of lspci -nn (1.69 KB, text/plain)
2012-08-07 03:45 UTC, Roberto Romero
Details
Patch which solves the problem but generates lots of warnings (594 bytes, patch)
2012-08-07 03:46 UTC, Roberto Romero
Details | Diff
dmesg of kernel 3.5 before patching (87.59 KB, text/plain)
2012-08-07 03:47 UTC, Roberto Romero
Details
dmesg of kernel 3.5 after patching (101.95 KB, text/plain)
2012-08-07 03:48 UTC, Roberto Romero
Details
edp panel off after dp sink off (1014 bytes, patch)
2012-08-07 13:54 UTC, Daniel Vetter
Details | Diff
dmesg of kernel 3.5 with drm.debug=0xe (111.84 KB, text/plain)
2012-08-07 17:45 UTC, Roberto Romero
Details
dmesg of kernel 3.5, branch modeset_rework with drm.debug=0xe (113.00 KB, text/plain)
2012-08-07 23:23 UTC, Roberto Romero
Details
new trial at reordering the edp off sequence (1.62 KB, patch)
2012-08-08 08:34 UTC, Daniel Vetter
Details | Diff
dmesg of kernel 3.5 with first patch and FORCE_VDD hack (111.45 KB, text/plain)
2012-08-09 03:15 UTC, Roberto Romero
Details
dmesg of kernel 3.5 with second patch (109.59 KB, text/plain)
2012-08-09 04:10 UTC, Roberto Romero
Details
reorder edp panel off (3.39 KB, patch)
2012-08-09 08:05 UTC, Daniel Vetter
Details | Diff
dmesg of kernel 3.5 with third patch (111.79 KB, text/plain)
2012-08-09 21:03 UTC, Roberto Romero
Details
reorder edp panel off v2 (3.69 KB, patch)
2012-08-10 09:45 UTC, Daniel Vetter
Details | Diff
dmesg of kernel 3.5 with fourth patch (111.20 KB, text/plain)
2012-08-11 16:37 UTC, Roberto Romero
Details
patch v3 (3.82 KB, patch)
2012-08-11 19:07 UTC, Daniel Vetter
Details | Diff
patch v3 on top of drm-intel-next (151.57 KB, application/octet-stream)
2012-08-12 20:54 UTC, Daniel Wagner
Details

Description Roberto Romero 2012-08-07 03:44:51 UTC
Created attachment 76961 [details]
Results of git bisect

From 3.2.20 until now (3.5), booting in a MacBookAir5,1 will consistently result in a blank (as empty, not as power off) screen. Trying to start X does not make any difference.

I did a git bisect and found the line causing me problems. Reverting that line fixes the problem, but I don't think it's a solution, as it generates a lot of warnings about "eDP powered off while attempting aux channel communication".
Comment 1 Roberto Romero 2012-08-07 03:45:28 UTC
Created attachment 76971 [details]
Output of lspci -nn
Comment 2 Roberto Romero 2012-08-07 03:46:27 UTC
Created attachment 76981 [details]
Patch which solves the problem but generates lots of warnings
Comment 3 Roberto Romero 2012-08-07 03:47:09 UTC
Created attachment 76991 [details]
dmesg of kernel 3.5 before patching
Comment 4 Roberto Romero 2012-08-07 03:48:06 UTC
Created attachment 77001 [details]
dmesg of kernel 3.5 after patching
Comment 5 Daniel Vetter 2012-08-07 13:48:44 UTC
For reference, is the below patch (respectively the backport of it to 3.2) the one causing your regression?

commit 6cb49835da0426f69a2931bc2a0a8156344b0e41
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 20 17:14:50 2012 +0200

    drm/i915: enable vdd when switching off the eDP panel
    
    We have one bug report from a validation team that we get the eDP
    panel sequencing still somewhat wrong: We need to enable VDD while
    switching off the panel and backlight. Unfortunately that reporter
    seems to have fallen off the earth :(
    
    For another reporter this actually fixes a black panel issue because
    without this the backlight/panel gets confused and doesn't light up
    again.
    
    v2: I've forgotten to remove the vdd_off call in panel_off which is
    now bogus. This essentially reverts
    
    commit 17038de5f16569a25343cf68668f3b657eafb00e
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Mon Apr 16 22:43:42 2012 +0100
    
        drm/i915/dp: Flush any outstanding work to turn the VDD off
    
    v3: the current panel_off code forces off the vdd power, too. Which is
    bogus and resulted in some funny warnings later on when we've tried to
    do aux channel communications with just the vdd forced on. Fix this,
    too.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163
    Tested-by: Vincent Frentzel <zcecc22@gmail.com>
    Cc: stable@kernel.org
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 6 Daniel Vetter 2012-08-07 13:50:13 UTC
Another thing: Does a modeset sequence resurrect the screen? E.g. crtc switching with 

$ xrandr --output eDP1 --auto crtc 1
$ xrandr --output eDP1 --auto crtc 0
Comment 7 Daniel Vetter 2012-08-07 13:51:30 UTC
Also, can you please boot with drm.debug=0xe added to your kernel cmdline (doesn't matter whether with patch or without) on 3.5 and attach the full dmesg?
Comment 8 Daniel Vetter 2012-08-07 13:54:59 UTC
Created attachment 77031 [details]
edp panel off after dp sink off

... and a quick patch for you to test (instead of the FORCE_VDD hack).
Comment 9 Daniel Vetter 2012-08-07 13:55:59 UTC
btw, if the above patch doesn't work, please also test it together with your FORCE_VDD hack.
Comment 10 Roberto Romero 2012-08-07 17:06:02 UTC
(In reply to comment #6)
> Another thing: Does a modeset sequence resurrect the screen? E.g. crtc
> switching with 
> 
> $ xrandr --output eDP1 --auto crtc 1
> $ xrandr --output eDP1 --auto crtc 0

These commands gave me error, so I tried with:
$ xrandr --output eDP1 --auto --crtc 0
$ xrandr --output eDP1 --auto --crtc 1

That worked, but not always. I did some tests and I think it is time-related. Waiting over a minute after the machine boots to run these commands generally does the trick.
Comment 11 Daniel Vetter 2012-08-07 17:12:10 UTC
While you go through all the variations for testing: Can you please also test the modeset-rework branch from git://people.freedesktop.org/~danvet/drm ?

That git branch fixes a modeset sequence issue for ivb cpu edp (which is rather likely what you have, but I need the drm.debug dmesg to confirm).
Comment 12 Roberto Romero 2012-08-07 17:18:03 UTC
(In reply to comment #5)
> For reference, is the below patch (respectively the backport of it to 3.2) the
> one causing your regression?
> 
> commit 6cb49835da0426f69a2931bc2a0a8156344b0e41
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Sun May 20 17:14:50 2012 +0200
> 
>     drm/i915: enable vdd when switching off the eDP panel
> 
>     We have one bug report from a validation team that we get the eDP
>     panel sequencing still somewhat wrong: We need to enable VDD while
>     switching off the panel and backlight. Unfortunately that reporter
>     seems to have fallen off the earth :(
> 
>     For another reporter this actually fixes a black panel issue because
>     without this the backlight/panel gets confused and doesn't light up
>     again.
> 
>     v2: I've forgotten to remove the vdd_off call in panel_off which is
>     now bogus. This essentially reverts
> 
>     commit 17038de5f16569a25343cf68668f3b657eafb00e
>     Author: Chris Wilson <chris@chris-wilson.co.uk>
>     Date:   Mon Apr 16 22:43:42 2012 +0100
> 
>         drm/i915/dp: Flush any outstanding work to turn the VDD off
> 
>     v3: the current panel_off code forces off the vdd power, too. Which is
>     bogus and resulted in some funny warnings later on when we've tried to
>     do aux channel communications with just the vdd forced on. Fix this,
>     too.
> 
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312
>     Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163
>     Tested-by: Vincent Frentzel <zcecc22@gmail.com>
>     Cc: stable@kernel.org
>     Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>     Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Yes, it is. Reverting this patch on a 3.5 kernel makes the screen work again.
Comment 13 Roberto Romero 2012-08-07 17:45:01 UTC
Created attachment 77041 [details]
dmesg of kernel 3.5 with drm.debug=0xe
Comment 14 Daniel Vetter 2012-08-07 17:49:50 UTC
(In reply to comment #13)
> Created an attachment (id=77041) [details]
> dmesg of kernel 3.5 with drm.debug=0xe

Yep, cpu edp.
Comment 15 Roberto Romero 2012-08-07 22:59:48 UTC
(In reply to comment #8)
> Created an attachment (id=77031) [details]
> edp panel off after dp sink off
> 
> ... and a quick patch for you to test (instead of the FORCE_VDD hack).

The screen goes blank with this patch.
Comment 16 Roberto Romero 2012-08-07 23:19:41 UTC
(In reply to comment #11)
> While you go through all the variations for testing: Can you please also test
> the modeset-rework branch from git://people.freedesktop.org/~danvet/drm ?
> 
> That git branch fixes a modeset sequence issue for ivb cpu edp (which is rather
> likely what you have, but I need the drm.debug dmesg to confirm).

With this kernel the screen goes also blank, but in this case, it goes blank as in power off.

I'm going to attach a dmesg with drm.debug=0xe for this kernel, maybe it is useful.
Comment 17 Roberto Romero 2012-08-07 23:23:37 UTC
Created attachment 77081 [details]
dmesg of kernel 3.5, branch modeset_rework with drm.debug=0xe
Comment 18 Daniel Vetter 2012-08-08 08:34:52 UTC
Created attachment 77101 [details]
new trial at reordering the edp off sequence

Please test this new patch, thanks.
Comment 19 Roberto Romero 2012-08-09 03:13:16 UTC
(In reply to comment #9)
> btw, if the above patch doesn't work, please also test it together with your
> FORCE_VDD hack.

Just for the record, I tried your first patch with my FORCE_VDD hack and it worked without warnings. I'm going to attach a dmesg with drm.debug=0xe, just in case.
Comment 20 Roberto Romero 2012-08-09 03:15:04 UTC
Created attachment 77141 [details]
dmesg of kernel 3.5 with first patch and FORCE_VDD hack
Comment 21 Roberto Romero 2012-08-09 03:17:12 UTC
(In reply to comment #18)
> Created an attachment (id=77101) [details]
> new trial at reordering the edp off sequence
> 
> Please test this new patch, thanks.

Tried this patch, and works, but generates warnings about "Need VDD to turn off panel". I'm going to attach a dmesg with drm.debug=0xe about it.
Comment 22 Roberto Romero 2012-08-09 04:10:24 UTC
Created attachment 77151 [details]
dmesg of kernel 3.5 with second patch
Comment 23 Daniel Vetter 2012-08-09 08:05:52 UTC
Created attachment 77161 [details]
reorder edp panel off

Hopefully final patch, please test. Unfortunately the reporter of the other bug is travelling, so we can't test that. But since this here is a regression, it has priority. I've we're unlucky, I need to bugger you again if this patch here breaks the other machine again, but I'm hopeful that that won't happen.
Comment 24 Roberto Romero 2012-08-09 21:02:28 UTC
(In reply to comment #23)
> Created an attachment (id=77161) [details]
> reorder edp panel off
> 
> Hopefully final patch, please test. Unfortunately the reporter of the other bug
> is travelling, so we can't test that. But since this here is a regression, it
> has priority. I've we're unlucky, I need to bugger you again if this patch here
> breaks the other machine again, but I'm hopeful that that won't happen.

Sorry, but it seems this patch makes the screen blank again like when I reported the bug (as in empty, not as in power off). I'm going to attach a dmesg with drm.debug=0xe, just in case.
Comment 25 Roberto Romero 2012-08-09 21:03:54 UTC
Created attachment 77251 [details]
dmesg of kernel 3.5 with third patch
Comment 26 Daniel Vetter 2012-08-10 09:45:55 UTC
Created attachment 77271 [details]
reorder edp panel off v2

ok, the clearing of force_vdd seems to be the crucial thing here ... please test.
Comment 27 Roberto Romero 2012-08-11 16:35:02 UTC
(In reply to comment #26)
> Created an attachment (id=77271) [details]
> reorder edp panel off v2
> 
> ok, the clearing of force_vdd seems to be the crucial thing here ... please
> test.

This one works, but unfortunately generates warnings. The warnings say "eDP powered off while attempting aux channel communication". This is the same warning it generated when I applied only my hack. I'm going to attach another dmesg. I'm not sure if the dmesg are useful, please tell me if they are not.
Comment 28 Roberto Romero 2012-08-11 16:37:04 UTC
Created attachment 77351 [details]
dmesg of kernel 3.5 with fourth patch
Comment 29 Daniel Vetter 2012-08-11 19:07:06 UTC
Created attachment 77381 [details]
patch v3

New patch, v2 assumed that the panel is left behind by the Apple in an enabled state. The new patch hopefully rectifies that. Please test.

Fyi, dmesg with drm.debug=0xe is perfect in case something in the edp panel power code blows up.
Comment 30 Daniel Wagner 2012-08-12 19:34:20 UTC
I have tested patch v3 but it doesn't work. Unfortunately, at this point I am not able to add the dmesg. The remote login doesn't work yet.
Comment 31 Roberto Romero 2012-08-12 19:43:43 UTC
(In reply to comment #29)
> Created an attachment (id=77381) [details]
> patch v3
> 
> New patch, v2 assumed that the panel is left behind by the Apple in an enabled
> state. The new patch hopefully rectifies that. Please test.
> 
> Fyi, dmesg with drm.debug=0xe is perfect in case something in the edp panel
> power code blows up.

This one seems to work perfectly. Boots correctly with no warnings. Thanks you a lot for all your efforts!

Out of curiosity, why did you discard the combination of your first patch (edp panel off after dp sink off) and the FORCE_VDD hack? It appeared to work, without warnings. It could create problems to other users?

Also, sometimes, after suspending the laptop, when I try to wake it up after a few hours, it comes back, but the screen remains blank as in power off. May it be related? Should I fill another bug report?
Comment 32 Daniel Wagner 2012-08-12 20:04:10 UTC
I got it working now too. In my previous post I did apply it on top of drm-intel-next with the default platform configuration from the kernel. In the working configuration, I applied it on top of Linus' tree with the Fedora configuration.

I'll rebuild the drm-intel-next tree with the Fedora configuration to rule out some problems with the settings.
Comment 33 Daniel Vetter 2012-08-12 20:15:44 UTC
(In reply to comment #31)
> This one seems to work perfectly. Boots correctly with no warnings. Thanks you
> a lot for all your efforts!

Thanks for testing! I'll wait with applying the patch until Daniel confirmed that it works on -next, too.
 
> Out of curiosity, why did you discard the combination of your first patch (edp
> panel off after dp sink off) and the FORCE_VDD hack? It appeared to work,
> without warnings. It could create problems to other users?

The new patch _is_ the first one + hack, but (hopefully) done right.
 
> Also, sometimes, after suspending the laptop, when I try to wake it up after a
> few hours, it comes back, but the screen remains blank as in power off. May it
> be related? Should I fill another bug report?

We have other issues with cpu edp on ivb, could be that you're hitting those. Can you still ssh into the machine once the screen comes up black after resume?
Comment 34 Roberto Romero 2012-08-12 20:25:02 UTC
(In reply to comment #33)
> (In reply to comment #31)
> > This one seems to work perfectly. Boots correctly with no warnings. Thanks you
> > a lot for all your efforts!
> 
> Thanks for testing! I'll wait with applying the patch until Daniel confirmed
> that it works on -next, too.
> 
> > Out of curiosity, why did you discard the combination of your first patch (edp
> > panel off after dp sink off) and the FORCE_VDD hack? It appeared to work,
> > without warnings. It could create problems to other users?
> 
> The new patch _is_ the first one + hack, but (hopefully) done right.
> 
> > Also, sometimes, after suspending the laptop, when I try to wake it up after a
> > few hours, it comes back, but the screen remains blank as in power off. May it
> > be related? Should I fill another bug report?
> 
> We have other issues with cpu edp on ivb, could be that you're hitting those.
> Can you still ssh into the machine once the screen comes up black after resume?

Yes, I can. It happened a few hours ago and I logged in and saw a dmesg with a drm.debug=0xe (that I forgot to save, damn). It showed no warnings. I can add that option to GRUB, wait until it happens again and mail you that dmesg (or other info), if you want.
Comment 35 Daniel Vetter 2012-08-12 20:31:00 UTC
(In reply to comment #34)
> Yes, I can. It happened a few hours ago and I logged in and saw a dmesg with a
> drm.debug=0xe (that I forgot to save, damn). It showed no warnings. I can add
> that option to GRUB, wait until it happens again and mail you that dmesg (or
> other info), if you want.

Ok, then please grab the latest git tree of intel-gpu-tools at 

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

and grab the output of intel_reg_dumper after the screen has stuck to black. Then please open a new bug report (together with the debug dmesg) at bugs.freedesktop.org.
Comment 36 Daniel Wagner 2012-08-12 20:31:45 UTC
patch v3 on top of drm-linux-next with Fedora configuration: The backlight is
not on, but I see that contents is drawn, e.g. the KDM is started and drawn.
Now I might be able to retrieve the dmsg. Just a sec.
Comment 37 Daniel Wagner 2012-08-12 20:44:29 UTC
I have troubles to create the log. I am able to login to the box but after a short time it freezes or crashes. I can't tell. I'll retry to get the log, I need to be fast enough.
Comment 38 Daniel Wagner 2012-08-12 20:54:15 UTC
Created attachment 77461 [details]
patch v3 on top of drm-intel-next

This is the dmesg with patch "drm/i915: reorder edp disabling to fix ivb MacBook Air" on top of drm-linux-next (drm/i915: don't grab dev->struct_mutex for userspace forcewak)

The system boots and X is started though the back light is missing. After a while the system either hangs or panics and the screen goes blank. No network connection at this point.
Comment 39 Daniel Vetter 2012-08-12 21:01:45 UTC
Hm, drm-linux-next is at a totally different baseline atm (3.5-rc4 compared to to Linux tree at 3.6-rc1) so this could be anything. Also, not all i915 fixes in Linus' tree are included in -next. So I think the patch is good, and you're crashes something else. Thanks to everyone for reporting this issue.
Comment 40 Florian Mickler 2012-08-20 21:55:44 UTC
A patch referencing this bug report has been merged in Linux v3.6-rc2:

commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Aug 12 22:17:14 2012 +0200

    drm/i915: reorder edp disabling to fix ivb MacBook Air

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