From owner-freebsd-arch@FreeBSD.ORG  Fri Jun 27 14:22:06 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id F1EB237B401
	for <freebsd-arch@freebsd.org>; Fri, 27 Jun 2003 14:22:05 -0700 (PDT)
Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 1CC6943FAF
	for <freebsd-arch@freebsd.org>; Fri, 27 Jun 2003 14:22:05 -0700 (PDT)
	(envelope-from gallatin@cs.duke.edu)
Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu
	[152.3.145.30])
	by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h5RLM3wV003207
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 27 Jun 2003 17:22:03 -0400 (EDT)
Received: (from gallatin@localhost)
	by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h5RLLwX00743;
	Fri, 27 Jun 2003 17:21:58 -0400 (EDT)
	(envelope-from gallatin@cs.duke.edu)
From: Andrew Gallatin <gallatin@cs.duke.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16124.46454.595892.860118@grasshopper.cs.duke.edu>
Date: Fri, 27 Jun 2003 17:21:58 -0400 (EDT)
To: Scott Long <scott_long@btc.adaptec.com>
In-Reply-To: <3EFCB178.9030207@btc.adaptec.com>
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>
X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid
cc: freebsd-arch@freebsd.org
Subject: Re: API change for bus_dma
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jun 2003 21:22:06 -0000


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

 > 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