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