Let me try to explain my findings: > How does this magic sequence come? By dumping Win7 driver's init sequence and reproducing it through ALSA driver.
>why does it need to set UNSOL flag at first? No such need, I've put it after regular init so that only affected chipsets are reset again. Putting this anywhere around init code works (tried it). >Is the while loop guaranteed to quit for a reasonable time? Being household user, I can only confirm on my chipset. Only a thorough testing may ensure sanity. >Can't it be simply calling azx_reset() twice? It is interesting hardware bug which kicks in only during first init after power-on. So if Win7 driver in qemu inits the board, and I simply plugin "unchanged" hda_intel afterwards, it still detects codecs. But multiple normal resets do not have any effect. Being no hardware expert, I can only speculate that tight spin loop after reset has the crux. A normal delay call there does not detect codec. >And, yet another question comes up: doesn't S4 need the similar workaround? If >S4 works, what's the difference? Haven't tried with sleep-wake or hibernate-restore sequence yet. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1155202 Title: [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1155202/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
