[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1264501741.5260.29.camel@realization>
Date: Tue, 26 Jan 2010 11:29:01 +0100
From: Alberto Panizzo <maramaopercheseimorto@...il.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: H Hartley Sweeten <hartleys@...ionengravers.com>,
linux-input@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-arm-kernel-infradead <linux-arm-kernel@...ts.infradead.org>,
Sascha linux-arm <s.hauer@...gutronix.de>
Subject: Re: [PATCH v2] input: MXC: add mxc-keypad driver to support the
Keypad Port present in the mxc application processors family.
Hi Dmitry! Thanks for reviewing!
On mar, 2010-01-26 at 01:52 -0800, Dmitry Torokhov wrote:
> > This algorithm is done via a threaded management of the keypad interrupt source
> > and delayed by a proper (and longer) debounce interval controlled by the
> > platform initialization.
>
> This I am not so sure about - the core of the matrix scan routine does
> not sleep so I wonder if starting a separate thread is not too wasteful
> in this case - you can easily do whan you want with a timer, no?
I'm pretty new to kernel programming and, from the university, the
threaded way looked the better (and unique) for me..
Let me find some documentation on timers and I will restructure the
interrupt management. Yes I need only to delay the matrix-scan activity
without waste cpu time.
>
> > +
> > + /*
> > + * Search for rows and cols enabled
> > + */
> > + keymap_data = (struct matrix_keymap_data *) pdata->keymap_data;
>
> Why do you need to cast away constness instead of declaring keymap_data
> as const pointer?
In next version will be fixed.
Alberto!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists