<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:imre.deak@intel.com" title="Imre Deak <imre.deak@intel.com>"> <span class="fn">Imre Deak</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [regression] Loss of i915 (Apollo Lake/Broxton) HDMI audio after display sleep v4.14+"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104952">bug 104952</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>imre.deak@intel.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [regression] Loss of i915 (Apollo Lake/Broxton) HDMI audio after display sleep v4.14+"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104952#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [regression] Loss of i915 (Apollo Lake/Broxton) HDMI audio after display sleep v4.14+"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104952">bug 104952</a>
from <span class="vcard"><a class="email" href="mailto:imre.deak@intel.com" title="Imre Deak <imre.deak@intel.com>"> <span class="fn">Imre Deak</span></a>
</span></b>
<pre>Created <span class=""><a href="attachment.cgi?id=137189" name="attach_137189" title="Debug patches">attachment 137189</a> <a href="attachment.cgi?id=137189&action=edit" title="Debug patches">[details]</a></span>
Debug patches
In reply to Simon Casey from <a href="show_bug.cgi?id=104952#c3">comment #3</a>)
<span class="quote">> So the issue does seems to be somehow triggered by 42d9366d41a992.</span >
Ok, thanks for the effort.
I still suspect that some unintended dependency on timing causes this. Looking
at azx_rirb_get_response() it's obvious there is some magic involved when
accessing the audio codec. So based on that I'd like to ask you to try a few
debug patches on top of 42d9366d4 I attached to the bug to narrow down the root
cause.
First, could you reproduce the bug and get the stacktrace with
0001-sound-hda-Print-stack-dump-during-probe-failure.patch
?
One thing that 42d9366d4 changes is that intel_wait_for_register() is used
instead of wait_for() to wait for the power well enabled status. This means
we'll potentially complete the wait faster than before, as
intel_wait_for_register() uses a 2 usec atomic wait before doing a sleeping
wait. But that should be fine and nothing should depend on any delays there. To
check for such a dependency, could you try if the problem goes away with
0002-drm-i915-Don-t-spin-wait-during-power-well-enabling.patch
(without the other patches)?
If with the above you can't reproduce the problem, could you try the same with
0002-drm-i915-Don-t-spin-wait-during-power-well-enabling.patch
(again without the other patches)?
Thanks.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>