[lkml]   [2019]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectApplied "SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress detection" to the asoc tree
The patch

SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress detection

has been applied to the asoc tree at for-5.3

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.


From f86621cd6c6f54edfdd62da347b2bbb8d7fddc8d Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <>
Date: Fri, 19 Jul 2019 19:39:29 +0200
Subject: [PATCH] SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset
keypress detection

The TS3A227E says that the headset keypress detection needs the MICBIAS
power in order to report the key events to ensure proper operation
The headset keypress detection needs the MICBIAS power in order to report
the key events all the time as long as MIC is present. So MICBIAS pin
is forced on when a MICROPHONE is detected.

On Veyron Minnie I observed that if the MICBIAS power is not present and
the key press detection is activated (just because it is enabled when you
insert a headset), it randomly reports a keypress on insert.

Event: (SW_HEADPHONE_INSERT), value 1
Event: (SW_MICROPHONE_INSERT), value 1
Event: -------------- SYN_REPORT ------------
Event: (KEY_PLAYPAUSE), value 1

Userspace thinks that KEY_PLAYPAUSE is pressed and produces the annoying
effect that the media player starts a play/pause loop.

Note that, although most of the time the key reported is the one
associated with BTN_0, not always this is true. On my tests I also saw
different keys reported

Signed-off-by: Enric Balletbo i Serra <>
Signed-off-by: Mark Brown <>
sound/soc/rockchip/rockchip_max98090.c | 32 ++++++++++++++++++++++++++
1 file changed, 32 insertions(+)

diff --git a/sound/soc/rockchip/rockchip_max98090.c b/sound/soc/rockchip/rockchip_max98090.c
index c5fc24675a33..782e534d4c0d 100644
--- a/sound/soc/rockchip/rockchip_max98090.c
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -61,6 +61,37 @@ static const struct snd_kcontrol_new rk_mc_controls[] = {

+static int rk_jack_event(struct notifier_block *nb, unsigned long event,
+ void *data)
+ struct snd_soc_jack *jack = (struct snd_soc_jack *)data;
+ struct snd_soc_dapm_context *dapm = &jack->card->dapm;
+ if (event & SND_JACK_MICROPHONE)
+ snd_soc_dapm_force_enable_pin(dapm, "MICBIAS");
+ else
+ snd_soc_dapm_disable_pin(dapm, "MICBIAS");
+ snd_soc_dapm_sync(dapm);
+ return 0;
+static struct notifier_block rk_jack_nb = {
+ .notifier_call = rk_jack_event,
+static int rk_init(struct snd_soc_pcm_runtime *runtime)
+ /*
+ * The jack has already been created in the rk_98090_headset_init()
+ * function.
+ */
+ snd_soc_jack_notifier_register(&headset_jack, &rk_jack_nb);
+ return 0;
static int rk_aif1_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
@@ -119,6 +150,7 @@ SND_SOC_DAILINK_DEFS(hifi,
static struct snd_soc_dai_link rk_dailink = {
.name = "max98090",
.stream_name = "Audio",
+ .init = rk_init,
.ops = &rk_aif1_ops,
/* set max98090 as slave */
 \ /
  Last update: 2019-07-22 14:23    [W:0.035 / U:18.076 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site