Date: Mon, 21 Jul 1997 17:12:58 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: msmith@atrad.adelaide.edu.au, luigi@iet.unipi.it, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver Message-ID: <199707210742.RAA22211@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707210422.GAA20549@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 06:22:54 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo stands accused of saying: > > certainly I am not inventing anything :) the problem is that, while > writing, one never knows if sufficient info are given to let > everybody understand all the details, so better give more than be too > criptic. Oh, understood entirely. Likewise my reply 8) > > describe a triple-buffered approach which is more suited to the high > > latency that is often encountered in multiprocessing situations. > > in fact I don't agree that multiprocessors should necessarily have high > latency, and if a critical interrupt (e.g. the one restarting a DMA > transfer) is delayed too much, we are in trouble and get holes in the > i/o no matter what we do... Oops, I meant "multiprogramming", sorry. The big issue with something like this is the possibility that the task responsible for writing audio data may be a long way down the list of runnables. > whoops... I did not think explicitly to autoinit mode, actually I > suspect that some changes are necessary to my scheme to support > automode. I'll look into them, thanks for the suggestion. Sure. Note that autoinit is only suitable for circular buffers. > > If not, there's no apparent need for such a complex approach; you can > > just use three separate buffers each sized suitably to cover the > > latency involved in filling the next. > > not sure. the problem which worries me more is the latency from the > time the write routine is invoked with a large block, and the time the > next buffer is completely filled up by the uiomove. Now you are right > that one could play games such as first mark the buffer as full, with > the appropriate length, and then start the uiomove, in the assumption > that uiomove will finish first anyways (if not interrupted...) ... or you can chunk any copy in in reasonable slabs, and update the DMA controller TC after each slab. ie. for any given write, divide the region being written into page-sized slabs so that you have at most one VM hit per uiomove and then update the DMA after each one. Note that the endleess buffer approach I described specifically tries to avoid the delay problem by trying to keep the buffer as full as possible at all times. It is only in the case where the buffer is almost empty because the writer has lagged that you have to worry about how long a copyin takes. You might also want to check and see if the copyin used by uiomove actually faults the pages first and then copies, or whether it only faults on demand. In this case, doing a full-sized move would actually be faster. Also, consider that the move overhead is really nothing more than another latency item; ie. it's quantitive not qualatative. > yes a lot. An interesting alternative, I just have to see how complex > (and reliable) is to read from the DMA registers on the fly, and how to > do this with the MSS which has some kind of dma support on board. Indeedy. As Amancio said, my suggestion's nothing new either; streaming DMA is probably about as old as double-buffered DMA 8) The former is good for DMA controllers that loop, the latter for those that support buffer chaining. The 8357 doesn't do buffer chaining, so streaming is the way to go. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707210742.RAA22211>