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