On 07/12/2013 08:13 AM, Wang Xingchao wrote:
Hi David/Takashi,
Here's some update on this topic. I used evtest to monitor hotplug input event for Headphone, it doesnot report the hotplug event when audio controller/codec in runtime suspend mode. if it's during audio playback(both controller and codec are active), the events could be monitored correctly. However even the controller/codec in runtime suspend mode, the hotplug event was not missed when waken up from suspend mode. After exit from suspend mode, the hotplug event would be reported asap. So userspace will not receive the event notification from driver when controller/codec in suspend mode, but it will get them once audio controller/codec become active. I think it's acceptable for audio playback functinality, it will not harm audio routing in fact. i'm not sure there's other potential risk, i.e. user space will show/hide the devices in UI according to the event, in that case , user will never see the Headphone device for playback before audio controller/codec was waken up in another way.
Meanwhile i tested attached patch to monitor WAKEEN events, it doesnot work well as Spec said. it would not wake up audio controller/codec when plug in/out headphone in runtime suspend mode, and the status register always be 0.
Hi Xingchao,
Maybe you're giving up too easily on the WAKEEN stuff? I can spot a few places where your patch is incomplete:
- First, WAKEEN and STATETS are word registers, you should probably use azx_writew when you access them
- Second, and this is definitely a problem, azx_runtime_suspend calls azx_stop_chip -> azx_int_disable. So we disable interrupts, that's why we don't get them from the wake events.
- Third, first in azx_interrupt, we check for chip->pci->dev.power.runtime_status - maybe this is no longer true if the device is in D3?
Do you know how and if Windows has solved this?
thanks --xingchao
2013/6/25 David Henningsson david.henningsson@canonical.com:
On 06/25/2013 11:33 AM, Wang, Xingchao wrote:
Hi David,
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of David Henningsson Sent: Tuesday, June 25, 2013 5:02 PM To: Wang, Xingchao Cc: Takashi Iwai; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH 2/2] ALSA: hda - get realtime ELD info when codec suspended
On 06/25/2013 09:55 AM, Takashi Iwai wrote:
At Tue, 25 Jun 2013 09:45:04 +0200, David Henningsson wrote:
> > There is a low power mode that allows the jack detection, but this > is different from the aggressive power-saving with runtime D3.
If "aggressive power-saving with runtime D3" is the same as AZX_DCAPS_PM_RUNTIME, this is also enabled for analog codecs connected to a Lynx point controller.
It looks like userspace have problems getting notifications for e g headphone insertion on Lynx point controllers, so this is not only an HDMI/DP problem?
Yes.
Trying to read up a little on this, there seem to be an option to set the WAKEEN register to have jack detection working even when the controller is in D3. (refer HDA specification 4.5.9.2: Codec Wake From System S0, Controller D3.) But it seems we do not (yet) use this feature. Is this something that could/should be implemented to fix the jack detection problems that seems to be happening otherwise?
It sounds feasible, at least for traditional jack detection of analog pins. But I'm not sure whether this would help for the Intel graphics case. Just need testing.
Xingchao, what are your thoughts about using WAKEEN to wakeup both Lynx point and Haswell HDMI?
That's okay for me, I would do some test on that. do you have some test cases? That would help me verify them when enable WAKEEN feature.
Since we still enable the legacy jack feature through /dev/input/event*, the easiest way to test would probably to run evtest (which is in the Ubuntu repositories). Find the correct /dev/input/event file by checking dmesg (or just trying them one by one), then run "sudo evtest /dev/input/<filename>".
Now check if you get events correctly on HDMI/DP/Headphone/Mic/etc plug and unplug, even if the controller is runtime suspended.
Also note that WAKEEN should probably be disabled during system S3, because we don't want to wake up the entire computer just because somebody unplugs his headphone, right?
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel