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

[Wang, Xingchao]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson at canonical.com]
> Sent: Monday, July 15, 2013 12:29 PM
> To: Wang Xingchao
> Cc: Takashi Iwai; Wang, Xingchao; alsa-devel at alsa-project.org
> Subject: Re: [alsa-devel] [PATCH 2/2] ALSA: hda - get realtime ELD info when
> codec suspended
> 
> 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

Thanks for clarify this. We support 8 codec at most, so I think it's safe to use writeb/readb here.
 
> 
>   - 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.
[Wang, Xingchao]  yes, moreover I think it's not enough only enabling "controller interrupt" bits in this case, 
PCI interrupt bits must be anbled too. I'm still checking the setting in runtime_suspend.

> 
>   - 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?
[Wang, Xingchao] yes, it's a risk here. Just move the lines before the "if" condition check.
> 
> Do you know how and if Windows has solved this?
> 
[Wang, Xingchao] I have wrote emails for windows team guys, has no response yet. I will update here when I have update.

thanks
--xingchao