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 think I finally managed to make the tca6424 (4-0022) driver handle interrupts (it is a little crazy chip). There was also some wrong pinmux in the DT which made the kernel block after some interrupts being processed.
What I have not yet seen are ts3a227e interrupts... And I am not exactly sure if they are correctly enabled because /proc/interrupts lists it but with count 0.
178: 0 0 4805b000.gpio 15 Edge RIGHT 195: 23057 0 WUGEN 34 Level 4805d000.gpio 197: 23057 0 4805d000.gpio 1 Level 4-0022 210: 0 0 4805d000.gpio 14 Level TS3A227E 215: 0 0 4805d000.gpio 19 Edge Right-Shoulder-Top
But for the ts3a227e there is also one missing piece in code/DT.
The driver defines a function ts3a227e_enable_jack_detect which is assumed to be called from some sound-boardfile.
But we have none with omap5 and DT. Or do we have?
Here is where this function is defined and used by
sound/soc/intel/boards/cht_bsw_max98090_ti.c and sound/soc/rockchip/rockchip_max98090.c
See: http://lxr.free-electrons.com/ident?i=ts3a227e_enable_jack_detect
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.
BR and thanks, Nikolaus
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.
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. Actually I'm pretty much interested in using Pyra as voice communications device.
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
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
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.
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
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
Hi, I have some progress.
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.
This has been identified as a missing component on my prototype board. This did have the effect that the GND line of the ts3a chip was floating.
It appears that as long as no headset is inserted there is enough leakage current to make the I2C interface work, but as soon as I insert the headset, I2C stops working (and the "GND" voltage goes up).
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...
All this did not work due to the hardware issue mentioned above.
But now as it is solved, I can't get the ts3a plug detection interrupt working.
So again I have to ask for your kernel specialists help.
I could trace it to that the ts3a chip driver is registering an interrupt but the pca935x driver is never called to change its masks. Hence it does not know what to do if an interrupt arrives at one of the inputs.
Here is a short trace (by adding some printk in an attempt to understand how interrupt registration works):
[ 5.280900] pca953x_setup_gpio [ 5.308539] pca953x_irq_setup 1 [ 5.312458] pca953x_irq_setup 2 [ 5.315975] pca953x_irq_bus_lock [ 5.319527] pca953x_irq_bus_sync_unlock [ 5.323704] pca953x_irq_bus_lock [ 5.327117] pca953x_irq_bus_sync_unlock [ 5.331279] pca953x_irq_bus_lock [ 5.334667] pca953x_irq_bus_sync_unlock [ 5.338852] pca953x_irq_bus_lock [ 5.342238] pca953x_irq_bus_sync_unlock [ 5.346386] pca953x_irq_bus_lock [ 5.349795] pca953x_irq_bus_sync_unlock [ 5.353949] pca953x_irq_bus_lock [ 5.357360] pca953x_irq_bus_sync_unlock [ 5.361518] pca953x_irq_bus_lock [ 5.364902] pca953x_irq_bus_sync_unlock [ 5.369078] pca953x_irq_bus_lock [ 5.372460] pca953x_irq_bus_sync_unlock [ 5.376634] pca953x_irq_bus_lock [ 5.380015] pca953x_irq_bus_sync_unlock [ 5.384169] pca953x_irq_bus_lock [ 5.387574] pca953x_irq_bus_sync_unlock [ 5.391722] pca953x_irq_bus_lock [ 5.395112] pca953x_irq_bus_sync_unlock [ 5.399283] pca953x_irq_bus_lock [ 5.402672] pca953x_irq_bus_sync_unlock [ 5.406849] pca953x_irq_bus_lock [ 5.410239] pca953x_irq_bus_sync_unlock [ 5.414386] pca953x_irq_bus_lock [ 5.417791] pca953x_irq_bus_sync_unlock [ 5.421947] pca953x_irq_bus_lock [ 5.425334] pca953x_irq_bus_sync_unlock [ 5.429512] pca953x_irq_bus_lock [ 5.432897] pca953x_irq_bus_sync_unlock [ 5.437072] pca953x_irq_bus_lock [ 5.440463] pca953x_irq_bus_sync_unlock [ 5.444612] pca953x_irq_bus_lock [ 5.448014] pca953x_irq_bus_sync_unlock [ 5.452370] pca953x_irq_bus_lock [ 5.455767] pca953x_irq_bus_sync_unlock [ 5.459995] pca953x_irq_bus_lock [ 5.463378] pca953x_irq_bus_sync_unlock [ 5.467554] pca953x_irq_bus_lock [ 5.470941] pca953x_irq_bus_sync_unlock [ 5.475094] pca953x_irq_bus_lock [ 5.478499] pca953x_irq_bus_sync_unlock [ 5.482657] pca953x_irq_bus_lock [ 5.486042] pca953x_irq_bus_sync_unlock [ 5.490212] pca953x_irq_bus_lock [ 5.493598] pca953x_irq_bus_sync_unlock
[ 9.009952] driver_register 'ts3a227e' [ 9.013202] request_threaded_irq(210, 2008, TS3A227E) [ 9.013208] chip_bus_lock() [ 9.013213] __setup_irq() [ 9.013216] __setup_irq() 1 [ 9.013219] __setup_irq() 2 [ 9.013222] __setup_irq() 3 [ 9.023889] __setup_irq() 4 [ 9.023893] __setup_irq() 5 [ 9.023916] __setup_irq() 6 [ 9.024023] __setup_irq() 8 [ 9.024026] __setup_irq() -> 0 [ 9.024029] request_threaded_irq() -> 0
So this means that request_threaded_irq() returns 0 and a all steps of __setup_irq() are done.
Somewhere the gpiochip should be called to enable the bit mask as defined by the DT. I guess through some combination of:
pca953x_irq_set_type() static void pca953x_irq_mask() pca953x_irq_bus_sync_unlock()
But none of these functions is called.
So I ask: a) is there a bug in interrupt (gpiochip_irqchip_add/gpiochip_set_chained_irqchip) registration b) is there somehing needed in DT c) is there an enable irq missing in the ts3a227 driver? d) should chip_bus_lock() be forwarded to pca953x_irq_bus_lock? If yes, why isn't it?
So if someone else could please dig into this (at least from code inspection) it would probably save me a lot of time to give an ok for the ts3a227 hardware design.
BR and thanks, Nikolaus
On Thu, Oct 20, 2016 at 03:40:29PM +0200, H. Nikolaus Schaller wrote:
But now as it is solved, I can't get the ts3a plug detection interrupt working.
From your description it seems your actual problem is lack of update of
GPIO management chip config, at last it is where you are looking for the problem. However from skimming drivers/gpio/gpio-pca953x.c and sound/soc/codecs/ts3a227e.c it caught my attention that ts3a227e seems to need explicit ts3a227e_enable_jack_detect() call in order to bind events to actual struct snd_soc_jack *jack, which is used in snd_soc_jack_report(). snd_soc_jack_report() returns early if jack is NULL, which is the case until ts3a227e_enable_jack_detect() is called.
You can see these calls in place only for two SoCs in linux repo, and none of them seem related to Pyra or Letux project:
$ grep ts3a227e_enable_jack_detect * -RnI sound/soc/rockchip/rockchip_max98090.c:173: ret = ts3a227e_enable_jack_detect(component, &headset_jack); sound/soc/intel/boards/cht_bsw_max98090_ti.c:204: return ts3a227e_enable_jack_detect(component, &ctx->jack);
Maybe the problem is here? Or, at last, this is one of parts which should be changed to fix the problem?
I'm not sure what I'll say next makes sense, but I guess you could somehow manage to configure that GPIO chip pca953x to enable pins of ts3a227e statically. Then, the only remaining thing to do would be ts3a227e_enable_jack_detect(). However, I have no idea what is appropriate place and context to put that call into.
Hi Andrey,
Am 22.10.2016 um 21:21 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Thu, Oct 20, 2016 at 03:40:29PM +0200, H. Nikolaus Schaller wrote:
But now as it is solved, I can't get the ts3a plug detection interrupt working.
From your description it seems your actual problem is lack of update of GPIO management chip config, at last it is where you are looking for the problem. However from skimming drivers/gpio/gpio-pca953x.c and sound/soc/codecs/ts3a227e.c it caught my attention that ts3a227e seems to need explicit ts3a227e_enable_jack_detect() call in order to bind
yes, that also caught my attention when starting this thread (see my first mail).
events to actual struct snd_soc_jack *jack, which is used in snd_soc_jack_report(). snd_soc_jack_report() returns early if jack is NULL, which is the case until ts3a227e_enable_jack_detect() is called.
Indeed.
You can see these calls in place only for two SoCs in linux repo, and none of them seem related to Pyra or Letux project:
$ grep ts3a227e_enable_jack_detect * -RnI sound/soc/rockchip/rockchip_max98090.c:173: ret = ts3a227e_enable_jack_detect(component, &headset_jack); sound/soc/intel/boards/cht_bsw_max98090_ti.c:204: return ts3a227e_enable_jack_detect(component, &ctx->jack);
These seem to be "sound board files" which are AFAIK a little deprecated, but not as much as "board files".
Maybe the problem is here? Or, at last, this is one of parts which should be changed to fix the problem?
I had thought about that as well, but in my understanding it only enables headset reporting through the sound system.
But the ts3a227e_interrupt() should be called anyways and only reporting should be suppressed if jack == NULL.
I have added some printk to ts3a227e_interrupt() but it stays silent :(
Or is there a side-effect of ts3a227e_enable_jack_detect() that indirectly enables interrupts?
I'm not sure what I'll say next makes sense, but I guess you could somehow manage to configure that GPIO chip pca953x to enable pins of ts3a227e statically.
Ah, a good hack! At least for completing my hardware test of the Pyra mainboard we could have something into the probe function of the pca953x driver so that the interrupt mask becomes correctly set. Maybe I can make it conditional on the presence of some ts3a227 DT node so that it triggers only on the Pyra mainboard.
If that works I can complete my hw test and we can postpone debugging of the pca953x and ts3a227 interrupt setup until we have more developers with real (and final) hardware.
Then, the only remaining thing to do would be ts3a227e_enable_jack_detect(). However, I have no idea what is appropriate place and context to put that call into.
Well, I think there should also be some "sound board file" for the Pyra. I assume it is the default:
sound/soc/omap/omap-abe-twl6040.c since
we define
http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap5-board-common.dt...
Hm. There is already a jack detection by the twl6040 driver but we don't have the property ti,jack-detection. It is only used by arch/arm/boot/dts/omap4-sdp.dts.
Interesting.
Maybe not having this propery and still activating the twl6040 plugdet input makes the kernel hang problem I have reported to Peter in a different mail subject ("wl6040 plugdet intererupt").
So we have two new ideas :)
Thanks and BR, Nikolaus
-
Andrey Utkin -
H. Nikolaus Schaller