[Bug 86201] [VLV Bisected] Delayed boot and distorted text console after commit 773538e8

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=86201

--- Comment #10 from Egbert Eich <eich at pdx.freedesktop.org> ---
Created attachment 109950
  --> https://bugs.freedesktop.org/attachment.cgi?id=109950&action=edit
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20141124/ae167826/attachment.html>