Bug 28070

Summary: [Arrandale] No output (black) on eDP
Product: xorg Reporter: Dick Marinus <dick>
Component: Driver/intelAssignee: Wang Zhenyu <zhenyu.z.wang>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: aenertia, ben, cdiego, changsijay, infinity_0_8, jg, j.schauer, keyzer.suze, kincaid.dave, marcel.hess83, niveditha.rau, pjssilva, sergio, zhenyu.z.wang
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
intel_reg_dump
none
dmesg
none
dmesg-drm.debug=0x04
none
vbios
none
xrandr-verbose
none
dmesg-2.6.33
none
intel_reg_dump-2.6.33
none
dmesg-ajax
none
intel_reg_dump_nomodeset
none
[Patch 1/2]: set the DP sync polarity according to the desired mode
none
[Patch 2/2]: try the max link rate
none
dmesg-ykzhao
none
intel_reg_dump_ykzhao
none
dmesg-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
none
intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
none
intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
none
portions of the syslog that show the crash to the system none

Description Dick Marinus 2010-05-11 12:52:45 UTC
I'm using git tip sources for intel-drm, (lib)drm and xf86-video-intel. Everything seems to work but my display is black (backlight is on).

xrandr output:
# DISPLAY=:0.0 xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1920x1080      60.0*+   40.0  
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
DP4 disconnected (normal left inverted right x axis y axis)

I can disable the backlight using xrandr --output DP1 --off
Comment 1 Dick Marinus 2010-05-11 12:53:30 UTC
Created attachment 35578 [details]
Xorg.0.log
Comment 2 Dick Marinus 2010-05-11 12:54:37 UTC
Created attachment 35579 [details]
intel_reg_dump
Comment 3 Dick Marinus 2010-05-11 12:55:33 UTC
Created attachment 35580 [details]
dmesg
Comment 4 ykzhao 2010-05-12 00:35:59 UTC
From the info in comment #2 it seems that the eDP port is not enable. Not sure why it is not enabled.
Will you please add the boot option of "drm.debug=0x04" and attach the output of dmesg? (Had better compile the i915 as built-in kernel module).

It will be great if you can also try it on 2.6.33 kernel and see whether the issue also exists. Please also attach the output of dmesg, intel_reg_dumper on 2.6.33 kernel.

Please attach the vbios.dump on this box, which can be obtained by using the following command:
    1. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
    2. cat /sys/devices/pci0000:00/0000:00:02.0/rom >vbios.dump
    3. echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom

Please also attach the output of "xrandr -q --verbose" on this box.

Thanks.
Comment 5 Dick Marinus 2010-05-12 01:43:51 UTC
Created attachment 35584 [details]
dmesg-drm.debug=0x04
Comment 6 Dick Marinus 2010-05-12 01:58:27 UTC
Created attachment 35585 [details]
vbios
Comment 7 Dick Marinus 2010-05-12 02:01:21 UTC
Created attachment 35586 [details]
xrandr-verbose
Comment 8 Dick Marinus 2010-05-12 02:16:37 UTC
Created attachment 35587 [details]
dmesg-2.6.33
Comment 9 Dick Marinus 2010-05-12 02:17:30 UTC
Created attachment 35588 [details]
intel_reg_dump-2.6.33

The problem persists using this kernel (2.6.33)
Comment 10 ykzhao 2010-05-12 17:41:30 UTC
Hi, Zhenyu
    any idea about this issue on eDP panel?

