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