This used to work on 958d073869404f60e56dc0cc70b3e7de85904694 but is broken at 428125c095b18c2a2864c1aef24ac0f384b6be54. I will try to find the exact commit that broke it.
the regression was caused by c7eeda8c3f3514ba95ebf2893fbe124bf526b3df. Let me know if you need more info.
Can you attach your vbios? As root: cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/imac27.rom echo 0 > rom
Created attachment 35875 [details] rom
FYI, reverting c7eeda8c3f3514ba95ebf2893fbe124bf526b3df on top of current master (f64bf0de8e2de7c1bf9cc0c614603dd23c9060ad) also fixes the problem. Too busy right now to debug this for real, but might be able to do so next week.
That commit doesn't really break anything per se. Before that commit the driver wasn't touching the display hardware for that connector so you ended up with the output in the state left by the bios. The problem is the dp link training is not completing so the display never comes up. There seems to be a general issue training 2560x1440 dp monitors. I suspect this is a case where there are several different combinations of link rates and lanes that could support that mode, but the monitor only likes certain ones.
Thanks for the info. Are there any debug printfs that I could add to list the available "link rates and lanes" being listed and the one being selected?
Can you dump the regs from a working setup (bios/vesa/fglrx) using avivotool? You can get avivotool here: http://cgit.freedesktop.org/~airlied/radeontool/ Also, please apply this patch to avivotool: https://bugs.freedesktop.org/attachment.cgi?id=34810 To dump the regs, make sure the monitor is on and working, and then dump the regs: avivotool regs all > working.dump For comparison, dump the regs using the non-working radeon driver: avivotool regs all > broken.dump Note that you must be root to use avivotool. Also try to use the same mode (e.g., 2560x1440) with both dumps if possible.
can you attach a dmesg when booting to runlevel with drm.debug=15?
Created attachment 37164 [details] working dump
Created attachment 37165 [details] [review] Another working dump I noticed that the dump was not stable, so I am attaching a dump from a second run.
Created attachment 37166 [details] [review] dmesg of a boot to a working setup Looks like with drm.debgug=15 the buffer is full very early. Let me know if part you are interested in is not on this file.
Created attachment 37167 [details] [review] dump of a non-working display
Created attachment 37168 [details] [review] second dump of a non-working display
This seems to be a general issue with 2560x1440 panels. *** This bug has been marked as a duplicate of bug 27314 ***
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.