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