[alsa-devel] [PATCH 3/3] ASoC: max98090: fix possible race conditions

[Tzung-Bi Shih]

On Fri, Nov 22, 2019 at 3:20 AM Pierre-Louis Bossart
<pierre-louis.bossart at linux.intel.com> wrote:
> > Can we suppose CPUs always get ULK=1 if PLL is unlocked so that we can
> > simply ignore the case (2)?  Since we know the register is volatile
> > and read the register via I2C should be much slower than hardware
> > raise the bit.
>
> Your option B with the small change to sleep then retest is probably the
> better solution overall.

Have sent v2, https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/159050.html

> BTW did you test this on both Baytrail and BSW chromebooks? In the past
> I saw baytrail devices exposed this error a lot more than BSW.

I tested on a Baytrail-based chromebook which is easy to generate lots
of "PLL unlocked" on the console.  After applying this series and the
next series (https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158853.html),
I seldom see "PLL unlocked" on the console.  It still happens a few
times, but with very very low probability.