-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 10:26 PM
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.
Well, we can create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo.
Hi Takashi,
I'm sure how to use a common object like vga_switcheroo. Would you please share more info?
I feel a wake up process may be like this: - Gfx driver detects the hot-plug at first and notify audio driver by the communication channel. - In the notification callback, the audio driver wakes up the audio controller to D0, but codec can still stay in D3. (Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event) - Then when Gfx driver enables or disables audio, and the audio controller can receive the unsol event in D0. - Audio driver check ELD in unsol event handler, this will make codec resume to D0.
Regards Mengdong