-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, December 11, 2013 9:37 PM To: Lin, Mengdong Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Wed, 11 Dec 2013 05:37:44 +0000, Lin, Mengdong wrote:
-----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.
If we have a direct communication with the graphics driver, the audio driver doesn't wait for the unsol event at all. It can retrieve ELD and even better port info more directly; i.e. we can skip even the wake up of the HDMI controller and codec chips. The notification and ELD updates can be done without the audio hardware, after all (actual ELD updates will be done at resume).
Good idea. We can try this. The HDMI controller and codec can sleep until user space really wants to use HDMI audio.
Regards Mengdong