-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 8:25 PM To: Lin, Mengdong Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Tue, 10 Dec 2013 12:17:16 +0000, Lin, Mengdong wrote:
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.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will wake up and audio driver can check ELD info.
Regards Mengdong