On Mon, Sep 10, 2012 at 6:47 PM, Takashi Iwai <tiwai at 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 at 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.
