On Sun, Sep 15, 2013 at 11:56:25AM +0100, Jonathan Cameron wrote: > On 09/11/13 09:18, Juergen Beisert wrote: > > For battery driven systems it is a very bad idea to collect the touchscreen > > data within a kernel busy loop. > > > > This change uses the features of the hardware to delay and accumulate samples in > > hardware to avoid a high interrupt and CPU load. > > > > Note: this is only tested on an i.MX23 SoC yet. > > > > Signed-off-by: Juergen Beisert <jbe@xxxxxxxxxxxxxx> > > CC: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > CC: devel@xxxxxxxxxxxxxxxxxxxx > > CC: Marek Vasut <marex@xxxxxxx> > > CC: Fabio Estevam <fabio.estevam@xxxxxxxxxxxxx> > > CC: Jonathan Cameron <jic23@xxxxxxxxx> > While this driver is placed in IIO within staging at the moment, these changes are definitely > input related. Hence I have cc'd Dmitry and the input list. > > I am personaly a little uncomfortable that we have such a complex bit of input code sat > within an IIO driver but such is life. > ... > > > > static int mxs_lradc_ts_register(struct mxs_lradc *lradc) > > @@ -641,6 +1056,7 @@ static void mxs_lradc_ts_unregister(struct mxs_lradc *lradc) > > > > cancel_work_sync(&lradc->ts_work); > > > > + mxs_lradc_disable_ts(lradc); > > input_unregister_device(lradc->ts_input); > > } This looks iffy... Normally you disable the device so that it does not generate more interrupts, and then cancel outstanding work(s), otherwise newly generated interrupts may cause more work to be scheduled. Or I missed some of the context and this is not a concern here? Thanks. -- Dmitry _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
