Add high resolution timer support to kernel

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile the following program:
#include <time.h>
int main() {

    struct timespec res;
    int rv;

    rv = clock_getres(CLOCK_MONOTONIC, &res);
    if (!rv)
        printf("CLOCK_MONOTONIC has resolution %ld ns\n", res.tv_nsec);
}
2. Observe the printout:
CLOCK_MONOTONIC has resolution 9999609 ns
i.e. timer resolution is 10ms

What is the expected output? What do you see instead?
According to 
http://bec-systems.com/site/175/how-to-implement-realtime-periodic-tasks-in-linu
x-applications
if high resolution timers were implemented, the clock resolution would be 
reported as 1 ns.
The kernel config entry for high resolution timers is CONFIG_HIGH_RES_TIMERS

What version of the product are you using? On what operating system?
2.6.29.6 FW 4.0

Please provide any additional information below.
Without high resolution timers, nanosleep sleeps increments of the kernel clock 
tick (10ms). This makes robot timing very coarse-grained. It should be possible 
to to much better with high-resolution timers (100ns). It is desirable to let 
nanosleep or usleep sleep the application for a while so that other tasks can 
continue, and so that apps don't have to do a busy-wait (which could last 
seconds), potentially disturbing the kernel & networking.

Original issue reported on code.google.com by paul.bou...@gmail.com on 29 Nov 2011 at 9:22

[GoogleCodeExporter]

Original comment by rich.m.l...@gmail.com on 13 Dec 2011 at 10:12

• Changed state: Accepted

[GoogleCodeExporter]

I just added microsecond, millisecond, and second resolution busy-wait timers, 
timeouts, and timestamps via timer.h and timer.cxx.  (Committed revision 1361.)

It would still be nice to have high-resolution timers that don't spin, as Paul 
requests.

Original comment by d...@reeceweb.com on 26 Feb 2012 at 4:40