[Note: changed subject line, removed source-changes, added tech-kern ]

> > > Log Message:
> > > rearrange the order of bus_dma operations to be more like many other
> > > drivers, at the suggestion of fvdl.  also, use bus_dmamap_load() not
> > > load_raw().
> > 
> > You're headed for trouble with this change. According to bus_dma(9),
> > memory allocated with bus_dmamem_alloc() should be loaded with
> > bus_dmamap_load_raw().
> 
> Not really.. there seems to be some confusion on this.
> 
> However, if you map the memory allocated by bus_dmamem_alloc through
> bus_dmamem_map, then you can use the va obtained through this call
> to load the memory into a dmamap using bus_dmamap_load. This is
> what most drivers do.


I am aware of the current practice and interpretation of the existing
bus_dma specs.

Rather, the issue here is how to adjust the bus_dma API semantics so that
it can better accommodate the machine architectures we want it to actually
work on correctly.

The particular problem for DVMA archs like sun3 and sparc[64] is in
dealing with the alignment and boundary arguments to bus_dmamem_alloc().
Unlike other archs, these arguments do not apply to the physical
memory allocated, but to the DVMA addresses allocated at `dma map load'
time.  One way of resolving this issue is to apply more rigour to the
bus_dma(9) semantics, i.e. the requirement to use bus_dmamap_load_raw()
for any segments allocated with bus_dmamem_alloc().

If a change like this leads to problems elsewhere or turns out to be
too rigorous and distorting the entire design then we'll have look
for other solutions, possibly involving an actual API change.


A related semantics issue that remains unresolved in bus_dma(9):
both dmamap_create() and dmamem_alloc() take a `boundary' parameter.
It is not clear what relationship needs to exist between the two
if both are present. Note that on DVMA archs both come into view when
loading a dma map. Probably, the strictest boundary needs to be applied
at that time.

-pk