[Celinux-dev] MIPS: a volunteer for HRT implementation

[Paolo Giarrusso]

I'm a Linux developer having experience with UserModeLinux and some
core work (remap_file_pages extensions), now working for Tvblob S.r.L.
which needs to get high timer resolution (at least up to 1ms but
possibly higher) on a certain MIPS platform.

After looking at the current code I could understand that MIPS has a
in-house HRT support with hardware time sources, which already gets
something to the platform (namely, with HZ=100 I can sleep for just
2ms), and that what I need to do is to improve the subsystem (down to
1ms) and to possibly merge it with the generic timeofday code by John
Stultz (not sure whether my employer needs it but I'll probably try
doing this too), which is _not_ yet planned for the HRT patch.

I volunteer to start this work (it will be easier to refactor the code
than to understand its interactions with hw as I have no docs on the
latter), but I need some interactions and recommendations before
starting (I don't ask to be taught about generic timeofday, I haven't
yet started reading it but I don't expect it to be too difficult), and
I'd be interested in ideas from MIPS people.

=====
Some details on the particular situation follow.

I'm developing on a board derived from the TOSHIBA_RBTX4938 one (that
config option is used) with a 300MHz processor and "Using 150.000 MHz
high precision timer." in the boot logs; this board _does_ use (for
what I could understand from comments, unfortunately I'm a novice
about MIPS architecture) CPU timing and the only existing attempt at
HRT for this platform (from 2 years ago):

http://marc.theaimsgroup.com/?l=linux-mips&m=108303124723562&w=2

is based on CPU timer, so it seems the HRT source exists.

Our currently Linux release is 2.6.15.3 (but we _do_ track, at
intervals, later releases, so I'll do this work on CVS head).

As I said, I can sleep (with nanosleep /
clock_nanosleep(CLOCK_REALTIME / CLOCK_MONOTONIC)) for just 2ms; with
timer_create I can reach lower times, but this result is suspect since
librt forks a new thread which uses clock_gettime; additionally,
*nanosleep is also inaccurate since I sleeps usually for
ROUND_UP(1msec, asked_time) - 1microsec, and sometimes for more (have
yet to diagnose which is the load causing this, but there is a driver
which is probably causing high latencies which I'm fixing).

On a Ubuntu 2.6.15 i386 kernel I also get inaccuracies however, so I
don't know what is at fault (if hw inaccuracies or what else).