At Mon, 10 Sep 2012 15:04:02 +1000, Dave Airlie wrote: > > On Mon, Sep 10, 2012 at 2:31 PM, Dave Airlie <airlied@xxxxxxxxx> 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. 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. thanks, Takashi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel