On 11/3/17 3:41 AM, Hans de Goede wrote:
Hi All,
Umberto Izzo (in the Cc) mailed me to see if I could help
with implementing headphone detection through GPIOS as I've
been doing all kinds of Bay / Cherry Trail related work
recently.
Umberto found this commit:
https://github.com/me176c-dev/kernel_asus_me176c/commit/498116d7e7b4718fa0655c4879e59a163b1dd85b
Which looks interesting, but is specific to the RT5640
driver. Looking at my own test devices I found a device
with an ES8316 using a gpio for headphone detection.
What Umberto and my device have in common is that
the GPIO to use is listed in the ACPI tables
under an AMCR0F28 device and that is also what the
above commit binds too.
This is not a generic solution, these sort of ACPI entries are only
present in devices designed for Android, in Windows the STA_ method
typically reports 0 (not present) - the ASL code is usually shared
between Windows and Android devices but there are variables controlling
what the run-time behavior is, mostly to avoid the yellow bang the
windows device manager if there is a device without a driver.
Also you have two quirks for each of jack detection / button press, some
platforms rely on codec-based detection and some of gpios directly
connected to the SOC. We tried to port some of the code from Android a
while ago but i haven't had time to maintain or even clean it. See
https://github.com/plbossart/sound/pull/1
So I was wondering if there is a way to have a headphone
switch without tying it to a card, while userspace will
still know what to do ?
###
Another (non audio) problem is that the AMCR0F28 ACPI
device seems to be present in the DSTD for almost all
Bay / Cherry Trail devices, but its _STA method always
returns 0 even on devices where we do need to use gpios
for headphone-detection.
I'm thinking about solving this by adding the AMCR0F28
device to the list of always present ACPI devices, so that
the kernel ignores _STA and creates a platform device for
it. And then in the platform driver for the AMCR0F28
platform device use a DMI whitelist, this is not the
prettiest solution but it is the best I can come up with
atm. As said not really audio related,
Regards,
Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
