Re: [RFC PATCH v2 1/2] ASoC: refine ASoC hdmi audio suspend/resume

From: Keyon Jie <yang.jie@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>, "Yang, Libin" <libin.yang@intel.com>
Cc: "liam.r.girdwood@linux.intel.com"
	<liam.r.girdwood@linux.intel.com>,
	"Lin, Mengdong" <mengdong.lin@intel.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: [RFC PATCH v2 1/2] ASoC: refine ASoC hdmi audio suspend/resume
Date: Mon, 14 Jan 2019 09:16:02 +0800	[thread overview]
Message-ID: <1a7ffff2-4249-f2a0-ba7e-549910ad49b9@linux.intel.com> (raw)
In-Reply-To: <s5hk1jajp89.wl-tiwai@suse.de>

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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel