with bus_dmamap_create() and not only bus_dmamem_alloc() so move
the description of this flag up accordingly in order to document
this fact. While at, it refine this description with an application
example.
- Reword the description of BUS_DMA_NOCACHE as this flag is also
implemented on sparc64.
MFC after: 1 week
ago. Document the real behavior of bus_dma_tag_create, bus_dmamap_load,
and other functions. Also document their arguments and return values.
MFC After: 3 days
when it won't be called. The old wording was correct, but not
sufficiently specific to understand when and how it would be called.
The new wording describes the current implementation's usage (which
should be updated if other appropriate times are decided upon),
specifically that it is called only when the load operation is
deferred to keep the locking state consistent. When the operation
isn't deferred, the calling routine is assumed to have a coherent
locking world.
Reviewed by: scottl
the arguments to bus_dmamap_load, so don't use '...' but list the
actual args. '...' usually means a variable number of args (cf
printf(3)), but bus_dmamap_load takes a fixed number of arguments.
to just before bus_dmamem_free, which is (a) more logical; (b) likely
what was originally intended and (c) matches the order in the NAME and
FUNCTIONS sections.
bus_dmamap_sync() by OR'ing them together.
- Don't document what BUS_DMASYNC_PREREAD|BUS_DMASYNC_PREWRITE and
BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE is supposed to do when
passed to bus_dmamap_sync(). There are other possible combinations
and the reader just needs to know what the individual flags do and
that he can combine different DMA operations.
- Use .An when listing authors.
Reviewed by: hmp
