Date: Mon, 18 Aug 1997 18:41:02 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> 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 Message-ID: <199708190141.SAA06127@rah.star-gate.com> In-Reply-To: Your message of "Tue, 19 Aug 1997 10:57:59 %2B0930." <199708190127.KAA15154@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708190141.SAA06127>