Bug 44001

Summary: [ivb cpu eDP] - screen flickers then turns black
Product: Drivers Reporter: Dominik Meissner (dominik.meissner)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED CODE_FIX    
Severity: normal CC: daniel, florian, intel-gfx-bugs, jbarnes
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.4.4 Subsystem:
Regression: No Bisected commit-id:
Attachments: messages.log booted with drm.debug=0xe
output of lspci -vvvnn
messages.log with cpu_edp-abomination
Xorg.log started with the intel driver
output of xrandr --verbose
output of intel_reg_dumper after executing both commands
output of intel_reg_dumper after switching to crtc 1
output of intel_reg_dumper after switching back to crtc 0
messages.log with modeset-rework branch
dmesg with modeset-rework branch
intel_reg_dump before switching crtc
intel_reg_dump after switching to crtc 1
intel_reg_dump after switching back to crtc 0

Description Dominik Meissner 2012-06-30 10:38:21 UTC
Created attachment 74461 [details]
messages.log booted with drm.debug=0xe

Hi,

i was advised to create a new report for my issue, so here it is:
I have a problem booting the new Macbook Air 5,2 (Mid 2012). When udev
runs and loads the i915 driver the screen flickers short and then turns black
(two seconds without backlight, than the backlight turns on again, but the screen remains black)

If i disable kms (by adding an unkown module option, like i915.diescreaming=1) it boots and with xf86-video-fbdev i'm also able to start X.

I also noted that if i plug an external monitor to the thunderbolt/minidisplay
port that (booting with enabled kms) the display gets on, right
after the internal display turned off, but with the resolution of the internal
display.

I already tested this with the 3.4.4 kernel (default archlinux kernel) and the 3.5
mainline kernel.

I don't know if it matters, but i'm starting linux with grub2 efi, i also needed to add noapic to the kernel line, because otherwise the screen turns instantly black after grub finished. I think the reason for that is a interrupt related kernel panic.

Thanks for your Help!
Comment 1 Dominik Meissner 2012-06-30 10:39:00 UTC
Created attachment 74471 [details]
output of lspci -vvvnn
Comment 2 Daniel Vetter 2012-06-30 13:45:24 UTC
Can you please test with my cpu_edp-abomination branch from my personal git repo at http://cgit.freedesktop.org/~danvet/drm ? That one fixes a few edp issues I've seen on my own ivb laptop, and I suspect your new MBA has a similar panel output config (and hence might suffer from similar issues). Branch is based on 3.5-rc4 + a few patches from drm-intel
Comment 3 Dominik Meissner 2012-06-30 14:56:54 UTC
Created attachment 74501 [details]
messages.log with cpu_edp-abomination

unfortunately does not work, but there is no screen flickering, it instantly got black. Is there some additional information, i could provide?
Comment 4 Dominik Meissner 2012-07-02 06:29:13 UTC
I think this is an eDP related issue. The new Macbook Air's internal display is plugged in via an embedded DisplayPort, the old Macbook Air still via LVDS.

When i wait until the System booted and blindly login in X, then start a Terminal and then type:
$ xrandr --output eDP1 --off
$ xrandr --output eDP1 --auto

After that the screen works as desired.
I'll attach the Xorg.log and a xrandr --verbose.

I'm currently using your drm-intel-fixes branch, but the mainline should also work (i'm going to confirm this later).
Comment 5 Dominik Meissner 2012-07-02 06:30:31 UTC
Created attachment 74531 [details]
Xorg.log started with the intel driver
Comment 6 Dominik Meissner 2012-07-02 06:33:38 UTC
Created attachment 74541 [details]
output of xrandr --verbose
Comment 7 Daniel Vetter 2012-07-02 08:33:26 UTC
On Mon, Jul 2, 2012 at 8:29 AM,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
> --- Comment #4 from Dominik Meissner <dominik.meissner@uni-ulm.de> 
> 2012-07-02 06:29:13 ---
> I think this is an eDP related issue. The new Macbook Air's internal display
> is
> plugged in via an embedded DisplayPort, the old Macbook Air still via LVDS.

