Date: Wed, 22 Oct 1997 14:48:08 -0700 (PDT) From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> To: freebsd-hackers@FreeBSD.ORG Subject: using acquire_timer0() in drivers Message-ID: <Pine.BSF.3.96.971022141721.744A-100000@trojanhorse.ml.org> In-Reply-To: <199710222021.WAA11525@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Am I correct to gather that on the 8253 timer chip.
clock 0 is freely available
clock 1 is used for scheduling interrupt (i.e. HZ)
clock 2 is connected to the speaker
If so I think there is a better way to utilize the clock 0 resource.
I was thinking that using acquire_timer0() is bad for any drivers that may
need it (such as data acquisition drivers). I wish to use it to clock
input from an analog board at around 1024hz, I am already certain that
this is perfectly doable. However, I am concerned that it might be a bad
architectural idea to acquire_timer0() for long periods of time in a
driver (or at all for that matter), since according to the clock.c code it
looks to me like only one interrupt routine can be acquired at a time.
But suppose I have 2 or three drivers needing polling service like this it
might be a good Idea to reimplement the 8253(8254 i think)
acquire_timer0() code so that more than one driver routine can be linked
to the interrupt routine. So polling hardware like this which does (and
will continue to exist) can get serviced properly. What I propose is that
multiple acquisitions are allowed which will make it easy to
check which routines will be run at that interrupt. The interrupt can be
maintained at the highest frequency requested.
like this: Routine Freq Reset val Phase val
1 256 4 1
2 512 2 0
3 1024 1 0
We could limit the counters to like 8 or more.
When a counter = 0 call the routine and set back to original counter
value. I would be interested in any analysis of the overhead here, we are
hopefully talking about small routines anyhow.
The phase value for instance would be a snapshot of the couter values at
one one point which would be the insertion point for dynamically added
routines. That way with 3 routines as above you optimize your distribution
of Timer Service Routines getting called. This would look like (in this
case). So with phase only 2 routines are getting executed on any one
interrupt.
2 1 2 2 1 2
3 3 3 3 3 3 3 3
Some of you may scream overhead and that your going to miss interrupts,
but if you had three boards on 3 different interrupts as above (their own
clocks presumably) I don't think it is going to look any better in terms
of overhead and chances of an interrupt getting missed (which is probably
the main concern).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971022141721.744A-100000>