On Fri, Apr 21, 2017 at 03:42:43PM +0200, Takashi Iwai wrote:
Hi,
I noticed that the unstable PM behavior on my Cherrytrail laptop actually comes from the sound driver. First off, the atom/sst/sst.c has the following suspend code:
static int intel_sst_suspend(struct device *dev) { .... /* * check if any stream is active and running * they should already by suspend by soc_suspend */ for (i = 1; i <= ctx->info.max_streams; i++) { struct stream_info *stream = &ctx->streams[i];
if (stream->status == STREAM_RUNNING) { dev_err(dev, "stream %d is running, can't suspend, abort\n", i); return -EBUSY; }}
This doesn't look good, and I actually hit this when I tried to suspend while playing something. In general, the driver shouldn't reject at this point, because this is the PM suspend callback, i.e. the user wants to suspend the device inevitably. The driver should return an error only when it faces to a fatal error.
Mea culpa
And you are now second person to complain about this so I wonder if we should rework this
So from hardware POV, we need to first suspend all running streams and then save the context from DSP (in order to restore them later) and then we can shutdown the DSP.
The problem is driver being split into platform (which knows streams) and sst dsp driver. So we devised a careful sequence where platform suspend is invoked first (calls using asoc pm ops) and then DSP
This results is ASoC doing stream suspend for us and when we hit intel_sst_suspend() we are supposed to have stream suspended, so save and shut off DSP.
Now for you issue you see can you check why platform suspend is not getting called?
But I wondered why this happened at all, and noticed that the machine driver (in my case bytcr_rt5640) has no its own PM ops. But hooking the snd_soc_pm_ops there seems causing a hang up at suspend by some reason.
O yes, thats due to double suspend
See 3639ac1cd5177685a5c8abb7230096b680e1d497
Maybe this wasn't a big problem until now since the BYT/CHT didn't support the suspend/resume properly in the past. But now PM suspend is supported on these devices, so the problem surfaced more often.
The Chromebooks shipped on BSW use this method so..
Could you guys check the status of these drivers?