Hi,
Am 13.10.2016 um 15:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
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.
I have now observed a really strange effect.
As soon as I plug in a headset (with or w/o microphone), the LEDs stop blinking and I get timeouts from the I2C bus where the LED controller and ths ts3a227 are connected to:
[ 317.843723] omap_i2c 4807c000.i2c: controller timed out [ 317.873828] leds pyra:green:mid: Setting an LED's brightness failed (-110) [ 318.963729] omap_i2c 4807c000.i2c: controller timed out [ 318.969375] leds pyra:blue:right: Setting an LED's brightness failed (-110) [ 320.003743] omap_i2c 4807c000.i2c: controller timed out
The first idea was that the chip is not correctly connected and e.g. the interrupt line has a short circuit to some I2C line. But that isn't the case. I2C SDA and SCL remain "high" in that state.
As soon as I unplug the LEDs continue to blink and everything is fine again.
The only remaining signal path I see is that Plug-Detect is also routed to the tsl6040. And I see the /proc/interrupts counter for twl6040_irq_plug increment by 2 for each plug/unplug sequence.
So could it be that headset insertion of the twl6040 disables something in i2c5???
What I have not yet tested is to cut the wire to the twl6040 and check if that is really the "stop i2c5 operation" signal.
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
BR, Nikolaus