Re: [PATCH 3/4] ASoC: Intel: bdw-rt5677: Remove ignore_suspend flag from SSP0 dai link - Pierre-Louis Bossart

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>,
	Cezary Rojewski <cezary.rojewski@intel.com>,
	alsa-devel@alsa-project.org
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Curtis Malainey <cujomalainey@google.com>,
	tiwai@suse.com, Dominik Brodowski <linux@dominikbrodowski.net>,
	lgirdwood@gmail.com, vkoul@kernel.org, broonie@kernel.org,
	Ben Zhang <benzh@google.com>
Subject: Re: [PATCH 3/4] ASoC: Intel: bdw-rt5677: Remove ignore_suspend flag from SSP0 dai link
Date: Sun, 5 Apr 2020 18:11:34 -0500	[thread overview]
Message-ID: <3af264d9-7064-dad4-b937-af45ffad4e65@linux.intel.com> (raw)
In-Reply-To: <fdb1f5f5-53a2-f1ae-c193-145c8a7f4f42@redhat.com>

> 
> I just noticed something which is somewhat related to this
> discussion (and also somewhat off topic).
> 
> I just noticed on a Bay Trail device with a RT5672 codec
> and on a Cherry Trail device with a RT5645 codec that
> if an input / recording audio stream is active while
> suspending the tablet, then after resume audio is broken,
> playback seems to work (audio samples get consumed at normal
> speed) but it is silent.  Recording also is broken, not
> sure if it is broken, or just silent too.
> 
> When this happens, closing all apps which consume audio
> and waiting 5 seconds for a runtime-suspend to kick in
> fixes things. After this both record and playback
> works again.
> 
> Any idea what the cause for this problem might be?

Power management for the Atom/sst stuff is far from clear for me, it 
uses .prepare/.complete callbacks where 
snd_soc_suspend()/poweroff()/resume() are invoked, so there's a bit of 
confusion IMO between that the framework does and what the driver should do.

It's also unclear to me why the INFO_RESUME flag was set, since the 
driver cannot restart from the same position.

I would try and triangulate with the more traditional bytcr-rt5640, to 
rule out a codec-specific or machine driver issue (handling of rt5645 
and 5672 was done by different people and the machine driver is quite 
different).

I would also remove the INFO_RESUME, that will force the ALSA core to 
call the .prepare steps and maybe restore settings that are not applied 
with the current resume.

Either way, it's a bit of a shot in the dark :-(

My 2 cents
-Pierre