[alsa-devel] HD-audio runtime PM

Lin, Mengdong mengdong.lin at intel.com
Tue Dec 10 13:17:16 CET 2013

Hi Takashi,

> -----Original Message-----
> From: Lin, Mengdong
> Sent: Monday, December 09, 2013 3:03 PM

> > > > I've checked two Haswell-ULT platforms with sound git tree
> > > > for-linus
> > > branch, under Ubuntu:
> > > > - ELD cannot refresh properly.
> > > > - HDMI hot-plug cannot wake up the audio controller.
> I've tested the latest 3.13-rc2 based sound git tree, master branch:
> - ELD can refresh properly on hot-plug event.
>  I need to bisect to see where the ELD regression happened and how it
> was fixed.

ELD info cannot refresh on hot-plug event after the controller enters D3 on Haswell.
Sorry, I forgot to enable runtime PM yesterday when checking ELD refreshing.  

> - Headset insertion can wake up the legacy audio controller (PCI device
> 00:1b)
> - HDMI insertion still cannot wake up the display audio controller (PCI
> device 00:03)  We'll double check with HW owner whether the display
> audio controller really supports wake up on HDMI/DP insertion.
>  I remember when Xingchao enabled runtime PM on Haswell display
> audio controller for display power well release,  there was an issue that
> this controller does not support "wake up", but we finally enable runtime
> PM on it and remove the request for "wake up".

HW team clarified that HDMI/DP jack insertion cannot wake up the controller from D3. So this is a HW restriction for Haswell, not a driver regression.

Now the problem on Haswell/Broadwell is:
After the controller enters D3, Gfx driver can still detect HDMI/DP hot plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.

Is it audio driver itself or the user space that need this ELD info?
Maybe Gfx driver can directly report ELD info to user space.


More information about the Alsa-devel mailing list