From owner-freebsd-multimedia  Mon Aug 18 18:41:26 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA01063
          for multimedia-outgoing; Mon, 18 Aug 1997 18:41:26 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA01034;
          Mon, 18 Aug 1997 18:41:18 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
	by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id SAA06127;
	Mon, 18 Aug 1997 18:41:02 -0700 (PDT)
Message-Id: <199708190141.SAA06127@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Michael Smith <msmith@atrad.adelaide.edu.au>
cc: luigi@labinfo.iet.unipi.it, smp@csn.net, multimedia@FreeBSD.ORG,
        hackers@FreeBSD.ORG
Subject: Re: isa_dmastatus 
In-reply-to: Your message of "Tue, 19 Aug 1997 10:57:59 +0930."
             <199708190127.KAA15154@genesis.atrad.adelaide.edu.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 18 Aug 1997 18:41:02 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>From The Desk Of Michael Smith :
> Amancio Hasty stands accused of saying:
> > 
> > When we get a dma interrupt from the device, if I call isa_dmadone to
> > clear the busy flag it does not mean that I am  done using the
> > buffer and I can't call isa_dmastart because the dma processes
> > is still active. 
> 
> OK.
> 
> > So if we wish to support auto dma and use the existing dma interface
> > in isa.c then I suggest that we add a simple check in the isa 
> > dma routine to bypass the busy flag check when we are using 
> > auto dma. What does this mean in an SMP environment I have no 
> > idea because when a driver requests auto dma in essence he is 
> > requesting exclusive access of the dma channel.
> 
> It sounds like you're just adding hairs to an existing wart.  This may
> well be the most expedient way to go in the short term though.
> 
> > Please let me know if my explanation is not clear and if there
> > are any intentions to support auto dma in the isa.c / *dma* routines.
> 
> It sounds to me as though there is a need for a couple of different
> levels of access to the DMA support.  At the bottom, we need some
> primitives :
> 
> isa_dmaacquire		- obtain a DMA channel
> isa_dmarelease		- release a DMA channel
> isa_dmastart		- start a DMA transfer
> isa_dmastop		- stop a DMA transfer
> isa_dmastatus		- query DMA status
> 
> which provide hands-on access to the DMA hardware.  Above these, it seems
> that DMA consumers would benefit from 
> 
> isa_dmatransact		- start one-shot DMA transaction
> isa_dmatransstatus	- query/complete DMA transaction
> 
> where the first would take assorted parameters (address, port, direction,
> channel etc.), and then use the primitives to obtain the channel and start
> the transaction, and the second would allow for polling the status of a
> DMA transaction (instead of sleeping for it to finish, etg.).
> 
> For auto-DMA operation, you would acquire the DMA channel, and then
> use the other isa_dma* functions until done, at which point you would
> release the channel again.  It seems to me that this is the critical
> point; the current mixing of the acquire/release with the start/done
> functionality is breaking your use of auto DMA, correct?

This is correct. there is no mechanism for me to use auto dma with
isa_dmadone, isa_dmastatus or isa_dmastop .

I can only call isa_dmadone when the driver is done using the dma
channel. However, I do need to use isa_dmastatus and possibly 
isa_dmastop  while I am doing auto dma.

	Amancio