On 12/18/18 4:12 PM, Pierre-Louis Bossart wrote:
My point was that the machine driver can track DAPM events and put the device in a 'safe' state on SND_SOC_DAPM_EVENT_OFF so that the rate can be changed when playback restarts. I don't see what prevents us from using the same config as during suspend? It's pretty common to play with clocks with these events, and calling clk_disable_unprepare() could lead to whatever configuration sequence is needed for pop-free restart on startup.
I only wanted to point out that, given the current DAPM configuration of the pcm512x CODEC driver (as determined from monitoring calls to the .set_bias_level callback, which seems to be the only place where the power state of the chip is actually manipulated), it seemed like it wasn't necessarily turned off between sample rate changes, and that I'm not sure there's a 'safe' state you can put it in, so that it won't pop on the next change to the clock source, if it's powered up at the time. The DAPM subsystem is complex and documentation on it is scarce, but it seems the former can be fixed. At least it is implied that the DAC can be turned on/off at the stream domain level, which seems to be tied to playback starting/stopping. If the DAC can be suspended right after playback stops and powered back up right before playback starts again, then I don't think anything else needs to be done to avoid pops, as all clock switching will have been done with the device suspended. If this is not possible, then I'm not sure if you can put the device in a 'safe' state, say with both clocks turned off, or the clock reference switched away from SCK, or something like that, so that it won't pop when the sample rate (and hence clock source) is later changed, while the DAC is powered up. Anyway, calling my familiarity with the internals of ASOC drivers superficial, would probably be stretching it, so the above is (hopefully somewhat educated) guesswork at best. Ignore it if it doesn't make sense. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
