Date: Wed, 13 Feb 2002 01:46:04 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: mike varga <mike.varga@cavium.com> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>, freebsd-arch@freebsd.org Subject: Re: bus_dma_load_uio() function Message-ID: <3C6A35DC.F03DC26A@mindspring.com> References: <00d401c1b428$e4929df0$b210a8c0@netscreen5> <20020212172445.A85182@troutmask.apl.washington.edu> <000701c1b42e$7835eda0$b210a8c0@netscreen5>
next in thread | previous in thread | raw e-mail | index | archive | help
mike varga wrote: > My question essentially > boils down to,"How do you > map and lock user pages (buffers) > for use in a driver that wants > to do a DMA directly > from/to them. > > It removes unnecessary > copies. Hi, Mike. Normally, this type of copy elimination is done, not by taking user pages and making them available to the driver, but by taking driver pages, and making them available to the user space program. There are a lot of ways to do this, but it normally depends on how you intend to do the accesses. If your driver has a device node, the simplest way is to allocate a memory region when the driver is instanced, and then use mmap() on the device itself to map the pages into the user space program. This has the usually desirable side effect of making the memory access controls equal to the driver enforced access controls on the open. There are a number of drivers, such as the bktr and other capture cards, as well as the linear frame buffer devices. See also /dev/agpgart. Another alternative is to use System V shared memory, which is implemented as a KVA space allocation which gets mapped into the user process address space as a result of the attach. This memory is wired down, and it also will not move out from under you while you are using it. You can use this approach by making a single call to the driver to identify the shared memory segment to it, and then use relative addressing in both user and kernel space to end up with invariant pointers relative to the base address (which will be different in kernel and user space). If you are building a special purpose embedded system, rather than a just a driver for use in a general purpose system, then there are other ways to make the code faster that involve giving up some of the guarantees that you normally get from a protected mode OS. My personal suggestion, given what I know of your intended application, would be to use the first approach. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C6A35DC.F03DC26A>