[alsa-devel] [PATCH V2] ASoC: fix hdmi codec driver contest in S3

[Takashi Iwai]

On Tue, 26 Mar 2019 12:15:06 +0100,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> >-----Original Message-----
> >From: Takashi Iwai [mailto:tiwai at suse.de]
> >Sent: Tuesday, March 26, 2019 4:54 PM
> >To: Yang, Libin <libin.yang at intel.com>
> >Cc: alsa-devel at alsa-project.org; broonie at kernel.org
> >Subject: Re: [alsa-devel] [PATCH V2] ASoC: fix hdmi codec driver contest in S3
> >
> >On Tue, 26 Mar 2019 09:46:31 +0100,
> >Yang, Libin wrote:
> >>
> >> Hi Takashi
> >>
> >> >
> >> >In the case of legacy HD-audio, we "fixed" the problem by avoiding
> >> >the trigger of async work at resume, but let it be triggered from
> >> >runtime resume.  In ASoC case, however, it's no option.
> >> >
> >> >Maybe a possible solution in the sound driver side would be to move
> >> >from system suspend/resume to ASoC component suspend/resume.  The
> >> >runtime suspend/resume can be kept as is, and call
> >> >pm_runtime_force_suspend and resume from the component
> >suspend/resume
> >> >callbacks.  Since the component callbacks are certainly processed
> >> >before DAPM events, this should assure the order.
> >>
> >> I tried to move display power setting from runtime suspend/resume to
> >> component suspend/resume. I found there may be another issue:
> >> playback will NOT call component suspend/resume.
> >> This  means we will never have chance to set the display power if we
> >> don't do the S3.
> >
> >The runtime suspend/resume are fine and need to be kept, I suppose.
> >The only problem is the system suspend/resume callbacks that call
> >pm_runtime_force_*().  Just moving these two to component would work?
> >
> 
> Let's see the flow of the suspend:
> 1. Component suspend is called. It will call snd_hdac_display_power()
> to turn off the display power.

No, what I meant was to make the component suspend calling
pm_runtime_force_suspend() instead of the system suspend.
Ditto for the component resume calling pm_runtime_force_resume().


Takashi