Date: Mon, 21 Jul 1997 06:22:54 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: luigi@iet.unipi.it, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver Message-ID: <199707210422.GAA20549@labinfo.iet.unipi.it> In-Reply-To: <199707210158.LAA20128@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 11:28:25 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Luigi Rizzo stands accused of saying: > > > > - with two DMA buffers, we can refill one buffer while the other one ... > This is the traditional double-buffered approach. You go on to 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. > 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... > > one free for refills. > > > > dp,dl rp,rl fp,fl > > +-------+-------------+---------------+------+ > > | free | used by dma | ready for use | free | > > +-------+-------------+---------------+------+ > > > > Both the "ready" and "free" areas can wrap around the end of the > > buffer. > > I presume that the plan here is that the host DMA controller loops > endlessly over this buffer in autoinit mode? 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. > 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...) > Another alternative would be to simply use an endlessly-recirculating > DMA buffer of appropriate size thus : ... > I'm not sure if this actually helps you... 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. 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?199707210422.GAA20549>