[linuxsh-dev] Re: Running TMU1

[Masahiro A. <m-...@aa...>]

Hi Jeremy,

I've attached our code in RTLinux-sh where manipulates TMU0 and 1. I use
TMU1 as free running timer, same as your code does, but additionally we
check if TMU1 has wrapped (0->0xffffffff) periodically.

You may notice by looking at our code that we implemented mechanism to
get time since machine boot, using TMU1. ("_shtimer_gettime()" returns
nanoseconds since machine boot)

I think your code require RTLinux-sh some adjustments, but it won't
break the mechanism. Adjustment shouldn't be much. I don't say your code
"conflicts" with ours, but rather "require tweaks". (I'm afraid if I'm
not giving you the right words to express my thinking).

Attached rtl_time.c forms part of kernel module, so your code uses TMU1
earlier than rtl_time.c do. I don't think you need to check the usage of
the timer, but our code do.

If you have time, please take a look at our code, and tell me your
impression on how those two codes can coexist together.

(As a side note, RTLinux-sh takeover TMU0 also. It is no longer simple
periodic timer, but reprogrammed every time the interrupt occur, to wake
up the real-time task.)

On Thu, 28 Feb 2002 14:05:50 -0800
Jeremy Siegel <js...@mv...> wrote:

> I'd like to include the following timer.c patch to set up TMU1 as a
> free-running timer for timestamp or instrumentation purposes (or maybe a
> future port of hi-res timers to the SH kernel).  This'll be in our
> distribution under ifdefs specific to features that use it; in this patch
> it's just under CONFIG_START_TMU1 since that seemed more general (could be
> turned on by features needing it).  [I've also attached a modified
> preem_latency.h file, just as an example of how it'd be used; it seems
> simpler than what's currently in the preempt_stats patch for SH.]
> 
> To Masahiro Abe: is this usage similar enough to your usage in RT-Linux
> that it doesn't conflict?  Would it help to
> put the startup code under a conditional check on whether the timer has
> already been activated?
> 
> Last month I sent out a query about this, and one question I had was that
> even TMU0 seems to be running faster
> than the specs allow, and I've been running both TMU1 and TMU0 at the same
> speed w/o apparent problems yet...
> again, I'm assuming that aspect of the spec is incorrect (irrelvant to
> SH3/SH4) but if that's a bad assumption
> please let me know!
> 
> Any objections to the timer.c change?
> 
> Thanks,
>   --Jeremy Siegel

=================================
Masahiro ABE, A&D Co., Ltd. Japan