<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - vgaswitcheroo doesn't deal with powered off dGPU on resume" href="https://bugs.freedesktop.org/show_bug.cgi?id=65068#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - vgaswitcheroo doesn't deal with powered off dGPU on resume" href="https://bugs.freedesktop.org/show_bug.cgi?id=65068">bug 65068</a> from <a class="email" href="mailto:austin.lund@gmail.com" title="Austin Lund <austin.lund@gmail.com>"> Austin Lund</a> <pre>(In reply to <a href="show_bug.cgi?id=65068#c5">comment #5</a>) > (In reply to <a href="show_bug.cgi?id=65068#c4">comment #4</a>) > > I'm not sure if this has anything to do with this bug, but the PCI config > > space is all messed up when running on the integrated GPU: > > When you disable the GPU the hardware is physically powered off so you are > accessing non-existent registers. You need to power up the GPU using > vgaswitcheroo before loading/resuming the driver or access the config space > with lspci. I guess what I was trying to say was, does having the device in this state before you start suspend make the power management subsystem confused? Will it try to "restore" the pci configuration space to 0xff? The radeon GPU is definitely turned on by the firmware on resume and the apple-gmux driver turns it off if that was the state of the system when suspend was started. I tried a quick hack to call the "ON" function for vga-switcheroo from the apple-gmux driver suspend hook. But that didn't work. However, if I do it manually (i.e. echo ON > /sys/kernel/debug/vgaswitcheroo/switch) before suspend, then it does seem to fix it.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>