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.
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.
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.
Could you guys check the status of these drivers?
thanks,
Takashi