Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Delay with no real time clock
Message-ID: <9014@mimsy.UUCP>
Date: Fri, 16-Oct-87 10:14:07 EDT
Article-I.D.: mimsy.9014
Posted: Fri Oct 16 10:14:07 1987
Date-Received: Sun, 18-Oct-87 00:19:26 EDT
References: <2414@masscomp.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 52
Xref: mnetor comp.unix.questions:4546 comp.unix.wizards:4950

In article <2414@masscomp.UUCP> jeffrey@masscomp.UUCP (Jeff Jones) writes:
>I am working with a driver that must wait ... after issuing a command
>before assuming that a device is not present.  This must happend during
>device initialization time. ... There are no real time clock interrupts
>during the device initialization phase of our kernel.
>	How do you determine how much time has expired
>	when you have no real time clock interrupt?

My UDA50 driver has the same problem.  On Vaxen, there is a CPU
register called TODR (Time Of Day Register) that is incremented
once every millisecond, so to wait for one second, one could use

	register int timo = mfpr(TODR) + 1000;

	while ((device->status & READY) == 0)
		if (mfpr(TODR) >= timo)
			return (0);	/* device never went ready */

Alas, not *all* Vaxen have a TODR---in particular, the Microvax
series and (I believe) the 8800.  For now, I changed mfpr(TODR)
to a call to todr():

	register int timo = todr() + 1000;

	while ((device->status & READY) == 0)
		if (todr() >= timo)
			return (0);

The routine todr() then reads (approximately)

	todr()
	{
		switch (cpu) {

		case VAX_8600:
		case VAX_8200:
		case VAX_780:
		case VAX_750:
		case VAX_730:
			return (mfpr(TODR));

		case VAX_630:
			/* hack */
			{ static int t; DELAY(10000); return (++t); }
	}

It is sort of a hack, but it works.  Since it is used only at boot
time, it need not be very accurate---and it is better than having
the machine hang if a device gets stuck.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris