[PATCH] ASoC: dmic: Allow GPIO operations to sleep
If there is a power GPIO provided we control it from DAPM context so there is no problem with a sleeping GPIO, use the _cansleep() version of the API to allow this.
Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/codecs/dmic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c index f5560a49b9e5..5d079d90fd3b 100644 --- a/sound/soc/codecs/dmic.c +++ b/sound/soc/codecs/dmic.c @@ -59,14 +59,14 @@ static int dmic_aif_event(struct snd_soc_dapm_widget *w, switch (event) { case SND_SOC_DAPM_POST_PMU: if (dmic->gpio_en) - gpiod_set_value(dmic->gpio_en, 1); + gpiod_set_value_cansleep(dmic->gpio_en, 1);
if (dmic->wakeup_delay) msleep(dmic->wakeup_delay); break; case SND_SOC_DAPM_POST_PMD: if (dmic->gpio_en) - gpiod_set_value(dmic->gpio_en, 0); + gpiod_set_value_cansleep(dmic->gpio_en, 0); break; }
On Wed, Apr 22, 2020 at 4:37 PM Mark Brown broonie@kernel.org wrote:
If there is a power GPIO provided we control it from DAPM context so there is no problem with a sleeping GPIO, use the _cansleep() version of the API to allow this.
Compared gpiod_set_value_cansleep() vs. gpiod_set_value().
gpiod_set_value_cansleep() + might_sleep_if(extra_checks);
gpiod_set_value() + /* Should be using gpiod_set_value_cansleep() */ + WARN_ON(desc->gdev->chip->can_sleep);
And the extra_checks is: #ifdef DEBUG #define extra_checks 1 #else #define extra_checks 0 #endif
Looks like it only changes behavior when DEBUG.
Wondering about: - Did you get any warning message to inspire you to use _cansleep() version? - Does that imply in any _can sleep_ context, it is more encouraged to call _cansleep() version? (e.g. https://elixir.bootlin.com/linux/v5.7-rc2/source/sound/soc/codecs/max98357a....)
On Wed, Apr 22, 2020 at 05:24:54PM +0800, Tzung-Bi Shih wrote:
Wondering about:
- Did you get any warning message to inspire you to use _cansleep() version?
No, pure code inspection. I don't know that I've got any systems that can run this driver.
- Does that imply in any _can sleep_ context, it is more encouraged to
call _cansleep() version? (e.g. https://elixir.bootlin.com/linux/v5.7-rc2/source/sound/soc/codecs/max98357a....)
Yes, it's better.
On Wed, Apr 22, 2020 at 4:37 PM Mark Brown broonie@kernel.org wrote:
If there is a power GPIO provided we control it from DAPM context so there is no problem with a sleeping GPIO, use the _cansleep() version of the API to allow this.
Signed-off-by: Mark Brown broonie@kernel.org
Reviewed-by: Tzung-Bi Shih tzungbi@google.com
On Wed, 22 Apr 2020 09:35:50 +0100, Mark Brown wrote:
If there is a power GPIO provided we control it from DAPM context so there is no problem with a sleeping GPIO, use the _cansleep() version of the API to allow this.
Signed-off-by: Mark Brown broonie@kernel.org
sound/soc/codecs/dmic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/1] ASoC: dmic: Allow GPIO operations to sleep commit: 5d7e0b1516dfc5901d1e394f17eb55b360e7d3d3
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
participants (2)
-
Mark Brown -
Tzung-Bi Shih