Date: Fri, 27 Jun 2003 15:29:09 -0600 From: Scott Long <scott_long@btc.adaptec.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma Message-ID: <3EFCB725.4060902@btc.adaptec.com> In-Reply-To: <16124.46454.595892.860118@grasshopper.cs.duke.edu> 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> <16124.46454.595892.860118@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EFCB725.4060902>