From owner-freebsd-multimedia Sat Aug 30 10:43:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26191 for multimedia-outgoing; Sat, 30 Aug 1997 10:43:14 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA26184; Sat, 30 Aug 1997 10:43:09 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA03050; Sat, 30 Aug 1997 18:29:51 +0200 From: Luigi Rizzo Message-Id: <199708301629.SAA03050@labinfo.iet.unipi.it> Subject: IRQ problem (was Re: IRQ timing) To: dec@phoenix.its.rpi.edu (David E. Cross) Date: Sat, 30 Aug 1997 18:29:51 +0200 (MET DST) Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG In-Reply-To: from "David E. Cross" at Aug 30, 97 11:22:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I just sent a message to the OSS people, and they mentioned that some of > the problem I am experiencing is a result of some tight IRQ timing that > the FreeBSD kernel has (ie, it takes too long to transfer the data). I would you care to mention what problem are you experiencing ? Curiously I have a related question, so hope people would excluse the crosspost.. I have a problem of missing interrupts with a device, but am not sure if it is a broken device, an intrinsic problem with ISA interrupts, a problem with my 82371 chipset, or what. So some help would be appreciated. Briefly, the question is: is there any feedback on the ISA bus to signal a device WITH MULTIPLE INTERNAL SOURCES that an interrupt has been served by the CPU and it can lower the interrupt line ? The device I have problems with is the OPTI931, a full duplex audio chip. It has multiple internal interrupt sources, all routed to a single ISA interrupt line. It is possible to acknowledge separately each interrupt source. My interrupt driver loops on the interrupt status register and returns when there are no more active sources, acking the various sources as they are served. Since the cause for interrupts is the completion of a dma transfer, I have an alternate way to check that the conditions for an interrupt have occurred. Very frequently, when both DMA channels are active, I find that the DMA transfer is complete, yet I don't get the interrupt I expect (luckily in most cases I can recover because at the same time I get an interrupt on the other channel, can test the ISA DMA count, and do the appropriate actions). At first I thought it was a problem with the board, but am not that sure now. Apparently the only feedback I can give to the device is through the individual interrupt acknowledge bits in the device. But when multiple internal sources are active, and one of them is not acked by the interrupt service routine (e.g. because it goes high after I read the status register) then the IRQ line should stay high. If ISA interrupts are really edge triggered, any interrupt not served when it occurs would be irremediably lost, or what ? Evidently things must be different from what I think because other similar devices (e.g. the CS4236) seem to work fine, but where is the trick ? Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________