thanks.
Comment 11 Wang Zhenyu 2010-05-12 19:34:27 UTC
I haven't tried current driver for eDP recently. Could you try drm-intel-next to see how's going?
Comment 12 Wang Zhenyu 2010-05-12 19:48:01 UTC
Please help to test ajax's patch at http://lists.freedesktop.org/archives/intel-gfx/2010-May/006847.html
Comment 13 Gordon Jin 2010-05-12 20:12:18 UTC
(In reply to comment #11)
> I haven't tried current driver for eDP recently. Could you try drm-intel-next
> to see how's going?

drm-intel-next is probably broken on Ironlake now: bug#28046

Dick, is this regression on this machine?
Comment 14 Dick Marinus 2010-05-13 01:34:59 UTC
(In reply to comment #13)
> (In reply to comment #11)
> > I haven't tried current driver for eDP recently. Could you try drm-intel-next
> > to see how's going?
> 
> drm-intel-next is probably broken on Ironlake now: bug#28046
> 
> Dick, is this regression on this machine?

I've first tried drm-intel-next and later "vanilla" 2.6.33 they both aren't working.
Comment 15 Dick Marinus 2010-05-13 07:59:20 UTC
Created attachment 35625 [details]
dmesg-ajax

I've tried the patch from ajax (using intel-drm-next sources) but it still doesn't give any output.
Comment 16 Dick Marinus 2010-05-13 08:08:42 UTC
I'm using drm-intel-next on Ironlake but I don't have the errors like bug#28046. My output is still black.
Comment 17 Adam Jackson 2010-05-13 10:47:45 UTC
Can you please also attach intel_reg_dump output from booting with nomodeset?
Comment 18 Dick Marinus 2010-05-13 11:07:55 UTC
Created attachment 35629 [details]
intel_reg_dump_nomodeset
Comment 19 Dick Marinus 2010-05-15 10:29:36 UTC
From mailing list:
> We just have one 1366x768 panel which works fine for me last time I tried,
> but that [this] bug has a larger one, and from log it seems driver still
> use 1.6Ghz which may lead to the problem as you addressed.
Ick.  His VBT reports 1.62GHz x1, which is definitely not going to hold
a 1920x1080 mode.  Guess we'll have to do this the hard way.


I really like to know what the "hard way" is :)
Comment 20 Dick Marinus 2010-05-19 02:30:29 UTC
Ajax told me yesterday he is a little bit behind because he broke his arm. 
Best wishes for a speedy recovery!
Comment 21 ykzhao 2010-05-21 07:13:33 UTC
Created attachment 35782 [details] [review]
[Patch 1/2]: set the DP sync polarity according to the desired mode
Comment 22 ykzhao 2010-05-21 07:14:15 UTC
Created attachment 35783 [details] [review]
[Patch 2/2]: try the max link rate
Comment 23 ykzhao 2010-05-21 07:16:42 UTC
Hi, Dick
    Will you please try the two debug patches in comment #21/22 on the 2.6.33 kernel and see whether it is helpful?
    Please add the boot option of "drm.debug=0x04" and attach the output of dmesg. Please also attach the output of intel_reg_dumper.

Thanks.
    Yakui
Comment 24 Dick Marinus 2010-05-21 13:50:59 UTC
Created attachment 35789 [details]
dmesg-ykzhao

Thanks! It works
Comment 25 Dick Marinus 2010-05-21 13:51:37 UTC
Created attachment 35790 [details]
intel_reg_dump_ykzhao
Comment 26 Wang Zhenyu 2010-05-23 18:57:58 UTC
Yakui, some comment for your patch. 

We already have the first one from ajax. For second one, maybe we can try to convert the loop with

for (clock = max_clock; clock >= 0; clock--) {..}

instead of always using max_clock. I'm not sure about if power consumption will be higher with high clock? And hopefully we don't have regression on some eDP panels?
Comment 27 ykzhao 2010-05-24 02:43:25 UTC
(In reply to comment #24)
> Created an attachment (id=35789) [details]
> dmesg-ykzhao
> 
> Thanks! It works

Thanks for the testing. It is good news that the eDP can work after applying the two debugs patches in comment #21/22. The next step is to identify which patch is required to solve the issue.

Hi, Dick
   Can you try the debug patch in comment #21/22 one by one and see whether the issue can be resolved? 

thanks.
   Yakui
Comment 28 Dick Marinus 2010-05-24 08:40:49 UTC
It still works when I only apply the first patch (from comment #21, 0001-set-the-DP-sync-polarity-according-to-the-desired-mo.patch). Do you want me to try the second patch (without the first)?
Comment 29 Jim Gettys 2010-05-24 11:27:42 UTC
(In reply to comment #26)
> instead of always using max_clock. I'm not sure about if power consumption will
> be higher with high clock? And hopefully we don't have regression on some eDP
> panels?

Power consumption will always be higher at higher frequencies.  And some panels may only go so fast.  So using the maximum clock frequency, if that is what you are doing, is probably not a great idea, if lower options are available.  Most built-in panels go at 60hz, FWIW.
Comment 30 ykzhao 2010-05-24 17:52:09 UTC
(In reply to comment #28)
> It still works when I only apply the first patch (from comment #21,
> 0001-set-the-DP-sync-polarity-according-to-the-desired-mo.patch). Do you want
> me to try the second patch (without the first)?

It is good news that it still can work only when the first patch in comment #21 is applied.
Can you also try the second patch(without the first) and see whether it is helpful?

Thanks.
Comment 31 ykzhao 2010-05-24 19:41:34 UTC
(In reply to comment #29)
> (In reply to comment #26)
> > instead of always using max_clock. I'm not sure about if power consumption will
> > be higher with high clock? And hopefully we don't have regression on some eDP
> > panels?
> 
> Power consumption will always be higher at higher frequencies.  And some panels
> may only go so fast.  So using the maximum clock frequency, if that is what you
> are doing, is probably not a great idea, if lower options are available.  Most
> built-in panels go at 60hz, FWIW.

What I am doing only affects the link rate of display port. It has no effect on the clock for eDP panel. 
I agree with your concern. The power consumption will be higher when using the high link rate for display port.

I look at the bios code and it seems that the BIOS code uses the high link rate to calculate the link setting for the eDP. Maybe it is safe, which can assure that the system has the correct the link setting.

On the Dick's laptop: before applying the patches in comment #21/22, lane count is 2, and low link rate(1.62G) is used. The active pixel rate occupies nearly 96% bandwidth of the link.
    (137.7 * 18 / 8) / (162 * 2) = 95.6%
    
Let's wait for the Dick's test result and see whether the high link rate is helpful to solve the issue.

thanks.
Comment 32 Dick Marinus 2010-05-25 12:10:48 UTC
I've tried the second patch - try the max link rate (without the first) and I still have output. So both patches seem to work combined or seperate.

Please let me know when I need to do some other testing.
Comment 33 ykzhao 2010-05-25 20:14:35 UTC
(In reply to comment #32)
> I've tried the second patch - try the max link rate (without the first) and I
> still have output. So both patches seem to work combined or seperate.
> 
> Please let me know when I need to do some other testing.

Hi, Dick
   Thank you for the nice testing. It seems that the both two patches in comment #21/22 can solve the issue. 
   In fact the patch similar to that in comment #21 is already pushed by Ajax and in drm-intel-next tree.
    >commit 9c9e792795f96d201d85188607261f9f8bbf3219
Author: Adam Jackson <ajax@redhat.com>
Date:   Mon Apr 5 17:57:59 2010 -0400

    drm/i915: Set sync polarity correctly on DisplayPort

    Will you please test the drm-intel-next tree again and see whether the issue still exists?    

thanks.
Comment 34 ykzhao 2010-05-26 02:04:00 UTC
(In reply to comment #28)
> It still works when I only apply the first patch (from comment #21,
> 0001-set-the-DP-sync-polarity-according-to-the-desired-mo.patch). Do you want
> me to try the second patch (without the first)?

Will you please also attach the output of dmesg, intel_reg_dumper only when the patch in comment #21 is applied on 2.6.33 kernel?(The boot option of "drm.debug=0x04" should be added).

thanks.
Comment 35 Dick Marinus 2010-05-30 11:25:17 UTC
(In reply to comment #33)
> Will you please test the drm-intel-next tree again and see whether the
> issue still exists?

I've just tried drm-intel-next and it doesn't give any output on my eDP. (So my issue still exist using this kernel)
Comment 36 Dick Marinus 2010-05-30 11:57:20 UTC
Created attachment 35958 [details]
dmesg-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
Comment 37 Dick Marinus 2010-05-30 11:57:52 UTC
Created attachment 35959 [details]
intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
Comment 38 ykzhao 2010-05-30 22:22:58 UTC
(In reply to comment #37)
> Created an attachment (id=35959) [details]
> intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode

Hi, Dick
    From the register dump in comment #37 it seems that the eDP port is not enabled. 
    >PCH_eDP_A: 0x300c001c

    Will you please double check whether the system can work well only when the patch in comment #21 is applied on 2.6.33 kernel?

Thanks.
Comment 39 Dick Marinus 2010-05-31 10:39:53 UTC
Created attachment 35974 [details]
intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode

whoops, I guess gnome disabled the eDP when I logged in.
I hope this dump is better.
Comment 40 ykzhao 2010-06-06 18:14:13 UTC
(In reply to comment #39)
> Created an attachment (id=35974) [details]
> intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
> 
> whoops, I guess gnome disabled the eDP when I logged in.
> I hope this dump is better.

thanks for the confirmation.
From the log it seems that the issue can be resolved when the patch in comment #21 is applied on the 2.6.33 kernel. And the similar patch is already shipped in drm-intel-next tree as mentioned in comment #33.
    But it is very strange that the issue still exists when using drm-intel-next tree. Maybe the issue is affected by something else in drm-intel-next tree. the next step is to track which commit affects this issue.
    
    
    >
Comment 41 Jim Gettys 2010-06-16 15:23:26 UTC
(In reply to comment #40)

> thanks for the confirmation.
> From the log it seems that the issue can be resolved when the patch in comment
> #21 is applied on the 2.6.33 kernel. And the similar patch is already shipped
> in drm-intel-next tree as mentioned in comment #33.
>     But it is very strange that the issue still exists when using
> drm-intel-next tree. Maybe the issue is affected by something else in
> drm-intel-next tree. the next step is to track which commit affects this issue.
> 

Any progress figuring out why drm-intel-next is having trouble?
              - Jim
Comment 42 Geir Ove Myhr 2010-06-24 23:47:18 UTC
There is a new patch on the intel-gfx mailing list today that may fix this. http://lists.freedesktop.org/archives/intel-gfx/2010-June/007216.html
Comment 43 Dave Airlie 2010-06-24 23:48:01 UTC
http://lists.freedesktop.org/archives/intel-gfx/2010-June/007216.html

please try this patch.
Comment 44 Dave Airlie 2010-06-24 23:48:28 UTC
lols some ppl are faster than me ;-)
Comment 45 Dick Marinus 2010-06-25 11:10:23 UTC
Geir Ove Myhr, Dave Airlie thanks for pointing me to this patch. This fixes drm-intel-next for me! Please commit.
Comment 46 Dave Airlie 2010-06-27 16:48:27 UTC
new patch 

http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html

please test.
Comment 47 Andrew Klossner 2010-06-30 15:13:13 UTC
(In reply to comment #46)
> new patch 
> 
> http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html
> 
> please test.

I registered an account just to say:
This patch, applied to a kernel pulled today from kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git, makes my Dell Latitude E6510 (with Intel HD graphics, not the Nvidia option) work for the first time with mode setting.  Thanks!
Comment 48 Sérgio M. Basto 2010-06-30 16:00:49 UTC
*** Bug 28224 has been marked as a duplicate of this bug. ***
Comment 49 Sérgio M. Basto 2010-06-30 16:03:48 UTC
*** Bug 28746 has been marked as a duplicate of this bug. ***
Comment 50 Keyzer Suze 2010-06-30 20:10:20 UTC
(In reply to comment #47)
> (In reply to comment #46)
> > new patch 
> > 
> > http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html
> > 
> > please test.
> 
> I registered an account just to say:
> This patch, applied to a kernel pulled today from
> kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git, makes my Dell
> Latitude E6510 (with Intel HD graphics, not the Nvidia option) work for the
> first time with mode setting.  Thanks!

Hi

I tried this, against a debian 2.6.34-1 experimental.2 build, works as well, but if I start X with an external monitor attached the machine hangs....

I can attach after X has started.

So  (with i915 blacklisted)

1.a boot
1.b modprobe i915 modeset=1
1.c startx
1.d attached ext display
1.e xrandr add second display
works

2.a boot
2.b modprobe i915 modeset=1
2.c attach ext monitor
2.d startx
dead have to hold the  power button for a while

Alex
Comment 51 Keyzer Suze 2010-06-30 20:20:35 UTC
Created attachment 36650 [details]
portions of the syslog that show the crash to the system

This is the section of the syslog, that shows the crash when I try and start X with 2 screens (edp and external).

This is on a HP 2540p

Alex
Comment 52 Sérgio M. Basto 2010-07-01 08:23:18 UTC
Hi, I add CC the people which CC in others bigs that are marked as duplicated , 
I hope that don't miss any ... 

2nd,  I am testing kernel 2.6.33.5-137.fc13.x86_64 from http://koji.fedoraproject.org/koji/packageinfo?packageID=8 , which have the latest patch of airlied mention on this report. which works ...
Comment 53 Andrew Klossner 2010-07-01 11:15:22 UTC
(In reply to comment #46)
> new patch 
> 
> http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html
> 
> please test.

I tested this patch against mainline 2.6.34 and can report that this combination works on my Dell Latitude E6510.  (Which is good because I can avoid bleeding-edge problems in drm-intel-next like the udevd 100% bug.)
Comment 54 Keyzer Suze 2010-07-01 17:31:22 UTC
Done some more testing with suspending/hibernating and the patched driver.

the edp doesn't come back on, I have to attach a second screen, restart gdm/X and then use xrandr to restart the eDP.

So its nearly there, if only I could do this from the command line with one of the fb* tools.

Thanks
Comment 55 BenG 2010-07-02 06:17:20 UTC
FWIW, a build of (In reply to comment #53)
> (In reply to comment #46)
> > new patch 
> > 
> > http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html
> > 
> > please test.
> 
> I tested this patch against mainline 2.6.34 and can report that this
> combination works on my Dell Latitude E6510.  (Which is good because I can
> avoid bleeding-edge problems in drm-intel-next like the udevd 100% bug.)

FWIW, this patch also works with the E6410, when applied against a clean 2.6.34 kernel.

drm-intel-next, and 2.6.35 both seem to be problematic.

Thanks for chasing this down!
Comment 56 Keyzer Suze 2010-07-04 23:30:54 UTC
Hi

There is a still an issue with 2 monitors being attached when starting up #51 and attachment.


Or do I need to start a new bug report ?
Comment 57 Wang Zhenyu 2010-07-04 23:38:38 UTC
Yes, please.
Comment 58 Paulo J. S. Silva 2010-07-05 05:20:36 UTC
If you create a new bug report to deal with the problem with two monitors, please leave a message here with the new bug number.
Comment 59 Sérgio M. Basto 2010-07-05 11:12:26 UTC
(In reply to comment #54)
> Done some more testing with suspending/hibernating and the patched driver.
> 
> the edp doesn't come back on, I have to attach a second screen, restart gdm/X
> and then use xrandr to restart the eDP.
> 
> So its nearly there, if only I could do this from the command line with one of
> the fb* tools.
> 
> Thanks

see bug #28739, and comment there please, about  suspending/hibernating problems .
Comment 60 Keyzer Suze 2010-07-06 04:05:12 UTC
(In reply to comment #58)
> If you create a new bug report to deal with the problem with two monitors,
> please leave a message here with the new bug number.

done https://bugs.freedesktop.org/show_bug.cgi?id=28911
Comment 61 josch 2010-07-28 06:08:13 UTC
the exact same issue still persists with kernel 2.6.35-rc6+ (containing the latest commits up to 14h ago) even though the (supposedly) fixing patch is already included there.
this is on a dell E6510
can anybody confirm?
Comment 62 Chris Wilson 2010-07-28 06:26:53 UTC
josh, please do not hijack bug reports. This one was clearly identified and fixed, so if you are seeing a very similar bug on different hardware, you have a different bug and need to file a separate bug report.
Comment 63 Sérgio M. Basto 2010-07-28 12:33:42 UTC
(In reply to comment #61)
> the exact same issue still persists with kernel 2.6.35-rc6+ (containing the
> latest commits up to 14h ago) even though the (supposedly) fixing patch is
> already included there.
> this is on a dell E6510
> can anybody confirm?

To simplify , jost try fedora 13 updated with kernel , 

http://admin.fedoraproject.org/updates/kernel-2.6.33.6-147.2.4.fc13

as you can see the patch can be applied to kernel 2.6.33/4 ,
you may have lots of thing not updated
Comment 64 Dick Marinus 2010-08-27 07:15:34 UTC
(In reply to comment #61)
Josch is right, I've tried drm-intel git sources (2.6.36-rc2+) and I lost my working eDP. I've noticed not all (none?) of the patches referred in this bug report are committed to drm-intel.
I was using the drm patch from fedora but since an update of my kernel that doesn't work anymore either.
Comment 65 Chris Wilson 2010-09-11 01:46:37 UTC
(In reply to comment #54)
> Done some more testing with suspending/hibernating and the patched driver.
> 
> the edp doesn't come back on, I have to attach a second screen, restart gdm/X
> and then use xrandr to restart the eDP.
> 
> So its nearly there, if only I could do this from the command line with one of
> the fb* tools.
> 
> Thanks

The original bug has been fixed, so I am closing this report so that we can't focus on the remaining issues in separate bug reports.

There have been many more eDP fixes in

git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-next

so please bare those in mind when opening new bugs.
Comment 66 Joel Wiramu Pauling (aenertia) 2010-11-22 22:16:10 UTC
So should we concentrate on https://bugs.freedesktop.org/show_bug.cgi?id=29278
?

I can confirm that as of the 21/11/2010 that drm-intel and drm-intel-next based of the 2.6.37rc2 merges fail with an HP elitebook 2740p (Samsung touch eDP).

So I don't think anyone can say this is fixed upstream.
Comment 67 Sérgio M. Basto 2010-11-23 08:30:42 UTC
(In reply to comment #66)
> So should we concentrate on https://bugs.freedesktop.org/show_bug.cgi?id=29278
> ?
> 
> I can confirm that as of the 21/11/2010 that drm-intel and drm-intel-next based
> of the 2.6.37rc2 merges fail with an HP elitebook 2740p (Samsung touch eDP).
> 
> So I don't think anyone can say this is fixed upstream.

Fedora kernel works very well on dell latitude E6410,

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.