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
