Letux Kernel

Issue 482: Jack detection has become unreliable in 3.11 kernel

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:


In the GTA04A5 board there will be a GPIO based jack detection so 
this has low priority.
Labels: Priority:Low Milestone:3.12 Priority:Medium

Comment 2 by Nikolaus Schaller, Nov 14, 2013

May have been fixed by the latest .config and ALSA patch:


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: 
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 

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.

Created: 5 years 11 months ago by ben deering

Updated: 1 month 23 days ago

Status: New

Followed by: 2 persons