-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Monday, April 15, 2013 3:03 PM To: Lin, Mengdong Cc: Takashi Iwai; alsa-devel@alsa-project.org; Girdwood, Liam R Subject: Re: [alsa-devel] [PATCH] ALSA: hda - delay resume haswell hdmi codec in system resume
On 04/14/2013 03:48 PM, Lin, Mengdong wrote:
Hi David and Takashi,
I'm sorry for the late response. I was assigned other tasks this week
We don't have a better solution for this issue now, still trying. The delay_resume() ops for a codec can help not delaying the unsol event. So
our patch can solve the problem after system suspend/resume if the cable is connected.
But I'm afraid that if the HDMI/DP cable removed during system suspend and connected again sometime after system is resumed, and if the codec
access happens before the cable is connected, waiting for unsol event can be time out and codec cannot be properly resumed.
And if runtime power saving is also disabled, the audio driver has no chance to
resume the codec again. I cannot verify such hot-plug case during system/suspend now because my Haswell machines cannot reach a stable S3 and then resume.
But we do observed a similar bug: if cable is connected after boot, the pin is in
D3 with right channel muted, as the codec is initialized before unsol event comes.
Audio driver cannot find a suitable time out to wait for the usnsol event as we
don't know when the cable will be connected.
Takashi's latest suggestion was to enable unsol events, and nothing else, directly on S3 resume. See suggested patch below.
Will that not help here? Then we would at least get some unsol events on hotplug I assume?
I think Takashi's patch can help when cable is connected during suspend/resume cycles. This patch enables unsol event, so make sure unsol event won't be delayed.
So shall I improve the patch as Takashi suggested, to solve current suspend/resume issue?
We'll try if we can fix this dependency issue in Gfx driver side, and by sync Gfx
and audio driver processing.
And we cannot implement pm domain atm. Last Thursday, we have a meeting
with Gfx team, for Gfx power well support and audio dependency on Gfx.
Linux PM maintainer Rafael also attended the meeting. He suggested us not
use pm domain now because it cannot fully support PCI devices (PM domains ops will override PCI bus ops). We will use and extend the existing private gfx driver API to control the powerwell and sequence the initialization/suspend/resume events between gfx and audio for internal releases. Once this is working well with the private API, we will then look at either implementing this functionality as PM domain or PM runtime depending on the best fit and upstream.
I'm working on HD-A RTD3 for legacy audio in one or two weeks. After that,
I'll continue to work on this issue.
The dependency on the Gfx driver, is it both codec-wide and per pin? It seems to be at least per pin, which means that whenever we plug something in, we need to redo our initialization of that pin after the Gfx driver has finished, is that correct?
We're still investigating the Gfx driver sequence. In fact, not every hot plug will cause trouble. If the system is booted with cable connected, later hot-plug does not cause error, including switch between DP and HDMI cable. The dependency issue only happens on boot and resume. Since the hot-plug will also make Gfx reconfig the display pipeline, so we want to compare the difference and locate the accurate dependency.
Thanks Mengdong