At Mon, 10 Sep 2012 18:50:04 +1000, Dave Airlie wrote: > > On Mon, Sep 10, 2012 at 6:47 PM, Takashi Iwai <tiwai@xxxxxxx> 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@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. > > 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. Does your tree contain the recent patches in sound git tree for-next branch, or it's based on 3.6-rc? The former contains some patches to make the controller going to D3, so this might have some side effect. Takashi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
