]> git.baikalelectronics.ru Git - kernel.git/commit
SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress detection
authorEnric Balletbo i Serra <enric.balletbo@collabora.com>
Fri, 19 Jul 2019 17:39:29 +0000 (19:39 +0200)
committerMark Brown <broonie@kernel.org>
Mon, 22 Jul 2019 12:00:48 +0000 (13:00 +0100)
commiteb52e6711535f1b9bfc631fc7ccfd024abca19e8
treed9ece8d1a74fb2fe63b283b29914f7506a12242a
parent1ee17d067153b72646fc942cc7bc9d26e1ae0b96
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.
E.g. (KEY_PLAYPAUSE)

 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 <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20190719173929.24065-1-enric.balletbo@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
sound/soc/rockchip/rockchip_max98090.c