On Tue, May 12, 2015 at 8:04 PM, Dave Jones <davej@xxxxxxxxxxxxxxxxx> wrote: > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote: > > > > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, without any noticable > > > difference. Is there something else I can try to make it try harder before giving up? > > > > > > > Can you attach your boot dmesg output with drm.debug=0xf set? > > > > You might also check the dpcd values in the driver during boot up and > > link training. There appears to be an issue where that data gets > > corrupted in some cases: > > https://bugs.freedesktop.org/show_bug.cgi?id=73530 > > I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios for eDP' > patches from that bug. Again, no obvious difference. > > Log from kernel with both applied attached. > > Also a log file from after I woke up the LCD when it was in sleep mode. > > Something else curious is how it only discovers a maximum mode from the LCD > of 1024x768. I looks like the monitor is not responding. I'm not entirely sure what's going on. I posted a new debugging patch on the bug report that will dump the dpcd at various times to see if and when it's getting corrupt. Fixing that should at least get the monitor to come up reliably (assuming you are experiencing the same issue). Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
