[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60599.1302963433@localhost>
Date: Sat, 16 Apr 2011 10:17:13 -0400
From: Valdis.Kletnieks@...edu
To: Haojian Zhuang <haojian.zhuang@...vell.com>
Cc: haojian.zhuang@...il.com, sameo@...ux.intel.com,
linux-kernel@...r.kernel.org,
Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH 01/13] input: touchscreen: use polling mode in 88pm860x
On Sat, 16 Apr 2011 20:46:20 +0800, Haojian Zhuang said:
> Measuring point on touchscreen with IRQ mode can only monitor pen-down
> event. If finger is moving on touchscreen, it can't be monitored by
> IRQ pen-down event. So switch to polling mode after pen-down event.
> drivers/input/touchscreen/88pm860x-ts.c | 79 ++++++++++++++++++++++++------
> +/*
> + * While 32KHz hardware timer is used for scheduler, we always assign HZ
> + * to 128. It means that 1 tick costs 7.8msec.
> + */
> +#define MEASURE_INTERVAL_MS (7)
Is it guaranteed that this hardware part will only ever be used on systems
where this is true? How big a bug would it be if somebody tried to glue this
touchscreen into some random embedded-ARM where HZ was something else, and
should this be computed as a function of HZ instead of hardcoding 7?
It *looks* like the intent of the schedule_delayed_work() call is "let's run
this once a tick when we're awake *anyhow*" - but looking at the code, I can't
convince myself a rounding error in computing 'interval' won't schedule 1ms
before or after the next tick would have been. Isn't there a better API with
slack timers or something that would do a better "next tick" job?
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists