<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#c10">Comment # 10</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:eich@pdx.freedesktop.org" title="Egbert Eich <eich@pdx.freedesktop.org>"> Egbert Eich</a> <pre>Created <a href="attachment.cgi?id=109950" name="attach_109950" title="Fix: When enabling panel VDD cancel pending disable worker">attachment 109950</a> <a href="attachment.cgi?id=109950&action=edit" title="Fix: When enabling panel VDD cancel pending disable worker">[details]</a> <a href='page.cgi?id=splinter.html&bug=86201&attachment=109950'>[review]</a> Fix: When enabling panel VDD cancel pending disable worker I found the time to debug this. There are two issues: 1. In edp_panel_vdd_on() we don't cancel a vdd_off worker which may be pending. This may lead to the worker firing right in the middle of an EDID transfer. While this is most likely not what is expected it didn't cause the EDID to be misread - at least for my panel. Attached os a patch that attempts to fix this. 2. The long delay happens when the HZ is set to 250. I don't see it when it is set to 1000. Here is what's happening: on eDP pps_lock()/unlock() gets called on each low level transfer. This function can be quite expensive however: when checking if the power well is enabled vlv_sideband_rw() gets called this performs its tests in a wait_for() loop. Since these tests don't seem to succeed the first time around the test is redone after an 1 ms wait. With HZ set to 250 the granularity is higher 1 ms however and those waits add up. This can be seen easily by replacing wait_for() by wait_for_atomic() which retests after a 0 wait. In this case the long delay period disappears even for HZ=250. It is however waistful to perfrom those operations at the lowest level at intel_dp_aux_ch(). It would be better to wrap the entire i2c transfer by single calls to these functions. The current design of drm_dp_helper.c doesn't allow this however. I'm going to propose a patchset for this to the ML.</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>