[alsa-devel] HD-audio runtime PM

Lin, Mengdong mengdong.lin at intel.com
Tue Nov 26 09:53:00 CET 2013


> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Tuesday, November 26, 2013 3:28 PM
> To: Lin, Mengdong
> Cc: Wang Xingchao; Alsa-devel at alsa-project.org; David Henningsson
> Subject: Re: [alsa-devel] HD-audio runtime PM
> 
> At Tue, 26 Nov 2013 06:56:12 +0000,
> Lin, Mengdong wrote:
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > Sent: Tuesday, November 26, 2013 2:14 PM
> > > To: Wang Xingchao
> >
> > > > 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?
> >
> > I will double check this on Haswell with sound git tree for-linus branch.
> > We've tried Android on Haswell-ULT last week, the display HD-A
> controller can enter D3 and HDMI cable plug-in can wake up the controller
> and codec. The code base is v3.9 with various driver patches.
> 
> Hrm, but as I mentioned, we have no D3 call in runtime suspend callback.
> How does it reach to D3 then?  Maybe that part is patched in your side?
> 
> > For non-Haswell platforms, hardware team suggest that unless all of the
> codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the
> controller should not be enabled on the controller. Otherwise,
> functionality will be lost and there are likely going to be audio artifacts.
> 
> Is EPSS mandatory?  We have already a check of ClkStopOK bit, but EPSS
> influences only on the wait time, so far.

It's a suggestion based on Windows experience. 
So maybe we can add this check at the moment. How do you think?

Regards
Mengdong
 


More information about the Alsa-devel mailing list