Re: [RFC] drm dynamic power off support

[Takashi Iwai <tiwai@suse.de>]

At Mon, 10 Sep 2012 18:50:04 +1000,
Dave Airlie wrote:
> 
> 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.

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