[alsa-devel] [PATCH 2/2] ALSA: hda - get realtime ELD info when codec suspended

[David Henningsson]

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 at canonical.com>:
>> On 06/25/2013 11:33 AM, Wang, Xingchao wrote:
>>>
>>> Hi David,
>>>
>>>
>>>> -----Original Message-----
>>>> From: alsa-devel-bounces at alsa-project.org
>>>> [mailto:alsa-devel-bounces at alsa-project.org] On Behalf Of David
>>>> Henningsson
>>>> Sent: Tuesday, June 25, 2013 5:02 PM
>>>> To: Wang, Xingchao
>>>> Cc: Takashi Iwai; alsa-devel at 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 at alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic