I'm using an hrtimer in my tsc2004 touch driver to sleep between samples
for 7.5mSec. Here's the essence of the inner loop that grabs samples:
for (;;) {
// Get a point, pass it to input_report_abs...
pen_is_down = tsc2004_get_point(d);
// If pen is up up, then break out
if (!pen_is_down || signal_pending(tsk))
break;
{
struct timespec timeout;
// sleep for 7.5 mSec (giving max 133 touch/sec)
timeout = ns_to_timespec(75 * 100 * 1000);
hrtimer_nanosleep(&timeout, NULL, HRTIMER_MODE_REL,
CLOCK_MONOTONIC);
}
}
What's really strange is when I use ts_test to measure sample rate, I
see:
OMAP-Torpedo# export TSLIB_TSDEVICE=/dev/input/event0
OMAP-Torpedo# export TSLIB_CONSOLEDEVICE=none
OMAP-Torpedo# ts_test
717.804687:176161234
717.813446:176161234
717.822265:176160234
717.993255:178159234
718.002014:179158234
718.188537:180158234
719.015441:181157234
719.165100:181157234
719.360412:182157234
719.369079:182157234
719.438537:182156234
719.555725:182156234
719.564392:182156234
719.751037:180155234
719.768432:179155234
719.777099:178154234
719.946350:174150234
720.000976:175144234
720.141662:184140234
720.336975:189138234
720.490722:195137234
720.499420:198138234
720.858123:198139234
720.922912:198139234
721.126922:198139234
721.135620:198139234
721.144317:198139234
721.152984:198139234
721.161682:198139234
721.313537:198139234
721.438537:198138 0
Which shows over 3.63 seconds 33 samples, or only 9.08 samples/second,
including a max delay of .827 seconds (719.015441 - 718.188537).
But if I "ifup eth0" to bring the networking up (and nothing else is
running), I get:
OMAP-Torpedo# ifup eth0
[sleeping 5s]...net eth0: SMSC911x/921x identified at 0xc8858000, IRQ:
289
eth0: link down
eth0: link up, 100Mbps, full-duplex
udhcpc (v1.15.1) started
Sending discover...
Sending select for 192.168.3.151...
Lease of 192.168.3.151 obtained, lease time 86400
deleting routers
route: SIOCDELRT: No such process
adding dns 192.168.3.1
OMAP-Torpedo# ts_test
735.615905:263140234
735.615905:263140234
735.625152:261141234
735.634277:260141234
735.643463:260141234
735.652648:260142234
735.661865:261142234
735.671081:262141234
735.680267:263141234
735.689453:264140234
735.698669:265139234
735.707885:266139234
735.717102:267138234
735.726318:268138234
735.735534:268138234
735.744751:269137234
735.762725:269137234
735.771942:270137234
735.790344:270136234
735.799560:270136234
735.808746:270136234
735.817962:270136234
735.845611:270136234
735.910217:270136234
735.919403:270136234
735.928588:271136234
735.937866:271136234
735.947082:271136234
735.955871:271136234
735.974334:271136234
735.983551:270136234
736.001220:270136234
736.010467:270136234
736.047302:270136234
736.056488:270136234
736.074951:270137234
736.093383:269137234
736.102600:269137 0
Or 36 samples in 0.486695 seconds -> ~74 samples per second with an
average/deviation that is much more acceptable.
This is completely reproducible.
Any ideas why firing up the SMSC911x driver would cause
hrtimer_nanosleep() to be much more predictable?
--
Peter Barada
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
