<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [VLV Bisected] Delayed boot and distorted text console after commit 773538e8" href="https://bugs.freedesktop.org/show_bug.cgi?id=86201#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [VLV Bisected] Delayed boot and distorted text console after commit 773538e8" href="https://bugs.freedesktop.org/show_bug.cgi?id=86201">bug 86201</a> from <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>(In reply to Egbert Eich from <a href="show_bug.cgi?id=86201#c4">comment #4</a>) > (In reply to Ville Syrjala from <a href="show_bug.cgi?id=86201#c3">comment #3</a>) > > You have this? > > > > commit 1e74a324465e5a4f8e3ee7c423aef92c54de8a72 > > Author: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>> > > Date: Tue Oct 28 16:15:51 2014 +0200 > > > > drm/i915: Initialize PPS timestamps on vlv/chv > > Yup. > > HEAD of my build is at > > commit ea361c1700ccb5acdc0f5970fd4d64c94c6aa6ee > Author: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>> > Date: Wed Nov 12 10:28:50 2014 +0100 > > drm-intel-nightly: 2014y-11m-12d-09h-28m-33s UTC integration manifest The log is from an older kernel since it doesn't have the port information in the vdd debug messages. But I guess you're sayng it still happens with the more recent kernels too. Apart from the massive delay there's one other WTF in the logs: [ 3.840671] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x87d00001, PP_OFF 0x1f40001, PP_DIV 0x270f06 [ 5.068936] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x80000001, PP_OFF 0x1, PP_DIV 0x270f00 I'm left wondering what happened to the delays we had in those registers. Somehow they got zeroed after we already computed them to !=0 values. Althoguh that issue was already present in the "good" log. Also can you make edp_panel_vdd_on() dump a backtrace so we can see where it's coming from. I guess it's some AUX stuff (EDID read perhaps). I can't see why it would suddenly take forever. Especially since it doesn't appear to time out or anything. I don't see any "disabling display" power well debug messages in the log, so at least resetting pps_pipe doesn't seem to happen anywhere. The other part of the patch adds the power_domain get/put around the pps_mutex, but since we have init power enabled here, these should be mostly nops. It does mean we grab and release the power domain mutex a few extra times as well, so there's some overhead, but I would think there would have to some serious contention on the lock to get this kind of effect. Sadly I can't reproduce this here.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>