Re: API change for bus_dma

From: Scott Long (scott_long_at_btc.adaptec.com)
Date: 06/27/03

  • Next message: Andrew Gallatin: "Re: API change for bus_dma" 
    Date: Fri, 27 Jun 2003 15:29:09 -0600
To: Andrew Gallatin <gallatin@cs.duke.edu>

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

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Andrew Gallatin: "Re: API change for bus_dma"