cvs commit: src/share/man/man9 bus_dma.9

[John-Mark Gurney]

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