[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.
Thanks
Mengdong
More information about the Alsa-devel
mailing list