On Fri, Nov 22, 2019 at 3:20 AM Pierre-Louis Bossart pierre-louis.bossart@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.h...
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.h...), I seldom see "PLL unlocked" on the console. It still happens a few times, but with very very low probability.