On Mon, Sep 10, 2012 at 6:47 PM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 10 Sep 2012 15:04:02 +1000, Dave Airlie wrote:
On Mon, Sep 10, 2012 at 2:31 PM, Dave Airlie airlied@gmail.com wrote:
For optimus and powerxpress setups where we can explicitly power off the GPU I'd like to do this under control of the driver. Now that I've added X server support for secondary GPUs, it makes sense to start powering them down more often if we can.
I've tested this code on two laptops, one intel/nouveau one intel/radeon It works, powertop says I use 5-6W less power.
Caveats: There is a race at X server start with platform probing code, if the secondary device is off, we the wrong PCI info for it, I've got a patch that works around this I'll send to the xorg-devel.
Audio seems to get screwed at least on one machine, we power up and the alsa callbacks into snd_hda_intel get called but it can't find the hw properly, need to investigate a bit further.
Dave.
Hi Takashi,
just wondering how well setup alsa would be for the dGPU powering up/down a lot more often, 139.529103] nouveau [ DRM][0000:01:00.0] resuming display... [ 139.833960] ALSA sound/pci/hda/hda_intel.c:2533 Enabling 0000:01:00.1 via VGA-switcheroo [ 139.844789] snd_hda_intel 0000:01:00.1: Refused to change power state, currently in D3 [ 139.915760] snd_hda_intel 0000:01:00.1: Refused to change power state, currently in D3
These come from PCI core, and...
[ 140.917437] ALSA sound/pci/hda/hda_intel.c:813 spurious response 0x0:0x3, last cmd=0x301f0500 [ 140.917449] ALSA sound/pci/hda/hda_intel.c:813 spurious response 0x0:0x3, last cmd=0x301f0500 [ 140.917455] ALSA sound/pci/hda/hda_intel.c:813 spurious response 0x0:0x3, last cmd=0x301f0500 [ 140.917460] ALSA sound/pci/hda/hda_intel.c:813 spurious response 0x0:0x3, last cmd=0x301f0500 [ 140.917465] ALSA sound/pci/hda/hda_intel.c:813 spurious response 0x0:0x3, last cmd=0x301f0500
These are from hda-codec. The verb 0x301f0500 is GET_POWER_STATE verb, so it looks like that the hardware doesn't respond to any h/w state query / change.
is just some of the things I see, if I turn off before snd_hda_intel, things go badly wrong when I do power up the dGPU, if I delay the power off until audio is loaded, I start to see wierd things when pulseaudio starts when the dGPU is off.
What does your patch do? Sorry, I still haven't followed your patch yet.
It turns the GPU off completely on a timer, so 5s after we have no activity we cut the power to the GPU completely,
but I call the switcheroo callbacks properly and it should be bringing the power back up correctly, unless there is some initialisation delay or the audio hw comes up in a wierd state.
Though it should be no different than using the ON/OFF stuff that we have now.
The message from PCI core makes me wonder whether the GPU is really active at that point. Since it's just a call of pci_set_power_state(PCI_D0) at the beginning of resume procedure, it's rather a problem in a deeper level than the audio controller itself. The following spurious response messages are likely the result of the controller being still in D3.
That can happen where the device has gone into a really wierd place and just won't come back
I might try adding some delays tomorrow.
Dave.