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

[Uhler, Mike]

I'll have someone from our Linux development team contact you directly.

> Date: Fri, 4 Aug 2006 13:00:43 +0200
> From: "Paolo Giarrusso" <p.giarrusso at gmail.com>
> Subject: [Celinux-dev] MIPS: a volunteer for HRT implementation
> To: celinux-dev at tree.celinuxforum.org, linux-mips at vger.kernel.org,
> 	johnstul at us.ibm.com
> Cc: mingo at redhat.com, tglx at tglx.de
> Message-ID:
> 	<a4d0c86c0608040400w4acecdcaw39e74d1e1631a0d4 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> 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).

/gmu
---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler AT mips.com
1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
Mountain View, CA 94043