From owner-freebsd-new-bus Tue Jun 27 0:14:47 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id BB8A137B604 for ; Tue, 27 Jun 2000 00:14:43 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 136pZx-0003sy-0K; Tue, 27 Jun 2000 07:14:42 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA09246; Tue, 27 Jun 2000 08:14:35 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 27 Jun 2000 08:18:23 +0100 (BST) From: Doug Rabson To: Warner Losh Cc: new-bus@freebsd.org Subject: Re: Why can't I have.. In-Reply-To: <200006270619.AAA31901@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jun 2000, Warner Losh wrote: > In message Doug Rabson writes: > : On Mon, 26 Jun 2000, Warner Losh wrote: > : > : > > : > ... a INTR_TYPE_FAST | INTR_TYPE_MISC? > : > > : > It gives me: > : > panic("still using grody create_intr interface"); > : > > : > What's the deal? It is easy enough to fix the problem, but I was > : > wondering why the code is still there... > : > > : > This is, admittedly, in -stable. > : > : Hmm. I thought Peter had fixed that ages ago. If you can generate patches, > : I would appreciate it. > > Here's what I have. Tell me how it is wrong and I'll fix it :-). > > Fast interrupts make a *HUGE* difference for some hardware that I'm > writing a driver for hire fore. This hardware generates an interrupt > on the first write to a FIFO. In the ISR the you set the DMA > parameters of the card, and you have only until the FIFO fills up to > set the DMA. Once the DMA is set, the fifo drains (as well as data > that is fed through it) and your hunk of data is complete. The normal > interrupts had too much of a latency to make them work. Minor rework > of the driver for fast interrupts seems to have solved the latency > problem at the cost that each of these cards must have their own > interrupt. Major rework of the driver could make it possible for > interrupt sharing with other cards of this type with one ISR handling > all of them. > > Anyway, enough about my oddball hardware. Here's the patch. This looks correct for your purposes but I think we should be able to specify more than one interrupt type in the mask (e.g CAM|NET). Its not worth fixing that though since spls will be disappearing soon. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message