Reported by ben deering, Sep 12, 2013
Headset jack detection does not work well in 3.11. Sometimes it detects when a jack is plugged in. Sometimes it does not. If the jack is detected, the gta04 will think it has been unplugged a short time later when it hasn't. This did not happen in 3.7. I think there was a recent commit in 3.7 to ignore invalid jack values instead of treating them as events. It may just be a matter of merging this commit into 3.11.
Comment 1 by Nikolaus Schaller, Sep 24, 2013
I have not verified the problem, but maybe this patch has been lost during rebase: http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=07d7c5a3c24f1 1445cd0dd1ba78cc92cf2c4ae54 In the GTA04A5 board there will be a GPIO based jack detection so this has low priority.
Comment 2 by Nikolaus Schaller, Nov 14, 2013
May have been fixed by the latest .config and ALSA patch: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/ master If still not working, we have to look to the patch mentioned above.
Comment 3 by Nikolaus Schaller, Nov 14, 2013
Just in case it's relevant, please see my jack detection observations from some time ago: http://lists.goldelico.com/pipermail/gta04-owner/2013-January/003758. html. My inference was that one of the detection conditions was wrong, and changing that did make jack detection much more stable for me. Probably this isn't anything to do with Ben's observation of a degradation from 3.7 to 3.12, but I do wonder if I just misunderstood the relevant code and in7_input values that I saw, and would appreciate any comments on that.
Comment 4 by ben deering, Nov 15, 2013
The .config fix did not fix the problem. I added a printk(val) in gta04_audio.c:169 and the values it get from madc don't make sense. They are almost always in the 337-341 range. This is plugged in or not. Once in a while it spikes to 828 for a very short time. Again, plugging in the headset seems to have no effect. I booted to a 3.7 kernel to veryify plug detection still works. It does. It seems like something is wrong with getting the converted value from the ADC.
Comment 5 by ben deering, Nov 15, 2013
twl4030-madc.c has a 5ms delay using msec_to_jiffies. This is similar to the problem with the bmp085. I wonder how many other places this is happening in the kernel?
Comment 6 by meenase, Jun 25, 2019
More projects and sharing the wonderful tips about reviews and including the essential documentation. Find here https://www.topaperwritingservices.com/review-essayshark-com/ the more educational methods and developing the more thoughts.