Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Wed, May 12, 2010 at 11:15:11AM +0530, Shilimkar, Santosh wrote:
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Arce,
> > Abraham
> > Sent: Wednesday, May 12, 2010 11:10 AM
> > To: Dmitry Torokhov
> > Cc: linux-input@vger.kernel.org; linux-omap@vger.kernel.org
> > Subject: RE: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
> > 
> > Dmitry,
> > 
> > 2 comments + one question before sending next version...
> > 
> > [...]
> > 
> > > > > > > +static irqreturn_t omap_keypad_threaded(int irq, void *dev_id)
> > > > > > > +{
> > > > > >
> > > > > > Why is iti threaded? I fo not see anything that will sleep.
> > > >
> > > >
> > > > It was implemented based on previous comments...
> > > >
> > >
> > > Would you point me to that comment? Like I said, I do not see anything
> > > that would possibly sleep in this routine so you don't need to use
> > > threaded interrupt.
> > 
> > Using now request_irq based on your comments. In same omap_keypad_interrupt disable/clear/enable
> > interrupts will be executed
> > 
> > [...]
> >
> Sorry for jumping into the comments late. Thought this was sorted out. Key scanning
> and debounce timeouts etc still there. Having all these things in ISR itself isn't good
> idea.
> 
> Dmitry,
> Don't you think its optimal to push the key-scanning and debounce timeout code
> part of bottom half ??
>

If you need debounce then you need to fire a timer and keep doing this
until interrupt (or key state) settles. It really depends on the device.

-- 
Dmitry