Hi,

On 03-11-17 12:24, Mark Brown wrote:

On Fri, Nov 03, 2017 at 09:41:29AM +0100, Hans de Goede wrote:

...

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 ?

You can make a GPIO input device but obviously can't have anything reporting through the sound card interface without a sound card.

Ok, so I could make the driver generate evdev events of type EV_SW with code SW_HEADPHONE_INSERT. Does userspace do anything useful with this like automatically switching between headphones and speakers as a headphone-jack which is part of the sound card would do ?

If not, then is there a way to get a list of registered soundcards from a driver, then pick one of the cards based on some heuristics and then do the snd_soc_card_jack_new, etc. on the picked card?

I assume that the approach from: https://github.com/me176c-dev/kernel_asus_me176c/commit/498116d7e7b4718fa065...

Where the struct snd_soc_card byt_rt5640_card is made non-static and exported is not acceptable ?

Regards,

Hans

Hi,

On 03-11-17 18:40, Mark Brown wrote:

On Fri, Nov 03, 2017 at 01:09:37PM +0100, Hans de Goede wrote:

...

On 03-11-17 12:24, Mark Brown wrote:

...

...

You can make a GPIO input device but obviously can't have anything reporting through the sound card interface without a sound card.

...

Ok, so I could make the driver generate evdev events of type EV_SW with code SW_HEADPHONE_INSERT. Does userspace do anything useful with this like automatically switching between headphones and speakers as a headphone-jack which is part of the sound card would do ?

Depends on your userspace, you can also do an extcon which Android listens to IIRC.

...

If not, then is there a way to get a list of registered soundcards from a driver, then pick one of the cards based on some heuristics and then do the snd_soc_card_jack_new, etc. on the picked card?

...

I assume that the approach from: https://github.com/me176c-dev/kernel_asus_me176c/commit/498116d7e7b4718fa065...

...

Where the struct snd_soc_card byt_rt5640_card is made non-static and exported is not acceptable ?

Why not have the sound card claim the GPIO and provide the jack?

Yes that would be ideal, but on some devices the ACPI resources table describing the gpio is not part of the acpi_companion of the codec, but rather of another ACPI device all together.

It might be best to see if we can somehow search through the list of ACPI devices from the codec driver and get through the GPIO that way. I guess we will need a utility function for this to share between codec drivers, since the same AMCR0F28 ACPI device is used in DSTDs together with different codecs.

Regards,

Hans

Hi,

On 03-11-17 13:41, Pierre-Louis Bossart wrote:

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/498116d7e7b4718fa065...

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 one problem here is that your work is based on getting gpios from the acpi_companion of the codec, but in the dsdt of Umberto's device: https://github.com/sfumato77/DSDT/blob/master/dsdt.dsl the gpio ("\_SB.GPO2" pin 0x1b) is only part of the resources list of the TIMC0F28 and the AMCR0F28 devices and on one of my tablets with an es8316 which uses the same gpio for headphone detection the same is true.

So as I said in my reply to Mark:

"It might be best to see if we can somehow search through the list of ACPI devices from the codec driver and get to the GPIO that way. I guess we will need a utility function for this to share between codec drivers, since the same AMCR0F28 ACPI device is used in DSTDs together with different codecs."

Would adding such a utility function to parse the gpio info in the AMCR0F28 ACPI device on devices where this is necessary be acceptable?

Of course using the AMCR0F28 ACPI device is not going to be the right thing to do everywhere, so we are going to need a (dmi-based) quirk table in the codec driver for this.

Regards,

Hans

...

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