Hi Andrey,
Am 13.10.2016 um 14:50 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Thu, Oct 13, 2016 at 02:37:28PM +0200, H. Nikolaus Schaller wrote:
Hi, I am trying to make headset detection work.
Previously there was a ts3a225 (like omap5 evm) with a driver hacked by me:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
It is simply polling the device for changes and printing some messages. No other integration into the sound system exists.
Now, the Pyra mass production shall use the ts3a227e because it is newer, better and has an in-kernel driver:
http://lxr.free-electrons.com/source/sound/soc/codecs/ts3a227e.c
What differs is that it is interrupt driven. So we need to set up the interrupts for this chip.
I have one prototype mainboard with ts3a227e hooked up so that it can send an interrupt through the tca6424 gpio expander (like on the EVM).
I have two different 4-contact-audiojack wired headsets - from Beats and from Lenovo smartphone. EvilDragon said that I'll receive Pyra prototype in blue case in nearest days. Should I be able to work on this issue with what I will have? From your description it is a bit unclear which chips (of two mentioned) are used in Pyra prototypes.
All of them have the older 225 chip which has no good driver, but I have already tested with different headsets. If connected correctly, it correctly detects the different headsets ans switches and reports if there is a microphone or none... But this result is quite useless for the mass production devices which shall get the newer 227 chip.
At the moment there is only the single 227 prototype I have on my desk and I need to verify that it basically works, before finalizing mass production PCB and BOM lists.
So I need someone who can help me to understand how to correctly set up the 227 driver on omap5 + twl6040 audio.
The alternative would be to hack my 225 test driver to account for the slightly different registers. But then I can't test if 227 interrupts work and arrive in the driver. I can then only see if the chip responds. But that is not much new information since I can already see the chip by i2cdetect and the driver probes successfully.
So if someone with much better knowledge about the kernel sound system (which is easy since I have almost none), could help to make this fixed, please raise your hands.
I am actually not experienced or qualified on sound system, but I would be glad to make it happen.
Me too :) So we need some real expert to discuss with...
Actually I'm pretty much interested in using Pyra as voice communications device.
The latter should already be possible. It might just silently switch headset contacts but not report jack insertion or microphone button events...
BR and thanks, Nikolaus