<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [SKL][Audio][HD-A Display]: Can't detect Display audio codec if not connect HDMI and DP monitor when boot up" href="https://bugs.freedesktop.org/show_bug.cgi?id=89419#c17">Comment # 17</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [SKL][Audio][HD-A Display]: Can't detect Display audio codec if not connect HDMI and DP monitor when boot up" href="https://bugs.freedesktop.org/show_bug.cgi?id=89419">bug 89419</a> from <a class="email" href="mailto:imre.deak@intel.com" title="Imre Deak <imre.deak@intel.com>"> Imre Deak</a> <pre>Hi, (In reply to Libin Yang from <a href="show_bug.cgi?id=89419#c15">comment #15</a>) > Hi Imre, > > Based on my experience, EM4/5 impacts on the playback speed, I don't think > it will impact on the audio codec detection. (Actually before we detect HDMI > codec, we will never touch such registers) What I meant is that the EM4/5 registers do not exist on SKL. Adding simply the AZX_DCAPS_I915_POWERWELL flag to AZX_DCAPS_INTEL_SKYLAKE would result in programming these registers also on SKL, which is incorrect, so that programming needs to be avoided. > For the power well, yes, we need set the power well before HDMI codec > detection. And the audio driver does do it already. It didn't do it, you need to set AZX_DCAPS_I915_POWERWELL for that. > After power well on, we will do the HDMI codec detection. We won't power off > the power well before HDMI codec detection. > > BTW: I have asked the BIOS team about this issue. They told me that we > should: > 1. update the BIOS to latest (we have already done) > 2. update the gfx driver to latest(windows). So I believe that BIOS may have > changed some interfaces with gfx for this issue. Maybe we missed the change? I'm not aware of any other interaction between the gfx and sound driver besides what is done via the i915/audio component framework. For SKL in practice this means turning on and off power well 2. I still suspect that after turning power well 2 off then back on (this sequence actually happens based on the attached dmesg) some of the audio HW state gets reset and is not reinitialized properly. I would probably start enabling debugging in the sound driver and see where the detection fails. (In reply to Libin Yang from <a href="show_bug.cgi?id=89419#c16">comment #16</a>) > Hi Imre, > > I found SKL doesn't apply the powerwell flag. I will test by adding the flag > although it shouldn't add the flag here. Will update the test result later. Not sure what you mean here. The sound driver needs to turn on/off its dependent power well (power well 2 in case of SKL), and it does this on platforms with the AZX_DCAPS_I915_POWERWELL flag set. So the flag needs to be set for SKL.</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> </ul> </body> </html>