Am 15.10.2016 um 12:52 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 15.10.2016 um 11:02 schrieb H. Nikolaus Schaller hns@goldelico.com:
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.
Hm. I still have this effect after cutting the connection to the twl6040. Maybe I am simply irritated by a broken ts3a227 chip.
I have to check if I have one for replacement or have to buy one first.
I would have to buy new chips first...
So I did run a simple test in U-Boot.
Chip seems to work (register 00 is the device ID and 01 is the interrupt status register):
=> i2c md 3b 00.0 0000: 11 00 00 08 23 00 0e 00 00 0c 00 00 00 20 40 68 ....#........ @h
11 is the correct device ID and all other register values look exactly as defined by section 9.5 of the data sheet.
After some plugin/out tests:
=> i2c md 3b 01 1 0001: 03 . => i2c md 3b 01 1 0001: 01 . => i2c md 3b 01 1 0001: 00 . => i2c md 3b 01 1 0001: 00 . => i2c md 3b 01 1 0001: 00 .
----> plug in headset
=> i2c md 3b 01 1 0001: 03 . => i2c md 3b 01 1 0001: 00 . => i2c md 3b 01 1 0001: 00 . => i2c md 3b 01 1
----> unplug headset
0001: 01 . => i2c md 3b 01 1 0001: 00 . =>
So U-Boot shows no problems on headset insertion. Of course there are no multiple users of the I2C bus in this test (no LEDs blinking, no tca6424 interrupt processing).
Therefore it appears as if the ts3a227 chip is running fine from hardware side. But somehow the kernel stumbles over it.
Next I will try to disable the ts3a227 interrupt in kernel. Maybe it is indeed a bug in the kernel interrupt handlers. Maybe the i2c bus is not properly unlocked while processing interrupts.
We have to remember that probably nobody else is using the ts3a227 interrupt behind a tca6424 gpio expander and has both connected to the same i2c bus. So nobody has tested that combination before...
BR, Nikolaus