API change for bus_dma
scott_long at btc.adaptec.com
Fri Jun 27 14:32:30 PDT 2003
Andrew Gallatin wrote:
> 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).
The bus_dmamap_sync() isn't done from a separate system call. The flow
set up S/G list;
tell hardware that DMA is ready;
The callback gets called immediately as long as conditions are met, as
we have discuss prior.
see that hardware has DMA'd data to us;
As I understand it, it is possible to set the pycho bridge to use
a coherent address range, but FreeBSD doesn't take advantage of that
> > 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..
More information about the freebsd-arch