API change for bus_dma

Scott Long 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
is this:

		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..
> Drew

More information about the freebsd-arch mailing list