From owner-freebsd-hackers Wed Oct 22 14:48:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA01463 for hackers-outgoing; Wed, 22 Oct 1997 14:48:57 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA01448 for ; Wed, 22 Oct 1997 14:48:51 -0700 (PDT) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id OAA00811 for ; Wed, 22 Oct 1997 14:48:08 -0700 (PDT) Date: Wed, 22 Oct 1997 14:48:08 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-hackers@FreeBSD.ORG Subject: using acquire_timer0() in drivers In-Reply-To: <199710222021.WAA11525@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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).