[alsa-devel] HD-audio runtime PM

[Takashi Iwai]

At Tue, 26 Nov 2013 09:05:20 +0800,
Wang Xingchao wrote:
> 
> Hi Takashi,
> 
> 2013/11/22 Takashi Iwai <tiwai at suse.de>:
> > Hi,
> >
> > after my previous fix, the runtime PM seems working stably finally.
> > However, there seem still some glitches:
> >
> > 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
> >   test machines.  WAKEEN is set properly.  And its value can be read
> >   correctly at the point of runtime resume, too.
> >
> > 2. We don't change the device to D3 in runtime suspend.  So I guess we
> >   save little power as of now.
> >
> >   Actually, setting to D3 and resuming to D0 works fine, as far as I
> >   tested -- except for HDMI/DP ELD read out on Haswell.  Although ELD
> >   read doesn't give any errors, the received bytes are corrupted.  In
> >   my case, the read starts from offset 0x1c.
> >
> >   The HDMI can be still played even at that state, but then it falls
> >   back to the stereo 2ch mode, of course.
> >
> > The tests were performed on both Haswell (DP and LynxPoint-LP) and
> > IvyBridge (PantherPoint) machines.
> >
> > The first problem has been present, and it's also the behavior of some
> > old chips where the codec can't go to sleep with unsol wakeup.  So, in
> > this regard, it's no regression, per se.  But certainly it's no good
> > thing.
> >
> > I thought Mengdong once made WAKEEN working.  Mengdong, do you
> > remember what was the condition?  Could you check whether the latest
> > kernel (at best sound git tree for-linus branch) still works?
> >
> > About the second point: we should do D3 if we do care power, and
> > that's the very right reason for runtime PM.  But the ELD issue is a
> > bad bug, and it makes me wonder whether it's a graphics driver side
> > issue or a codec side.  As a quick workaround, we can implement D3 on
> > controllers but for Haswell HDMI/DP.
> 
> I didnot follow alsa-devel threads often now, is that ELD issue an
> regression from my previous commit?

I'm not sure whether it's a regression.  We need to track down.

> I test WAKEEN feature on Haswell machines before, it could really
> wakeup system from D3.

But the runtime suspend doesn't power down to D3 by itself.
Did you test really with D3?

> The controller must be in RESET mode after enter runtime-suspend,
> otherwise it will not be waken up
> even if codec send out wake-up event. And STATESTS will be cleared
> after controller brought out of RESET mode.

And I noticed that RESET mode makes some machines inconsistent,
e.g. the mute LED is reset on HP machines without keeping the previous
state.  I need to double-check whether this still happens with the
recent fixes.


thanks,

Takashi

> 
> thanks
> --xingchao
> >
> > In anyway, this is no urgent issue, clearly targeted for 3.14.
> > The whole patch series are found in my sound-unstable git tree
> > test/hda branch.
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
> >
> >
> > thanks,
> >
> > Takashi
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>