tree c948e9df9646d03a0b8094befa4580c9a704ceeb
parent 2a0bda276c64212e517cc1d65cf65719a9ab1ef6
author Tzung-Bi Shih <tzungbi@google.com> 1574407872 +0800
committer Mark Brown <broonie@kernel.org> 1574859320 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl3eckMTHGJyb29uaWVA
 a2VybmVsLm9yZwAKCRAk1otyXVSH0FMsB/4o3d2WrvJjh9gimu0XtcMqj0sTg21i
 4/itSR+IC7x+nSj2sqRXAmWjtYxYW4iejR4/zujDU9QcPv7QoVTECCnFkkVaPxyB
 08wlDKXf1lO8dnho7ufZ3pSLtqVcDu2aKAhyg/1c/mrZpCednShC9D7qZG+gdTzG
 o/D7S3wiskiit8mTNft0wYvtXrYARqF9qxZVDHmUqlV2jrsLPtuyEO29SqUmHMQa
 ILo4k7xWgkRXL7hXKjKHuprOw+CxfKpxBS90sFS5RHSN8ysT2HBrYZ8qDog3v7tt
 //tv/xjS5ZSPiwNE5uoC+1ipK45LmMucOsU4wqWc1d8Ht4qvMfyK5kfU
 =HoMe
 -----END PGP SIGNATURE-----

ASoC: max98090: remove msleep in PLL unlocked workaround

It was observed Baytrail-based chromebooks could cause continuous PLL
unlocked when using playback stream and capture stream simultaneously.
Specifically, starting a capture stream after started a playback stream.
As a result, the audio data could corrupt or turn completely silent.

As the datasheet suggested, the maximum PLL lock time should be 7 msec.
The workaround resets the codec softly by toggling SHDN off and on if
PLL failed to lock for 10 msec.  Notably, there is no suggested hold
time for SHDN off.

On Baytrail-based chromebooks, it would easily happen continuous PLL
unlocked if there is a 10 msec delay between SHDN off and on.  Removes
the msleep().

Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20191122073114.219945-2-tzungbi@google.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>