At Mon, 24 Jun 2013 14:47:01 +0200, David Henningsson wrote:
On 06/24/2013 02:00 PM, Takashi Iwai wrote:
At Mon, 24 Jun 2013 11:56:21 +0000, Wang, Xingchao wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Monday, June 24, 2013 7:36 PM To: Wang Xingchao Cc: alsa-devel@alsa-project.org; Wang, Xingchao Subject: Re: [PATCH 2/2] ALSA: hda - get realtime ELD info when codec suspended
At Mon, 24 Jun 2013 07:45:24 -0400, Wang Xingchao wrote:
when controller/codec in runtime suspended mode, monitor hotplug would not trigger unsolicited event.
And here's the original problem IMO: If you can't detect plug/unplug in runtime suspend mode, the runtime suspend mode is broken. Userspace relies on getting notification when a HDMI/DP connection is plugged/unplugged. If no unsol event is triggered, how is userspace notified?
It can't, so far. The same thing happens for any other jack detections when the power-saving is turned on.
There is a low power mode that allows the jack detection, but this is different from the aggressive power-saving with runtime D3.
In theory, the audio driver can be resumed forcibly before unsolicited event is sent, once if we have a layer controlling the power of both graphics and audio devices. This is the thing to be done in future, together with the runtime PM control of the graphics side.
This patch tries to power up codec and
hdmi driver would probe ELD info again.
I don't know whether this is the wanted behavior. The proc file is supposed to read the driver's status, not to trigger anything.
I explained in another mail what the patch fix. In the real case, when HDMI monitor removed, Eld# still hold monitor information because the codec/controller is in suspend mode atm and has no chance to refresh eld.
And this is no bug, per se. The proc file shows the driver's current status, not the hardware's raw status.
Well, the codec proc file shows the hardware's raw status (which includes powering up the codec), perhaps it would be more consistent if the eld proc file did the same?
Well, the concept is different.
The codec proc file shows the codec raw status, so it is. The eld proc file shows the content of the data the driver currently contains. It's good so for debugging purpose; otherwise the driver status would change just by reading this proc file.
Even when controller/codec waken up, it will not refresh eld# as gfx side hand
led hdmi hotplut when audio driver suspended.
... and this is actually the bug. But, it's still unclear why the jack detection callback isn't called at resume.
Well, I haven't double checked, but is there anyone actually calling it? Just setting a jack to dirty does not cause any action in itself.
The culprit was found, see my previous reply.
And btw, even if the proc file might show old information, we also have the ELD bytes ctrl, which IMO should always correctly return 0 if there's nothing connected.
Right.
thanks,
Takashi