From owner-freebsd-multimedia Sun Aug 17 20:42:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA17881 for multimedia-outgoing; Sun, 17 Aug 1997 20:42:27 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA17861; Sun, 17 Aug 1997 20:42:13 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id EAA09705; Mon, 18 Aug 1997 04:34:19 +0200 From: Luigi Rizzo Message-Id: <199708180234.EAA09705@labinfo.iet.unipi.it> Subject: isa_dmastatus To: smp@csn.net (Steve Passe), luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 18 Aug 1997 04:34:18 +0200 (MET DST) Cc: multimedia@freebsd.org, hackers@freebsd.org In-Reply-To: <199708180245.UAA09140@Ilsa.StevesCafe.com> from "Steve Passe" at Aug 17, 97 08:44:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Feeling much involved with this issue... I fully second Steve's opinion and with the same motivations: > people realize that the days of different pieces of code accessing common > hardware are over. As SMP is brought into more and more of the kernel this > becomes unacceptable. Areas such as the DMA hardware will have to be > encapsolated into "critical regions". No one will be allowed to have private > code to access these sorts of things, not even for short testing periods. this said, and since I cannot track very easily -current and amancio's work, I cannot say from here what in the committed isa_dmastatus conflicts with guxpnpXX. I saw once a comment related to the voxware code not following the proper sequence of calls to the dma functions thus having problems with checks for dma_inuse and dma_busy. Having been there I have the feeling that it would be a pain in the neck to make the voxware code behave properly, and the easiest workaround is to disable such checks. My code does not have these problems but I had the advantage of starting from scratch, so I decided to put the checks in as an additional safety mechanism, and since they did not harm for me. Pragmatically, I suggest that at least temporarily the isa_dmastatus be made to work for guspnpXX. After all the sound driver (guspnpXX, or mine) is the only part of the system using it at the moment, I don't think Amancio is asking for changes to the interface of the function, and disabling some checks does not change the function's behaviour when invoked in the correct way. Cheers 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/ _____________________________|______________________________________