Date: Mon, 18 Aug 1997 00:23:44 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: smp@csn.net (Steve Passe), multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: isa_dmastatus Message-ID: <199708180723.AAA00439@rah.star-gate.com> In-Reply-To: Your message of "Mon, 18 Aug 1997 04:34:18 %2B0200." <199708180234.EAA09705@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Lets see, If a driver uses auto dma, it generally calls isa_dmastart once. isa_dmastart sets the busy flag: from isa_dmastart: dma_busy |= (1 << chan); 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. 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. 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. Thank you, Amancio >From The Desk Of Luigi Rizzo : > 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 priva te > > 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/ > _____________________________|______________________________________ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708180723.AAA00439>