Date: Thu, 10 Oct 1996 08:40:21 -0500 (CDT) From: Mark Tinguely <tinguely@plains.nodak.edu> To: jkh@time.cdrom.com, luigi@labinfo.iet.unipi.it Cc: CSP1DWD@MVS.OAC.UCLA.EDU, hasty@rah.star-gate.com, multimedia@FreeBSD.org Subject: Re: When is the new sound code being committed? Message-ID: <199610101340.IAA04739@plains.nodak.edu>
next in thread | raw e-mail | index | archive | help
> > Because Hannu would like to allocate some 64K of contiguous DMA space > > (if memory serves me correctly - it might be only 16K) and FreeBSD > > doesn't allow that once the system is up to the stage where an LKM > > would be loaded. We've talked to John Dyson about it and he's > > promised to try and work something out, though the problem is also not > > entirely trivial to fix, apparently. > > a similar problem (get a large contiguous chunk of RAM) exists in the > meteor driver. There, allocation is done at probe time. Of course > this does not help if you want to build the driver as an LKM, but > perhaps one could use a simple hack while a better solution appears: (agreeing with above points, I am just a little defensive on this point), the meteor driver needs a large contigous chunk of memory for the frame and boot time is the only time it will succeed. The cards do not give you the option of DMA-ing smaller chunks (well the odd/even scan lines could be seperated into different buffers). We tried to be a good citzen and release the buffer and once released I could never get that size chunk of contigous memory back. rewriting the VM code that goes to force contigous memory chunks is a tall request, but if done, our drivers will be more than pleased to release our buffers when we no longer need them. and you aint seen nothing yet, just wait until you see what an ATM driver allocates for initial memory! --mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610101340.IAA04739>