Reading Sun 3 timer register within Kernel device driver

Tom Perrine x426 tots!heinlein!tep at suntan.west.sun.com
Sun Dec 3 04:34:52 AEST 1989


In sun-spots V8#207, Andrew Harker <tots!nosc!relay.eu.net!larch!anh
writes:

> I have a problem relating to SUN OS3.5 kernel device drivers. I want to
> measure the performance of the driver by calling a routine at certain
> points in the driver which records a timer value in a buffer somewhere.
> Outside the kernel, the obvious answer is to use gettimeofday(), but this
> is no good inside the device driver.
>
> Is there a way of accessing the SUN's timer register from within the
> kernel? Is there an easier way?

I needed to do almost the exact same thing last year. I was working on a
driver and needed to do some performance measurement, from a user program
written in Ada. The easiest way to do this was to write an ioctl in the
driver that returned the data I wanted with a timestamp of when the data
snapshot was taken. The easiest place to find a timestamp was go straight
to the source so I read the clock chip.

This works on a Sun 3/260 under SunOS 3.5 (and 3.5.2):

#include "../sun3/clock.h"
...
/* time stamp structure - derived from struct intersil7170 in clock.h
 * The important difference is that all fields are longword-aligned longwords.
 * This makes interfacing to Ada easier (via representation clauses)
 */
struct rts_timestamp {
	long	tms_hsec;	/* counter - hundredths of seconds 0-99 */
	long	tms_hour;	/* counter - hours 0-23 (24hr) 1-12 (12hr) */
	long	tms_min;	/* counter - minutes 0-59 */
	long	tms_sec;	/* counter - seconds 0-59 */
	long	tms_mon;	/* counter - month 1-12 */
	long	tms_day;	/* counter - day 1-31 */
	long	tms_year;	/* counter - year 0-99 */
	long	tms_weekday;	/* counter - week day 0-6 */
      };
...
/* set a pointer to the clock chip onboard registers */
struct intersil7170 *clock = CLKADDR;
...
static
get_timestamp(now)
struct rts_timestamp *now;
{
	/* EXAMINE AND UNDERSTAND everthing in clock.h before modifying this
	 * procedure!! Especially the part about latching via clk_hsec!
	 */
	now->tms_hsec = (long)clock->clk_hsec;
	now->tms_hour = (long)clock->clk_hour;
	now->tms_min = (long)clock->clk_min;
	now->tms_sec = (long)clock->clk_sec;
	now->tms_mon = (long)clock->clk_mon;
	now->tms_day = (long)clock->clk_day;
	now->tms_year = (long)clock->clk_year;
	now->tms_weekday = (long)clock->clk_weekday;

} ...  The note about latching via clk_hsec refers to the fact that
reading clk_hsec latches the time in all the other bytes so you get a
consistent time. To see any changes in the other fields, you must read
clk_hsec again. READ THE clock.h COMMENTS and make sure you understand
what is going on or you may get inconsistent timestamps (or if you were to
loop waiting for a fields to change, you could loop forever at elevated
priority).

Beware of comparing timestamps from this method to those returned by any
other method, including gettimeofday(). You will be reading the clock chip
registers, which are munged to produce the "system date"; there are
offsets, corrections, adjustmants and other things going on.

Let me know how this works out for you.

Tom Perrine (tep)
Logicon (Tactical and Training Systems Division) San Diego CA (619) 455-1330
Internet: tots!tep at LOGICON.ARPA		GENIE: T.PERRINE
UUCP:{nosc,ucsd}!snoopy!tots!tep -or- nosc!hamachi!tots!tep -or- sun!suntan!tots!tep



More information about the Comp.sys.sun mailing list