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