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

[Wang, Xingchao]

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

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