Re: [PATCH 5/6] Staging/iio/adc/touchscreen/MXS: add interrupt driven touch detection

On Sun, Sep 15, 2013 at 11:56:25AM +0100, Jonathan Cameron wrote:

On 09/11/13 09:18, Juergen Beisert wrote:

quoted

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 <redacted>
CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
CC: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org
CC: Marek Vasut <redacted>
CC: Fabio Estevam <redacted>
CC: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>

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.

...

quoted

 
 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