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

[Takashi Iwai]

At Thu, 18 Jul 2013 05:47:30 +0000,
Wang, Xingchao wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Wang, Xingchao
> > Sent: Wednesday, July 17, 2013 6:15 PM
> > To: Wang, Xingchao; David Henningsson
> > 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
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: alsa-devel-bounces at alsa-project.org
> > > [mailto:alsa-devel-bounces at alsa-project.org] On Behalf Of Wang,
> > > Xingchao
> > > Sent: Monday, July 15, 2013 4:54 PM
> > > To: David Henningsson; 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
> > >
> > >
> > >
> > > > -----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
> > 
> > If the controller is active while codec suspended, "evtest" can catch headphone
> > hotplug event.
> > I made some changes in azx_runtime_suspend(), which in brief leave interrupt
> > enabled, then "evtest" cannot catch input event.
> > Also I added some debug log shows, when controller enter suspend mode, the
> > WAKEEN bits were set(value 0x3), after headphone hotplug, Audio controller
> > was not waken up. When audio controller exit, in azx_runtime_resume(), the
> > debug shows WAKEEN bits value no change, STATETS has value 0. The controller
> > did not detect changes from codec side, so it donot set the bits in STATETS.
> > 
> > I read the spec, and found something different:
> > - Controller should be in reset state while In D3?(Chapter 4.5.9.2 in  HD-A
> > spec.)
> > Azx_runtime-suspend() did not reset the controller.
> > - codec will use power state change request on the link to let controller know.
> > Not sure it's hardware operation or software layer.
> > - codec discovery ( chapter 4.3)
> > "When the link is enabled by the assertion of CRST, the codecs will detect the
> > de-assertion of the RESET# signal and request a status change and
> > enumeration by the controller.
> >  As the controller hardware detects these requests, it will provide the codecs
> > with their unique addresses and set the controller STATESTS bits  to indicate
> > that a Status Change event was detected on the appropriate SDATA_INx
> > signals.  "
> > I'm afraid something was not configured correctly, i.e. should let controller in
> > reset state when enter runtime suspend mode?
> 
> After some test, I found the controller should be in "reset" state, and CIE interrupt should be enabled,
> Otherwise the wake-up event from codec could not wake up system.
> 
> I'm writing a patch to fix this.

Great, thanks for checking it.


Takashi

> 
> --xingchao
> 
> 
>  
> > Thanks
> > --xingchao
> > >
> > > 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
> > > > chip->pci->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
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel at alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>