[Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell

[Takashi Iwai]

At Wed, 17 Jul 2013 02:52:41 +0000,
Wang, Xingchao wrote:
> 
> Hi Takashi/Paulo,
> 
> > > > would you change it to "auto" and test again.
> > > > Runtime power save should be enabled with "auto".
> > >
> > > Doesn't solve the problem. Should I open a bug report somewhere?
> > > Having the power well enabled prevents some power saving features from
> > > the graphics driver.
> > 
> > Is the HD-audio power-saving itself working?  You can check it via watching
> > /sys/class/hwC*/power_{on|off}_acct files.
> > 
> > power_save option has to be adjusted appropriately.  Note that many DEs
> > change this value dynamically per AC-cable plug/unplug depending on the
> > configuration, and often it's set to 0 (= no power save) when AC-cable is
> > plugged.
> > 
> [Wang, Xingchao] Paulo used a new Ultrabook board with charger connected, and see the default parameter "auto=on".
> In such scenario, power-well is always occupied by Display audio controller. Moreover, in this board, if no external monitors connected,
> It's using internal eDP and totally no audio support. Power-well usage in such case also blocks some eDP features as Paulo told me.
> 
> So I think it's not a good idea to break the rule of power policy when charger connected but it's necessary to add support in this particular case.
> Takashi, do you think it's acceptable to let Display audio controller/codec suspend in such case?

Do you mean the driver enables the powersave forcibly?
Then, no, not in general.

If the default parameter of autopm is the problem, this should be
changed, instead of forcing the policy in the driver.

OTOH, the audio codec's powersave policy is governed by the power_save
option and it's set up dynamically by the desktop system.  We
shouldn't override it in the driver.

If the power well *must* be off when only an eDP is used
(e.g. otherwise the hardware doesn't work properly), then it's a
different story.  Is it the case?   And what exactly would be the
problem?

If it's the case, controlling the power well based on the runtime PM
is likely a bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
 completely via Kconfig, too.)


Takashi