Messages in this thread | | | From | Haojian Zhuang <> | Date | Mon, 18 Apr 2011 06:12:25 -0700 | Subject | RE: [PATCH 01/13] input: touchscreen: use polling mode in 88pm860x |
| |
>-----Original Message----- >From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] >Sent: 2011年4月16日 10:17 PM >To: Haojian Zhuang >Cc: haojian.zhuang@gmail.com; sameo@linux.intel.com; linux- >kernel@vger.kernel.org; Dmitry Torokhov >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's 7msec whatever you choose any silicon. So it's not a problem.
> >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? > >
| |