On 12/17/18 6:17 AM, Dimitris Papavasiliou wrote:
On 12/13/18 7:42 PM, Mark Brown wrote:
On Sat, Nov 24, 2018 at 10:17:49PM +0200, Dimitris Papavasiliou wrote:
discussion here. I still feel that fixing the machine driver, so that it doesn't generate the pop at all would be desirable, as I'm not sure whether the digital_mute callback is guaranteed to have muted the device when the clock source takes place.
Making the machine driver more robust is definitely better, it's more robust in case the mute is for example just a very low gain which might still let the pop through at a lower level.
Even worse, it would let the pop through at full volume, as it doesn't depend on the gain. Still, there doesn't seem to be a safe way to avoid the pop altogether, as far as I can see, since the only way I have found to avoid it, is to suspend the chip during the switch, and I can't synchronize access to the relevant register by the machine and CODEC drivers.
If you have any other ideas/pointers on approaches I could investigate, please let me know.
I started prototyping a different approach where the codec driver passes the regmap information to the clock driver. What's missing in the patchset is the addition of a clock control in the machine driver, and logic added so that rate change can only be done in a hw_params if there was a complete stop and reset on a DAPM_OFF event. compile-tested only for now.