Date: Wed, 17 Feb 1999 12:50:52 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Kevin Day <toasty@home.dragondata.com>, dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <Pine.BSF.3.95.990217124352.15285H-100000@current1.whistle.com> In-Reply-To: <199902172020.MAA10702@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This all reminds me of the system we used at TRW under BSD4.[23] Mach OSF1 and FreeBSD for transfering image data. We allocated fixed memory buffers for image data and modified all the devices (disks, network, compression, display) to know how to directly transfer to and from these fixed buffers. Processes controlling the whole thing mmapped the fixed buffers and could thus sample the data. but on the whole they didn't get in the way of the transfers.. it would have slowed things down too much. On Wed, 17 Feb 1999, Matthew Dillon wrote: > :I tried this, but ran into a few problems. > : > :First, I had to somehow convince the vm system to bring the pages in from > :disk, before doing the DMA, and making sure they were contiguously mapped to > :physical ram, and then forcing it not to dump them later. Never quite got > :past this hurdle. :) Is there a driver somewhere that does this? In my > :system, userland code mmap()'s data, and does memcpy's to a mmaped device > :that corresponds directly to the physical frame buffer. I wasn't really sure > :how to make sure the data ended up in a nice contiguous buffer to DMA it out > :of, without doing another copy. > > You would have to design a device to do it. Not terrible, but not > trivial either. But that wouldn't get rid of the memcpy... the only > way to get rid of the memcpy is to make the filesystem write the > data from the file directly to the frame buffer by supplying > ficticious pages directly to the underlying block device. > > This would be a difficult hack to do in the filesystem, but you > might be able to do it talking to a raw device and not have to > hack the system at all. > > For example, create a partition on the hard disk that you intend > to access directly. i.e. no filesystem. > > If you mmap() the frame buffer, and issue a read() on the raw > device interface for the partition with a pointer into the > mmap()'d frame buffer, I *believe* this will result in > direct DISK->PCI DMA. I'm not positive, though. Yes this is exactly correct. The pages in your address space that represent the frame buffer will be used as the DMA addresses for the transfer. > > :> the SCSI bus and have it master the data directly from the > :> drives without host intervention ). This is a rather more > :> complex solution. > : > :We're using IDE too. :) > > It is a DMA capable IDE controller, right? If not, you are > S.O.L. As Matt says, a DMA IDE controller (that we support) will also transfer directly to the frame buffer if you mmap it. It uses approximatly the same code to work out the DMA addresses. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990217124352.15285H-100000>