Status of Intel HDA powersave mode for Maverick

[Daniel Chen]

On Thu, May 27, 2010 at 10:50 PM, Chase Douglas
<chase.douglas at canonical.com> wrote:
> I queried you about this on IRC, but I think it would be easier to do
> this over email.

Sure (I also responded in the IRC channel, but timezones make for
interesting blocking).

> What's the status of Intel HDA powersave mode? In Lucid, when the mode
> is enabled we hear popping as the chip powers on. Will this be resolved
> for Maverick?

That symptom is largely dependent on the specific controller and codec
combination. It should be resolved for the Intel+Sigmatel/IDT
combination; NVidia+Conexant/Analog Devices/etc. are not as
well-tested. As I mentioned in the channel yesterday, we likely need
to sleep longer in the driver to allow for dissipation to occur, which
may mean reverting a patch [that reverts an earlier patch to sleep
longer!].

In short, I'd put forth that we have a decent chance to get this issue
sorted for Maverick, but it likely will mean carrying patches that are
not in 2.6.35.

> I'm working on the pm-utils-powersave-policy scripts, and I've been
> working under the assumption that this would be fixed for Maverick. Then
> we would just enable it by default at all times and drop the policy
> script that currently enables powersave mode when we go to battery
> power.

We (well, I) tried this back in Karmic, and the state is nominally
better now: Intel+Sigmatel/IDT are well-supported, but there are other
combinations. We should have a better idea by the beginning of August
(prior to Release Development Iteration three planning according to
the Maverick release schedule) whether it is feasible to enable
powerdown by default for all combinations.

Speaking of powerdown, I don't believe it's necessary to twiddle
/dev/dsp anymore, not the least due to /dev/dsp going the route of
ossp (and thus via PulseAudio, which will have the powerdown applied
when the device is resumed with PA's module-suspend-on-idle).

Best,
-Dan