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?
Thanks,
~Keyon
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
