From owner-freebsd-arch Sat Mar 17 10: 3:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C2FA737B718; Sat, 17 Mar 2001 10:03:26 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2HI3Q945895; Sat, 17 Mar 2001 11:03:26 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103171803.f2HI3Q945895@harmony.village.org> To: John Baldwin Subject: Re: man pages Cc: Matthew Jacob , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Mar 2001 14:31:18 PST." References: Date: Sat, 17 Mar 2001 11:03:26 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : Actually, the cy(4) driver uses explicit enable_intr()'s as does : some of the 386 fpu code, and the pre-spinlock variant of the sio(4) : driver also used explicit enable_intr(). I'm not a big fan out of : it myself, but some things do need it. The manpages look good : though I'd be inclined personally to collapse them into a single : intr.9 manpage. Also, the actual functions are declared in : , and I didn't write these, I am just tweaking : them. :) 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(). 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. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message