cvs commit: src/share/man/man9 bus_dma.9
gurney_j at resnet.uoregon.edu
Wed Aug 11 18:28:59 PDT 2004
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
> 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."
More information about the cvs-all