Date: Wed, 11 Aug 2004 18:28:56 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Thomas Moestl <t.moestl@tu-bs.de> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/man/man9 bus_dma.9 Message-ID: <20040812012856.GY991@funkthat.com> In-Reply-To: <20040812011010.GA4799@timesink.dyndns.org> References: <200408111452.i7BEqXg8071621@repoman.freebsd.org> <20040811150458.GU991@funkthat.com> <20040812011010.GA4799@timesink.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040812012856.GY991>