[alsa-devel] [PATCH 1/3] ASoC: max98090: remove msleep in PLL unlocked workaround

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Wed Nov 20 15:33:16 CET 2019



On 11/20/19 12:02 AM, Tzung-Bi Shih wrote:
> 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 at google.com>
> ---
>   sound/soc/codecs/max98090.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
> index f6bf4cfbea23..8382a77586ee 100644
> --- a/sound/soc/codecs/max98090.c
> +++ b/sound/soc/codecs/max98090.c
> @@ -2117,7 +2117,6 @@ static void max98090_pll_work(struct work_struct *work)
>   	/* Toggle shutdown OFF then ON */
>   	snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN,
>   			    M98090_SHDNN_MASK, 0);
> -	msleep(10);

maybe add a comment here that the off/on sequence is done on purpose (as 
stated in the commit message)?

>   	snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN,
>   			    M98090_SHDNN_MASK, M98090_SHDNN_MASK);
>   
> 


More information about the Alsa-devel mailing list