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