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?
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?
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.
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.