API change for bus_dma

[Scott Long]

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:


bus_dmamap_load();
	driver_callback()
	{
		set up S/G list;
		bus_dmamap_sync(PREWRITE);
		tell hardware that DMA is ready;
	}

The callback gets called immediately as long as conditions are met, as
we have discuss prior.

Then:

driver_intr()
{
	see that hardware has DMA'd data to us;
	bus_dmamap_sync(POSTREAD);
	bus_dmamap_unload();
}

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

Scott

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