On 09/15/13 11:56, 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 <j...@pengutronix.de>
>> CC: linux-arm-ker...@lists.infradead.org
>> CC: de...@driverdev.osuosl.org
>> CC: Marek Vasut <ma...@denx.de>
>> CC: Fabio Estevam <fabio.este...@freescale.com>
>> CC: Jonathan Cameron <ji...@cam.ac.uk>
> 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.
The logic in here looks reasonable to me. I am far from a specialist in how
these touch
screens are normally handled though.
One thing to note is that you really want to get a proposed device tree spec
out asap
as that can take longer to review than the driver. If you are proposing to do
that as a future
patch, then take into account that you'll need to ensure these are the defaults
if
it is not specified in the device tree for ever more (which is more painful than
hammering out he device tree stuff now!)
...
>> +static int mxs_lradc_probe_touchscreen(struct mxs_lradc *lradc,
>> + struct device_node *lradc_node)
>> +{
>> + /* TODO retrieve from device tree */
>> + lradc->over_sample_cnt = 4;
>> + lradc->over_sample_delay = 2;
>> + lradc->settling_delay = 10;
>> +
>> + return 0;
>> +}
>> +
...
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
