BTW, while checking these things, I noticed that there are three exceptional drivers: sound/soc/intel/atom/sst-mfld-platform-pcm.c, sound/soc/intel/haswell/sst-haswell-pcm.c, and sound/soc/samsung/tm2_wm5110.c. (You can simply grep the external snd_soc_suspend call, and only these match.) The former two drivers look really weird: they do handle the PM only with PM prepare and complete callbacks, while snd_soc_suspend() and co are called internally from there. The prepare and complete callbacks aren't designed for the complete suspend/resume tasks, so I'd say it's a quite abuse.
For the Atom/SST driver, I remember there was a need to set/restore the DSP state with a specific command that wasn't handled with regular controls - largely a work-around due to the firmware design.
For the Haswell driver, there was also a need to preserve/restore state and pause/stop pipelines (a recurring issue with the "Made for Windows" firmware).
These drivers are quite old now and it's not clear to me if they are broken or if we are talking of an improvement. Could you clarify what you view as "abuse"?
a) is this the fact that there are prepare/complete callback for those drivers, instead of others such as freeze, thaw, etc.
b) the fact they they call snd_soc_suspend/resume directly? c) the fact that they suspend the PCM streams? d) all of the above (which is entirely possible). Thanks -Pierre _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
