Date: Fri, 27 Jun 2003 17:21:58 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Scott Long <scott_long@btc.adaptec.com> Cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma Message-ID: <16124.46454.595892.860118@grasshopper.cs.duke.edu> In-Reply-To: <3EFCB178.9030207@btc.adaptec.com> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com> <16124.45051.919899.414795@grasshopper.cs.duke.edu> <3EFCB178.9030207@btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long writes: > > The approach taken with busdma is that you don't assume coherency. The Unfortunately, in our application we must assume coherency in some situations. We have kernel memory mmap'ed into user space for zero-copy io of small messages. Doing a system call to force the dma sync would add unacceptable latency. (we're talking sub 10us latencies here, without syscalls). > idea is to call bus_dmamap_sync() with the appropriate opcode to signal > pre|post read|write, and have that take care of the platform-specific > magic. On i386 when bouncing does not occur, these are NOOP, otherwise > the actual bouncing bcopy() takes place. On sparc64 it looks like it > does the appropriate IOMMU and memory barrier magic. Sure, but we're a 64-bit card and never bounce. If we've bounced, we might as well take the ball and go home, so to speak ;) Anyway, this has saved me a lot of time. Its now apparent that there's no point in our using busdma, since the main gain would have been to enable us to run on sparc64. Directly using physical addresses works great everywhere else.. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16124.46454.595892.860118>