[PATCH] ASoC: dmic: Allow GPIO operations to sleep

[PATCH] ASoC: dmic: Allow GPIO operations to sleep

[Mark Brown]

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;
 	}
 
-- 
2.20.1

Re: [PATCH] ASoC: dmic: Allow GPIO operations to sleep

[Tzung-Bi Shih]

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.c#L41)

Re: [PATCH] ASoC: dmic: Allow GPIO operations to sleep

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

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.c#L41)

Yes, it's better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] ASoC: dmic: Allow GPIO operations to sleep

[Tzung-Bi Shih]

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>

Re: [PATCH] ASoC: dmic: Allow GPIO operations to sleep

[Mark Brown]

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