[alsa-devel] [PATCH v2 0/3] ASoC: max98090: fix PLL unlocked workaround-related
This series is a follow up fix for the question: https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/157364.ht...
Changes from v1: ASoC: max98090: remove msleep in PLL unlocked workaround - add more comments https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158969.h...
ASoC: max98090: exit workaround earlier if PLL is locked - "sleep first and then check the status" https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158998.h...
ASoC: max98090: fix possible race conditions - fix typo https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158966.h... - add more descriptions in commit message
Tzung-Bi Shih (3): ASoC: max98090: remove msleep in PLL unlocked workaround ASoC: max98090: exit workaround earlier if PLL is locked ASoC: max98090: fix possible race conditions
sound/soc/codecs/max98090.c | 30 +++++++++++++++++++++--------- sound/soc/codecs/max98090.h | 1 - 2 files changed, 21 insertions(+), 10 deletions(-)
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 --- sound/soc/codecs/max98090.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index f6bf4cfbea23..12cb87c0d463 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2114,10 +2114,16 @@ static void max98090_pll_work(struct work_struct *work)
dev_info_ratelimited(component->dev, "PLL unlocked\n");
+ /* + * 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. + */ + /* Toggle shutdown OFF then ON */ snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, 0); - msleep(10); snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, M98090_SHDNN_MASK);
The patch
ASoC: max98090: remove msleep in PLL unlocked workaround
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From acb874a7c049ec49d8fc66c893170fb42c01bdf7 Mon Sep 17 00:00:00 2001
From: Tzung-Bi Shih tzungbi@google.com Date: Fri, 22 Nov 2019 15:31:12 +0800 Subject: [PATCH] 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 --- sound/soc/codecs/max98090.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index f6bf4cfbea23..12cb87c0d463 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2114,10 +2114,16 @@ static void max98090_pll_work(struct work_struct *work)
dev_info_ratelimited(component->dev, "PLL unlocked\n");
+ /* + * 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. + */ + /* Toggle shutdown OFF then ON */ snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, 0); - msleep(10); snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, M98090_SHDNN_MASK);
According to the datasheet, PLL lock time typically takes 2 msec and at most takes 7 msec.
Check the lock status every 1 msec and exit the workaround if PLL is locked.
Signed-off-by: Tzung-Bi Shih tzungbi@google.com --- sound/soc/codecs/max98090.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index 12cb87c0d463..f531e5a11bdd 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2108,6 +2108,8 @@ static void max98090_pll_work(struct work_struct *work) struct max98090_priv *max98090 = container_of(work, struct max98090_priv, pll_work); struct snd_soc_component *component = max98090->component; + unsigned int pll; + int i;
if (!snd_soc_component_is_active(component)) return; @@ -2127,8 +2129,16 @@ static void max98090_pll_work(struct work_struct *work) snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, M98090_SHDNN_MASK);
- /* Give PLL time to lock */ - msleep(10); + for (i = 0; i < 10; ++i) { + /* Give PLL time to lock */ + usleep_range(1000, 1200); + + /* Check lock status */ + pll = snd_soc_component_read32( + component, M98090_REG_DEVICE_STATUS); + if (!(pll & M98090_ULK_MASK)) + break; + } }
static void max98090_jack_work(struct work_struct *work)
The patch
ASoC: max98090: exit workaround earlier if PLL is locked
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From 6f49919d11690a9b5614445ba30fde18083fdd63 Mon Sep 17 00:00:00 2001
From: Tzung-Bi Shih tzungbi@google.com Date: Fri, 22 Nov 2019 15:31:13 +0800 Subject: [PATCH] ASoC: max98090: exit workaround earlier if PLL is locked
According to the datasheet, PLL lock time typically takes 2 msec and at most takes 7 msec.
Check the lock status every 1 msec and exit the workaround if PLL is locked.
Signed-off-by: Tzung-Bi Shih tzungbi@google.com Link: https://lore.kernel.org/r/20191122073114.219945-3-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/codecs/max98090.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index 12cb87c0d463..f531e5a11bdd 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2108,6 +2108,8 @@ static void max98090_pll_work(struct work_struct *work) struct max98090_priv *max98090 = container_of(work, struct max98090_priv, pll_work); struct snd_soc_component *component = max98090->component; + unsigned int pll; + int i;
if (!snd_soc_component_is_active(component)) return; @@ -2127,8 +2129,16 @@ static void max98090_pll_work(struct work_struct *work) snd_soc_component_update_bits(component, M98090_REG_DEVICE_SHUTDOWN, M98090_SHDNN_MASK, M98090_SHDNN_MASK);
- /* Give PLL time to lock */ - msleep(10); + for (i = 0; i < 10; ++i) { + /* Give PLL time to lock */ + usleep_range(1000, 1200); + + /* Check lock status */ + pll = snd_soc_component_read32( + component, M98090_REG_DEVICE_STATUS); + if (!(pll & M98090_ULK_MASK)) + break; + } }
static void max98090_jack_work(struct work_struct *work)
max98090_interrupt() and max98090_pll_work() run in 2 different threads. There are 2 possible races:
Note: M98090_REG_DEVICE_STATUS = 0x01. Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked.
max98090_interrupt max98090_pll_work ---------------------------------------------- schedule max98090_pll_work restart max98090 codec receive ULK INT assert ULK == 0 schedule max98090_pll_work (1).
In the case (1), the PLL is locked but max98090_interrupt unnecessarily schedules another max98090_pll_work.
max98090_interrupt max98090_pll_work max98090 codec ---------------------------------------------------------------------- ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) schedule max98090_pll_work restart max98090 codec ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) read 0x01 assert ULK == 0 (2).
In the case (2), both max98090_interrupt and max98090_pll_work read the same clear-on-read register. max98090_pll_work would falsely thought PLL is locked. Note: the case (2) race is introduced by the previous commit ("ASoC: max98090: exit workaround earlier if PLL is locked") to check the status and exit the loop earlier in max98090_pll_work.
There are 2 possible solution options: A. turn off ULK interrupt before scheduling max98090_pll_work; and turn on again before exiting max98090_pll_work. B. remove the second thread of execution.
Option A cannot fix the case (2) race because it still has 2 threads access the same clear-on-read register simultaneously. Although we could suppose the register is volatile and read the status via I2C could be much slower than the hardware raises the bits.
Option B introduces a maximum 10~12 msec penalty delay in the interrupt handler. However, it could only punish the jack detection by extra 10~12 msec.
Adopts option B which is the better solution overall.
Signed-off-by: Tzung-Bi Shih tzungbi@google.com --- sound/soc/codecs/max98090.c | 8 ++------ sound/soc/codecs/max98090.h | 1 - 2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index f531e5a11bdd..e46b6ada13b1 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2103,10 +2103,8 @@ static void max98090_pll_det_disable_work(struct work_struct *work) M98090_IULK_MASK, 0); }
-static void max98090_pll_work(struct work_struct *work) +static void max98090_pll_work(struct max98090_priv *max98090) { - struct max98090_priv *max98090 = - container_of(work, struct max98090_priv, pll_work); struct snd_soc_component *component = max98090->component; unsigned int pll; int i; @@ -2275,7 +2273,7 @@ static irqreturn_t max98090_interrupt(int irq, void *data)
if (active & M98090_ULK_MASK) { dev_dbg(component->dev, "M98090_ULK_MASK\n"); - schedule_work(&max98090->pll_work); + max98090_pll_work(max98090); }
if (active & M98090_JDET_MASK) { @@ -2438,7 +2436,6 @@ static int max98090_probe(struct snd_soc_component *component) max98090_pll_det_enable_work); INIT_WORK(&max98090->pll_det_disable_work, max98090_pll_det_disable_work); - INIT_WORK(&max98090->pll_work, max98090_pll_work);
/* Enable jack detection */ snd_soc_component_write(component, M98090_REG_JACK_DETECT, @@ -2491,7 +2488,6 @@ static void max98090_remove(struct snd_soc_component *component) cancel_delayed_work_sync(&max98090->jack_work); cancel_delayed_work_sync(&max98090->pll_det_enable_work); cancel_work_sync(&max98090->pll_det_disable_work); - cancel_work_sync(&max98090->pll_work); max98090->component = NULL; }
diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h index 57965cd678b4..a197114b0dad 100644 --- a/sound/soc/codecs/max98090.h +++ b/sound/soc/codecs/max98090.h @@ -1530,7 +1530,6 @@ struct max98090_priv { struct delayed_work jack_work; struct delayed_work pll_det_enable_work; struct work_struct pll_det_disable_work; - struct work_struct pll_work; struct snd_soc_jack *jack; unsigned int dai_fmt; int tdm_slots;
The patch
ASoC: max98090: fix possible race conditions
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From 45dfbf56975994822cce00b7475732a49f8aefed Mon Sep 17 00:00:00 2001
From: Tzung-Bi Shih tzungbi@google.com Date: Fri, 22 Nov 2019 15:31:14 +0800 Subject: [PATCH] ASoC: max98090: fix possible race conditions
max98090_interrupt() and max98090_pll_work() run in 2 different threads. There are 2 possible races:
Note: M98090_REG_DEVICE_STATUS = 0x01. Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked.
max98090_interrupt max98090_pll_work ---------------------------------------------- schedule max98090_pll_work restart max98090 codec receive ULK INT assert ULK == 0 schedule max98090_pll_work (1).
In the case (1), the PLL is locked but max98090_interrupt unnecessarily schedules another max98090_pll_work.
max98090_interrupt max98090_pll_work max98090 codec ---------------------------------------------------------------------- ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) schedule max98090_pll_work restart max98090 codec ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) read 0x01 assert ULK == 0 (2).
In the case (2), both max98090_interrupt and max98090_pll_work read the same clear-on-read register. max98090_pll_work would falsely thought PLL is locked. Note: the case (2) race is introduced by the previous commit ("ASoC: max98090: exit workaround earlier if PLL is locked") to check the status and exit the loop earlier in max98090_pll_work.
There are 2 possible solution options: A. turn off ULK interrupt before scheduling max98090_pll_work; and turn on again before exiting max98090_pll_work. B. remove the second thread of execution.
Option A cannot fix the case (2) race because it still has 2 threads access the same clear-on-read register simultaneously. Although we could suppose the register is volatile and read the status via I2C could be much slower than the hardware raises the bits.
Option B introduces a maximum 10~12 msec penalty delay in the interrupt handler. However, it could only punish the jack detection by extra 10~12 msec.
Adopts option B which is the better solution overall.
Signed-off-by: Tzung-Bi Shih tzungbi@google.com Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/codecs/max98090.c | 8 ++------ sound/soc/codecs/max98090.h | 1 - 2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index f531e5a11bdd..e46b6ada13b1 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2103,10 +2103,8 @@ static void max98090_pll_det_disable_work(struct work_struct *work) M98090_IULK_MASK, 0); }
-static void max98090_pll_work(struct work_struct *work) +static void max98090_pll_work(struct max98090_priv *max98090) { - struct max98090_priv *max98090 = - container_of(work, struct max98090_priv, pll_work); struct snd_soc_component *component = max98090->component; unsigned int pll; int i; @@ -2275,7 +2273,7 @@ static irqreturn_t max98090_interrupt(int irq, void *data)
if (active & M98090_ULK_MASK) { dev_dbg(component->dev, "M98090_ULK_MASK\n"); - schedule_work(&max98090->pll_work); + max98090_pll_work(max98090); }
if (active & M98090_JDET_MASK) { @@ -2438,7 +2436,6 @@ static int max98090_probe(struct snd_soc_component *component) max98090_pll_det_enable_work); INIT_WORK(&max98090->pll_det_disable_work, max98090_pll_det_disable_work); - INIT_WORK(&max98090->pll_work, max98090_pll_work);
/* Enable jack detection */ snd_soc_component_write(component, M98090_REG_JACK_DETECT, @@ -2491,7 +2488,6 @@ static void max98090_remove(struct snd_soc_component *component) cancel_delayed_work_sync(&max98090->jack_work); cancel_delayed_work_sync(&max98090->pll_det_enable_work); cancel_work_sync(&max98090->pll_det_disable_work); - cancel_work_sync(&max98090->pll_work); max98090->component = NULL; }
diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h index 57965cd678b4..a197114b0dad 100644 --- a/sound/soc/codecs/max98090.h +++ b/sound/soc/codecs/max98090.h @@ -1530,7 +1530,6 @@ struct max98090_priv { struct delayed_work jack_work; struct delayed_work pll_det_enable_work; struct work_struct pll_det_disable_work; - struct work_struct pll_work; struct snd_soc_jack *jack; unsigned int dai_fmt; int tdm_slots;
On 11/22/19 1:31 AM, Tzung-Bi Shih wrote:
This series is a follow up fix for the question: https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/157364.ht...
For the series
Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Hope this is the last time we see this PLL unlock error :-)
Changes from v1: ASoC: max98090: remove msleep in PLL unlocked workaround
- add more comments
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158969.h...
ASoC: max98090: exit workaround earlier if PLL is locked
- "sleep first and then check the status"
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158998.h...
ASoC: max98090: fix possible race conditions
- fix typo
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158966.h...
- add more descriptions in commit message
Tzung-Bi Shih (3): ASoC: max98090: remove msleep in PLL unlocked workaround ASoC: max98090: exit workaround earlier if PLL is locked ASoC: max98090: fix possible race conditions
sound/soc/codecs/max98090.c | 30 +++++++++++++++++++++--------- sound/soc/codecs/max98090.h | 1 - 2 files changed, 21 insertions(+), 10 deletions(-)
participants (3)
-
Mark Brown
-
Pierre-Louis Bossart
-
Tzung-Bi Shih