[alsa-devel] [RFC PATCH v2 1/2] ASoC: refine ASoC hdmi audio suspend/resume

[Takashi Iwai]

On Mon, 14 Jan 2019 02:16:02 +0100,
Keyon Jie wrote:
> 
> 
> 
> On 2019/1/12 下午3:43, Takashi Iwai wrote:
> > On Sat, 12 Jan 2019 02:46:33 +0100,
> > Yang, Libin wrote:
> >>
> >> Hi Takashi,
> >>
> >>>>>
> >>>>> On Fri, 11 Jan 2019 06:20:23 +0100,
> >>>>> Yang, Libin wrote:
> >>>>>>
> >>>>>> The below patch may have a small confliction that the trigger will
> >>>>>> be called twice as our SOF has already call snd_pcm_suspend() in
> >>>>>> card suspend.
> >>>>>
> >>>>> It should be no problem, snd_pcm_suspend() can be called multiple
> >>>>> times.  If it's already suspended, just nothing happens.
> >>>>
> >>>> Thinking of this problem again, does a patch like below work instead?
> >>>> This looks like a better and more generic solution.
> >>>>
> >>>> What I'm not quite sure is whether the device suspend order between
> >>>> PCM device and HD-audio codec device is guaranteed.  I guess yes,
> >>>> because the PCM device is registered always after the codec.  But ASoC
> >>>> might have another weirdness :)
> >>
> >> The suspend order is always a quite hard issue for me. I have to spend
> >> a lot time checking the parent-child relationship. And if they don't have
> >> such relationship, I don't know how to find the order.
> >>
> >> My initial idea to get rid of such dependency is: do the pcm suspend before
> >> suspend(), for example put it in prepare(). And set device clk off and power
> >> off in suspend(). This can make sure pcm is always properly suspended.
> >> But, I'm not sure prepare() is a right place because it seems prepare() is not
> >> designed to do such things and prepare() may impact the suspend/resume
> >> sequence based on its return value. If your below patch works, I think it will
> >> be a best solution which can handle such things in ALSA level. I think we
> >> may need to do a lot of test because the different cards drivers are
> >> extremely different.
> >
> > As mentioned below, ASoC is another thing.  Its PM sequence is found
> > in snd_soc_suspend().
> >
> >
> > Takashi
> 
> This is an interesting topic, it worth to do a surgery to remove those
> ASoC snd_pcm_suspend_all() invoking and do unified PCM suspend in ALSA
> PCM level?

This won't work easily, I suppose.  Take a look at snd_soc_suspend()
code.  It's designed to run several procedures sequentially there, and
each component is supposed to process the suspend/resume task via the
ASoC component callback, not the driver PM ops that can be outside
this call.

HD-audio ASoC codec driver is an ASoC codec driver, hence it should
follow that way.


Takashi