From owner-cvs-src@FreeBSD.ORG Thu Aug 12 01:28:58 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A610416A4CF for ; Thu, 12 Aug 2004 01:28:58 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427C143D5D for ; Thu, 12 Aug 2004 01:28:58 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 14274 invoked from network); 12 Aug 2004 01:28:57 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Aug 2004 01:28:57 -0000 Received: from hydrogen.funkthat.com (nefezk@localhost.funkthat.com [127.0.0.1])i7C1SvuU011980; Wed, 11 Aug 2004 18:28:57 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7C1Su94011979; Wed, 11 Aug 2004 18:28:56 -0700 (PDT) Date: Wed, 11 Aug 2004 18:28:56 -0700 From: John-Mark Gurney To: Thomas Moestl Message-ID: <20040812012856.GY991@funkthat.com> References: <200408111452.i7BEqXg8071621@repoman.freebsd.org> <20040811150458.GU991@funkthat.com> <20040812011010.GA4799@timesink.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040812011010.GA4799@timesink.dyndns.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/man/man9 bus_dma.9 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 01:28:58 -0000 Thomas Moestl wrote this message on Thu, Aug 12, 2004 at 03:10 +0200: > On Wed, 2004/08/11 at 08:04:58 -0700, John-Mark Gurney wrote: > Hmmm. It seems to me that the text the new reference points to is > wrong, or at least ambiguous: > > bus_dmamap_sync() is the method used to ensure that CPU and > device DMA access to shared memory is coherent. For example, > the CPU might be used to setup the contents of a buffer that is > to be DMA'ed into a device. To ensure that the data are visible > via the device's mapping of that memory, the buffer must be > loaded and a dma sync operation of BUS_DMASYNC_PREREAD must be > performed. Additional sync operations must be performed after > every CPU write to this memory if additional DMA reads are to be > performed. Conversely, for the DMA write case, the buffer must > be loaded, and a dma sync operation of BUS_DMASYNC_PREWRITE must > be performed. The CPU will only be able to see the results of > this DMA write once the DMA has completed and a > BUS_DMASYNC_POSTWRITE operation has been performed. > > When the CPU sets up data to be DMAed into the device from memory, it > needs to use a PREWRITE, not POSTREAD, sync before starting the DMA We aren't NetBSD... :) it needs to be a _PREREAD since the device is _reading_ from the cpu's memory... check sys/i386/i386/busdma_machdep.c function _bus_dmamap_sync which does bounce buffering... > operation. Likewise, after DMAing data out of the device and into > memory, a POSTREAD is required. This is quickly evident when looking and here the device is _writing_ to the cpu's memory, and hence a _POSTWRITE... > into the busdma implementations, for example the way the i386 one > deals with bounce buffers on syncs. > The best way to memorize the flags (and probably their origin) is to > imagine a disk controller; a write to disk will need the *WRITE flags > (but it reads from memory), and vice versa. > > NetBSD has a nice clarification: > Synchronization operations are expressed from the perspective of > the host RAM, e.g., a device -> memory operation is a READ and a > memory -> device operation is a WRITE. > > I think that something of that variety is required, since there are > always the two opposite meanings of "reading from" and "reading into". Personally, if I am memory, a device _reads_ me, I don't _read_ a device, it's the device that does the work, not me... the memory isn't active in dma... it's a passive receiver of requests... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."