On Sun, Feb 17, 2013 at 06:11:45PM +0000, Mark Brown wrote:
On Sun, Feb 17, 2013 at 12:07:25PM +0530, Omair M. Abdullah wrote:
On Fri, Feb 15, 2013 at 12:17:27PM +0000, Mark Brown wrote:
It sounds like all you're looking for here is a better debounce algorithm, for example one that delays for a bit then starts polling the GPIO state at a higher rate and declares a result when the GPIO state doesn't change for a few polls.
We are using a polling mechanism in our system to check the jack state a few times. But what we observed is that we always get a bounce.
If you're already doing that then this is at best redundant and at worst will make things worse if you do happen to hit a case where you don't see any bounce for some reason.
Also, we do have a system where we are using the snd_soc_jack_gpio code for a codec interrupt through a GPIO line, like Ramesh mentioned - even if it is just for re-using the software debounce mechanism. In such cases, the interrupt would be triggered on one edge only. Maybe that is not the original intent the of that code?
What you're describing does not sound at all sane, the GPIO jack code is there for managing GPIO jacks not for providing a generic debounce mechanism for interrupts. I'm not sure how you'd actually go about doing this...
If you have the codec interrupt line which is connected to the SoC through a GPIO then this is possible.