Yeah, eDP is pain :( Can you please do some further tests, just to
confirm that what you're seeing on your eDP machine is similar to what
I'm seeing here on mine. Please switch the crtc of the panel with
(after it's working)

xrandr --output eDP1 --auto --crtc 1

take a note of how well this works and then switch back

xrandr --output eDP1 --auto --crtc 0

If switching to crtc 1 doesn't work the first time around, please try
again (it should work then). Afterwards, please grab the output of the
intel_reg_dumper tool from the intel-gpu-tools git at:

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Comment 8 Dominik Meissner 2012-07-02 10:33:29 UTC
Created attachment 74551 [details]
output of intel_reg_dumper after executing both commands

after executing "xrandr --output eDP1 --auto --crtc 1" my screen turned black (but the cursor remained), after switching back, everything was normal again.
Comment 9 Daniel Vetter 2012-07-02 10:46:31 UTC
> --- Comment #8 from Dominik Meissner <dominik.meissner@uni-ulm.de> 
> 2012-07-02 10:33:29 ---
> Created an attachment (id=74551)
>  --> (https://bugzilla.kernel.org/attachment.cgi?id=74551)
> output of intel_reg_dumper after executing both commands
>
> after executing "xrandr --output eDP1 --auto --crtc 1" my screen turned black
> (but the cursor remained), after switching back, everything was normal again.

Exact same symptoms as I have. Unfortunately the git branch is a
decent hack and not quite correct in all corner cases, so I guess your
machine is stumbling over a few issues still.

To confirm this a bit more, can you please try the cpu_edp branch
again, do the crtc switching as above and then grab another
intel_reg_dumper afterwards?
Comment 10 Dominik Meissner 2012-07-02 12:17:08 UTC
Created attachment 74561 [details]
output of intel_reg_dumper after switching to crtc 1
Comment 11 Dominik Meissner 2012-07-02 12:18:27 UTC
Created attachment 74571 [details]
output of intel_reg_dumper after switching back to crtc 0

This time switching to crtc 1 worked, or at least my display worked as with crtc 0.
Comment 12 Daniel Vetter 2012-07-02 12:35:27 UTC
> --- Comment #11 from Dominik Meissner <dominik.meissner@uni-ulm.de> 
> 2012-07-02 12:18:27 ---
> This time switching to crtc 1 worked, or at least my display worked as with
> crtc 0.

... and the reg dump also confirms the story ;-) Thanks for testing.
Real patches to really fix this might take a while, it's a rather
fundamental issue with our current code.
Comment 13 Daniel Vetter 2012-07-11 15:06:23 UTC
Please test the ivb-edp-fixpile from my personal git repo. That contains the modeset rewrite, which includes the ivb cpu edp bugfix. At least on my ivb machine, this works now rather well.

http://cgit.freedesktop.org/~danvet/drm/

Testing feedback highly welcome, especially whether there are any corner cases left. Also please check dmesg, the new code has grown tons of WARNs to cross check the modeset state tracking with the actual hw state.
Comment 14 Daniel Vetter 2012-07-11 19:06:24 UTC
Actually that branch has broken dpms handling, so once the screens suspends it won't wake up. Please use the modeset-rework branch instead, that is fixed up ...
Comment 15 Dominik Meissner 2012-07-12 14:15:45 UTC
Created attachment 75261 [details]
messages.log with modeset-rework branch

I've now tried your modeset-rework branch.
Screen flickers, then turns black (but this time, also the backlight turns off)
Should I try the ivb-edp-fixpile, too?
Comment 16 Daniel Vetter 2012-07-12 18:14:34 UTC
Hm, that's disappointed. ivb-edp-fixpile is the same code, just as wip before I've integrated it into the modeset rework.

Can you please do the crtc switching dance again on the modeset-rework branch and then again grab an intel_reg_dump? Also, do any of the old tricks (--off --auto) still help?
Comment 17 Dominik Meissner 2012-07-15 12:48:21 UTC
Created attachment 75391 [details]
dmesg with modeset-rework branch
Comment 18 Dominik Meissner 2012-07-15 12:50:05 UTC
Created attachment 75401 [details]
intel_reg_dump before switching crtc
Comment 19 Dominik Meissner 2012-07-15 12:51:06 UTC
Created attachment 75411 [details]
intel_reg_dump after switching to crtc 1
Comment 20 Dominik Meissner 2012-07-15 12:51:38 UTC
Created attachment 75421 [details]
intel_reg_dump after switching back to crtc 0
Comment 21 Dominik Meissner 2012-07-15 12:59:48 UTC
Now I had enough time to perform all tests.

While booting the eDP turns off, but all external monitors turned on.
All crtc switching and off and on turning, turned the backlight off and on again, but without showing anything on the screen.
At all I wasn't able to get the internal screen working.

The only thing changed in the output of the intel_reg_dumper was the RC6p_RESIDENCY_TIME:

before:   RC6p_RESIDENCY_TIME: 0x05b9080b
crtc_1:   RC6p_RESIDENCY_TIME: 0x07b924af
after:    RC6p_RESIDENCY_TIME: 0x08f63033

I hope the information help further.
Comment 22 Daniel Vetter 2012-09-20 14:31:20 UTC
Can you please retest on latest drm-intel-next-queued from http://cgit.freedesktop.org/~danvet/drm-intel/

There's an additional patch from Dave Airlie in there (on to of the ivb cpu edp fixes which are required afaict, too) which should help.
Comment 23 Florian Mickler 2012-10-15 21:22:14 UTC
A patch referencing this bug report has been merged in Linux v3.7-rc1:

commit 3739850b46f560a2be29287c3e5c29999d1a7e0e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Sep 6 22:15:44 2012 +0200

    drm/i915: disable the cpu edp port after the cpu pipe
Comment 24 Daniel Vetter 2012-10-15 21:36:44 UTC
Ping for the retest (you can test on 3.7-rc1, too). If you retest, please attach a full dmesg with drm.debug=0xe added to your kernel cmdline, thanks.
Comment 25 Daniel Vetter 2012-11-13 12:07:47 UTC
Ok, in addition to testing 3.7 kernels, you should also test the latest drm-intel-next-queued branch from

http://cgit.freedesktop.org/~danvet/drm-intel

it contains some additional improvements for the eDP backlight code, which might also help.
Comment 26 Jesse Barnes 2012-12-12 19:37:15 UTC
Dominik, any chance to test the latest bits?  Daniel fixed a lot of IVB eDP issues in the past release, hopefully your issue is fixed as well.
Comment 27 Jani Nikula 2013-04-10 13:44:03 UTC
Ping. Dominik, please try the latest kernels and report back.
Comment 28 Jani Nikula 2013-04-30 07:21:44 UTC
No word from reporter in 9 months, plenty of fixes merged since. Assuming fixed, please reopen if the problems persist.