(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > 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 reason you are getting 0xff is because you are accessing a disabled device.
 lspci would need to power up the GPU using vgaswitcheroo before accessing the
hardware.

> 
> 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 suspect the gmux driver resumes first and disables the hardware before the
radeon driver resumes. So the radeon driver resumes on disabled hardware.

> 
> 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.

Some one needs to sort out the interactions between the the vgaswitcheroo
drivers and the GPU drivers so that they do the right thing on suspend and
resume and hw access from userspace utilities like lspci.