Re: [RFC] drm dynamic power off support

From: Dave Airlie <airlied@gmail.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC] drm dynamic power off support
Date: Mon, 10 Sep 2012 18:50:04 +1000	[thread overview]
Message-ID: <CAPM=9tyLX=HhTV5=1duifSFpVx2FRxLefFcsMTbo4+LxB_gkGA@mail.gmail.com> (raw)
In-Reply-To: <s5hwr02tgc6.wl%tiwai@suse.de>

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.