Date: Sun, 18 Mar 2001 15:23:40 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@harmony.village.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, Matthew Jacob <mjacob@feral.com>, arch@FreeBSD.ORG Subject: Re: man pages Message-ID: <Pine.BSF.4.21.0103181501580.25882-100000@besplex.bde.org> In-Reply-To: <200103171803.f2HI3Q945895@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Mar 2001, Warner Losh wrote: > I have a device that I've written a driver for. The device has a data > pump <-> FIFO <-> DMA ENGINE on it. So far fairly standard. However, > I get an interrupt when the first byte hits the FIFO. I then have a > very small window to program the DMA ENGINE before the FIFO fills up. > When I'm in my interrupt handler, I want to disable *ALL* interrupts > so that I can do the complicated handsprings necessary to turn on the > DMA ENGINE as fast as possible without *ANY* interruption. If I miss > my window, I either miss data, or due to a hardware bug, I hang the > PCI bus. This is an embedded system, so I don't have to worry about > the mouse being responsive :-) > > I tried using splhigh(), but found that intr_disable() and > intr_enable() in the old code proved to work more reliably in > practice than splhigh(). This is a good bad example. It's too late to disable interrupts in the interrupt handler, because the handler might not be called until long after the hardware asserts an interrupt (a delay of 20 msec is not impossible, especially in -current). > No, I don't know why. Just wanted to show > an example that needed it, not for syncronization, but to assume total > control of the CPU and to make everyone else wait while I do my > semi-time critical hardware frobbing. You should know better :-). A device where you start i/o in a non-interrupt-driven way and have to continue the i/o within a certain time would give a better example. In your example, if missing the window would be fatal, to work under FreeBSD you need to use a fast interrupt handler under FreeBSD-4.x or better (fast interrupt handlers are broken in -current), and arrange for all other fast interrupt handlers combined to not break the window (this probably involves not having any other active ones). If missing the windows wouldn't be fatal, then just use a normal interrupt handler and recover from errors. Fast interrupt handlers are too hard to use to use routinely. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103181501580.25882-100000>