<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3" href="https://bugs.freedesktop.org/show_bug.cgi?id=106597#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on Alienware 15R3" href="https://bugs.freedesktop.org/show_bug.cgi?id=106597">bug 106597</a> from <a class="email" href="mailto:lukas@wunner.de" title="Lukas Wunner <lukas@wunner.de>"> Lukas Wunner</a> <pre>So hda_call_codec_suspend() tries to set the codec's power state to D3 by calling hda_set_power_state(). The return value of that is the 32 bit response detailed on page 151 ff. of the HDA spec. hda_codec_runtime_suspend() then checks if the PS-ClkStopOk bit (bit 9) is set. Only then does it allow suspend of the codec. That bit is not set. It's also not set for the other two codecs of your machine (in the Intel HDA controller). And there's another oddity, the 32 bit response should contain the actual power state in bits 7:4, but those bits are always cleared, for all codecs and regardless whether the codec was put into D0 or D3. In other words, the codecs all remain in D0 even if we tell them to go to D3. Moreover, bits 0:3 of the response should contain the last power state set, but those bits are always either set to D0 or D1. But according to the power capabilities of the AMD HDA controller, it only supports D0 and D3, not D1. So this looks totally bogus. Let me test the debug patch on my own machine and check what the response looks like there.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>