From owner-cvs-src@FreeBSD.ORG Thu Aug 12 01:52:24 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 B8E4D16A4CE for ; Thu, 12 Aug 2004 01:52:24 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A0F8243D4C for ; Thu, 12 Aug 2004 01:52:23 +0000 (GMT) (envelope-from tmoestl@gmx.net) Received: (qmail 30913 invoked by uid 65534); 12 Aug 2004 01:52:22 -0000 Received: from p509076EC.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.144.118.236) by mail.gmx.net (mp001) with SMTP; 12 Aug 2004 03:52:22 +0200 X-Authenticated: #5374206 Received: by abel (Postfix, from userid 1001) id 0F10B56E; Thu, 12 Aug 2004 03:53:16 +0200 (CEST) Date: Thu, 12 Aug 2004 03:53:15 +0200 From: Thomas Moestl To: John-Mark Gurney Message-ID: <20040812015315.GB4799@timesink.dyndns.org> References: <200408111452.i7BEqXg8071621@repoman.freebsd.org> <20040811150458.GU991@funkthat.com> <20040812011010.GA4799@timesink.dyndns.org> <20040812012856.GY991@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: <20040812012856.GY991@funkthat.com> User-Agent: Mutt/1.5.6i 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 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:52:24 -0000 --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, 2004/08/11 at 18:28:56 -0700, John-Mark Gurney wrote: > 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 Oops, that should have been "PREWRITE, not PREREAD", of course. > We aren't NetBSD... :) We are compatible with NetBSD in that respect, and should remain so, there's enough confusion about that topic already. > 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... I did. It reads: if (op & BUS_DMASYNC_PREWRITE) { while (bpage != NULL) { bcopy((void *)bpage->datavaddr, (void *)bpage->vaddr, bpage->datacount); bpage = STAILQ_NEXT(bpage, links); } } if (op & BUS_DMASYNC_POSTREAD) { while (bpage != NULL) { bcopy((void *)bpage->vaddr, (void *)bpage->datavaddr, bpage->datacount); bpage = STAILQ_NEXT(bpage, links); } } bpage->vaddr is the bounce buffer address, bpage->datavaddr is the address that the CPU uses. PREREAD isn't even implemented, and PREWRITE does exactly the thing that is required in this situation, copying the data into the bounce buffer for the device to read. > > 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... Well, obviously the NetBSD author thought the other way around, so there is potential for confusion. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ OpenPGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C --qcHopEYAB45HaUaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGs2LH+ZPHUGcd2wRAp4pAJ443Ap5AhfASxJDPxgTZnDDAkb4owCgmSOH ix4PgK8l5ZNI9PO5zdLwygw= =ixBZ -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB--